FRCA Implementation of Integrated Tax System - Fiji · PDF file · 2014-10-16FRCA Implementation of Integrated Tax System ... The FRCA is a combined Customs and Tax authority and

FRCA Implementation of

Integrated Tax System

Requirement Specification Catalogue (RSC)

-- Generic User Requirements --

FITS Review Team August 2014

FRCA ITIS Acquisition Preliminary generic user requirements Version: 0.8

FITS Review Team August 2014 Page 2 of 67

Contents

1 TERMS AND ABBREVIATIONS ............................................................................................................. 5

2 INTRODUCTION AND BACKGROUND ................................................................................................ 7

3 CURRENT STATE OF AFFAIRS ............................................................................................................. 7

3.1 GENERAL OUTLINE .................................................................................................................................... 7 3.2 CURRENT FRCA ORGANISATIONAL STRUCTURE ....................................................................................... 9 3.3 FRCA BPS ................................................................................................................................................. 9

4 REQUIREMENTS FOR THE NEW SYSTEM ...................................................................................... 10

4.1 ENVISAGED FUTURE BP STRUCTURE ....................................................................................................... 10 4.1.1 Legislation and Policy ................................................................................................................... 11 4.1.2 Taxpayer Registration ................................................................................................................... 11 4.1.3 Assess Tax ...................................................................................................................................... 11 4.1.4 Debt Management & Collection of Tax ......................................................................................... 12 4.1.5 Make Disbursements ...................................................................................................................... 12 4.1.6 Provide Information Taxpayer Services ........................................................................................ 12

4.2 REQUIREMENT TEMPLATES ...................................................................................................................... 12 4.3 TAXES TO BE COMPUTERISED .................................................................................................................. 14 4.4 GENERAL REQUIREMENTS ....................................................................................................................... 14

4.4.1 Summary of General Requirements ............................................................................................... 15 4.5 SYSTEM ARCHITECTURE AND DESIGN APPROACH ................................................................................... 18

4.5.1 Summary of Requirements Related to the System Architecture and Design .................................. 22 4.5.2 Analysis of Existing IT Components .............................................................................................. 24 4.5.3 Integration Approach..................................................................................................................... 24

4.6 FUNCTIONAL MODEL ............................................................................................................................... 25 4.7 FUNCTIONAL REQUIREMENTS .................................................................................................................. 25

4.7.1 Summary of Functional Requirements Related to the Taxpayer Registration ............................... 26 4.7.2 Summary of Functional Requirements Related to the Assessment and Payments ......................... 28 4.7.3 Summary of Functional Requirements Related to the Compliance Monitoring and Enforcement 33 4.7.4 Summary of Functional Requirements Related to Collection and Debt Management ................... 38 4.7.5 Summary of Functional Requirements Related to Objections and Appeals ................................... 40 4.7.6 Summary of Functional Requirements Related to Taxpayer Services ........................................... 42 4.7.7 Security and Data Privacy Requirements ...................................................................................... 43 4.7.8 IT Operational Requirements ........................................................................................................ 44 4.7.9 Miscellaneous Requirements ......................................................................................................... 45

5 IMPLEMENTATION CONSIDERATIONS .......................................................................................... 46

5.1 OUTLINE .................................................................................................................................................. 47 5.2 CAPABILITY - CHANNEL DELIVERY ......................................................................................................... 47

5.2.1 Abstract .......................................................................................................................................... 47 5.2.2 Details ............................................................................................................................................ 48

5.3 CAPABILITY - CLIENT RELATIONSHIP MANAGEMENT .............................................................................. 49 5.3.1 Abstract .......................................................................................................................................... 49 5.3.2 Details ............................................................................................................................................ 49

5.4 CAPABILITY - REVENUE MANAGEMENT .................................................................................................. 49 5.4.1 Abstract .......................................................................................................................................... 49 5.4.2 Details ............................................................................................................................................ 49

5.5 CAPABILITY - CASE AND WORK MANAGEMENT ...................................................................................... 51 5.5.1 Abstract .......................................................................................................................................... 51 5.5.2 Details ............................................................................................................................................ 51

5.6 CAPABILITY - OUTCOME IMPROVEMENT .................................................................................................. 52 5.6.1 Abstract .......................................................................................................................................... 52 5.6.2 Details ............................................................................................................................................ 52

5.7 CAPABILITY - PLAN AND MANAGE ENTERPRISE ...................................................................................... 53 5.7.1 Abstract .......................................................................................................................................... 53 5.7.2 Details ............................................................................................................................................ 53



5.8 CAPABILITY - ENABLERS ......................................................................................................................... 54 5.8.1 Abstract .......................................................................................................................................... 54 5.8.2 Details ............................................................................................................................................ 54

6 CHANGE MANAGEMENT ..................................................................................................................... 55

7 INDICATIVE DELIVERY PLAN AND PRELIMINARY SCHEDULE ............................................. 55

7.1 DURATION ............................................................................................................................................... 55 7.2 OVERVIEW ............................................................................................................................................... 55

8 INSTRUCTION TO TENDERERS ......................................................................................................... 56

8.1 GENERAL ................................................................................................................................................. 56 8.1.1 Cost of Tender ............................................................................................................................... 56

8.2 TENDER DOCUMENTS .............................................................................................................................. 56 8.2.1 Tender Procedure .......................................................................................................................... 56 8.2.2 General Responsibility of Tenderer ............................................................................................... 56 8.2.3 Clarification of Tender Documents ............................................................................................... 56 8.2.4 Amendment of Tender Documents ................................................................................................. 57

8.3 PREPARATION OF TENDERS ...................................................................................................................... 57 8.3.1 Language of Tender ....................................................................................................................... 57 8.3.2 Documents Comprising the Tender ............................................................................................... 57 8.3.3 Tender Prices ................................................................................................................................. 57 8.3.4 Tender Currencies ......................................................................................................................... 57 8.3.5 Documents Establishing Good's Conformity to Tender Documents .............................................. 57 8.3.6 Tender Security .............................................................................................................................. 58 8.3.7 Period of Validity of Tenders ......................................................................................................... 58 8.3.8 Format and Signing of Tender ....................................................................................................... 58

8.4 SUBMISSION OF TENDERS ........................................................................................................................ 58 8.4.1 Sealed Envelopes ........................................................................................................................... 58 8.4.2 Number of Proposals ..................................................................................................................... 58 8.4.3 All envelopes shall: ........................................................................................................................ 59 8.4.4 Deadline for Submission of Tenders .............................................................................................. 59 8.4.5 Late Tenders .................................................................................................................................. 59 8.4.6 Modification and Withdrawal of Tenders ...................................................................................... 59 8.4.7 Preliminary Examination ............................................................................................................... 59 8.4.8 Clarification of Tenders ................................................................................................................. 59 8.4.9 Evaluation of Technical Proposals ................................................................................................ 60 8.4.10 Screening of requirements ........................................................................................................ 60 8.4.11 Layout of Technical Proposals ................................................................................................. 60 8.4.12 Presentations ............................................................................................................................ 60 8.4.13 Scoring of Technical Proposals ................................................................................................ 60 8.4.14 Short listed technical proposals ................................................................................................ 60 8.4.15 Demonstrations ......................................................................................................................... 61 8.4.16 Solutions Presentation and Demo ............................................................................................. 61 8.4.17 Final Short-listed Solutions ...................................................................................................... 61 8.4.18 Envelopes containing the financial proposals of Tenderers shall be opened provided that the

technical proposal: ...................................................................................................................................... 61 8.4.19 Financial Evaluation ................................................................................................................ 61

8.5 AWARD OF CONTRACT ............................................................................................................................. 62 8.5.1 Award of Tender ............................................................................................................................ 62 8.5.2 Award Criteria ............................................................................................................................... 62 8.5.3 Purchaser's right to accept any Tender and to reject any or all Tenders ...................................... 62 8.5.4 Notification of Award .................................................................................................................... 62 8.5.5 Signing of Contract ........................................................................................................................ 62 8.5.6 Performance Security .................................................................................................................... 63 8.5.7 Delivery Schedule .......................................................................................................................... 63

Tables TABLE: TERMS AND ABBREVIATIONS ....................................................................................................................... 7



TABLE: THE CONCEPT OF FUNCTIONAL AND SERVICE REQUIREMENTS ................................................................... 12 TABLE: THE TEMPLATE FOR FUNCTIONAL AND SELECTED MISCELLANEOUS REQUIREMENTS ................................. 13 TABLE: THE TEMPLATE FOR OTHER GROUPS OF REQUIREMENTS ............................................................................ 13 TABLE: MAIN GENERAL REQUIREMENTS ................................................................................................................ 18 TABLE: SUMMARY OF REQUIREMENTS RELATED TO THE COTS ARCHITECTURE AND DESIGN ................................ 24 TABLE: DECLARATIONS AND PAYMENTS VOLUME FOR 2013 .................................................................................. 24 TABLE: SUMMARY TAXPAYER REGISTRATION REQUIREMENTS .............................................................................. 27 TABLE: SELECTED DETAILS OF TAXPAYER REGISTRATION REQUIREMENTS ............................................................ 28 TABLE: SUMMARY TAXPAYER ASSESSMENT AND PAYMENT REQUIREMENTS ......................................................... 29 TABLE: SELECTED DETAILS OF TAXPAYER RETURN MANAGEMENT ........................................................................ 30 TABLE: SELECTED DETAILS OF TAXPAYER PAYMENT PROCESSING ......................................................................... 31 TABLE: SELECTED DETAILS OF TAXPAYER AND REVENUE ACCOUNTING ................................................................ 33 TABLE: SUMMARY OF REQUIREMENTS RELATED TO THE COMPLIANCE MONITORING AND ENFORCEMENT ............. 35 TABLE: SUMMARY OF RISK MANAGEMENT RELATED REQUIREMENTS .................................................................... 38 TABLE: SUMMARY OF REQUIREMENTS RELATED TO THE COLLECTION OF ARREARS AND DEBT MANAGEMENT....... 39 TABLE: SELECTED DETAILS RELATED TO DEBT COLLECTION AND MANAGEMENT .................................................. 40 TABLE: SUMMARY OF REQUIREMENTS RELATED TO THE OBJECTIONS AND APPEALS .............................................. 41 TABLE: FRAMEWORK OF E-SERVICES (SOURCE OECD) .......................................................................................... 42 TABLE: SUMMARY OF SELECTED TAXPAYER SERVICE REQUIREMENTS ................................................................... 43 TABLE: SECURITY AND DATA PRIVACY RELATED REQUIREMENTS .......................................................................... 43 TABLE: SUMMARY OF OPERATIONAL REQUIREMENTS ............................................................................................ 44 TABLE: SUMMARY OF MISCELLANEOUS REQUIREMENTS ........................................................................................ 46 TABLE: DELIVERY CHANNELS ................................................................................................................................ 49 TABLE: CRM ......................................................................................................................................................... 49 TABLE: REVENUE MANAGEMENT ........................................................................................................................... 51 TABLE: CASE AND WORKFLOW MANAGEMENT ....................................................................................................... 52 TABLE: OUTCOME IMPROVEMENT .......................................................................................................................... 53 TABLE: ENTERPRISE PLANNING AND MANAGEMENT .............................................................................................. 53 TABLE: ENABLERS ................................................................................................................................................. 54 TABLE: INDICATIVE DELIVERY PLAN ..................................................................................................................... 56

Diagrams DIAGRAM: FUNCTIONAL GROUPING OF BPS ........................................................................................................... 10 DIAGRAM: CORE BUSINESS OF FRCA TAXATION DIVISION ................................................................................... 11 DIAGRAM: THE LIAM IMPLEMENTATION OF THE TTT PRINCIPLE .......................................................................... 22 DIAGRAM: ENVISAGED GENERAL FUNCTIONAL STRUCTURE AND MAIN INFORMATION FLOW ................................. 25 DIAGRAM: STRATEGIC RISK MANAGEMENT CYCLE MODEL .................................................................................. 35 DIAGRAM: TAX REFERENCE MODEL ...................................................................................................................... 47



1 TERMS AND ABBREVIATIONS

Terms and abbreviations used in this document and attachments have the meaning as shown in the table below.

Term/abbreviation Meaning

ACCU Amendment Correspondence & Control Unit

ASYCUDA Automated System of Customs Data

BA Business Analyst

BCP Business Continuity Plan

BP Business Process

BR Business Rule

BS Bureau of Statistics

CAAF Civil Aviation Authority of Fiji

CT Corporate Tax

COTS Custom Off The Shelf

CRM Customer Relationship Management

DB Data base

DBMS (DB) Data base management system

DMS Debt Management Services

DoI Department of Immigration

DR Disaster Recovery

EMS Employer Monthly Summary

FAQ Frequently asked questions

FIA Fiji Institute of Accountants

FITS Fiji Integrated Tax System

FNPF Fiji National Provident Fund

FRCA Fiji Revenue & Customs Authority

FSIC Fiji Standard Industrial Classification

GTT Gambling Turnover Tax

HR Human Resources

HR21 Employee & Manager Self Service Kiosk

HW Computer Hardware

ICT Information and Communication Technology

IMF International Monetary Fund




IRP Industry Risk Profile

IS Information System

IT Information Technology

ITIS The new Integrated Tax Information System

JID Joint Identification Card

LEU Lodgement Enforcement Unit

LIAM Logical Information Architecture Model

LP Legal person; business entity.

LTA Land Transport Authority

MIS Management Information System

MoF Ministry of Finance

MoJ Ministry of Justice

NGO Non-governmental organization

Nil Return A nil declaration, i.e. the tax period without economic result

NOA Notice of Assessment

NP Natural Person

OECD Organization for European Cooperation and Development

PAYE Final Pay As You Earn As Final Tax

PFTAC Pacific Financial Technical Assistance Centre

PM Project Manager

QA Quality Assurance

RA Revenue Accounting

RBF Reserve Bank of Fiji

REALB Real Estate Licensing Board

Registrar BDM Registrar of Births, Deaths & Marriage

RMS Risk Management System

RSC Requirement Specification Catalogue

SC Steering Committee

SDD Systems design documentation

SOA Service oriented architecture.

SOP Standard Operating Procedures

SPoE Single Point of Entry

SUN SunSystems




TADAT Tax Administration Diagnostic Assessment Tool

TIN Taxpayer Identification Number

TIEA Tax Information Exchange Agreements

TLTB i-Taukei Land Trust Board

TOR Terms of Reference

TTPA Time To Pay Arrangement

TTT Taxpayer-per-Tax type-per Tax period

VAT Value Added Tax

Table: Terms and Abbreviations

2 Introduction and Background

The business and IT modernisation is a longstanding issue, and to this end FRCA, in the past two years, had

been engaging PFTAC technical assistance for the following review activities:

SOPs review and modernisation to include PAYE As FINAL TAX

IT systems especially in the area of DR and BCP

FITS technical review

VAT Self-Assessment

In addition, PFTAC assistance was also provided to the Authority defining user requirements for the preparation

of the technical solution for the new COTS that leverages off international best practices. The user requirements

are included in this TOR document for the Tender of the COTS.

Should we add in a section on future vision and insert your diagram?

3 Current State of Affairs

The FRCA is a combined Customs and Tax authority and each division has it‘s respective IT system

ASYCUDA++ and FITS. The ASYCUDA++ migration to ASYCUDA World project had begun in September of

this year.

3.1 General Outline

The existing Revenue system FITS has been in operation since 2003, with only three major tax types namely

Income Tax, PAYE and VAT. It has grown from six core original modules to currently hosting twenty eight

modules. In the same token additional tax types have been introduced together with implementation of

Compulsory TIN registration for all Fiji citizens.

FITS recently had delivered PAYE Final while VAT Self-Assessment as well as having the capability to host e-

commerce related activities is currently being tested. However, the following additional requirements justify the

need for a COTS solution to replace FITS:

Growth in economic activities;

Full Self-assessment environment for all tax types;

Improved customer service e.g. e-services; paperless FRCA;

Improved user interface with inclusion of single view of customer;

Challenge faced with making changes in a short turnaround period of time after budget announcements

As well as other system changes.

In addition, there is also the need to seamlessly integrate ASYCUDA to the Revenue system for specific

functions. Thus vendors must also demonstrate where their product has interfaced with ASYCUDA World or



another customs system as well as successful integration with any other revenue system in the past. The diagram

below depicts the integration needs of the Authority:

ASYCUDA WORLD, EMPLOYERS, FNPF, LOCAL GOVT, REGISTRAR BDM, REGISTRAR COMPANIES, TITLES, BANKS, LTA, TLTB,

INVESTMENT FIJI, IMMIGRATION, LANDS

National Switch

Reserve Bank of Fiji

Commercial Banks

Merchants

EFTPOS Network

Importers/Exporters

International BanksVisa Member Banks



3.2 Current FRCA Organisational Structure

Diagram: FRCA Organisational Structure

Review the structure – some functions are not in the correct box e.g. TEPU/TIPU are now part of DMS, Benefits no longer a fn of HR

3.3 FRCA BPs

Currently the business processes of FRCA are largely guided by Legislation as well as the various Taxation

functional units. For this reason the provision of the new COTS should include the task of analysis and revision

of all main BPs to ensure the adoption of an end to end process approach and reduce the opportunity for siloed

functional approaches.

It should be determined which processes are obsolete or should be amended, which processes to include with the

view of automation, and which processes should preferably remain manual. In turn, this will serve dual purpose:

a) Easing the understanding of the current FRCA BPs; and

b) Transferring the skills and BP analysis related experience to FRCA.

In addition, the following high-level business rules must be adhered to:

The business requirements must drive IT and are the key to the future IT environment.

Understanding the total cost of a solution from both an implementation and on-going support needs is a

critical requirement for IT decision making.

Maintain a balance between innovation and risk, by carefully assessing risks against potential benefits

when considering the adoption of new technology.

IT decisions are made to provide maximum benefit to the Revenue Administration as a whole.

IT investments are recognized as FRCA corporate assets and are managed accordingly.

Ensure appropriate system security is in place so that information and systems are protected from

unauthorized use and disclosure.

Information is recognized as an asset and must be managed accordingly.

As much as possible there should be ―one version of the truth‖, e.g. collect data once but access it many

times.

IT systems are designed and implemented allowing for reuse by other business processes, e.g. one case

management system for Audit, Debt and Investigations.

Minimize the number of different technologies and products providing the same or similar service.

Capacity must be anticipated and maintained to ensure appropriate responsiveness to end users.

Every IT solution should have disaster recovery addressed as part of the implementation plan.

Hardware and operating systems must operate in an environment where the software is only one version

behind the latest released one.

Commercially developed package software should be purchased whenever possible, rather than build

specific software products just for FRCA.

There must be one central point of taxpayer registration.

Attempt to collect revenue at the original source as much as possible—adopt a full and final approach.

Minimize any customization of the COTS solution—change the business process first before

customizing the COTS.



End to end business processes must be designed, not functional based siloed processes.

Design these processes by ―being in the shoes of the customer‖—ensure end customers are involved in

business process design, e.g. FIA, groups of taxpayers, etc.

Adopt a ―whole of government ―approach—if another government agency has the taxpayer information

already, how can FRCA access this through system integration?

The current BPs is being updated from an SOP or Operations Manual perspective and it is expected that the use

of these manuals will enable the successful vendor to better understand the current FRCA environment. In

addition, these manuals should be a minimal benchmark of any future Operational Manual(s) /SOP(s) arising

from the new COTS. The successful vendor is required to design a process that will enable FRCA to maintain

these manuals on an on-going basis.

4 Requirements for the New System

4.1 Envisaged Future BP Structure

The FRCA core functions and consequently those of the COTS are closely related to encouraging and servicing

taxpayers to correctly account for their obligations and comply with tax legislation. FRCA is directly responsible

for collecting national taxes, supervising compliance with local taxes, as well as implementing Double Tax

Agreements and TIEA‘s. The main core business processes can be divided into the following groups also

forming the high level business logic of COTS functionality.

1. Legislation and Policy - To ensure better, more effective tax policy development and giving effect to

them through law

2. Taxpayer Registration - To record taxpayer entities in the system.

3. Assess Tax – Determine the correct tax liability

4. Debt Management & Collection of Tax - For taxpayers to file returns and pay taxes due.

5. Make Disbursements - To refund entitlements and issue NOA to taxpayers

6. Provide Information Taxpayer Services - To assist in future planning.

The diagram below depicts major groups of business function within this classification.

Taxation

Core FunctionsManagement of Taxpayers and

Revenue

Organizational Functions

Registration Policy & Law

Collect TaxAssess Tax

Providing Information

Disbursement

Revenue Collection

Audit & Compliance

Functions Customs

Debt Management

Services

Corporate Governance

External

Diagram: Functional grouping of BPs/Review fn grouping e.g. TEPU/TIPU are now part of DMS



The requirements of this RSC focus largely on the first group of tasks representing the core business of the

Taxation Division illustrated by the next diagram and to applicable extent, other task and processes are dealt

with or referred to; e.g. legal implications, strategic compliance enforcement planning and risk management.

Diagram: Core business of FRCA Taxation Division

4.1.1 Legislation and Policy

The centrally placed Policy & Legal Units are tasked with the responsibility for developing better and more

effective tax policies and giving effect to them through law. The current Low Rate Broad Base Tax policy is

expected to facilitate Fiji‘s economic growth to 3.6% in 2014. The main groups of business processes, most of

which relate to the change management performed by Policy & Legal comprise:

To regulate preferential tax policies

To ensure that the Policy & Law process is fit for purpose

To reflect tax policy and law changes

Implement legal proceedings

Legal support and processing of objections and appeals.

To measure the outcomes of the policy and law changes

To be consistent with changing business environment

4.1.2 Taxpayer Registration

The registrations of all new taxpayers and issue of Joint ID Cards are handled at the Customer Service Centres.

The process comprises of the following:

To improve understanding of the Registration process

To enable taxpayer entities to register for tax purpose

To formally confirm tax registration of taxpayer entities

To update Taxpayer registration database

To deregister the taxpayer following a change in their circumstances

To measure the outcomes of the registration process

To be consistent with the changing business environment

To issue Joint ID Cards to individuals.

4.1.3 Assess Tax

Authority-based assessments are currently being handled by several units including Processing, Technical,

Companies, Gold Card, CGT & Stamp Duties while Self-Assessed returns inclusive of FBT, STT & CCL are

processed by the Data Entry Unit.

On the other hand, the approval process of refunds are currently handled by Processing, Technical, Companies,

Gold Card, with approvers being Chief Assessors, NMRC and GMT.

Monitoring of

economixc

activities

Voluntary

registration

Forced

registration

Deregistration

Tax type

entitlement

Filing

compliance

Declaration

compliance

Payment

compliance

no

Debt

management

IS

Risk

management



The process comprises of the following:

Assist Taxpayers in voluntarily complying with their tax obligations

Process tax returns and update the returns database

Formally advise taxpayers of their tax liability

To amend the assessment if required

To be consistent with the changing business environment

To measure the outcomes of policy and law changes

4.1.4 Debt Management & Collection of Tax

The collection of all tax types are handled by DMS, Despatch, Audit, PAYE, CGT & Stamp Duties sections.

These units also enforce the filing of outstanding returns. The process comprises of the following:

Advise and assist Taxpayers understand their payment obligations

Receive Tax payments

Implement recovery actions when taxpayers fail to pay a tax liability

Initiate legal proceedings

Supervision of the activity of all tax inspectors and adherence to legislation and guidelines.

Objection to Tax Refunds

Compliance methodologies

Monitor and Review Collect Tax process

4.1.5 Make Disbursements

The issuing of Notices of Assessments, facilitating the issuing of refunds and accounting for receipts and

payments is the responsibility of Despatch and Gold Card Units. The process comprises of the following:

Educate taxpayers on the Tax Refunds criteria

Provide Statement of Tax Account

Facilitate Objection to Tax Refunds

Monitor and Review Disbursements Process

4.1.6 Provide Information Taxpayer Services

General awareness on various tax issues is the responsibility of all units. The provision of accurate taxpayer

information is vital especially with the move towards a Self-Assessment environment. In addition, the Authority

expects customer interaction to improve with the expansion of communication services using social media and

through the establishment of a Contact Centre. This process comprises of the following:

Design reporting responsibilities to all internal and external stakeholders

Develop reporting responsibilities

Implement reporting responsibilities

Provide information to external stakeholders

Monitor and Review Provide Information Process

4.2 Requirement Templates

For the purpose of collecting the requirement specifications, this chapter complies with a widely applied model

of functional and service concepts, where the functional concepts describes the "WHAT"s and the service

concept describes the "HOW"s, e.g.:

ID This is a functional concept description (WHAT is needed).

This is a service concept description (HOW to achieve the WHAT).

Rationale (optional) providing arguments or explanation for a given concept

(requirement).

Table: The concept of functional and service requirements



At this stage the focus is on functional concepts as most decisions about HOW are not relevant until later. It is

only when the service concept is of importance, or when clear directions are already available, assumed or

strictly recommended, that the service concept is included.

The requirements included in the remainder of the chapter is drafted to the level of granularity and details

expected to be adequate for the inclusion of the envisaged tender dossier to be prepared in the consequent stages

of the COTS acquisition process. For that purpose the requirements are divided into the following groups:

1. Taxes to be computerised.

2. General requirements.

3. Requirements regarding the systems architecture and design approach.

4. Functional model and requirements, sub-divided according to the main functions.

5. Security and data privacy requirements.

6. IT operational requirements.

7. Miscellaneous requirements.

The functional requirements (4) and partial requirements from other groups are structured as shown with three

additional columns indicating the existence of the requirement in existing system, mandatory requirement, and a

proposal based on best practice.

ID This is a functional concept description (WHAT is

needed).

This is a service concept description (HOW to

achieve the WHAT).

Rationale (optional) providing arguments or

explanation for a given concept (requirement).

Existing Mandatory Proposal

Table: The template for functional and selected miscellaneous requirements

Yet other requirements, while following the same functional or service concept are collected with an additional

column showing the origin of a given requirement, which could be either generic (according to acknowledged

international practice) or indicating an authority, organization, a department or an entity as the source of its

origin.

ID This is a functional concept description (WHAT is needed).

This is a service concept description (HOW to achieve the WHAT).

Rationale (optional) providing arguments or explanation for a given

concept (requirement).

Origin

Table: The template for other groups of requirements

As appropriate, the structured and numbered requirements are accompanied by narrative lead-in paragraphs or

explanatory comments.



4.3 Taxes to be Computerised

The new system to be implemented to support the collection and management of taxes listed in the next table.

ID Requirement outline Origin

CT Company Tax FRCA

CGT Capital Gains Tax FRCA

CCL Credit Card Levy FRCA

DT Dividend Tax FRCA

FBT Fringe Benefit Tax FRCA

FC Fees and Charges FRCA

GTT Gambling Turnover Tax FRCA

IT Income Tax FRCA

MISC Miscellaneous FRCA

PAYE Pay As You Earn FRCA

PT Provisional Tax FRCA

SD Stamp Duty FRCA

SRT Social Responsibility Tax FRCA

STT Service Turnover Tax FRCA

TL Telecommunication Levy FRCA

TPIL Third Party Insurance Levy FRCA

VAT Value Added Tax FRCA

WHT Withholding Tax FRCA

4.4 General Requirements

The recent trends in the international community show that most countries have realized that for the Tax

Authority to obtain and maintain the positive recognition of society, such Authority must act fair and equal and

must collect the public revenue with a maximum efficiency that can be mobilized at any time in terms of legal

provision, skilled organization and timely and accurate information on taxpayers (meant in generic terms as an

individual or an organization contributing a public revenue of any kind). The above approach is currently

monitored using the TADAT Framework which provides assessment through monitoring the nine performance

outcome areas and their associated indicators to assist a revenue administrator - identify administrative strengths

and weaknesses; facilitate a shared view among all stakeholders; with setting a reform agenda; as well as

facilitate the management and coordination of external support for reforms together with providing a basis for

monitoring and evaluating progress.



Diagram: The TADAT Framework

Proposals should refer to best practices experienced for the integrated tax information systems implemented.

4.4.1 Summary of General Requirements

GR Requirement outline Origin

1 The new system must incorporate, as far as practically possible and economically

justifiable, the existing components and as much functionality as possible to be

available in a single integrated system such as a Data Warehouse, web portal etc.

as integrated components and not as tack on options for later purchase.

FRCA

1.1 Re-use of the application should be based on proper mapping of existing

applications in the new concept and evaluation of the possibility of re-using them

in the system.

FRCA

2 The new system must be customisable. Generic.

2.1 The new system must be built on a standard framework of core features and

layers for the customization, which as far as possible should be done following a

configuration approach rather than one based on individually designed and

specifically developed components.

Generic.

2.2 Use of configurable Reference table maintenance, non-exhaustively including:

Tax period definition & management.

Tax type rates maintenance.

Tax type maintenance.

Interest rate (or equivalent instrument) management.

Management of various charges and penalties.

Region maintenance and tax office maintenance.

Return type maintenance.

Transaction type maintenance.

Employee maintenance.

Generic




Reasons maintenance.

Adjustment type maintenance.

FSIC code maintenance.

Transaction class maintenance.

Registration status maintenance.

Registration reasons maintenance.

Case type code maintenance.

Criteria type code maintenance.

3 The new system must provide full history of reference data. Generic




4 The new system must provide a full suite of tax related functionality including a

comprehensive Risk Management System component.

Generic

5 The new system must provide comprehensive data exchange capability for

systematic exchange of relevant data internally (e.g. ASYCUDA World, SUN,

HR21) as well as with other public authorities and private sector 3rd

party

information providers.

Generic

5.1 This involves several external entities: RBF, Investment Fiji, Local Governments,

CAAF, Ministry of Lands, MoF, Bureau of Statistics, MoJ (Registrar of

Company, Registrar of Titles and Birth, Death & Marriage), DoI, LTA, Banks,

REALB and Telecommunication Providers, etc.

FRCA

6 The new system must provide comprehensive Case Management and tracking

capability features.

Generic.

7 The new system must provide comprehensive Document Management. Generic

8 The new system must provide comprehensive MIS, comprising predefined

reports, ad hoc queries and ad hoc report generation.

Generic.

9 The new system must provide support for processing paper based information as

well as electronic processing, i.e. e-filing, e-payments, enquiries, bilateral

exchange of data with taxpayers, etc.

Generic.

10 The new system must provide comprehensive documentation, including system

administration and maintenance literature and user guides. It is required that

online training and all support documentation must be available electronically and

that these must be able to be maintained on an ongoing basis in an effective and

efficient manner.

Generic.

10.1 User manuals must be available as a comprehensive onscreen context sensitive

help system.

Generic.

10.2 System maintenance and operations related manuals to be provided in electronic

form and hard copy.

Generic.

10.3 As a minimum, the following functionalities are generally required for all

overviews and reports:

Screen display.

Appropriate hardcopy printout.

Selected data export.

Mandatory electronic data submission.

Reasonable set up of restrictions and criteria.

Smart search by chosen fields.

Sorting settings.

Saving and selection of prepared settings for shared use.

Generic.

11 The new system must be fully operational by the end of 2016 with migration of its FRCA




selected components from 2015

12 The new system must be able to import and export data in various formats with

clear data migration plans and a proposed best practise migration model clearly

defined.

Generic.

13 There must be substantial public awareness about the new system. Generic

14 The analysis of tax processes and product optimization regarding the specifics of

the tax process is required.

Generic

14.1 Mapping of current BP presenting "as is" situation. Generic

14.2 Proposing relevant modernization and optimization of all business critical

processes based on the vendor's own reference model and recognized best

practice.

Generic

14.3 Preparing BP model, which includes simulation of automated processes. Generic

15 All user screens, user manuals, and basic technical system support in English

language. The basic configuration ensures that there is no need to create new

program versions for language versions.

FRCA

16 The proposed system should support multi-lingual solution just as all user screens,

user manuals, and basic technical system support must be provided in the English

language.

FRCA

17 The new system must ensure secure, authorised and auditable/traceable access to

taxpayers' data, which in principle and by nature is sensitive and should be

protected accordingly;

Generic

17.1 Vendors may propose use of recognized products for the purposes of

authorization and authentication.

Generic

18 The User Administration module of the new system must use the domain and

privilege of the system administrator, who in turn may assign a subset of his

rights in accordance with security requirements to the so-called advanced users.

Generic

19 Comprehensive risk management is mandatory. Generic

20 The new system should be configured for electronic filing of purchases/sales

books. Generic

21 The new system should be configured for electronic filing of payroll lists and all

related evaluations (business rules applicable). Generic

Table: Main general requirements

4.5 System Architecture and Design Approach

This section provides requirements for selected technical elements related to the new COTS architecture and

design approach. A general view of the new system is based on expectations that it will satisfy all of the

following main demands:



The new system's architecture will consist of two main layers, i.e. the internal COTS specific

architecture and common services provided by relevant governmental institutions.

The internal COTS specific architecture will be formed by the core tax information system, potentially

a standard or standardized system, integrated at adequate level with the selected components from the

existing IT structure.

The new system must be designed to satisfy the demands for:

1. Multi-tier architecture comprising separate layers for presentation, business logic and database

management.

2. Web based multilingual user interface utilizing a thin web client.

3. Web services provided by loosely coupled components.

4. Business logic layer driven by business rules – a precondition for fulfilling the ambition of national

customization mainly through configuration rather than through (re-)design and (re-)development.

5. Compliance with the Logical Information Architecture Model (LIAM) for integrated revenue

management.

The following diagrams depict a simplified system architecture model; outline the multi-layer system

architecture and present the LIAM built upon the Taxpayer-per-Tax type-per Tax period (TTT)

principle.

The new system architecture should include currently required services and should be able to include

any number of future services within the same service layer. These services should be configurable

based on business rules reflecting the legislative acts.



Diagram: General IT system architecture based on rigid access control and common service bus

The above concept is illustrated in the next diagram outlining the IT multi-tier architecture, comprising web

services objects (presentation layer), business logic layer, and data access objects layer connecting through

appropriate mechanisms to the applicable database structures.

Authorized users & FRCA Staff General public

Access control

Registration Declaration

filing & payments

Compliance Control

Audit prep . & recording

Case mgmt . & workflow

FAQ & enquiry

Download & upload Other

S 1

S 2

S 3

S 4

S 5

S 6

S 7

S n

Business rules for all services

Live Transaction

DB Analytical Data DB

E - Archive

Services according to access rights

Temporary data repository for services

Central Databases

FRCA ITIS Acaquisition Preliminary generic user requirements Version: 0.8

P. Menhard 26 March 2014 Page 21 of 67

Diagram: The multi-layer system architecture

DBMS1

DBMS 2

DBMS n

ODBC/JDBCconnection/

command

object (DBMS 1)

Business logic object

(of type: aggregating

data from more DBs)

ODBC/JDBC

connection/

commandobject (DBMS 2)


command

object (DBMS 2)


command

object (DBMS n)

Business logic

object (of type:

retrieve data from

one DB)

Business logic

object

Business logic

object

Presentation

object

Presentation object

Web services

object

Web services

object

W

E

B

S

E

R

V

E

R

Client WS

Web brow ser

Client WS

Other applications

or other Web

services

http/s request/ response

SOAP request/ response

ODBC/JDBC

compliant DBs

ODBC/JDBC

connection

Data access

objects layer

Business logic

objects layerPresentation objects (& Web

services) layer

Inet/https/

SOAP

A

P

P

L

I

C

A

T

I

O

N

S

E

R

V

E

R

D

B

M

S

S

E

R

V

E

R

Multi-layer System

Architecture



Another significant feature to be mandatory and generally included in the new COTS design is the relations

amongst taxpayers, tax types and tax periods according to the Taxpayer-per-Tax type-per Tax period (TTT)

principle, as shown below.

Diagram: The TTT principle based object model

The application of the TTT principle is depicted in the next diagram outlining the logical information

architecture model (LIAM). The model also includes the accounting modules, the taxpayer accounting, revenue

accounting, as well as it indicates incoming and outgoing data streams in relation to taxpayers and others FRCA

shareholders. For the sake of completeness the diagram also includes (below the red line) the functional

components normally belonging to the Ministry of Finance domain, meaning these components are outside the

scope of this project, while the data exchange interfaces from and to are within the same scope.

Diagram: The LIAM implementation of the TTT principle

4.5.1 Summary of Requirements Related to the System Architecture and Design

The above outlined aspects are elaborated in the following specific requirements.

SA&D Requirement outline Origin

1 The new system must have flexible architecture and provide for scalability, i.e. ability to

add resources without changes to the architecture. Generic

Taxpayer several Tax typesmay have

liabilities for Tax periodfor each there is

uniquely defined

Taxpayer Registration

Taxpayer Accounting

Tax-type

registration

Tax-type

assessment

General

registration

Tax-typ

#1

Tax-typ

#1

Tax-typ

#2

Tax-typ

#2

Tax-typ

#3

Tax-typ

#3

Tax-typ

#N

Tax-typ

#N

Tax

pay

er M

ailb

ox +

Doc.

/Form

s

Arc

hiv

e

Payment

+

Refund

Taxpayer

Taxpayers

(banks) Receipts PaymentsCash Flow Mgmt

(TSA)

Revenue

Accounting

Expenditure

Accounting

Government

Budget

Governmental Mailbox +

Document / Forms Archive Suppli

er M

ailb

ox +

Doc.

/ F

orm

s A

rchiv

e

Government Ministries and Agencies (Spending Agencies)

Suppliers

Payment

+

Refund

Accounts receivables

Suppliers

(banks)

Gov. employees

(banks)

Social

beneficiaries

(banks)

Non-Tax

Revenue

Rev.type Rev.type Rev.type Rev.type




1.1 As a part of scalability, a maximum virtualization is required, e.g. access to admin tasks

should be granted based on login credentials from any computer in the system, without

the tools used for the purpose being physically present on it.

Generic.

1.2 Preferably, this should include the management of application as well as DB

management.

Generic

1.3 Separate layers for presentation, business logic and DB management. Generic

1.4 Multi-tier system architecture adhering to the SOA principles and standards for

providing a flexible way to combine and use multiple components executed on different

operating systems, technical platform, etc.

Generic

1.5 Web services provided by loosely coupled components and utilizing a thin web client. Generic

1.6 Assuming a web based application, the system should support ―Cascading Style Sheets‖

technical specification for presentation layout of documents.

2

The new tax system must be designed and implemented strictly according to the LIAM,

so as to grant consistent relations between various components (e.g. registration and

accounting) of the system.

Generic.

2.1 In terms of the functional structure, the new system must be designed and implemented

based on modularity principles and depicting the logical flow of information amongst

the functional modules

3 Common (unique) taxpayer identifier is mandatory. Generic.

3.1 Used throughout the system in order to maintain unique identification of tax liabilities

and ease the administration.

Generic.

4 Common double entry book keeping accounting is mandatory. Generic.

4.1 Should be based on the established international accounting standards. Generic.

4.2 Should facilitate daily operations of the authority with respect to the taxpayer

management and tax revenue collection.

Generic.

5

In terms of internal business logic, the new system must be designed and implemented

strictly according to the Taxpayer-per-Tax type-per Tax period (TTT) principle, so as

to grant consistent relations between a taxable body and its obligation for reporting and

paying taxes and non-tax collectibles.

Generic.

5.1 This conformity is required for consistent and direct drill-down to the lowest level of

details kept in the taxpayer ledger and in the associated files, i.e. returns data,

assessment data, payment data, etc.

Generic.

5.2

In terms of the functional structure, the new system must be designed and implemented

based on modularity principles and depicting the logical flow of information amongst

the functional modules.

Generic.

6 Common revenue accounting is mandatory. Generic.

6.1 Provides a complete overview of revenue accounting on the aggregate level and

Generic




decomposed to the individual tax types and further broken down, as a minimum, to its

main sub-components, i.e. (value of) principal tax, interest, penalty, administrative

charges.

Table: Summary of requirements related to the COTS architecture and design

4.5.2 Analysis of Existing IT Components

Number of

registered

taxpayers

Number of filers Number of filed

declarations

Number of

payment

transactions

700,956 170,824 166,223 121,563

Table: Declarations and payments volume for 2013

4.5.3 Integration Approach

The new system should have an integrated platform for connecting different parts of the system and connecting

with external systems. The next diagram shows the current IT system and sub-systems that need to be fully or

partially replaced. The most appropriate methods of integration with the existing environment must be defined.

Integration must be implemented in the following ways:

- Data level: Data server data server;

- Application level: On the level of application interfaces and web services;

- On user interface level.

Basic guideline for selection of the integration method should be the use of standard technologies and interfaces,

reliability, security and simplicity of the technical solution.

Some of the existing sub-systems will need to be incorporated with the new system in order to offer the single

point of information to all users. Transformed into a high level functional architecture, the next diagram outlines

the functional blocks of the "standard system" with those to be provided through integration, enhancements or

replacements of the existing components.



4.6 Functional Model

Observing the established best practices and experience from the integrated tax information systems, the

functional model should satisfy the main processing and functional logic and information flow outlined below.

Diagram: Envisaged general functional structure and main information flow

4.7 Functional Requirements

This section outlines the main functional requirements for the affected operational areas sub-divided into:

Taxpayer registration.

Assessment and payments of tax obligations.

Taxpayer compliance monitoring and enforcement.

Taxpayer objections and appeals.

Arrears collection and debt management.



4.7.1 Summary of Functional Requirements Related to the Taxpayer Registration

Based on the LIAM principles and architecture presented in the previous section, the taxpayer registration

requirements are summarised as follows.

TPR Requirement outline/ Suggest review of table breakdown from 2 to 5.2 Origin

1 The new system must facilitate general taxpayer registration of NPs and LPs

according to the above depicted BPs. Generic

1.1 Applying a unique identification number for each registered entity. Generic

1.2 Preventing multiple registrations of the same taxpayer, using all available

means of identification confirmation.

Generic

1.3 Linking uniquely the taxpayer (taxable subject) with relevant tax types

(taxable objects) and their respective reporting period.

Generic

1.4 Including FSIC classification of economic activities where appropriate for

the registered taxpayer.

Generic

1.5 Creating registration status and recording of registration mode, i.e. counter,

e-lodgement and mail room.

Generic

1.6 Creating the initial taxpayer profile and updating it according to the

registration mode.

Generic

1.7 Issuing appropriate registration notification by email or postal letter Generic

2 The new system must facilitate tax type specific registration of taxpayers.

Generic

2.1 Logical control of tax types available for assignment according to the NP

vs. LP and organizational structure and nature of business of the registered

entity.

Generic

2.2 Supporting the control of entitlement to certain tax type registration, e.g.

VAT registration cannot apply to a salary wage earner taxpayer.

Generic

2.3 Issuing appropriate tax type registration certificates (e.g. VAT) notification. Generic

2.4 Enabling periodic inactivation and reactivation for a given tax type. Generic

3 The new system must facilitate tax type specific inactivation and

deregistration Generic

3.1 This applies to NPs and LPs. Generic

3.2 The new system must facilitate special deregistration of taxpayers cases e.g.

Business t/p (registered for VAT) to be deregistered only after flagging from

Audit.

Generic

4 The new system must facilitate comprehensive enquiry and reporting on all

registration/deregistration data. Generic

4.1 Using predefined and ad hoc reporting features as well as Business

Intelligence functions.

Generic

5 The new system should have a Single View Of Customer (SVOC) with

provision for photo id for NPs and LPs

Generic

6 Record Of Action (ROA) should be available in all modules whereby

applicable reports can be generated

Generic



TPR Requirement outline/ Suggest review of table breakdown from 2 to 5.2 Origin

7 Ability to maintain the history of contacts and other personal information

for assistance and further analysis including who and when changes were

made.

Generic

8 Electronic signature capturing capability provision Generic

Table: Summary taxpayer registration requirements

4.7.1.1 Taxpayer Registration - Selected Details

TPR-D Required function

Expected provided by / through


1 Allocate the TIN to a new registrant uniquely identifying

the taxpayer.

Y Y Y

2 Capture and store TIN registration details. Y Y

3 Store FSIC industry code for all TIN registrations with

the possibility of multiple FSIC classification entries.

Y Y Y

4 Capture and store specific registration details for

different tax types.

Y Y Y

5 Maintain and update taxpayer status (active, inactive,

deregistered, etc.)

Y Y Y

6 Allow retrieval of de-registered taxpayer details that has

been archived.

Y Y Y

7 Search taxpayer register by name, trading name, address,

Birth registration number, death registration number,

TIN, and other registration data items.

Y Y Y

8 Produce name and address details for bulk mail-out

exercises according to predetermined criteria for address

labels and pre-printed stationery. This could be for all

taxpayers, individual taxpayers, or selected taxpayers.

Y Y

9 Create and maintain meaningful links to other registered

entities e.g. owners, directors, spouses, related

companies, etc.

Y Y Y

10 Enquire on data or print reports of linked entities. Y Y

11 Cross reference to other official numbers or codes. Y Y

12 Create, maintain and enable viewing of the ‗situation

summary‘ information, indicating on-going audit, open

assessments, suspense items, appeals, bankruptcy,

internal arrangements as a part of the global risk profile.

Y Y

13 Ability to capture, store, and retrieve bank account and

routing information.

Y Y Y

14 Ability to provide maintenance of taxpayer preferred

contacts and agents with effective dating. For bulk

postings, system must include the right or applicable

Y Y



TPR-D Required function



address

15 Ability to support document exporting into PDF, TIFF,

file formats, etc.

Y Y

Table: Selected details of taxpayer registration requirements

4.7.2 Summary of Functional Requirements Related to the Assessment and Payments

Strictly applying the LIAM principles, the taxpayer assessment and payment requirements are summarised as

follows. Consideration to include electronic stamp facility.

A&P Requirement outline Origin

1 The new system must facilitate recording and management of taxpayers´

liabilities originating from returns, assessment (Self-assessed and FRCA

assessed taxes) and various adjustments. The system should capture all tax

types including Stamp Duty & CGT and integrate with ASYCUDA World.

Generic

1.1 Paper based documents and electronic records received from taxpayers or

generated by the tax officer.

Generic

1.2 All relevant validations, formal, logical, arithmetic and probability check

based on configurable predefined criteria, historic data and other relevant

information sources.

Generic

1.3 Maintaining archive of digital copy of all assessment documents. Generic

1.4 Maintaining analytic data in an appropriate repository. Generic

1.5 Forwarding the aggregated assessment result to the taxpayer accounting

module.

Generic

2 Generation of automated assessment reminders to late-filers. Under current

portfolio management, two reminders of current lodgment & payment dues.

Generic

2.1 Must facilitate an automated system created assessment of late filers /non-

filers as well as an accompanying generated demand letter to be sent based

on configurable predefined criteria, historic data and other relevant

information sources.

Generic

3 An assessment officer is able to adjust or overrule the automated system

before and after assessment especially for self-assessment returns. The

system must allow for electronic & interactive transactions.

Generic

4 The new system must facilitate generation and submission of payment

orders for self-assessed and FRCA assessed taxes with applicable automated

system generated notifications sent for EMS raised; payables due; etc.

Generic

5 The new system must facilitate recording and management of payments

received from taxpayers and refunds made to taxpayers. Generic



A&P Requirement outline Origin

5.1 Includes payment made at the bank, and payments performed electronically. Generic

5.2 All cash & cheque payments accepted by the FRCA. Generic

5.3 Generation of automated payment reminders to late-payers. If there is a

TTPA (Time To Pay Arrangement), reminders should alert installments due

for that month.

Generic

5.4 Linking with the collection module for initiating the collection case of

unpaid obligations.

Generic

5.5 Linking with the compliance module for alert and flagging non-compliance,

including updating the taxpayer profile.

Generic

6 The new system must facilitate complete cycle of refunds processing.

Generic

6.1 Verifying the entitlement to refunding. Generic

6.2 Linking with risk module for credibility control of claim. Generic

6.3 Issuing a notice of approval or rejection (Audit) of refund claim. Generic

6.4 Issuing payment orders to MoF for all approved refund claims. Generic


assessment and payment data. Generic

7.1 Using predefined and ad hoc reporting features as well as BI functions. Generic

Table: Summary taxpayer assessment and payment requirements

4.7.2.1 Returns Management - Selected Details

RM-D Required function



1 Provide all functions relating to the processing of returns

within the system including:

1.1 Determining whether a return for a particular tax type

should be expected from a taxpayer. This includes a ―NIL

Return‖. Business Rule includes flagging of multiple NIL

linked to non-lodgers.

Y Y Y

1.2 Receiving returns. Explore the capability of using barcodes

and scanners for uploading of returns received manually.

Y Y Y

1.3 Computing & posting tax liability. Y Y Y

1.4 Reversing returns. Y Y Y

1.5 Processing and reprocessing returns and to be incorporated

in the ACCU/Audit function.

Y Y Y

1.6 Viewing returns. Y Y Y



RM-D Required function



1.7 Viewing filing history. Y Y Y

1.8 Raise a default assessment based on previous returns.

Automatic calculation of liability for a default assessment.

Based on proper rules.

Y Y

1.9 Impose late lodgement penalty, when the lodged return is

overdue or when the default assessment is raised.

Y Y Y

1.10 Ability to view all returns filed at the period level, account

level, or entity level.

Y Y Y

1.11 Ability to allow posting of informational, zero balance,

negative balance and positive balance returns.

Y Y Y

1.12 Provide user modifiable table for validation and posting

rules.

Y Y

1.13 Ability to capture and store return amendments with full

history and linking to the original declaration.

Y Y Y

1.14 Ability to process returns with or without payments.

EMS/PT – cannot process Commissioners Assessment/

Form B & C without PAYE/PT payment.

Y Y Y

1.15 Ability to recognise and prevent duplicate returns. VAT

return lodgement based on taxable period of lodgement.

Y Y Y

1.16 Ability to record the received/postmark date and process

date for all returns.

Y Y Y

1.17 Ability to display taxpayer original and revised (system

calculated) data.

Y Y Y

1.18 Ability to generate electronic receipt for electronic returns. Y Y

1.19 Record and maintain location of paper returns and files. Y Y

1.20 Ability to validate specified lines of a return based on

configurable rules.

Y Y Y

Table: Selected details of taxpayer return management

4.7.2.2 Payment Processing - Selected Details

PP-D Required function



1 Receive payments by a number of payment method

options.

Y Y Y

2 Capture TIN, tax type, payment date, payment method,

instalment number, payment amount, receipt number,

source document ID.

Y Y Y



PP-D Required function



3 Determine the due date for the payment. Y Y Y

4 Update taxpayer and revenue accounts. Y Y Y

5 Calculate late payment penalties and notify taxpayers of

late payment.

Y Y Y

6 Process unidentified payments (will arise when TTT

payment detail is not present, or is incorrect).

Y Y

All unidentifiable payments can be clearly recognized. Y Y Y

The payment is accounted for in all payment

reconciliations.

Y Y Y

The payment is held on an appropriate suspense account

until full TTT identification.

Y Y Y

Enquire lists for the unidentified payment for manual

resolution.

Y Y Y

Transfer resolved payments to the correct taxpayer

account.

Y Y Y

7 Provide for history of all manipulation to a record (e.g.

Transfer history, Error corrections, etc.).

Y Y Y

8 Provide payment deferral and payment of tax in

instalments for predefined volume and frequency based

on business rules and regulations.

Y Y Y

9 Enable instalment calculation for TTT based on business

rules and regulations.

Y Y Y

10 Facilitate new payment (posting) methods e.g. posting

by third parties such as post offices, banks, e-PAY,

internet, direct bank transfer, etc..

Y Y

Table: Selected details of taxpayer payment processing

4.7.2.3 Taxpayer and Revenue Accounting - Selected Details

AC-D Required function



1 Create and maintain a Chart of Accounts Y Y

2 Account for all debits / credits for all taxpayer, tax types

tax period (TTT)

Y Y

3 Maintain a common account posting structure for all

debit and credit transaction types.

Y Y

4 Post debits and credits to taxpayer and revenue accounts

using a common accounting ―engine‖ (double entry

book keeping).

Y Y

5 Enable ―suspense‖ accounts for unidentified payments,

and the ability to transfer payments from the suspense

Y Y






account to a taxpayer account.

6 Allow enquiry on all details of a taxpayer‘s account. Y Y

7 Dissect the taxpayer‘s account for each tax type into

principal tax, penalties, interest etc.

Y Y

8 Presentation of the aggregated taxpayer‘s account

balances across all tax types or/and tax period.

Y Y

9 Identify the individual outstanding debts. Y Y

10 Identify debts by age. Y Y

11 Generate a statement of account for a particular tax type

for a taxpayer in total and for a given period of time and

dissecting primary tax and penalties.

Y Y

12 Generate a statement of account across all tax types for a

taxpayer in total for a given period of time, dissecting

primary tax and penalties.

Y Y

13 Offset credits and debits within a tax type and between

tax types according to the configurable business rules

(coverage sequence).

Y Y

14 Display tax arrears on Notices of Assessment and

Statement of Tax Accounts issued to taxpayers for both

the particular tax type in question, and all tax types.

Y Y

15 Ability to create Account for Branches of a taxpayer‘s

organisation and for individual entity and aggregated for

the entire branch according to the configurable business

rules.

Y N

16 Automatically calculate penalty on overdue debts from

the due date according to the configurable business

rules.

Y Y

17 Ensure that account postings are never deleted or

adjusted – they are reversed to provide a trail for both

understanding of the account and for audit purposes.

Y Y

18 Provide a variety of miscellaneous account adjustment

transactions designed to accommodate many purposes

and maintain the taxpayer‘s account, e.g. transfers,

adjustments, bad debts, dishonoured cheques, refunds

etc.

Y Y

19 Debit the taxpayer account for the amount of refund. Y Y

20 Identify amounts in dispute and amounts where there is

an application for taxation release.

N Y

21 Identify amounts in the accounts subject to legal action. N Y

22 Ability to apply notations to accounts e.g. bankruptcy,

and apply the appropriate business rules where the

notations are present.

N Y

23 Allow for payment of outstanding tax by instalments. Y Y

24 Allow periodic maintenance activities which are related

to accounting changeover periods such as a new

accounting year, archiving etc.

Y Y

25 Ability to propose and automatically perform

appropriate offsets prior to refund issuance according to

configurable business rule.

Y Y






26 Ability to provide for paying interest on delayed

refunds.

Y N

27 Ability to group multiple overpayment periods for one

taxpayer into one refund.

Y Y

28 Ability to reflect that cancelled or voided refunds were

not disbursed.

Y Y

29 Ability to split an overpayment into a credit, refund and

possibly donations.

Y

Table: Selected details of taxpayer and revenue accounting

4.7.3 Summary of Functional Requirements Related to the Compliance Monitoring and Enforcement

The Authority‘s Intelligence-Led Risk-based Compliance Strategy has identified the areas of specific

focus/criticality. Through this, an annual risk management strategy is prepared and maintained together with its

annual audit plan. The main compliance actions are subdivided as shown below:

Primary (operational) compliance enforcement, dealing with:

Widening the taxpayer base (register related).

Filing compliance, dealing with late filers reminding and sanctioning, but also responsible

for officer/system raised assessment, when no return is received.

Payment compliance, dealing with late payments reminding and sanctioning, but also

managing the instalment arrangements, and interacting with forced collection functions.

Secondary compliance enforcement, dealing with:

Individual risk assessment, also using extensively 3rd party information e.g. MOF, Bureau

of Statistics, MOJ (Registrar of Company, Registrar of Titles and BDM), REALB, DOI,

LTA, Banks and Telecommunication Providers etc.

Risk based audit selection and assignment of audit teams.

Comprehensive audit preparation, based on own data as well as taxpayer's records.

Collection compliance, dealing with defaulted taxpayers, also those defaulting the

instalment arrangements, and responsible for debt protection and forced recovery.

Extended concept of taxpayer services focusing on:

"Marketing" of voluntary compliance benefits.

Informational/educational activities offered to the compliant and "would like to comply"

taxpayers.

Sanctioning of noncompliance, where sanctions should be proportional to the gravity of

contravention.

Proposing legal steps and action against taxpayers exercising activities of a criminal

nature and therefore falling outside the administrative rulings.

The functional requirements related to the compliance monitoring and enforcement are summarised as follows.

CM&E Requirement outline Origin




1 The new system must provide support for strategic compliance monitoring Generic

1.1 Preparation, maintenance and internal distribution of the annual control

plan, comprising document review, item checks, thematic and

comprehensive audit actions.

Generic

1.2 Annual audit plan to be prepared on variable and configurable parameters,

such as number of calendar days available, number of staff available,

duration and complexity of an action according to the category.

Generic

1.3 Applying an approximate split of 60% of cases based on risk assessment,

30% based on other criteria and 10% assigned by random selection.

Generic

2 The new system must provide support for the strategic extended taxpayer

services. Generic

2.1 Preparation, maintenance and internal distribution of the annual service

plan, comprising educational visit, information material (printed and

electronic), first level debt collection, publishing and maintenance and of e-

portal including FAQ, campaigns and other voluntary promotional actions.

Generic

3 The new system must facilitate compliance monitoring and sanctioning of

operational non-compliance (non-filer, late-filer, non- or late payment). Generic

3.1 Receiving alert of non-compliance through workflow from the Assessment

module

Generic

3.2 Opening of an audit case according to configurable predefined parameters.

Need to review the current parameters.

Generic

4 The new system must facilitate audit support including risk management and

risk based audit selection. For details see the narrative requirements in the

foregoing section. Need to review the parameters. Ad hoc enquiries.

Generic

4.1 Maintaining risk profiles, i.e. the individual risk profiles (IRP). Generic

4.2 Propose selection of audit targets according to the selection split rules and

risk assessment.

Generic

4.3 Opening of an audit case for audit targets confirmed by the audit manager. Generic

4.4 Propose a list of documents and all other information relevant for the audit

case preparation, including available intelligence.

Generic

4.5 Assigning audit teams for the selected cases. Generic

4.6 Performing various business related and financial analysis. Generic

4.7 Updating the audit plan. Generic

4.8 Submitting audit notification to the taxpayer. Generic

4.9 Uploading (or linking) relevant data and documents onto the auditor's

computer.

Generic

4.10 Creating audit log for auditor's findings and observations. Generic

5 The new system must support the preparation and processing of audit report,

using case management and workflow functions. Generic




5.1 Updating the accounts of the audited taxpayer. Generic

5.2 Updating the risk profile of the audited taxpayer. Generic

5.3 Interactively updating the risk analysis and assessment model according to

the detected hit rate in each audit case.

Generic

5.4 Updating the performance statistics according to configurable predefined

values. Need to review the current parameters.

Generic


audit case related data. Generic

6.1 Using predefined and ad hoc reporting features as well as BI. Generic

Table: Summary of requirements related to the compliance monitoring and enforcement

4.7.3.1 Risk Management Related Requirements - Selected Details

The risk analysis and assessment module are envisaged to be available through a fully integrated RMS module.

A holistic approach towards the RMS can be translated into a Compliance Strategy Model as well as a Strategic

Risk Management Cycle (SRMC):

Have decided not to comply

Don’t want to comply,but will if we pay attention

Try to but don’t

always succeed

Willing to dothe right thing

Use the full force of the law

Deter by detection

Assist to comply

Make it easy

Our strategies aim to create pressure down

Attitude to compliance Compliance strategy

0

1

2

3

4

5

6

7

8

9

10

Psychological

IndustryBusiness

Sociological Economic

Taxpayer

Psychological

IndustryBusiness


Taxpayer

Factors influencing taxpayer behaviour

Have decided not to comply

Don’t want to comply,but will if we pay attention

Try to but don’t

always succeed

Willing to dothe right thing

Use the full force of the law

Deter by detection

Assist to comply

Make it easy

Our strategies aim to create pressure down

Attitude to compliance Compliance strategy

0

1

2

3

4

5

6

7

8

9

10

Psychological

IndustryBusiness


Taxpayer

Psychological

IndustryBusiness


Taxpayer

Factors influencing taxpayer behaviour

Diagram: Compliance Strategy Model

2. Identifying Risks & Opportunities

3. Developing Strategies & Priorities

4. Business Plans &Performance Indicators

5. Program Execution

Program

Monitoring

Program

Evaluation &

Reporting

Vision of Successful Revenue Administration

1. Developing Strategic Goals

and Objectives

Diagram: Strategic Risk Management Cycle Model



Box 3 in the above diagram indicates the home of the overall compliance strategies giving the space to the

nationally specific priorities. The strategy should have a scope sufficiently wide to accommodate and support

(normally annual) Business Plans (Box 4), which from year to year may differ and target various sectors of the

business community, thus ensuring reasonable coverage of economic activities as envisaged by the overall

strategy.

The performance indicators (Box 4) are established mainly as the dual sides of a coin: a) risk indicators, on one

side, enabling the risk profiling of taxpayers/traders and monitoring of compliance performance; and b)

indicators of the performance of the risk system itself on the other.

While the above indicated top-down approach provides the possibility for balancing the treatment method with

appropriate proportioning of taxpayer service and compliance enforcement, the latter one requires additional

analytic elements for detection of the most risky individual taxpayers.

The individual risk analysis may be applied to the business sectors selected in the top-down approach, it may

however also be considered as an analytical tool applied generally across all sectors and thus indirectly

supporting the effort of detecting the sectors deserving specific attention.

On these grounds it is requested that the proposed solution should provide a RMS module that enables the

functionality for the individual taxpayer risk analysis comprising the below listed elements.


1 Creation and maintenance of analytical models. Generic

1.1 Industry risk profile (IRP) maintained on the basis of risk value assigned to

the trade class groups. In this context, the commodity code classification

(normally in use by Customs) is considered inadequate for the IRP tax

control objectives, but rather the FSIC (Fiji Standard for Industrial

Classification) coding should be used. Include ASYCUDA WORLD and

other Law Enforcement Database risk engines integration.

Generic

2 Regular update of risk and segment information for operational systems. Generic

2.1 General taxpayer risk profile maintained on the basis of IRP risk indicator

(trade class inherited risk) with addition of the taxpayer‘s individual risk

indicators.

Generic

2.2 Tax type related risk elements including the risk assigned to the specific

type of transactions, such as tax credit in general reimbursements and VAT

refunds in particular.

Generic

3 Provision of case selection candidates for processing. Need to review the

current parameters and automate and improve data capture. Data cleansing

validation checks.

Generic

3.1 For the purpose of assessment of general tax compliance of a given

taxpayer, the applicable elements should comprise inter alia the following

grouping of risk relevant information:

1. Data from the tax returns – ideally seven years history of all main

taxes should be available for the purpose of comparison.

2. Financial statement data - ideally a seven year comparative

history.

3. Compliance history over a reasonable period of time.

4. Third party information (as appropriate and available).

5. Leads and intelligence information.

Generic




6. Specific risk assessment data i.e. risk parameters, risk level, etc.

7. Economic sector benchmarks compared with the taxpayer‘s

accounts (e.g. VAT ratio, gross profit ratio, net profit ratio, etc.).

3.2 For the purpose of the tax type related risk assessment and analysis, the

following main indicators are normally sufficient at earlier stages of the

implementation.

If there are outstanding balances in any of the tax types comprised in the

risk profiling facilities, then this is risk-indicative.

If previous audits of any tax type resulted in tax uplift, this may indicate

possible risk. Analogue, if previous audits led to no adjustments, this

may indicate a lower risk.

If penalties were charged to the taxpayer, then this indicates possible

risk.

Gap filing, late filing or periods in default in particular, where

surcharges exist, this is risk-indicative.

History of late or missing payments in any tax type also indicate risk.

Financial statements analysis can provide significant risk indicators. The

following financial statement ratios will be useful in detecting risk:

1. Fixed assets. When the ratio of fixed assets to gross revenues is

low (e.g. 15% below the benchmarked average), there is a possible

compliance risk.

2. Liquidity checks based on the current capital ratio. This is

calculated as the value of current assets divided by the value of

current liabilities. A ratio above 2 generally indicates adequate

working capital while a ratio below 0.5 in connection with

decreasing net profit indicates risk.

3. Salaries and wages as a percentage of gross revenues.

Benchmarking by economic sector may determine whether the

salary and wages are in line with reported revenues. If revenues

are lower than expected, the condition is risk-indicative.

4. High risk expense items. Where significant amounts are claimed

against high risk expenses such as dubious or bad debts, the

expense items are risk indicative.

Generic




3.3 Two commonly applied benchmarks for assessing the presence and to some

extent the level of risk are shown below. The tolerance limits for

determining the risk are expressed as percentage (e.g. 15% below the

average), or as absolute material value (e.g. at least xxx,xxx.xx below the

benchmark):

1. Gross profit ratio. This ratio is simply the gross profit divided by net

sales. Reporting a gross profit substantially below the sector average

(e.g. 15% below), this should be considered as being risk indicative

and it may indicate detection of suppressed revenue.

2. Net profit ratio. This ratio is defined as the net operating profit (or

loss) divided by the net sales. Similar to the gross profit test, reporting

a net profit ratio substantially below the sector average may indicate

the non-compliance risk.

Generic

3.4 The following risk parameters can be used to assess risk associated with

history trend normally assessed over a period of seven consecutive years:

1. An annual decrease of more than 15% in gross earnings is risk-

indicative.

2. An annual decrease of more than 15% in the gross or net profit is risk

indicative.

3. If the profit tax or income tax turnover figures in the latest year were

below the comparable VAT supplies figures, then this is risk-

indicative.

Generic

3.5 Apart from the above listed risk indicators, which to certain extent can all

be further parameterized, and thus can be created and maintained in

automated way, the following less tangible indicators should be used as

complementary elements when assessing the risk profile of a given

taxpayer:

1. The lead ‗bank‘ should be checked during the screening of tax files.

The presence of relevant leads should be factored into the final

decision to select a case for audit or not.

2. Additionally, cross-comparison to other relevant databases can be

factored into audit selection decisions.

3. Continuous operating losses are risk-indicative.

4. Declining net income in combination with the presence of any

outstanding balance is risk-indicative.

Generic

Table: Summary of risk management related requirements

4.7.4 Summary of Functional Requirements Related to Collection and Debt Management

The functional requirements related to the collection and debt management are summarised as follows.

C&DM Requirement outline Origin

1 The new system must facilitate debt collection, including debt protection

instruments, along with classic collection features such as calculation of

penalties, interest, and management of instalments payment arrangements.

Generic

1.1 Automated creation of a collection case according to configurable

predefined events and using case management, workflow and document

Generic



C&DM Requirement outline Origin

management features

1.2 Assessment of debtor's payment capability considering financial means and

sellable assets and updating the collectability status.

Generic

1.3 Lodging of assets protection measures with banks, other financial

institutions, court, etc.

Generic

1.4 Simplified procedures for installment application, also via portal, for arrears

below given amount and observing general compliance criteria.

Generic

1.5 Updating the taxpayer account according to the current debt status. Generic

1.6 Updating the taxpayer profile e.g. using the FSIC coding Generic

1.7 Updating the case status with meaningful assignments, e.g. open, request for

information, analysis, normal case, forced collection, closed, suspended,

bad debts, reopen, etc.

Generic

2 The new system must support preparation, execution and post processing of

different forced collection measures, including auctions. Generic

2.1 Seizure of financial assets. Generic

2.2 Maintaining records of itemized seized goods with indication of expected

value e.g. data input through physical verification of asset schedule

Generic

2.3 Off-setting the taxpayer account with proceeds from forced recovery. Generic

2.4 Updating the taxpayer profile. Generic

3 The new system must support writing-off debt and collection suspension

procedures. Generic

3.1 Preparing lists of debt according to the taxpayer, tax type, amount, age of

debt, industry type according to FSIC and collectability indicator.

Generic

3.2 Based on Commissioner‘s decision, writing-off approved debts. Generic

3.3 Based on Commissioner‘s decision, temporarily suspend the collection of

approved debts.

Generic

3.4 Updating taxpayers´ accounts and risk profiles. Generic


audit case related data. For TTPA purpose, Audit to also input latest records

into system e.g. LTA records and vice versa. Interaction between the DMS

and Audit modules on related cases allowable – sys updates to the latest

records, DMS officers to view audit report online.

Generic

4.1 Using predefined and ad hoc reporting features as well as BI functions (see

also the technical requirement section).

Generic

Table: Summary of requirements related to the collection of arrears and debt management



4.7.4.1 Collection and Debt Management - Selected Details

C&DM-D Required function



1 Detect cases where there is outstanding tax payable. Y Y

2 Automatically schedule debt collection reviews by the

system.

Y Y

3 Automatically generate a demand for payment

according to the escalation procedures defined by

business rules.

Y Y

4 Suppress system actions in certain circumstances e.g.

prosecution pending, based on business rules.

Y Y

5 Comprehensive debt reporting, inclusive by debt age

attributes.

Y Y

6 Retain history of actions to recover previous debts for

the particular taxpayer.

Y Y

7 Case management actions based on business rules. Y Y

8 Support for prosecutions for debt collection. Y Y

9 Support for the collection of outstanding debts by

instalments.

Y Y

10 Support the compilation of national and regional debt

collection plans.

Y N

Table: Selected details related to debt collection and management

4.7.5 Summary of Functional Requirements Related to Objections and Appeals

Taxpayers can file an objection if dissatisfied with the assessment raised. If still dissatisfied with the amended

assessment, the taxpayer may also refer the case directly to the Court Tribunal.

Taxpayers and FRCA can disagree over the ruling provided by the Court Tribunal and escalate the case to the

High Court.

FRCA handles an average of 2000 objection cases per annum, most of those relating to the re-assessment of

VAT returns performed by FRCA officers. Of these, one third will be normally be escalated to the Court

Tribunal, while in both instances approximately xx-yy% of ruling is made in the favour of the Authority.

Filing an objection does not upset the taxpayer's payment obligations. The functional requirements related to the

objections and appeals are summarised as follows.



O&A Requirement outline Origin

1 The new system must facilitate comprehensive handling of objection and

appeal cases, using case management integrated with document management

and workflow features.

Generic

1.1 Receipt of application and opening a new court case. Generic

1.2 Verifying the objection fee has been lodged on the prescribed account. Generic

1.3 Notifying the objector on approval or rejection of case. Generic

1.4 Suspension of penalty adding to the taxpayer account until the ruling. Generic

1.5 Reactivation and adding of penalty to the taxpayer account if the case ruling

is in favor of FRCA.

Generic

1.6 Storing all electronic documents and scanned images of paper based

information in the Court repository with very strong security on access.

Generic

1.7 Supporting case hearing and ruling, adding new documents to the case and

apply version control on all documents.

Generic

1.8 Submission of Court ruling decisions to the objector within a specified time. Generic

1.9 Reopening a case already closed. Generic

1.10 Updating the case status with meaningful assignments, e.g. open, request for

information, analysis, ready for hearing, ruling, closed, reopen, FRCA

actions required by the Court before a ruling, etc.

Generic

1.11 Updating the taxpayer account according to the case ruling. Generic


2 The new system must support efficient handling of appeal tribunal cases,

using case management integrated with document management and

workflow features.

Generic

2.1 Receiving, recording and distributing the notification of cases. Generic

2.2 Preparing and processing court cases. Generic

2.3 Receiving, recording and distributing the tribunal cases rulings. Generic

2.4 Updating the taxpayer account according to the case ruling. Generic



audit case related data.

Generic

3.1 Using predefined and ad hoc reporting features. Generic

Table: Summary of requirements related to the objections and appeals



4.7.6 Summary of Functional Requirements Related to Taxpayer Services

In general the provision of taxpayer services should follow the following FRCA specifications as shown in the

next table.

Table: Framework of e-services (source OECD)

The next table presents some main requirements related to the tax portal and integration of the portal with other

COTS modules, case management and document management in particular.

TPS Requirement outline Origin

1 The new system must comprise a comprehensive tax portal. Generic

1.1 The common part of the portal available to the general public and offering

variety of information and services for interaction with the tax authority.

Generic

1.2 The restricted part available to e-users registered for specific e-services and

accessing these according to the user specific profile.

Generic

1.3 Maintain knowledge database, including FAQ, legal provisions, appeal

rulings, court case decisions, etc.

Generic

1.4 Enable access to and facilitate download of various forms and documents. Generic

2 The new system must enable integration of the portal functions with case

management module; document management module as well as other

Generic

Category Description Confidentiality and data

access considerations

Presence (or

"information"

One way information flow providing static information

about the agency. Includes publications (e.g. legislation,

policy documents, finalised court cases), instructions, and

education/marketing material. Interaction is limited to

inquiry & search functions.

Publicly available/non-

confidential data.

No access restriction.

Interaction Two-way information flow which does not alter systems or

data. This includes expanded search and filtering capabilities

and services such as calculators where all data are entered by

users (e.g. to assess eligibility for benefits or determine tax

payable and related technical interpretations on rulings to be

published).

Publicly available/non-

confidential data.

No access restriction.

Transaction Any exchange which alters data holdings or provides access

to taxpayer data. Includes activities such as enquiries

involving taxpayer data, use of calculators pre-filled with

taxpayer data, & filing returns / making payments. Based on

the search function and knowledge base, standard replies are

available to taxpayer online enquiries. Periodic updates to be

done. Every update – new version created.

Confidential data.

Access restricted to

specific individuals.

Integration/

transformation

Exchange of information between different government

agencies regarding a specific user (individual, business,

organisation). For example, a change of address advised

only once by the user and then shared across relevant

agencies.

Confidential data.

Access restricted to

specific individuals.



TPS Requirement outline Origin

modules.

2.1 Automated creation of cases based taxpayers´ request submitted via the

portal, e.g. creation of objection and appeal cases.

Generic

2.2 Responding to taxpayers requests and submitting various certificates and

other documents such as Certificate of Exemption (COE), Tax Clearance

Certificate (TCC), etc.

Generic

Table: Summary of selected taxpayer service requirements

4.7.7 Security and Data Privacy Requirements

S&DP Requirement outline Origin

1 The new system must provide support for processing of paper based

information as well as electronic processing, i.e. e-filing, e-payments,

enquiries, bi-lateral exchange of data with taxpayers, employers and partner

agencies, etc. with security measures in place for verification and

authentication of the other party

Generic

1.1 The electronic processing must be secured, safe and reliable by applying

appropriate security, authentication and protection measures.

Generic

1.2 All users, internal and external, use and access the same system through the

SPoE, as indicated below.

Diagram: SPoE – Single Point of Entry

Generic

The new system should facilitate Fault tolerant – redundancy in hardware

and software, two systems running simultaneously (software fail over, active

replication which sends information from one system to the other).

Generic

Table: Security and data privacy related requirements

WEB Client services for external users

Internet

browser

INTERNET

1 . FW

WEB sevices - SPoE

2 . FW

First level

Second level

Third level

INTRANET

WEB Client services for internal

users

Internet

browser

local

applications

iISE taxation and Customs

Central facilities: TIS, RMS,

etc.



4.7.8 IT Operational Requirements

This section contains basic requirements related to the operations of the main transaction system and thereto

related e-services.

OP Requirement outline Origin

1 The new tax system must remain operational with respect to the nature of its

components. Generic

1.1 The transaction modules e.g. functions related to the registration and

accounting should be operational at least throughout the working hours.

Generic

1.2 In addition, although not time critical, these modules should remain

operational 99.99x% of the overall calendar time, 24/365.

Generic

1.3 The electronic front end i.e. the user portal, should in principle be available

and remain operational 24/365. This is required for the purpose of

establishing and maintaining the users´ confidence in the use and reliability

of the electronic services.

Generic

1.4 In the event of the transactional modules not being available, the incoming

data received by the front end system must be securely stored and cached

for later processing.

Generic

2 The new tax system must provide a comprehensive support model for all

internal and external users:

User friendly, logical and intuitive user interface organised according

to the applicable standards.

Context sensitive on-screen help consisting of general guidance,

thematically arranged subject and specific data field related help.

Adequate support for the Help Desk staff serving the internal and

external users´ requests received via an online advice through the

website or taxpayer portal; via email or social media or by phone.

Generic

2.1 The Help Desk team will need to record the reported malfunctions and

errors of the systems following a well-established procedure for diagnostics

and for accelerating the recovery according the clearly set priorities to the

appropriate part of the organization.

Generic

2.2 This includes issuing of receipt for the malfunction reports and serving

feedback to the originator.

Generic

Table: Summary of operational requirements



4.7.9 Miscellaneous Requirements

This section contains various requirements, mainly technical, reflecting partially design aspects and indicating

some implementation related considerations.


1 FITS utilises Oracle DBMS technology, and its licenses are provided

through the general agreement with the Oracle Corporation. Currently

installed is the version Oracle database 10.X.

FRCA

1.1 It is expected that the new system will be based on the same RDBMS

platform.

FRCA

1.2 As Oracle supports cloud technology, this could be considered in relation to

the backup routines and disaster recovery approach. Disaster recovery is a

mandatory requirement to be implemented and tested prior to the new

COTS system going live.

Generic

2 The new system must ensure full referential integrity in the main DB as well

as in all instances of replicated or distributed DB sub-sets.

Generic

2.1 Facilitate seamless context based integration and consequent user

navigation amongst the components of the entire system.

Generic

2.2 Related to the above, the system must facilitate seamless context based

integration and consequent user navigation amongst the components of the

entire system.

Generic

2.3 Facilitate comprehensive transaction logging and full audit trail. Generic

3 The new system should utilise the Business Intelligence technology (BI) e.g.

Dash board and visual analysis tools used for organizing and presentation of

information (user specific tools).

Generic

3.1 Using BI tools enables e.g. single fit on a screen, filtering and drill-down

capabilities, frequent update of data, etc.

Generic

3.2 Facilitate onscreen generated queries and ad hoc report creation. Generic

4 The new system to employ two-factor authentication to safeguard against

cyber theft; e.g. fingerprint as a standard login credential and applied as

unique identifier in the audit trail.

Generic

4.1 Use of Active Directory Integrated logins (to allow single logon to access

multiple applications)

Generic

4.2 Automatic kill session capability to support security (to kill a session which

is inactive for a configurable specific amount of time).

Generic

5 The new system should support the encryption of data to a high level

encryption strength. Generic

5.1 This includes internal encryption/decryption (from DB to the screen) at

normally applied strength level and strong encryption when propagating

data to/from the cloud.

Generic

6 The new system should facilitate comprehensive case management and

document management as well as user manageable workflow functions. Generic

6.1 These features should be integrated (from the user perspective seamlessly)

in principle with all modules of the main transaction system. Case

management should be event driven for automatic generation, opening or

updating a given case.

Generic




6.2 The workflow functions need to facilitate establishment and maintenance of

flow scripts on the level of system administration and preferably, to limited

extent on the level of general users.

Generic

6.3 Reasonably integrated with the document management facilities. Generic

7 The new system should facilitate Fault tolerant – redundancy in hardware

and software, two systems running simultaneously (software fail over, active

replication which sends information from one system to the other).

Generic

8 The new system should provide Data warehousing capabilities for reporting

and for data analysis. Generic

9 The new system must be able to import and export data in various formats. Generic

10 In-Memory Computing Technology for data transactions and analytics

preferable Generic

Table: Summary of miscellaneous requirements

5 Implementation Considerations

This chapter outlines a high level functional architecture following the FRCA Tax Reference Model and

provides requirements for selected functional elements, which should be included in the bidding documents.

The targeted new system should have a functional structure, which seen from the user perspective could appear

as shown in the next diagram.

Diagram: Envisaged general functional structure and main information flow



5.1 Outline

The FRCA Tax Reference Model comprises the following main components:

1. Delivery channels.

2. Client Relationship Management (CRM).

3. Revenue management.

4. Case and work management.

5. Outcome improvement.

6. Enterprise planning and management.

7. Various enablers.

These components are graphically depicted in the next diagram.

Diagram: Tax Reference Model

The following sections show delimitation of elements, functions/capabilities expected to be provided specifically

for the new system (Bespoke) vs. those that could utilise standard components (COTS), and finally, the existing

elements, which will have to be integrated in the overall architecture.

5.2 Capability - Channel Delivery

5.2.1 Abstract

Delivers products and services through channels in a manner that meets client needs, while achieving revenue

administration and government objectives.

Includes capabilities to support content, document and records management of inbound and outbound material.

These expected sources are only a guideline. As much functionality as possible, should be incorporated in the

COTS solution.



5.2.2 Details

Function Description Expected provided by / through

Bespoke COTS Existing

Online Supports interactive channels for the community,

providing both static content and transaction

services. Interactive channels include:

1. portals Y Y N

2. web sites yes (yes)

3. web services for integration into external

applications

yes yes (yes)

4. secure messaging (email) services (yes) (yes) (yes)

5. search services across web sites yes

6. calculators yes

Inbound Supports predominantly non-interactive inbound

channels for the community and other government

agencies. Includes:

7. inbound paper processing for forms and

white mail, including image capture,

Optical Character Recognition and key

capture

yes yes

8. inbound fax processing yes yes

9. inbound bulk file and message handling yes

10. secure messages from portals yes

11. indexing, classification and routing of client

requests

(yes) (yes)

12. inbound email (general email addresses

only)

yes

13. automated inbound phone services for

simple transactions

yes yes no

14. key data capture for bulk forms that are not

imaged

yes yes

Outbound Supports non-interactive outbound channels for the

community. Includes:

15. outbound material, including forms, letters

and marketing/education material

yes yes

16. outbound delivery to paper, secure

messaging, email and SMS channels

yes

17. the naming, addressing, cc copying,

merging, sorting, formatting, storing and

printing of personalised mail items

yes

18. outbound bulk file and message handling. yes

Content

Management

The enterprise functionality for initiating, approving,

storing, maintaining and publishing approved content

for informational, transactional, interpretative and

correspondence products, including marketing and

education material.

yes





Document

Management

The Document Management capability provides the

ability to store and retrieve electronic versions of

documents and manage the retention and destruction

of electronic records in accordance with legislative

requirements.

Can apply to both client-related documents and

administrative material (e.g. internal documents).

yes

Table: Delivery channels

5.3 Capability - Client Relationship Management

5.3.1 Abstract

Deliver the right experience at the right time through the right channel.

5.3.2 Details



Contact

Management

Provides client contact management services, in

particular for the phone channel. Includes:

1. Interactive Voice Recognition (IVR) and

Computer Telephony Integration (CTI) for

staff-operated phone services

yes yes no

2. Integrated view of client. Should be

available to taxpayers in a different format

as approved by Taxation Management.

Should be user friendly with capability to

generate reports, certificates, etc.

yes yes

3. Tracking, recording, escalation and

monitoring of client contacts

yes (yes)

Marketing and

Education

Provides marketing, communication and education

services, including campaign management for single

and categorized taxpayer groups.

yes

Table: CRM

5.4 Capability - Revenue Management

5.4.1 Abstract

Enables clients (including tax intermediaries) to efficiently and effectively register, lodge/file and pay, and the

revenue administration to recover the correct amount of tax and entitlement, whilst minimising the cost to the

client.

5.4.2 Details



Registration Provides client registration services. Includes:

1. individual and non-individual registration yes





2. registration and maintenance of tax

professionals and all other intermediaries

yes

3. endorsement of charities and deductible gift

recipients

yes

4. tax type/role registration and

lodgement/filing cycle determination

yes

5. client data quality management yes (yes)

6. client preferences yes (yes)

7. client search yes (yes)

8. identity strength yes (yes)

9. data extracts for external agencies yes

Generic

processing

Provides lodgement/filing and payment processing

for all tax products, using a generic approach that

can support new products. Includes:

10. tax business rules processing yes yes

11. form generation yes (yes) (yes)

12. paper form filing yes (yes) (yes)

13. e-filing (yes) yes (yes)

14. e-certificate management. Provision for

charging a fee as there is an expected influx

of requests in the future.

yes yes

15. filing compliance control yes yes

16. payment compliance control yes yes

17. instalment arrangements yes yes

18. tax risk processing by tax type etc. yes (yes)

19. generation of account posting yes yes

20. generation of outbound communications

(e.g. notice of assessment).

yes (yes)

Client

accounting

Provides account management services for all clients

and all tax products. A fee may be applicable for the

servicing of ad-hoc requests. Includes:

21. client account maintenance yes yes

22. client account statement yes (yes)

23. interest and penalty imposition and

remission

yes (yes)

24. refunds and disbursements yes (yes)

Revenue

accounting

Provides summarisation, reconciliation and reporting

for revenue accounts. Includes:

25. maintenance of revenue accounting

information on an internal General Ledger

yes





26. providing users with direct access to

revenue accounting information

yes yes

27. automated reconciliation of revenue

accounts to bank statements

(yes) yes

28. revenue forecasting (yes) yes

29. revenue reporting (yes) yes

Debt &

Lodgement

Identifies, creates and auto-actions cases where a

client has either failed to lodge/file or failed to pay.

Includes:

30. initiate auto-recovery actions for example,

if t/p owes tax, the integration with

ASYCUDA World will ensure that the t/p

consignment is held by Customs. Special

business rules to apply.

yes yes

31. identify and create debt and non-lodgement

case

yes

32. action debt and non-lodgement case yes

33. process update transactions from data

matching processes

yes yes

34. due date deferrals yes yes

35. payment arrangements yes yes

36. legal and prosecution details yes yes

Table: Revenue management

5.5 Capability - Case and Work Management

5.5.1 Abstract

Delivers enterprise wide case and work management capability to support active compliance, provision of

written advice, debt collection, action inbound correspondence and exception processing.

5.5.2 Details



Enterprise

Case

Management

Supports enterprise-wide case management.

Includes:

1. case management yes

2. case assignment yes

3. case tracking yes

4. case admin & reporting yes





5. case action including default assessments,

amendments, penalty & interest, form

letters, etc.

yes yes

6. update of case plans yes

Enterprise

Workflow

Supports enterprise-wide work management of

exceptions from operational systems and acts on

correspondences. Includes:

7. work item creation yes

8. work allocation yes

9. work actioning yes

10. work reporting yes

11. work escalation yes

12. workflow admin yes

Table: Case and workflow management

5.6 Capability - Outcome Improvement

5.6.1 Abstract

Provides feedback on the client experience, effectiveness of risk treatments and other enterprise information to

continuously improve the operations of the revenue administration and provides input to Case Management and

Revenue Management capabilities to ensure appropriate and relevant treatment according to risk.

5.6.2 Details



Analytics Provides analytical models to support case selection

and the risk and market segment treatment of clients.

Includes:

yes

1. creation and maintenance of analytical

models

yes (yes)

2. regular update of risk and segment

information for operational systems

yes yes

3. provision of case selection candidates for

processing

yes yes

Information

Management

Policy and

architecture

Information Management Policy and architecture

covers the development of information models and

the overall management of information within the

revenue administration.

Reporting Provides a corporate reporting capability including

transactional, management and ad hoc reporting to

support operational management and continuous

improvement. Includes:

4. report generation (yes) yes

5. report distribution (yes) yes





Data matching Provides services for matching and interpretation of

data from multiple sources.

yes

Data

Warehouse

Management

An integrated and centralized data storage and access

capability organized specifically for end-user

reporting and analysis.

yes

Intelligence Supports gathering, storing and interpretation of data

from the community to assist in case identification

and selection.

yes

Table: Outcome improvement

5.7 Capability - Plan and Manage Enterprise

5.7.1 Abstract

Provide the management processes and structure for running the day-to-day business of the revenue

administration.

5.7.2 Details



Governance &

assurance

Development and implementation of policies,

strategies and assurance processes relating to

governance, integrity, audit & fraud control and

security.

Yes – not

for

integratio

n

Finance Budget and asset planning and management

yes

Employee

policy and

services

Incorporates a wide range of services, including:

6. employment policy & advice As above

7. recruitment, personnel, appointments As above

8. performance management yes

9. industrial relations yes

10. organisational health/workplace safety &

health

As above

11. workplace diversity As above

Table: Enterprise planning and management



5.8 Capability - Enablers

5.8.1 Abstract

Other major functionality areas can use these additional capabilities.

5.8.2 Details



Security

This capability ensures that corporate systems and

data are secure from unauthorised access. Includes:

1. security for internal systems to prevent

unauthorised access by staff

yes

2. security for external facing systems to

prevent unauthorised access by clients

yes

3. logging any unsuccessful attempts to access

the systems by staff or clients

yes

4. ensuring the security of the systems

themselves from malicious or criminal

attack, particularly from the internet

yes

Workforce

Management

Provides management of the revenue

administration‗s workforce, in particular focusing on

the information required for workflow management.

Includes:

5. engagement and termination processing yes

6. skills management Yes (yes)

7. holiday management Yes (yes) yes

Interaction

Services

A system capability that provides the services,

patterns and templates required to develop User

Interfaces that comply with the revenue

administration‗s User Interface standards, branding

rules, legal requirements (e.g. adherence to the Web

Accessibility Guidelines for the disabled), fraud

prevention and control logging.

Yes yes

Integration

Services

A system capability providing all services involved

in supporting integration between the revenue

administration‗s applications. Broadly this covers

three types of integration:

8. interaction layer integration – seamless in-

context navigation between user interfaces

in the applications

Yes yes

9. service layer integration – standard

Enterprise Application Integration

Yes yes

10. data layer integration – replication of data

between master and slave databases

Yes yes

11. transaction audit logging Yes yes

Table: Enablers



6 CHANGE MANAGEMENT

Vendors must demonstrate past successful Change Management internally and externally to a similar Revenue

Administration. The following areas are to be included in the Change Management Plan:

Effective and Efficient Data Migration

Possibility of concurrent use of FITS and the new COTS

Effective and Efficient Integration with other agencies

Effective and Efficient provision and continuous update of Electronic SOPs and Manuals

Effective and Efficient provision and continuous update of e-training materials

7 Indicative Delivery Plan and Preliminary Schedule

7.1 Duration

The overall duration of this project has been preliminary calculated for 2.5 years, corresponding to

approximately 30 calendar months. The first 12 months are envisaged for the procurement and provision of

equipment and services relating to the delivery of the new IS. This will be followed by a period of 6 months

envisaged for complete migration of historic data. The remaining 12 months have been included for the purpose

of the warranty and the system maintenance period. It is expected that the project will start with a pilot revenue

type, e.g. VAT and then progressively roll out other revenue types as the environment settles down with FITS

and COTS running concurrently. It is to be noted that FRCA financial year is from January to December.

7.2 Overview

The start and completion parameters are expressed as calendar weeks elapsed relative to the effective project

start date = T, being the date of contract signing.

In the final and supplemented version, the complete Delivery plan will be included as an attachment to the

general terms and conditions of the contract and as a result will become an integral part of the entire agreement

between the contractor and the contracting entity.

Stage

ID

Start Main deliverable Completion

1 T Mobilisation T+4

2 T+5 Project Plan and QA Plan T+8

3 T+6 Transfer of knowledge: strategy and plan T+9

4 T+6 Appraisal of current situation & verification of requirements T+10

5 T+8 Implementation approach, integration and migration strategy T+11

6 T+8 Installation plan (technical components) T+11

7 T+11 Acceptance strategy and test plans T+20

8 T+11 System design modifications and prototype T+20

9 T+15 System development & factory testing T+30

10 T+15 Technical manuals, user manuals and training material T+30

11 T+20 Installation and testing of technical components T+25

12 T+26 Training: technical staff T+29



Stage

ID

Start Main deliverable Completion

13 T+30 Installation and integration of system components T+35

14 T+36 Training: testers and help desk staff T+38

15 T+39 Acceptance test core system T+44

16 T+45 Acceptance test integrated system T+49

17 T+40 Error correction, adjustments and retesting T+52

18 T+45 Training of trainers T+52

19 T+50 Data migration T+70

20 T+53 Mass training T+75

21 T+71 Acceptance test migrated system T+80

22 T+81 Warranty period for accepted migrated system T+136

23 T+10 Transfer of knowledge, on-going T+136

Table: Indicative Delivery Plan

8 INSTRUCTION TO TENDERERS

8.1 General

8.1.1 Cost of Tender

The Tenderer shall bear all costs associated with the preparation and submission of its Tender, and the

Fiji Revenue & Customs Authority, hereinafter referred to as "the Purchaser", will in no case be

responsible or liable for those costs, regardless of the conduct or outcome of the Tender process.

8.2 Tender Documents

8.2.1 Tender Procedure

The Tender Procedure, the goods and services required by the Tender and the contract terms are

prescribed in this chapter. In addition to the Invitation to Tender, this Terms of Reference Document

(TOR) can be downloaded via http://www.frca.org.fj or requested via email [email protected] .

8.2.2 General Responsibility of Tenderer

The Tenderer is expected to examine all instructions, forms, terms and specifications in the Tender

Documents. Failure to furnish all information required by the Tender Documents or submission of a

Tender not substantially responsive to the Tender Documents in every respect will be at the Tenderer's

risk and may be rejected.

8.2.3 Clarification of Tender Documents

a. A prospective Tenderer requiring any clarification of the Tender Documents may notify the Purchaser

in writing via email [email protected]. The clarifications shall be received not later than 15

days prior to the deadline for Submission of Tenders prescribed under Clause 8.4.4a;

http://www.frca.org.fj/

mailto:[email protected]

mailto:[email protected]



b. The Purchaser will respond electronically to any request for clarification of the Tender Documents.

Written copies of the Purchaser's response (including an explanation of the query but without

identifying the source of the inquiry) will be sent to all prospective Tenderers who have received the

Tender documents;

c. The Tenderers right to request clarifications is not covered by any deadline extension to the

Submission of Tenders that the Purchaser may give under Clause 8.4.4b. Therefore, all clarifications

shall be reviewed according to ‗item a‘ above whether or not any deadline extension is given;

8.2.4 Amendment of Tender Documents

a. Prior to the deadline for submission of Tenders, the Purchaser may, for any reason whether at its own

initiative or in response to a clarification requested by a prospective Tenderer, modify the Tender

documents by amendment;

b. The amendment will be notified in writing to all prospective Tenderers and will be binding on them;

c. In order to afford prospective Tenderers reasonable time within which to take the amendment into

account in preparing their Tenders, the Purchaser may, at its discretion, extend the Deadline for the

Submission of Tenders.

8.3 Preparation of Tenders

8.3.1 Language of Tender

The Tender prepared by the Tenderer and all correspondence and documents relating to the Tender

exchanged by the Tenderer and the Purchaser, shall be written in the English language.

8.3.2 Documents Comprising the Tender

The Tender prepared by the Tenderer shall comprise the following components:

a. Financial Proposal(s) comprising of an appropriate price schedule showing that the goods and services

to be supplied by the Tenderer conform to the Tender Documents;

b. Technical Proposal(s) (8.4.11) showing that the goods and services to be supplied by the Tenderer

conform to the Tender Documents;

c. Tender Security (Clause 8.3.6).

8.3.3 Tender Prices

a. The Tenderer shall indicate on an appropriate Financial Proposal, the total price of the goods and

services it proposes to supply under the Contract. Prices quoted for the Equipment and System

Software shall be duty free and inclusive of all expenses for transportation, clearing, delivery,

installation and commissioning;

b. Prices quoted should not include the Value Added Tax (VAT). The VAT amount should be shown

only on the ‗Summary of Total Costs‘‘.

8.3.4 Tender Currencies

Prices shall be quoted in Fiji Dollars or US Dollars. Tenderers quoting in US Dollars are to include the

exchange rate that is applicable.

8.3.5 Documents Establishing Good's Conformity to Tender Documents

a. The Tenderer shall furnish, as part of its Tender, documents establishing the conformity to the Tender

Documents of all goods and services which the Tenderer proposes to supply under the contract;

b. All technical specifications shall be supported by documentary evidence which must prove the goods'

and services conformity to the Tender requirements. Such documentary evidence may be in the form

of literature, drawings and data.



8.3.6 Tender Security

a. The Tenderer shall furnish, as part of its tender, Tender Security equal to FJ$50,000 (Fifty Thousand

Fiji Dollars). The Tender Security shall be issued in the name of Fiji Revenue & Customs Authority;

b. The Tender Security shall be a bank guarantee issued by a bank operating in Fiji and valid for 30 days

beyond the validity of the tender;

c. Any Tender not secured in accordance with ‗item a or b‘ above will be rejected by the Purchaser as

non-responsive;

d. Unsuccessful Tenderer's Tender security will be returned as promptly as possible but not later than 30

days after the expiration of the period of Tender validity prescribed by the Purchaser;

e. The successful Tenderer's Tender Security will be discharged upon the Tenderer's signing the

Contract, and furnishing a performance security.

f. The Tender security may be forfeited:

(I) if a Tenderer withdraws its Tender during the period of Tender validity;

or

(II) in the case of a successful Tenderer, if the Tenderer fails:

(a) to sign the Contract, or

(b) to furnish a performance security.

8.3.7 Period of Validity of Tenders

a. Tenders shall remain valid for 180 days after the deadline for submission of Tender prescribed by the

Purchaser. A tender valid for a shorter period will be rejected by the Purchaser as non-responsive;

b. In exceptional circumstances, the Purchaser may solicit the Tenderer's consent to an extension of the

period of validity. The request and the responses thereto shall be made in writing. The Tender Security

provided shall also be suitably extended. A Tenderer may refuse the request without forfeiting its

Tender Security. A Tenderer granting the request will not be required nor permitted to modify its

Tender.

8.3.8 Format and Signing of Tender

a. The Tender shall be prepared in three (3) identical copies clearly marking one copy as "Original

Tender". In the event of any discrepancy between them, the original shall govern;

b. The original and all copies of the Tender shall be typed or written in indelible ink and shall be signed

by the Tenderer or a person or persons duly authorised to bind the Tenderer to the contract;

c. The Tender shall contain no inter-lineation, erasures or overwriting except as necessary to correct

errors made by the Tenderer, in which case such corrections shall be initialed by the person or persons

signing the Tender.

d. The hardcopy Tender must be accompanied by an electronic copy.

8.4 Submission of Tenders

8.4.1 Sealed Envelopes

Tenders should be submitted in two separate sealed envelopes each clearly marked as to contents and

enclosed in a third sealed envelope. The first envelope shall contain the Technical Proposal together

with the Tender Security. The second envelope shall contain the Financial Proposal.

8.4.2 Number of Proposals

The Tenderer may submit more than one proposal based on different system software platforms,

provided each proposal is self-contained and submitted in separate sealed envelopes, in accordance with

these Instructions, and no cross reference is made between them.



8.4.3 All envelopes shall:

a. Bear the project name - "TENDER NO. 25/2014 – TENDER FOR THE SUPPLY,

INSTALLATION AND COMMISSIONING OF A TAXATION COTS SOLUTION" and

b. be addressed to:-

The Tender Board,

Fiji Revenue & Customs Authority,

Level 3 Building 3

1 Ratu Sukuna Road, Nasese

Suva

FIJI

8.4.4 Deadline for Submission of Tenders

a. Tenders must be received by the Purchaser at the address specified under Clause 0 no later than 12pm

5th

December 2014;

b. The Purchaser may, at its discretion, extend this deadline for the submission of Tenders by amending

the Tender Documents, in which case all rights and obligations of the Purchaser and Tenderers

previously subject to the deadline will thereafter be subject to the deadline as extended.

8.4.5 Late Tenders

Any Tender not submitted by the time and date prescribed under Clause 8.4.4 will be rejected.

8.4.6 Modification and Withdrawal of Tenders

a. The Tenderer may modify or withdraw its Tender after the Tender submission, provided that written

notice of the modification or withdrawal is received by the Purchaser prior to the deadline prescribed

for submission of Tenders in Clause 8.4.4;

b. The Tenderer's modification or withdrawal notice shall be prepared, marked and dispatched in

accordance with the provisions of Clauses 0 and 8.4.4. A withdrawal notice may also be sent by cable

but followed by a signed confirmation copy, post marked not later than the deadline for submission of

Tenders;

c. No Tender may be withdrawn in the interval between the deadline for submission of Tenders and the

expiration of the period of Tender validity specified by the Tenderer. Withdrawal of a Tender during

this interval may result in the Tenderer's forfeiture of its Tender security.

8.4.7 Preliminary Examination

a. The Purchaser will examine the Technical Proposals to determine whether they are complete, whether

the required sureties have been furnished, whether the documents have been properly signed and

whether the tenders are generally in order;

b. Prior to the detailed evaluation of the Technical Proposals the Purchaser will determine the substantial

responsiveness of each tender to the Tender Documents. A substantially responsive tender is one

which conforms to all the terms and conditions of the Tender Documents without material deviations.

The Purchaser‘s determination of a tenderer‘s responsiveness is to be based on the contents of the

tender itself without recourse to extrinsic evidence.

8.4.8 Clarification of Tenders

a. To assist in the examination, evaluation and comparison of Tenders the Purchaser may, at its

discretion, ask the Tenderer for a clarification of its Tender. The request for clarification and the

response shall be in writing and no change in the price or substance of the Tender shall be sought,

offered or permitted.



8.4.9 Evaluation of Technical Proposals

a. The Purchaser will determine which Tenderers are qualified to perform the contract satisfactorily by

evaluating the Technical Proposals submitted prior to the opening of the Financial Proposals. During

the evaluation of the Technical Proposals the Financial Proposals will be kept under lock and key at

the premises of the Main Tender Board;

b. The Purchaser will evaluate the technical proposals on the basis of the following Evaluation

Categories and Weights:

1. Tenderer Credibility.

Overall suitability of the Tenderer to undertake the task

required.

10%

2. Implementation Plan and Support.

Tenders ability to develop, install and support the system. 30%

3. System Software, Hardware and Application

Environment.

Compliance against the stated requirements. Any

additional requirements above the specified requirements

shall be considered during evaluation.

50%

4. Overall Solution Offered. 10%

A more detailed analysis of the above evaluation categories is given in the table attached to the end of

this Section as ANNEX A.

8.4.10 Screening of requirements

Technical Proposals that do not comply with the requirements specified in the Tender Documents will

be disqualified. Tenderers who cannot meet fully a requirement but can provide a suitable alternative

may be included for further consideration.

8.4.11 Layout of Technical Proposals

The technical proposals submitted by the Tenderers shall comprise of the following:

Technical Proposal Cover Letter;

Tender Security;

Introduction;

Executive Summary;

Details of Compliance to Chapters 4, 5 & 6 of this document.

Relevant Company and Staff Profile as well as Experiences

8.4.12 Presentations

The presentations, if requested by the Purchaser, shall take place in Fiji. Tenderers shall have the

opportunity to present their solutions to the Evaluation Committee and be ready to receive/clarify any

issues that the Committee shall raise. The main aim of the presentation is to clarify the details of the

technical proposal and to ensure that the Purchaser fully understands the Tenderer‘s technical proposal.

During the presentations the screening of the requirements will continue.

8.4.13 Scoring of Technical Proposals

Technical Proposals that successfully pass the requirements screening will be evaluated and scored on

the basis of how they meet and exceed the requirements.

8.4.14 Short listed technical proposals

Assessment reports shall be prepared for the short listed Technical Proposals.



8.4.15 Demonstrations

a. Following the selection recommendation and acceptance of the short-listed Technical Proposals as per

Clause 8.4.14, Tenderers may be asked to demonstrate their solutions to the Evaluation Committee.

Refusal by any Tenderer to demonstrate its solution may be considered as a withdrawal of the Tender

and may result in the forfeiture of the Tender Security in accordance with Clause 8.4.6;

b. Demonstration Details

The demonstration environment shall enable the Evaluation Committee to verify the functionality,

features, and integration of the proposed system. The demonstration shall as a minimum include the

following:

1. Software features

2. Failures scenarios

2.1 Database Server(s)

2.2 Application Server(s)

2.3 Disk subsystem

2.4 Fail-over/re-establishment central /backup server

(The demo shall present the LAN and WAN features of the framework)

4. Application software and hardware

4.1 Software and hardware offered (richness and limitations)

4.2 Data & Functional Integration across application and entire solution

4.3 Production of ad-hoc enquiries & reports

4.4 If package is offered, ease of package customization, modular design

5. Security features of applications/solution

6. Development environment and tools proposed

6.1 Integration

6.2 Ease of use

6.3 Maintainability

7. An application environment shall be set up to demonstrate the key features of the solution

proposed and/or tools for development. The scenarios should be modelled around the required

system functionality and procedures outlined in this document.

8. In addition to the above requirements, the Tenderer may be asked to arrange one site visit to an

existing similar installation where the Evaluation Committee can observe the proposed

environment in operation.

c. Tenderers shall demonstrate their solutions over a period of up to four (4) days. Failure to demonstrate

will be at the Tenderer‘s risk and may result in the rejection of the Tender;

d. Demonstrations can take place either in Fiji or abroad. Tenderers shall be ready to demonstrate on or

after the 7th

week from the date of submission of the Tenders;

e. Following the demonstration process and as a result of the demonstration(s) the scoring of the

Technical Proposals shall be reviewed.

8.4.16 Solutions Presentation and Demo

The presentation and the demonstration costs shall be borne by the Tenderer.

8.4.17 Final Short-listed Solutions

At this stage, assessment reports shall be prepared for the final short-listed Technical Proposals. The

final short-list of Technical Proposals shall be based on the points scored.

8.4.18 Envelopes containing the financial proposals of Tenderers shall be opened provided that the

technical proposal:

a. score a minimum of 75% of the total marks on the basis of the above criteria (Clause 8.4.9) or

b. score a minimum of 60% on each Category.

8.4.19 Financial Evaluation

a. The Purchaser will evaluate and compare the tenders previously determined to be substantially

responsive pursuant to Clause d;



b. Arithmetical errors will be rectified on the following basis. If there is a discrepancy between the unit

price and the total price that is obtained by multiplying the unit price and quantity, the unit price shall

prevail and the total price shall be corrected. If there is a discrepancy between words and figures, the

amount in words will prevail;

c. The comparison of tenders and the selection of the best evaluated Tender shall be made on the basis

of the Total Price and the cost of annual maintenance for five years (including one year warranty

period) shown on the Financial Form ―Summary of Total Costs‖, hereinafter called the ―Tender Cost‖;

d. To facilitate evaluation and comparison, the Purchaser will convert Tender Prices of all pre-qualified

Tenders to Fiji Dollars at the exchange rate established by the Reserve Bank of Fiji for similar

transactions, on the date of the opening of tenders. If there is a change in the value of the currencies

prior to the decision on award, the Tender Prices will be re-evaluated at the exchange rates prevailing

on the date of decision on award.

8.5 Award of Contract

8.5.1 Award of Tender

Following the opening of financial envelopes, the Purchaser will determine the best evaluated tender by

correlating the pre-qualification marks with the respective Tender Cost as follows:

S = 0.7 x (T/Tmax) + 0.3 x (Cmin/C) where

S the calculated Tender score, the highest value being the

best evaluated Tender; T the Technical score of the qualifying Tender;

Tmax the maximum Technical score amongst the qualifying Tender;

C the Tender cost of the qualifying Tender;

Cmin the minimum Tender cost amongst qualifying Tenders.

8.5.2 Award Criteria

Subject to Clause 8.5.3, the Purchaser will award the contract to the Tenderer whose Tender has been

determined as the best evaluated Tender according to Clause 8.5.1.

8.5.3 Purchaser's right to accept any Tender and to reject any or all Tenders

The Purchaser is not bound to accept the Tender with the highest calculated score or any Tender and

reserves the right to accept the whole or part of any Tender. Furthermore, the Purchaser reserves the

right to annul the Tender process and reject all Tender(s) at any time prior to award of contract, without

thereby incurring any liability to the affected Tenderer or Tenderers or any obligation to inform the

affected Tenderer or Tenderers of the grounds for the Purchaser‘s action.

8.5.4 Notification of Award

a. Prior to the expiration of the period of Tender validity, the Purchaser will notify the successful

Tenderer in writing that its Tender has been accepted;

b. The notification of Tender award will constitute the formation of the contract;

c. Upon the successful Tenderer's furnishing of performance security pursuant to Clause 8.5.6, the

Purchaser will notify each unsuccessful Tenderer and will discharge its Tender security, pursuant to

Clause 8.3.6 as promptly as possible.

8.5.5 Signing of Contract

a. At the time that it notifies the successful Tenderer that its Tender has been accepted, the Purchaser will

send to the Tenderer the Contract Form provided in the Tender Documents, incorporating all

agreements between the parties, and any third party, if any;

b. Within 30 days of receipt of the Contract Form, the successful Tenderer shall sign and date the

contract and return it to the Purchaser together with the Performance Security pursuant to Clause 8.5.6.



8.5.6 Performance Security

a. Within 30 days of the receipt of notification of award from the Purchaser, the successful Tenderer

shall furnish an irrevocable and unconditional performance security, equal to 10% of contract value,

issued by a bank operating in Fiji, in the form acceptable to the Purchaser;

b. The proceeds of the performance security shall be payable to the Purchaser as compensation for any

loss resulting from the Tenderer's failure to complete its obligations under the Contract;

c. The performance security shall be valid for the whole warranty period and shall be discharged by the

Purchaser immediately after its expiry date subject to clause b;

d. Failure of the successful Tenderer to comply with the requirements of Clause 8.5.5 or Clause 8.5.6 of

Chapter 8 shall constitute sufficient grounds for the annulment of the award and forfeiture of the

Tender security, in which event the Purchaser may make the award to the next best evaluated Tenderer

or call for new Tenders.

8.5.7 Delivery Schedule

a. Delivery and installation of all goods and services ordered under this tender shall be completed as

specified in the TOR document

b. Technical, functional and operational training shall also be phased during this period and Tenderers

shall highlight this within their plans.



ANNEX A

EVALUATION CRITERIA

S/N Evaluation Criteria Weight %

Tenderer Credibility

Profile of Tender/Consortium;

Experience in architecture and design of Tax COTS

Experience in development and test of Tax COTS

Experience in integration of hardware

Project management skills and qualifications

Change management skills

Services Support Enhancement Project - Tax COTS

Training skills

Project Experience;

Experience in implementing complex IT projects in similar

institutions (i.e. public, telecom or financial)

Experience in implementing complex IT projects within a tax

authority

Experience under various working-conditions in developing

countries

Readiness assessment

Method of assessing FRCA readiness

Incorporation of the readiness assessment findings into the

implementation approach (short and long term)

Best practices in relation to the realisation of the new tax system

Development of a corporate architecture model

A review on the existing data base portfolio in relation to data

availability for use and the cross functional integration for

loading into the new database

Pre-conditions for interfaces with third parties so their

information can feed into the COTS

Implementation methodology and plan which also can be used in

the short term to advocate and create business impact.

Phased iterative implementation according to international best

practices

Technique of analysis on current decision making process and a

proposal how this can be improved

Assessment of the current and up-coming IT-Infrastructure‗s

suitability to host the COTS

10

Implementation Plan and Support Project Methodology used e.g. PRINCE2, PMBOK or AGILE

Process of Initial, Change and Validation of Requirements

specification

Realisation of IT-components (Hard- and software)

IT-architecture of COTS including integration in the IT-

architecture of FRCA

Process of design, development/customisation and test

Optimising current IT-infrastructure for COTS

Installation and integration resulting in a working solution

Preparation of business environment

Supports the project team in advocating the solution to

stakeholders, by using demos, prototyping etc.

Determination of roles and responsibilities during the phase of

20




operations and maintenance of the COTS

Development of a decision support framework

Data quality management (functional focused)

Technical Implementation

Delivery of the solution via a phased implementation

Explanation of how the proposed solution will accommodate new,

removed or substituted data sources after commissioning the

solution

Explanation of how data that supports specific business

operations is anticipated to be stored in data marts

Description of how the solution deals with the unstructured data

(Big Data)

Method of managing the generated Metadata and ensuring it is

kept updated

Training and skills transfer

Quality Assurance on project process and deliverables

User Acceptance Testing

Test Environment

Live Environment

Integration Plan with Existing FITS System

Test Plans

Data Migration Plan

Commissioning Solution (Roll-out plan);

Prototype

Pilot

Full Roll Out

Documentation;

Prototype build

Pilot build

Final Build

UAT Acceptance

Live Acceptance

User Manual

Training Manual

Operational Activities;

Project Team (CV‘s, Software Supplier);

Technical Approach to the Project;

Functional Training Plan

Technical Training Plan

Development Training Plan

Changes especially for management of Fiji Government‘s budget

announcement changes

Post-Implementation

User Manual and maintainability

Clearly state what system and process documentation will be left

with FRCA, and what steps will be put in place to ensure that any

vendor produced documentation is maintained and updated on a

regular basis.

Standards Compliance

Demonstrate System conformance to industry standards such as

ITIL; PMI; PRINCE2, etc.




Project Governance

Clear and Concise Project Cost and Time Schedules

Clear Communication Plan from Initiation to Closure

Key Benefits assumption to FRCA

Risk Management – Indicate a Risk Management Plan on Issues

Escalation and Management

Dispute Escalation and Resolution Process

Quality Assurance Qualifications and Management

Provide clarity on Project Resource Plan with emphasis on the

retention of key project personnel on the team during

implementation.

Project Documentations and Maintainability must be demonstrated

with examples from previous implementation

20

System Software, Hardware and Application

Environment

System Architecture;

Modularity, Language written in; Database type; OS type;

Messaging/Data exchange Format and Clustering capability must

be clearly defined

Capability for seamless integration with internal as well as

external systems such ASYCUDA World; financial institutions

etc.

Business rules and logic on client and server must be

demonstrated

User authentication; Encryption and Built-in Security as well as

other features like e-signature clearly stated

Communication protocol employed and its telecommunication

infrastructure independence demonstrated

E-documents ownership management; full audit trails of changes

and resilience to telecom breakdown must be defined

Computing Technology employed for data transactions and

analytics

Programming Change management and technology employed

A complete list of all the Hardware and Software details in the

solutions must be clearly contained.

Details of how existing FRCA owned hardware and software will

be utilized and accommodated for in the tender pricing approach

must be displayed clearly

Application Environment and its Architecture.

Graphical User Interface (GUI) Architecture;

Single View of Customer

Reporting & Printing Functionalities;

Multi-media desktop persistence defined

Change Management (access, change, management)

Plans for post implementation support and maintenance of the

solution

Implementation of changes are in accordance with ITIL best

practice

Licensing

Provision for automatic access to new software versions as and

when they are available?

Provision for automatic access to new products as they are added

to the overall system portfolio

Documentation

40




System and Application Architecture document management and

maintainability

Overall Solution Offered

System Architecture (constraints/features);

Availability/Failure Scenarios;

Disaster Recovery MUST be in place and tested from day one

Resilience to telecom breakdown

Capability to Integrate with existing FRCA applications and systems

Proven prior implementation

Contextualisation capability of solution

10