ifb section vi sub-section b: functional requirements · web viewbank/branch. date of lodging the...

Bidder: <insert bidder name> IDRAS IFB Technical Responsiveness Checklist – 1st Stage Bids 1

<Bidders must complete this checklist and include it within their bid in softcopy Microsoft Word form. Instructions pertaining to the use of the checklist are described in the IFB document. Refer to Section I: Instructions to Bidders (in particular subsection C), Section II: Bid Data Sheet (in particular subsection C), and Section VI: Technical Requirements (in particular subsections G and H).Note that a summary of each requirement is provided for reference. The Bidder is directed to read the Technical Requirements for the full description. >

1 IFB Section VI Sub-Section B: Functional RequirementsReq’t Type

(M / D)Description of Requirement Code for Meeting

Requirement(I, C, M, F, N)

Explanation for Given Code

Taxpayer Registration and Identification Number (REG)REG001 M TIN Assignment: Assign a unique TIN to a taxpayer

when a new profile is created, profile is created, becoming the primary identifier in the system for all operations, and unify TIN and VAT registration processes and application forms. Provide a facility to notify taxpayers by e-mail or SMS on their status of registrationThe system should allow different channels of submission of information from the applicant. Among channels acceptable are on line form and paper filled form. The system should respond back to the applicant acknowledging receipt of the application and advise on the office, date and time an applicant should show up for biometric processes before creating the profile.The system shall assign a unique TIN to a taxpayer when a new profile is created, becoming the primary identifier in the system for all operations, and unify TIN and VAT registration processes and application forms. The system shall have facility to include the vital information of the number issued by the National Identification Authority (NIDA) to provide future linkage with the Government Agency for identifying living individual. This will be option for individuals until such time when registration is completed by the NIDA. The number will be secondary identifier for such individual. Once national identifier is generated for an individual taxpayer, the same is to be updated as secondary field and is to be sent as email and SMS to the taxpayer demographics captured at the time of TIN registration. The solution should provide for controls so that non businesses TIN are not permitted to be used in other business transactions such as

IDRAS 1st Stage IFB 2015


Req’t Type(M / D)

Description of Requirement Code for Meeting Requirement(I, C, M, F, N)


importation of goods for business purposes. In addition, the system shall Provide a facility to notify taxpayers by e-mail, SMS and other means on their status of registration.

REG002 M Detect Duplicate Accounts: Show potential duplicate taxpayer accounts before creating new taxpayer profiles.

REG003 M Record Taxpayer Information: Record new profile information about taxpayers, using the TIN, and scan documents, upload and, store as attachment in the binary format. Furthermore the solution should be able to capture personal and business information including photos, signature and biometric data.

REG004 M Register Taxpayer for Multiple Taxes: Register a taxpayer for multiple taxes. The system MUST provide the capability to add or change the tax types for which a taxpayer is obligated to file and pay.

REG005 M Register Taxpayer Locations: Register a taxpayer conducting business from multiple locations. However, the taxpayer will be required to consolidate his return and file at a location where he is registered

REG006 M Registration Workflow: Provide workflow capability to enable implementation of relevant business processes to allow execution of decision such as approving at different levels of the process; solution which uses the "Status Log" to record the different system (application) statuses. Depending on the status, conditions can be put in place to trigger e.g. workflows to approve or to reject registration forms at different levels of the registration process.

REG007 M Provide Audit Trail: Provide an audit trail of all activity related to a taxpayer’s profile by keeping track of who created or modified the profile and when the creation or modification took place.

REG008 M Maintain Taxpayer Profile History: Maintain all versions of a taxpayer’s profile by always adding new information, never updating existing information.

REG009 M Maintain Versions of TRA Business Rules: Maintain all versions of the TRA business rules by always adding new rules, never updating existing rules.



Req’t Type(M / D)



Note: that this capability is required for all business rules to be implemented for all modules. Furthermore, the business rules must be date sensitive such that Forms have names and versions and a validity date range is recorded for each version of a Form and version. Business applications within IDRAS will use the Form and version applicable to the date relevant to the transaction – refer to requirement CNC003.

REG010 M Support Changes to Taxpayer Reporting: Allow changes, both programmatically and manually, to taxpayer reporting. Such changes could be Jurisdiction Region and taxpayer's registration particulars

REG011 M Support Multiple Taxpayer Addresses: Accept multiple addresses for a single taxpayer.

REG012 D Store Addresses for Each Tax Type: Accept multiple addresses for each tax that a taxpayer is responsible for.

REG013 M Maintain Address for each business Location: Accept multiple addresses for each of the taxpayer’s reporting locations

REG014 M Automated Updating of Taxpayer Accounts: Support a no-human intervention in updating taxpayers’ accounts. Also, enable the TRA to have a single view of taxpayers’ accounts.

REG015 M The system shall be able to de-register taxpayers in line with business rules.

Taxpayer Return, Assessment and Document Processing (RET)RET001 M Return Filing and Processing: The solution should be

able to allow different taxpayer groups to file return and make payments according to the business rule and allow taxpayers to pay advance payments on predetermined periods. The proposed solution should allow electronic filing of returns and offer the possibility to schedule a notification of a requirement to file returns and make payments based on tax statute and tax type e.g. Corporate Tax, Personal Income Tax, VAT, Withholding Taxes, Employment taxes, etc.The solution should provide mechanism to sign such



Req’t Type(M / D)



returns when sending it and issue acknowledgement back to the sender indicating a unique reference number for such transaction. A valid return must be signed by the sender. The requirement for signing the return could be by Digital Signature using Public Key Infrastructure technology.

RET002 M Validate Returns: Provide the capability to perform data validation, using the TRA business rules against data captured from returns. Create work items for returns that fail validation or exceed tolerance levels set for certain data elements. Returns that fail validation will not post to the taxpayer’s account until a resolution is reached. Returns that pass validation but fail tolerance level checks can be posted to the taxpayer’s account.

RET003 M Detect Calculation Errors: Detect calculation errors early. The System MUST calculate automatically all arithmetic operations on the tax return’s fields.Tax return processing capabilities of the System should be able to perform some calculations for all types of taxes for the taxpayer as well as to disallow input of incorrect data in fields, e.g. alpha data in numeric field when entering the data.

RET004 The system must be able to make calculation of tax payable for each tax type periodically and provide notice of assessment to the taxpayer where applicable.

RET005 M Payment Notices: Produce payment notice/slip for a taxpayer to proceed with payment and generate a unique reference number for it.

RET006 M Store Assessment Information: Capture assessment information automatically into the Accounting System immediately when an assessment is raised, including where a taxpayer undertakes self-assessment.

RET007 M Extensions: Grant time extensions to file returns.RET008 M Withholding Taxes: Process withholding taxes:

interest, royalties, technical fees, rental income, insurance, dividends, and transport.

RET009 M Work Item for Out of Business Taxpayer: Generate a work item if a return is received from an out of business taxpayer i.e. previously registered taxpayers



Req’t Type(M / D)



who become dormant and are no longer in operation.RET010 M Warn of Second Return Received in Period: Provide

the capability to limit the filing of only one original return for a reporting period for a tax type, and generate a work item for resolution upon the receipt of a second original return. For VAT and Excise Duty cases only one return is expected in a month. For other taxes only one final return is submitted at the end of the year, however statements of estimates can be filed more than once and such amendments are allowed by the law and will be treated as amended/revised.

RET011 M Balance Return Data: Balance tax return data brought forward from supporting attachments that have been captured by the system. This refers to the summary or totals of the supporting attachments.

RET012 M Support Previous Period Reporting Periods: The system should be able to provide the capability for processing tax returns for reporting periods no longer maintained on the system, e.g. in the case of back duty assessments.

RET013 M Amended Returns: The system shall provide the ability for a taxpayer to file an amended return where the business rules require.

RET014 M Process Integrated Tax Return: Process an integrated tax return and payment regime for periodic tax liabilities (e.g., employee withholdings, VAT, advance payments of corporate income tax, and other miscellaneous taxes) for medium and large taxpayers.

RET015 M Track Channel of Filing: Indicate how a return was filed.

RET016 M Matching of Returns: Facilitate the matching of returns. The system must be able to match Return of Income, VAT Return, VAT 201A, and Withholding Tax Returns, match reports in the Electronic Fiscal Device Management System (EDMS) with the returns submitted by taxpayers. The solution should be able to interface with Customs Systems to march imports /exports with returns for each taxpayer. The system shall be required to provide match of vehicle from CMVRS by disclosing vehicle owned by the taxpayer



Req’t Type(M / D)



during the year of income. The solution shall also have linkage with the Block Management System that provide report for all taxpayers belonging in the blocks and match their properties including buildings.

RET017 M Multiple Channels for Filing: Allow taxpayers to file tax returns through multiple channels, including paper-based forms, fax, or the internet. Validate tax returns, conduct exception handling, and calculate tax liabilities.

RET018 M Printing, Viewing, and Searching of Return Information: The System MUST be able to print, view, search, export data and summarize all tax return information.

RET019 M Identification of Users: The System MUST store the actions of those who entered the return.

RET020 M Returns Reports: The System MUST be able to print and view and allow to save Reports of tax returns or any other standard reports, in Adobe Microsoft Excel pdf or any new technology available, at user request.

RET021 M Capture Tax Assessment Information: Capture all tax assessment information prior to payment.

RET022 M Match Payments: Accurately match tax payments with relating tax assessments.

RET023 D Process Estimated Tax Payable: Process Statement of Estimated Tax payable and Return of Income for entities and individuals.

RET024 M Estimated Tax – Presumptive Regime: Process Statement of Estimated Tax payable for individuals under presumptive regime.

RET025 M Amended Statements: The system shall allow submission and Process amended assessment when changes to the original liability are made and keep track of all changes. Adjustment to the return can be made either by the taxpayer or by the officer after audit procedures. Amendment made by the court shall be the final. Any assessment made by the commissioner shall be served to the taxpayer in electronic media or paper as the commissioner may decide depending on the environment.

RET026 M Jeopardy Assessment Notices: i.e., assessment issued



Req’t Type(M / D)



to taxpayer who want to leave the Republic. In this type of cases assessment are issued without waiting for the date of filing return. The system shall record assessment information and immediately print “jeopardy” assessment notices and forced collection documents.

RET027 M Amended Assessments: Amend assessments when changes to the original liability are made. The system generate task for amended assessment for all the return cases where original return was filed, assessment was done by TRA in the system and where the taxpayer has filed another return. For statement of estimates, taxpayer is allowed to amend his statement any time. In the case of final return, taxpayer is not allowed to amend except for adjusted assessment. 2) After assessment done by TRA, the taxpayer is allowed to object if he has ground of such objection, following which, the return may be amended.

RET028 D Track Assessments: Track additional assessments issued, both forward and backward. Forward assessment means upward assessment issued as a result of additional income, while backward assessments reflect the opposite.

RET029 M Identify Duplicate Assessments: Identify duplicate or similar assessments. E.g. In case taxpayer tries to submit another return for some reasons

RET030 M Generate Presumptive Estimation: Generate presumptive estimation of tax liabilities for non-filers based on all of the following:1. Historical data2. User pre-defined criteria or available fallback/alternative indicators 3. Analysis of similar industries

RET031 M Support Various Penalty and Interest Rates: Calculate applicable penalties and interests using various rates as provided under various Tax Laws defined by the TRA business rules.Rates for Penalties and Interest for each tax type must be able to be easily changed.

RET032 M Calculate Penalties and Interest: Calculate applicable



Req’t Type(M / D)



penalties and interests using rules for a specific tax type

RET033 M Accommodate and support the implementation of an indicator based fallback system to estimate tax dues.

RET034 Tax Assessed Report: The System MUST be able to print and view the total tax assessed by tax return, including interest and penalty imposed for delinquency, for each tax period, tax office and tax type within the interval selected by the user.The solution should provide mechanism to sign such returns when sending it and issue acknowledgement back to the sender indicating a unique reference number for such transaction.

Compliance Monitoring (COM)COM001 M Bankruptcy Warning: Provide the capability to signal

users when a taxpayer has filed for bankruptcy (and what chapter) or is under investigation and audit.

COM002 M Out of Business Warning: Provide a means to denote on taxpayer's profile that the taxpayer is out of business. The solution should be able within the set parameters to flag taxpayers by marking while processing the return in the Taxpayers profile.

COM003 M Warn of Consistent Delinquency: Provide the capability to notify the appropriate user that a taxpayer has been consistently filing late returns.

COM004 M Warn of Fraudulent Returns: Provide a means to denote on the taxpayer’s profile that a taxpayer has a history of filing fraudulent returns.

COM005 M Process Multiple Tax Returns per Period: the capability to process multiple returns per reporting period from the same taxpayer for different tax types.

COM006 M Track One time Extension Request: Provide the capability for users to denote on a taxpayer’s account that a one-time request for extension for filing a return for a specific tax period has been received and granted, and record the date on which the extension has been granted.

COM007 M Track Temporary Extension: Provide the capability for users to denote on a taxpayer’s account that a request for a temporary extension for filing returns for multiple



Req’t Type(M / D)



tax periods has been received and granted, and record the dates to which the extension has been granted and the periods covered by the extension.

COM008 M Track Permanent Extension: Provide the capability for users to denote on a taxpayer’s account that a request for a permanent extension for filing returns for a particular tax has been received and granted, and record the effective date for which the extension has been granted and the tax covered by the extension.

COM009 M Provide Correspondence about Extensions: Provide the capability to generate correspondence to taxpayers when a filing extension has been granted.

COM010 M Returns History: The System MUST store ALL tax returns including history of all deleted (amended) returns submitted by each Taxpayer, for each tax.

COM011 M Identify Under-Estimation: Identify and detect the under-estimation of tax liabilities for non-filers over a period of time

COM012 M Inform Taxpayers of Returns and Amounts Due: Contact taxpayers to request filing of all required returns as well as payment of any amounts due.

COM013 M Record Non-Filing Reasons: Record the reasons for non-filing.For example, application for extension to file return must be supported with reason to be approved by TRA. Such reasons must be stored in the system regardless whether they are granted the extension or not

COM014 M Support Action for Bankruptcy Notice Received: Provide the capability to consolidate activities, suspend collection activities, and generate a bankruptcy claim when TRA receives notice of a taxpayer filing for bankruptcy.

COM015 M Returns Summary Report: The System MUST be able to print and view information regardingi) total number of taxpayers who are due to submit tax return,ii) who submitted tax return;iii) who submitted Zero tax return, and iv) who failed to submit tax return



Req’t Type(M / D)



v) repayment returnsvi) loss returns for their tax period, tax office, tax type within the interval selected by the user

COM016 M The solution should be able to store the filling obligation and remind taxpayers and authority the requirement to file and receive returns according to period as stipulated by the law

Payment Processing (PAY)PAY001 M Direct Refunds as Prepayments: Provide the capability

to direct all or a portion of a refund as pre-payment of tax for the next reporting period, generating the proper accounting transactions.

PAY002 M Payment Reference Numbers and payment Registration: The system should Generate a unique reference number for each tax payment. In this regard the system should enable Taxpayer to properly fill in the online electronic tax payment Order Form which will be available through TRA portal and integrated to IDRAS (which will provide unique Control Number) and electronically IDRAS forward to Taxpayer banker for effecting credit and debit. This control number shall be:

1. accessible to banks through the TRA Web Portal,

2. used for bank reconciliation and crediting taxpayers’ accounts,

3. used by taxpayers to make payments, and4. used to update the system with every

payment made at the bankPAY003 M Statement of taxpayer’s account: Provide the

capability to generate statement of taxpayer’s tax account. The system should be able to match daily debit and credit entries.

PAY004 M Distribute Payments: Provide the capability to apply money paid by a taxpayer in a single payment to multiple tax bills.

PAY005 M Multiple Payments to Single Tax: Provide the capability to apply money paid by a taxpayer through multiple payments to a single tax bill.



Req’t Type(M / D)



PAY006 M Matching of Expected and Received Payments: (a) Control the matching of expected payments against received payments (PAYE); (b) Do not capture PAYE payments paid through the TISS when transferred to the system as both debits and credit; capture debits separately from credits and match the two to ascertain compliance; (c) Capture tax charged in employers payrolls separately from payments received through TISS.

PAY007 M Accept Direct Deposit: Accept direct deposit as detected on commissioner’s account.

PAY008 M Applied Payments to Liabilities Owed: Apply money paid with a single payment to liabilities owed across multiple taxes and multiple reporting periods.

PAY009 M Consolidated Billing Notice: Produce a consolidated billing notice (taxpayer account statement) of all outstanding liabilities for a taxpayer on demand or at regularly scheduled intervals.

PAY010 M Installment Plan: Provide the capability for establishing an Installment Payment Plan for a taxpayer with outstanding liabilities on request, providing for the proper interest and penalties to be forecasted and payment slips to be printed.

PAY012 M Validating Financial Deposits: Provide the capability for a user to validate financial deposits by comparing deposit totals by tax type to Taxpayer Account summary totals by tax type and to Revenue Accounting summary

PAY013 M Bank Payment Details: Automatically receive tax payment details from RGS () and populate the information to respective taxpayers’ accounts on the system totals by tax type.

PAY014 M Electronic Payment Matching: Match payments received through other electronic payment and automatically capture tax payment details from bank accounts and populate the information to respective taxpayers’ accounts on the system totals by tax type.

PAY015 M Reconciliation of Bank Payments: Facilitate automated reconciliation with TRA’s banks collection accounts.



Req’t Type(M / D)



PAY017 M Store Bank Routing and Account Information: Store bank routing and account numbers from taxpayers’ payments.

PAY018 M Support Reversed Payment Transactions with Audit Trail: Provide the capability to reverse all transactions generated by a payment when the payment is returned by the bank.

PAY019 M Provide Suspense Account for Unidentified Payments: Provide the capability to track money received that cannot immediately be associated with a particular taxpayer until it is properly associated with a taxpayer and credited to that taxpayer’s account.

Notes: System must provide ability to move suspense payments to specific payments to taxpayers and tax type.

PAY020 M Track Money Received for Taxpayer Not Identified by Tax: Provide the capability to track money received that can be associated to a particular taxpayer but not to a specific tax type and/or reporting period until it is properly associated with a specific tax type and/or reporting period and credited to that

PAY021 M Payments from Unregistered Taxpayers: Accept payments from unregistered taxpayers booked in the Custody Account.

Notes: System be able to verify through provided paramiters on correctness of TP being not registered.

PAY022 M Clearance of Custody Account: Support the clearance of ‘Custody Account’.

Notes: Custody account be cleared on daily basis by the system.

PAY023 M Accept Various Payment Methods: Accept various payment methods, including electronic funds transfer, the ACH network, debit cards, cheques, credit cards, mobile payment, Mobile banking, POS, ATMS and cash. Support global standardized electronic payment formats, such as EDI, SWIFT as well as various country-specific formats like TISS.

PAY024 M Report of Imported Payment Data: The System MUST be able to store, print, view, search and summarize the



Req’t Type(M / D)



importation of tax payment information for each taxpayer, tax type, date and time, and total amount of payment.

PAY025 M Payments Received & Due Report: The System MUST produce output reports showing the overall situation of each Taxpayer (i.e. the summary for each tax of: include in return processing; (ii) payments made; (iii) payments overdue, if any and the corresponding interest; (iv) interest payments; (v) penalties payments; (vi) payment plans for outstanding debts, including penalties; (vii) tax refunds, etc.).

Notes: At the time of the System’s customization other output reports for payment processing will be defined by the Purchaser.

PAY026 M Payments for Penalties & Interest: The System MUST be able to process the Taxpayer’s payment of interest and penalties for late payment.

PAY027 M Payment Transfers & Adjustments: The System MUST provide ability to transfer payments and immediately adjust account balances of Taxpayer profiles and ledgers.

PAY028 Payment History: The System MUST be able to store the history of changes and deletions made with regard to tax payment.

PAY029 M Report of Imported Payment Data: The System MUST able to store, print, view, search and summarize the importation of tax payment information for each taxpayer, tax type, date and time, and total amount of payment.

PAY030 M Vendor should develop common standard interfaces through which various data from different types of media and disparate multiple stakeholders systems may be exchanged.

PAY031 M Support to various/multiple channels of payments: The system should facilitate revenue payment requirements initiated from different payment delivery channels such as point of sale terminals, mobile phones, ATM, web portals, easy pay, instructions to payers, through commercial banks to the Bank of Tanzania.



Req’t Type(M / D)



PAY032 M The solution should ensure systems security and data integrity is guaranteed as per acceptable best practice and international standards.

PAY033 M Identify fraud that might be or intended to be committed by internal or external parties through sending sms and emails to various approved supervisors

PAY034 M Generation of unique control number for payment: System to generate unique reference number for each tax payment or part there of.

PAY035 M Taxpayer access to payments information: The system should provide a solution that allows a taxpayer to access his/her tax position through TRA web portal.

PAY036 M The system shall electronically prepare revenue cash books, tax collection analysis by collecting agencies and personalized accounts in the form of specific tax types and specific taxpayers.

PAY037 M System monitoring processes: to provide facilities to allow various financial alerts and notifications to taxpayer in the form of SMS, emails, on-screen messages and calls according to the leading practices.

PAY038 M Provide assurance on availability of an effective, adequate and reliable communication infrastructure at 24/7 guarantee.

PAY039 M The solution should provide real-time updating of accounts and taxpayers’ ledgers.

PAY040 M System shall be able to ensure that proper books of accounts are maintained to record all tax revenues from which reliable financial statements can be compiled according to the requirements of IPSAS .

PAY041 M The system should provide a smooth flow of information to and from stations, districts, regions and departments to the Central Revenue Accounting Unit at TRA headquarters.

PAY042 M The solution should provide automated facility to match Tax payments captured into the system with tax assessments raised in the Tax Administration Systems.



Req’t Type(M / D)



PAY043 M The solution should be capable of providing periodic revenue Statements (Monthly, Quoterly, Annually) by a click of a button including; Statement of revenue collections and transfers Statement of comparison of revenue targets and

actual collections Statement of tax exemptions and rebates Statement of tax refunds and reversals Statement of Tax arrears and other outstandings Statement of Tax objections Statement of Tax appeals

PAY044 M The system should facilitate provision of schedules to summary reports and statements.

PAY045 M Registration and validation functionality; to validate the data that makes up a message/ instruction be ac-cepted and registered by the revenue accounting mod-ule according to specified pre-agreed business rules.

PAY046 M The system should be able to electronically record “Tax stood over” information from tax objections into the envisaged Accounting module and update Taxpay-ers profile. The information should include the ob-jected amounts and related penalties, interest and any other future dues as a result of this objection.

PAY047 M The system to provide facility for monitoring of commercial bank tax collection accounts for tax payments received and any entries effected by banks for control and reconciliation. I.e. Through interface be able to monitor actions happening in tax collection accounts maintained with banks.

PAY048 M The system should be the main tax revenue reporting engine and therefore perform a unified revenue ac-counting function facilitated by integration with all col-lection systems like, Central Motor Vehicle Registra-tion Systems, Central Driver’s License System Property tax and any other tax administration system in each of the revenue accounting processes. It should provide a detailed info and summary for all collection in a se-lected period.

PAY049 M Accounting information from other systems shall be extracted through developed interfaces so that Tax-



Req’t Type(M / D)



payer statement of account and payments within this system becomes a single window or point whereby all information of individual taxpayer can be accessed easily and at any time provide credible taxpayer ac-count position.

PAY050 The System should be capable of handling funds adjustments either in Taxpayers’ accounts or commercial banks accounts. In case of wrong credit made to the account of the taxpayer in DRD instead of CED, then cancellation will be made in IDRAS to adjust the same and reverse the entry to update the related accounts. Using the Revenue Gateway System, the IDRAS shall update the respective accounts at the Central Bank to reflect the same.

Refunds Processing (RFD)RFD001 M Refund Processing: Provide an adequate support for

refund processing. The system shall process refunds automatically using workflow management.

RFD002 M The system shall support the classification of taxpayers in Gold, Silver and Non-Gold-Silver.

RFD003 M The system shall provide a function to extract information on the category of traders, evaluate the taxpayers’ history of tax compliance during the last two years and categorize accordingly.

RFD004 M The system shall maintain a classification history of the taxpayers, their classes, change of class, date and time of change as below:

TIN VRN Name of Taxpayer Class Previous class Date of change Name of officer

RFD005 M The system should be able to inform the taxpayer on the change of category where business rules permit.

RFD006 M The system should be able to generate a Tax Compliance Analysis Report periodically showing the following information:

a. S/N



Req’t Type(M / D)



b. TINc. Name of taxpayerd. Nature of businesse. Tax typef. Number of returns filed in timeg. Correctness of return declarationh. Frequency in making timely payments in a

yeari. Audit report findings

RFD007 M The system shall provide a Refund/ Repayment Data Capturing Interface having the following information:

a) TINb) VRNc) Name of Taxpayerd) Category of Taxpayere) Bank Account No.f) Bank/Branchg) Date of lodging the claimh) Period covered by the claimi) Tax typej) Amount claimedk) Amount approvedl) Date of approvalm) Amount paidn) Date of paymento) Approving Authority (Regional Manager/

Manager Technical Service/Revenue Com-missioner/Refund Committee/Commissioner General). The system should provide distinc-tive rights for each approving authority

RFD008 M The System shall provide an electronic link with TRA expenditure system allowing payment updates in taxpayer’s account.

RFD009 M The system should be able to keep an electronic diary showing particulars and status of refund application.

RFD010 M The system must be able to capture trends of Refund performance parameters and report against the parameters.

RFD011 M The system must be able to capture escalation procedures and by making use of workflow escalate



Req’t Type(M / D)



the procedure to the next higher hierarchical level.RFD012 M Depending on their security profile, the system

should enable users to access the system at all levels.RFD013 M The system shall provide an audit trailRFD014 M The system should have a link with audit and debt

management modules.RFD015 M The system should be able to track taxpayers due for

audit and those with tax liabilities.RFD016 M The system should be able to produce the following

reports by Region and Departmenta) List of all refund claimsb) List of refund claim by category (gold, silver,

non-gold-silver)c) List of refund claim by tax type-sectord) List of approved refund by categorye) List of approved refund by tax type sectorf) List of refund paid by category, tax type,

sectorg) List of unpaid refund claims age wise by daysh) List disapproved refund claims by categoryi) Monthly Refund/Repayment Reportj) Monthly Report on outstanding refund/re-

payment claims/age analysisRFD017 M The system should be able to maintain a list of tax

consultants and NBAA registered /authorized accountant or auditor. The register shall comprise of:

a) NBAA Number,b) TINc) Name of the consultantd) Premises of business,e) Year of consultancy,f) Status of the Tax consultant (active/non-

active)RFD018 M Refunding of Tax Paid by Exempt Organizations:

Provide the capability for refunds to be generated for tax erroneously paid by exempt organizations.

RFD019 M Track Users Initiating Refund: Provide the capability for recording the user who initiated refund request.

RFD020 M Update Accounts with Refund Information: Automatically update taxpayers’ accounts upon



Req’t Type(M / D)



effecting tax refunds.RFD021 M Calculate Interest for Refunds: Calculate refund

interest using varying rates depending on tax type and tax period.

RFD022 M Evaluate Risk of Refund Claims: Evaluate refund claims based on risk level. The System MUST be able to provide for the selection of inspection cases based on predetermined risk criteria and generates audit orders.

RFD023 M Pre- and Post-Refund Support: Support pre-audit refund and post audit refund.

RFD024 M Refunds to Offset Other Liabilities: The system must be able to determine if the taxpayer owed monies for other tax liabilities. It must provide the capability to use refunds to offset liabilities across tax types based on the status of a taxpayer’s account and generate the proper accounting transactions.

RFD025 M Installment Payment of Refunds: Provide the ability to pay refund claims by installments.

RFD026 M Tracking Decisions on Refunds: The System MUST store and change the decision of granting tax refund.

RFD027 M Retrieving Refund Information: The System MUST be able to view, search, print and summarize all refund information.

RFD028 M Refund Reference Numbers: The System MUST be able to process each tax refund request and generate corresponding responses with a unique reference number.

RFD29 M Refund History: The System MUST be able to store all documents related to refunds

Revenue Accounting (RVA)RVA001 M The system shall electronically prepare revenue cash

books, tax collection analysis by collecting agencies and personalized accounts in the form of specific tax types and specific taxpayers.

Notes: Refer PAY039.RVA002 M System monitoring processes to provide facilities to

allow various financial alerts and notifications in the form of SMS, emails, on-screen messages and calls ac-



Req’t Type(M / D)



cording to the leading practiceNotes: Refer PAY040.

RVA003 M Provide assurance on availability an effective, ade-quate and reliable communication infrastructure at 24/7 guarantee.

Notes: Refer PAY041.RVA004 M The solution should provide real-time updating of ac-

counts and taxpayers’ ledgers.Notes: Refer PAY042.

RVA005 M System shall be able to ensure that proper books of accounts are maintained to record all tax revenues from which reliable financial statements can be com-piled according to the requirements of IPSAS and IFRS.

Notes: Refer PAY043.RVA006 M The system should provide a smooth flow of informa-

tion to and from stations, districts, regions and depart-ments to the Central Revenue Accounting Unit at TRA headquarters.

Notes: Refer PAY044.RVA007 M The solution should be provide automated facility to

match Tax payments captured into the system with tax assessments raised in the Tax Administration Sys-tems.

Notes: Refer PAY045.RVA008 M System be capable of producing accounting required

basic reports and records for quick decision making like;

Performs reconciliation of revenues per ac-counts maintained,

Maintain chart of accounts to identify collection items and structure of posting accounts.

Generates Cash Books, Books of Accounts, Gen-eral Ledger and Final Accounts

Prepares Revenue Executive Summary Prepares Management Information Reports Prepares Country Tax Revenue collection State-

ments daily, weekly and monthly.RVA009 M The solution should be capable of providing annual

revenue Statements by a click of a button without fur-ther manipulations so as to include;



Req’t Type(M / D)



Statement of revenue collections and transfers Statement of comparison of revenue targets

and actual collections Statement of tax exemptions and rebates Statement of tax refunds and reversals Statement of Tax arrears and other outstanding Statement of Tax objections

Notes: Refer PAY046.RVA010 M The system should facilitate provision of schedules to

summary reports and statements.Notes: Refer PAY047.

RVA011 M Registration and validation functionality to validate the data that makes up a message/ instruction be ac-cepted and registered by the revenue accounting mod-ule according to specified pre-agreed business rules.

Notes: Refer PAY048.RVA012 M Tax stood over records: The system should be able to

electronically record “Tax stood over” information from tax objections into the envisaged Accounting So-lution.

Notes: Refer PAY049.RVA013 M Monitoring banks collection accounts: The system to

provide facility for monitoring of commercial bank collection accounts for tax payments received and any entries effected by banks for control

Notes: Refer PAY050.RVA014 M The system should be the main tax revenue reporting

engine and therefore perform a unified revenue ac-counting function facilitated by integration with all collection systems like New Customs Management Sys-tem in each of the revenue accounting processes

Notes: Refer PAY051.RVA015 M Monitoring of Transfers: The system should monitor

electronically monthly transfers from Commissioners’ revenue accounts at commercial banks and BOT to PMG account at BOT.

RVA016 M GFS codes: The new system should match latest Gov-ernment Financial statics (GFS) codes as issued by IMF to the types of taxes collected for better reporting of government revenues.



Req’t Type(M / D)



Tax Audit (AUD)AUD001 M Audit Management Information: The system must

provide solution for monitoring tax audit cases countrywide.

AUD002 M Audit Selection: Identify and allow selecting taxpayers for audit on configurable audit parameters based on weight and score for each risk such as:

1. Tax type2. Tax payment levels3. Sales levels4. Income levels5. Comparison of common items and/or trends

across business groups.6. Comparison of common items or trends between

taxpayers in business classes that are alike7. Comparison of common deductions between

taxpayers8. Previous tax payment amounts adjusted for

audited amounts as compared to current tax payments

9. Taxpayer’s compliance10. Multinational companies: Branches and

subsidiariesNotes: These parameters shall be used singly, in groups or combination of customers/taxpayers depending on the need and should be configurable and customizable per taxpayer or their combination, industry, sector and any other parameters as appropriate.The dynamic risk engine shall be deployed that shall be configurable to meet different risk requirements based on different profile characteristics of tax type, compliance, industry, sector, business, industry, taxpayers, regulation, laws, customers, compliance strategy (meet criteria, strategy response - resources allocation etc.), or any functionality implemented in the revenue administration across the Authority

AUD003 M Record Audit Activity: Assign cases and allow audit groups and/or individuals to record activity on cases,



Req’t Type(M / D)



schedule the next appropriate actions, and provide a basis for individual workload scheduling, follow-up, and case load evaluation. Should also provide creation of an audit work item while audit is in place and allocate the work item to the audit Team or individual with a plan for closure.

AUD004 M Update Audit Case Information: Automatically update audit case information when new taxpayer profile information is added.

AUD005 M Import External Source Data: Provide that the capability to allow TRA to load data from different sources to match against data in the system to generate audit leads.

AUD006 M Upload Audit Information: Provide the capability to upload audit information directly into the system.

AUD007 M Support Audit Activity: Provide adequate support for the audit cycle, risk profiling, and audit case selection and preparation.

AUD008 M Risk Profiling for De-Registering Taxpayers: The solution should be able to risk profile a Taxpayer before de-registration is effected by booking as a special case either comprehensive or issue oriented audit.

AUD009 M Day-to-Day Audit Activity Recording: Allow the auditors to record every procedure in the system on a day-to-day basis. Report on omitted steps in the audit, and any departure from the set standards shall be viewed by the supervisor for protection purposes.

AUD010 M Auditing Support: Support Risk Profiling, Annual Audit Business Planning, and Scheduling of Audit.

AUD011 M Audit Team Assignment: Assign audit teams to specific audit cases. The selection assignment of auditors should take into consideration each auditor’s workload and the need to use a different auditor after two consecutive audits

AUD012 M Rotation of Auditors: Support the rotation of auditors and audit cases. No auditor shall audit the same case after two consecutive audits.

AUD013 M Audit Case Support: Support all of the following:1. Selection of audit cases based on risk ratio



Req’t Type(M / D)



2. Generation of the Audit Business Plan3. Notification of the taxpayer4. Generation of the Case Audit Plan, Audit

Timesheet/Management Reports, Monthly Report of Audit Results, Narrative Audit Report, and Audit Results Report.

AUD014 M Audit Reports and Results: Support the issuance of audit reports and determine which audited account can result in additional tax, penalty, and interest liabilities; tax refunds; or no changes in tax liability.

AUD015 M Identifying Tax Frauds: The system shall have an algorithm that helps identifying tax frauds for referral purposes.

AUD016 M Logging Audit Status: Log the status of a tax account under audit.

AUD017 M Links to Previous Audit Findings: Support linkage and comparison with previous audit findings.

AUD018 M Maintenance of Risk Criteria: The Audit risk parameters must be configurable thus able to create, change and delete selection criteria of tax audit. Selection criteria can be fixed or ad-hoc.

AUD019 M Reporting Search Results of Applying the Selection Criteria: The System must be able to report the results of applying selection criteria for audits.

AUD020 M Printing, Viewing and Searching of Taxpayers to be Audited: The System mustbe able to print, view and allocate the number of taxpayers to be audited.

AUD021 M Audit Plans: The System must support an authorized user to develop or change a monthly and/or annual plan of audit.

AUD022 M Direct Selection of Taxpayers for Audit: The System MUSTallow direcly selecting the taxpayer for audit regardless of selection criteria and record the reasons of tax audit.

Notes: Documents supporting the reason should be able to be entered into the System by scanning.

AUD023 M Random Selection of Taxpayers for Audit: The System MUST provide for the random selection of Taxpayers on a periodic basis.



Req’t Type(M / D)



AUD024 M Unique Numbering of Tax Audit Reports: The System should provide for the automatic assignment and register a consecutive and unique number to all tax audit reports including printed documents that were made void

AUD025 M Summary Report of Auditor’s Activities: The System should be able to produce a report summarizing each auditor’s activities (i.e. audits conducted, average audits duration, penalties assessed, comparison of actual auditing activity against objectives, adjustments done in the Taxpayer’s assessment details, etc.).

AUD026 D Comparing Audit Peformance with Audit Plan: The System SHOULD be able to print and view the comparison of tax audit plan against tax audit performance by taxpayer’s activity, tax type, schedule of tax audit, tax staff , tax office, and reason of tax audit, etc.

AUD027 M Track Audit Status: Indicate which taxes and which tax periods have been or are under audit in order to create a work item should amended returns be filed for those periods.

Tax Investigations (INV)INV001 M Criminal Investigation Management Information: The

system must provide solution for monitoring criminal investigation cases countrywide.

INV002 M Investigation Case Support: Support all of the following 1. Selection of investigation cases based on risk criteria. 2. Generation of the Investigation Business Plan. 3. Notification of the taxpayer 4. Generation of the Case Investigation Work Plan, Investigation Time Consumption sheet/Management Reports, Monthly Report of Investigation Results, Narrative Investigation Report, and Investigation Results Report.

INV003 M Maintenance of Risk Criteria: The Investigation risk parameters must be configurable thus able to create, change and delete selection criteria of tax investigation. Selection criteria can be fixed or ad-hoc.

INV004 M Case selection: The solution must have algorithm/parameters that helps identifying cases with indicators of tax fraud.



Req’t Type(M / D)



INV005 M Direct Selection of Taxpayers for Investigation: The System MUST allow directly selecting the taxpayer for investigation regardless of selection criteria and record the reasons of tax investigation.

INV006 M Random Selection of Taxpayers for Investigation: The System MUST provide for the random selection of Taxpayers on a periodic basis.

INV007 M Reporting Search Results of Applying the Selection Criteria: The System must be able to report the results of applying selection criteria for investigations.

INV008 M Match Returns and information from internal and external sources: The system must have capability of uploading, analyzing information from statutory returns submitted by taxpayers and match with information received from internal (TANCIS, CMVRS), and external sources (Financial institutions, government ministries and private sector etc. and informants).

INV009 M Investigation of Income Sources: Support the investigation of taxpayer sources of income, assets, and third party sources and data.

INV010 M Referral cases: provide facility for receiving list of cases referred from Domestic Revenue Department (DRD) or Customs and Excise Department and reviewing, evaluating and identify elements of tax fraud.

INV011 M Inquiry number: The system must provide facility for providing inquiry numbers on sequential numbers that is centrally controlled for all cases identified with indicators/elements of tax fraud and thereafter allocate to respective ZONAL Managers for dissemination to Primary investigators.

INV012 M Uploading data: The solution must have the capability of uploading taxpayer profile information from registration module and add other necessary single or multiple data fields that are mandatory or option for the purpose of input addition information not available in the registration module.

INV013 M Review and evaluation of allegations: Provide facility for investigators to input information in respect of



Req’t Type(M / D)



reviewing, evaluating assigned cases and determine if the criminal tax fraud may have occurred.

INV014 M Report transmission: Provide a solution for online transmission of reports to Supervisor, and Reviewer.

INV015 M The system should provide a mechanism for providing feedback to Primary Investigators, Supervisor and Reviewer.

INV016 Evaluation of Allegations or Referral cases: the system must have the capability of creating communication channel to provide feedback on decision made in respect of preliminary report on inquiry initiated. If the investigation request for investigation is declined the system must provide a facility for additional screen/window requiring the supervisor to provide reason/s for rejection and the system must have the facility to send the inquiry into close status. If the Supervisor is returning preliminary inquiry report to the investigator for additional work prior to numbering the investigation request should not be rejected.

INV017 M Approval for Investigation initiation: Provide facility for approving initiation of investigations. if the request for investigation initiation is approved by superior the system must provide a facility to communicate the preliminary inquiry report to the CTI seeking for approval to initiate criminal investigations.

INV018 M Investigation reference number: the system must have capability of generating an investigation number automatically after the approval to initiate investigation is granted.

INV019 M Investigation activities: the solution must provide a facility for recording investigation activities from the initiation stage to closure.

INV020 M Time consumption sheet: The system must have a capability to monitor time spent by each investigator in a specific investigation case.

INV021 M Workload analysis: the system must have capability of analyzing man-hours and ascertaining workload for each investigator based on working hours in a specific period.

INV022 M Specific Method of investigation: the system must



Req’t Type(M / D)



provide algorithm/parameter for computing tax evaded under specific method of investigations i.e. Net worth method, expenditure approach method, bank deposit method

INV023 M Tracking the Status of the case: The system should provide a mechanism to track status of the case using the investigation initiation number

INV024 M Search seizure: provide facility recording assets, equipment and documents seized.

INV025 M Recording evidence: the solution must provide facility for recording/scanning tax fraud evidentiary documents seized by investigators

INV026 M Forensic laboratory inputs: The solution should provide online form for requesting forensic expert/s to participate in evidence collection of a specific case. The form should indicate the name and position of the forensic official.

INV027 M Additional Forensic Evidence: Provide facility for recording and numbering assets or equipment involved and type of evidence/information collected

INV028 M Control duplicate investigations: Provide facility to display message/alarm/warning to the data entry operator of duplicate investigation. The system should have the capability of ensuring that the same investigation number is not used to cover subsequent investigation of the same taxpayer where the prior criminal investigation was concluded and closed.

INV029 M Additional violations: the system should provide a facility that if there is an ongoing investigation on a taxpayer, then any additional violation should be investigated in combination with those ongoing investigations.

INV030 M Transfer Tax Investigation Cases: Provide facility for approving the transfer of Investigation cases from one zonal office to another.

INV031 M Reviewing investigation report: Providing mechanism of reviewing investigation report at different levels of approving official with a notation that the investigation has been reviewed showing the name of the reviewing official and the date it was reviewed.



Req’t Type(M / D)



INV032 M Recommendation for prosecution: the system must provide a facility to input information that evidence collected is sufficient to support recommendation of prosecution. Provide a facility to provide list of tax laws violation and charging sections.

INV033 M Referral for Prosecution: provide mechanism of referring cases to legal department for prosecution.

INV034 M Prosecutor: the system should provide facility to track down prosecutor handling the case.

INV035 M Court Decision: the facility must provide communication channel to provide feedback on court decision.

INV036 M Referral for civil settlement: Provide facility for recording investigation cases discontinued because the evidence does not substantiate criminal activities therefore referral to Commissioner for DRD or Commissioner for Customs and Excise for civil settlement.

INV037 M Printing, Viewing and Searching of Taxpayers to be Investigated: The System must be able to print, view and allocate the number of taxpayers to be investigated or under-investigation.

INV038 M Electronic Archiving: Provide electronic archiving of investigation documents.

Collection of Delinquent Accounts/Enforced Collection (COL)COL001 M Identify Delinquent Taxpayers: Identify delinquent

taxpayers based on the TRA business rules e.g. ageing, write-off, collectable and uncollectable, etc. for each tax type and/or report.

COL002 M Requests for Payments: Provide a mechanism (e.g., SMS, emails, Faxes) for contacting taxpayers and requesting payment of all delinquent and current taxes that are due.

COL003 M Track Delinquent Tax Returns: Record delinquent tax returns and all amounts due

COL004 M Reports of Ability to Pay: Generate reports for reviewing a taxpayer’s financial records and third party data to determine the taxpayer’s ability to pay delinquent taxes that are due.



Req’t Type(M / D)



COL005 M Reasons for Non-Payment: Record the reasons for non-payment.

COL006 M Detect non-Payers and Late Payers: The system should provide a solution for detecting non-payers and late payers. As per user requirements, e.g. per tax type, sector, business type, etc.

COL007 M Reconciliation of Payments: Support the reconciliation of payments including partial payments with assessment debits.

COL008 M Determine Collectability of Liability: Determine if a tax liability is collectible with reasons based on specific set parameters.

COL009 D Identify Cases to Pursue: Identify cases to be pursued legally based on case risk level and case materiality.

COL010 M Impose Penalties: Automatically impose penalties on unpaid taxes.

COL011 M Compute Late Payer Interest and Penalties: Automatically compute interest and penalties for late payers.

COL012 M Posting of Non-Payers’ Penalties and Interest Due: Support loading of Penalty and Interest to a non-payer taxpayer’s account.

COL013 M Collection Payment Plans: The System MUST provide ability to set up, maintain a payment plan for taxpayers and provide alert mechanism.

COL014 M Collectors’ Work Baskets: The System MUST allow the authorized user to upload the new overdue accounts to staff’s “work basket”. This process can be run nightly or weekly as decided by an authorized user.

COL015 M Case Selection for Debt management: Allow case selection for enforcement based on risk indictors.

Notes: Calculating Risk: Risk categories for different classes of

delinquents based on amount of expected debt and probability.

Must provide the ability of recovery Priorities, packages of actions, and resources for each risk category

History of actions taken to recover previous returns for the particular taxpayers.



Req’t Type(M / D)



COL016 D Monitor Taxes Due: Monitor taxes due, support enforcement (e.g., reminder letter, demand letter), and report on taxes overdue/arrears.

COL017 M Risk Management: Provide risk management that will determine the chances of actual collection of tax from specific taxpayers and groups of taxpayers. Also, allow determining and inputting various profiles based on the tax policies and laws of Tanzania which will be used to analyze and forecast tax collection.

COL018 M Support Hold on Collection: Provide the capability for a user to place a “hold” on an account so that further collection activity will be suspended while the “hold” is in effect

COL019 M Release Hold on Collection: Provide the capability for a user to release a “hold” that was previously placed on an account.

COL020 M Assignment of Collection Accounts: The System must allow the authorized user to assign one overdue account to one or more staff and store the assignment information. Based on results of risk analysis on overdue accounts and taxpayers who are in risk identified categories, the overdue accounts can be assigned in a way that “junior” or less experienced staff member to the accounts identified as requiring only minimal attention whereas the more experienced staff can then concentrate on more difficult taxpayers and enforcement.

COL021 M Assigning and Tracking Due Dates: The System must support a “future” view date and amounts owing to the specified date.

Notes: Tax office, a tax staff shall define the due date of the payment of tax arrears as follows: Tax arrears and tax remains revealed

through tax imposition shall be paid within pre-determined number working days since handing over such act;

Re–imposed tax, interest and fine revealed through tax audit shall be paid within a specific number of working days since handing over such act.



Req’t Type(M / D)



COL022 M Tracking Non-Payment and Stop Payments: The System must provide the ability to view and sort non-payments and stop-payments by tax type and taxpayer group and amount and date.

COL023 M Support for No Returns Required and NIL Returns: The System MUST provide the ability to determine “No Returns Required and NIL” returns from specific taxpayers for all tax types.

COL024 M Support of Payment Processing Workflow: When there is an agreed-upon payment plan for an outstanding debt and the Taxpayer fails to make one of such payments, the System MUST automatically move the Taxpayer’s account to the next collection step as predefined by the authorized user.

Notes: Upon receiving a request filed by the taxpayer to extend the payment due date and supporting attachments, a head of the particular tax office by his/her decision may extend the date of payment once up to 60 days if there are grounds to deem taxpayer’s request is reasonable and taxes are to be paid reliablyPayment plan arrangement may be changed depending on the situation.

COL025 M Monitoring Payment Plans: The System MUST automatically monitors payment plans, identifies and informs of payment default.

Notes: Due date for payment is generally falls into:

Due date as stated in law Period to pay tax arrears after act being

issued according to law Additional period or postponed due

dateTax not paid during above stated period shall be deemed as delinquent taxes and subject to enforcement action

COL026 M Criminal Act Notices: Capture and process criminal act notices received from various processes, including court rulings.

COL027 M Rules for Processing Overdue Accounts: The System



Req’t Type(M / D)



must be able to automatically move overdue accounts through the collection process based on the predetermined rules and time intervals. Predetermined rules and time intervals will be configured by the authorized user.

COL028 M Identify Taxpayer Asset Types: Automatically identify movable and immovable assets of a taxpayer using data available in the system or other systems that can be attached or seized for non-payment of taxes due.In case there are no data enough to build such intelligence user can capture those information from external sources.

COL029 M Track Recovery/Enforcement: Track and monitor recovery and enforcements tasks.

COL030 M Double Enforcement Tasks: Initiate double enforcement tasks simultaneously.

COL031 M Seizure of Goods: provide the capability to automatically process distraint action(seizure of goods and chattels) that reflect the total taxes amounts due from the taxpayer including the appropriate seizure fees and costs based on the business rules.

COL032 M Information of seized goods: the system must provide the ability to view, print, and summarize information of seized goods and chattels including value date of distraint and expected date of auction.

COL033 M Information of goods under walking possession: the system must provide the ability to view, print and summarize information of goods and chattels seized but left in the possession of the taxpayer under an agreement not to dispose of.

COL034 M Support Auction Process: the system must be able to support auctioning process including selection of court broker, determination of fees and cost of auctioning, maintain the amount of taxes collected and refund of any excess monies collected from the auction.

COL035 M Release of seized goods: the system must provide capability to automatically process release of seized goods where tax is paid before their auctioning.

COL036 M Recovery of tax from tax debtor: provide the capability to automatically recover tax from tax debtor



Req’t Type(M / D)



including instituting suit for unpaid tax.COL037 M Recovery of tax from third party: provide the capability

to automatically institute recovery of third party liability including recovery from receiver/person owing money to a tax debtor and agent of non-resident person.

COL038 M History of Bank Action: The System MUST store the records of bank action on freezing taxpayer’s bank account and its cancellation. The System should be able to produce records of cancellation of bank account freeze once all monies have been recovered.

Notes: If delinquent tax was not paid within 10 working days of sending the delinquency notice, the tax office shall send a letter of notification to the banks to freeze the taxpayer’s out-flowing transaction.Upon receiving an official letter for cancellation of “notification letter/banks” sent by tax office, the bank action shall be terminated.

COL039 M Registration of Interest in Immovable Property: The system must be capable of automatically registering interest of the Commissioner in immovable properties held or seized for non-payment of taxes. The system must be capable to process approval from appropriate authority for auctioning an immovable property in which the Commissioner has registered interest for non-payment of taxes.

COL040 M Cancellation of interest in immovable property:-the system must be able to automatically cancel interest previously registered in an immovable property upon proof of satisfaction of the tax debt or presence of an acceptable alternative security for unpaid taxes.

COL041 M Offsetting of multiple liabilities: The system should provide a solution for tax offset by excess tax paid on another tax.

Notes: For example, if a taxpayer who owes the government from two different taxes paid an excess amount on the first tax and then offset the second payment with the excess payments from the first tax, the system shall capture that transaction and the second tax shall not



Req’t Type(M / D)



continue to be delinquent.COL042 M Bankruptcy Proof of Claim: Produce a Bankruptcy

Proof of Claim and applicable exhibits with interest computed to an applicable date.

COL043 M Staff Performance Reports: The System MUST be able to produce reports indicating the effectiveness of each staff (average days required to collect an overdue tax, number of cases where collection was not possible, number of phone calls and visits made by each collector, etc.

Notes: The performance indicators are developed by a tax office and entered into the System.

COL044 M Collection Reports: The System MUST provide the ability to view, print, search and summarize information, e.g.; amount due, age analysis, amount collected, outstanding amount pending etc. for each staff and for each tax office which can be exported to commonly used file formats like Excel and PDF etc. The system should be enabled to send summary of collection reports for a given period to designated officers through various channels.

Appeal Management (APM)APM001 M Output for Objection and Appeals: Produce the

expected output for Objection and Appeals, as per the business requirements. Automatically file all objections and appeals and update accounts to reflect the cases. Automatically prepare all weekly, monthly, and annual reports from objections and appeals according to user formats e.g. Tax discharged, Tax confirmed, Taxpayers who are flagged as frequent objectors.

APM002 M “Tax Stood Over” Information Capture: Electronically capture “Tax stood over” information from tax objections and tag this information to the Taxpayer account.

APM003 M Track Dates: Track different dates that are necessary in the validity of objections. Therefore, provision for tax under objection is done by the system. Closely monitor the process of determination of objections and demarcates (from tax arrears) the tax assessments



Req’t Type(M / D)



which are under objectionsAPM004 M Support Objection Processes: Support all of the

following objection processes:1. Receiving new objections2. Validating objections according to prevailing set

criteria and a provision for Commissioner to intervene with reasons

3. Allocating objections to teams and officers.4. Produce a report summarizing each

team/officer’s activities (i.e. objections settled, average number of objections handled, adjustments done in handling the objected issues, etc.)

5. Preparing objections panel6. Preparing settlement of objections7. Prepare analysis of objections by age, value,

complexity, category, tax type, sector8. Prepare Objection settlement plan start and end

of the case.9. Processing appeals from taxpayer and keep track

of proceedings: receiving appeals instructions, allocating advocates to the appeal case, preparing pre-hearing, and preparing appeals resolution

APM005 M Capture/Process Appeal Data: Capture and process appeal data in all phases of the appeal; namely, administrative appeal, board of appeal, and tax court. Additionally, keep history records of all submitted and determined appeals (objections).

APM006 M Electronic Archiving: Provide electronic archiving of objections and appeal documents.

Taxpayer Services: Customer Feedback Management (CFM)CFM001 M Allow taxpayers to register complaints, enquiries and

comments through multiple channels including social media

CFM002 M Make the system to capture and analyze the taxpayers complaints, enquiries and comments automatically

CFM003 M Reports: The system to generate daily, weekly, monthly quarterly and annually reports of taxpayers’



Req’t Type(M / D)



feedbackCFM004 M Taxpayer’s education: Support online provision of tax

education to taxpayersCFM005 M Customer Relationship Management System (CRMS):

Provide interface/link with CRMS which is currently in operation at the TRA Call Centre

Case Management and Tracking (CSE)CSE001 M Support for All Functional Areas: Support all of the

following processes:1. Registration (TIN)2. Returns capturing3. Tax assessments4. Tax collection5. Accounting6. Audit7. Debt management8. Reporting9. Objections and appeals10. Refunds for all domestic taxes and levies11. Non tax Revenue collections

CSE002 M Links to Other Components: Enable the linking of objects/components from different applications. E-filing of returns and e-payments using mobile phones and other various channels

CSE003 M Track Staff Assignments: Trace progress of tasks/documents assigned to various staff.Furthermore, identify those which are completed, within time frame and the overdue ones. (The aim is to provide a good tool for managing staff performance.)

CSE004 M Setup Roles and Responsibilities: Setup roles and responsibilities appropriately based on the job description of the staff users.

CSE005 M Workflow Tools: Provide workflow tools to support a progressive set of measures designed to collect amounts due to the TRA in an efficient manner. That is, utilize workflow technology to sort, prioritize, and route work to the appropriate user.

CSE006 M Process for Editing Transactions: Support change management process for editing approved transactions.



Req’t Type(M / D)



CSE007 M Business Rules: Enforce all business rules into the system to ensure that all transactions are appropriately checked and authorized before being committed.

CSE008 M “Pulling” of Work Items: Allow users to “pull” unassigned work items.

CSE009 M Push of Work Items: Allow supervisors to “push” work items.

CSE010 M Priorities: Assign priorities to work items in workflows.CSE011 M Auto Increment of Priorities: Automatically increment

priorities of “un-pulled” work items over time.CSE012 M On-demand Increment of Priorities: Increment

priorities of work items on an as-needed basis.CSE013 M Expedite Business Processes: Expedite a business

process from beginning to end on an emergency basis.CSE014 M Deadlines: Provide the capability to allow a user to

place a deadline for completing a process.CSE015 M Transfer of Work Items: Provide the capability to allow

a user to transfer assigned work items.CSE015 M Assignment of Work Item: Provide the capability for a

user to directly assign a work item to a specific user.CSE015 M Adjustment of Workloads: Provides the capability for

users to allow adjustments to workloads to correct out-of-balance conditions.

VAT Relief Processing (VREL)VRL 001 M Provide support for VAT relief processing: The system

should be able provide an adequate support for VAT relief processing.

VRL 002 M VAT Relief Work Flow Management: The system should be able to process VAT relief application using Work Flow Management.

VRL 003 M Interfacing with other modules of IDRAS: The system should be able to interface relief module with other modules of the systems (IDRAS) E.g. registration module, return processing etc.

VRL 004 M Track Users Initiating VAT relief: The system should be able to record the user who initiated VAT relief date and approvers

VRL 005 M Evaluate risk of VAT relief application: Evaluate VAT



Req’t Type(M / D)



relief application based on risk level. The system must be able to provide the selection of inspection cases based on pre-predetermine risk criteria and generate verification orders

VRL 006 M VAT relief reference Numbers: The system must be able to process each VAT relief application and generate corresponding responses with unique reference number.Also the system must be able to provide users decision and recommendation on various levels.

VRL 007 M Retrieve VAT relief information: The system must be able to view, search, print and summaries all vat relief information.

VRL 008 M Tracking decision on VAT relief: The system must store and change the decision of granting relief and notify the taxpayers of the decision.

VRL 009 M Update VAT relief information: Automatically provide information on items, estimated values and supplier of the items or service.

VRL 010 M Relief History: The system must be able to store all documents related to VAT relief.

Interfacing and Integration (I&I)I&I001 M Electronic Interface with BRELA: Provide an electronic

data exchange interface with the business registration system at the BRELA.

I&I002 M Electronic Interchange with Other Systems: Provide electronic data exchange interface between TRA and other Government Institutions of Pension schemes (e.g. NSSF, PPF, PSPF), Professional bodies (e.g. NBAA, ERB, Tanganyika Law Society etc.), TIC, TCCIA, CTI, PPRA, TCRA, NIDA and other regulatory bodies.

I&I003 M Client Applications: Implement TISS, enable mobile payment, and enable the use of client applications such as TaxBank to enable the generation of unique reference numbers for every payment made by taxpayers.

I&I004 M Interface with Key ICT Systems: Interface with different key ICT systems of external stakeholders such as commercial banks, BoT, and Accountant General in order to enable seamless flow of data and information



Req’t Type(M / D)



among these systems.I&I005 M Integrate with Revenue Accounting: Integrate with

revenue accounting, the ERP systems, and other government agencies which collect other fees, levies, and licenses.

I&I006 M Bank Revenue Collection: Allow configuration to work with TaxBank client for banks, for revenue collection.

I&I007 M Data Exchange: Implement a data exchange capability between TISS/Revenue Gateway and revenue administration systems at the TRA.

I&I008 M Existing Data in Database: Either work with the existing database or migrate existing data to the new system’s database.

I&I009 M Integrate to produce overall ‘Holistic Single view of Taxpayer’: TRA intends to integrate all its systems to enable taxpayers view all its activities with the Authority. The system shall be configurable using open standards to enable this integration

I&I009 M Interfaces with Applications: Interface with a number of applications/systems that have been implemented to support various processes in the TRA, including all of the following:

1. CMVRS and CDLS2. New Customs System -TANCIS3. Mobile Phone4. Revenue accounting system5. Banking systems operated by various

banking institutions6. Data warehouse system7. EFD Management software8. Financial systems9. TRA Revenue Gateway System (RGS)10. A Monitoring and Evaluation Database

(TRAMED)11. SMS gateway12. Automatic Fingerprint Identification

System (AFIS) (Used for Taxpayer’s registration)

13. Geographical Information System (GIS)14. Other relevant system



Req’t Type(M / D)



The system shall be capable of interfacing using international open standard protocols.

I&I010 M Integrate Revenue Accounting: Integrate revenue accounting and control functions with the tax and revenue management processes to provide all of the following:

1. Timely tax and revenue distribution2. New Customs System3. Mobile Phone4. Revenue accounting system5. Banking systems operated by various

banking institutions6. Data warehouse system7. EFD Management software8. Financial systems9. TRA Monitoring and Evaluation Database

(TRAMED)10. TRA Revenue Gateway System (RGS)11. SMS gateway12. Automatic Fingerprint Identification

System (AFIS) (Used for Taxpayer’s registration)

13. Geographical Information System (GIS)14. Other relevant systems

The system shall be capable of interfacing using international open standard protocols.

I&I011 M Integrate Revenue Accounting and Control Functions: Integrate revenue accounting and control functions with the tax and revenue management processes to provide all of the following:

1. Timely tax and revenue distribution2. General ledger accounting3. Funds management4. Fiscal reporting to legislative bodies and the

publicI&I012 M Recording of Payments by TISS/Revenue Gateway:

Allow automatic/manual recording and loading payments by TISS/Revenue Gateway and reconcile them automatically.

I&I013 M Transfer/Exchange Data: Transfer/Exchange data



Req’t Type(M / D)



electronically with governmental and non-governmental institutions (e-government).

I&I014 M Bank Interface: Interface with banks to enable banks to provide payment data in electronic form according to a specific format.

I&I015 M Legacy Interfaces: Interface with legacy systems (e.g. HRMIS). This is a two-way interface solution. The vendor is required to review legacy systems interface protocol and develop compatible interface solutions to fulfill this requirement. These solutions shall adhere to standard industry practices for application interfaces.

I&I016 M Integration with IDRAS Modules: Integrate different modules with one another. For example, the Audit Module shall be integrated with the Assessment Module and the Return Module shall be integrated with the Refund Module.

I&I017 M GIS Integration: The system shall be able to integrate with Geographic Information System (GIS) to allow capturing in detail the taxpayers location information.

Forms Definition (FRM)FRM001 M Forms Definition Support: The System MUST provide a

Forms Definition Capability that supports the definition form versioning, active dates

and taxpayers’ scope the association of a form with specific Tax

Type the definition of pre-posting and post-

posting events and actions and/or business rules at a form level (used in non-compliance and various case management states)

the definition of sections and cells on a form the definition of fields types for each cell

(e.g., date, currency, etc.)FRM002 M Standard Form Header: The System MUST be able to

provide the ability to support a standard Form Header with common reference information such as: taxpayer identification number, tax type, tax period, date of receipt and a (unique) document identification number (DIN).



Req’t Type(M / D)



FRM003 M Business Rules Support: System MUST provide the ability to support the definition of business rules specifying the mathematical operations and validations of cells within a form.

FRM004 M Association of Form Fields to Financial Transactions: System MUST provide the ability to define the association (mapping) of a cell on a tax form with a specific taxpayer financial transaction type. The result of this association results in the amount entered in the form for the cell being posted to a taxpayer’s current account using the associated transaction code.

FRM005 M Date sensitivity: The Form Definition must be date sensitive such that Forms have names and versions and a validity date range is recorded for each version of a Form and version. Business applications within IDRAS will use the Form and version applicable to the date relevant to the transaction (rather than necessarily the transaction date).

Taxpayer Notices (NTC)NTC001 M Automated Taxpayer Notices: The System MUST

provide the ability to support automated, standardized taxpayer notices for all tax types through business rules and configuration for all core tax functional areas

Notes: Currently notices issued a tax staff are as follow: A letter of notice - for summoning a taxpayer

to a tax office for meeting An act - for determining tax amount, for

sealing properties, for imposing liabilities if taxpayer has hidden taxable income and taxable items other than income

A demand - for purpose of eliminating causes and conditions of violation of tax legislation.

A delinquency notice - to have a taxpayer paid tax amount, which was not paid on time or was imposed indirectly

A payment bill/order - to collect taxes through withholding mechanism through a legal entity, from which a taxpayer is gaining income



Req’t Type(M / D)



A conclusion - for starting criminal enquiry of person, who seriously violated tax legislation, or has hidden great amount of taxable income and avoided tax payment.

An agreement – is made with a taxpayer according to legal requirements to take its property as collateral.

A protocol - is kept while inspecting premises of taxpayer, making inventory, getting on-job photo taking, sealing property, taking collateral and interviewing and questioning a taxpayer within the framework of his/her competence.

NTC002 M Templates for Standard Notices: The System MUST provide templates for standard notices such as those listed.

Notes: Bidders should describe how the addition of new notices is done in their proposed IDRAS solution.

NTC003 M Authorized User Support for Notice Definition: The System MUST allow the authorized users to define new templates and notices using the notice generation

NTC004 M E-mail Support for Notices: The System MUST be able to send notices to taxpayers by e-mail.

NTC005 M Mobile support for Notices: The System MUST be able to send notices to taxpayers by SMS or mobile apps.

NTC006 M Date sensitivity: The Notice Definition must be date sensitive such that Notices have names and versions and a validity date range is recorded for each version of a notice and version. Business applications within IDRAS will use the notice and version applicable to the date relevant to the transaction (rather than necessarily the transaction date).

Reports (RPT)RPT001 M Report Generation, Viewing and Printing: Reports

generated by the System MUST be able to be previewed on a screen prior to printing.

Notes: Reports must be able to be previewed on a screen prior to printing (if the user chooses to print the report)



Req’t Type(M / D)



RPT002 M Standard Reports: The System MUST provide standard reports according to user requirements.

Notes: Standard Reports include but are not limited to the following:- Pending Registration Report- Registry of Taxpayers (individuals and

Corporate- Taxpayer Registration Changes Report- Registry of Inactive Taxpayers- Tax Returns Summary by tax, day and period- Tax Returns Report (for one or more

taxpayers)- Tax Assessed Report- Payments Received and Due Report by tax

Daily Tax Collection Report- Bar Coded Payment Forms- Payment Error Report- Imported Payment Data Report- Chart of Accounts Report- Revenue Accounting Report- Refund Reports- Staff Collection Performance Report- Collection Reports- Multiple Staff Evaluation Report- Stop-Filer Report- Late Payer/Non-Payer Report- Late Filer Report- NIL Returns Report

RPT003 M User-Friendly Report Generator: The System MUST have a user-friendly report generator to allow authorized users to create new printed reports as well as screen queries using the data stored in the System’s database(s).

Notes: Bidders must describe details about the report generator and demonstrate that it is user-friendly. The report generator shall be simple enough to not need any assistance from ICT staff.The System Report Generator will be used to define more reports (in addition to those described in RPT002).



Req’t Type(M / D)



RPT004 D Export of Reports: The System SHOULD be able to export financial reports to the different file formats such as Excel format (.xls), pdf etc.

Notes: The financial reports shall be configurable to meet underlying standards such as IFRS and IPSAS

RPT005 M Sample Reports: Bidders MUST include in their Bids samples of the output reports that each functional area could have.

Notes: TRA will evaluate the clarity and effectiveness of report formats

IDRAS Configuration and Customization (CNC)CNC001 M Software Configuration and Customization

Methodology: To the extent that the proposed IDRAS solution requires customization to accommodate the TRA’s requirements (based on the results of the Bidder’s gap analysis), the Bidder MUST describe its configuration and customization methodology, the tools and/or programming languages that are used and how it will be applied by addressing examples of a functional requirement that probably would require implementation: by (1) out of the box, (2) configuration through data tables, (3) configuration of COTS parameters, (4) customization by software coding.

CNC 002 M Sustainable Solution: The bidder MUST explain how the proposed solution is sustainable after the project ends. This explanation must include the following:Possible future updates to IDRASTRA’s ability toImplement new taxes and non-taxes under IDRASModify IDRAS to support changing relevant laws, decrees, procedures and formsFlexible report generator (add or modify report formats)Change/reconfiguration of workflows by business staff and business rules without need of system codingIn-built reconfigurable change management workflow to manage the transaction or data/information



Req’t Type(M / D)



changes within the system through appropriate levels from initiation to approvals of business users.The tools that will be provided to support IDRAS in the futureProvision of Source codeConfiguration Management of the system based on ITIL ver 3 framework.- Support and Maintenance based on ITIL ver 3

framework. Different environment shall be provided for development, testing, training and production to accommodate ongoing changes in the system

CNC003 M Business rules engine and rule date sensitive: Business Rules configured in the system to the extent practical by non-ICT personnel. Each Bidder should declare in their bid the rules that can be configured and executed ‘out of the box’. Rules must be date sensitive such that (1) the rules and versions and validity date range for the rule and version is recorded and (2) business applications within IDRAS use the date range applicable to the date relevant to the transaction (rather than necessarily the transaction date).

CNC004 M Workflow engine: Workflows should be definable (and re-definable) by a trained TRA administrator (non-ICT personnel), within the configuration suite of the Bidder’s software such that the defined workflow directs the performance of the system at run-time. Each Bidder should declare in their bid the workflows that can be configured using tools ‘out of the box’.

E-Services (ESV)ESV001 M Multiple Channel Registration: Allow taxpayers to

register through multiple channels and provide a single and unique account that is accessible via the internet to support around-the-clock taxpayers’ services. Also, allow online profile update and online application for de-registration.

ESV002 M Deregistration Historical Records: Keep historical records for de-registered taxpayers.



Req’t Type(M / D)



ESV003 M Taxpayer Access: Grant taxpayers access to the TRA Web Portal upon successful authentication.

ESV004 M Online Refund Requests: Accept online refund claims as part of online tax returns filing.

ESV005 M Online Tax Calculator: Provide an online tax calculator.ESV006 M Enrollment of Taxpayers: Allow new taxpayers that do

not yet have a TIN to enroll online as follows:1. Show the requirements to get registered prior to

starting the registration process (e.g., trade number issued by the BRELA, information on the sector of activities, etc.). (The objective is that the taxpayer assembles in advance all the information that they will need to appropriately complete the registration process.)

2. Direct the registration process through logical steps and validate the data at each step. Capture the following information during the registration process:a. Personal data (e.g., name, phone, national

ID, contact information, etc.)b. Organization data (e.g., type of

organization, number of employees, branches, projected first year annual turnover, etc.)

c. Sectors of the taxpayer’s activity (e.g., construction, agriculture, etc.)

3. Complete the registration process securely, followed by a confirmation email and an official document that can be printed by the taxpayer as a proof of online registration

4. Complete the registration process by registering the taxpayer to the tax types he/she is liable for and by making available to him/her the TIN and VAT certificates with the Tax Authority’s electronic signature. The taxpayer can print it at will and query it at any time on the E-Services platform. At this stage, the registration process is considered as completed.

ESV007 M Filing Declarations: Allow registered taxpayers to file tax declarations and supporting documents online as



Req’t Type(M / D)



follows:1. Support manual data-entry of tax declarations

and relevant annexes (supporting documents) as follows:a. Allow taxpayers to file tax declarations

online through logical steps for the various tax lines that have to be completed per tax type.

b. Allow taxpayers to save tax declarations before submitting them, without losing entered data.

c. Support tax declaration annexes (e.g., list of suppliers for VAT) using similar functionality to the tax declaration.

d. Enforce line validations in the tax declaration and the tax annexes on data format (e.g., dates, numbers, etc.) and calculations (e.g., VAT net taxable amount).

e. The system enforces the calculation of all the lines of the returns (e.g. VAT net taxable amount; VAT tax liability, etc.) and guides the taxpayer through the tax return in order to make sure that no errors relating to calculations are submitted online.

2. Support large-volume data upload of tax declarations and tax annexes. For example, when filing the details of Wage Withholding Tax, employers with significant number of employees cannot capture the details of the payroll. However, they could extract the data from their own internal system in an acceptable prescribed format that can be uploaded through the e-services platform. Large-volume data upload is to be supported as follows:a. Describe the prescribed data format of

each tax type that can use the large-volume upload feature.

b. Allow taxpayers to upload tax annexes



Req’t Type(M / D)



using prescribed electronic file.3. Provide confirmation upon completion of filing

(manual entry or large-volume) as follows:a. Add a confirmation step before taxpayers

can submit tax declarations. Once submitted, taxpayers cannot modify tax declarations anymore.

b. Generate a confirmation number that taxpayers can keep as proof of submission of the tax declaration.

c. Allow printing submitted tax declarations for reference.

ESV008 M Electronic Payment: Support the electronic payment tax owed as follows:

1. Allow the taxpayer to electronically pay and settle his/her tax liability through a secured channel. This covers installments (for taxpayers with arrears on a payment plan) and prepayments (against Corporate Income Tax each quarter). Methods of payment can be various like direct bank account wire transfer, Mobile money, ATM, debit or credit card, etc.

2. Has a confirmation step before the taxpayer can submit his/her payment.

3. Generates a confirmation number (unique payment control number) that the taxpayer can keep as a proof of the payment being submitted.

4. IDRAS should automatically reconcile bank statements with payment module and thereafter update Taxpayer account

5. Provides acknowledgement in the form of email and SMS to Taxpayers for tax payments made and received.

ESV009 M Obligation Management: Facilitate the management of taxpayers’ obligations as follows:

1. Provide the following information to taxpayers about filing and payments:a. Statuses of the tax periods for the tax

types (e.g., VAT for February 2012 is due, CIT for 2011 is in progress, Wage



Req’t Type(M / D)



Withholding for February 2012 is submitted, etc.)

b. Payments (e.g., outstanding liability on VAT January 2012, penalties due for CIT in 2011, etc.)

2. Allow taxpayers to query transactions registered under their TIN by providing a list of transactions that are registered under their TIN per tax period, tax type, dates, etc.

3. Allow taxpayers to update basic enrollment information as follows:a. Allow taxpayers to modify personal data,

such as phone number and contact information. However, some fields cannot be modified, such as the trade name of the taxpayer.

b. Keep track of the history of the modifications conducted by the taxpayer to his/her enrollment information.

4. The system contains a page displaying links to reference sites

5. Facilitate the dissemination of information by providing links to various sites, such as the TRA, Ministry of Trade & Commerce, and VAT legislation.

ESV010 M Taxpayer Questions: Allow taxpayers to ask questions and give feedback to the TRA via a secured communication channel, as follows:

1. Allow taxpayers to send messages to the TRA, or vice-versa, securely and confidentially.

2. Keep track of the history of the communications.3. Send common communications to selected

groups of taxpayers (group mailing). For example, send a communication to all VAT taxpayers when a modification is brought to the VAT legislation.

ESV011 M Taxpayer Printing: Allow taxpayers to print at least the following reports:

1. Submitted registration information and registration confirmation number



Req’t Type(M / D)



2. Submitted tax declaration and tax annexes information and tax declaration confirmation number

3. Submitted electronic payment with corresponding details and payment confirmation number

4. List of transactions conducted by the Taxpayer5. Submitted new enrollment information6. Messages sent/received, with their history

ESV012 D Upload/Download of Data: Manage data upload/download to/from the back-office system as follows:

1. Allow the batch management by the TRA of new taxpayers getting registered and requiring a TIN. The information is sent to the back-office system.

2. Allow the batch management by the TRA of submitted tax declarations and tax annexes to upload them into the back-office system (e.g., VAT tax declarations for the month of February 2012). Basic information such as the TIN, date of submission, tax type, and tax period are available with each submitted tax declaration/annex.

3. Allow batch management by the TRA of submitted enrollment modifications, to upload them into the Registration Module of the IDRAS.

4. Accept specific data from the remainder of the IDRAS, to be provided to taxpayers (e.g., TIN certificate is ready for pick up, tax declaration is assessed and accepted).

ESV013 M Active Administration Support: Allow active administration as follows:

1. List all users with their corresponding details (e.g. System ID, username, date of registration, TIN, etc.)

2. Define roles that can be configured and associated with different roles. At a minimum allow the definition and administration of the following roles



Req’t Type(M / D)



a. Tax Authority Registration Role (register taxpayers, block taxpayers, update information, etc.) users/user groups.

b. Tax Authority Communication Role (send messages to taxpayers, answer to their requests, etc.)

c. Tax Authority Batch Management Role (manage the upload of data in batches to the back-office system)

d. Taxpayer Role (file online, etc.)e. Taxpayer Representative Role (third party

accounting firm filing on behalf of the taxpayer)

3. Register and manage—via a webpage; not through programming or other type of technical intervention—users and user roles. A user can have multiple roles.

4. Allow users to modify some basic registration information and to change the password.

5. Allow configuration of the underlying reference tables by non-technical persons (via a webpage accessible to authorized users having the proper role), such as tax type, tax period, taxpayer type, registration type, and roles.

6. Allow non-technical persons to add tax types, tax periods, etc.

ESV014 M Additional Features: Provide the following other features and capabilities:

1. Has a dynamic online help to support all users according to their specific role (both taxpayer and Tax Authority users)

2. Contain a service request feature allowing the taxpayer to make requests concerning the management of his/her tax accounts/obligations to the Tax Authority. Examples of requests are deregistration to a tax type, request for refund, etc. Basic information can be captured with each request, along with a status indicating if the request if pending, rejected, approved, etc.

3. Can be implemented as part of an overall



Req’t Type(M / D)



government portal. Note that for implementation purposes, this is not required, but could become a requirements in the future as the government portal is deployed.

4. Provide online video training for both taxpayers and staff on the use of the system and relevant laws, regulation and procedures

5. Provide Instant Multimedia (voice, messages and video) capabilities to allow interaction with taxpayers by technical staff for support and clarifications on tax or systems issues. The collaborations should be able to be consolidated and trailed through a unique identifier independent of the channel used for communication such as SMS, email, mobile app or web portal

6. The system shall provide for knowledge management system that will capture data, facts and information through collaborations, experience, knowledge and through documentation and compilation present to system users internally and externally depending on level of access

ESV015 M Online Security: Secure all underlying functional and technical processes as follows:

1. Secure all user access as follows:a. Implement a distinct security mechanism:

i. for taxpayers getting enrolled for the first time and hence who are not yet in the database,

ii. taxpayers already enrolled and registered in the system

b. Implement a specific security mechanism for third party accounting firm filing on behalf of taxpayers, especially if different users of the same firm file on behalf of different taxpayers (i.e., segregation of data and access to data).

c. Provide a secured login page for the various roles.



Req’t Type(M / D)



d. Implement a “Forgot Password” functionality using users’ registered email addresses.

2. Implement a secure architecture and ensure a highly robust and secured electronic services system as follows:a. The system is separate from the back-

office and implement as a stand-alone (i.e., the e-services platform has its own database separate from the back-office’s database). Changing the back-office’s system or data model does not necessarily entail changing the e-services platform.

b. Prevent access to absolutely all users’ passwords by any role. Encrypt absolutely all passwords at the database level.

ESV016 M Third Party Access: Allow third party to manage tax obligations (return, payment, etc.) on behalf of taxpayers (e.g. accounting firm filing on behalf of a large taxpayer).

1. Allow all requirements, except 0, to be conducted by a third party that is not the taxpayer but its representative.

2. Allow the identification of the taxpayers that have authorized a third party to file on their behalf.

ESV017 M Mobile Device Support: Allow having the same set of functionality described above on mobile devices such as electronic pads and smart phones with mobile app. It includes as well the capacity of mobile payment method.

Administration, Reporting, and Information (ARI)ARI001 M Admin Features: Allow the creation of New User

Access, User Access Review, and User Termination Process.

ARI002 M Recording Information: Record information coming from audit results, annual risk-based systems, additional assessment processes, and other sources within the TRA.



Req’t Type(M / D)



ARI003 M Transaction ID Numbers: Permanently record transactions’ ID numbers, even if transactions are cancelled or deleted. That is, if the record is deleted, the Transaction ID number shall remain in the database.

ARI004 M Validate Data: Validate captured data and ensure that it is complete.

ARI005 M Local Printing: Provide for local printing of documents at headquarters and remote locations.

ARI006 M Recording Notes: Provide the capability for recording notes and/or narratives about actions taken for each taxpayer.

ARI007 M Viewing & Printing Profiles: Provide the capability for viewing and printing taxpayer profile information.

ARI008 M Inquiries: Provide the capability to inquire on demographic and summary taxpayer data by all of the following parameters:

1. Tax liability (declarations)2. City and/or county3. Business type4. Tax type5. Account status6. Exceptional account entries

ARI009 M Search by DLN: Search for documents by a Document Locator Number (DLN).

ARI010 M Batch Support: The system shall provide the ability to enter data from applications, returns, reports, schedules, and payments, in a batch mode, using data TRA received from external sources. The ability to capture data in batch mode does not compromise the integrity of the system in any way. Validate data according to the same rules applied to online data capture.

ARI011 M Sector Reports: Generate reports that help calculate sectoral indices and indicators.

ARI012 M User Authorization - Waivers: Recognize those users authorized to waive penalties.

ARI013 M Record Waived Penalties: Record the user waiving the penalty and the reason for the waiving it.



Req’t Type(M / D)



ARI014 M Review of Penalty Waivers: Using TRA business rules for supervisors, review certain penalty waivers prior to the waiver taking affect.

ARI015 M Approval of Transactions: Using TRA business rules for supervisors, approve transactions and data entered by users prior to posting the transactions.

ARI016 M Restricted Viewing – Payments: Allow specified users to view only payment transactions for a given taxpayer and reporting period.

ARI017 M Restricted Viewing – Refunds: Allow specified users to view only refund transactions for a given taxpayer, tax type, and reporting period.

ARI018 M Viewing All Transactions – Tax Type: Allow specified users to view all transactions posted for a given taxpayer and tax type.

ARI019 M Viewing All Transactions – Tax Period: Allow specified users to view all transactions posted for a given taxpayer, tax type, and reporting period.

ARI020 M View Summary Transactions: Allow specified users to view a summary of the transactions posted for a given taxpayer and tax type.

ARI021 M Lock Down Collection Transactions: Lock down collection transactions made on periods to which their accounting periods have been finalized and closed.

ARI022 M Lock down approved transactions: Lock down approved transactions to prevent from unauthorized editing. If any change is required on such transactions, follow in-built change management process workflow to ensure that the change is appropriately approved and documented.

ARI023 M Lock down Closed Accounting Period: Lock down a closed accounting period to prevent from unauthorized changes made on periods to which their accounting periods have been finalized and closed. Prevent editing any information on a closed financial period.

ARI024 M Audit Trails: Provide an audit trail of every user transaction that includes the user and administrators performing the transaction and the date and time the transaction was performed.



Req’t Type(M / D)



ARI025 M Revenue Accounting Journal Items: Provide the capability to automatically translate financial transactions that were posted to a taxpayers account into Revenue Accounting journal items that are then posted to Revenue Accounting summaries.

ARI026 M Notification of Taxpayer Correspondence: Provide the capability to notify the appropriate user when a correspondence has been received and identified as being relevant to a specific transaction and taxpayer.

ARI027 M Export of Information: Export information directly to Word, Excel, Access or Text or any other agreed open standard file formats.

ARI028 M Posting of Accounts Receivable: Post Accounts Receivable in a standard format for all taxes. Automatically generate standardized recurring follow-up notices for all taxes on a standardized schedule, as determined by TRA.

ARI029 M Integrated Statement of Taxpayer Account: All payments made and due, including Accounts Receivable, will be maintained and displayed in one data table. Any of the authorized TRA users will be able to see a complete Statement of Account on any taxpayer at any time.

ARI030 M Logging of Activities: Generate log activities on administrators’ activities so that periodic reviews can be performed by internal auditors.

ARI031 M Reference to Physical Files: Reference taxpayers’ physical files.

ARI032 M Timely Updating: Update information in a timely manner.

ARI033 M Back-Office Functionality: Provide full functionality for back-office operations.

ARI034 M Centralized Processing: Handle centralized processing of taxpayer transactions.

ARI035 M Compliance Monitoring/Enforcement: Provide adequate support for compliance monitoring and enforcement configurable to approved compliance strategy based on key criteria such as automatically track due dates, issue reminders, calculate interest, and compile reports.



Req’t Type(M / D)



ARI036 M Audit Team Statistics: Provide statistics for team performance and overall audit progress.

ARI037 M Taxpayer Single Account: Provide holistic view of taxpayer single account for each registered taxpayer for them view and collaborate all issues and transactions dealing with tax matters for all relevant tax functionality deployed in the system such as viewing status of the request, generate reports etc.

ARI038 M Record All Transactions: Record all transactions (e.g. assessment, payment, refund) into taxpayers’ accounts.

ARI039 M Revenue Income Report: Report on revenue income and monitoring procedures such as debt management.

ARI040 M Accounting Support: Support accrual-based accounting: Revenue Control Account, Taxpayer Control Account, and General Ledger.

ARI041 M User Access Control: Support user access and privilege rights administration.

ARI042 M Parameter Support: Maintain various parameters including all of the following:

1. Tax Types2. Tax Rates3. Salary Ranges4. Targets5. Banks and Branches6. Region’s Parameters7. Enforcement Parameters8. Currency Denominators9. Taxpayer Groups10. GFS Codes11. Work days and Public Holidays12. Exchange Rates13. Interest Rates14. General Ledger Posting Accounts15. Initialize Reports16. Work hours

Date sensitivity: Parameters must be date sensitive such that (1) the validity date range for the parameter is recorded and (2) business applications within IDRAS use the date range applicable to the date relevant to



Req’t Type(M / D)



the transaction (rather than necessarily the transaction date).

ARI043 M Search for Taxpayers: Intelligent search for existing taxpayers by all of the following options:

1. Search for names that begin with the same letter supplied by user input

2. Perform an exact name match (search by full, first, middle, or last name)

3. Perform a partial name match4. Perform a phonetic name match5. Search by address, post code, both full and

partial6. Search by TIN7. Search by account/charter number

ARI044 M Periodic Reports: Generate various statutory periodic reports including float revenues, tax revenues, and tax arrears.

ARI045 M Chart of Accounts: Maintain chart of accounts to identify collection items and structure of posting accounts.

ARI046 M Executive Summaries: Prepare Revenue Executive Summary.

ARI047 M Management Information Reports: Generate Management Information reports.

ARI048 M Revenue Collection Statements: Prepare Country Tax Revenue Collection Statements.

ARI049 M Reporting Frequency: Determine, through the use of TRA business rules, the proper reporting frequency for each tax the taxpayer is responsible for.

ARI050 M Ad-hoc Reporting: Support ad-hoc reporting.ARI051 M Period Beginning and Ending Dates: For taxpayers

reporting on four-week periods, maintain a taxpayer supplied schedule of the beginning and ending dates for each four-week period.

ARI052 M Irregular Reporting Periods: Support taxpayers with irregular reporting requirements (e.g., seasonal businesses).

ARI053 M History of Reporting Frequencies: Maintain a history of the reporting frequencies, by tax, for each taxpayer.



Req’t Type(M / D)



This history includes the applicable dates for which the reporting frequency was in effect

ARI054 M Daily Reports 1: Generate daily reports to ensure that Accounts Receivables are in balance.

ARI055 M Daily Reports 2: Generate daily reports to ensure that external data received by the tax system was recorded as transactions within the system.

ARI056 M Out of Balance Reports: Generate daily reports that identify out-of-balance conditions.

ARI057 M Statistics Printing: Allow users to view and print a summary of their own production statistics.

ARI058 M Subordinates Production Statistics Reports: Allow supervisors to view and print a summary of their subordinates’ production statistics.

ARI059 M Arrears Periodic Reports: Generate various periodic reports including tax arrears and float revenues.

ARI060 M User Access Permission Reports: Generate reports on all access permissions per user.

ARI061 M Daily and Monthly Collection Reports: Generate aggregated daily and monthly collection reports and aggregate these monthly reports into an annual report.

ARI062 M Bank Reconciliation Reports: Reconcile with bank reports.

ARI063 M Customized Reports: Generate customized reports that facilitate timely preparation of daily, monthly and quarterly reports for the management and board.

ARI064 M Other Reconciliation Reports: Generate monthly reports that reconcile with other reports from different resources.

ARI065 M Detailed Reconciliation Reports: Generate detailed reports that reconcile with summarized collection reports, even if the collection reports are made by a tax region on behalf of other regions.

ARI066 M Reliable Taxpayers’ Account Statements: Generate reliable taxpayers’ Statement of Account.

ARI067 M Specific Reports: Generate all of the following reports:1. Non- and late filers, and non-, late-, short-

payers2. Tax Position for every taxpayer



Req’t Type(M / D)



3. Analysis reports4. Taxpayer trends of payment for all taxes5. Compliance based reports

ARI068 M Up-to-Date Information: Provide an up-to-date information of taxpayers’ accounts and allow all of the following operations:

1. View all transactions2. Sort information3. Filter information4. View information by tax type5. Print Tax Positions on demand6. Revenue accounting

ARI069 M Generate Reports: Generate all of the following reports:

1. Collection reports (daily, weekly, monthly, quarterly, yearly, or any period)

2. Executive Summary3. Cash Accounting/Cash Book4. Revenue Control Account5. Taxpayer Control Account6. Special reports on demand7. Comparison of actual collection versus targets8. Overdue debts/tax arrears9. Standard report includes daily

ARI070 M Link Merged Businesses: Provide the capability to link businesses that have merged to form a new entity.

ARI071 M Revenue Office Identification: Automatically identify and assign the proper revenue office to each taxpayer based on location (i.e., area, county, district, and region).

ARI072 M Partner Links: Provide the capability to link Limited Liability Companies (LLC) with the corporations and/or individuals who are partners in the LLC.

ARI073 M Monitoring Taxpayer Categories: Provide a mechanism to help monitoring taxpayers who are eligible to graduate from one category to another.

ARI074 M Tracking of Rules: Provide the ability to track rules by tax period and tax type.

ARI075 M Links to Related Taxpayers: Provide the capability to link taxpayers related in a parent and subsidiary



Req’t Type(M / D)



relationship.ARI076 M Link to Partners in Partnerships: Provide the capability

to link partnerships with individuals participating in the partnership.

ARI077 M Tracking Business Schedule: For taxpayers reporting irregularly, maintain a schedule of when the taxpayer will be conducting business.

ARI078 M Maintain Tax Position: Provide a correct tax position of each taxpayer, including tax arrears.

ARI079 M Provide a Taxpayer Account Statement: Provide a taxpayer account statement for each taxpayer that shows taxpayer position including tax arrears.

ARI080 M Electronic Capture: the ability to capture electronically taxpayers’ returns/accounts other than VAT returns.

ARI081 M Waiving of Penalties & Interest: Provide the capability for authorized users to waive penalties and interests assessed against a taxpayer’s account and generate the proper accounting transactions.

ARI082 M Track Actions of Users & Supervisors: Allow and generate reports (audit trail) for system administrators to track all actions of users and supervisors (e.g., additions, deletions, modifications, etc.). The proposed solution shall also record the time/date of the transactions.

ARI083 M Monitor Monthly Funds Transfers: Monitor monthly transfers from commissioners’ revenue accounts at commercial banks and the BoT to Paymaster General account at the BoT.

ARI084 M Enhanced Accounting System: Provide an enhanced accounting system that can perform data capture, analysis, reconciliation, monitoring of revenue transfers, as well as other related processes in an automated fashion in order to improve overall accounting for government revenue.

ARI085 M Maintain Credible Positions: Maintain individual taxpayer’s accounts and at any time provide credible taxpayer account position.

ARI086 M Automatic Penalty Calculation: Automatically calculate penalties on overdue taxes and update taxpayer accounts.



Req’t Type(M / D)



ARI087 M Update Ledgers: Update accounting systems and taxpayers ledger in real-time.

ARI088 M Central Merging of Accounting Information: Centrally manage revenue accounting for all tax types.

ARI089 M Revenue Collection Reconciliation: Reconcile revenue collection.

ARI090 M Consistent Information: Provide consistent information across channels (i.e., mobile and web applications).

ARI091 M The system shall have a Data Warehouse / Business Intelligence capability to enable complex reporting, risk assessment, audit selection, econometric modelling and impact analyses and other such capabilities.

Other IDRAS General Requirements (OTH)OTH001 M User-Friendly Screens: Implement user-friendly

screens that are easy to navigate through. Ensure users are able to intuitively reach any desired screen.

OTH002 M Consistent Screen Profile Information: Provide consistent profile information on each screen.

OTH003 M TIN Display on Screens: Display taxpayers’ ID number /TIN and name on each screen.

OTH004 M GUI Interface: Collect data from users via GUIs, including payment transactions and transactions adjustments.

OTH005 M Resolving Return Validation Errors: Provide the capability for users to resolve return validation errors, through the use of a GUI, by correcting data elements captured incorrectly.

OTH006 M Return Review via GUI: Allow users to review via GUIs returns containing certain data elements that exceed tolerance levels.

OTH007 M Disaster Recovery Plan: Adhere to a disaster recovery plan.

OTH008 M Backup: Backup data.OTH009 M Web Application for Users: The system’s web

application shall enable the user to interact with the customer service, or the help desk, via the web.

OTH010 M Correspondence Types: Offer a comprehensive set of



Req’t Type(M / D)



correspondence types for communications with taxpayers, such as tax returns and remittance documents. All correspondences in connection with tax returns are stored in one consolidated view and can be restored as and when required. Correspondences may be of any format such as written correspondences, e-mail, telephone, SMS, fax, EDI, or other paper documents.

OTH011 M Property Rate Module: Implement a Property Rate Module that supports Property Rate through registration of property, billing to property owners, and collection of revenue.

OTH012 M Property Rate Penalties: Implement a Property Rate Module that supports enforcement of defaulters by calculating the penalty, loading to property account, and providing collection report to the Municipal Councils.

OTH013 M Scanned Documents and Photos: Implement a Property Rate Module that stores scanned and imported property photos up to one million digital and scanned photos, where each property will have up to four photos.

OTH014 M Single View of a Taxpayer: Provide the ability to have a single view of a taxpayer, whereby all information of a taxpayer can be easily accessed.



2 IFB Section VI Sub-Section C: Technical SpecificationsReq’t Type

(M / D)Description of Requirement Bidder’s response

Non-Functional Technical Requirements – General Technical RequirementsGTR001 M Language Support: End user interface for IDRAS must

support English. End user interface includes menus, data capture screens, data display screens, queries, reports, messages and manuals.

GTR002 M Dates: All information technologies MUST properly display, calculate, and transmit date data, including, but not restricted to 21st-Century date data.

GTR003 M Electrical Power: All active (powered) equipment must operate on 220v +/- 20v, 50Hz +/- 2Hz. All active equipment must include power plugs standard in Tanzania. The following electrical standards apply for hardware equipment in Tanzania: Primary socket types British BS-1363

GTR004 M Environmental: Unless otherwise specified, all equipment must operate in environments of 10-30 degrees centigrade, 20-80 percent relative humidity, and 0-40 grams per cubic meter of dust.

GTR005 M Safety:1. Unless otherwise specified, all equipment must

operate at noise levels no greater than 55 decibels.

2. All electronic equipment that emits electromagnetic energy must be certified as meeting EN 55022 and EN 50082-1 or equivalent, emission standards.

Non-Functional Technical Requirements – ArchitectureGTR006 M Fully web-based and accessed using a standard

internet browser; no other application software module is installed on the workstations.

GTR007 M Provide for mobile apps that might be used at least for notification, payment or view taxpayer’s position.

GTR008 M Portable, lightweight, and cross-platform.GTR009 M Based on the 3-tier architecture to allow

implementation of application, database and storage both at the primary site and disaster recovery sites.

GTR010 M The system shall be implemented on Disaster Recovery Site in addition to the primary site. Cold,



Req’t Type(M / D)

Description of Requirement Bidder’s response

warm and hot configurations required, using best practice, relevant Business Impact Analysis and Disaster Recovery Plan.

GTR011 M A complete turn-key solution including required software, hardware, and services (i.e., design, implementation, testing, training, and integration with other systems mentioned in this document)

System Support and MaintenanceGTR013 M The vendor shall specify his capability regarding

services such as maintenance and support for local IT equipment. Any limitation regarding the availability of such services around the world shall also be specified.

GTR014 M The vendor shall provide a full support for the system, during the deployment and ‘go-live’ phases and during the warranty / support and maintenance phase (post warranty)

GTR015 M The vendor shall provide the knowledge transfer at advanced level on system customization (development), installation, configuration and maintenance to allow first and second level support to be done with IT department in the Authority

GTR016 M Source code: It is the preference of the Purchaser that the vendor shall handover the final approved version of the source code of the system (which includes all the changes made during customization) to TRA as part of the software configuration database to enable smooth support and maintenance of the system. During warranty and post-warranty period will continue updating the source code to the latest configuration available in the system. The Vendor may propose an alternative approach that TRA will assess for acceptability at its sole discretion.

GTR017 M Costings based on TCO: If and when submitting a 2nd stage bid, the Bidder shall provide the breakdown of the costing on the basis of total cost of ownership as for initial system deployment investment to the cost of the system for up to subsequent six years of operation for the support and maintenance of all the components involved in the proper running of the system.



Req’t Type(M / D)


Maintenance and Equipment SupportGTR018a M Maintenance and support for local IT equipment: The

vendor shall specify his capability regarding services such as maintenance and support for local IT equipment. Any limitation regarding the availability of such services around the world shall also be specified.

GTR018b M The Vendor shall provide a full support for the system, during the deployment and ‘go-live’ phases and during the warranty / support and maintenance phase. (post warranty).

GTR018c M Knowledge transfer: The vendor shall provide the knowledge transfer at advanced level on system customization (development), installation, configuration and maintenance to allow first and second level support to be done with IT department in the Authority

SecurityGTR019a M Implement Identity Access Management that

centralizes user managementGTR019b M User passwords: Provide a universal standard for

password setting requirements across the board to ensure they are not easy to crack. (i.e., standard requirements for password length, content, and age).

GTR019c M Protections against security threats and vulnerabilities: At all layers of OSI model, the system shall implement a centralized detection, prevention, correction and audit of any security threats and vulnerabilities with a GUI that shall provide a dashboard and detail presentation of overall health of the system and underlying business process performance based on configurable various targets such KPIs and CSFs.

GTR020a M Application Interaction with Underlying Host: This item lists requirements governing how the application interacts with its underlying host environment:

1. No bypass of security controls: The application must prevent users from bypassing any application security controls in an attempt to directly access any underlying operating system, subsystem, or middleware component (i.e., PKI



Req’t Type(M / D)


component, DBMS, Web server, etc.)2. The application must be capable of being

configured—preferably through automatic configuration—for secure operation in its intended environment(s), and must report any deficiencies that preclude its complete configuration

3. The application’s underlying host—including operating system, subsystems, and middleware—must be configured in compliance with TRA’s ICT Security policy

GTR021 M Separation of Duties: The system must implement the principle of “separation of duties” whereby different functions are performed by different roles so as to avoid single point of compromise. Besides application functional roles, the system shall accommodate roles for system administrators, application administrators, database administrators, security administrators and auditors who have responsibilities as following:

1. Application administrators are responsible for user management, access control and application operations functions management.

2. System administrators are responsible for the system maintenance i.e. managing system performance, capacity, services and backup management.

3. Database administrators are responsible for database management.

4. Security administrators are responsible for monitoring, reviewing logs and review of user rights and activities, plus the implementation and review of all system security controls.

5. Auditors are responsible for monitoring and review of user rights and activities.

GTR022 M Cryptography: Cryptography must be used to protect sensitive information which includes data in storage and transit. Cryptography deployed for the purpose of protecting the Applications and TRA information must comply with the following requirements;

1. Data protection – The system shall support the following FIPS-approved symmetric encryption



Req’t Type(M / D)


algorithms: Advanced Encryption Standard (AES) – FIPS 197, Triple Data Encryption Standard (3DES) – FIPS 46-3 and Escrowed Encryption Standard – FIPS 185.

2. Data Authentication – The system shall be capable of performing data authentication using the Computer Data Authentication – Message Authentication Code (BAC) – FIPS 113 and HBAC – Keyed-Hash Message Authentication Code (HBAC) – FIPS 198 based on FIPS-approved symmetric encryption algorithms. The system shall be capable of adopting future data authentication methods using Block Cipher Modes of Operation on AES.

3. Digital Signature – The system shall support the FIPS-approved Digital Signature Standard (DSS) – FIPS 186-2 which addresses three FIPS-approved algorithms for generating and verifying digital signatures: Digital Signature Algorithm (DSA), RSA, and Elliptic Curve DSA (ECDSA).

4. Security of Cryptographic Modules – Cryptographic modules provided by the system shall be validated under the Cryptographic Module Validation to conform to FIPS 140-2, with at least level 2.

GTR023 M Identification and Authentication (I&A): This item lists the security requirements defining how server application processes should perform—or interface with external I&A facilities that perform on their behalf—identification and authentication of users, client processes, and other servers.

1. Centralized user management: The application must be able to integrate with Oracle Identity and Access Management system for enabling centralized user management.

2. User authentication: Application must ensure that users have been authenticated before granting them access to sensitive resources or trusted roles.

3. Process authentication: Applications must authenticate any process, program, or other



Req’t Type(M / D)


active entity or object that interacts with the application on a user’s behalf.

GTR024 M I&A Mechanisms (1): I&A performed before granting access to the application must use a non-forgeable, non replayable mechanism that supports both one-way and two-way authentication.

GTR025 M I&A Mechanisms (2): Application I&A should use one or more of the following technologies instead of or in addition to User ID/static password: (1) single sign-on (SSO), (2) PKI, (3) hardware token, (4) biometrics, (5) dynamic (one-time) passwords.

GTR026 M Unsuccessful I&A attempts: The I&A mechanism must enable an application administrator to configure the maximum number of login attempts (configurable per user or per role) allowed within a given time period.

GTR026a M I&A lockout period: The application I&A mechanism must enable application administrators to configure the duration of the “lockout” period during which a user (or role) who exceeds the number of allowable login attempts will be prevented from making another I&A attempt.

GTR027 M I&A using biometrics: The application I&A mechanism shall use biometrics in accordance with TRA ICT policy. The application performs user I&A using biometrics

GTR028 M Strong passwords : The application’s password management mechanism must prevent users from choosing passwords that do not comply with the password construction rules defined in TRA’s ICT Security Policy, i.e.:

1. The password must be case-sensitive;2. The password must contain at least eight

characters;3. The password must not contain spaces or a “+”;4. The password must contain at least one [1]

uppercase letter, one [1] lowercase letter, and one [1] non-alphanumeric (“special”) character. In addition, the password should not constitute or contain:

(1) a word found in the dictionary of a major human language (e.g., English, French, German, Spanish,



Req’t Type(M / D)


(2) a text string commonly known to be used as a password (e.g., “password”, “administrator”, “nobody”),(3) a string(s) of repeating characters, e.g., “ee”, designated by the administrator as prohibited,(4) the user’s name or user ID

The application performs user I&A based on User ID and static password

GTR029 M Password changes by user: The application’s password management mechanism must:1. Enable the application administrator to assign

passwords to enable users first login ;2. Require the user to change his/her application

administrator-assigned password after the first login using that password;

3. Enable the user to change his/her own password on demand thereafter with no restrictions as to frequency of changes allowed,

4. Require that the new password selected by the user contain at least four [4] new characters. The application performs user I&A based on User ID and static password

GTR030 M Password changes by application administrator: The application must ensure that only the application administrator is allowed to change passwords other than his/her own. The application performs user I&A based on User ID and static password.

GTR031 M New password after expiration: The application must not authenticate a user whose password has expired until the user changes the expired password. The application performs user I&A based on User ID and static password.

GTR032 M Non-reuse of expired password: The application’s password management mechanism must be able to recognize a user’s attempt to choose one of his/her previous, now expired password(s), and must prevent the user from choosing such a password. The new password chosen by the user must contain at least four (4) characters not found in the user’s expired password. The administrator should be allowed to



Req’t Type(M / D)


specify the number of expired previous passwords that must not be chosen by a user. The application performs user I&A based on User ID and password.

GTR033 M Password expiration: The application’s password management mechanism must enable the application administrator to set an expiration threshold for every password associated with every User ID. The application performs user I&A based on User ID and static password.

GTR034 M Confidentiality of transmitted I&A data: The application must encrypt user passwords and any other sensitive I&A data before transmission over a network, and the strength of that encryption must be at least equivalent to the assurance and robustness of encryption used to protect the information that will be accessed after the user is authenticated. Application transmits sensitive I&A data (e.g., passwords, biometric data, and certificates) over a network.

GTR035 M The privileged accounts management shall be implemented providing capabilities such as password vault, check-in and checkout (e.g. one-time password), audit logging, policy control and account lifecycle management.

GTR036 M Authorization and Session Control: This item lists requirements governing how applications authorize users and external processes access to application resources, and to data handled by the application, and also how applications perform session control (i.e., de authorization and reauthorization of users). An application may invoke an external authorization mechanism, such as a Role Based Access Control implementation, via trustworthy calls.

1. User authorization: The application must ensure that users have been authorized to perform the functions they attempt to perform or access the resources (including data) they attempt to access, and that those authorizations explicitly allow them to perform those functions or access those resources/data in the ways the users attempt to do so.

2. Authorization management tool: The application



Req’t Type(M / D)


must provide a tool for creating and modifying authorization information (e.g., ACLs, active accounts). For server applications, the tool must be able to create or modify this information without having to restart the application. The application must ensure that the tool can be accessed only by an authorized user.

3. PBAC or RBAC: The application must implement Policy-Based Access Control (PBAC) or Role-Based Access Control (RBAC) for authorizing user privileges in conjunction with its discretionary and mandatory data access control schemes.

4. Group privileges: The application must enable the creation of different user groups, and the assignment of different privileges to each group. The application is an electronic records management application.

GTR037 M Access Control: This item lists requirements governing how applications control access by users and external processes to application resources, and to data handled by the application. These requirements pertain both to applications that interact with the underlying host or surrounding infrastructure to provide access control, and to applications that perform their own access control in some form (e.g., using embedded digital rights management mechanisms).

1. Unauthorized access: The access controls used by the application must prevent unauthorized users from reading or manipulating data, application resources, devices, etc. that are created, manipulated, or used by the application.

2. Unauthorized actions: The application must prevent authorized users from using the application to perform any function that they are not authorized to perform.

3. No unauthorized access to cryptographic materials: The application must ensure that its access controls prevent unauthenticated, unauthorized users from gaining access to any



Req’t Type(M / D)


cryptographic material used by the application, including keys, trust points, and certificates. The application must also ensure that access to private keys is strictly limited to users authorized to access those keys. The application uses cryptography

4. Configurable access controls: The access control mechanism used by the application must provide an interface or tool to enable the application administrator to define the access control characteristics of each data object and resource to be controlled with relation to the individual user, group, role, etc. that is allowed to access it.

5. The system shall have readily available reports that can enable supervisors (process owners) or internal auditors to review current user access rights to the application.

GTR038 M Confidentiality: Confidentiality is the assurance of non-disclosure of information/ data to unauthorized entities. This item lists requirements governing the methods used by applications to ensure the confidentiality of the data they manipulate, store, or transmit. These requirements pertain to applications which augment, at the application layer—either through embedded functionality or by secure calls to approved external encryption mechanisms—those confidentiality controls provided at lower (e.g., network, data link) layers such as Virtual Private Networks and link encryption.

1. Encryption API: There must be an API that enables the application to invoke an encryption capability to selectively encrypt data and files.

2. Nondisclosure of clear text data: The application must ensure that sensitive clear text data are not disclosed before they are encrypted.

3. Confidentiality of user identities: The application must not: (1) Reveal to external users or processes the identity of any user associated with any application session; (2) Include within or append onto a data object an indicator of the



Req’t Type(M / D)


identity of the data’s creator or sender; (3) Invoke any external process that includes within or appends onto a data object any indicator of the identity of the data’s creator or sender. There is an operational requirement for the Identities of users to be protected from disclosure.

4. Protection of sensitive Web transactions: The application should use SSL or TLS (SSL Version 3.0 or TLS Version 1.0) with approved cryptographic and key management algorithms to implement seamless end-to-end session encryption of all network-based Web transactions in which sensitive information is transmitted. The application is a Web application.

GTR039 M Integrity: Integrity, in terms of data security, is the assurance that information/ data can only be accessed and modified by authorized entities and can only modified in an authorized way. This item lists requirements governing how applications ensure the integrity of the data they manipulate, store, or transmit, as well as the Integrity of their own data, executables, and runtime resources. These requirements pertain to applications in environments in which the application augments at the application layer—through embedded functionality or secure calls to approved external integrity mechanisms (e.g., PKI-based cryptographic hash or digital signature mechanisms)—any integrity controls provided by the application’s underlying host operating system and surrounding security infrastructure1. Integrity of transmitted data: The application

must use a certified FIPS 140-1 or TRA -approved technology (as appropriate for the application’s Business Impact Category and robustness level) to implement a hash (e.g., Secure Hash Algorithm One [SHA-1]), checksum, or digital signature (e.g., DSS) of the data before transmission. The application transmits data over a high level of concern network.



Req’t Type(M / D)


2. Validate Input and output: User input and output to and from the system is the route for malicious payloads into or out of the system. All user input and user output should be checked to ensure it is both appropriate and expected

3. Input validation: The application must validate all data input by users or external processes, and must reject all input for which one or more of the following is true: (1) not formatted as expected; (2) contains incorrect syntax; (3) not a valid data string; (4) contains parameters or characters with invalid values; (5) falls outside the expected bounds (e.g., length, range); (6) contains a numeric value that would cause a routine or calculation in the application to divide any number by zero; (7) contains any parameters the source of which cannot be validated by the user’s session token; (8) can induce a buffer overflow; (9) contains HTML; (10) contains special characters, meta code, or meta characters that have not been encoded (if encoding is allowed); (11) contains direct SQL queries; (12) contains any other type of unexpected content or invalid parameters; (13) contains a truncated pathname reference.

GTR040 M Availability: Availability is the assurance that data/ system is accessible and usable when needed by authorized entities. This item lists requirements governing how applications ensure the availability of the data they manipulate, store, or transmit, as well as the availability of their own data, executable, and runtime resources. These requirements pertain to applications in environments in which the independent availability controls provided by the application’s underlying host and surrounding security infrastructure are not considered adequate to protect the application and/or its data, and thus must be augmented by the application itself at the application layer.1. Application correctness guarantees data

availability: The application code must not



Req’t Type(M / D)


contain errors, bugs, or vulnerabilities that could cause any executing process within the application to inadvertently delete or overwrite data, to incorrectly assign/change access permissions to that data, or to otherwise impinge on the data’s availability.

2. Adjust to unresponsive output: The application should be configured with a threshold whereby, if the application attempts to return data to a requesting client, but that client—or its network connection—does not respond after a certain period, the application will release its session locks and stop waiting for a client response. The application is a server application

3. Error/exception handling: The application must contain an error/exception handling capability that ensures that the application executable files and data will not become vulnerable in case of an application processing failure. The application must not rely on its programming language alone to perform error/exception handling. The application is a server application

4. Configurable error/exception handling: The application’s error handling mechanism must be configurable to allow the administrator to choose the way in which the application will respond to a detected error. At a minimum the options for error response should include: (1) Entire application terminates, (2) Erroneous process terminates, (3) Erroneous process and other selected processes terminate. In addition, the administrator should be able to choose one or more actions to be triggered by an error-related termination. These choices should include: (1) Termination triggers user notification, (2) Termination triggers administrator notification, and (3) Termination triggers automatic check-point restart.

GTR041 M Non-Repudiation: Non-Repudiation refers to the ability to ensure that a party to a contract or a communication cannot deny performing an action by



Req’t Type(M / D)


providing undeniable proofs to both parties. This item lists requirements governing how applications ensure non-repudiation by users of activities they perform, processes they spawn, and data they create, modify, delete, or transmit while using the application. These requirements are pertinent for applications whose users must be held accountable for individual transactions; particularly those transactions performed using different application components over a network (e.g., email user agent and email server, browser and Web server, directory user agent and directory server, etc.) for which traditional auditing and logging would not be sufficient to maintain and easily track user accountability, as well as those applications for which non-repudiation is a legal requirement.1. Proof of transmission: The application must

invoke a TRA approved digital signature technology (e.g., SHA-1, DSA, RSA) appropriate to the application’s Business Impact Category to enable the creator/sender to digitally sign the data/keys the application is used to create or transmit over the network. The application requires non-repudiation by the creator or sender of data or cryptokeys transmitted via the application.

2. Proof of delivery: The application must invoke a TRA approved digital signature technology (e.g., DSS) appropriate to the application’s Business Impact Category to enable recipient to sign data received via the application. The application requires non-repudiation by the recipient of data received via the application.

3. Digital signature validation: The application must invoke a digital signature validation facility to validate all digital signatures applied to data or cryptokeys it receives over the network or retrieves from a database or directory. The system should be able to use PKI infrastructure to manage digital signature for users.

GTR042 M Accountability: Accountability is the property of a system (including all of its system resources) that



Req’t Type(M / D)


ensures that the actions of a system entity may be traced uniquely to that entity, which can be held responsible for its actions. This list lists requirements governing how applications ensure the accountability of users for the activities they perform and the application processes they spawn while using the application. These requirements pertain to applications for which user accountability via logging of application specific events/transactions is required in addition to auditing at the operating system, Web server, and DBMS levels.1. Audit/event logging mechanism: The application

must log all security-relevant events (configured by the security administrator) to its own secure audit/event log, or transmit these data securely to an external audit collection facility. In high –robustness applications, this audit mechanism must provide continuous, automated online auditing.

2. Configurable audit parameters: The audit facility used by the application must allow the security administrator to select the events to be logged and the information to be captured about each event.

3. No permanent Delete of Data: The system shall not allow permanent delete of data from users , instead all deleted data shall be removed from users view but available from security review purpose

4. Events to be audited: The application must log and notify security/audit administrators the following types of events to its audit facility, at a minimum: (1) Startup and shutdown, (2) Authentication, (3) Authorization/permission granting, (4) Actions by trusted and privileged users, (5) Process invocation, (6) Controlled access to data by individually authenticated user, (7) Unsuccessful data access attempt, (8) Data update, (9) Data deletion, (10) Input validation, (11) Establishment of network connection, (12) Data transfer, (13) Application configuration



Req’t Type(M / D)


change, (14) Application of confidentiality or integrity labels to data, (15) Override or modification of data labels or markings, (16) Output to removable media, (17) Output to a printer, (18) For classified applications: Changes of sensitivity labels on application accessed data objects.

5. Audit viewing and reporting tool: The audit facility used by the application shall include a tool that enables the security administrators and auditors to view the application’s audit records, and to report against them.

6. The system shall provide inbuilt change management process workflow that shall be invoked whenever there are changes to be made into the system configuration. This workflow shall be reflected during when the approved change requests in the logs for easy tracking and management.

GTR043 M The system shall support “object” and “object type” security. "Object based security" means that an object can be assigned certain security tokens that states which users/groups can perform which functions. "Object type based security" means that documents/folders or any other object will automatically inherit a default security token assigned by the application administrator.

GTR044 M The system shall implement compartmentalization: compartmentalizing users, processes and data helps contain problems if they do occur. Compartmentalization is an important concept widely adopted in the information security realm

GTR045 M The system shall put into place an intrusion detection system and ensure that all publicly accessible sections of the system are run from a demilitarized zone. Suppliers are invited to adopt the concept of militarized zone (MZ) and demilitarized zone (DMZ) to implement different security levels for each category of users. Suppliers are also expected to demonstrate how information is exchanged between the MZ and DMZ.



Req’t Type(M / D)


GTR046 M The system shall have a Test environment where new content/features need to be tested before moving to the production environment.

GTR047 M Other malware protections: The system shall be able to detect, prevent, correct and audit SQL injection; Parameter tempering; Hidden manipulations; Backdoors and debug option; Buffer overflow; Stealth command; Cross-site scripting; Forceful browsing and malicious software.Note: The successful bidder will be responsible to adhere to TRA ICT Security policy and a detailed Application Security requirements document in the implementation of the system.

Software Maintenance PolicyGTR048 M Provide details of the Bidder’s software

deployment/maintenance policy. It is expected that only mature versions of software will be deployed and that this will be refreshed at agreed periods to ensure full maintenance, support, and provision of new functionality. When new functionality is required which is only present in a relatively new release of software, you are expected to make new versions of software available by agreement

Additional Security RequirementsGTR049 M Validate Input and output: User input and output to

and from the system is the route for malicious payloads into or out of the system. All user input and user output should be checked to ensure it is both appropriate and expected.

GTR050 M Fail Securely (Closed) When any security mechanism fails it should be designed in such way that it fails closed. That is to say it should fail to a state that rejects all subsequent security requests rather than allows them.

GTR051 M Compartmentalization: compartmentalizing users, processes and data helps contain problems if they do occur. Compartmentalization is an important concept widely adopted in the information security realm.

GTR052 M No permanent Delete of Data: The system shall not allow permanent delete of data from users, instead all



Req’t Type(M / D)


deleted data shall be removed from users view but available from security review purpose.

GTR053 M Recoverability: Backup and restore capabilities.GTR054 M The system shall enable to detect, prevent, correct and

audit the following:1. SQL injection2. Parameter tempering3. Hidden manipulations4. Backdoors and debug option5. Buffer overflow6. Stealth command7. Cross-site scripting8. Forceful browsing

Additional Security RequirementsGTR049 M Validate Input and output: User input and output to

and from the system is the route for malicious payloads into or out of the system. All user input and user output should be checked to ensure it is both appropriate and expected.

InterfacesUser InterfacesGTR055 M EDI users must be provided with the choice of using

either a web-based or a thin-client graphical user interface.

GTR056 M The thin-client module must be installable remotely by the EDI user with minimal or no configurations needed on their behalf and with minimal installation of third party software (e.g. Java Virtual Machines, Flash Players etc.).

GTR057 M The thin-client module must be user friendly and must provide an online help capability.

GTR058 M Data submitted via the EDI interfaces must be sufficiently validated to ensure correct data capture before submission into the Domestic Revenue Administration Systems database for processing.

GTR059 M The system must also provide for non-repudiation of data submitted.

GTR060 M The thin-client module must provide off-line capabilities so that the user can work off-line without being connected to the Internet and is then able to



Req’t Type(M / D)


batch uploads the data when the connection is available.

GTR061 M Browser support: The web-based interface must support Internet Explorer version 7 and Firefox version 4 at the minimum for any web-based components. They must support a minimum screen resolution of 1280x768 and must not have side-scrolling under any circumstances.

GTR062 M Client interface performance: The client interface should be sufficiently light that it loads on a 64kbps internet connection in under 5 seconds.

GTR063 M The thin-client component must be update-able remotely using a central server-based updating mechanism on the network.

GTR064 M Off-line capabilities: The thin-client software must have off-line capabilities with localized off-line databases where required (e.g. at remote stations) so that users can prepare data and submit it later when a connection is available.

Hardware InterfacesGTR065 M Server hardware and OS: The Integrated Domestic

Revenue Administration System should run on any typical server hardware that supports industry standard operating system such as Windows, Linux, or UNIX

GTR066 M Interfaces to be proposed: The following interfaces to the system must be supported and proposed:

1. The proposed IDRAS should provide for Short Text Messaging (SMS) notifications and the system shall be able to interface with the most common mobile modems and/or mobile phones to support this feature.

2. The system shall be able to print on any printer and shall adjust its report resolutions to fit the common A4 print size at the minimum.

3. The system shall not require specialized data input hardware and shall be able to interface with standard keyboard, mouse, scanner and bar-code scanners if required.

4. The system shall not require specialized monitors and other data display hardware and



Req’t Type(M / D)


shall be able to work on typical standard computer monitors

Software InterfacesGTR067 M RDBMS: The system shall store data in common

relational databases and have tools for maintenance and troubleshooting of the relational database management systems (RDMS).

GTR068 File compression server: The system should provide the capability for interfacing with a file compression server that will be used for the management, compression and storage of documents related to declarations in the tiff or JPEG formats.

GTR069 External systems at TRA: The system shall provide for interfaces for external systems currently deployed at the TRA. These systems are described in the relevant section of the document

GTR070 Regional integration: The system shall also, at the minimum, take into consideration interfaces with the following system developed as part of the various regional integration initiatives:

1. The SADC and COMESA.2. The COMESA and East African Community

InitiativeCommunications InterfacesGTR071 M The system shall support common data exchange

formats and at the minimum must support the Extensible Mark-up Language (XML) and the EDIFACT messaging formats.

GTR072 M Web services interfaces: The system will provide interfaces for data exchange via the use of web services (e.g. SOAP/XML) as a means of ensuring that any system can interface and exchange data with it.

GTR073 M Email and SMS interfaces: The system shall provide the for use email as one of the means of sending alerts and notifications. Where possible, the system shall also send out alerts using mobile technologies such as the SMS service.

GTR074 M Messaging through UN/EDIFACT and UN/CEFACT: The system shall provide for the sending and receiving of messages in the UN-EDIFACT and UN-CEFACT



Req’t Type(M / D)


messages as a means of possible integration with other revenue collection and accounting systems in use in within TRA, nationally and internationally.

GTR075 M FTP usage: The system will be able to upload and store files and images on to the server file system or on to another server via the common File Transfer Protocol (FTP).

Performance and Availability RequirementsPrimary ServicesGTR076 M High availability clustering: A highly available

clustered system should be proposed with no single point of failure. Critical database and application services should be clustered into active/passive mode with automatics failover mechanism. Appropriate clustering technology should be proposed to enable this feature.

GTR077 M Availability monitoring: The proposed software to implement the high-availability mechanism should be able to monitor the status of the critical database and application layer services and initiate failover to a secondary node in case the primary active mode goes offline.

GTR078 M Fail-over facilities: When any hardware fault such as CPU, Disk Drives, Network port or any hardware resource fails on one server, the resources required to deploy the services should be automatically transferred from the failed server to the secondary server. Similarly, if any fault is detected on the Operating System, Database or application services, the cluster software should automatically stop the services on the failing servers and should automatically start the required services on the secondary server.

GTR079 M Minimum uptime for EDI: The system should provide for a minimum uptime of 99.9% to the EDI clients / web-portal users. The server should be able to handle workload of concurrent users and shall have enough database connection pooling capabilities. The concurrent number of users can presently reach about 450.

GTR080 M Reboot for memory / paging faults resolutions: The



Req’t Type(M / D)


system shall be sufficiently configured that a simple reboot of the main server can solve issues of memory leaks and page file issues without the need for technical intervention and/or reconfigurations.

GTR081 M Configured start-up services: The system shall ensure the critical start-up processes for the system are either configured as services if the deployment is Windows-based or as daemon's if the deployment is Linux/UNIX-based so that the system automatically starts up when the servers are started up.

GTR082 M Configured auto restart: The system shall be adequately configured for automatic reboots and restarts in case of disaster.

GTR083 M Response and through-put: The system shall ensure that all users including remote offices and EDI users can connect to the main server at speeds that do not hamper their data input and submission. Queries shall be processed within a second Message exchanges would not take more than

few minutes even for the network bandwidth as low as 256 kbps or dialup.

Average time for a message (average file size of 32 KB) to reach from sender to recipient’s mailbox should not take more than 8 seconds.

Bulk import of data should be completed in few minutes.

The system should be scalable so that there should not be a performance issues due to increase in the transaction volume.

Disaster RecoveryGTR084 M DR objectives: TRA currently has its main data center

where all key hardware infrastructure are hosted. To ensure business continuity in case of major disaster, the TRA has a disaster recovery site at a remote location situated about 15 kms away from the main site. The two sites have been connected via 100 mbps communication links. The strategy is meant to activate the DR system whenever there is a failure of respective system or/and of the main Data center. There will be standard daily backup/restore system using tape technology of the system at the Data center for off-site



Req’t Type(M / D)


storage. Should such disaster situation prevail at the main data center, the TRA can only allow for 30 minutes of data loss from the moment the disaster happens (i.e. an RPO of 30 minutes) and a maximum tolerable system outage of 2hours (i.e. an RTO of 2 hours).

GTR085 M Mirrored site: It is required that the disaster recovery setup mirror the main system so as to allow for rapid switchover in case of failure of the main site.

GTR086 M Business continuity: Bidders are therefore required to describe how the proposed solution will ensure business continuity through the use of the disaster recovery site.

Computing Hardware SpecificationsInfrastructure RequirementsGTR087 M Hardware infrastructure: TRA requires the Bidder to

offer to provide a new hardware infrastructure consisting of servers, storage, networking and security devices and associated system software to support the Integrated Domestic Revenue Administration System in a highly available, reliable and secure environment. The supplier is expected to supply Hardware solution as a converged infrastructure solution which is a pre-configured bundles of hardware and software in a single chassis

GTR087a M Main Site equipment and configuration plan: Having carefully study these Bidding Documents (and the Technical Requirements therein), the Bidder is required to:

1. Provide a detailed configuration diagram with explanatory narrative for the proposed main site technical infrastructure showing components, infrastructure and application software per component, main site interconnections, DR site interconnection, and network interconnections for all users.

2. A complete listing (bill of materials) of all technical infrastructure for the main site, detailing: makes, models, sizes and quantities.

GTR087b M DR equipment and configuration plan: Having



Req’t Type(M / D)


carefully study these Bidding Documents (and the Technical Requirements therein), the Bidder is required to:

1. Provide a detailed configuration diagram with explanatory narrative for the proposed DR site technical infrastructure showing components, infrastructure and application software per component, main site interconnections, DR site interconnection, and network interconnections for all users.

2. A complete listing (bill of materials) of all technical infrastructure for the DR site, detailing: makes, models, sizes and quantities.

GTR088 M Justification of the proposed infrastructure: Bidders shall propose a detailed technical infrastructure to meet the needs of the Integrated Domestic Revenue Administration System and the expected demands of the user workforce. Bidders are expected to properly justify their choice for any specific hardware and sizes and quantities of that hardware and to clearly demonstrate how they arrive to proposed hardware specifications.Reference sites where the proposed solution is installed are required as part of the proposal. Comprehensive description of reference sites are required: including the technical infrastructure configurations installed at those sites, operational use of modules at those sites and the supported taxes, usage data including taxpayers, and on-line taxpayer populations and tax-officer user populations. The Bidder shall use the data to justify the configuration proposed to TRA.

Operating EnvironmentGTR089 M Operating system including any 3rd party software:

The proposed IDRAS should be hosted onto suitably sized server environment. Bidders are invited to propose the best tested and recommended operating system for the deployment of the proposed system. However, Bidders need to ensure the proposed operating system is one that is robust and scalable enough so the system runs without any issues of



Req’t Type(M / D)


portability or performance degradation. Any third party software required, for the proper operation of the system, must be clearly indicated and supplied.

GTR090 M Client-side software: Bidders will also have to ensure that EDI users, whether web-based or using thin clients with a standard, out-of-the-box Windows Client Operating System, can access and operate the IDRAS. Bidders must supply any and all client side software tools/utilities needed for use of their proposed solution on TRA’s website for EDI users to download and install on their equipment.

GTR091 M TRA hosted: The server infrastructure will be hosted at the TRA’s premises and be accessible via its own Virtual Private Network (VPN).

GTR092 M All application user interfaces will be enabled through a graphical user environment, providing windowing features.

HistorisationGTR093 M No physical deletion: The system should not allow the

deletion of data after it has been saved in the system. Once a record is saved it should remain in the system. Records in the system can be altered. If alteration of a record takes place, the original record remains unchanged; the altered record becomes the valid record.

GTR094 M Reference data and transaction data: This historisation procedure shall be valid for all data in the system, reference data as well as transaction data.

GTR095 M Data validity periods: Historisation shall take place using validity periods for the data (“Valid From” and “Valid To”) as well as the date alteration has taken place.

GTR096 M Audit trail: The system should provide for audit trail facility to enable tracking of all transactions that bring about any changes to the database or state of the system.

Platforms and Installation RequirementsGTR097 M Currently the Purchaser has deployed HP Blade System

Server based on C7000 Carrier-Grade Enclosure. Further the Purchaser has deployed HP EVA 4400, HP



Req’t Type(M / D)


EVA 6400 and Netapp FAS2040.<No specific response to this item is expected from the Bidder.>

GTR098 M With the objective of improving RTO and RPO, the Purchaser is deploying a storage consolidation solution in Data Center and Disaster Recovery sites. By August, 2013, it expected that, the Purchaser shall deploy Vmware vSphere, Microsoft HyperV environment in the Data Center and Disaster Recovery Site. Further, the Purchaser shall deploy Netapp V2310.<No specific response to this item is expected from the Bidder.>

GTR099 M Private Cloud Platform: By January, 2014 the Purchaser is formulating a strategy that shall be a guidance to transform the current Data Center and Disaster Recovery Sites to ‘Private Cloud Platform’.The Bidder shall offer to design the deployment strategy (as part of the proposal) that shall enable implementation of the ‘Private Cloud Platform’ at the Data Center and Disaster Recovery Site during the implementation of the IDRAS within its scope.

GTR100 M Latest versions of software: The database platforms currently being used are MS SQL and Oracle. By November, 2013, it is expected they shall be upgraded and configured to Enterprise versions based on processors licensing scheme.The Bidder shall offer to provide software that are all of latest applicable versions.

GTR101 M Linux / Unix: The proposed system shall be easy to deploy on a Linux/UNIX-based platform. Installation scripts should be provided wherever necessary to automate the installation tasks on either platform

GTR102 M Automated backup and restore: The proposed system shall provide tools and scripts to automate the backup and the building of the entire database schema from scratch. The system shall provide a deployment guide and an installation guide as well as a set of wizards where necessary to ensure that the system deployment is as easy to achieve as possible.

GTR103 M Minimum technical infrastructure: The proposal should outline the recommended platform minimum



Req’t Type(M / D)


requirements in terms of hardware and software requirements as well as any third party software components that may be required.The proposed solution shall meet or exceed those recommended minima. The supplier is required to install and configure system for testing, training and production environments separately.

GTR104 M Telecommunications requirements: The proposed system should provide at least all minimum telecommunication requirements including the minimal VPN setup required for secure communication.

GTR105 M Reuse of existing telecommunications infrastructure: The system must be compatible with the existing telecommunication infrastructure and must be able to re-use as much of this infrastructure as possible.

GTR106 M Client computer program checks: The system shall provide for a program requirements check at the installation of the thin-client or on loading of the web-client on the end users computers in order to check that all required components are installed and if not then to alert the user of what components need to be installed.

Localization and Internationalization RequirementsGTR107 M Multi-lingual user interface: The system, where

possible, shall provide for the possibility of having a multi-lingual user interface but the primary user interface language shall be British English and secondary Kiswahili and the labels shall be as per the world applicable standards for the data elements.

GTR108 M Data and message formats: The system shall ensure that all data is captured and sent in utf-8 and Unicode formats as well as strict adherence to international HTML schemas for web interfaces and XML schemas and DTDs for XML data messages.

GTR109 M Operating conditions: The Bidder is expected to provide details about the recommended environmental conditions for proper operation of the computer hardware. Information such as optimal ambient temperature range, required humidity level and maximum heat dissipation for each hardware



Req’t Type(M / D)


should be specified.Design and Implementation Constraints and AssumptionsGTR110 M Maximum re-use of existing infrastructure: The

system shall ensure the maximum re-use of all hardware/software installations currently in use at the TRA. Any new additional hardware/software needed as enhancement for the deployment of the system shall fit in with the general strategy and policies that the TRA is conforming to.

GTR111 M PC for EDI thin client: The thin client solution for EDI users must be able to operate on a personal computer with standard configuration

GTR112 M Open standards for h/w and s/w: Proprietary software and hardware components shall not be used for the deployment of the system. All components of the deployment must conform to open and widely supported open standards.

GTR113 M Superior to ITAX: The main assumption is that the system shall replace ITAX system currently in use in order to fill in the missing functionality. Hence the performance of the IDRAS shall be better than the current system in operations in terms of functionality, scope, capability and coverage.

GTR114 M Interoperability: It will utilise “open systems” standards and architectures in order to ensure interoperability with any future system that is developed in the TRA.

GTR115 M Assumption re h/w BOM: The hardware envisaged for the setting up of the System is listed in the following subsections. However, if the bidder feels that that proposed bill of material needs to be modified to meet the performance specifications and the functional requirements, he may propose additional / revised bill of material.

Server Sizing and Architectural RequirementsGTR116 M Warranty for an integrated technical infrastructure

solution: The Bidder shall ensure that its recommended hardware solutions perform with the solution as expected and warranted based on the implementation of the ‘Private Cloud Platform’ within



Req’t Type(M / D)


its scope. This responsibility shall be based on current and identified future environment characteristics. This performance responsibility shall be expected through production implementation and shall be in force for one (1) production year providing that all contract requirements have not changed.

GTR117 M Describe sizing method: The Bidder’s proposal must describe the methodology used for sizing the proposed solution server computing platforms, whether for Web, application or database servers.

GTR118 M ‘Private cloud platform’: The Bidder must include a description of any necessary ‘private cloud platform’ technology for any proposed and future proposed solution platform architecture, specifying load balancing, performance scaling and hot switchover technologies for the processor and memory.Rack mounted solutions are required for servers.

GTR119 M An external disk array with appropriate RAID configuration to be used with the database server will have to be proposed.Unix database server preferred: It is preferred that the database server be UNIX based for performance considerations, other proposals will however be considered.

GTR120 M UPS for servers: The computing platform shall be required to include external uninterruptible power supply (UPS) power units for the servers.

Data Archiving, Backup, Replication and Recovery RequirementsGTR121 M Bidders are required to propose a centralized and

automated backup system. The backup system must be able to perform scheduled unattended backup of the data files and system files. Bidders are invited to propose the most convenient and effective backup strategy so as to allow for minimal backup window size and to reduce impact on production system when backup is carried out. Currently TRA is using HP protector solution for back up and restoration of production systems to/from tapes.

GTR122 M The system shall have an automatic rollback of the data backup on extreme disasters to the last point where data and system integrity was still retained.



Req’t Type(M / D)


GTR123 M The system shall create an archive of data on a prescribed frequency as part of its database cleanup and compression mechanisms that shall be easily accessible on demand. It is expected that the system shall be able to perform an automatic data archiving which involves identifying and moving inactive data of the current production system into specialized long term archived storage system. The retention period would be based on the Government’s Financial Regulations guidelines.

Network and Communication RequirementsGTR124 n/a The diagram following illustrates a proposed network

architecture that takes into consideration access by external users, proper authentication, intrusion detection and security, testing facilities, secured EDI users, internal users, integration with external third party systems and the integration requirements into the IDRAS (during the pilot-run and parallel run).<No specific response to this item is expected from the Bidder.>

GTR125 n/a Site B is recommended as a mirror of main site in order to enable rapid switchover in case of disaster at the main site.<No specific response to this item is expected from the Bidder.>

GTR126 M Network architecture model: Bidders shall confirm to offer a solution that meets the technical architecture shown or propose another improved network architecture that provides same or superior access and security characteristics as the above architecture.If an alternative is proposed the Bidder shall document the reasons that its proposal is superior.

GTR127 M Network architecture solution: The Bidder must propose a design for the recommended network for the proposed solution and quote for all components of the recommended network. The Bidder must define the required elements of the proposed solution’s network design including the data center network operations, communication hardware, local building and/or campus network (inter-site) components (e.g. structured cabling, etc…). These designs must be



Req’t Type(M / D)


compatible with industry standard technologies.GTR128 M Local network architecture: The Bidder must indicate

the type of local network connection, enabling communications between the client workstation, Web, application and/or database server(s), supporting the appropriate network and application protocols. These environmental elements shall include specifications of the cabling to be installed, local network backbone and all local installations of hubs, switches and/or routers.

GTR129 M Bandwidth specification: The Purchaser has implemented communication links to remote offices with a bandwidth ranging between 256 kbps (small offices) to 1 mbps for large offices used by all business application. The communication link between the main data center and disaster recovery site has a bandwidth of 100 mbps. The Bidder therefore, shall ensure the system being implemented will be accommodated with the mentioned bandwidth ranges.Implementation: The Bidder will offer to undertake planning, installation, configuration and testing of both active and passive components.

Desktop ConfigurationGTR130 M Windows-based desktops: All end users of the

software will interface to the application through Windows-based desktops. The Bidder must specify how this function shall be accomplished, including the operating system requirements.

GTR131 M Web Browser: For Web-based functions, users must interface to the solution through a Web Browser such as Microsoft Internet Explorer, and similar tools

GTR132 M Minimum recommended workstation configuration: The Bidder’s proposal must specify the minimum recommended workstation configuration (module by module if appropriate) including CPU(s), processor speed, memory, disk space, monitor, operating system, and any additional hardware required.

GTR133 M Desktop s/w needed: The Bidder must also recommend the required software that must exist on the desktop in order to support the functionality that shall be provided by the solution. Modems are not required for the personal computers, Internet access



Req’t Type(M / D)


will be centralised.Sofware SpecificationsRelational Database Management System (RDBMS)GTR134 M Proposed RDBMS: It is expected that the application

software will use a relational data base management system (RDBMS). The Bidder’s proposal must indicate the RDBMS system being proposed for use with its proposed software and must define the database or file processing characteristics of all software proposed in responding to this RFP.

GTR135 M Information on the RDBMS must include: List all RDBMS engines that can drive your

proposed module(s). State which of the RDBMS engines is your

recommended or preferred platform and why. Explain how referential integrity is enforced at

the RDBMS level. Describe features in RDBMS or solution that aid

in recovery procedures (rollback and recovery).Desirable features:

Capability of storing searchable free-form data elements.

Capability of referencing image-based documents and performing context-based searches in image based documents

Software Quality AttributesGTR136 M The system shall satisfy all common software quality

metrics including but not limited to adaptability, availability, correctness, flexibility, interoperability, maintainability, portability, reliability, reusability, robustness, testability, and usability.

GTR137 M Super-user intervention: The system shall provide for authenticated super-user intervention to cancel, modify or correct, or start certain business processes on behalf of any of the user categories that can use the system.

GTR138 M Super-user for correction procedures: The system shall provide 100% login capability for the super-user account even in the worst disaster possible in order to provide for an account that can start correction



Req’t Type(M / D)


procedures.Safety RequirementsGTR139 M Transactional integrity: The system shall ensure the

atomicity of all transactions; failure of one part of a transaction must result in the previous steps being rolled back in order to preserve data integrity.

GTR140 M Safe for client computers: The system shall ensure that installation of the thin-client and or use of the EDI web based interface does not cause damage to the client computers when used by the user.

Document HandlingGTR141 M Document image solution: Stakeholders will submit

supporting documents as scanned images in order to support tax returns and other submissions. The system should include solutions for speedy access to documents and should incorporate image compression tools for efficient utilization of storage.

System Management, Administration, and Security SpecificationsGeneralGTR141 M Document image solution: Stakeholders will submit

supporting documents as scanned images in order to support tax returns and other submissions. The system should include solutions for speedy access to documents and should incorporate image compression tools for efficient utilization of storage.

System Administration RequirementsGTR143 M Single control panel for system admin: The system

administration aspects should be manageable from a single control panel provided by the system.

GTR144 M Single control panel for DB admin: The database management aspects should be manageable from a single control panel provided by the system.

GTR145 M Bidders should describe how the proposed system provides the necessary tools to allow system administrators carry day-to-day system admin tasks including, but not limited to: User administration including creation of users,

groups, roles, etc. Backup and restore including backup and restore

testing and tape management



Req’t Type(M / D)


Login and password Management Bandwidth and Network monitoring including Disk space monitoring Monitoring log files including core files

generated in root file system Housekeeping of files

SecurityGTR146 M Security proposal: TRA requires effective security for

the Integrated Domestic Revenue Administration System and Bidders are expected to demonstrate how secure the proposed Integrated Domestic Revenue Administration System will be in terms of physical and logical setup.

GTR147 M 2-factor authentication: In order to provide enhanced security for system access, Bidders must provide means for two factor authentication which must be flexible and portable with minimal setup requirements. This enhanced security will not apply to all user categories and the Purchaser can selectively determine for which user category this two factor authentication must apply.

GTR148 M The systems must not be open to manipulation. Data must be secure both internally and externally and there must be extensive audit trails on what is done by whom. This applies to actions through the front end and backend of the systems.

GTR149 M The system shall provide for software security elements including access control (e.g. single sign on) to ensure that all users are correctly authenticated and authorized to access the system functionality (up to the transaction and record level) they are supposed to access and the system shall integrate with Centralized Identity Access Management System already deployed based on Oracle technology.

GTR150 M Safe transmission of data: The system shall use a combination of IP-level access restriction and VPN-level encryption to ensure the safe transmission of data.

GTR151 M The system shall ensure that all interfaces to external systems are secured using the appropriate levels of encryption and authentication mechanisms. This shall



Req’t Type(M / D)


include all messages sent and received.GTR152 M Anti-malware: The system shall put into place

mechanisms to thwart all common forms of attacks including but not limited to SQL injection attacks, cross-site scripting attacks and Denial of Service attacks.

GTR153 M The system shall put into place an intrusion detection system and ensure that all publicly accessible sections of the system are run from a demilitarized zone. Suppliers are invited to adopt the concept of militarized zone (MZ) and demilitarized zone (DMZ) to implement different security levels for each category of users. Suppliers are also expected to demonstrate how information is exchanged between the MZ and DMZ.

GTR154 M Password security (1): The system shall automatically require users to change their passwords at given intervals. The intervals should be configurable by selected Security Administrators.

GTR155 M Password security (2): The system shall automatically disable the User Id of any user who does not sign-on to the IDRAS within a given interval. This interval shall be configurable by selected Security Administrators.

GTR156 M Other high-level security features: The Integrated Domestic Revenue Administration System should also have the following high-level security features/functions: Hardware security features and device

hardening Test environment where new content/features

need to be tested before moving to the production environment.

Virus, Spam-ware and Spy-ware ProtectionGTR157 M Anti-virus: The system shall deploy or shall work with

common software anti-virus packages to ensure the operation of the system is uninterrupted by virus infections, spam-ware infections or spy-ware infections

GTR158 M Virus, spam-ware and spy-ware protection: The system shall ensure all publicly accessible sections of the system are sufficiently protected against viruses,



Req’t Type(M / D)


spam-ware and spy-ware attacksGTR159 M Worms, hacker protection: The system shall ensure

that all web-based sections of the system are sufficiently protected from infection by worms and are sufficiently protected from hackers.

Service Specifications (including training)System IntegrationGTR160 M System Integration: The Bidder shall offer the

development, testing, and implementation of standard, configured and custom software; functional and technical integration of IDRAS with all TRA systems to introduce centralized ‘Single View of Taxpayer/Customer’ and centralized Revenue Collection and Accounting System.

TrainingGTR161a M Training and Training Materials

1. User: classroom and user manual. Content must include application software end user functions for all standard functions, and functions configured, or customized for IDRAS.

2. Technical: System administration, technical support, analysts (business and system), integrators, development, database management, network management, security and auditing, developers, specialized training on supplied hardware and replication and disaster recovery to reach level 2 of support and maintenance. Technical manuals, administration manuals and classroom training must be delivered.

3. Management: Training on online queries to access key management tools and generation of management reports. This group include senior, middle and lower management staff at their specific level of functional requirements and for all functions whether standard, or configured or customized for IDRAS.

4. EDI clients: specific courseware is required for TRA’s online customers, preferably including self-paced online tutorials.



Req’t Type(M / D)


GTR161b M Training method: Bidders must demonstrate their ability and approach/methodology to provide training services to the TRA in the design, development, installation, configuration, operation, commissioning (testing and deployment) support and maintenance of the proposed system.Samples of training programs and training materials deployed elsewhere should be included with the bid.

GTR162 M Detailed training plan: The Bidder must provide in the bid a detailed plan for project team training and technology personnel detailing the training materials they would use, location, the training courses (detailed program) and duration of the training.

GTR163 M Technical training of the TRA Staff members before, during and after implementation is a must in order to bring them up to the same technical level as the vendor's personnel with regards to level 2 technical support, maintenance and development.The training shall include project management and system engineering methods orientation for TRA’s project team in the first phase of the project.Training of trainers for all end user functions is also required.

GTR164 M The number of staff to be trained is estimated as follows: Project Implementation Team (Subject Matter

Expert – Business/Stakeholders + ICT): 40 Business Application Experts (+Training of

Trainers): 40 ICT engineers, administrators (system, network,

infrastructure): 25 Business and ICT support: 40 Management – 30 Database Administrator – 5 Developer – 5 Data ware house Expert – 5

GTR165 M Materials to be provided: The Bidder shall offer to provide all material for all aspects of training, including the provision of user training manuals, and where possible CD-based tutorials and online training for dissemination.



Req’t Type(M / D)


GTR166 M Advanced training: The Bidder shall offer to include, within the training program, the training of all administrators such as system administrators, security administrators, network administrators, and database administrators to attain level 2 advanced support and maintenance capabilities.The TRA reserves the right to reproduce the training materials for subsequent in-house training of other staff and external users.

GTR167 M Training assessment methods and instruments: The training plan must include assessments to measure the success of training and knowledge transfer. The assessment results must be submitted to TRA for review and confirmation that the knowledge transfer has been successful.

GTR168 M There shall be online video (of latest technology) training (e-learning system with appropriate stages and grading for qualifications) at different levels for both taxpayers and staff for the system operation and relevant laws, regulations and procedures.

Data Conversion / Migration RequirementGTR169 M Data migration/conversion tools: The system shall

have easy to use tools and scripts to assist in the easy data migration and conversion from the ITAX database scheme and its own database schema, and vice versa.

GTR170 M Data mapping and migration / conversion scripts: The Bidder shall provide documentation on its database schema vis a vis the ITAX database schema and all relevant SQL scripts and procedures required to undertake the data migration and conversion

GTR171 M No data loss: The data migration and conversion from ITAX to the new system's database schema shall not result in any loss whatsoever and any modifications and data conversions undertaken to ensure this is a key consideration for the system deployment.

GTR171a M Data Migration Assistance: TRA requires that the Supplier shall provide expert assistance and jointly share responsibilities, during the planning, data mapping, extraction, transformation, load, testing, and quality assurance of all data migration activities.TRA must be assured of data-safe methods, esp. for



Req’t Type(M / D)


ongoing debt management from information in its (then-to-be) legacy I-Tax system

Technical SupportGTR172a M Warranty Service: 1 year for application software, 3

years for servers, workstations, and notebooks, 1 year on other hardware equipment

GTR172b M User support / hot line: Available during business hours 8am to 5 pm, on-call support after business hours (Dar es Salaam time).

GTR172c M Post-warranty maintenance services: As per contract, these will be negotiated subsequently, based on services and prices that are included as part of the bid as described in the Instructions to Bidders / Bid Data Sheet.

GTR172d M Bidder shall offer to provide application and system support and maintenance service to ensure that the Integrated Domestic Revenue Administration System and all its modules and the supporting infrastructure are running optimally and to minimize downtime.

GTR173a M S&M services to include: The Purchaser requires Bidders to offer to provide support and maintenance for subsequent service that: Provide for post-implementation support (e.g.

post go live support); Provide for support such as hotline/helpdesk,

on-site, remote dial-in, website access to patches, fixes and knowledge base;

Cater for deploying application and system software security updates, installation of patches, upgrades and bug fixes;

Cater for hardware maintenance, upgrades and bug fixes;

Provide for clearly spell out periodic tests, inspections, and preventive maintenance according to the recommended practices furnished by the original equipment manufacturer aimed at achieving efficient operation of the system and provides safe and adequate service at all times.

Submit a report for each and every unscheduled outage detailing the cause of the outage, fixes,



Req’t Type(M / D)


and steps necessary to prevent recurrence; Maintain up-to-date documentation of existing

system, infrastructure and configuration and make it available to the TRA on a regular basis.

GTR173b M S&M with minimal impact on operations: The support and maintenance service shall provide for mechanism to address application faults, problem reporting and resolution procedures in an efficient manner with minimal impact on operational services.

GTR174 M Service Level Agreements (SLA): The system shall be deployed with SLAs that sufficiently cover the maintenance and operations of the system as well as the third party components used to deploy and run the system without any exceptions.

GTR175 M Technology transfer: The supplier’s personnel deployment shall provide adequate capacity building and technology transfer to the TRA staff members who will act as the second level support for the system.

GTR175a M Implementation Change Management: TRA requires1. A collaboration between the Supplier and TRA to

design a ICM program for IDRAS for TRA personnel and also taking into consideration the relationship between TRA, taxpayers and the public.

2. The ICM program will take into account the revised Standard Operating Procedures that TRA prepares with the assistance of the Supplier (refer to GTR176b).

3. A program of Implementation Change Management (ICM) training for selected key ‘TRA change champions’, to form a ‘TRA IDRAS ICM Team’

4. Assistance to the ‘TRA IDRAS ICM Team’ to promulgate and champion changes to TRA business practices arising from IDRAS implementation through TRA through local office change champions,

5. Monitoring and review of the success of the ICM program.

This program would commence once the Supplier has published its high level system design statement at



Req’t Type(M / D)


which time the Supplier would define and develop ICM plans and instruments in detail in step with each implementation roll-out step.The Bidder shall nominate and describe its expert for these purposes (refer to QUL010).

GTR175b M Acceptance Testing Assistance: TRA requires the Supplier to provide expert assistance and to work closely with the TRA team for its acceptance testing (the Supplier being the expert in its solution). This assistance shall include: assistance in defining comprehensive test scenarios, test data sets, test scripts, expected results, test operating procedures, test ICT environments etc.

GTR175c M Warranty and Post-warranty management: The Bidder will prepare the standard operating procedure (SOPs) based on ITIL ver 3 framework that will guide the support and maintenance of the system’s life cycle.

Documentation RequirementsGTR176 M End-User documents: Two manuals in hard copy and

softcopy (format to be agreed with TRA) are to be provided:(i) Guide and tips on common use functions(ii) Comprehensive detailed user guides tailored to the specific needs of groups of TRA staff and of taxpayers and the public.Documents must be provided in English version.The Documents must be customized to the specific implementation for IDRAS at TRA.Both hardcopy and softcopy may be reproduced without limit by TRA.TRA shall have the right to modify the softcopy. The softcopy must be in an editable format.

GTR176a M Samples of user documentation: Provide samples of user documentation that the Bidder has customized for clients at its reference sites.

GTR176b M Revised Standard Operating Procedures: The Bidder team shall include business analyst(s) to work with TRA requirements experts to assist TRA revise and publish revised Standard Operating Procedures (corresponding to each implementation stage for IDRAS) corresponding to the revised end-to-end business



Req’t Type(M / D)


procedures to be operated using IDRAS.GTR177 M Technical Documents: One complete set of hardcopy

documents and one set of documents on CD for all hardware and software products supplied under the Contract.

GTR178 M User configuration documentation: Bidders shall offer to provide configuration documentation with regards to the users of the system, their permissions, their roles and the functionality they are allowed to access.

GTR179 M System configuration documentation: The system shall be provided with documentation of all infrastructure configurations, including VPN configurations, network configurations, server configurations, client configurations and any other aspect in this regard including all relevant scripts/configuration files needed.

GTR180 M Application system documentation must be provided and relevant plans and guidelines must be used to compile documentation about changes to business processes, to basic functions and to interfaces.

GTR181 M User manuals in hardcopy and softcopy format shall be provided to give detailed description of features and guidance on the use of the features.

GTR182 M Data dictionary with proper documentation must also be provided so that TRA can generate ad hoc reports.

GTR183 M Other documentation shall include: System-level (architecture, data, user interface,

hardware, application network etc.) design documentation.

Vendor-supplied documentation of hardware. Vendor-supplied documentation of software. System security plan. General support system(s) security plan(s). Application program documentation and

specifications. System Quality Assurance and Control

Methodology and results. Standard operating procedures. Emergency procedures. System-level operation and user manuals. Backup and Recovery procedures.



Req’t Type(M / D)


GTR184 M The Bidder shall offer to deliver a Continuity of Support Plan for the System that shall detail the taking of appropriate and timely action to protect system assets from damage or misappropriation in the event of the threat of a disaster or emergency. The emphasis shall be on avoiding or mitigating the damage caused by such things as fire, power, hardware/software breakdown or attackers. The plan shall, at a minimum– Include risk assessment. Include business impact assessment. Identify essential functions or critical processes,

components, and the relationship of critical workload to variables, such as time to recovery.

Identify activities that can be suspended temporarily.

Identify alternate procedures. Identify action(s) to be taken to mitigate threats.

GTR185 M The Continuity of Support Plan shall detail the taking of appropriate and timely action to return assets to use after damage, destruction, alteration, or misappropriation. The system recovery portion of the plan shall include at a minimum - Basic strategy to recovery. Specifications for restoration procedures by

component and subsystem priority. Testing procedures during redundant

operations. Specific responsibilities for emergency response.

GTR186 M Continuity of Support testing: The continuity of support plan shall state how the plan shall be tested and how often the tests shall be done. Annual testing is required as a minimum, and some tests shall be done without advance notice

GTR187 M Permanently inoperative components: The Bidder shall detail the replacement of the system or its component when rendered permanently inoperative during post warranty or in alternative way.

GTR188 M The language to be used throughout the IDRAS and all its related documentation shall be English and configurable into Swahili when needed.

Management System



Req’t Type(M / D)


GTR189 M Key Features: The System shall provide a platform upon which the enterprise can base its administrative and management operations to ensure all systems components and the services they provide are highly available. The system shall enable business administrators to monitor performance of business processes and services and modify as required. The system administrators to perform remote system configuration, monitor performance, and isolate hardware and software faults all through an easy-to-use graphical user interface. The monitoring shall be consolidated centrally to be monitored at centralized console in multiple location. Further the monitoring can be monitored from desired levels from a normal web console at the desktop/laptop or from mobile app on a simplified version.1. Reliability, Availability, and Serviceability (RAS) Features

Proactive and automated management of complex and common administrative tasks, reducing the likelihood for costly errors and ensuring availability.

GUI using Java technology, providing heterogeneous GUI support, a common look-and-feel for all applications, and the flexibility to manage the enterprise from any Java-enabled platform, thereby increasing administrator efficiency. The GUI supports dynamic reconfiguration and multi-pathing, ensuring high system availability.

Active configuration management controls, providing a secure interface for remote dynamic reconfiguration capabilities and ensuring availability.

Predictive failure analysis, enabling administrators to predict potential memory and disk hardware failures on a statistical basis, thereby enhancing decision making and increasing availability.

2.System Administration Tools Health monitoring, a sophisticated set of



Req’t Type(M / D)


heuristics that incorporates a large body of administrative knowledge, including an intelligent rules-based health monitor that correlates metrics and gives suggested steps for resolution, resulting in simplified administration.

Log-file scanning, enabling administrators to search and parse logs and registers for a particular status—the foundation for application health monitoring.

Physical viewer, displaying photo-realistic images of hardware components and pointing to components with an associated event, enabling administrators unfamiliar with a particular platform to quickly determine which components need to be replaced.

Logical viewer, presenting a tree hierarchy of the managed host or domain, including all hardware and operating system components. If an event is associated with a particular component, the logical viewer will identify its exact location within the hierarchy.

Event and alarm management, providing administrators with the information they need when they need it.

Real-time performance analysis, enabling administrators to isolate potential and existing bottlenecks.

3.Integration Features Single event model, enabling information to be

shared with multiple consoles or users with ease.

Standard interfaces and protocols, enabling integration with third-party management tools, including Tivoli TME 10 TEC 3.6, HP OpenView ITOps, and Computer Associates Unicenter TNG, thereby providing a complete enterprise management solution

Full SNMP (versions 1, 2c and V2usec) and RMI connectivity, enabling information to be shared with other enterprise management



Req’t Type(M / D)


tools Console development guide, enabling

organizations to integrate new or legacy applications with the EMS console

4.Scalability and Customization Features Common management platform, scalable from

a single system to thousands of server and desktop systems.

Configuration flexibility, enabling to be configured out of the box to best fit the needs of the environment, as well providing easy customization for new rules, scripts, actions, etc.

Extensible agent architecture, enabling administrators to add functionality and management features with ease.

Developer environment, enabling organizations to plan, design, develop and integrate third-party applications, tools, and customized solutions

Rules writing documentation, enabling rules to be created and customized

5.Security Features Enterprise-wide security measures, such as

authentication, data integrity, and access control lists for management of data and active management functions.

6.Ease-of-Use Features Single point of management, enabling

effective use of administrative resources. Dynamic agent modules, enabling functionality

to be added or removed asynchronously and dynamically

Domain-aware agents, enabling the dynamic system domains supported on the system and its associated resources to be monitored independently

Multiple system support, enabling administrators to monitor and manage all Operating Environment systems remotely.

Logical element grouping, enabling the



Req’t Type(M / D)


grouping of TRA systems by geographical (Regional) location, server role, administrative responsibility, etc. The status of the individual systems is summarized by the group, as events and alarms are issued to each system.

Hierarchy and topology viewer, a central management application that displays the hierarchy and a topology map of all the objects that are being managed.

Automatic discovery of TRA systems, including IP address, subnet address, hostnames, and to identify specific types of systems

Console wrapper, giving users easy access to native UNIX commands

GTR190 M Management System: As per OSI published official definition, the management system shall include five different components: configuration management, fault management, performance management, security management and accounting management.1. The Configuration Management, at a minimum,

shall include two different but related activities. The first shall keep track of physical hardware, serial numbers, locations, patching information and so forth. The second is the process of modifying, backing up, and restoring the software configuration of the network devices. This will include the configuration management of all system components

2. The Fault Management is the active monitoring of the various key system components to find problems and alert the appropriate people or devices. The alert shall include enough information in order to assist on troubleshooting process.

3. The Performance Management is the monitoring the system carefully and looking for bottlenecks and congestion issues. The monitoring information and decision will be input to the Capacity planning of the system.

4. The Security Management is the set of activities that ensure that the system’s security measures



Req’t Type(M / D)


work properly.5. The management system shall be capable of

managing both production and standby system components. This will allow proper management of the system during service provisioning, service management and service assurance of the system.



3 IFB Section VI Sub-Section D: Testing and Quality Assurance RequirementsReq’t Type

(M / D)Description of Requirement Bidder’s Response

InspectionsTQA001 M Inspections following delivery: The Purchaser, or its

agent, upon delivery and unpacking of the Information Technologies and other Goods to the Site(s) will perform operational tests to assess base operational capability of goods delivered. The Supplier shall render assistance to the Purchaser for the efficient conduct of this process.

Pre-commissioning TestsTQA002 M Supplier’s standard checkout and set-up tests: The

Supplier shall perform its standard checkout and set-up tests and offer to demonstrate same to the Purchaser.

TQA003 M In addition to the Supplier’s standard checkout and set-up tests, the Supplier (with the assistance of the Purchaser) must perform the following tests on the System and its Subsystems before Installation will be deemed to have occurred and the Purchaser will issue the Installation Certificate(s) (pursuant to GCC Clause 26 and related SCC clauses). Purchaser, or its agent, will execute base

functions that are available with System and its subsystems

Operational Acceptance TestsTQA004 M Operational acceptance tests: Pursuant to GCC

Clause 28 and related SCC clauses, the Purchaser (with the assistance of the Supplier) will perform tests on the System and its Subsystems following Installation to determine whether the System and the Subsystems meet all the requirements mandated for Operational Acceptance.

TQA005 M Testing tools: The system shall provide a set of tools that can be used to test various aspects of the system including but not limited to the generation of test vectors and functional testing, load and stress testing and telecommunications and transmission testing.

TQA006 M Comprehensive stress test: Following the implementation of the hardware, network and security



Req’t Type(M / D)

Description of Requirement Bidder’s Response

infrastructure, the TRA, with the assistance of the Supplier, will test the resiliency and stability of the solution by performing comprehensive stress test.

TQA007 M Quality guidelines: The elements of Certified Software Quality Engineer (CSQE) Body of Knowledge as outlined in American Society for Quality (ASQ) item B0110 shall guide in the software quality assurance.

TQA008 M Quality criteria: The quality of the system shall follow a criteria based on system usability, functionality, reliability, efficiency, maintainability, portability (based on adaptability, install ability, conformance and replace ability), security, availability, scalability and time-to-market as shown in Table 2 below.

TQA009 M Specifically for system inspection: testing, verification and validation shall be evaluated as shown in Table 1 and Figure 3.

TQA010 M Test cases: The Supplier shall prepare and derive relevant test cases and plan together with TRA for smooth implementation of testing and system quality assurance.

TQA011 M The Supplier shall manage the system configuration through identification of software items, versioning, dependency tracking and change management, requirement tracing, configuration management and audit trails that its database shall be handed over to TRA at commissioning stage and further be used during support and maintenance of the system. This shall also involve intermediary approvals before going to the subsequent stage.

TQA012 M System ownership: The system source code, software, equipment and underlying components including relevant licenses shall bear the ownership of TRA perpetually.

TQA013 M Pilot testing: The deployment testing (alpha and beta) shall include system pre-pilot run, then pilot run for three months in selected controlled areas and during in full operations after rollout for following six months.

Entry Criteria for Operational Acceptance TestsTQA014 M Prior to starting the Operational Acceptance Test, the

Purchaser with the assistance of the Supplier will perform a tests on the System and Subsystems that



Req’t Type(M / D)


are ready for test as per schedule shown in Table 1 and 2 and Figure 3.

TQA015 M Entry criteria: The tests shall validate that the system is ready for use and that there are no major defects that prevent the smooth execution of the operational acceptance test. The success rate for the entry criteria test must exceed 90%. If the success rate is below 90%, the Operational Acceptance Test cannot start and it will be deemed that the Supplier has not met the milestone for start of Acceptance Test. Any delay in start of Operational Acceptance Test will be the responsibility of the Supplier.

TQA016 M Schedule and repair: Operational Acceptance Test will be executed within the time period as agreed in the Project Implementation Plan. Defects will be formally recorded and notified to the Supplier who shall execute the necessary modification to meet the Purchasers requirements at a rate of 100%.

Exit Criteria for Operational Acceptance TestsTQA017 M Exit criteria (1): The Operational Acceptance Test will

be complete whenAt least 95% of the tests have been executed successfully

TQA018 M Exit criteria (2): The Operational Acceptance Test will be complete when

The Supplier has submitted a plan for correction of pending defects within A timeframe that is acceptable to the Purchaser within the Warranty Period.



4 IFB Section VI Sub-Section E: Firm and Team QualificationsReq’t Type

(M / D)Description of Requirement Bidder’s Response

Firm and Team QualificationsQUL001 M Proven system: The proposed IDRAS Solution MUST be

operational in at least two (2) other tax agencies similar to the Purchaser implemented within the last eight (8) years.“Similar” means that the Tax Administration already using the System MUST have a comparable number of:

- Taxpayers, which should be more than 1,000,000 Taxpayers.

- Different types of taxes which should provide an integrated tax account per taxpayer (and integrated revenue accounts) for multiple tax-types including at least personal and corporate income taxes, a consumption tax (such as VAT or sales tax) , non-periodic taxes such as a withholding tax on transactions and miscellaneous fees and charges.

QUL002 M Bidder experience: The Bidder MUST have been in operation for at least the eight (8) years preceding the Bid Opening date.

QUL003 M Project team: Bidder MUST identify all the members of their project team and the organizational model for the project. Substitutions for any member of the winning bidder’s proposed project team must be approved by the TRA.

QUL004 M Technology transfer: Bidder MUST specify their methodology for technology transfer and provide qualified specialists to train TRA including professional staff, IT staff and managers.

QUL005 M Bidder MUST provide appropriate professional staff (quality and quantity) during duration of the project

QUL006 M Bidder MUST provide a project manager for this project with at least the following knowledge and experience:

1. Right-depth of understanding of the scope of the project

2. Understanding in-depth the methodology



Req’t Type(M / D)


that will be applied by Bidder3. At least five (5) years of experience in project

management to develop and implement ICT systems

4. Experience relevant to the service the bidder must provide to the TRA, and management capabilities to meet the requirements of the TRA.

5. A graduate degree in business, finance, information technology or a related area is desirable.

QUL007 M Bidder MUST provide a business solution design specialist with professional knowledge and experience as follows:

1. Must have at least five (5) years’ experience implementing the design and implementation of IT systems government finance projects (e.g., budget, customs, and/or tax administration).

2. At least five (5) years’ experience in supervision and leadership to the project team to implement the development and implementation of tax processing system.

3. Having a deep understanding of business processes management of taxes.

4. Having a deep understanding of and experience implementing the proposed COTS product.

5. Ability to listen, capture professional requirements of customers, ability to assist in resolving problems.

6. Having a graduate degree in business, finance, information technology or a related area.

QUL008 M Bidder shall propose one or more tax administration specialists that (collectively) have experience and knowledge in the functional areas specified in this IFBEach of the specialists must have the knowledge and experience as follows:

1. At least eight (8) years’ experience in the functional area(s) in which they will be



Req’t Type(M / D)


responsible for providing guidance and advice in business process reengineering or IDRAS requirements definition.

2. At least a graduate degree business, finance, or a related area.

Preferably the experts also have experience at sites that have implemented the proposed COTS product.

QUL009 M Bidder shall propose ICT specialists responsible for1. The configuration and customization, testing,

and implementation of the proposed systems and

2. Handling issues related to the business and other technical requirements of the TRA.

The ICT specialists collectively must have the knowledge and experience as follows:

1. At least ten (10) years’ experience working in the IT field.

2. A graduate degrees in information technology or a related area (desired only).

3. At least five (5) years’ experience in supervision and leadership to the ICT project team

4. Ability to resolve issues related to software application design.

5. Have knowledge financial information systems

6. At least five (5) years’ experience working with Oracle database and its programming

7. At least five (5) years’ experience implementing the proposed COTS solution.

8. At least one (1) years’ experience in the field implementing each of the proposed technical infrastructure products.

QUL010 M Bidder shall propose a Change Management expert responsible for the Implementation Change Management (ICM) requirements set out at GTR175a in these Technical Requirements and with at least the following knowledge and experience:

1. At least five (5) years of experience in conducting a comparable ICM program in a nation-wide government-sector projects of



Req’t Type(M / D)


similar complexity2. A graduate degree in business, finance,

information technology or a related area is desirable.

Preferably the expert also have experience (1) conducting ICM programs within a tax administration and (2) at sites that have implemented the proposed COTS product.

QUL011 M Bidder shall propose a lead Trainer (supplemented by a training team which may be drawn from other members of its team and other resources for the delivery of training) responsible for the Training requirements set out at GTR1661a to 168 in these Technical Requirements and with at least the following knowledge and experience:

1. At least five (5) years of experience in conducting a comparable Training program in a nation-wide government-sector projects of similar complexity

2. A graduate degree in business, finance, information technology or a related area is desirable.

Preferably the expert also have experience (1) conducting Training programs within a tax administration and (2) at sites that have implemented the proposed COTS product.



5 IFB Section VI Sub-Section F: Implementation Schedule

Req’t Type(M / D)


Implementation and Implementation Schedule RequirementsIAS001 M The services for system development shall follow

iterative process flow based on requirement engineering, planning, modelling, construction and deployment into operation as shown in Figure 2 below. Requirement Engineering – This shall involves

inception, elicitation, negotiation, specification, validation and requirement management;

Planning – software design, implementation and deployment project planning;

Modeling – This shall include requirement modelling (such as scenarios, information, analysis, classes, flow and patterns), user interface design (such as interface, aesthetic, content and navigation designs), architecture design, component design and prototyping;

Construction – This shall include configuration, coding/customization, installation and testing;

Deployment –This shall include system release, transition, delivery, commissioning and feedback.

Post-Deployment – This shall involve support, maintenance, warranty and post warranty.

IAS001a M Requirement Engineering (supplementary requirement): The vendor will use the requirements that have been provided and implement the system through requirement engineering methodology as described above and elsewhere in the IFB.As part of its preparation for IDRAS, TRA has conducted Business Process Reengineering and relevant requirements and descriptions are contained with these Technical Specifications. Nevertheless the Bidder shall offer to discuss with TRA’s designated business experts further refinements to the TRA business processes based on best use of their proposed COTS solution and the Bidder’s suggestions



Req’t Type(M / D)


of international good practice based on their projects elsewhere. Before concluding the Requirements Documentation per implementation stage, the Bidder shall offer to prepare supplementary proposals for further refinements based on these discussions. TRA will consider such proposals and accept, reject or modify as it assesses necessary. The Supplier would then proceed to finalize the Requirements Documentation per implementation stage.

IAS002 M Project Management: Either Prince 2 or PMBOK methodologies shall be used for the project management. The project management shall involve the integration, scope, time, cost, quality, human resource, communications, risk, change and contract management

IAS003 M Implementation Schedule: It is proposed that the system be implemented in phases as described below in Table 3.The Purchaser will not accept a ‘big bang’ approach for all functions, tax-types, taxpayers and tax offices.The Purchaser requires that the implementation proceeds in stages with each stage being a subset of the total functions and tax-types to be implemented.Nominally three stages are indicated, e.g.

Stage#1 might be Income Tax and selected non-periodic taxes for a core set of functions necessary for tax administration (not less than Taxpayer Registration and Identification Number, Taxpayer Return, Assessment and Document Processing, Compliance Monitoring, Payment Processing, Refund Processing, and Taxpayer and Revenue Accounting and associated system management functions and reports and enquiries)

Stage#2 might be VAT and other periodic taxes for the core set of functions necessary for tax administration

Stage#3 might be all other taxes and all other functions for all tax-types)

Core modules/functionalities include:



Req’t Type(M / D)


E-service Workflow and Data ManagementTaxpayer RegistrationReturn processingPayment processingTaxpayers & Revenue AccountingCompliance & EnforcementObjection and AppealsAudit SupportManagement Information System

Other Modules include:Refund ManagementCase ManagementTax Payer Services and Customer Relationship Management

The exact definition of the contents of each implementation set shall be subject to agreement during Phase 0 of the project.The Phases and activities should overlap for efficient deployment of the Supplier’s resources, and to restrict the implementation timeline – the concept is illustrated below after Table 3.However, at all times the schedule will address: (1) the need for TRA to continue its full functioning during the implementation and (2) the demands that implementation placed upon TRA’s domain expert. These domain experts would be expected to be engaged most heavily during the Analysis, Change Management, Standard Operating Procedure drafting, Acceptance Testing, end-user training, deployment and go-live activities.It is desired that the System Development Project duration be no longer than 30 months. In particular, TRA would find it beneficial to have a substantial set of core functions for Income Tax by the 2017 filing period for the 2016-17 tax year (from July 2017). Bidders are however invited to propose alternative implementation phases and duration that they view as being more beneficial to the Purchaser.The Payment Schedule for the System Development shall be as shown in Table 4 below.

IAS004 M Documents subject to review and approval: The



Req’t Type(M / D)


following documents shall be subject to review and approval process by the Purchaser prior to full-scale execution of subsequent steps:1. detailed site surveys;2. Detailed Requirements Documentation per

implemented module3. Detailed overall system design specifications4. Functional Specifications document per

implemented module,5. Change management and training plans6. Stakeholder communication plan7. final Subsystem configurations8. Operational Acceptance Test Plans and Results9. Data Migration Plans and execution results10. Monthly progress reports

IAS005 M Preliminary Project Plan1. The Bidder must prepare a Preliminary Project Plan

describing, among other things, the methods and human and material resources that the Bidder proposes to employ in the design, management, coordination, and execution of all its responsibilities, if awarded the Contract, as well as the estimated duration and completion date for each major activity. The Preliminary Project Plan must also address the topics and points of emphasis specified in SCC Clause 19 including any additional items stated in the Bid Data Sheet for ITB Clause 14.2 (c).

2. The Preliminary Project Plan should also state the Bidder’s assessment of the major responsibilities of the Purchaser and any other involved third parties in System supply and installation, as well as the Bidder’s proposed means for coordinating activities by each of the involved parties to avoid delays or interference.

3. In addition to the topics and points of emphasis, the Preliminary Project Plan MUST also address Quality Management activities and reports

to be provided to the Purchaser.IAS006 M Confirmation of Responsibility for Integration and

Interoperability of Information Technologies



Req’t Type(M / D)


The Bidder must submit a written confirmation that, if awarded the Contract, it shall accept responsibility for successful integration and interoperability of all the proposed Information Technologies included in the System, as further specified in the Bidding Documents.



Notes to Bidders on the preparation of Bid Response Forms and Preparation of Bids

This section and the next are not part of the TRC but are repeated here as a reminder that careful attention to detail is required for the preparation of bids in the required format.

ID Requirement Description Bidder’s response

BRF001 The Purchaser has prepared the forms in this section of the Bidding Documents to suit the specific requirements of the System being procured. They are derived from the forms contained in the PPRA’s Standard Bidding Documents for the Supply and Installation of Information Systems modified where necessary for 2-stage bidding based on World Bank Standard Bidding Documents for ICT. In its bid, the Bidder must use these forms (or forms that present in the same sequence substantially the same information). Bidders should not introduce changes without the Purchaser’s prior written consent. If the Bidder has a question regarding the meaning or appropriateness of the contents or format of the forms and/or the instructions contained in them, these questions should be brought to the Purchaser’s attention as soon as possible during the bid clarification process, either at the pre-bid meeting or by addressing them to the Purchaser in writing pursuant to ITB Clause 10.

BRF002

BRF003

The Purchaser has tried to provide explanatory text and instructions to help the Bidder prepare the forms accurately and completely. The instructions that appear directly on the forms themselves are indicated by use of typographical aides such as italicized text within square brackets [] as is shown in the following example taken from the 1st stage Bid Form:Duly authorized to sign this bid for and on behalf of [insert: name of Bidder]

BRF004 In preparing its bid, the Bidder must ensure all such information is provided and that the typographical aides are removed. Failure to do so may render the bid non-responsive.

BRF005 The sample forms provide a standard set of documents that support the procurement process as it moves forward from the stages of bidding, through Contract formation and onto Contract performance. The first set of forms must be completed and submitted as part of the 1 st stage bid prior to the deadline for bid submission.These include:

i. the 1st stage Bid Form;ii. the Manufacturer’s Authorization Forms;

iii. the List of Proposed Subcontractors; and other forms as found in sub-sections 1 through 4 of this Section VII of the Bidding Documents

Forms that would be required at the second stage for invited Bidders will include:i. the 2nd stage Bid Form

ii. the Price Schedulesiii. the Manufacturer’s Authorization Forms;iv. the List of Proposed Subcontractors;v. the Bid Security; and other forms as found in sub-sections 1 through 4 of this Section VII of




the Bidding Documents.BRF006 The 1 st stage Bid Form : In addition to being the place where other important details are expressed,

the Bid Form is also used by the Bidder to confirm - in case adjudication applies in this Contract - its acceptance of the Purchaser’s proposed Adjudicator, or to propose an alternative. If the bid is being submitted on behalf of a Joint Venture, it is essential that the Bid Form be signed by the partner-in-charge and that it be supported by the authorizations and power of attorney required pursuant to ITB Clause 6.2. Given widespread concern about illegal use of licensed software, Bidders will be asked to certify in the Bid Form that either the Software included in the bid was developed and is owned by the Bidder, or, if not, the Software is covered by valid licenses with the proprietor of the Software.The 2 nd stage Bid Form: In addition to being the place where official confirmation of the bid price, the currency breakdown, the completion date(s), and other important Contract details are expressed, the Bid Form is also used by the Bidder to confirm - in case adjudication applies in this Contract - its acceptance of the Purchaser’s proposed Adjudicator, or to propose an alternative. If the bid is being submitted on behalf of a Joint Venture, it is essential that the Bid Form be signed by the partner in charge and that it be supported by the authorizations and power of attorney required pursuant to ITB Clause 6.2. Given widespread concern about illegal use of licensed software, Bidders will be asked to certify in the Bid Form that either the Software included in the bid was developed and is owned by the Bidder, or, if not, the Software is covered by valid licenses with the proprietor of the Software.

BRF007 Price Schedules : (to be provided with 2 nd stage bids only) The prices quoted in the Price Schedules should constitute full and fair compensation for supply, installation, and achieving Operational Acceptance of the System as described in the Technical Requirements based on the Implementation Schedule, and the terms and conditions of the proposed Contract as set forth in the Bidding Documents. Prices should be given for each line item provided in the Schedules, with costs carefully aggregated first at the Subsystem level and then for the entire System. If the Price Schedules provide only a summary breakdown of items and components, or do not cover some items unique to the Bidder’s specific technical solution, the Bidder may extend the Schedules to capture those items or components. If supporting price and cost tables are needed for a full understanding of the bid, they should be included.

BRF008 Arithmetical errors should be avoided. If they occur, the Purchaser will correct them according to ITB Clause 38.2 without consulting the Bidder.Major omissions, inconsistencies, or lack of substantiating detail can lead to rejection of a bid for commercial non-responsiveness. Presenting prices according to the breakdown prescribed in the Price Schedules is also essential for another reason. If a bid does not separate prices in the prescribed way, and, as a result, the Purchaser cannot apply the domestic preference provision described in ITB Clause 41, the Bidder will lose the benefit of the preference. Once bids are opened, none of these problems can be rectified. At that stage, Bidders are not permitted to change their bid prices to overcome errors or omissions.




BRF009 Manufacturer’s Authorizations: In accordance with ITB Clause 6.1 (b), a Bidder must submit, as part of its bid, Manufacturer’s Authorization Forms in the format provided in the Bidding Documents for all items specified in the Bid Data Sheet.

BRF010 List of Proposed Subcontractors: In accordance with ITB Clause 6.3, a Bidder must submit, as part of its bid, a list of proposed subcontracts for complex Technologies, Goods, and Service items (and those estimated to cost more than 10 percent of the total bid price). The list should also include the names and places of registration of the Subcontractors proposed for each item and a summary of their qualifications.

BRF011 List of Software and Materials: In accordance with ITB Clauses 13.1 (c) (vi) and 25.1 (e) (vi), Bidders must submit, as part of their bids, lists of all the Software included in the bid assigned to one of each of the following two categories:(A) System, General Purpose, or Application Software; and(B) Standard or Custom Software.Bidders must also submit a list of all Custom Materials. If provided for in the Bid Data Sheet, the Purchaser may reserve the right to reassign certain key Software to a different category. Software categorization has particular meaning in the GCC / SCC.

BRF012 Qualification Information Forms: In accordance with ITB Clause 6, the Purchaser will determine whether the Bidder is qualified to undertake the Contract. This entails financial, technical as well as performance history criteria which are specified in the BDS for ITB Clause 6. The Bidder must provide the necessary information for the Purchaser to make this assessment through the forms in this sub-section. The forms contain additional detailed instructions which the Bidder must follow.

BRF013 Bid Security: The Bidder shall provide the Bid Security, either in the form included in these sample forms or in another form acceptable to the Purchaser, pursuant to the provisions in the Instructions to Bidders.If a Bidder wishes to use an alternative Bid Security format, it should ensure that the revised format provides substantially the same protection as the standard format; failing that, it runs the risk of rejection for commercial non-responsiveness. Refer also to BRF001 concerning Bidder questions pertaining to the content and format of forms.

BRF014 Bidders need not provide the Performance Security and Advance Payment Bank Guarantee with their bids (1st stage and 2nd stage). Only the Bidder selected for award by the Purchaser will be required to provide these securities.

BRF015 The following Forms are to be completed and submitted by the successful Bidder following notification of award: (i) Contract Agreement, with all Appendices; (ii) Performance Security; and (iii) Bank Guarantee for Advance Payment.

BRF016 Contract Agreement: In addition to specifying the parties and the Contract Price, the Contract Agreement is where the: (i) Supplier Representative; (ii) if applicable, agreed Adjudicator and his/her compensation; and (iii) the List of Approved Subcontractors are specified. In addition, modifications




to the successful Bidder’s Bid Price Schedules are attached to the Agreement. These contain corrections and adjustments to the Supplier’s bid prices to correct errors, adjust the Contract Price to reflect – if applicable - any extensions to bid validity beyond the last day of original bid validity plus 56 days, etc.

BRF017 Performance Security: Pursuant to GCC Clause 13.3, the successful Bidder is required to provide the Performance Security in the form contained in this section of these Bidding Documents and in the amount specified in accordance with the SCC.

BRF018 Bank Guarantee for Advance Payment: Pursuant to GCC Clause 13.2, the successful Bidder is required to provide the Bank Guarantee for Advance Payment in the form contained in this section of these Bidding Documents or another form acceptable to the Purchaser. If a Bidder wishes to propose a different Advance Payment Security form, it should submit a copy to the Purchaser promptly for review and confirmation of acceptability before the bid submission deadline. The amount of the advance payment to be guaranteed is specified in SCC Clause 13 (which itself typically refers back to SCC Clause 12, Terms of Payment).

BRF019 The Purchaser and Supplier will use the following additional forms during Contract implementation to formalize or certify important Contract events: (i) the Installation and Operational Acceptance Certificates; and (ii) the various Change forms. These and the procedures for their use during performance of the Contract are included in the Bidding Documents for the information of Bidders.



Bid Table of Contents and ChecklistNote: Bidders should expand and (if appropriate) modify and complete the following table. The purpose of the table is to provide the Bidder with a summary checklist of items that must be included in the First Stage Bid, as described in ITB Clauses 13 and 14. It also provides a summary page reference scheme to ease and speed the Purchaser’s bid evaluation process.Required Contents of Bid

Item present: y/n

page no.

First Stage Bid FormSignature Authorization

(for Joint Ventures additionally including the authorizations listed in ITB Clause 6.2)Attachment 1 Bidder’s EligibilityAttachment 2 Bidder’s Qualifications

Financial, Technical , Production Capability (per ITB 6.1 (a))1. Similar assignment experience (per BDS 6.1 (a) 1.2. Contract references (per BDS 6.1 (a) 2.)3. Financial statements (per BDS 6.1 (a) 3.)4. Statement of pending litigation (per BDS 6.1 (a) 4.)

Manufacturer’s Authorizations (per ITB 6.1(b))Software Ownership statement (per BDS 6.1 (b))Agent confirmation (per ITB 6.1 (c))

Attachment 3 Eligibility of Goods and ServicesAttachment 4 Conformity of the Information System to the Bidding Documents

Overview of proposed solutionTechnical Responsiveness ChecklistManagement and Personnel capabilityPreliminary Project Plan

Attachment 5 Proposed SubcontractorsAttachment 6 Intellectual Property (Software and Materials Lists)Attachment 7 DeviationsAttachment 8 Alternative Bids

Required Media and Format for BidItem present: y/n Item present: y/nOriginal Bid (hardcopy) Copy of Bid (hardcopy)CD#1 or Memory Stick#1(containing PDF document of entire bid plus MS Word document of TRC)

CD#2 or Memory Stick#2(containing PDF document of entire bid plus MS Word document of TRC)
