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 Requirements
Req’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
registration
The 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
Bidder: <insert bidder name> IDRAS IFB Technical Responsiveness Checklist – 1st Stage Bids
Req’t
Type
(M / D)
REG002
M
REG003
M
REG004
M
REG005
M
REG006
M
REG007
M
REG008
M
REG009
M
Description of Requirement
Code for Meeting
Requirement
(I, C, M, F, N)
2
Explanation for Given Code
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.
Detect Duplicate Accounts: Show potential duplicate
taxpayer accounts before creating new taxpayer
profiles.
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.
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.
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
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.
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.
Maintain Taxpayer Profile History: Maintain all
versions of a taxpayer’s profile by always adding new
information, never updating existing information.
Maintain Versions of TRA Business Rules: Maintain all
versions of the TRA business rules by always adding
new rules, never updating existing rules.
IDRAS 1st Stage IFB 2015
Bidder: <insert bidder name> IDRAS IFB Technical Responsiveness Checklist – 1st Stage Bids
Req’t
Type
(M / D)
REG010
M
REG011
M
REG012
D
REG013
M
REG014
M
REG015
M
Description of Requirement
Code for Meeting
Requirement
(I, C, M, F, N)
3
Explanation for Given Code
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.
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
Support Multiple Taxpayer Addresses: Accept
multiple addresses for a single taxpayer.
Store Addresses for Each Tax Type: Accept multiple
addresses for each tax that a taxpayer is responsible
for.
Maintain Address for each business Location: Accept
multiple addresses for each of the taxpayer’s reporting
locations
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.
The system shall be able to de-register taxpayers in
line with business rules.
IDRAS 1st Stage IFB 2015
Bidder: <insert bidder name> IDRAS IFB Technical Responsiveness Checklist – 1st Stage Bids
Req’t
Type
(M / D)
Description of Requirement
Code for Meeting
Requirement
(I, C, M, F, N)
4
Explanation for Given Code
Taxpayer Return, Assessment and Document Processing (RET)
RET001
M
RET002
M
RET003
M
RET004
RET005
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
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.
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.
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.
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.
Payment Notices: Produce payment notice/slip for a
IDRAS 1st Stage IFB 2015
Bidder: <insert bidder name> IDRAS IFB Technical Responsiveness Checklist – 1st Stage Bids
Req’t
Type
(M / D)
RET006
M
RET007
M
RET008
M
RET009
M
RET010
M
RET011
M
RET012
M
RET013
M
RET014
M
Description of Requirement
Code for Meeting
Requirement
(I, C, M, F, N)
5
Explanation for Given Code
taxpayer to proceed with payment and generate a
unique reference number for it.
Store Assessment Information: Capture assessment
information automatically into the Accounting System
immediately when an assessment is raised, including
where a taxpayer undertakes self-assessment.
Extensions: Grant time extensions to file returns.
Withholding Taxes: Process withholding taxes:
interest, royalties, technical fees, rental income,
insurance, dividends, and transport.
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
who become dormant and are no longer in operation.
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.
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.
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.
Amended Returns: The system shall provide the ability
for a taxpayer to file an amended return where the
business rules require.
Process Integrated Tax Return: Process an integrated
tax return and payment regime for periodic tax
liabilities (e.g., employee withholdings, VAT, advance
IDRAS 1st Stage IFB 2015
Bidder: <insert bidder name> IDRAS IFB Technical Responsiveness Checklist – 1st Stage Bids
Req’t
Type
(M / D)
RET015
M
RET016
M
RET017
M
RET018
M
RET019
M
RET020
M
RET021
M
RET022
M
RET023
D
Description of Requirement
Code for Meeting
Requirement
(I, C, M, F, N)
6
Explanation for Given Code
payments of corporate income tax, and other
miscellaneous taxes) for medium and large taxpayers.
Track Channel of Filing: Indicate how a return was
filed.
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
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.
Multiple Channels for Filing: Allow taxpayers to file tax
returns through multiple channels, including paperbased forms, fax, or the internet. Validate tax returns,
conduct exception handling, and calculate tax
liabilities.
Printing, Viewing, and Searching of Return
Information: The System MUST be able to print, view,
search, export data and summarize all tax return
information.
Identification of Users: The System MUST store the
actions of those who entered the return.
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.
Capture Tax Assessment Information: Capture all tax
assessment information prior to payment.
Match Payments: Accurately match tax payments with
relating tax assessments.
Process Estimated Tax Payable: Process Statement of
Estimated Tax payable and Return of Income for
entities and individuals.
IDRAS 1st Stage IFB 2015
Bidder: <insert bidder name> IDRAS IFB Technical Responsiveness Checklist – 1st Stage Bids
Req’t
Type
(M / D)
Description of Requirement
RET024
M
RET025
M
RET026
M
RET027
M
RET028
D
RET029
M
Estimated Tax – Presumptive Regime: Process
Statement of Estimated Tax payable for individuals
under presumptive regime.
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.
Jeopardy Assessment Notices: i.e., assessment issued
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.
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.
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.
Identify Duplicate Assessments: Identify duplicate or
similar assessments. E.g. In case taxpayer tries to
submit another return for some reasons
Code for Meeting
Requirement
(I, C, M, F, N)
7
Explanation for Given Code
IDRAS 1st Stage IFB 2015
Bidder: <insert bidder name> IDRAS IFB Technical Responsiveness Checklist – 1st Stage Bids
Req’t
Type
(M / D)
Description of Requirement
RET030
M
RET031
M
RET032
M
RET033
M
Generate Presumptive Estimation: Generate
presumptive estimation of tax liabilities for non-filers
based on all of the following:
1. Historical data
2. User pre-defined criteria or available
fallback/alternative indicators
3. Analysis of similar industries
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.
Calculate Penalties and Interest: Calculate applicable
penalties and interests using rules for a specific tax
type
Accommodate and support the implementation of an
indicator based fallback system to estimate tax dues.
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.
RET034
Code for Meeting
Requirement
(I, C, M, F, N)
8
Explanation for Given Code
IDRAS 1st Stage IFB 2015
Bidder: <insert bidder name> IDRAS IFB Technical Responsiveness Checklist – 1st Stage Bids
Req’t
Type
(M / D)
Description of Requirement
Code for Meeting
Requirement
(I, C, M, F, N)
9
Explanation for Given Code
Compliance Monitoring (COM)
COM001
M
COM002
M
COM003
M
COM004
M
COM005
M
COM006
M
COM007
M
COM008
M
COM009
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.
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.
Warn of Consistent Delinquency: Provide the
capability to notify the appropriate user that a
taxpayer has been consistently filing late returns.
Warn of Fraudulent Returns: Provide a means to
denote on the taxpayer’s profile that a taxpayer has a
history of filing fraudulent returns.
Process Multiple Tax Returns per Period: the
capability to process multiple returns per reporting
period from the same taxpayer for different tax types.
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.
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 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.
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.
Provide Correspondence about Extensions: Provide
the capability to generate correspondence to
taxpayers when a filing extension has been granted.
IDRAS 1st Stage IFB 2015
Bidder: <insert bidder name> IDRAS IFB Technical Responsiveness Checklist – 1st Stage Bids
Req’t
Type
(M / D)
Description of Requirement
COM010
M
COM011
M
COM012
M
COM013
M
COM014
M
COM015
M
COM016
M
Returns History: The System MUST store ALL tax
returns including history of all deleted (amended)
returns submitted by each Taxpayer, for each tax.
Identify Under-Estimation: Identify and detect the
under-estimation of tax liabilities for non-filers over a
period of time
Inform Taxpayers of Returns and Amounts Due:
Contact taxpayers to request filing of all required
returns as well as payment of any amounts due.
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
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.
Returns Summary Report: The System MUST be able
to print and view information regarding
i) 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
v) repayment returns
vi) loss returns for their tax period, tax office, tax type
within the interval selected by the user
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
Code for Meeting
Requirement
(I, C, M, F, N)
10
Explanation for Given Code
IDRAS 1st Stage IFB 2015
Bidder: <insert bidder name> IDRAS IFB Technical Responsiveness Checklist – 1st Stage Bids
Req’t
Type
(M / D)
Description of Requirement
Code for Meeting
Requirement
(I, C, M, F, N)
11
Explanation for Given Code
Payment Processing (PAY)
PAY001
M
PAY002
M
PAY003
M
PAY004
M
PAY005
M
PAY006
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.
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, and
4. used to update the system with every
payment made at the bank
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.
Distribute Payments: Provide the capability to apply
money paid by a taxpayer in a single payment to
multiple tax bills.
Multiple Payments to Single Tax: Provide the
capability to apply money paid by a taxpayer through
multiple payments to a single tax bill.
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
IDRAS 1st Stage IFB 2015
Bidder: <insert bidder name> IDRAS IFB Technical Responsiveness Checklist – 1st Stage Bids
Req’t
Type
(M / D)
PAY007
M
PAY008
M
PAY009
M
PAY010
M
PAY012
M
PAY013
M
PAY014
M
PAY015
M
PAY017
M
PAY018
M
PAY019
M
Description of Requirement
Code for Meeting
Requirement
(I, C, M, F, N)
12
Explanation for Given Code
TISS.
Accept Direct Deposit: Accept direct deposit as
detected on commissioner’s account.
Applied Payments to Liabilities Owed: Apply money
paid with a single payment to liabilities owed across
multiple taxes and multiple reporting periods.
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.
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.
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
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.
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.
Reconciliation of Bank Payments: Facilitate
automated reconciliation with TRA’s banks collection
accounts.
Store Bank Routing and Account Information: Store
bank routing and account numbers from taxpayers’
payments.
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.
Provide Suspense Account for Unidentified Payments:
IDRAS 1st Stage IFB 2015
Bidder: <insert bidder name> IDRAS IFB Technical Responsiveness Checklist – 1st Stage Bids
Req’t
Type
(M / D)
PAY020
M
PAY021
M
PAY022
M
PAY023
M
PAY024
M
PAY025
M
Description of Requirement
Code for Meeting
Requirement
(I, C, M, F, N)
13
Explanation for Given Code
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.
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
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.
Clearance of Custody Account: Support the clearance
of ‘Custody Account’.
Notes: Custody account be cleared on daily
basis by the system.
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 countryspecific formats like TISS.
Report of Imported Payment Data: The System MUST
be 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.
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
IDRAS 1st Stage IFB 2015
Bidder: <insert bidder name> IDRAS IFB Technical Responsiveness Checklist – 1st Stage Bids
Req’t
Type
(M / D)
PAY026
M
PAY027
M
PAY028
PAY029
M
PAY030
M
PAY031
M
PAY032
M
PAY033
M
PAY034
M
Description of Requirement
Code for Meeting
Requirement
(I, C, M, F, N)
14
Explanation for Given Code
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.
Payments for Penalties & Interest: The System MUST
be able to process the Taxpayer’s payment of interest
and penalties for late payment.
Payment Transfers & Adjustments: The System MUST
provide ability to transfer payments and immediately
adjust account balances of Taxpayer profiles and
ledgers.
Payment History: The System MUST be able to store
the history of changes and deletions made with regard
to tax payment.
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.
Vendor should develop common standard interfaces
through which various data from different types of
media and disparate multiple stakeholders systems
may be exchanged.
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.
The solution should ensure systems security and data
integrity is guaranteed as per acceptable best practice
and international standards.
Identify fraud that might be or intended to be
committed by internal or external parties through
sending sms and emails to various approved
supervisors
Generation of unique control number for payment:
IDRAS 1st Stage IFB 2015
Bidder: <insert bidder name> IDRAS IFB Technical Responsiveness Checklist – 1st Stage Bids
Req’t
Type
(M / D)
PAY035
M
PAY036
M
PAY037
M
PAY038
M
PAY039
M
PAY040
M
PAY041
M
PAY042
M
PAY043
M
Description of Requirement
Code for Meeting
Requirement
(I, C, M, F, N)
15
Explanation for Given Code
System to generate unique reference number for each
tax payment or part there of.
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.
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.
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.
Provide assurance on availability of an effective,
adequate and reliable communication infrastructure at
24/7 guarantee.
The solution should provide real-time updating of
accounts and taxpayers’ ledgers.
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 .
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.
The solution should provide automated facility to
match Tax payments captured into the system with
tax assessments raised in the Tax Administration
Systems.
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
IDRAS 1st Stage IFB 2015
Bidder: <insert bidder name> IDRAS IFB Technical Responsiveness Checklist – 1st Stage Bids
Req’t
Type
(M / D)
PAY044
M
PAY045
M
PAY046
M
PAY047
M
PAY048
M
Description of Requirement
Code for Meeting
Requirement
(I, C, M, F, N)
16
Explanation for Given Code

Statement of Tax arrears and other outstandings

Statement of Tax objections

Statement of Tax appeals
The system should facilitate provision of schedules to
summary reports and statements.
Registration and validation functionality; to validate
the data that makes up a message/ instruction be
accepted and registered by the revenue accounting
module according to specified pre-agreed business
rules.
The system should be able to electronically record
“Tax stood over” information from tax objections into
the envisaged Accounting module and update
Taxpayers profile. The information should include the
objected amounts and related penalties, interest and
any other future dues as a result of this objection.
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.
The system should be the main tax revenue reporting
engine and therefore perform a unified revenue
accounting function facilitated by integration with all
collection systems like, Central Motor Vehicle
Registration 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 selected period.
IDRAS 1st Stage IFB 2015
Bidder: <insert bidder name> IDRAS IFB Technical Responsiveness Checklist – 1st Stage Bids
Req’t
PAY049
PAY050
Type
(M / D)
M
Description of Requirement
Code for Meeting
Requirement
(I, C, M, F, N)
17
Explanation for Given Code
Accounting information from other systems shall be
extracted through developed interfaces so that
Taxpayer 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 account position.
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.
IDRAS 1st Stage IFB 2015
Bidder: <insert bidder name> IDRAS IFB Technical Responsiveness Checklist – 1st Stage Bids
Req’t
Type
(M / D)
Description of Requirement
Code for Meeting
Requirement
(I, C, M, F, N)
18
Explanation for Given Code
Refunds Processing (RFD)
RFD001
M
RFD002
M
RFD003
M
RFD004
M
RFD005
M
RFD006
M
RFD007
M
Refund Processing: Provide an adequate support for
refund processing. The system shall process refunds
automatically using workflow management.
The system shall support the classification of
taxpayers in Gold, Silver and Non-Gold-Silver.
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.
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
The system should be able to inform the taxpayer on
the change of category where business rules permit.
The system should be able to generate a Tax
Compliance Analysis Report periodically showing the
following information:
a. S/N
b. TIN
c. Name of taxpayer
d. Nature of business
e. Tax type
f. Number of returns filed in time
g. Correctness of return declaration
h. Frequency in making timely payments in a
year
i.
Audit report findings
The system shall provide a Refund/ Repayment Data
Capturing Interface having the following information:
a) TIN
b) VRN
IDRAS 1st Stage IFB 2015
Bidder: <insert bidder name> IDRAS IFB Technical Responsiveness Checklist – 1st Stage Bids
Req’t
Type
(M / D)
Description of Requirement
Code for Meeting
Requirement
(I, C, M, F, N)
19
Explanation for Given Code
c)
d)
e)
f)
g)
h)
i)
j)
k)
l)
m)
n)
o)
RFD008
M
RFD009
M
RFD010
M
RFD011
M
RFD012
M
RFD013
M
RFD014
M
RFD015
M
RFD016
M
Name of Taxpayer
Category of Taxpayer
Bank Account No.
Bank/Branch
Date of lodging the claim
Period covered by the claim
Tax type
Amount claimed
Amount approved
Date of approval
Amount paid
Date of payment
Approving
Authority
(Regional
Manager/Manager
Technical
Service/Revenue
Commissioner/Refund
Committee/Commissioner General). The
system should provide distinctive rights for
each approving authority
The System shall provide an electronic link with TRA
expenditure system allowing payment updates in
taxpayer’s account.
The system should be able to keep an electronic diary
showing particulars and status of refund application.
The system must be able to capture trends of Refund
performance parameters and report against the
parameters.
The system must be able to capture escalation
procedures and by making use of workflow escalate
the procedure to the next higher hierarchical level.
Depending on their security profile, the system
should enable users to access the system at all levels.
The system shall provide an audit trail
The system should have a link with audit and debt
management modules.
The system should be able to track taxpayers due for
audit and those with tax liabilities.
The system should be able to produce the following
reports by Region and Department
a) List of all refund claims
b) List of refund claim by category (gold, silver,
IDRAS 1st Stage IFB 2015
Bidder: <insert bidder name> IDRAS IFB Technical Responsiveness Checklist – 1st Stage Bids
Req’t
Type
(M / D)
Description of Requirement
Code for Meeting
Requirement
(I, C, M, F, N)
20
Explanation for Given Code
non-gold-silver)
List of refund claim by tax type-sector
List of approved refund by category
List of approved refund by tax type sector
List of refund paid by category, tax type,
sector
g) List of unpaid refund claims age wise by days
h) List disapproved refund claims by category
i) Monthly Refund/Repayment Report
j) Monthly Report on outstanding
refund/repayment claims/age analysis
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) TIN
c) Name of the consultant
d) Premises of business,
e) Year of consultancy,
f) Status of the Tax consultant (active/nonactive)
Refunding of Tax Paid by Exempt Organizations:
Provide the capability for refunds to be generated for
tax erroneously paid by exempt organizations.
Track Users Initiating Refund: Provide the capability
for recording the user who initiated refund request.
Update Accounts with Refund Information:
Automatically update taxpayers’ accounts upon
effecting tax refunds.
Calculate Interest for Refunds: Calculate refund
interest using varying rates depending on tax type and
tax period.
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.
Pre- and Post-Refund Support: Support pre-audit
refund and post audit refund.
Refunds to Offset Other Liabilities: The system must
c)
d)
e)
f)
RFD017
M
RFD018
M
RFD019
M
RFD020
M
RFD021
M
RFD022
M
RFD023
M
RFD024
M
IDRAS 1st Stage IFB 2015
Bidder: <insert bidder name> IDRAS IFB Technical Responsiveness Checklist – 1st Stage Bids
Req’t
Type
(M / D)
RFD025
M
RFD026
M
RFD027
M
RFD028
M
RFD29
M
Description of Requirement
Code for Meeting
Requirement
(I, C, M, F, N)
21
Explanation for Given Code
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.
Installment Payment of Refunds: Provide the ability to
pay refund claims by installments.
Tracking Decisions on Refunds: The System MUST
store and change the decision of granting tax refund.
Retrieving Refund Information: The System MUST be
able to view, search, print and summarize all refund
information.
Refund Reference Numbers: The System MUST be
able to process each tax refund request and generate
corresponding responses with a unique reference
number.
Refund History: The System MUST be able to store all
documents related to refunds
IDRAS 1st Stage IFB 2015
Bidder: <insert bidder name> IDRAS IFB Technical Responsiveness Checklist – 1st Stage Bids
Req’t
Type
(M / D)
Description of Requirement
Code for Meeting
Requirement
(I, C, M, F, N)
22
Explanation for Given Code
Revenue Accounting (RVA)
RVA001
M
RVA002
M
RVA003
M
RVA004
M
RVA005
M
RVA006
M
RVA007
M
RVA008
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.
System monitoring processes to provide facilities to
allow various financial alerts and notifications in the
form of SMS, emails, on-screen messages and calls
according to the leading practice
Notes: Refer PAY040.
Provide assurance on availability an effective,
adequate and reliable communication infrastructure
at 24/7 guarantee.
Notes: Refer PAY041.
The solution should provide real-time updating of
accounts and taxpayers’ ledgers.
Notes: Refer PAY042.
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 and
IFRS.
Notes: Refer PAY043.
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.
Notes: Refer PAY044.
The solution should be provide automated facility to
match Tax payments captured into the system with
tax assessments raised in the Tax Administration
Systems.
Notes: Refer PAY045.
System be capable of producing accounting required
basic reports and records for quick decision making
like;

Performs reconciliation of revenues per
accounts maintained,

Maintain chart of accounts to identify collection
IDRAS 1st Stage IFB 2015
Bidder: <insert bidder name> IDRAS IFB Technical Responsiveness Checklist – 1st Stage Bids
Req’t
Type
(M / D)
Description of Requirement
Code for Meeting
Requirement
(I, C, M, F, N)
23
Explanation for Given Code
items and structure of posting accounts.
Generates Cash Books, Books of Accounts,
General Ledger and Final Accounts

Prepares Revenue Executive Summary

Prepares Management Information Reports

Prepares Country Tax Revenue collection
Statements daily, weekly and monthly.
The solution should be capable of providing annual
revenue Statements by a click of a button without
further manipulations so as to include;

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.
The system should facilitate provision of schedules to
summary reports and statements.
Notes: Refer PAY047.
Registration and validation functionality to validate
the data that makes up a message/ instruction be
accepted and registered by the revenue accounting
module according to specified pre-agreed business
rules.
Notes: Refer PAY048.
Tax stood over records: The system should be able to
electronically record “Tax stood over” information
from tax objections into the envisaged Accounting
Solution.
Notes: Refer PAY049.
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.
The system should be the main tax revenue reporting
engine and therefore perform a unified revenue
accounting function facilitated by integration with all

RVA009
M
RVA010
M
RVA011
M
RVA012
M
RVA013
M
RVA014
M
IDRAS 1st Stage IFB 2015
Bidder: <insert bidder name> IDRAS IFB Technical Responsiveness Checklist – 1st Stage Bids
Req’t
Type
(M / D)
RVA015
M
RVA016
M
Description of Requirement
Code for Meeting
Requirement
(I, C, M, F, N)
24
Explanation for Given Code
collection systems like New Customs Management
System in each of the revenue accounting processes
Notes: Refer PAY051.
Monitoring of Transfers: The system should monitor
electronically monthly transfers from Commissioners’
revenue accounts at commercial banks and BOT to
PMG account at BOT.
GFS codes: The new system should match latest
Government Financial statics (GFS) codes as issued by
IMF to the types of taxes collected for better reporting
of government revenues.
IDRAS 1st Stage IFB 2015
Bidder: <insert bidder name> IDRAS IFB Technical Responsiveness Checklist – 1st Stage Bids
Req’t
Type
(M / D)
Description of Requirement
Code for Meeting
Requirement
(I, C, M, F, N)
25
Explanation for Given Code
Tax Audit (AUD)
AUD001
M
AUD002
M
AUD003
M
Audit Management Information: The system must
provide solution for monitoring tax audit cases
countrywide.
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 type
2. Tax payment levels
3. Sales levels
4. Income levels
5. Comparison of common items and/or trends
across business groups.
6. Comparison of common items or trends between
taxpayers in business classes that are alike
7. Comparison of common deductions between
taxpayers
8. Previous tax payment amounts adjusted for
audited amounts as compared to current tax
payments
9. Taxpayer’s compliance
10. Multinational companies: Branches and
subsidiaries
Notes: 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
Record Audit Activity: Assign cases and allow audit
groups and/or individuals to record activity on cases,
IDRAS 1st Stage IFB 2015
Bidder: <insert bidder name> IDRAS IFB Technical Responsiveness Checklist – 1st Stage Bids
Req’t
Type
(M / D)
AUD004
M
AUD005
M
AUD006
M
AUD007
M
AUD008
M
AUD009
M
AUD010
M
AUD011
M
AUD012
M
AUD013
M
Description of Requirement
Code for Meeting
Requirement
(I, C, M, F, N)
26
Explanation for Given Code
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.
Update Audit Case Information: Automatically update
audit case information when new taxpayer profile
information is added.
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.
Upload Audit Information: Provide the capability to
upload audit information directly into the system.
Support Audit Activity: Provide adequate support for
the audit cycle, risk profiling, and audit case selection
and preparation.
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.
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.
Auditing Support: Support Risk Profiling, Annual Audit
Business Planning, and Scheduling of Audit.
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
Rotation of Auditors: Support the rotation of auditors
and audit cases. No auditor shall audit the same case
after two consecutive audits.
Audit Case Support: Support all of the following:
1. Selection of audit cases based on risk ratio
IDRAS 1st Stage IFB 2015
Bidder: <insert bidder name> IDRAS IFB Technical Responsiveness Checklist – 1st Stage Bids
Req’t
Type
(M / D)
AUD014
M
AUD015
M
AUD016
M
AUD017
M
AUD018
M
AUD019
M
AUD020
M
AUD021
M
AUD022
M
AUD023
M
Description of Requirement
Code for Meeting
Requirement
(I, C, M, F, N)
27
Explanation for Given Code
2. Generation of the Audit Business Plan
3. Notification of the taxpayer
4. Generation of the Case Audit Plan, Audit
Timesheet/Management Reports, Monthly
Report of Audit Results, Narrative Audit Report,
and Audit Results Report.
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.
Identifying Tax Frauds: The system shall have an
algorithm that helps identifying tax frauds for referral
purposes.
Logging Audit Status: Log the status of a tax account
under audit.
Links to Previous Audit Findings: Support linkage and
comparison with previous audit findings.
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.
Reporting Search Results of Applying the Selection
Criteria: The System must be able to report the results
of applying selection criteria for audits.
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.
Audit Plans: The System must support an authorized
user to develop or change a monthly and/or annual
plan of audit.
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.
Random Selection of Taxpayers for Audit: The System
MUST provide for the random selection of Taxpayers
on a periodic basis.
IDRAS 1st Stage IFB 2015
Bidder: <insert bidder name> IDRAS IFB Technical Responsiveness Checklist – 1st Stage Bids
Req’t
Type
(M / D)
Description of Requirement
AUD024
M
AUD025
M
AUD026
D
AUD027
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
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.).
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.
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.
Code for Meeting
Requirement
(I, C, M, F, N)
28
Explanation for Given Code
IDRAS 1st Stage IFB 2015
Bidder: <insert bidder name> IDRAS IFB Technical Responsiveness Checklist – 1st Stage Bids
Req’t
Type
(M / D)
Description of Requirement
Code for Meeting
Requirement
(I, C, M, F, N)
29
Explanation for Given Code
Tax Investigations (INV)
INV001
M
INV002
M
INV003
M
INV004
M
INV005
M
INV006
M
INV007
M
INV008
M
INV009
M
Criminal Investigation Management Information: The
system must provide solution for monitoring criminal
investigation cases countrywide.
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.
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.
Case selection: The solution must have
algorithm/parameters that helps identifying cases with
indicators of tax fraud.
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.
Random Selection of Taxpayers for Investigation: The
System MUST provide for the random selection of
Taxpayers on a periodic basis.
Reporting Search Results of Applying the Selection
Criteria: The System must be able to report the results
of applying selection criteria for investigations.
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).
Investigation of Income Sources: Support the
investigation of taxpayer sources of income, assets,
IDRAS 1st Stage IFB 2015
Bidder: <insert bidder name> IDRAS IFB Technical Responsiveness Checklist – 1st Stage Bids
Req’t
Type
(M / D)
INV010
M
INV011
M
INV012
M
INV013
M
INV014
M
INV015
M
INV016
INV017
M
Description of Requirement
Code for Meeting
Requirement
(I, C, M, F, N)
30
Explanation for Given Code
and third party sources and data.
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.
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.
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.
Review and evaluation of allegations: Provide facility
for investigators to input information in respect of
reviewing, evaluating assigned cases and determine if
the criminal tax fraud may have occurred.
Report transmission: Provide a solution for online
transmission of reports to Supervisor, and Reviewer.
The system should provide a mechanism for
providing feedback to Primary Investigators,
Supervisor and Reviewer.
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.
Approval for Investigation initiation: Provide facility
IDRAS 1st Stage IFB 2015
Bidder: <insert bidder name> IDRAS IFB Technical Responsiveness Checklist – 1st Stage Bids
Req’t
Type
(M / D)
INV018
M
INV019
M
INV020
M
INV021
M
INV022
M
INV023
M
INV024
M
INV025
M
INV026
M
INV027
M
Description of Requirement
Code for Meeting
Requirement
(I, C, M, F, N)
31
Explanation for Given Code
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.
Investigation reference number: the system must
have capability of generating an investigation number
automatically after the approval to initiate
investigation is granted.
Investigation activities: the solution must provide a
facility for recording investigation activities from the
initiation stage to closure.
Time consumption sheet: The system must have a
capability to monitor time spent by each investigator
in a specific investigation case.
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.
Specific Method of investigation: the system must
provide algorithm/parameter for computing tax
evaded under specific method of investigations i.e. Net
worth method, expenditure approach method, bank
deposit method
Tracking the Status of the case: The system should
provide a mechanism to track status of the case using
the investigation initiation number
Search seizure: provide facility recording assets,
equipment and documents seized.
Recording evidence: the solution must provide facility
for recording/scanning tax fraud evidentiary
documents seized by investigators
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.
Additional Forensic Evidence: Provide facility for
recording and numbering assets or equipment
involved and type of evidence/information collected
IDRAS 1st Stage IFB 2015
Bidder: <insert bidder name> IDRAS IFB Technical Responsiveness Checklist – 1st Stage Bids
Req’t
Type
(M / D)
Description of Requirement
INV028
M
INV029
M
INV030
M
INV031
M
INV032
M
INV033
M
INV034
M
INV035
M
INV036
M
INV037
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.
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.
Transfer Tax Investigation Cases: Provide facility for
approving the transfer of Investigation cases from one
zonal office to another.
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.
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.
Referral for Prosecution: provide mechanism of
referring cases to legal department for prosecution.
Prosecutor: the system should provide facility to track
down prosecutor handling the case.
Court Decision: the facility must provide
communication channel to provide feedback on court
decision.
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.
Printing, Viewing and Searching of Taxpayers to be
Investigated: The System must be able to print, view
Code for Meeting
Requirement
(I, C, M, F, N)
32
Explanation for Given Code
IDRAS 1st Stage IFB 2015
Bidder: <insert bidder name> IDRAS IFB Technical Responsiveness Checklist – 1st Stage Bids
Req’t
INV038
Type
(M / D)
M
Description of Requirement
Code for Meeting
Requirement
(I, C, M, F, N)
33
Explanation for Given Code
and allocate the number of taxpayers to be
investigated or under-investigation.
Electronic Archiving: Provide electronic archiving of
investigation documents.
IDRAS 1st Stage IFB 2015
Bidder: <insert bidder name> IDRAS IFB Technical Responsiveness Checklist – 1st Stage Bids
Req’t
Type
(M / D)
Description of Requirement
Code for Meeting
Requirement
(I, C, M, F, N)
34
Explanation for Given Code
Collection of Delinquent Accounts/Enforced Collection (COL)
COL001
M
COL002
M
COL003
M
COL004
M
COL005
M
COL006
M
COL007
M
COL008
M
COL009
D
COL010
M
COL011
M
COL012
M
COL013
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.
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.
Track Delinquent Tax Returns: Record delinquent tax
returns and all amounts due
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.
Reasons for Non-Payment: Record the reasons for
non-payment.
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.
Reconciliation of Payments: Support the reconciliation
of payments including partial payments with
assessment debits.
Determine Collectability of Liability: Determine if a
tax liability is collectible with reasons based on specific
set parameters.
Identify Cases to Pursue: Identify cases to be pursued
legally based on case risk level and case materiality.
Impose Penalties: Automatically impose penalties on
unpaid taxes.
Compute Late Payer Interest and Penalties:
Automatically compute interest and penalties for late
payers.
Posting of Non-Payers’ Penalties and Interest Due:
Support loading of Penalty and Interest to a non-payer
taxpayer’s account.
Collection Payment Plans: The System MUST provide
ability to set up, maintain a payment plan for
IDRAS 1st Stage IFB 2015
Bidder: <insert bidder name> IDRAS IFB Technical Responsiveness Checklist – 1st Stage Bids
Req’t
Type
(M / D)
COL014
M
COL015
M
COL016
D
COL017
M
COL018
M
COL019
M
COL020
M
Description of Requirement
Code for Meeting
Requirement
(I, C, M, F, N)
35
Explanation for Given Code
taxpayers and provide alert mechanism.
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.
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.
Monitor Taxes Due: Monitor taxes due, support
enforcement (e.g., reminder letter, demand letter),
and report on taxes overdue/arrears.
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.
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
Release Hold on Collection: Provide the capability for
a user to release a “hold” that was previously placed
on an account.
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
IDRAS 1st Stage IFB 2015
Bidder: <insert bidder name> IDRAS IFB Technical Responsiveness Checklist – 1st Stage Bids
Req’t
Type
(M / D)
COL021
M
COL022
M
COL023
M
COL024
M
COL025
M
Description of Requirement
Code for Meeting
Requirement
(I, C, M, F, N)
36
Explanation for Given Code
only minimal attention whereas the more experienced
staff can then concentrate on more difficult taxpayers
and enforcement.
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.
Tracking Non-Payment and Stop Payments: The
System must provide the ability to view and sort nonpayments and stop-payments by tax type and taxpayer
group and amount and date.
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.
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 reliably
Payment plan arrangement may be changed
depending on the situation.
Monitoring Payment Plans: The System MUST
IDRAS 1st Stage IFB 2015
Bidder: <insert bidder name> IDRAS IFB Technical Responsiveness Checklist – 1st Stage Bids
Req’t
Type
(M / D)
COL026
M
COL027
M
COL028
M
COL029
M
COL030
M
COL031
M
COL032
M
Description of Requirement
Code for Meeting
Requirement
(I, C, M, F, N)
37
Explanation for Given Code
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
date
Tax not paid during above stated period shall be
deemed as delinquent taxes and subject to
enforcement action
Criminal Act Notices: Capture and process criminal act
notices received from various processes, including
court rulings.
Rules for Processing Overdue Accounts: The System
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.
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.
Track Recovery/Enforcement: Track and monitor
recovery and enforcements tasks.
Double Enforcement Tasks: Initiate double
enforcement tasks simultaneously.
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.
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
IDRAS 1st Stage IFB 2015
Bidder: <insert bidder name> IDRAS IFB Technical Responsiveness Checklist – 1st Stage Bids
Req’t
Type
(M / D)
COL033
M
COL034
M
COL035
M
COL036
M
COL037
M
COL038
M
COL039
M
Description of Requirement
Code for Meeting
Requirement
(I, C, M, F, N)
38
Explanation for Given Code
distraint and expected date of auction.
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.
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.
Release of seized goods: the system must provide
capability to automatically process release of seized
goods where tax is paid before their auctioning.
Recovery of tax from tax debtor: provide the
capability to automatically recover tax from tax debtor
including instituting suit for unpaid tax.
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.
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 outflowing transaction.
Upon receiving an official letter for cancellation
of “notification letter/banks” sent by tax office,
the bank action shall be terminated.
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
IDRAS 1st Stage IFB 2015
Bidder: <insert bidder name> IDRAS IFB Technical Responsiveness Checklist – 1st Stage Bids
Req’t
Type
(M / D)
COL040
M
COL041
M
COL042
M
COL043
M
COL044
M
Description of Requirement
Code for Meeting
Requirement
(I, C, M, F, N)
39
Explanation for Given Code
which the Commissioner has registered interest for
non-payment of taxes.
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.
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
continue to be delinquent.
Bankruptcy Proof of Claim: Produce a Bankruptcy
Proof of Claim and applicable exhibits with interest
computed to an applicable date.
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.
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.
IDRAS 1st Stage IFB 2015
Bidder: <insert bidder name> IDRAS IFB Technical Responsiveness Checklist – 1st Stage Bids
Req’t
Type
(M / D)
Description of Requirement
Code for Meeting
Requirement
(I, C, M, F, N)
40
Explanation for Given Code
Appeal Management (APM)
APM001
M
APM002
M
APM003
M
APM004
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.
“Tax Stood Over” Information Capture: Electronically
capture “Tax stood over” information from tax
objections and tag this information to the Taxpayer
account.
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
which are under objections
Support Objection Processes: Support all of the
following objection processes:
1. Receiving new objections
2. 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 panel
6. Preparing settlement of objections
7. Prepare analysis of objections by age, value,
complexity, category, tax type, sector
8. 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,
IDRAS 1st Stage IFB 2015
Bidder: <insert bidder name> IDRAS IFB Technical Responsiveness Checklist – 1st Stage Bids
Req’t
Type
(M / D)
APM005
M
APM006
M
Description of Requirement
Code for Meeting
Requirement
(I, C, M, F, N)
41
Explanation for Given Code
preparing pre-hearing, and preparing appeals
resolution
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).
Electronic Archiving: Provide electronic archiving of
objections and appeal documents.
IDRAS 1st Stage IFB 2015
Bidder: <insert bidder name> IDRAS IFB Technical Responsiveness Checklist – 1st Stage Bids
Req’t
Type
(M / D)
Description of Requirement
Code for Meeting
Requirement
(I, C, M, F, N)
42
Explanation for Given Code
Taxpayer Services: Customer Feedback Management (CFM)
CFM001
M
CFM002
M
CFM003
M
CFM004
M
CFM005
M
Allow taxpayers to register complaints, enquiries and
comments through multiple channels including social
media
Make the system to capture and analyze the
taxpayers complaints, enquiries and comments
automatically
Reports: The system to generate daily, weekly,
monthly quarterly and annually reports of taxpayers’
feedback
Taxpayer’s education: Support online provision of tax
education to taxpayers
Customer Relationship Management System (CRMS):
Provide interface/link with CRMS which is currently in
operation at the TRA Call Centre
IDRAS 1st Stage IFB 2015
Bidder: <insert bidder name> IDRAS IFB Technical Responsiveness Checklist – 1st Stage Bids
Req’t
Type
(M / D)
Description of Requirement
Code for Meeting
Requirement
(I, C, M, F, N)
43
Explanation for Given Code
Case Management and Tracking (CSE)
CSE001
M
CSE002
M
CSE003
M
CSE004
M
CSE005
M
CSE006
M
CSE007
M
CSE008
M
Support for All Functional Areas: Support all of the
following processes:
1. Registration (TIN)
2. Returns capturing
3. Tax assessments
4. Tax collection
5. Accounting
6. Audit
7. Debt management
8. Reporting
9. Objections and appeals
10. Refunds for all domestic taxes and levies
11. Non tax Revenue collections
Links to Other Components: Enable the linking of
objects/components from different applications. Efiling of returns and e-payments using mobile phones
and other various channels
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.)
Setup Roles and Responsibilities: Setup roles and
responsibilities appropriately based on the job
description of the staff users.
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.
Process for Editing Transactions: Support change
management process for editing approved
transactions.
Business Rules: Enforce all business rules into the
system to ensure that all transactions are
appropriately checked and authorized before being
committed.
“Pulling” of Work Items: Allow users to “pull”
unassigned work items.
IDRAS 1st Stage IFB 2015
Bidder: <insert bidder name> IDRAS IFB Technical Responsiveness Checklist – 1st Stage Bids
Req’t
Type
(M / D)
Description of Requirement
CSE009
M
CSE010
M
Push of Work Items: Allow supervisors to “push” work
items.
Priorities: Assign priorities to work items in workflows.
CSE011
M
CSE012
M
CSE013
M
CSE014
M
CSE015
M
CSE015
M
CSE015
M
Code for Meeting
Requirement
(I, C, M, F, N)
44
Explanation for Given Code
Auto Increment of Priorities: Automatically increment
priorities of “un-pulled” work items over time.
On-demand Increment of Priorities: Increment
priorities of work items on an as-needed basis.
Expedite Business Processes: Expedite a business
process from beginning to end on an emergency basis.
Deadlines: Provide the capability to allow a user to
place a deadline for completing a process.
Transfer of Work Items: Provide the capability to allow
a user to transfer assigned work items.
Assignment of Work Item: Provide the capability for a
user to directly assign a work item to a specific user.
Adjustment of Workloads: Provides the capability for
users to allow adjustments to workloads to correct
out-of-balance conditions.
IDRAS 1st Stage IFB 2015
Bidder: <insert bidder name> IDRAS IFB Technical Responsiveness Checklist – 1st Stage Bids
Req’t
Type
(M / D)
Description of Requirement
Code for Meeting
Requirement
(I, C, M, F, N)
45
Explanation for Given Code
VAT Relief Processing (VREL)
VRL 001
M
VRL 002
M
VRL 003
M
VRL 004
M
VRL 005
M
VRL 006
M
VRL 007
M
VRL 008
M
VRL 009
M
VRL 010
M
Provide support for VAT relief processing: The system
should be able provide an adequate support for VAT
relief processing.
VAT Relief Work Flow Management: The system
should be able to process VAT relief application using
Work Flow Management.
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.
Track Users Initiating VAT relief: The system should be
able to record the user who initiated VAT relief date
and approvers
Evaluate risk of VAT relief application: Evaluate VAT
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
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.
Retrieve VAT relief information: The system must be
able to view, search, print and summaries all vat relief
information.
Tracking decision on VAT relief: The system must
store and change the decision of granting relief and
notify the taxpayers of the decision.
Update VAT relief information: Automatically provide
information on items, estimated values and supplier of
the items or service.
Relief History: The system must be able to store all
documents related to VAT relief.
IDRAS 1st Stage IFB 2015
Bidder: <insert bidder name> IDRAS IFB Technical Responsiveness Checklist – 1st Stage Bids
Req’t
Type
(M / D)
Description of Requirement
Code for Meeting
Requirement
(I, C, M, F, N)
46
Explanation for Given Code
Interfacing and Integration (I&I)
I&I001
M
I&I002
M
I&I003
M
I&I004
M
I&I005
M
I&I006
M
I&I007
M
I&I008
M
I&I009
M
I&I009
M
Electronic Interface with BRELA: Provide an electronic
data exchange interface with the business registration
system at the BRELA.
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.
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.
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
among these systems.
Integrate with Revenue Accounting: Integrate with
revenue accounting, the ERP systems, and other
government agencies which collect other fees, levies,
and licenses.
Bank Revenue Collection: Allow configuration to work
with TaxBank client for banks, for revenue collection.
Data Exchange: Implement a data exchange capability
between TISS/Revenue Gateway and revenue
administration systems at the TRA.
Existing Data in Database: Either work with the
existing database or migrate existing data to the new
system’s database.
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
Interfaces with Applications: Interface with a number
of applications/systems that have been implemented
to support various processes in the TRA, including all
IDRAS 1st Stage IFB 2015
Bidder: <insert bidder name> IDRAS IFB Technical Responsiveness Checklist – 1st Stage Bids
Req’t
I&I010
Type
(M / D)
M
Description of Requirement
Code for Meeting
Requirement
(I, C, M, F, N)
47
Explanation for Given Code
of the following:
1. CMVRS and CDLS
2. New Customs System -TANCIS
3. Mobile Phone
4. Revenue accounting system
5. Banking systems operated by various
banking institutions
6. Data warehouse system
7. EFD Management software
8. Financial systems
9. TRA Revenue Gateway System (RGS)
10. A Monitoring and Evaluation Database
(TRAMED)
11. SMS gateway
12. Automatic
Fingerprint
Identification
System (AFIS) (Used for Taxpayer’s
registration)
13. Geographical Information System (GIS)
14. Other relevant system
The system shall be capable of interfacing using
international open standard protocols.
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 distribution
2. New Customs System
3. Mobile Phone
4. Revenue accounting system
5. Banking systems operated by various
banking institutions
6. Data warehouse system
7. EFD Management software
8. Financial systems
9. TRA Monitoring and Evaluation Database
(TRAMED)
10. TRA Revenue Gateway System (RGS)
11. SMS gateway
12. Automatic Fingerprint Identification
System (AFIS) (Used for Taxpayer’s
IDRAS 1st Stage IFB 2015
Bidder: <insert bidder name> IDRAS IFB Technical Responsiveness Checklist – 1st Stage Bids
Req’t
Type
(M / D)
I&I011
M
I&I012
M
I&I013
M
I&I014
M
I&I015
M
I&I016
M
I&I017
M
Description of Requirement
Code for Meeting
Requirement
(I, C, M, F, N)
48
Explanation for Given Code
registration)
13. Geographical Information System (GIS)
14. Other relevant systems
The system shall be capable of interfacing using
international open standard protocols.
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 distribution
2. General ledger accounting
3. Funds management
4. Fiscal reporting to legislative bodies and the
public
Recording of Payments by TISS/Revenue Gateway:
Allow automatic/manual recording and loading
payments by TISS/Revenue Gateway and reconcile
them automatically.
Transfer/Exchange Data: Transfer/Exchange data
electronically with governmental and nongovernmental institutions (e-government).
Bank Interface: Interface with banks to enable banks
to provide payment data in electronic form according
to a specific format.
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.
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.
GIS Integration: The system shall be able to integrate
with Geographic Information System (GIS) to allow
capturing in detail the taxpayers location information.
IDRAS 1st Stage IFB 2015
Bidder: <insert bidder name> IDRAS IFB Technical Responsiveness Checklist – 1st Stage Bids
Req’t
Type
(M / D)
Description of Requirement
Code for Meeting
Requirement
(I, C, M, F, N)
49
Explanation for Given Code
Forms Definition (FRM)
FRM001
M
FRM002
M
FRM003
M
FRM004
M
FRM005
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 postposting 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.)
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).
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.
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.
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).
IDRAS 1st Stage IFB 2015
Bidder: <insert bidder name> IDRAS IFB Technical Responsiveness Checklist – 1st Stage Bids
Req’t
Type
(M / D)
Description of Requirement
Code for Meeting
Requirement
(I, C, M, F, N)
50
Explanation for Given Code
Taxpayer Notices (NTC)
NTC001
M
NTC002
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

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.
Templates for Standard Notices: The System MUST
provide templates for standard notices such as those
listed.
Notes: Bidders should describe how the addition
IDRAS 1st Stage IFB 2015
Bidder: <insert bidder name> IDRAS IFB Technical Responsiveness Checklist – 1st Stage Bids
Req’t
Type
(M / D)
NTC003
M
NTC004
M
NTC005
M
NTC006
M
Description of Requirement
Code for Meeting
Requirement
(I, C, M, F, N)
51
Explanation for Given Code
of new notices is done in their proposed IDRAS
solution.
Authorized User Support for Notice Definition: The
System MUST allow the authorized users to define
new templates and notices using the notice generation
E-mail Support for Notices: The System MUST be able
to send notices to taxpayers by e-mail.
Mobile support for Notices: The System MUST be able
to send notices to taxpayers by SMS or mobile apps.
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).
IDRAS 1st Stage IFB 2015
Bidder: <insert bidder name> IDRAS IFB Technical Responsiveness Checklist – 1st Stage Bids
Req’t
Type
(M / D)
Description of Requirement
Code for Meeting
Requirement
(I, C, M, F, N)
52
Explanation for Given Code
Reports (RPT)
RPT001
M
RPT002
M
RPT003
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)
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
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).
IDRAS 1st Stage IFB 2015
Bidder: <insert bidder name> IDRAS IFB Technical Responsiveness Checklist – 1st Stage Bids
Req’t
Type
(M / D)
RPT004
D
RPT005
M
Description of Requirement
Code for Meeting
Requirement
(I, C, M, F, N)
53
Explanation for Given Code
Notes: Bidders must describe details about the
report generator and demonstrate that it is userfriendly. 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).
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
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 1st Stage IFB 2015
Bidder: <insert bidder name> IDRAS IFB Technical Responsiveness Checklist – 1st Stage Bids
Req’t
Type
(M / D)
Description of Requirement
Code for Meeting
Requirement
(I, C, M, F, N)
54
Explanation for Given Code
IDRAS Configuration and Customization (CNC)
CNC001
M
CNC 002
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.
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 IDRAS
TRA’s ability to
Implement new taxes and non-taxes under IDRAS
Modify IDRAS to support changing relevant laws,
decrees, procedures and forms
Flexible report generator (add or modify report
formats)
Change/reconfiguration of workflows by business
staff and business rules without need of system
coding
In-built reconfigurable change management workflow
to manage the transaction or data/information
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 future
Provision of Source code
Configuration 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
IDRAS 1st Stage IFB 2015
Bidder: <insert bidder name> IDRAS IFB Technical Responsiveness Checklist – 1st Stage Bids
Req’t
Type
(M / D)
CNC003
M
CNC004
M
Description of Requirement
Code for Meeting
Requirement
(I, C, M, F, N)
55
Explanation for Given Code
the system
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).
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’.
IDRAS 1st Stage IFB 2015
Bidder: <insert bidder name> IDRAS IFB Technical Responsiveness Checklist – 1st Stage Bids
Req’t
Type
(M / D)
Description of Requirement
Code for Meeting
Requirement
(I, C, M, F, N)
56
Explanation for Given Code
E-Services (ESV)
ESV001
M
ESV002
M
ESV003
M
ESV004
M
ESV005
M
ESV006
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.
Deregistration Historical Records: Keep historical
records for de-registered taxpayers.
Taxpayer Access: Grant taxpayers access to the TRA
Web Portal upon successful authentication.
Online Refund Requests: Accept online refund claims
as part of online tax returns filing.
Online Tax Calculator: Provide an online tax calculator.
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
IDRAS 1st Stage IFB 2015
Bidder: <insert bidder name> IDRAS IFB Technical Responsiveness Checklist – 1st Stage Bids
Req’t
ESV007
Type
(M / D)
M
Description of Requirement
Code for Meeting
Requirement
(I, C, M, F, N)
57
Explanation for Given Code
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.
Filing Declarations: Allow registered taxpayers to file
tax declarations and supporting documents online as
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.
IDRAS 1st Stage IFB 2015
Bidder: <insert bidder name> IDRAS IFB Technical Responsiveness Checklist – 1st Stage Bids
Req’t
ESV008
Type
(M / D)
M
Description of Requirement
Code for Meeting
Requirement
(I, C, M, F, N)
58
Explanation for Given Code
However, they could extract the data from their
own internal system in an acceptable prescribed
format that can be uploaded through the eservices 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 largevolume upload feature.
b. Allow taxpayers to upload tax annexes
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.
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
IDRAS 1st Stage IFB 2015
Bidder: <insert bidder name> IDRAS IFB Technical Responsiveness Checklist – 1st Stage Bids
Req’t
Type
(M / D)
ESV009
M
ESV010
M
Description of Requirement
Code for Meeting
Requirement
(I, C, M, F, N)
59
Explanation for Given Code
and SMS to Taxpayers for tax payments made
and received.
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
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.
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.
IDRAS 1st Stage IFB 2015
Bidder: <insert bidder name> IDRAS IFB Technical Responsiveness Checklist – 1st Stage Bids
Req’t
Type
(M / D)
Description of Requirement
Code for Meeting
Requirement
(I, C, M, F, N)
60
Explanation for Given Code
3.
ESV011
M
ESV012
D
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.
Taxpayer Printing: Allow taxpayers to print at least the
following reports:
1. Submitted
registration
information
and
registration confirmation number
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 Taxpayer
5. Submitted new enrollment information
6. Messages sent/received, with their history
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).
IDRAS 1st Stage IFB 2015
Bidder: <insert bidder name> IDRAS IFB Technical Responsiveness Checklist – 1st Stage Bids
Req’t
Type
(M / D)
Description of Requirement
ESV013
M
ESV014
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
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.
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)
Code for Meeting
Requirement
(I, C, M, F, N)
61
Explanation for Given Code
IDRAS 1st Stage IFB 2015
Bidder: <insert bidder name> IDRAS IFB Technical Responsiveness Checklist – 1st Stage Bids
Req’t
Type
(M / D)
Description of Requirement
Code for Meeting
Requirement
(I, C, M, F, N)
62
Explanation for Given Code
2.
ESV015
M
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
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
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
IDRAS 1st Stage IFB 2015
Bidder: <insert bidder name> IDRAS IFB Technical Responsiveness Checklist – 1st Stage Bids
Req’t
Type
(M / D)
Description of Requirement
Code for Meeting
Requirement
(I, C, M, F, N)
63
Explanation for Given Code
registered in the system
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.
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 backoffice 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.
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.
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.
b.
ESV016
M
ESV017
M
IDRAS 1st Stage IFB 2015
Bidder: <insert bidder name> IDRAS IFB Technical Responsiveness Checklist – 1st Stage Bids
Req’t
Type
(M / D)
Description of Requirement
Code for Meeting
Requirement
(I, C, M, F, N)
64
Explanation for Given Code
Administration, Reporting, and Information (ARI)
ARI001
M
ARI002
M
ARI003
M
ARI004
M
ARI005
M
ARI006
M
ARI007
M
ARI008
M
ARI009
M
ARI010
M
Admin Features: Allow the creation of New User
Access, User Access Review, and User Termination
Process.
Recording Information: Record information coming
from audit results, annual risk-based systems,
additional assessment processes, and other sources
within the TRA.
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.
Validate Data: Validate captured data and ensure that
it is complete.
Local Printing: Provide for local printing of documents
at headquarters and remote locations.
Recording Notes: Provide the capability for recording
notes and/or narratives about actions taken for each
taxpayer.
Viewing & Printing Profiles: Provide the capability for
viewing and printing taxpayer profile information.
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 county
3. Business type
4. Tax type
5. Account status
6. Exceptional account entries
Search by DLN: Search for documents by a Document
Locator Number (DLN).
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
IDRAS 1st Stage IFB 2015
Bidder: <insert bidder name> IDRAS IFB Technical Responsiveness Checklist – 1st Stage Bids
Req’t
Type
(M / D)
ARI011
M
ARI012
M
ARI013
M
ARI014
M
ARI015
M
ARI016
M
ARI017
M
ARI018
M
ARI019
M
ARI020
M
ARI021
M
ARI022
M
ARI023
M
Description of Requirement
Code for Meeting
Requirement
(I, C, M, F, N)
65
Explanation for Given Code
capture.
Sector Reports: Generate reports that help calculate
sectoral indices and indicators.
User Authorization - Waivers: Recognize those users
authorized to waive penalties.
Record Waived Penalties: Record the user waiving the
penalty and the reason for the waiving it.
Review of Penalty Waivers: Using TRA business rules
for supervisors, review certain penalty waivers prior to
the waiver taking affect.
Approval of Transactions: Using TRA business rules for
supervisors, approve transactions and data entered by
users prior to posting the transactions.
Restricted Viewing – Payments: Allow specified users
to view only payment transactions for a given taxpayer
and reporting period.
Restricted Viewing – Refunds: Allow specified users to
view only refund transactions for a given taxpayer, tax
type, and reporting period.
Viewing All Transactions – Tax Type: Allow specified
users to view all transactions posted for a given
taxpayer and tax type.
Viewing All Transactions – Tax Period: Allow specified
users to view all transactions posted for a given
taxpayer, tax type, and reporting period.
View Summary Transactions: Allow specified users to
view a summary of the transactions posted for a given
taxpayer and tax type.
Lock Down Collection Transactions: Lock down
collection transactions made on periods to which their
accounting periods have been finalized and closed.
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.
Lock down Closed Accounting Period: Lock down a
closed accounting period to prevent from
unauthorized changes made on periods to which their
IDRAS 1st Stage IFB 2015
Bidder: <insert bidder name> IDRAS IFB Technical Responsiveness Checklist – 1st Stage Bids
Req’t
Type
(M / D)
ARI024
M
ARI025
M
ARI026
M
ARI027
M
ARI028
M
ARI029
M
ARI030
M
ARI031
M
ARI032
M
ARI033
M
ARI034
M
Description of Requirement
Code for Meeting
Requirement
(I, C, M, F, N)
66
Explanation for Given Code
accounting periods have been finalized and closed.
Prevent editing any information on a closed financial
period.
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.
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.
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.
Export of Information: Export information directly to
Word, Excel, Access or Text or any other agreed open
standard file formats.
Posting of Accounts Receivable: Post Accounts
Receivable in a standard format for all taxes.
Automatically generate standardized recurring followup notices for all taxes on a standardized schedule, as
determined by TRA.
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.
Logging of Activities: Generate log activities on
administrators’ activities so that periodic reviews can
be performed by internal auditors.
Reference to Physical Files: Reference taxpayers’
physical files.
Timely Updating: Update information in a timely
manner.
Back-Office Functionality: Provide full functionality for
back-office operations.
Centralized Processing: Handle centralized processing
IDRAS 1st Stage IFB 2015
Bidder: <insert bidder name> IDRAS IFB Technical Responsiveness Checklist – 1st Stage Bids
Req’t
Type
(M / D)
ARI035
M
ARI036
M
ARI037
M
ARI038
M
ARI039
M
ARI040
M
ARI041
M
ARI042
M
Description of Requirement
Code for Meeting
Requirement
(I, C, M, F, N)
67
Explanation for Given Code
of taxpayer transactions.
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.
Audit Team Statistics: Provide statistics for team
performance and overall audit progress.
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.
Record All Transactions: Record all transactions (e.g.
assessment, payment, refund) into taxpayers’
accounts.
Revenue Income Report: Report on revenue income
and monitoring procedures such as debt management.
Accounting Support: Support accrual-based
accounting: Revenue Control Account, Taxpayer
Control Account, and General Ledger.
User Access Control: Support user access and privilege
rights administration.
Parameter Support: Maintain various parameters
including all of the following:
1. Tax Types
2. Tax Rates
3. Salary Ranges
4. Targets
5. Banks and Branches
6. Region’s Parameters
7. Enforcement Parameters
8. Currency Denominators
9. Taxpayer Groups
10. GFS Codes
11. Work days and Public Holidays
12. Exchange Rates
13. Interest Rates
IDRAS 1st Stage IFB 2015
Bidder: <insert bidder name> IDRAS IFB Technical Responsiveness Checklist – 1st Stage Bids
Req’t
Type
(M / D)
ARI043
M
ARI044
M
ARI045
M
ARI046
M
ARI047
M
ARI048
M
ARI049
M
ARI050
M
ARI051
M
Description of Requirement
Code for Meeting
Requirement
(I, C, M, F, N)
68
Explanation for Given Code
14. General Ledger Posting Accounts
15. Initialize Reports
16. 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
the transaction (rather than necessarily the
transaction date).
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 match
4. Perform a phonetic name match
5. Search by address, post code, both full and
partial
6. Search by TIN
7. Search by account/charter number
Periodic Reports: Generate various statutory periodic
reports including float revenues, tax revenues, and tax
arrears.
Chart of Accounts: Maintain chart of accounts to
identify collection items and structure of posting
accounts.
Executive Summaries: Prepare Revenue Executive
Summary.
Management Information Reports: Generate
Management Information reports.
Revenue Collection Statements: Prepare Country Tax
Revenue Collection Statements.
Reporting Frequency: Determine, through the use of
TRA business rules, the proper reporting frequency for
each tax the taxpayer is responsible for.
Ad-hoc Reporting: Support ad-hoc reporting.
Period Beginning and Ending Dates: For taxpayers
reporting on four-week periods, maintain a taxpayer
supplied schedule of the beginning and ending dates
IDRAS 1st Stage IFB 2015
Bidder: <insert bidder name> IDRAS IFB Technical Responsiveness Checklist – 1st Stage Bids
Req’t
Type
(M / D)
ARI052
M
ARI053
M
ARI054
M
ARI055
M
ARI056
M
ARI057
M
ARI058
M
ARI059
M
ARI060
M
ARI061
M
ARI062
M
ARI063
M
ARI064
M
ARI065
M
Description of Requirement
Code for Meeting
Requirement
(I, C, M, F, N)
69
Explanation for Given Code
for each four-week period.
Irregular Reporting Periods: Support taxpayers with
irregular reporting requirements (e.g., seasonal
businesses).
History of Reporting Frequencies: Maintain a history
of the reporting frequencies, by tax, for each taxpayer.
This history includes the applicable dates for which the
reporting frequency was in effect
Daily Reports 1: Generate daily reports to ensure that
Accounts Receivables are in balance.
Daily Reports 2: Generate daily reports to ensure that
external data received by the tax system was recorded
as transactions within the system.
Out of Balance Reports: Generate daily reports that
identify out-of-balance conditions.
Statistics Printing: Allow users to view and print a
summary of their own production statistics.
Subordinates Production Statistics Reports: Allow
supervisors to view and print a summary of their
subordinates’ production statistics.
Arrears Periodic Reports: Generate various periodic
reports including tax arrears and float revenues.
User Access Permission Reports: Generate reports on
all access permissions per user.
Daily and Monthly Collection Reports: Generate
aggregated daily and monthly collection reports and
aggregate these monthly reports into an annual
report.
Bank Reconciliation Reports: Reconcile with bank
reports.
Customized Reports: Generate customized reports
that facilitate timely preparation of daily, monthly and
quarterly reports for the management and board.
Other Reconciliation Reports: Generate monthly
reports that reconcile with other reports from
different resources.
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.
IDRAS 1st Stage IFB 2015
Bidder: <insert bidder name> IDRAS IFB Technical Responsiveness Checklist – 1st Stage Bids
Req’t
Type
(M / D)
Description of Requirement
ARI066
M
ARI067
M
ARI068
M
ARI069
M
ARI070
M
ARI071
M
ARI072
M
ARI073
M
Reliable Taxpayers’ Account Statements: Generate
reliable taxpayers’ Statement of Account.
Specific Reports: Generate all of the following reports:
1. Non- and late filers, and non-, late-, shortpayers
2. Tax Position for every taxpayer
3. Analysis reports
4. Taxpayer trends of payment for all taxes
5. Compliance based reports
Up-to-Date Information: Provide an up-to-date
information of taxpayers’ accounts and allow all of the
following operations:
1. View all transactions
2. Sort information
3. Filter information
4. View information by tax type
5. Print Tax Positions on demand
6. Revenue accounting
Generate Reports: Generate all of the following
reports:
1. Collection reports (daily, weekly, monthly,
quarterly, yearly, or any period)
2. Executive Summary
3. Cash Accounting/Cash Book
4. Revenue Control Account
5. Taxpayer Control Account
6. Special reports on demand
7. Comparison of actual collection versus targets
8. Overdue debts/tax arrears
9. Standard report includes daily
Link Merged Businesses: Provide the capability to link
businesses that have merged to form a new entity.
Revenue Office Identification: Automatically identify
and assign the proper revenue office to each taxpayer
based on location (i.e., area, county, district, and
region).
Partner Links: Provide the capability to link Limited
Liability Companies (LLC) with the corporations and/or
individuals who are partners in the LLC.
Monitoring Taxpayer Categories: Provide a
Code for Meeting
Requirement
(I, C, M, F, N)
70
Explanation for Given Code
IDRAS 1st Stage IFB 2015
Bidder: <insert bidder name> IDRAS IFB Technical Responsiveness Checklist – 1st Stage Bids
Req’t
Type
(M / D)
ARI074
M
ARI075
M
ARI076
M
ARI077
M
ARI078
M
ARI079
M
ARI080
M
ARI081
M
ARI082
M
ARI083
M
ARI084
M
Description of Requirement
Code for Meeting
Requirement
(I, C, M, F, N)
71
Explanation for Given Code
mechanism to help monitoring taxpayers who are
eligible to graduate from one category to another.
Tracking of Rules: Provide the ability to track rules by
tax period and tax type.
Links to Related Taxpayers: Provide the capability to
link taxpayers related in a parent and subsidiary
relationship.
Link to Partners in Partnerships: Provide the capability
to link partnerships with individuals participating in the
partnership.
Tracking Business Schedule: For taxpayers reporting
irregularly, maintain a schedule of when the taxpayer
will be conducting business.
Maintain Tax Position: Provide a correct tax position
of each taxpayer, including tax arrears.
Provide a Taxpayer Account Statement: Provide a
taxpayer account statement for each taxpayer that
shows taxpayer position including tax arrears.
Electronic Capture: the ability to capture electronically
taxpayers’ returns/accounts other than VAT returns.
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.
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.
Monitor Monthly Funds Transfers: Monitor monthly
transfers from commissioners’ revenue accounts at
commercial banks and the BoT to Paymaster General
account at the BoT.
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.
IDRAS 1st Stage IFB 2015
Bidder: <insert bidder name> IDRAS IFB Technical Responsiveness Checklist – 1st Stage Bids
Req’t
Type
(M / D)
Description of Requirement
ARI085
M
ARI086
M
ARI087
M
ARI088
M
ARI089
M
ARI090
M
ARI091
M
Maintain Credible Positions: Maintain individual
taxpayer’s accounts and at any time provide credible
taxpayer account position.
Automatic Penalty Calculation: Automatically
calculate penalties on overdue taxes and update
taxpayer accounts.
Update Ledgers: Update accounting systems and
taxpayers ledger in real-time.
Central Merging of Accounting Information: Centrally
manage revenue accounting for all tax types.
Revenue Collection Reconciliation: Reconcile revenue
collection.
Consistent Information: Provide consistent
information across channels (i.e., mobile and web
applications).
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.
Code for Meeting
Requirement
(I, C, M, F, N)
72
Explanation for Given Code
IDRAS 1st Stage IFB 2015
Bidder: <insert bidder name> IDRAS IFB Technical Responsiveness Checklist – 1st Stage Bids
Req’t
Type
(M / D)
Description of Requirement
Code for Meeting
Requirement
(I, C, M, F, N)
73
Explanation for Given Code
Other IDRAS General Requirements (OTH)
OTH001
M
OTH002
M
OTH003
M
OTH004
M
OTH005
M
OTH006
M
OTH007
M
OTH008
M
OTH009
M
OTH010
M
OTH011
M
OTH012
M
User-Friendly Screens: Implement user-friendly
screens that are easy to navigate through. Ensure
users are able to intuitively reach any desired screen.
Consistent Screen Profile Information: Provide
consistent profile information on each screen.
TIN Display on Screens: Display taxpayers’ ID number
/TIN and name on each screen.
GUI Interface: Collect data from users via GUIs,
including payment transactions and transactions
adjustments.
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.
Return Review via GUI: Allow users to review via GUIs
returns containing certain data elements that exceed
tolerance levels.
Disaster Recovery Plan: Adhere to a disaster recovery
plan.
Backup: Backup data.
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.
Correspondence Types: Offer a comprehensive set of
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.
Property Rate Module: Implement a Property Rate
Module that supports Property Rate through
registration of property, billing to property owners,
and collection of revenue.
Property Rate Penalties: Implement a Property Rate
Module that supports enforcement of defaulters by
IDRAS 1st Stage IFB 2015
Bidder: <insert bidder name> IDRAS IFB Technical Responsiveness Checklist – 1st Stage Bids
Req’t
Type
(M / D)
OTH013
M
OTH014
M
Description of Requirement
Code for Meeting
Requirement
(I, C, M, F, N)
74
Explanation for Given Code
calculating the penalty, loading to property account,
and providing collection report to the Municipal
Councils.
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.
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.
IDRAS 1st Stage IFB 2015
Bidder: <insert bidder name> IDRAS IFB Technical Responsiveness Checklist – 1st Stage Bids
2
75
IFB Section VI Sub-Section C: Technical Specifications
Req’t
Type
(M / D)
Description of Requirement
Bidder’s response
Non-Functional Technical Requirements – General Technical Requirements
GTR001
M
GTR002
M
GTR003
M
GTR004
M
GTR005
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.
Dates: All information technologies MUST properly
display, calculate, and transmit date data, including,
but not restricted to 21st-Century date data.
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
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.
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 – Architecture
GTR006
M
GTR007
M
GTR008
M
GTR009
M
GTR010
M
Fully web-based and accessed using a standard
internet browser; no other application software
module is installed on the workstations.
Provide for mobile apps that might be used at least for
notification, payment or view taxpayer’s position.
Portable, lightweight, and cross-platform.
Based on the 3-tier architecture to allow
implementation of application, database and storage
both at the primary site and disaster recovery sites.
The system shall be implemented on Disaster
Recovery Site in addition to the primary site. Cold,
warm and hot configurations required, using best
IDRAS 1st Stage IFB 2015
Bidder: <insert bidder name> IDRAS IFB Technical Responsiveness Checklist – 1st Stage Bids
Req’t
GTR011
Type
(M / D)
M
Description of Requirement
76
Bidder’s response
practice, relevant Business Impact Analysis and
Disaster Recovery Plan.
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 Maintenance
GTR013
M
GTR014
M
GTR015
M
GTR016
M
GTR017
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.
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)
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
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.
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.
Maintenance and Equipment Support
IDRAS 1st Stage IFB 2015
Bidder: <insert bidder name> IDRAS IFB Technical Responsiveness Checklist – 1st Stage Bids
Req’t
GTR018a
Type
(M / D)
M
GTR018b
M
GTR018c
M
Description of Requirement
77
Bidder’s response
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.
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).
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
Security
GTR019a
M
GTR019b
M
GTR019c
M
GTR020a
M
Implement Identity Access Management that
centralizes user management
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).
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.
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
component, DBMS, Web server, etc.)
2. The application must be capable of being
IDRAS 1st Stage IFB 2015
Bidder: <insert bidder name> IDRAS IFB Technical Responsiveness Checklist – 1st Stage Bids
Req’t
Type
(M / D)
GTR021
M
GTR022
M
Description of Requirement
78
Bidder’s response
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
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.
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
algorithms: Advanced Encryption Standard (AES)
– FIPS 197, Triple Data Encryption Standard
IDRAS 1st Stage IFB 2015
Bidder: <insert bidder name> IDRAS IFB Technical Responsiveness Checklist – 1st Stage Bids
Req’t
GTR023
Type
(M / D)
M
Description of Requirement
79
Bidder’s response
(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.
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
active entity or object that interacts with the
application on a user’s behalf.
IDRAS 1st Stage IFB 2015
Bidder: <insert bidder name> IDRAS IFB Technical Responsiveness Checklist – 1st Stage Bids
Req’t
GTR024
Type
(M / D)
M
GTR025
M
GTR026
M
GTR026a
M
GTR027
M
GTR028
M
Description of Requirement
80
Bidder’s response
I&A Mechanisms (1): I&A performed before granting
access to the application must use a non-forgeable,
non replayable mechanism that supports both oneway and two-way authentication.
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.
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.
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.
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
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,
(2) a text string commonly known to be used
as a password (e.g., “password”,
IDRAS 1st Stage IFB 2015
Bidder: <insert bidder name> IDRAS IFB Technical Responsiveness Checklist – 1st Stage Bids
Req’t
Type
(M / D)
GTR029
M
GTR030
M
GTR031
M
GTR032
M
Description of Requirement
81
Bidder’s response
“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
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
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.
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.
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
specify the number of expired previous passwords that
must not be chosen by a user. The application
IDRAS 1st Stage IFB 2015
Bidder: <insert bidder name> IDRAS IFB Technical Responsiveness Checklist – 1st Stage Bids
Req’t
Type
(M / D)
GTR033
M
GTR034
M
GTR035
M
GTR036
M
Description of Requirement
82
Bidder’s response
performs user I&A based on User ID and password.
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.
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.
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.
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
must provide a tool for creating and modifying
authorization information (e.g., ACLs, active
IDRAS 1st Stage IFB 2015
Bidder: <insert bidder name> IDRAS IFB Technical Responsiveness Checklist – 1st Stage Bids
Req’t
GTR037
Type
(M / D)
M
Description of Requirement
83
Bidder’s response
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 RoleBased 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.
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
cryptographic material used by the application,
including keys, trust points, and certificates. The
IDRAS 1st Stage IFB 2015
Bidder: <insert bidder name> IDRAS IFB Technical Responsiveness Checklist – 1st Stage Bids
Req’t
GTR038
Type
(M / D)
M
Description of Requirement
84
Bidder’s response
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.
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
identity of the data’s creator or sender; (3)
Invoke any external process that includes within
IDRAS 1st Stage IFB 2015
Bidder: <insert bidder name> IDRAS IFB Technical Responsiveness Checklist – 1st Stage Bids
Req’t
GTR039
Type
(M / D)
M
Description of Requirement
85
Bidder’s response
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.
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., PKIbased cryptographic hash or digital signature
mechanisms)—any integrity controls provided by the
application’s underlying host operating system and
surrounding security infrastructure
1. 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.
2. Validate Input and output: User input and output
to and from the system is the route for malicious
IDRAS 1st Stage IFB 2015
Bidder: <insert bidder name> IDRAS IFB Technical Responsiveness Checklist – 1st Stage Bids
Req’t
GTR040
Type
(M / D)
M
Description of Requirement
86
Bidder’s response
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.
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
contain errors, bugs, or vulnerabilities that could
cause any executing process within the
IDRAS 1st Stage IFB 2015
Bidder: <insert bidder name> IDRAS IFB Technical Responsiveness Checklist – 1st Stage Bids
Req’t
GTR041
Type
(M / D)
M
Description of Requirement
87
Bidder’s response
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 checkpoint restart.
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
providing undeniable proofs to both parties. This item
lists requirements governing how applications ensure
IDRAS 1st Stage IFB 2015
Bidder: <insert bidder name> IDRAS IFB Technical Responsiveness Checklist – 1st Stage Bids
Req’t
GTR042
Type
(M / D)
M
Description of Requirement
88
Bidder’s response
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.
Accountability: Accountability is the property of a
system (including all of its system resources) that
ensures that the actions of a system entity may be
traced uniquely to that entity, which can be held
IDRAS 1st Stage IFB 2015
Bidder: <insert bidder name> IDRAS IFB Technical Responsiveness Checklist – 1st Stage Bids
Req’t
Type
(M / D)
Description of Requirement
89
Bidder’s response
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
change, (14) Application of confidentiality or
integrity labels to data, (15) Override or
IDRAS 1st Stage IFB 2015
Bidder: <insert bidder name> IDRAS IFB Technical Responsiveness Checklist – 1st Stage Bids
Req’t
Type
(M / D)
GTR043
M
GTR044
M
GTR045
M
GTR046
M
Description of Requirement
90
Bidder’s response
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.
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.
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
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.
The system shall have a Test environment where new
content/features need to be tested before moving to
IDRAS 1st Stage IFB 2015
Bidder: <insert bidder name> IDRAS IFB Technical Responsiveness Checklist – 1st Stage Bids
Req’t
Type
(M / D)
GTR047
M
Description of Requirement
91
Bidder’s response
the production environment.
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 Policy
GTR048
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 Requirements
GTR049
M
GTR050
M
GTR051
M
GTR052
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.
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.
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.
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.
IDRAS 1st Stage IFB 2015
Bidder: <insert bidder name> IDRAS IFB Technical Responsiveness Checklist – 1st Stage Bids
Req’t
Description of Requirement
GTR053
Type
(M / D)
M
GTR054
M
The system shall enable to detect, prevent, correct and
audit the following:
1. SQL injection
2. Parameter tempering
3. Hidden manipulations
4. Backdoors and debug option
5. Buffer overflow
6. Stealth command
7. Cross-site scripting
8. Forceful browsing
92
Bidder’s response
Recoverability: Backup and restore capabilities.
Additional Security Requirements
GTR049
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.
IDRAS 1st Stage IFB 2015
Bidder: <insert bidder name> IDRAS IFB Technical Responsiveness Checklist – 1st Stage Bids
Req’t
Type
(M / D)
Description of Requirement
93
Bidder’s response
Interfaces
User Interfaces
GTR055
M
GTR056
M
GTR057
M
GTR058
M
GTR059
M
GTR060
M
GTR061
M
GTR062
M
GTR063
M
GTR064
M
EDI users must be provided with the choice of using
either a web-based or a thin-client graphical user
interface.
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.).
The thin-client module must be user friendly and
must provide an online help capability.
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.
The system must also provide for non-repudiation of
data submitted.
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
batch uploads the data when the connection is
available.
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.
Client interface performance: The client interface
should be sufficiently light that it loads on a 64kbps
internet connection in under 5 seconds.
The thin-client component must be update-able
remotely using a central server-based updating
mechanism on the network.
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.
IDRAS 1st Stage IFB 2015
Bidder: <insert bidder name> IDRAS IFB Technical Responsiveness Checklist – 1st Stage Bids
Req’t
Type
(M / D)
Description of Requirement
94
Bidder’s response
Hardware Interfaces
GTR065
M
GTR066
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
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
shall be able to work on typical standard
computer monitors
Software Interfaces
GTR067
GTR068
GTR069
GTR070
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).
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.
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
Regional integration: The system shall also, at the
minimum, take into consideration interfaces with the
IDRAS 1st Stage IFB 2015
Bidder: <insert bidder name> IDRAS IFB Technical Responsiveness Checklist – 1st Stage Bids
Req’t
Type
(M / D)
Description of Requirement
95
Bidder’s response
following system developed as part of the various
regional integration initiatives:
1. The SADC and COMESA.
2. The COMESA and East African Community
Initiative
Communications Interfaces
GTR071
M
GTR072
M
GTR073
M
GTR074
M
GTR075
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.
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.
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.
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
messages as a means of possible integration with
other revenue collection and accounting systems in
use in within TRA, nationally and internationally.
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).
IDRAS 1st Stage IFB 2015
Bidder: <insert bidder name> IDRAS IFB Technical Responsiveness Checklist – 1st Stage Bids
Req’t
Type
(M / D)
Description of Requirement
96
Bidder’s response
Performance and Availability Requirements
Primary Services
GTR076
M
GTR077
M
GTR078
M
GTR079
M
GTR080
M
GTR081
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.
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.
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.
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.
Reboot for memory / paging faults resolutions: The
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.
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 Windowsbased or as daemon's if the deployment is Linux/UNIX-
IDRAS 1st Stage IFB 2015
Bidder: <insert bidder name> IDRAS IFB Technical Responsiveness Checklist – 1st Stage Bids
Req’t
Type
(M / D)
GTR082
M
GTR083
M
Description of Requirement
97
Bidder’s response
based so that the system automatically starts up when
the servers are started up.
Configured auto restart: The system shall be
adequately configured for automatic reboots and
restarts in case of disaster.
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 Recovery
GTR084
M
GTR085
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
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).
Mirrored site: It is required that the disaster recovery
setup mirror the main system so as to allow for rapid
IDRAS 1st Stage IFB 2015
Bidder: <insert bidder name> IDRAS IFB Technical Responsiveness Checklist – 1st Stage Bids
Req’t
Type
(M / D)
GTR086
M
Description of Requirement
98
Bidder’s response
switchover in case of failure of the main site.
Business continuity: Bidders are therefore required to
describe how the proposed solution will ensure
business continuity through the use of the disaster
recovery site.
IDRAS 1st Stage IFB 2015
Bidder: <insert bidder name> IDRAS IFB Technical Responsiveness Checklist – 1st Stage Bids
Req’t
Type
(M / D)
Description of Requirement
99
Bidder’s response
Computing Hardware Specifications
Infrastructure Requirements
GTR087
M
GTR087a
M
GTR087b
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 preconfigured bundles of hardware and software in a
single chassis
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.
DR 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 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.
IDRAS 1st Stage IFB 2015
Bidder: <insert bidder name> IDRAS IFB Technical Responsiveness Checklist – 1st Stage Bids
Req’t
GTR088
Type
(M / D)
M
Description of Requirement
100
Bidder’s response
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 Environment
GTR089
M
GTR090
M
GTR091
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
portability or performance degradation. Any third
party software required, for the proper operation of
the system, must be clearly indicated and supplied.
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.
TRA hosted: The server infrastructure will be hosted at
the TRA’s premises and be accessible via its own
IDRAS 1st Stage IFB 2015
Bidder: <insert bidder name> IDRAS IFB Technical Responsiveness Checklist – 1st Stage Bids
Req’t
Type
(M / D)
GTR092
M
Description of Requirement
101
Bidder’s response
Virtual Private Network (VPN).
All application user interfaces will be enabled through
a graphical user environment, providing windowing
features.
Historisation
GTR093
M
GTR094
M
GTR095
M
GTR096
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.
Reference data and transaction data: This
historisation procedure shall be valid for all data in the
system, reference data as well as transaction data.
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.
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 Requirements
GTR097
M
GTR098
M
GTR099
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
EVA 6400 and Netapp FAS2040.
<No specific response to this item is expected from the
Bidder.>
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.>
Private Cloud Platform: By January, 2014 the
IDRAS 1st Stage IFB 2015
Bidder: <insert bidder name> IDRAS IFB Technical Responsiveness Checklist – 1st Stage Bids
Req’t
Type
(M / D)
GTR100
M
GTR101
M
GTR102
M
GTR103
M
GTR104
M
GTR105
M
Description of Requirement
102
Bidder’s response
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.
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.
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
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.
Minimum technical infrastructure: The proposal
should outline the recommended platform minimum
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.
Telecommunications requirements: The proposed
system should provide at least all minimum
telecommunication requirements including the
minimal VPN setup required for secure
communication.
Reuse of existing telecommunications infrastructure:
IDRAS 1st Stage IFB 2015
Bidder: <insert bidder name> IDRAS IFB Technical Responsiveness Checklist – 1st Stage Bids
Req’t
GTR106
Type
(M / D)
M
Description of Requirement
103
Bidder’s response
The system must be compatible with the existing
telecommunication infrastructure and must be able to
re-use as much of this infrastructure as possible.
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 webclient 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 Requirements
GTR107
M
GTR108
M
GTR109
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.
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.
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
should be specified.
Design and Implementation Constraints and Assumptions
GTR110
M
GTR111
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.
PC for EDI thin client: The thin client solution for EDI
users must be able to operate on a personal computer
with standard configuration
IDRAS 1st Stage IFB 2015
Bidder: <insert bidder name> IDRAS IFB Technical Responsiveness Checklist – 1st Stage Bids
Req’t
GTR112
Type
(M / D)
M
GTR113
M
GTR114
M
GTR115
M
Description of Requirement
104
Bidder’s response
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.
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.
Interoperability: It will utilise “open systems”
standards and architectures in order to ensure
interoperability with any future system that is
developed in the TRA.
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 Requirements
GTR116
M
GTR117
M
GTR118
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
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.
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.
‘Private cloud platform’: The Bidder must include a
description of any necessary ‘private cloud platform’
technology for any proposed and future proposed
IDRAS 1st Stage IFB 2015
Bidder: <insert bidder name> IDRAS IFB Technical Responsiveness Checklist – 1st Stage Bids
Req’t
Type
(M / D)
GTR119
M
GTR120
M
Description of Requirement
105
Bidder’s response
solution platform architecture, specifying load
balancing, performance scaling and hot switchover
technologies for the processor and memory.
Rack mounted solutions are required for servers.
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.
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 Requirements
GTR121
M
GTR122
M
GTR123
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.
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.
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 Requirements
GTR124
n/a
The diagram following illustrates a proposed network
IDRAS 1st Stage IFB 2015
Bidder: <insert bidder name> IDRAS IFB Technical Responsiveness Checklist – 1st Stage Bids
Req’t
Type
(M / D)
GTR125
n/a
GTR126
M
GTR127
M
GTR128
M
GTR129
M
Description of Requirement
106
Bidder’s response
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.>
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.>
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.
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
compatible with industry standard technologies.
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.
Bandwidth specification: The Purchaser has
implemented communication links to remote offices
with a bandwidth ranging between 256 kbps (small
IDRAS 1st Stage IFB 2015
Bidder: <insert bidder name> IDRAS IFB Technical Responsiveness Checklist – 1st Stage Bids
Req’t
Type
(M / D)
Description of Requirement
107
Bidder’s response
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 Configuration
GTR130
M
GTR131
M
GTR132
M
GTR133
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.
Web Browser: For Web-based functions, users must
interface to the solution through a Web Browser such
as Microsoft Internet Explorer, and similar tools
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.
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
will be centralised.
IDRAS 1st Stage IFB 2015
Bidder: <insert bidder name> IDRAS IFB Technical Responsiveness Checklist – 1st Stage Bids
Req’t
Type
(M / D)
Description of Requirement
108
Bidder’s response
Sofware Specifications
Relational Database Management System (RDBMS)
GTR134
M
GTR135
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.
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 Attributes
GTR136
M
GTR137
M
GTR138
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.
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.
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
procedures.
IDRAS 1st Stage IFB 2015
Bidder: <insert bidder name> IDRAS IFB Technical Responsiveness Checklist – 1st Stage Bids
Req’t
Type
(M / D)
Description of Requirement
109
Bidder’s response
Safety Requirements
GTR139
M
GTR140
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.
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 Handling
GTR141
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.
IDRAS 1st Stage IFB 2015
Bidder: <insert bidder name> IDRAS IFB Technical Responsiveness Checklist – 1st Stage Bids
Req’t
Type
(M / D)
Description of Requirement
110
Bidder’s response
System Management, Administration, and Security Specifications
General
GTR141
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 Requirements
GTR143
M
GTR144
M
GTR145
M
Single control panel for system admin: The system
administration aspects should be manageable from a
single control panel provided by the system.
Single control panel for DB admin: The database
management aspects should be manageable from a
single control panel provided by the system.
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

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
Security
GTR146
M
GTR147
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.
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
IDRAS 1st Stage IFB 2015
Bidder: <insert bidder name> IDRAS IFB Technical Responsiveness Checklist – 1st Stage Bids
Req’t
Type
(M / D)
GTR148
M
GTR149
M
GTR150
M
GTR151
M
GTR152
M
GTR153
M
GTR154
M
Description of Requirement
111
Bidder’s response
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.
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.
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.
Safe transmission of data: The system shall use a
combination of IP-level access restriction and VPNlevel encryption to ensure the safe transmission of
data.
The system shall ensure that all interfaces to external
systems are secured using the appropriate levels of
encryption and authentication mechanisms. This shall
include all messages sent and received.
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.
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.
Password security (1): The system shall automatically
require users to change their passwords at given
IDRAS 1st Stage IFB 2015
Bidder: <insert bidder name> IDRAS IFB Technical Responsiveness Checklist – 1st Stage Bids
Req’t
Type
(M / D)
GTR155
M
GTR156
M
Description of Requirement
112
Bidder’s response
intervals. The intervals should be configurable by
selected Security Administrators.
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.
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 Protection
GTR157
M
GTR158
M
GTR159
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
Virus, spam-ware and spy-ware protection: The
system shall ensure all publicly accessible sections of
the system are sufficiently protected against viruses,
spam-ware and spy-ware attacks
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.
IDRAS 1st Stage IFB 2015
Bidder: <insert bidder name> IDRAS IFB Technical Responsiveness Checklist – 1st Stage Bids
Req’t
Type
(M / D)
Description of Requirement
113
Bidder’s response
Service Specifications (including training)
System Integration
GTR160
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.
GTR161a
M
GTR161b
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.
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
Training
IDRAS 1st Stage IFB 2015
Bidder: <insert bidder name> IDRAS IFB Technical Responsiveness Checklist – 1st Stage Bids
Req’t
Type
(M / D)
GTR162
M
GTR163
M
GTR164
M
GTR165
M
GTR166
M
Description of Requirement
114
Bidder’s response
the proposed system.
Samples of training programs and training materials
deployed elsewhere should be included with the bid.
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.
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.
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
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.
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
IDRAS 1st Stage IFB 2015
Bidder: <insert bidder name> IDRAS IFB Technical Responsiveness Checklist – 1st Stage Bids
Req’t
Type
(M / D)
GTR167
M
GTR168
M
Description of Requirement
115
Bidder’s response
maintenance capabilities.
The TRA reserves the right to reproduce the training
materials for subsequent in-house training of other
staff and external users.
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.
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 Requirement
GTR169
M
GTR170
M
GTR171
M
GTR171a
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.
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
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.
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
ongoing debt management from information in its
(then-to-be) legacy I-Tax system
Technical Support
GTR172a
M
Warranty Service: 1 year for application software, 3
IDRAS 1st Stage IFB 2015
Bidder: <insert bidder name> IDRAS IFB Technical Responsiveness Checklist – 1st Stage Bids
Req’t
Type
(M / D)
GTR172b
M
GTR172c
M
GTR172d
M
GTR173a
M
Description of Requirement
116
Bidder’s response
years for servers, workstations, and notebooks, 1 year
on other hardware equipment
User support / hot line: Available during business
hours 8am to 5 pm, on-call support after business
hours (Dar es Salaam time).
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.
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.
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,
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.
IDRAS 1st Stage IFB 2015
Bidder: <insert bidder name> IDRAS IFB Technical Responsiveness Checklist – 1st Stage Bids
Req’t
GTR173b
Type
(M / D)
M
GTR174
M
GTR175
M
GTR175a
M
Description of Requirement
117
Bidder’s response
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.
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.
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.
Implementation Change Management: TRA requires
1. 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
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
IDRAS 1st Stage IFB 2015
Bidder: <insert bidder name> IDRAS IFB Technical Responsiveness Checklist – 1st Stage Bids
Req’t
Type
(M / D)
GTR175b
M
GTR175c
M
Description of Requirement
118
Bidder’s response
these purposes (refer to QUL010).
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.
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 Requirements
GTR176
M
GTR176a
M
GTR176b
M
GTR177
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.
Samples of user documentation: Provide samples of
user documentation that the Bidder has customized
for clients at its reference sites.
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
procedures to be operated using IDRAS.
Technical Documents: One complete set of hardcopy
documents and one set of documents on CD for all
hardware and software products supplied under the
IDRAS 1st Stage IFB 2015
Bidder: <insert bidder name> IDRAS IFB Technical Responsiveness Checklist – 1st Stage Bids
Req’t
Type
(M / D)
GTR178
M
GTR179
M
GTR180
M
GTR181
M
GTR182
M
GTR183
M
GTR184
M
Description of Requirement
119
Bidder’s response
Contract.
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.
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.
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.
User manuals in hardcopy and softcopy format shall
be provided to give detailed description of features
and guidance on the use of the features.
Data dictionary with proper documentation must also
be provided so that TRA can generate ad hoc reports.
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.
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
IDRAS 1st Stage IFB 2015
Bidder: <insert bidder name> IDRAS IFB Technical Responsiveness Checklist – 1st Stage Bids
Req’t
Type
(M / D)
GTR185
M
GTR186
M
GTR187
M
GTR188
M
Description of Requirement
120
Bidder’s response
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.
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.
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
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.
The language to be used throughout the IDRAS and all
its related documentation shall be English and
configurable into Swahili when needed.
IDRAS 1st Stage IFB 2015
Bidder: <insert bidder name> IDRAS IFB Technical Responsiveness Checklist – 1st Stage Bids
Req’t
Type
(M / D)
Description of Requirement
121
Bidder’s response
Management System
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-touse 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 lookand-feel for all applications, and the flexibility
to manage the enterprise from any Javaenabled
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
IDRAS 1st Stage IFB 2015
Bidder: <insert bidder name> IDRAS IFB Technical Responsiveness Checklist – 1st Stage Bids
Req’t
Type
(M / D)
Description of Requirement
122
Bidder’s response

Health monitoring, a sophisticated set of
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
IDRAS 1st Stage IFB 2015
Bidder: <insert bidder name> IDRAS IFB Technical Responsiveness Checklist – 1st Stage Bids
Req’t
Type
(M / D)
Description of Requirement
123
Bidder’s response
shared with other enterprise management
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.
IDRAS 1st Stage IFB 2015
Bidder: <insert bidder name> IDRAS IFB Technical Responsiveness Checklist – 1st Stage Bids
Req’t
Type
(M / D)
Description of Requirement
124
Bidder’s response

GTR190
M
Logical element grouping, enabling the
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
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
IDRAS 1st Stage IFB 2015
Bidder: <insert bidder name> IDRAS IFB Technical Responsiveness Checklist – 1st Stage Bids
Req’t
Type
(M / D)
Description of Requirement
5.
125
Bidder’s response
that ensure that the system’s security measures
work properly.
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.
IDRAS 1st Stage IFB 2015
Bidder: <insert bidder name> IDRAS IFB Technical Responsiveness Checklist – 1st Stage Bids
3
126
IFB Section VI Sub-Section D: Testing and Quality Assurance Requirements
Req’t
Type
(M / D)
Description of Requirement
Bidder’s Response
Inspections
TQA001
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 Tests
TQA002
M
TQA003
M
Supplier’s standard checkout and set-up tests: The
Supplier shall perform its standard checkout and setup tests and offer to demonstrate same to the
Purchaser.
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 Tests
TQA004
M
TQA005
M
TQA006
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.
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.
Comprehensive stress test: Following the
implementation of the hardware, network and security
infrastructure, the TRA, with the assistance of the
IDRAS 1st Stage IFB 2015
Bidder: <insert bidder name> IDRAS IFB Technical Responsiveness Checklist – 1st Stage Bids
Req’t
Type
(M / D)
TQA007
M
TQA008
M
TQA009
M
TQA010
M
TQA011
M
TQA012
M
TQA013
M
Description of Requirement
127
Bidder’s Response
Supplier, will test the resiliency and stability of the
solution by performing comprehensive stress test.
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.
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.
Specifically for system inspection: testing, verification
and validation shall be evaluated as shown in Table 1
and Figure 3.
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.
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.
System ownership: The system source code, software,
equipment and underlying components including
relevant licenses shall bear the ownership of TRA
perpetually.
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 Tests
TQA014
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
are ready for test as per schedule shown in Table 1 and
IDRAS 1st Stage IFB 2015
Bidder: <insert bidder name> IDRAS IFB Technical Responsiveness Checklist – 1st Stage Bids
Req’t
Type
(M / D)
TQA015
M
TQA016
M
Description of Requirement
128
Bidder’s Response
2 and Figure 3.
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.
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 Tests
TQA017
M
TQA018
M
Exit criteria (1): The Operational Acceptance Test will
be complete when
At least 95% of the tests have been executed
successfully
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.
IDRAS 1st Stage IFB 2015
Bidder: <insert bidder name> IDRAS IFB Technical Responsiveness Checklist – 1st Stage Bids
4
129
IFB Section VI Sub-Section E: Firm and Team Qualifications
Req’t
Type
(M / D)
Description of Requirement
Bidder’s Response
Firm and Team Qualifications
QUL001
M
QUL002
M
QUL003
M
QUL004
M
QUL005
M
QUL006
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.
Bidder experience: The Bidder MUST have been in
operation for at least the eight (8) years preceding the
Bid Opening date.
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.
Technology transfer: Bidder MUST specify their
methodology for technology transfer and provide
qualified specialists to train TRA including professional
staff, IT staff and managers.
Bidder MUST provide appropriate professional staff
(quality and quantity) during duration of the project
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
that will be applied by Bidder
IDRAS 1st Stage IFB 2015
Bidder: <insert bidder name> IDRAS IFB Technical Responsiveness Checklist – 1st Stage Bids
Req’t
Type
(M / D)
Description of Requirement
130
Bidder’s Response
3.
QUL007
M
QUL008
M
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.
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.
Bidder shall propose one or more tax administration
specialists that (collectively) have experience and
knowledge in the functional areas specified in this IFB
Each 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
responsible for providing guidance and
IDRAS 1st Stage IFB 2015
Bidder: <insert bidder name> IDRAS IFB Technical Responsiveness Checklist – 1st Stage Bids
Req’t
Type
(M / D)
QUL009
M
QUL010
M
Description of Requirement
131
Bidder’s Response
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.
Bidder shall propose ICT specialists responsible for
1. 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.
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
similar complexity
IDRAS 1st Stage IFB 2015
Bidder: <insert bidder name> IDRAS IFB Technical Responsiveness Checklist – 1st Stage Bids
Req’t
Type
(M / D)
Description of Requirement
132
Bidder’s Response
2.
QUL011
M
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.
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.
IDRAS 1st Stage IFB 2015
Bidder: <insert bidder name> IDRAS IFB Technical Responsiveness Checklist – 1st Stage Bids
5
133
IFB Section VI Sub-Section F: Implementation Schedule
Req’t
Type
(M / D)
Description of Requirement
Bidder’s Response
Implementation and Implementation Schedule Requirements
IAS001
M
IAS001a
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.
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
of international good practice based on their projects
elsewhere. Before concluding the Requirements
IDRAS 1st Stage IFB 2015
Bidder: <insert bidder name> IDRAS IFB Technical Responsiveness Checklist – 1st Stage Bids
Req’t
Type
(M / D)
IAS002
M
IAS003
M
Description of Requirement
134
Bidder’s Response
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.
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
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:
E-service Workflow and Data Management
Taxpayer Registration
IDRAS 1st Stage IFB 2015
Bidder: <insert bidder name> IDRAS IFB Technical Responsiveness Checklist – 1st Stage Bids
Req’t
IAS004
Type
(M / D)
M
Description of Requirement
135
Bidder’s Response
Return processing
Payment processing
Taxpayers & Revenue Accounting
Compliance & Enforcement
Objection and Appeals
Audit Support
Management Information System
Other Modules include:
Refund Management
Case Management
Tax 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.
Documents subject to review and approval: The
following documents shall be subject to review and
approval process by the Purchaser prior to full-scale
IDRAS 1st Stage IFB 2015
Bidder: <insert bidder name> IDRAS IFB Technical Responsiveness Checklist – 1st Stage Bids
Req’t
Type
(M / D)
IAS005
M
IAS006
M
Description of Requirement
136
Bidder’s Response
execution of subsequent steps:
1. detailed site surveys;
2. Detailed Requirements Documentation per
implemented module
3. Detailed overall system design specifications
4. Functional
Specifications
document
per
implemented module,
5. Change management and training plans
6. Stakeholder communication plan
7. final Subsystem configurations
8. Operational Acceptance Test Plans and Results
9. Data Migration Plans and execution results
10. Monthly progress reports
Preliminary Project Plan
1. 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.
Confirmation of Responsibility for Integration and
Interoperability of Information Technologies
The Bidder must submit a written confirmation that, if
awarded the Contract, it shall accept responsibility for
IDRAS 1st Stage IFB 2015
Bidder: <insert bidder name> IDRAS IFB Technical Responsiveness Checklist – 1st Stage Bids
Req’t
Type
(M / D)
Description of Requirement
137
Bidder’s Response
successful integration and interoperability of all the
proposed Information Technologies included in the
System, as further specified in the Bidding Documents.
IDRAS 1st Stage IFB 2015
Bidder: <insert bidder name> IDRAS IFB Technical Responsiveness Checklist – 1st Stage Bids
138
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
BRF001
BRF002
BRF003
BRF004
BRF005
Requirement Description
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.
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]
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.
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 1st 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 Schedules
iii.
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.
Bidder’s response
IDRAS 1st Stage IFB 2015
Bidder: <insert bidder name> IDRAS IFB Technical Responsiveness Checklist – 1st Stage Bids
ID
BRF006
BRF007
BRF008
Requirement Description
The 1st 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-incharge 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 2nd 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.
Price Schedules: (to be provided with 2nd 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.
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.
139
Bidder’s response
IDRAS 1st Stage IFB 2015
Bidder: <insert bidder name> IDRAS IFB Technical Responsiveness Checklist – 1st Stage Bids
ID
BRF009
BRF010
BRF011
BRF012
BRF013
BRF014
BRF015
BRF016
Requirement Description
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.
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.
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.
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 subsection. The forms contain additional detailed instructions which the Bidder must follow.
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.
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.
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.
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
140
Bidder’s response
IDRAS 1st Stage IFB 2015
Bidder: <insert bidder name> IDRAS IFB Technical Responsiveness Checklist – 1st Stage Bids
ID
BRF017
BRF018
BRF019
Requirement Description
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.
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.
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).
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.
141
Bidder’s response
IDRAS 1st Stage IFB 2015
Bidder: <insert bidder name> IDRAS IFB Technical Responsiveness Checklist – 1st Stage Bids
142
Bid Table of Contents and Checklist
Note: 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:
page no.
y/n
First Stage Bid Form ............................................................................................................
Signature Authorization ....................................................................................................
(for Joint Ventures additionally including the authorizations listed in ITB Clause 6.2)
Attachment 1
Bidder’s Eligibility ...................................................................................
Attachment 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 Services .............................................................
Attachment 4
Conformity of the Information System to the Bidding Documents .......
Overview of proposed solution ..............................................................
Technical Responsiveness Checklist ......................................................
Management and Personnel capability .................................................
Preliminary Project Plan .........................................................................
Attachment 5
Proposed Subcontractors .......................................................................
Attachment 6
Intellectual Property (Software and Materials Lists) ..............................
Attachment 7
Deviations...............................................................................................
Attachment 8
Alternative Bids ......................................................................................
Required Media and Format for Bid
Item
present: y/n Item
present: y/n
Original Bid (hardcopy) .................................
Copy of Bid (hardcopy) .................................
CD#1 or Memory Stick#1
CD#2 or Memory Stick#2
(containing PDF document of entire bid plus MS Word document of TRC)
(containing PDF document of entire bid plus MS Word document of TRC)
IDRAS 1st Stage IFB 2015