E Invoicing - RFP - Re-Tendering PDF

MINISTRY OF DIGITAL ECONOMY AND ENTREPRENEURSHIP (MODEE)
REQUEST FOR PROPOSAL (RFP)
NATIONAL E-INVOICING SOLUTION
PROPOSAL DEADLINE: 2-9-2020
RFP NO: 1F2019
1
Table of Contents
TABLE OF CONTENTS ............................................................................................................................. 2

1 INTRODUCTION ....................................................................................................................................... 6
1.1 RFP ORGANIZATION ................................................................................................................. 6
1.2 RFP PURPOSE ......................................................................................................................... 7
2 PROJECT DEFINITION AND DESCRIPTION ................................................................................................. 8
2.1 CURRENT SITUATION ................................................................................................................. 8
2.2 LEGAL FRAMEWORK .................................................................................................................. 8
2.3 USAGE STATISTICS ................................................................................................................... 8
2.4 GENERAL DEFINITIONS .............................................................................................................. 8
3 SYSTEM FEATURES AND REQUIREMENTS .............................................................................................. 10
3.1 USER GROUPS........................................................................................................................ 10
3.2 ACCESS CHANNELS................................................................................................................. 11
3.3 SYSTEMS ................................................................................................................................ 11
3.4 USE CASES AND FUNCTIONAL REQUIREMENTS ......................................................................... 12
3.4.1 Use Case 1: Receive e-Invoice .......................................................................................... 12
3.4.2 Use Case 2: Validate e-Invoice ......................................................................................... 13
3.4.3 Use Case 3: Send e-Invoice .............................................................................................. 13
3.4.4 Use Case 4: Create e-Invoice............................................................................................ 14
3.4.5 Use Case 5: Store e-Invoice .............................................................................................. 15
3.4.6 Use Case 6: Sign/Register e-Invoice ................................................................................. 16
3.4.7 Use Case 7: Perform System Administrative Functions ................................................... 17
3.4.8 Use Case 8: Register for e-Invoice Service ....................................................................... 18
3.4.9 Use Case 9: Handle claims and complaints ..................................................................... 18
3.4.10 Use Case 10: Identify Audit Subjects................................................................................ 19
3.4.11 Use Case 11: Run audit reports........................................................................................ 19
3.5 CONCEPTUAL ARCHITECTURE .................................................................................................. 20
3.5.1 E-Invoicing end user dimension overview ........................................................................ 20
3.5.2 User groups to access channel interactions .................................................................... 21
3.5.3 Access channel to use case relationships......................................................................... 21
3.5.4 Use cases to system interactions ..................................................................................... 23
3.5.5 Back office dimension ...................................................................................................... 23
3.6 MANDATORY NON-FUNCTIONAL REQUIREMENTS ...................................................................... 23
3.6.1 General ............................................................................................................................ 23
3.6.2 Customer Journey/Experience ......................................................................................... 26
3.7 SERVICE LEVEL AGREEMENT REQUIREMENTS .......................................................................... 28
3.7.1 Definitions ....................................................................................................................... 28
3.7.2 SLA Requirements ............................................................................................................ 29
4 SCOPE OF WORK FOR PROJECT DELIVERY .............................................................................................. 31
4.1 PROJECT OVERVIEW ............................................................................................................... 31
4.2 COMPONENT 1 – SYSTEM DESIGN, INSTALLATION AND CONFIGURATION .................................... 31
4.2.1 Winning bidder activities ................................................................................................. 31
4.2.2 Technical Proposal Requirements .................................................................................... 32
4.2.3 Financial Proposal Requirements .................................................................................... 33
4.2.4 Deliverables ..................................................................................................................... 33
4.3 COMPONENT 2 – REQUIRED SOLUTION INFRASTRUCTURE ......................................................... 34
4.3.1 Winning bidder activities and technical proposal requirements ..................................... 34
4.3.2 Financial proposal requirements ..................................................................................... 34
4.3.3 Deliverables ..................................................................................................................... 35
4.4 COMPONENT 3 – SOLUTION SECURITY REQUIREMENTS ............................................................ 35
4.4.2 Technical proposal requirements .................................................................................... 36
2
4.4.4 Deliverables ..................................................................................................................... 37
4.5 COMPONENT 4 – CHANGE MANAGEMENT, TRAINING AND KNOWLEDGE TRANSFER ..................... 38
4.5.4 Deliverables ..................................................................................................................... 39
4.6 COMPONENT 5 – OPERATIONS, MAINTENANCE AND SUPPORT ................................................... 39
4.6.4 Deliverables ..................................................................................................................... 40
4.7 COMPONENT 6 – PROJECT MANAGEMENT ................................................................................ 41
4.7.4 Deliverables ..................................................................................................................... 42
4.8 COMPONENT 7 – QUALITY MANAGEMENT ................................................................................. 43
4.8.4 Deliverables ..................................................................................................................... 44
4.9 COMPONENT 8: IMPLEMENTATION TIMELINE.............................................................................. 45
5 SUBMISSION PROCEDURES AND REQUIREMENTS ................................................................................. 46
5.1 BIDDER QUALIFICATIONS ......................................................................................................... 46
5.2 RESPONSE PROCEDURES ........................................................................................................ 46
5.3 RESPONSE FORMAT ................................................................................................................ 47
5.3.1 Part I: Technical Proposal ................................................................................................ 47
5.3.2 Part II: Financial Proposal ................................................................................................ 49
5.3.3 Part III: Bid Security ......................................................................................................... 50
5.4 RESPONSE SUBMISSION .......................................................................................................... 50
5.5 RESPONSE EVALUATION .......................................................................................................... 51
5.5.1 Technical proposal ........................................................................................................... 52
5.5.2 Financial proposal ........................................................................................................... 53
5.6 FINANCIAL TERMS ................................................................................................................... 53
5.6.1 Pricing terms .................................................................................................................... 53
5.6.2 Tender bond..................................................................................................................... 53
5.6.3 Other commercial terms .................................................................................................. 54
5.7 KEY RFPS DATES & DEADLINES .............................................................................................. 54
6 GENERAL TERMS ................................................................................................................................... 56
6.1 ESCALATION PROCEDURE AND PENALTIES: .............................................................................. 56
6.2 PREVENTIVE MAINTENANCE (PM) ............................................................................................ 57
6.3 PENALTIES FOR DEFAULTING ON PM ........................................................................................ 57
6.4 LEGAL TERMS ......................................................................................................................... 57
6.4.1 Joint-ventures .................................................................................................................. 57
6.4.2 Proposal Authorization .................................................................................................... 58
6.4.3 Corrupt and Fraudulent Practices .................................................................................... 58
6.4.4 Sample Arabic Contract Agreement Approval: ................................................................ 59
6.4.5 Other Legal Terms ........................................................................................................... 59
6.5 CONFLICT OF INTEREST ........................................................................................................... 65
6.6 SECRECY AND SECURITY ......................................................................................................... 65
6.7 DOCUMENTS PROPERTY .......................................................................................................... 65
6.8 REMOVAL OR/AND REPLACEMENT OF PERSONNEL .................................................................... 65
6.9 OTHER PROJECT-RELATED TERMS........................................................................................... 66
7 ANNEXES ............................................................................................................................................... 67
3
7.1 BYLAW OF ORGANIZING & CONTROLLING INVOICING 34/ 2019 ( ‫نظام تنظيم شؤون الفوترة والرقابة عليها‬
)2019 ‫ لسنة‬34 ‫ رقم‬............................................................................................................................. 67
7.2 GOVERNMENT PRIVATE CLOUD (GPC)..................................... ERROR! BOOKMARK NOT DEFINED.
7.3 NATIONAL E-GOVERNMENT CONTACT CENTRE REQUIRED INFORMATION ................................... 70
7.4 TECHNICAL PROPOSAL RESPONSE FORMAT............................................................................... 72
7.5 FINANCIAL PROPOSAL RESPONSE FORMAT .............................................................................. 77
7.6 CONFIDENTIALITY UNDERTAKING ............................................................................................. 83
7.7 JOINT VENTURE AGREEMENT TEMPLATE .................................................................................. 85
7.8 E-GOVERNMENT IMPLEMENTATION FRAMEWORK ...................................................................... 86
7.9 SAMPLE ARABIC CONTRACT AGREEMENT (ATTACHED) ........................................................... 109
4
DISCLAIMER
THIS DOCUMENT IS A REQUEST FOR PROPOSAL (RFP), AND SHALL NOT BE CONSTRUED IN WHOLE OR
PART AS A DIRECT OR INDIRECT ORDER. IT SHALL NOT BE CONSTRUED AS A REQUEST OR
AUTHORIZATION TO PERFORM WORK AT THE EXPENSE OF THE INCOME AND SALES TAX DEPARTMENT
(ISTD). THE INFORMATION IN THIS RFP IS INTENDED TO ENABLE BIDDERS TO FORMULATE A PROPOSAL
IN RESPONSE TO THE PROJECT REQUIREMENTS SET FORTH. ALTHOUGH THIS RFP CONTAINS SUCH
ENABLING INFORMATION, BIDDERS MUST MAKE THEIR OWN INDEPENDENT ASSESSMENTS AND
INVESTIGATIONS REGARDING THE SUBJECT MATTER OF THIS RFP. MODEE DOES NOT GUARANTEE THE
ACCURACY, RELIABILITY, CORRECTNESS OR COMPLETENESS OF THE INFORMATION IN THIS RFP. THE
BIDDER REMAINS RESPONSIBLE IN RELATION TO IDENTIFYING ANY FURTHER INFORMATION THAT IS
REQUIRED TO PREPARE THE PROPOSAL. THIS RFP SHALL CONSTITUTE PART OF THE CONTRACT THAT
WILL BE SIGNED BETWEEN ISTD AND THE WINNING BIDDER.
5
1 INTRODUCTION
1.1 RFP Organization
This RFP provides the information to enable bidders to submit written proposals for the sought
solution. The organization of the RFP is as follows:
Section 1: Introduction
This section outlines the RFP’s purpose and its organization.
Section 2: Project Definition and Description
This section provides general definition of the project scope and a high-level description of the
solution to be implemented,
Section 3: System Features and Requirements
This section describes the functional and technical requirements for the System.
Section 4: Scope of Work for Project Delivery
This section defines scope of work, proposal requirements and deliverables for the Project.
Section 5: Submission Procedures and Requirements
This section describes the administrative rules and procedures that guide the proposal and its
processes. This section also contains the dates that govern this RFP.
Section 6: General Terms
This section describes legal terms in relation to this RFP, bidder submissions, project delivery, and
other contractual terms and conditions.
Section 7: Annexes
This section includes all annexes to the RFP.
6
1.2 RFP Purpose
Ministry of Digital Economy and Entrepreneurship (MoDEE) is soliciting proposals from qualified
bidders as described in section 5 to provide Income & Sales Tax Department (ISTD) with a specialized
National E-Invoicing Solution and to collect data and manage information of sales processes from
sellers/ buyers or any third party, herein after referred to as the Project.
Income and Sales Tax Department (ISTD) is going to implement a national e-Invoicing solution as ISTD
is considering requiring sellers and buyers to use electronic invoices (e-Invoices) and submit those e-
Invoices to the ISTD.
Types of transactions that need to be considered:
 Business-to-Business (B2B)
 Business-to-Government (B2G)
 Business-to-Consumer (B2C)
Types of invoices to be considered:
 In-country with applied tax rate, for both domestic and foreign invoices
 Export - with optional override of 0% tax rate
 Import - with optional override of 0% tax rate
The proposed solution will benefit as the following:
 It will help prevent fraud and detect tax evaders.

 By eliminating the need to print paper invoices and deliver them to buyers; it would
make the process more efficient and less costly for business-to-business transactions.
 Proposed solution should provide different access channels such as mobile apps and
web platform.
 Ease of implementation for business entities to adopt new e-invoicing solution.
 Consistent high-quality user experience across all interfaces.
The winning bidder will be responsible for successful delivery of the project within specified timeframe
and must follow agreed tasks and achieve desired goals and requirements so that the project is
managed efficiently and effectively.
Responses to this Request for Proposal (RFP) must conform to the procedures, format and content
requirements outlined in this document. Deviation may be grounds for disqualification.
7
2 PROJECT DEFINITION AND DESCRIPTION
2.1 Current Situation
ISTD does not have an E-invoicing solution that handles invoices issued by sellers of commodities or
services. As of 1st of July 2019, invoicing bylaw No. 34 of 2019 has become effective and sellers of
goods and / or service have been obliged to issue an invoice for the sale.
The ways businesses currently manage their invoices vary greatly, as some sellers have their own
invoicing systems, others use third party systems and services, and some do not have systems at all.
This results in many challenges when businesses are exchanging information with the department, for
various accounting and compliance reasons.
It is the ISTD’s priority to help enable smaller businesses to use a common e-Invoicing solution directly.
In addition, the final solution should support common accounting functions and practices as it relates
to invoicing.
2.2 Legal Framework
This RFP document is being issued in response to the new invoicing provision of the tax law 38/2018
and bylaw of organizing & controlling invoicing 34/ 2019, please refer to (Annex 7.1) and the solution
must comply with Jordan Cloud Policy 2020 “2020 ‫”سياسة المنصات السحابية وخدماتها‬.
2.3 Usage Statistics
Usage Types Number
Income Tax Registered persons 1343123
Sales Tax Registered entities 34506
Expected number of invoice issuer 356000
Expected Daily invoice issued per invoice issuer 50
Total expected number of invoices daily 17,800,000
ISTD Users 1000
Invoicing Increasing percentage yearly 5%
2.4 General Definitions
 Good /commodity: any natural material or animal, agricultural or industrial product

including electricity power.
8
 Service: any activity done by the person for a fee, including the provision of a benefit to
others. This work does not include the supply of a good unless this commodity is required to
provide this service.
 Seller: the person who sells good, commodity, service.
 Invoice: a statement issued by seller describes the good, service or commodity and quantity,
price, tax calculated.
 Commodity selling: The transfer of the ownership of the commodity from the seller to the
buyer (for a fee or without) or use of the commodity by the person for his own purposes or
the empowerment of third parties for a price or for free or disposition of any of the legal
acts conveying ownership.
 Business to Government (B2G): the sale of products and services to federal, state, or local
agencies.
 Business to Business (B2B): transactions of goods and/or services that is conducted between
companies, rather than between a company and individual buyers.
 Business to Consumer (B2C): selling products and services directly to individual buyers who
are the end-users of those products or services.
 Service selling: Perform, deliver or provide the Service from Seller to Buyer for a fee.
9
3 SYSTEM FEATURES AND REQUIREMENTS
The project aims to build an E-Invoicing Solution based on industry best practices, information security
and Business continuity should be taken into consideration in the proposed system architecture.
In the following sub-sections, the requirements and features of the E-Invoicing Solution are explained
as follows:
 User Groups
 Access Channels
 Use Cases
 Systems
 Conceptual Architecture
3.1 User Groups
We have defined user groups according to types of needs and uses of the national e-invoicing system.
User type Description
Individual Buyer The retail buyer, who pays the full invoice value and is not required to keep a
record of received invoices as costs to be offset against income. The
Individual Buyer is expected to either use a mobile phone or a computer to
access the system.
Commercial Any sized business that needs to receive and process invoices. Depending on
Buyer size, this type of business may use any access channel, including outsourced
accounting services.
Government A public service entity that needs to receive and process invoices using any
Buyer access channel.
Commercial Any size seller that may use any type of system to present e-Invoices for a
Seller transaction.
Accountant A specialized accounting business that may use desktop computers or APIs to
access e-Invoicing functionality.
Administrator A MoDEE or ISTD employee with administrative rights to the e-Invoicing

platform.
Contact Centre A contact centre employee, who needs to track the status of open tickets on
Operator the e-Invoicing platform.
10
ISTD Auditor An ISTD employee responsible for reviewing and reconciling invoices to
ensure compliance and accuracy.
ISTD Analyst An ISTD employee responsible for compiling statistical and financial analysis
as well as identifying anomalies for Auditors to investigate.
3.2 Access Channels
The scope of the solution and services will rely upon the following access channels.
Access Channel Description
Mobile An iOS or Android smartphone with e-Invoicing application.
Web Portal The standard public-facing web interface to the e-Invoicing platform.
Application A web service interface to the e-Invoicing platform used for integrating
Programming third party systems.
Interface (API)
National E-Invoicing The standard user interface into the e-Invoicing platform for ISTD
System (NEIS) employees. This may be a web browser or a thick client.
E-Government Contact The standard user interface to the e-Government Contact Centre
Centre (EGCC) platform.
3.3 Systems
The scope of the solution and services will rely upon the following types of systems.
System Type Description
E-mail System used for receiving attachments as well as sending invoices and
notifications.
Close-Proximity Ability for users to receive invoice content on mobile devices via scan
Communication (machine-readable optical label, such as QR) or short-range wireless
communication (such as NFC).
Taxpayer’s System chosen/owned by the seller or buyer that is responsible for

Invoicing System generating, distributing, and storing invoices for their accounting purposes.
11
Public Service used to check whether invoices are registered within the National E-
Verification Invoice System.
Service
National E- The system that is subject of this RFP. In requirements, this system shall be
Invoice System referred to as “System”.
E-Government System to manage customer support and service related to e-Invoicing

Contact Centre systems to track and measure complaints, issue status and history.
(EGCC)
Government SMS System to facilitate and streamline the sending and receiving of SMS
Gateway messages.
3.4 Use Cases and Functional Requirements
3.4.1 Use Case 1: Receive e-Invoice

This represents the user’s ability to receive and/or retrieve an invoice using a convenient channel. The
user should be able to view the invoice and have the option to store it in their preferred location.
Number Requirement
The System shall allow buyers to receive invoices electronically via:
 QR code,
 PDF,
R01.01  Image (photo),
 Data object.
Other forms of receiving the invoice electronically may be proposed, ex. custom
mobile app to mobile app.
The System shall allow for receiving paper invoices by scanning them and entering
R01.02
information is manually by the receiving party.
The System shall allow the buyer/seller to retrieve a received/sent invoice by

R01.03
specifying criteria, like invoice number, data, seller name, etc.
The System shall allow the buyer/seller to export a collection of invoices that meet
R01.04 certain criteria for processing outside the system (ex. to import into accounting
software, store on disk, etc.).
The System shall provide an ability for a foreign buyer to submit collected officialised
R01.05 invoices for refunding paid sales tax. Foreign buyer types will be identified by ISTD.
ISTD will manage refund.
12
3.4.2 Use Case 2: Validate e-Invoice
This represents the user’s ability to validate if an e-Invoice has been registered in the National e-
Invoicing Solution and to verify the e-Invoice data format.
Number Requirement
The System shall provide a mechanism to verify the compliance of an e-Invoice to data
R02.01
format requirements. This may be done offline using a published toolkit.
The System shall provide a mechanism to allow an invoice holder to verify that an Invoice
has been registered with the System by the seller.
R02.02
This should be possible without the use of a trusted connection (i.e. no login required). Ex.
use cryptographic signatures.
3.4.3 Use Case 3: Send e-Invoice

This represents the user’s ability to send an invoice using a convenient channel while maintaining
privacy.
Number Requirement
The System will send notification(s) for significant transaction events. The supported
notification delivery methods includes and not limited to:
R03.01 1. E-Mail
2. SMS
3. Push notifications on the solution portal and mobile app.
As well as any other channel that will improve service delivery.
The System shall generate a QR code that contains invoice data allowing for receiving of the
R03.02
invoice with the help of a QR code scanner.
The System shall allow for sending a generated invoice by:
 Email,
 QR code,
R03.03  File on disk.
As a:
 PDF file,
 Data object.
13
The vendor may suggest other delivery methods that will improve service delivery. An email
gateway will be provided.
3.4.4 Use Case 4: Create e-Invoice

This represents the user’s ability to construct a valid e-Invoice, so that it can be processed and stored
by all interested stakeholders.
Number Requirement
R04.01 The System shall be able to generate e-Invoices as PDF documents that can be printed.
R04.02 e-Invoice creation shall be possible via the Mobile application.
R04.03 e-Invoice creation shall be possible via the Web application.
R04.04 e-Invoice creation shall be possible via the Web API.
The System shall provide issuing and modification functionality including: add, delete,
R04.05
modify for all invoices.
The System shall allow for some sellers to be authorized to generate a report of invoice
records for a given time period as a report that is generated submitted as a single invoice
to the System.
R04.06
Such Sellers must still be able to generate an individual invoice for a buyer that requests it.
Such an invoice would not be included in the report.
R04.07 The System shall also enable users to associate other files with an invoice.
The System shall provide the ability to amend invoices after issuance or after the transfer
to ISTD so that the old invoice is not deleted but shows the modification made and the
R04.08
adjustments to the invoices. This should also include which user made the adjustments and
the associated time stamps.
The System shall allow for invoices to be generated offline for later registering/uploading
R04.09
individually or in batch.
The System shall have the ability for the seller to save a draft invoice to be able to come
R04.10
back to it later, before it is finalized (signed and registered).
The System shall allow for the creation of invoices for foreigners with the purpose of filing
R04.11
for tax return during exiting the country.
14
3.4.5 Use Case 5: Store e-Invoice
This represents the user’s ability to store an e-Invoice in a convenient location while maintaining
privacy. The requirements in this section also address invoice data and features.
Number Requirement
R05.01 The System shall store registered invoices for later retrieval.
The period of storage of invoices by The System shall be indefinite. It is allowable for long
R05.02 term storage (ex. after 6 months) to be in an archival subsystem with lower performance
parameters.
If an invoice is in hardcopy format, it is required that it is scanned (by photo and/or scanner)
R05.03 and captured along with an identification number and regular invoice data in order to be
accessed and retrieved.
The System shall contain a database of harmonization codes for which there will be defined
R05.04
allowable tax rates that may vary with time according to changing government policy.
The harmonization codes shall be imported from an external Customs system and
R05.05 maintained by ISTD users locally with custom codes that will map back to the Customs
codes.
The System shall accept and store invoices in Universal Business Language (UBL) standard.
R05.06
Invoice data shall include at least the following:
 identification number of the invoice,

 full name and address of the seller,
R05.07  seller's tax number or national number,
 date of issuing the invoice,
 buyer name if invoice amount > 10,000 JD or postponed invoice,
 item or service description, quantity, prices, and Tax amount and rate,
 payment terms,
 comments.
The System shall allow for invoices to contain additional customized information that the
seller may add at their discretion.
R05.08
Ex. payment balances, invoice history, discount information, etc.
The System shall provide the ability of dealing with lease contracts as invoices. See
R05.09 section 7.1: Bylaw of organizing & controlling invoicing 34/ 2019 ( ‫نظام تنظيم شؤون الفوترة‬
)2019 ‫ لسنة‬34 ‫والرقابة عليها رقم‬7.1
The System shall have the capability to store and link scanned/captured paper invoices with
R05.10
invoice data in the same way as regular e-Invoices associated with buyers and sellers.
15
The System shall allow for an e-Invoice to contain the buyer’s name and identifier in some
R05.11
situations. Ex. Invoice amount over 10k JOD, post-payment.
Ability to handle international transactions and support invoices of different localized

types:
R05.12
 In-country purchase with appropriate sales tax
 Export (with optional 0% tax)
 Import (with optional 0% tax)
The System shall be able to allow ISTD users to attribute and categorize goods and services
R05.13
according to a SKU.
The SKU database must be connected and mapped to the standardized tax harmonization
R05.14 codes. The database will be under the sole management of ISTD users for maintenance and
upkeep of codes and SKU mappings.
Optional Feature: The solution should be able to scan/capture paper invoices, identifies
R05.15
their data and details, and converts them into UBL.
The System shall have advance search and filtration option so it will facilitate retrieving the
R05.16
required invoice data by ISTD users.
R05.17 The System shall log all create, read, update, and deletion requests.
The ability to share, access, and issue invoices must comply with privacy rules and
R05.18
regulations (e.g. confidential, sensitive, or personally identifiable information).
The System shall allow for Invoice storage operation by a buyer or seller to be either
R05.19
individual or in batch for a group of invoices.
R05.20 The System shall allow attachments to be stored along with an invoice.
3.4.6 Use Case 6: Sign/Register e-Invoice

This represents the user’s ability to sign an e-Invoice using their identity and register it with the
National e-Invoicing Solution.
Number Requirement
The System shall allow for generated invoices to be signed by the seller and officialised by
R06.01
registering them with the ISTD system individually or in batch.
The System shall allow for a corrected version of a signed invoice to invalidate the previous
R06.02
signed version of the same invoice.
The System shall allow for cancelling/deletion of signed and registered invoices by the seller
R06.03
and buyer. Such invoices shall no longer pass validation defined in requirement R2.02.
16
The System shall require and facilitate meeting the requirement that invoices above 10,000
R06.04 JD or that are postpaid receive confirmation of receipt by the buyer. This should dynamically
update per the specific invoice amount. See Annex in section 7.1.
The System shall allow interaction between sellers & buyers in order to correct the e-
R06.05
Invoice through credit and debit notes.
3.4.7 Use Case 7: Perform System Administrative Functions

This represents the ISTD Administrator’s ability to perform administrative tasks on the National e-
Invoicing Solution.
Number Requirement
The System shall provide dashboard for statistical information and generate analytical and
operational reports to provide live dashboard information on specified business KPIs.
R07.01
The winning bidder shall gather all reporting related requirements during business
requirements gathering and analysis phase to be able to build 5 report types.
The System shall employ the latest technological methods available to allow the
R07.02
administrator to assign roles to users: system administrators, seller, buyer, etc.
The system administrator may configure and provision access rights and functionality based
on roles.
The system administrator roles themselves may involve a hierarchy of administrative sub-
roles and functions.
System administration includes the following default operations:

R07.03
 add user profile,
 delete user profile,
 modify user profile,
 assign role to user profile,
 grant and revoke permissions,
 reset user password.
The System shall log all transactions on a user profile, including create, read, update, delete
R07.04
operations. The system should also capture login & logout transactions.
The sellers and buyers group should be granted access to free services by default.
R07.05
During the requirements gathering phase some functionalities will be defined as premium
services.
17
Within the free service functionality the seller/buyer shall have access to his file which
R07.06 includes the invoices, their values and details, and ability to report over date and time
ranges.
The System shall have functionality to mark seller types required by tax law in section 7.1.
These types will include:
R07.07
 Sellers allowed to issue cumulative invoice reports,
 Sellers required to create tax invoices.
The System shall have flexibility to be efficiently modified/reconfigured in response to
R07.08
legislation amendments.
3.4.8 Use Case 8: Register for e-Invoice Service

This represents the seller’s and buyer’s ability to register on the e-Invoicing system to make it possible
for them to issue valid signed e-Invoices.
Number Requirement
The System shall have a buyer/seller registration mechanism that includes 2-factor
R08.01
authentication, with a secondary factor such as e-mail, user's phone number, token, etc.
The System shall support user profile management and the ability to update the user profile
R08.02
information.
The System shall have an authentication module related to the “Sellers” and “Buyers” which
shall implement information security measures that guarantee information confidentiality,
R08.03
integrity, availability and accountability (non-repudiation) to meet the security level
sufficient to guarantee service delivery.
The System shall have an authentication module related to the administration and ISTD
R08.04 user part of the solution that should be integrated with the ISTD LDAP to allow ISTD
employees to access the system with a predefined roles and responsibilities.
The System shall support the ability for sellers to use two types of identifiers to register in
R08.05
the system: sales tax number, or the national number if sales tax number does not exist.
3.4.9 Use Case 9: Handle claims and complaints

This represents the user’s ability to generate and view the status of an open ticket from the e-Invoicing
System via the e-Government Contact Centre.
18
Number Requirement
The System shall make available a query interface with National Contact Centre (NCC) for
all raised complaints regarding the proposed e-Invoicing solution that allows for status
R09.01 tracking by ISTD-authorized Contact Centre employees.
Such employees can access and check the tickets information, status, and history.
Accordingly, enabling the agents to access the entity’s related applications for retrieving
R09.02 information, tracking the status of a service.
Please refer to (Annex 7.2) for more information about the Contact Centre requirements.
3.4.10 Use Case 10: Identify Audit Subjects

This use case refers to the ISTD user’s ability to run analytics that help in identifying taxpayers that
should be targeted for a detailed tax audit by ISTD auditors.
Number Requirement
The System shall allow for a data science team to create analytic reports to help identify
anomalies to identify audit subjects, and support business intelligence and risk analysis
capability.
R10.01
The system shall provide analytics and techniques to deal with, manipulate and provide
deep insights from high volumes of different types of data contained in e-invoices.
3.4.11 Use Case 11: Run audit reports

This represents the user’s ability to generate dynamic reports for audit purposes, as well as search for
invoices during an audit.
Number Requirement
The System shall have the ability to create dynamic report and save the result as template
so it can be reused later. Main functionality that can be provided are:
 Dynamic column define (at runtime).

R11.01  Create Group Report
 Dynamic Layout
 Inherited report design
 Sub Report
 Calculation Variables
19
 Exporting data to multiple format
 Add Chart and Images
 Connect to different Data Sources
 Matrix Report
 Form Report
This requirement may be met with the use of a standard reporting product, such as Crystal
Reports.
The System shall allow for ISTD Auditors to be able to find and view individual invoices that
R11.02
are stored in the system.
The System shall be able to generate reports for a given buyer/seller for reconciliation with
R11.03
tax return filings.
3.5 Conceptual Architecture
To help inform and structure the RFP requirements we propose a conceptual architecture that
represents high level relationships between the following entities:
 User groups
 Access channels
 Use cases
 Systems
3.5.1 E-Invoicing end user dimension overview
20
3.5.2 User groups to access channel interactions
3.5.3 Access channel to use case relationships

Mobile Use Cases
Web Use Cases
21
API Use Cases
Administrative and contact centre use cases
22
3.5.4 Use cases to system interactions
3.5.5 Back office dimension
3.6 Mandatory Non-Functional Requirements
The table below details the non-functional requirements as part of the proposed national e-Invoicing
solution.
3.6.1 General
Number Requirement
23
NFR01 Proposed solution should be centralized and hosted on a public cloud.
Proposed solution should be friendly and easy to use. (For the user experience compliance
NFR02
see Section 3.6.2)
NFR03 Availability & continuity; must be guaranteed 24/7.
The System shall meet efficiency targets to serve volumes of transactions described in
Usage Statistics section and number of users. Please find the performance measures
defined below.
 System reaction time: The time taken for logging into a system. [Up to 5
seconds].
 Response time: The time the system takes to respond to specific query by the
NFR04 user. [Up to 4 seconds].
 Capacity: The capability of the newer system to handle a number of
simultaneous requests from the network for the application and the volume
of data that it can handle from each of the users.
 In addition to the H/W capacity such as processing capability of all servers
including DB, Apps. [CPU Utilization: 70%, Memory Utilization: 70%].
 Utilization: The system minimum availability time vs. the system down time
[99.9].
The System shall contain administration module, to enable administrators to perform all
day-to-day administrative tasks at data, administrative task automation (scripting) engine,
and application levels.
NFR05
The winning bidder shall gather all solution related administration requirements during
business requirements gathering and analysis phase.
NFR06 The System shall include performance monitoring for all transactions.
Security of system and exchanged transaction information should be guaranteed at all

system layers Based on ISO 27001, WS-Security standards including infrastructure,
NFR07 application, web services and integration points, and access channels. This also includes
using detective and preventive controls for all security threats and approval by CBJ, MoF
and MoDEE.
In the cases where any parts of the user interface solution were developed web forms,
NFR08 those forms should support latest versions of the most popular browsers. According to the
W3C standards.
NFR09.1 The System shall support the Arabic language, including invoice language.
NFR09.2 The System shall support the English language, including invoice language.
The System shall provide a user-friendly interface along with on-line help (in both
languages) for user guidance while applying for different services transactions (through
NFR10
messages, wizard …etc.). Available across all access channels (Mobile App, Web Browser,
…etc.).
24
System should Keep track of who logs in and in what time and what action they did.
The tracking sub-system should help getting such information as:
NFR11  Timestamp of creation/modification

 User last changed and date last changed
 Changed record and last operation (Create, Update, and Delete).
 Before and after value for each column that has changed.
 Keep Track of what user retrieve or view (Select)
The proposed solution must provide APIs for all functionalities, so that it provides the
NFR12 capability to be consumed by any access channel (such as but not limited to: Mobile Apps,
Web portals, etc.) when required.
The technical readiness and the possibility of invoicing system to be integrated with any
systems necessary to maintain its work and / or provide data for the invoice according to
the legislation in force and to meet the public interest and the purpose of the system.
 The proposed system should be able to integrate with the invoices issuers’
“Sellers” current systems.
NFR13  The proposed system should be able to integrate with the third party (system
provider) via an API, which provides service to invoices issuers that do not have
their own invoicing system.
 The system allows invoices issuers to transfer data over mobile applications and
through web browsers.
 The bidder must provide a web portal specified for invoicing services.
 All integrations with government entities should be done through GSB service see
(Annex 7.7).
A dedicated backup solution must be provided, installed and configured by the winning
NFR14
bidder to serve as a backup solution for the proposed e-Invoicing solution.
DAMP (Database activity monitoring and Protection): Proposed solution should have
NFR15 a database Real-time protection and security technology for auditing, monitoring and
analyzing database activities.
Integration with e-Government Service Bus (GSB):

The winning bidder shall integrate the proposed system with GSB through supporting web
NFR16 services and message communication using XML format and SOAP messaging protocol
(Please refer to (Annex 7.7) for integration guidelines and SDK). More details will be
provided upon awarding to winning bidder.
Integration with National e-Government Contact Centre (NCC):

The winning bidder shall integrate the system with the National Contact Centre through the
NFR17 Government Service Bus (GSB). Accordingly, enabling the agents to access the entity’s
related applications for retrieving information, tracking the status of a service.
Please refer to (Annex 7.2) for more information about the Contact Centre requirements
Integration with SMS Gateway Winning bidder shall utilize current SMS gateway provided
NFR18 by the e-Government.
25
The System shall integrate with the stakeholders’ systems involved in the e-Invoicing
solution through GSB.
The below list includes the main stakeholders of the system:
 MIT: Ministry of Industry, Trade and Supply

 CCD: Company Control Department
NFR19  Customs: Jordan Customs
 DVLD: Drivers and Vehicles Licensing Department
 CSPD: Civil Status and Passport Department
 DoBR: Directorate of Residence and Borders
 ISTD - Tax Administration System
All interfaces will be one way read-only for retrieval of reference data sets from these
stakeholders to the e-Invoicing System. Details of data sets for import will be defined during
the requirements gathering phase of the project.
The winning bidder must commit to adopting the ISTD project management tool as the sole
NFR20
tool for management and collaboration regarding project activities.
It shall be possible to integrate the system with a future loyalty system that will motivate
NFR21
adoption.
3.6.2 Customer Journey/Experience

It is envisaged that the design of standard customer experience ‘component’ would be of great help
to the MoDEE and ISTD, who may be in the process of developing new e-Government services to
ensure consistency among e-Government services and provide a focus for customer experience.
3.6.2.1 Technical Requirements:

Number Requirement
Cross-Platform Capability: the e-Invoicing System must be accessible from various

NFR22 platforms including desktops, laptops, tablets and mobile devices.
NFR23 Browser Compatibility: The winning bidder must ensure that e-Services works equally well
with all popular browsers including Chrome, Firefox and Internet Explorer etc.
Systems Integration: The developer must ensure e-Services integrates with the relevant
NFR24 backend systems e.g. CRM, Billing, payments gateway etc. and make sure transactions are
recorded on such systems and customer records are updated correctly.
NFR25 Alerts: If, for some reason, the site is down, the ISTD teams should be informed
immediately in an automated manner.
Content Management System: As well as delivering e-Services, the vendor must deliver a
NFR26 Content Management System (CMS) that will allow ISTD team (webmaster) to add, edit,
delete, publish etc. items including text, multimedia and links on their own without having
to go back to the vendor in the form of a ‘Request for Change’ (RFC).
26
Load Time: The winning bidder must ensure that the speed of the main page and
NFR27 associated pages always load up within 4 seconds. The speed test must be performed
using recognized applications/tools e.g. pingdom.com or similar
3.6.2.2 Features:
Number Requirement
NFR28 Bi-Lingual: e-Services must cater for both Arabic and English versions.
NFR29 Search Engine: e-Services must contain a search engine that can be interrogated for
keywords and multiple criteria where appropriate.
NFR30 Feedback Form: e-Services must provide a ‘Feedback form’ to enable the customer to
provide comments, questions or report problems/complaints.
Links to e-Government Social Media Accounts: e-Services must provide working links to
MoDEE, e-Government Social Media Accounts
NFR31
NFR32 Frequently Asked Questions: e-Services should include an FAQ section to answer basic
questions that the user may have.
NFR33 Rating: e-Services must provide a function for the user to provide customer satisfaction
rating for Voice of Customer purposes
NFR34 Site Map: e-Services should include a site map that can be used for quick and painless
navigation.
On-Screen Message Confirmation: For non-browsing function, each customer transaction
NFR35 must display a ‘success’ or ‘failure’ message on the screen to notify the customer of the
outcome of his/her transaction.
3.6.2.3 Logs/Reports:
Number Requirement
NFR36 No. of users/hits: The winning bidder must provide systematic daily reports to show the
number of users, and unique users to the site and the number of hits per page of the site.
Transaction Logs: The winning bidder is expected to provide daily transaction logs that
NFR37 would contain key information relating to ‘non-browsing’ functions e.g. payment, rating,
feedback. Each transaction should have a unique identification number that is system
generated and can be used to traceability purposes.
NFR38 Incidents Report: all incidents should be reported on the same day to the ISTD teams.
NFR39 Service Level Agreement: The winning bidder is expected to provide 24/7
27
3.6.2.4 Customer feedback:
Number Requirement
Focus Group: The vendor is expected to conduct a Net Promoter Score (NPS) survey
NFR40 through the use of focus group (10-20 people from the general public) through a
recognized market research agency to assess the user-acceptability levels of e-Services.
3.6.2.5 Customer information:

Number Requirement
Userid/password complexity tests: E-Services must perform userid/password complexity

NFR41 tests to ensure userid/password combinations are not easily guessed. Additionally, the
length and format of userid/password needs to be clear e.g. 6-10 characters (a..z, A..Z,
0..9 etc). Duplicate userids are not permitted.
NFR42 Forgotten userid/password: E-Services shall be able to receive requests where the
customer forgets his/her userid/password.
Re-activation of userid/password: In cases where the customer terminates his/her
NFR43 account for a service, e-Services needs to handle cases where the customer can re-
activate his/her account within a given grace period in a secure manner.
NFR44 Confidentiality/Security: All customer information needs to be treated in a confidential

and secure manner.
3.6.2.6 Information Architecture:

Number Requirement
Fonts & color schemes: E-Services should use the fonts (type & size) and color schemes as
NFR45 per ISTD website www.ISTD.gov.jo, this is to give a consistent ‘look & feel’ for all e-
Government services.
Ownership: E-Services should clearly show its ownership for ISTD and that it is part of the
NFR46
e-Government services through the use of Joint logos.
Information Structure: The information must be organized in such a way (links, drop-down
NFR47
menus etc.) that the user must be able to access the required information within 3 clicks.
3.7 Service Level Agreement Requirements
3.7.1 Definitions
3.7.1.1.1 Severity One (Urgent)
A severity one (1) issue is a catastrophic production problem which may severely impact the Proposed
Solution Availability, In such case, part or all proposed Solution production components are down or
not functioning; loss of production data and no procedural work around exists.
28
Examples of Severity one cases: DB becoming corrupted or inaccessible.
3.7.1.1.2 Severity Two (High)

A severity two (2) issue is a problem where the Proposed Solution is functioning but in a severely
reduced capacity. The situation is causing significant impact to portions of business operations and
productivity of Proposed Solution. The system is exposed to potential loss or interruption of service.
Example of Severity two cases: one node of cluster becomes down or unavailable, inability to update
DB by entities representatives or solution administrators, or inability to synchronize data between DB
nodes.
3.7.1.1.3 Severity Three (Medium)

A severity three (3) issue is a medium-to-low impact problem which involves partial non-critical
functionality loss one which impairs some operations but allows the Proposed solution
users/administrators to continue to function. This may be a minor issue with limited loss or no loss of
functionality or impact to the client's operation and issues in which there is an easy circumvention or
avoidance by the end user.
3.7.1.1.4 Severity Four (Low)

Important problem but it can wait no loss of functionality or impact to the client's operation and issues
in which there is an easy circumvention or avoidance by the end user.
3.7.1.1.5 Response Time

Time taken to acknowledge receiving of reported incident calculated from the time sending an email
explaining the incident, opening a ticket on bidder ticketing system, or conducting a phone call with
the assigned support engineer by the bidder or bidder’s first line of support.
3.7.1.1.6 Resolution Time

Time taken to solve the reported incident completely. Resolution Time is calculated from the end of
the defined response time for each severity level as shown in the above table.
3.7.2 SLA Requirements

Number Requirement
The response and resolution times shall fall within the values specified in Table 1: Required
NFR48
response/resolution times for different severity levels.
Table 1: Required response/resolution times for different severity levels
Severity Response Time Resolution Time
1 1 hour 4 hours
2 3 hours 24 hours
29
3 4 hours 72 hours
4 8 hours One Week
30
4 SCOPE OF WORK FOR PROJECT DELIVERY
4.1 Project Overview
There are certain activities to be performed and deliverables to be provided by the winning bidder during
execution of the Project.
The bidder shall provide the solution, knowledge transfer, training, support, maintenance and warranty,
including any requirements or activities needed for the proper functioning of the system beside those outlined
in the following listing and the cost of these requirements or activities should be included in the fixed lump sum
price submitted by the bidder. Note that the bidders should detail in their proposals all recommended
mechanisms and methodologies through which its services and deliverables will be accomplished. All the final
documentation deliverables of the project are required to be prepared in English.
The sign off and approval will be given on both Arabic and English language deliverables for the deliverables that
are required bilingual. In case the documents differed due to translation, the Arabic documents shall prevail and
will be considered as the official ones.
More information regarding project delivery is detailed as follows:
 For the purpose of the completion of this project, some of the activities must be implemented and
certified and approved by the Solution Vendor, these will be explicitly mentioned in the scope of work
of this RFP as Vendor Activities and Winning Bidder Activities respectively.
 Final deliverables submitted by the winning bidder should be attached to an original official letter
properly bounded, stamped and signed by the winning bidder as shall be defined and approved by
ISTD.
 Proposals submitted by bidders that do not properly describe an acceptable solution for the whole
solution components delivery shall be rejected for being not responsive to the RFP requirements
 The expected duration of the project is (365) calendar days for pilot go-live, and 18 months (6 months
post pilot) for mass rollout of the e-invoicing system.
 It is expected that the bidder will include 36 months for maintenance and support time post mass-
rollout of the system.
4.2 Component 1 – System Design, Installation and Configuration
4.2.1 Winning bidder activities

In order to develop and launch this solution and mobile App, the solution vendor is required to
perform the activities mentioned below, noting that any additional related activities needed for the
proper functioning of The System shall be provided by the winning bidder and its cost should be
included in the fixed lump sum price submitted by the bidder.
Overview of Activities
 Perform requirements gathering and analysis for solution processes related to the
delivery of the solution keeping in mind implementation of worldwide best practices
31
 Perform requirements gathering and analysis for solution stakeholders keeping in mind
implementation of worldwide best practices.
 Develop needed policies, procedures and internal controls embedded in these policies
and procedures to govern the solution.
 Create a detailed requirements specifications document showing Integration with both
ISTD back-end system(s) and stakeholders.
 Starting with the high level requirements outlined in Section 3, create a detailed
functional design document together with detailed functional, non-functional and
technical specifications of the proposed solution, use cases and use case diagrams
considering the integration with all e-government shared services and the required
access and delivery channels
 Develop a prototype for the proposed system including user interfaces that can be
integrated with the e-government shared services
 Design, develop, implement, deploy (install, test, launch) and rollout of the proposed
solution. This needs to be aligned with the e-Government Architecture Framework
(including but not limited to the use of shared components and services like the SMS
Gateway, e-Government Contact Centre, and Government Service Bus (GSB).
 Develop on-line help for the solution through which users can inquire (via web) or any
other access channel provided by the e-Government Contact Centre.
 Design and build required interfaces for the various shared e-government infrastructure
components and integration with stakeholders through GSB
 Develop and conduct the User Acceptance Test (UAT) in collaboration of ISTD and
Stakeholders’ teams.
 Ensure high level of security for production environment layer.
 Prepare all needed documentation that shall enable ISTD to take over the operational
part for the proposed solution smoothly, this shall include the Operation manual for the
managing the major functionalities of the proposed solution, in addition to System
administration manual.
 Copyright to all bespoke and customization source code pertaining to Smart Attestation
solution applications must be handed over to MoDEE.
 Any open source software used as part of the solution must be licensed to use for this
project the terms of this license must be disclosed by the bidder in the bid terms. The
source code to such software must accompany the deliverables.
 Any closed source software used as part of this solution must be licensed to use by
MoDEE and the terms of this license must be disclosed by the bidder in the bid terms.
4.2.2 Technical Proposal Requirements

The bidder is required to provide the following information in the technical proposal in relation to the
System delivery.
System Implementation
 Provide a high-level design of the solution, describing system architecture, functions and
interactions of all the components,
 Describe how the solution will meet functional requirements, as described in
Section 3.4: Use Cases and Functional Requirements. Use the attached compliance
matrix excel to complement the answer.
32
 Describe how the solution will meet non-functional requirements as described in
Section 3.6: Mandatory Non-Functional Requirements. Use the attached compliance
matrix excel to complement the answer. (the winning bidder will be provided with the
relevant documentation describing the integration with the available access and delivery
channels)
 Describe approach to developing the prototype of the system
 Describe approach and methodology for integrating the solution with shared e-
government infrastructure and integration with stakeholders through GSB
 Describe approach of launching and rolling out the solution
 Provide a list of deliverables for the System Implementation
 Describe bidder’s qualifications in e-Invoicing Implementation
System Documentation
 Describe bidder’s qualifications in System Documentation development
4.2.3 Financial Proposal Requirements

The bidder is required to provide the following information in the financial proposal in relation to the
System Delivery:
 List all cost associated with the hardware equipment’s and software licenses included in
the proposed technical solution
 List all costs associated with the activities mentioned above
4.2.4 Deliverables
The winning bidder is required to provide the deliverables mentioned below, noting that any other
related deliverables needed for the proper functioning of The System shall be also provided by the
winning bidder and its cost should be included in the fixed lump sum price submitted by the bidder:
 System Implementation
o Requirements Analysis Document
o Detailed requirements specifications document
o Detailed functional, non-functional design, and technical specifications of the
system
o System prototype
o Implemented overall system delivery including relevant interfaces, data
migration (if needed), and web services necessary for integration with all related
internal and external systems and stakeholders.
o On-line help for the solution in Arabic language
o Detailed documented approach and implementation for the integration with the
shared e-government infrastructure and integration with stakeholders through
GSB.
 System Documentation
33
o System technical documentation (covering use cases and use case diagrams,
detailed requirements, architecture, data model, algorithms, protocols,
functionality of modules, quality-related documentation and artifacts, etc.)
o System manuals (covering software and hardware installation and configuration,
maintenance, backup, recovery, optimization etc.)
o End-user manuals (including and not limited to FAQ, “How do I” questions; in
Arabic & English).
o Detailed User Acceptance Test (UAT) Document and UAT test result report
based on Winning Bidder execution of those tests.
4.3 Component 2 – Required Solution Infrastructure
4.3.1 Winning bidder activities and technical proposal requirements

MoDEE is seeking proposals to host the solution on Public Cloud. The bidder must provide the
following details of the Public Cloud service:
1. The public cloud provider

2. The base technology of the public cloud
3. The location of the public cloud infrastructure
4. Location of the public cloud DR infrastructure
5. A detailed licensing\subscription model of both public cloud and the solution
6. Security measures taken
7. The possibility of doing aa 3rd party penetration testing on the hosted solution
8. How we can manage the hosted data, in terms of access, monitoring, delegation for
authorities, etc.
9. Logical Infrastructure architecture for the solution and how it will be hosted
10. Provide the service level agreement with the public cloud provider
11. Exit policy details
Note: If during implementation found that the components described in the technical proposal
submitted by the winning bidder do not fulfil the requirement of the scope of this project, then the
winning bidder must provide all additional needed components and the cost of these additional
components will borne by the winning bidder.
4.3.2 Financial proposal requirements

The bidder is required to provide list of all costs associated with the required infrastructure of the
System in the financial proposal.
Note: the financial proposal shall list all costs associated with all required licenses to provide the
proposed solution as listed in the technical proposal regardless of whether these licenses are covered
under the framework agreements with the government of Jordan or not and shall be included in total
project lump sum price.
34
4.3.3 Deliverables
The winning bidder is required to provide the deliverables mentioned below:
1. Comprehensive Logical Infrastructure Architecture detailing the solution components

2. Required Licenses for the proposed e-Invoicing solution
4.4 Component 3 – Solution Security Requirements

The winning bidder is required to perform the activities mentioned below to ensure System security:
 Develop a detailed backup policy and related procedures encompassing handling the
proposed solution and security controls. i.e. backup policy and procedures, auditing policy,
etc., and in compliance with ISO 27001 standard. The policy and procedures should consider
the operational environment of ISTD.
 Assess security risks implied in implementation of the proposed solution and in integration,
if any, with legacy system. And recommend and include controls to mitigate them.
 Conduct risk assessment by identify security threats and risks to the developed system, and
identify the controls applied by the developing bidder and the suggested controls.
 Appropriately assess, implement, test and deploy information security controls and
measures to secure the System considering the following:
o Controls to enforce separation of duties depending on Need-to-Know and Need-to-
Do.
o Controls to ensure input validation, data processing and output integrity and
confidentiality.
o Controls to ensure secure data at rest, in use and in transit, including encryption and
hashing algorithms and encryption keys management.
o Controls to ensure secure messaging according to the WS-Security Standard.
o Controls to secure transactions and messaging among all stakeholders and solution
components.
o Controls to ensure user privacy, including but not limited to, cookies management,
users log file and behavior.
o Controls to ensure secure exception and error management that is both user-
friendly and not revealing sensitive and structure data.
 Design and build secure connections and communication channels to ensure:
o Secure connections between clients and the System.
o Secure connections between the System and back-end systems (if any).
o Communication channels should be secured as per WS-Security specifications.
o Internet access should use encrypted communication channels.
 Provide and deploy security applications/solutions to secure the communication channel for
front-end and back-end systems.
 Design and build secure user identification and authentication approach.
 Ensure that Portlets are protected against web application threats, such as dangerous URL
and attacks such as cross-site scripting, Session Hijacking. The solution should ensure that it
is not vulnerable to common vulnerabilities and latest OWASP Top 10 vulnerabilities.
35
 Ensure that the final solution include comprehensive audit and log management and
reporting tools for all transactions, especially security logs, based on need-to-know and
need-to-do basis and having the following criteria:
o Audit and logging, comply with ISO 27001 and contain but not limited to:
- Input validation failures e.g. protocol violations, unacceptable encodings, invalid
parameter names and values
- Authentication successes and failures
- Authorization (access control) failures
- Session management failures e.g. cookie session identification value
modification
- Application errors and system events e.g. syntax and runtime errors,
connectivity problems, performance issues, file system errors, file upload virus
detection, configuration changes
- Application and related systems start-ups and shut-downs, and logging
initialization (starting, stopping or pausing)
- Use of higher-risk functionality e.g. addition or deletion of users, changes to
privileges, assigning users to tokens, adding or deleting tokens, use of systems
administrative privileges, access by application administrators, all actions by
users with administrative privileges, access to payment cardholder data, use of
data encrypting keys, key changes, creation and deletion of system-level objects,
data import and export including screen-based reports, submission of user-
generated content - especially file uploads
- Modifications to configuration
- Application code file and/or memory changes
 Audit record should contain the following information:

- When: time of event, time of log,
- Where: application/web service identifier, Window/form/page e.g. entry point
URL and HTTP method for a web application, code location.
- Who: source address and user ID.
- What: type, severity and description of the event, object.
- HTTP Status Code (web service only) - the status code returned to the user
(often 200 or 301)
- Request HTTP headers or HTTP User Agent (web service only)
- Log throttling should be used.
 Sensitive data is to be excluded from logs. See “National Security Policy”
 Build security controls in the proposed service/application against Level 1 and Level 2
controls of OWAS Application Security Verification Standard V4.0 (2019)
 Verify the implementation of all the required OWAS ASVS controls.
NOTE: ISTD reserves the right to perform their own vulnerability assessment and/or penetration test
on the solution and provide the vulnerability reports to the winning bidder to apply appropriate
recommendations to ensure system security. Another security test should be conducted to ensure
recommendations are reflected
4.4.2 Technical proposal requirements

Information Security:
36
 Risk Assessment plan or methodology.
 List of policies to be developed.
 Proposed security design of controls to be applied within the design in all layers: network
security, host security, application security, data security, and access management, if any.
 Proposed approach(s) to ensure confidentiality, integrity, availability, authenticity, auditing,
non-repudiation and accountability of data and services usage for the solution.
 Proposed approach(s) to ensure security for the following requirements:
o Separation of duties depending on Need-to-Know and Need-to-Do.
o Input validation, data processing and output integrity and confidentiality.
o Secure data at rest, in use and in transit, including encryption and hashing
algorithms and encryption keys management.
o Secure messaging according to the WS-Security Standard.
o Secure transactions and messaging among all stakeholders and solution
components.
o Ensure secure identification, authentication and user profile management.
o Ensure user privacy, including but not limited to, cookies management, users log file
and behaviour.
o Ensure secure exception and error management that is both user-friendly and not
revealing sensitive and structure data.
 Proposed design for secure connections between clients and the System.
 Proposed design for secure connections between the System and back-end systems.
 Proposed solution for encrypting internet communication channels.
 Proposed secure user identification and authentication approach.
 Proposed design to protect Portlets against web application threats. The solution should
ensure that it is not vulnerable to OWASP Top 10 latest vulnerabilities. I.e. design to secure
session management; security control such as session time out and secure channel and
access to session store should be used.

The bidder is required to provide list of all costs associated with the information security of the System
in the financial proposal.
4.4.4 Deliverables
The winning bidder is required to provide the deliverables mentioned below:
 Detailed security policy and related procedures encompassing handling the proposed
solution and security controls. i.e. backup policy and procedures, auditing policy, etc., Risk
assessment and mitigation document.
 Security design of controls appropriately implemented and tested information security
controls and measures to secure the target solution Separation of duties depending on
Need-to-Know and Need-to-Do.
 Input validation, data processing and output integrity and confidentiality.
 Secure data at rest, in use and in transit, including encryption and hashing algorithms and
encryption keys management.
 Secure messaging according to the WS-Security Standard.
 Secure transactions and messaging among all stakeholders and solution components.
 Ensure secure identification, authentication and user profile management.
 Ensure user privacy, including but not limited to, cookies management, users log file and
behaviour.
37
 Ensure secure exception and error management that is both user-friendly and not revealing
sensitive and structure data.
 Appropriately designed and built secure connections between clients and the System.
 Appropriately designed and built secure connections between the System and back-end
systems.
 Appropriately configured and secured user identification and registration.
 Security Test Results clarifying the elimination of the System from dangerous URL and
attacks such as cross-site scripting, Session hijacking. And it is not vulnerable to latest
OWASP Top 10 vulnerabilities.
 Audit and log management and reporting tools for all transactions, especially security logs
based on need-to-know and need-to-do basis.
 Verification check list against all the applied controls of the required in OWASP Application
Security Verification Standard V4.0 (2019) Level 1 and 2.
4.5 Component 4 – Change Management, Training and Knowledge

Transfer

In order to provide Change Management, Awareness, knowledge transfer and Training, the winning
bidder is required to perform the activities mentioned below noting that the winning bidder should
suggest the background and technical profile of the nominated trainees,
 Develop and execute awareness sessions plan in accordance to the current situation and
execute awareness sessions for identified entities, employees in involved entities and any
other identified stakeholders.
 Develop and execute training plan and knowledge transfer for identified team Training shall
be arranged at various phases of the project.
 Training venue and all needed PCs and equipment for training purposes must be provided by
the winning bidder.
 Number of trainees as follows:
1. NCC personnel (6).
2. Training of Trainers (ToT) for all types of end users (20)
3. System Administrators (12)
4. Security Training (10)
 Train ISTD team on the major components of the installed solution, this shall include the
following knowledge areas beside any tailored training that is related to the solution
components:
1. System Administration
2. System Monitoring
3. Data management
4. Reports and dashboards
 Knowledge Transfer: Transferring knowledge ISTD team for the following subjects:
1. System Installation
2. System Operation and Troubleshooting
3. System Backup and Restore
4. System Failure and Recovery Procedures
38
 Describe approach, including tools for knowledge transfer, awareness sessions and training
 Describe and list the proposed training sessions, session duration, and number of attendees
per session
 Provide a high-level training schedule showing the training activities
 Provide Awareness sessions plan.
 Provide a list of deliverables for the Knowledge Transfer, and Training
 Describe bidder’s qualifications in training including references and resumes of trainers.

 List all cost associated with the above activities under the Training and Knowledge
Transfer Component
4.5.4 Deliverables
The winning bidder is required to provide the deliverables mentioned below, and any other related
deliverables needed for the proper Knowledge Transfer, and training and its cost shall be included in
the fixed lump sum price submitted by the bidder:
 Training needs assessment report, knowledge transfer plan and awareness session plan.
 Knowledge transfer, and training sessions schedule and curricula
 Executed Knowledge Transfer and training sessions for all nominated trainees
 Provided training handout material.
 Executed awareness sessions for all involved entities.
4.6 Component 5 – Operations, Maintenance and Support

In order to execute “Operations Support and Maintenance” component of this project, the winning
bidder is required to provide all needed maintenance and support (including licenses) for 36 months
after obtaining the preliminary acceptance (Preliminary acceptance starts after accepting the
proposed solution by ISTD and before the support and maintenance period), noting that any additional
related activities needed for the proper functioning of The System shall be provided by the winning
bidder and its cost should be included in the fixed lump sum price submitted by the winning bidder:
 Assign a contact person / account manager to be responsible during the support and
maintenance period of this contract.
 Provide support and maintenance services on 24x7 basis for the implemented solution by a
team which possesses the proper knowledge and proven experience of the proposed
solution.
 Ensure the availability of educated resources to provide on-site support when needed
 Provide detailed implementation plan for any pre-planned maintenance operation that may
affect ISTD services availability, functionality or stability, with necessity to provide roll-back
plan before commencing with maintenance operation
39
 Issue a service report after each and every site visit registering the reported incident, its root
cause and the followed procedures for issue(s) successful resolution including the taken
and/or suggested recommendations and measures that shall prevent such incidents / issues
from reoccurring in the future.
 Renewal of the licenses for the software products (required for the covering and completion
of the scope of work in this RFP) should be for duration of 36 months starting from the date
of preliminary acceptance.
 Comply with the service level requirements defined by ISTD and as shown in Section 3.7:
Service Level Agreement Requirements of this document.
 Assign a hot line number to be used for reporting incidents
 Provide a ticketing system that records all reported incidents and that can be accessed by
ISTD and generated various incident reports
 Applying the latest fixes, patches and required upgrades to the installed software during the
support and maintenance period (if required) while ensuring system’s integrity, reliability,
conformity and normal operation for all system features including the content.

The bidder is required to provide the following information in the technical proposal in relation to
this component:
 Provide bidder’s methodology of providing the support and maintenance services required
in this RFP
 Demonstrate the technical capability for the team who will be in charge for maintaining and
supporting the proposed solution, by providing the team qualifications and number of
people who will be dedicated for supporting and maintaining the installed solution.
 Provide the appropriate escalation matrix and procedures (with contact details for
concerned parties) that guarantees performing corrective measures in case needed and in
actions within a guaranteed manner.
“Operation, Maintenance and Support” component:
 List all costs associated with the Operations Management component
4.6.4 Deliverables
 Service reports for all reported and resolved incidents signed by a representative from ISTD
 Proof of software subscription for the period of 36 months (If required)
 List of all fixes, patch and upgrades implemented during the support and maintenance
period
 Fixed and resolved outcomes of heath check (if required).
40
4.7 Component 6 – Project Management

Income and Sales Tax Department is following the PMI standards for managing projects and as per the
PMI best practices.
In order to provide project management services, the winning bidder is required to perform the
project management processes in addition to the activities mentioned below, noting that any other
related activities and processes needed for the proper functioning of the project implementation
should be provided by the winning bidder and its cost should be included in the fixed lump sum price
submitted by the bidder:
 Appoint a designated Project Manager (full-time for the contract duration) to oversee the
project execution together with project teams to execute all designated tasks and activities
 Develop a Project Plan, including project objectives and success criteria, deliverables,
role/responsibilities, communication protocols, document control methodology, cost
management, schedule management, quality management plan and any needed project
plan.
 Develop and maintain the overall project schedule, and review and verify the integration of
the project team’s activities & deliverables
 Develop project implementation strategy based on the needs and priorities of the business
owner that will ensure stakeholders buy-in and creates the needed impact at the different
stages of the project
 Develop a project plan that will determine and ensure the attainment of all project
objectives through the proper prioritization and dependency consideration of different
project activities.
 Work with ISTD and its stakeholders to come up with solid rational for phased approach of
the project implementation plan
 The winning bidder should implement a pilot according to working environment on one of
the sectors (such as the medical sector) and determine the duration of subsequent
application. The pilot then will be evaluated by both parties for any required modifications.
The pilot is expected to be implemented within 12 months of the start of the project.
 Ensure close cooperation with ISTD Project team as well as the service provider and
dependencies representatives
 Schedule and conduct on-site bi-weekly progress meetings involving the project team.
Meeting Minutes will be recorded and distributed, including an outstanding action Item Log,
detailing the status of key decisions, responsibility and required timing.
 Conduct Weekly progress meetings with ISTD team.
 Conduct periodic progress (steering committee) meetings with ISTD and all stakeholders’
representatives at least once a month. Provide and maintain a full and comprehensive plan
that covers all project management knowledge areas (i.e., time, scope, quality, HR,
communication, risk, etc.)
 Develop project organization structure to underline all possible resources needed from
engaged parties including their roles and responsibilities as well as their involvement at
different stages of the Project
 Establish and execute a process of Quality Assurance (planning, assurance and control) for
all components included in the scope of work
 Establish and execute a process for reporting project progress including deadlines; delays,
issues and critical paths to ensuring deliverables are met within resource constraints
 Establish and execute a process for project risks and issues management and mitigation
41
 Implement submission, key performance indicators and acceptance procedures for
approving project deliverables
 Close the project and document lessons learnt.

Project Management:
 The project’s implementation methodology and approach. And the description of the
different phases of the project
 Describe ideas how the overall project coordination should be tackled in order to assure
proper time and effective use of resources and information
 Describe proposed implementation strategy that will ensure project success.
 Provide Project management organization structure describing roles and responsibilities
 Describe approach to Quality Assurance for all components of the scope and relevant
qualifications in this field
 Describe approach for communication on the project
 Describe approach to report on project progress
 Describe approach to risks and issues management and mitigation
 Provide a list of deliverables for the Project Management.
 Describe methodology for the overall Project Management and bidder’s professional
qualifications (like PM certificates) in project management field
 The bidders must explicitly state their commitment and acceptance to adopt and utilize the
ISTD project management tool as the sole tool for management and collaboration regarding
project activities.
A detailed operational action plan should be provided, including the activities, procedures & time of
work implementation, and identification of those responsible for supervision and implementation, in
order to identify the required systems & equipment's during the implementation process. The
communication protocols, security and protection systems, in addition to identifying the required
training programs and the required operational manuals.

Project Management:
 List all costs associated with the Project Management.
4.7.4 Deliverables
related deliverables needed for the proper functioning of the project implementation should be
provided by the winning bidder and its cost should be included in the fixed lump sum price submitted
by the bidder:
 Project kick-off presentation (in English or Arabic)

 A project milestone schedule during the project preparation phase
42
 Project management documentation that will cover the different knowledge areas, listed
below but not limited to:
1. Project Charter
2. Project management plan
3. Stakeholder management plan including project organization structure and roles
and responsibilities
4. Communications management plan
5. Quality management plan ( as Described in Quality Management Component)
6. Risk management plan
7. Scheduled project status and progress reports, addressing Reasons behind any
deviation from Project baseline plan.
8. Deliverables traceability matrix.
 Issues and risk logs
 Action log
 Weekly and monthly status and progress reports
 Project closing presentation (in English or Arabic)
 Project conclusion document outlining work completed, lessons learned and
recommendations for “next steps”.
4.8 Component 7 – Quality Management

In order to provide Quality Management, the winning bidder is required to perform the activities
mentioned below, noting that any additional related activities needed for the proper functioning of
The System shall be provided by the winning bidder and its cost should be included in the fixed lump
sum price submitted by the bidder:
 Perform agile testing as it will be an integral part of the software development, where the
whole development team will be conducting the testing on the developed features and
functionalities and check behaviour of the outcomes according to the expectations and
requirements of ISTD team:
o Conduct sprint units testing for eservices and integrations points.
o Conduct sprint test.
 Assign a dedicated Quality team to ensure quality of project deliverables or software
through the related set of (Verification and Validation) activities.
 Prepare a detailed Quality plan scope that should include all project phases, deliverables,
and artifacts of any type relevant to the project nature like Portals, websites, e-Services
software, documentation, etc.
 Provide all Quality deliverables which ensure that all related activities are done successfully.
This includes but not limited to Test Plans, Test Case Scenarios including acceptance test
scenarios, Testing results/reports, Testing Summary report, Defect (Bug) report and other
required/proposed artifacts.
 Ensure proper deployment from staging environment to the ultimate Production
environment after getting the approval from ISTD.
 Perform all needed activities in the User Acceptance Testing that should be done in
cooperation with ISTD, all bugs and defects should be solved in order to get the approval on
e-Services launching before each phase.
43
Quality Management and validation and demonstrate the approach and components through which
the quality plan shall be implemented. The proposal should provide adequate explanation regarding
the proposed Quality management plan, including but not limited to:
 Describe methodology for the overall Quality Management and bidder’s professional
qualifications (like Quality certificates/accreditation) in quality management.
 Assurance and Conformance of project deliverables and work products to established
contractual agreements, processes, plans, policies, standards and procedures and e-
Government requirements.
 Identify and describe the process for reviewing the test plans, test cases, and test results,
identify the defect tracking processes, test environments, test roles and responsibilities, and
test phase entrance/exit criteria.
 Identify and describe the process for determining whether deliverables are ready to deploy
to the ultimate Production environment and production readiness criteria.
 Describe the project's quality practices, including but not limited to:
 The set of reviews and checkpoints for the project, including entry and/or exit criteria; hold
those reviews, and measure against entry/exit criteria.
 The standards and KPI’s to be used to measure project deliverable quality.
 The Quality metrics to be used to measure project deliverable quality.
 Identify and describe the testing tools should be used by the bidder to perform all required
testing types to measure of project deliverables quality and final products.
 Provide a list of deliverables for the Quality Management, as mentioned in the deliverable
section below, and as per the bidder proposed approach.

The bidder is required to provide the following information in the financial proposal in relation to
Quality Planning and Management in the financial proposal:
 List all costs associated with Quality Management activities.
4.8.4 Deliverables
related deliverables needed for the proper functioning of The System shall be provided by the winning
bidder and its cost should be included in the fixed lump sum price submitted by the bidder. Quality
management documentation that will cover the different knowledge areas, including but not limited
to:
 Quality Management plan (Quality and Test Plan documents)

 Quality Roles and responsibilities
 Test Case Scenarios / Test Data documents
 Test Results document and quality reports
 User and System Acceptance Criteria documents
 Quality metrics and Key Performance Indicators document
 Performed UAT sessions and approved UAT report.
44
4.9 Component 8: Implementation Timeline
The bid shall include the implementation timeline with significant milestones clearly defined in terms
of deliverables and success criteria for that milestone.
MoDEE is seeking an approach that develops a scalable product ready to deploy with a first release
for one taxpayer group in the first 6 months, followed by a phased roll-out approach across different
user groups, channels, or functions.
Months 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
Activities
Requirements Gathering
Implementation of Release1 1
Rollout and Next Phases 2
Maintenance & Support
1 Milestone 1: First phase release

2 Milestone 1: Mass rollout of the system
Figure 1: Timeline for project implementation and maintenance in the first 18 months
45
5 SUBMISSION PROCEDURES AND REQUIREMENTS
5.1 Bidder Qualifications
Bidders responding to this RFP should demonstrate up-to-date capabilities and experience in
providing similar services and similar engagements of the same scope, size and nature especially in
the public sector. These services and engagements must be accomplished successfully by the bidder
during the last 5 years. The bidder must have the following qualification:
1. Bidder is:
 A local company alone or having joint venture with local or international
company.
OR
 An International company having joint venture with local company.
Note: All partners to a joint venture will be jointly and severally responsible towards ISTD.
2. Bidders should be a Partner for the proposed solution Technology vendor, valid
partnership certificate must be attached to the technical proposal.
3. Bidders MUST demonstrate experience of e-Invoicing systems design and implementation

showing previous implementation of projects of same size and nature (One accomplished
successfully reference during the previous 5 years, accomplishment letter is required).
Not providing one accomplished successfully reference during the previous 5 years WILL
lead to dis-Qualification
4. Bidders should demonstrate the following specific capabilities:

 IT experience in cloud infrastructure, software and other IT related areas specified
in section 4.
 Experience in system security
 Experience in knowledge transfer and training
 Experience in operations support and maintenance
 Experience in web services development and standards
 General knowledge in Jordanian governmental laws and by-laws
Where some skills are not available, the bidder should sub-contract with a reputable firm to cover for
this specific skill(s), service(s) or equipment(s). The subcontractor must be approved by ISTD and the
contractor will be liable for all works performed by the sub-contractor.
5.2 Response Procedures
All inquiries with respect to this RFP are to be addressed to MoDEE Tendering Department in writing
by mail, e-mail or fax with the subject “NATIONAL E-INVOICING SOLUTION". Inquiries can only be
addressed to [[email protected]] or by Fax by [16/8/2020]. Responses will be sent in
46
writing no later than [19/8/2020]. Questions and answers will be shared with all Bidders’ primary
contacts.
5.3 Response Format
Bidders’ written response to the RFP must include both a technical and financial proposal. An overview
is provided in this section, with further details are provided in Annex 7.3.
5.3.1 Part I: Technical Proposal

Section Criteria Description
Corporate Corporate technical capabilities and experience in

technical implementing e-invoicing solution design and
capabilities implementation with detailed description and reference to
each of the following criteria (One accomplished successfully
reference during the previous 5 years):
 E-Invoicing design and implementation
 Systems Integration
 KPIs, Reports and Dashboards
 Big Data / Analytics Tools and Techniques
 Solution Security
Provide a current client list, highlighting potential conflicts of
interest, if any.
Proposed Team The project team should be composed of the following roles,
at a minimum, not including any additional specialized roles
per project requirements:
Corporate  Project Manager – PMP certified (or equivalent)
Capabilities  System Engineers – two resources with minimum 3
years of experience
 Technical Consultant – one resource with minimum
five years of experience in e-Invoicing
 E-Invoicing/Taxation Specialists two resources with
minimum 5 years’ experience
 Certified CPA/JCPA Accountant with minimum five
years’ experience
 Change management specialist – one resource with
five years’ experience
 DB Administrator - one resource with minimum five
years of experience
 System/Business Analyst – one resource with
minimum three years’ experience
 Quality Engineers – one resource with minimum five
years’ experience
Each resume will be subjected to the approval of ISTD, in case
of replacements the winning bidder must abide by the ISTD
47
requirements for replacements and approvals. In the
implementation phase; ISTD reserves the right to request
replacement of any resource that cannot fulfil the job.
Project Description and references to similar projects performed.
References
Sample Reference to appropriate work samples.
Deliverables
Project The roles and relationships of all project team members.
Organization
Structure
Proposed Work A high-level plan indicating activities and milestones for
Plan successful project delivery.
Resource Resource allocation throughout each phase of the project
Allocation with their percentage of involvement.
Technical Description of the approach to address the technical proposal
Proposal requirements for each of the project components
Requirements for  Component 1 - System Design, Installation and
each Component Configuration
 Component 2 - Required Solution Infrastructure
 Component 3 - Solution Security
 Component 4 - Training and Knowledge Transfer
 Component 5 - Operation Support, Maintenance
Project Delivery and Support
 Component 6 - Project Management
 Component 8 - Quality Management
Deliverables for Describing the approach to developing the deliverables, as
each Component well as the scope and structure for each. Provide appropriate
work samples as it pertains to the deliverables criteria for
each of the project components, as applicable.
Detailed timeline Describe the activities, duration, and milestones to execute
for each each component and develop the corresponding
Component deliverables.
Proposed Demonstrate compliance by submitting a populated
Solution Requirements Compliance Matrix, including descriptions for
Compliance with how the proposed solution will address functional
National E- Functional requirements.
Invoicing Requirements
Solution
Requirements Proposed Demonstrate compliance by submitted a populated
Solution Requirements Compliance Matrix, including descriptions for
Compliance with how the proposed solution will address non functional
Non Functional requirements.
Requirements
48
5.3.2 Part II: Financial Proposal
The bidder is asked to provide two financial proposals:
1. A turn-key proposal with traditional phased implementation pricing

2. A proposal to finance the implementation with income from transaction fees.
5.3.2.1 Turn-key Pricing

The turn-key financial proposal should include a cost summary and a detailed cost analysis section.
The cost summary must provide a fixed lump sum price in Jordan Dinars for the overall scope of work
and deliverables including all fees, taxes. The supporting detailed cost analysis should provide a
breakdown and details of the pricing should be provided. The day rates and expenses for any
consultants should be included separately along with the time for which they will be required. The
bidder will provide separately all professional fees and expenses (travel, project equipment,
accommodation and subsistence, etc) for the duration of the project. The pricing should show the
proposed linkage between deliverables and payments.
5.3.2.2 Transaction Financed Pricing

The Transaction Financed Pricing (TFP) proposal should include a pricing model and calculation for
financing the implementation cost with income from transactions spread over a 7 year period.
The total projected income from transactions should be capped to a maximum total fee that is no
more than twice the implementation price for the 7 year duration as calculated based on the Turn-
key Pricing bid. This number assumes a Present Value of return at year 7 and 10% cost of capital. Cost
of platform infrastructure operation may be added to this value.
The transactions that will be subject to pricing may include items such as taxpayer registration and
invoice creation/registration. The bidder is invited to propose an appropriate pricing model along with
required assumptions and boundary conditions.
Please assume the following:
 Consistent with requirement R07.05 and R07.06, the solution should provide a free service
variant for the smallest businesses,
 5% market coverage resulting from phase I deployment, full market coverage possible after
18 months,
 Use market size assumptions based on volume data given in section 2.3,
 All implementation costs performed under the Transaction Financed Pricing bid shall include
the activities performed under the Classic Pricing bid, rendering the TFP bid no worse in terms
of technical scope.
 In addition to implementation, the full operation, SLA, and maintenance costs of the solution
for 7 years should be covered by the transactional pricing model.
5.3.2.3 Additional Instructions for Financial Proposal

Financial proposal should include:
 The Form of Bid (‫ )عرض المناقصة‬duly filled; signed and stamped by the bidder
49
 The summary of remuneration )‫ (خالصة بدالت األتعاب‬attached in the Arabic Sample
Agreement under )3 ‫ و رقم‬2 ‫ )ملحق االتفاقية رقم‬duly filled; signed and stamped by the
bidder.
The Financial proposal should be submitted in separation of the technical proposal. In order for the
evaluation to progress quickly and effectively, bidders are requested to provide their proposal as per
the format described in (Annex 7.4).
- ‫) اال اذا كانت الشركة خاضعة للضريبة‬% 16 (‫على الفريق الثاني ان يشمل سعره الضريبة العامة على المبيعات بنسبة‬
‫ (بموجب كتاب رسمي من هيئة االستثمار يرفق مع العرض المالي) ويتم عكس هذه‬%)0( ‫العامة على المبيعات بنسبة‬
. ‫النسبة على السعر المقدم من قبلها‬
- ‫في حال عدم توضيح الضريبة العامة عل المبيعات على السعر المقدم من قبل الشركة يعتبر سعر الشركة شامل للضريبة‬
% 16 ‫العامة على المبيعات بنسبة‬.
5.3.3 Part III: Bid Security

This part includes the original Bid Security, as described in below section 5.6.2: Tender bond.
5.4 Response Submission
Bidders must submit proposals to this RFP to the MoDEE no later than 12:00 PM on [2/9/2020] (Jordan
Local Time).
Tendering Department – 3rd floor
Ministry of Digital Economy and Entrepreneurship
8th Circle
P.O. Box 9903
Amman 11191 Jordan
Tender No. 1F2019
Tel: 00 962 6 58055642 Fax: 00 962 6 5861059
E-mail: [email protected]
Proposals should be submitted as 3 separate parts each part in a separate well-sealed and wrapped
envelope clearly marked, respectively, as follows:
50
 Part I “NATIONAL E-INVOICING SOLUTION - Technical and Corporate
Capabilities Proposal”. This part (envelop) should contain 3 hard copies (1
original and 2 copies) and 1 softcopy (CD) [in Microsoft Office 2010 or Office
2010 compatible formats]. This part should not contain any reference to
cost or price. Inclusion of any cost or price information in the technical
proposal will result in the bidder’s proposal being disqualified as
irresponsive.
 Part II “NATIONAL E-INVOICING SOLUTION –– Financial Proposal for Both
Options”. This part (envelop) should contain 3 hard copies (1 original and 2
copy) and 1 softcopy (CD) [in Microsoft Office 2010 or Office 2010
compatible formats].
 Part III “NATIONAL E-INVOICING SOLUTION– Bid Security" This part
(envelope) should contain 1 hard copy. This part should not contain any
reference to cost or price. Inclusion of any cost or price information in the
technical proposal will result in the bidder’s proposal being disqualified as
irresponsive.
Note: Each CD should be enclosed in the relevant envelop. Late submissions will not be accepted nor
considered and in case of discrepancy between the original hard copy and other hard copies and/or
the soft copy of the proposal, the hard copy marked as original will prevail and will be considered the
official copy. Proposals may be withdrawn or modified and resubmitted in writing any time before the
submission date.
Regardless of method of delivery, the proposals must be received by the MoDEE no later than 12:00
PM on [2/9/2020] (Jordan Local Time).MoDEE will not be responsible for premature opening of
proposals not clearly labeled.
5.5 Response Evaluation
All responses to the RFP will be evaluated technically and financially and the winning proposal will be
selected on the basis of “best value” in terms of technical superiority as well as cost effectiveness.
Technical and financial proposals shall be reviewed by the Special Tendering Committee and evaluated
in accordance with the following criteria:
 Overall Technical Proposal 70%

 Overall Financial Proposal 30%
 The overall bidder’s mark will be calculated as follows:
(30%* least value of financial proposal)/bidder financial proposal value + (%70*bidder technical
mark)
MoDEE reserves the right not to select any offer. MoDEE also assumes no responsibility for costs of
bidders in preparing their submissions.
51
5.5.1 Technical proposal
The technical proposal shall be first evaluated according to the following criteria:
Evaluation Criteria Description Scoring
Past Experience Demonstrating experience and a proven track record 20

with similar projects and solutions. Bidders should
demonstrate their experience in:
o E-Invoicing design and
implementation
o Systems’ integration
o KPIs, Reports and
Dashboards
o Big Data Tools and
Techniques
o Solution Security
Staff Qualifications The Bidder must propose separate and dedicated CVs 10
and Experience for each role and highlight their relevant experience to
the scope of this RFP (Please refer to section 5.3.1 Part
I:Technical Proposal)
Correspondence to Per section 4 of this RFP, the Bidder must provide their 70
Technical Proposal approach and details to address the technical proposal
Requirements requirements within each of the following sections:
 4.2 - System Design, Installation and
Configuration
 4.3 - Required Solution Infrastructure
 4.4 - Solution Security
 4.5 - Training and Knowledge Transfer
 4.6 - Operation Support, Maintenance and
Support
 4.7 - Project Management
 4.8 - Quality Management
The bidder should provide examples of appropriate
work samples as it pertains to the deliverables in each
of the above-mentioned sections.
The bidder must also provide a timeline with significant
milestones clearly defined which adheres to the scope
identified in section 4.9 – Component 8:
Implementation Timeline.
Compliance to A completed Requirements Compliance Matrix Score included
Functional distributed as a separate Excel file attachment to this in Component
Requirements RFP, including descriptions for how the solution will 4.2
meet functional requirements.
Compliance to Non- A completed Requirements Compliance Matrix Score included
Functional distributed as a separate Excel file attachment to this in Component
Requirements RFP, including descriptions for how the solution will 4.2 and 4.6
meet non-functional requirements.
52
Overall Technical Proposal 100
5.5.2 Financial proposal

Only those bidders that qualify in the technical proposal will have their financial offers reviewed. The
Financial proposal will be evaluated only for companies who qualify, based on a minimum acceptable
score that will be defined by the special tenders committee. The financial offer of those who do not
qualify will not be opened and will be returned.
See section 5.3.2 Part II: Financial Proposal for a description of financial details. In addition, the bidder
must be able to provide a breakdown of fees and costs in accordance with all financial proposal
requirements outlined in section 4 of this RFP according to the structure per Annex 7.6.2.
5.6 Financial Terms
Bidders should take into consideration the following general financial terms when preparing and
submitting their proposals.
5.6.1 Pricing terms

 All prices should be quoted in Jordanian Dinars inclusive of all expenses,
governmental fees and taxes
 The type of contract will be a fixed lump sum price contract including costs
of all expenses incurred
 A clear breakdown (table format) of the price should be provided including
price for consulting time, other expenses, etc.
 The bidder shall bear all costs associated with the preparation and
submission of its proposal and MoDEE will in no case be responsible or liable
for these costs, regardless of the conduct or outcome of the proposal
process.
 The bidders shall furnish detailed information listing all commissions and
gratuities, if any, paid or to be paid to agents relating to this proposal and to
contract execution if the bidder is awarded the contract. The information to
be provided shall list the name and address of any agents, the amount and
currency paid and the purpose of the commission or gratuity.
5.6.2 Tender bond

The Bidder shall submit a (Tender Bond) proposal security on a form similar to the attached format in
Jordanian Dinars for a flat sum of (175000 J.D) Jordanian Dinars (in a separate sealed envelope.
The tender bond must adhere to the following terms:
 The bond will be in the form of a bank guarantee from a reputable registered bank,
located in Jordan, selected by the bidder.
53
 The bidder shall ensure that the (tender bond) proposal security shall remain valid for a
period of 90 days after the bid closing date or 30 days beyond any extension
subsequently requested by the tendering committee and agreed to by the bidder.
 Any proposal not accompanied by an acceptable proposal security (tender
bond) shall be rejected by the tendering committee as being non-responsive
pursuant to RFP.
 The proposal security of a joint venture can be in the name of all members
participating in the joint venture submitting the proposal or in the name of
one or more members in the joint-venture.
 The proposal security of the unsuccessful bidders will be returned not later
than 30 days after the expiration of the proposal validity period.
 The winning bidder is required to submit a performance bond of 10% of the
total value of the contract within 14 days as of the date of award notification
letter.
 The proposal security of the winning bidder will be returned when the
bidder has signed the contract and has furnished the required performance
security.
 The proposal security may, in the sole discretion of the tendering
committee, be forfeited:
 If the bidder withdraws its proposal during the
period of proposal validity as set out in the RFP; or
 In the case of winning bidder, if the bidder fails
within the specified time limit to sign the contract;
or sign the joint venture agreement in front of a
notary public in Amman, Jordan; or furnish the
required performance security as set out in the
contract.
5.6.3 Other commercial terms

 The winning bidder must pay the fees of the RFP advertisement issued in the
newspapers.
 MoDEE is not bound to accept the lowest bid and will reserve the right to
reject any bids without the obligation to give any explanation.
 Bidders must take into consideration that payments will be as specified in
the tender documents and will be distributed upon the winning submission
and acceptance of the scope of work and of the deliverables and milestones
of the scope of work defined for the project by the first party.
 MoDEE takes no responsibility for the costs of preparing any bids and will
not reimburse any Bidder for the cost of preparing its bid whether winning
or otherwise.
5.7 Key RFPs Dates & Deadlines
ITEM DATE
(DD/MM/YY)
Date of RFP distribution 19-26/9/2019
Deadline for submission of bidders’ questions to RFP 2/10/2019
54
Expected date for answers to bidders’ questions 9/10/2019
Proposal deadline 30/10/2019
55
6 GENERAL TERMS
6.1 Escalation Procedure and Penalties:
For incidents classified as Severity Level 1, 2, 3 & 4, if bidder:
1. Passed the Response Time: first level of escalation will be applied by notifying winning
bidder’s Technical Support Manager or the assigned contact person.
2. Passed the Resolution Time: ISTD is entitled to fix the problem and to apply penalty on
the winning bidder in accordance with the following criteria in the below table and all
costs incurred by ISTD for fixing will be charged to the winning bidder.
Table 2: Penalties
Severity Definition Penalty
1 Must be done, essential to A penalty of 80 J.D. shall be applied

business survival. Business can’t for each hour pass the resolution
continue time. This penalty shall continue
for the first 24 hours ( 80 x24). If
delay continues, then the penalty
of 1920 J.D. per day shall be
applied and for the maximum
duration of 3 days; after that, 3rd
party will be called to fix the
problem.
2 Should be done, near essential to A penalty of 1920 J.D. shall be

business survival. applied for each day pass the
resolution time. This penalty will
be applied for the maximum
problem.
3 Could be done, high benefit to A penalty of 1500 J.D. shall be

business if time and resources are applied for each day pass the
available. resolution time. This penalty will
problem.
4 Important problem but can wait A penalty of 1000 J.D. shall be

applied for each day pass the
resolution time. This penalty will
problem.
56
6.2 Preventive Maintenance (PM)
The winning bidder is required to provide the following visits for the purpose of PM on the hardware
equipment and software from the date of the preliminary acceptance by ISTD.
- Site visits to NITC one time for each month for the first six months and one time for each
quarter for the remaining maintenance period.
- Certified engineer with transportation who must present during all PM visits.
- Checking all the items that are included in the checklist that will be provided by ISTD.
- A PM form that must be signed by the winning bidder team and NITC representative.
- Compliance with the PM schedule that will be provided by NITC.
- Solution to all problems found during PM visits.
6.3 Penalties for defaulting on PM
A penalty of 500 JD per visit per location will be charged for not accomplishing the PM aforementioned
responsibilities.
6.4 Legal terms
Bidders should take into consideration the following general legal terms when preparing and
submitting their proposals.
6.4.1 Joint-ventures
 If the Bidder decides to form a joint venture, the joint venture members
should duly sign the joint venture agreement attached to this RFP under
(Annex 7.6) by authorized representatives of the joint venture partners
without being certified by a notary public and to be enclosed in the technical
proposal in addition to authorization for signature on behalf of each
member. Only the winning bidder partners in a joint venture should duly
sign the joint venture agreement attached to this RFP under (Annex 7.6) by
authorized signatories and this agreement is to be certified by a Notary
Public in Jordan within (10) calendar days as of the date of award
notification and before signing the Contract; otherwise MoDEE is entitled to
forfeit the bid bond whether it is in the name of all partners to the joint
venture or in the name of any of the joint venture partners. Each partner in
the joint venture shall be a business organization duly organized, existing
and registered and in good standing under the laws of its country of
domicile. The Bidder must furnish evidence of its structure as a joint venture
including, without limitation, information with respect to:
A. the legal relationship among the joint venture members that shall include
joint and several liability to execute the contract; and
B. the role and responsibility of each joint venture member
57
 The Bidder must nominate a managing member (leader) for any joint
venture which managing member will be authorized to act and receive
instructions on behalf of all the joint venture members.
 All bidders should duly sign the joint venture agreement attached to this RFP
under (Annex 7.6) by authorized representatives of the joint venture
partners without being certified by a notary public and to be enclosed in the
technical proposal in addition to authorization for signature on behalf of
each member. Only the winning bidder partners in a joint venture should
duly sign the joint venture agreement attached to this RFP under
(Annex 7.6) by authorized signatories and this agreement is to be certified
by a Notary Public in Jordan.
 If the bidder is a joint venture, then the partners need to be identified with
the rationale behind the partnership. Corporate capability statement should
also be provided for all partners
6.4.2 Proposal Authorization

 The bidders shall not submit alternative proposal. Alternative proposals will
be returned unopened or unread. If the bidder submits more than one
proposal and it is not obvious, on the sealed envelope(s), which is the
alternative proposal, in lieu of returning the alternative proposal, the entire
submission will be returned to the bidder and the bidder will be disqualified.
 The proposal shall be signed by the bidder or a person or persons duly

authorized to bind the bidder to the contract. The latter authorization shall
be indicated by duly-legalized power of attorney. All the pages of the
proposal, except un-amended printed literature, shall be initialled by the
person or persons signing the proposal.
 Any interlineations, erasures or overwriting shall only be valid if they are

initialled by the signatory(ies) to the proposal.
 The bid shall contain an acknowledgement of receipt of all Addenda to the

RFP, the numbers of which must be filled in on the Form of Bid attached to
the Arabic Sample Agreement
6.4.3 Corrupt and Fraudulent Practices

 MoDEE requires that all parties to the contracting process observe the highest standard of
ethics during the procurement and execution process. The Special Tenders Committee will
reject a proposal for award if it determines that the Bidder has engaged in corrupt or
fraudulent practices in competing for the contract in question.
Corrupt Practice means the offering, giving, receiving or soliciting of anything of value to
influence the action of a public official in the procurement process or in contract execution.
Fraudulent Practice means a misrepresentation of facts in order to influence a procurement
process or the execution of a contract to the detriment of MoDEE, and includes collusive
practice among Bidders (prior to or after proposal submission) designed to establish proposal
58
prices at artificial non-competitive levels and to deprive MoDEE of the benefits of free and
open competition.
 No bidder shall contact MoDEE, its employees or the Special Tenders

Committee or the technical committee members on any matter relating to
its proposal to the time the contract is awarded. Any effort by a bidder to
influence MoDEE, its employees, the Special Tenders Committee or the
technical committee members in the tendering committee’s proposal
evaluation, proposal comparison, or contract award decision will result in
rejection of the bidder’s proposal and forfeiture of the proposal security
 The remuneration of the Winning Bidder stated in the Decision of Award of

the bid shall constitute the Winning Bidder sole remuneration in connection
with this Project and/or the Services, and the Winning Bidder shall not
accept for their own benefit any trade commission, discount, or similar
payment in connection with activities pursuant to this Contract or to the
Services or in the discharge of their obligations under the Contract, and the
Winning Bidder shall use their best efforts to ensure that the Personnel, any
Sub-contractors, and agents of either of them similarly shall not receive any
such additional remuneration.
 A business registration certificate should be provided with the proposal
 The laws and regulations of The Hashemite Kingdom of Jordan shall apply to
awarded contracts.
6.4.4 Sample Arabic Contract Agreement Approval:

 Bidders must review the Sample Arabic Contract Agreement version
provided with the RFP, which shall be binding and shall be signed with
winning bidder.
 Bidders must fill out, stamp and duly sign the Form of Bid ‫(نموذج عرض‬
)‫ المناقصة‬attached to the Arabic Sample Agreement under )2( ‫ ملحق رقم‬and
enclose it in their financial proposals.
 Bidders must fill out the summary payment schedule form sub annex 3
)3 ‫ (الملحق رقم‬which is part of the Arabic Sample Contract version provided
with the RFP, sign and stamp it, and enclose it with the Financial Proposal.
6.4.5 Other Legal Terms
 MoDEE takes no responsibility for the costs of preparing any bids and will
not reimburse any bidder for the cost of preparing its bid whether winning
or otherwise.
 If the winning bidder is an international company, it must provide a local

representative or a local partner in Jordan.
59
 Bidders must review the Sample Arabic Contract Agreement provided with
this RFP and that will be the Contract to be signed with the winning bidder.
Provisions in this Sample Arabic Contract Agreement are not subject to any
changes; except as may be amended by MoDEE before tender submission;
such amendments are to be issued as an addendum.
 Proposals shall remain valid for period of (90) days from the closing date for
the receipt of proposals as established by the Special Tenders Committee.
 The Special Tenders Committee may solicit the bidders’ consent to an

extension of the proposal validity period. The request and responses thereto
shall be made in writing or by fax. If a bidder agrees to prolong the period of
validity, the proposal security shall also be suitably extended. A bidder may
refuse the request without forfeiting its proposal security; however, in its
discretion, the Special Tenders Committee may cease further review and
consideration of such bidder’s proposal. A bidder granting the request will
not be required nor permitted to modify its proposal, except as provided in
this RFP.
 MoDEE reserves the right to accept, annul or cancel the bidding process and
reject all proposals at any time without any liability to the bidders or any
other party and/withdraw this tender without providing reasons for such
action and with no legal or financial implications to MoDEE.
 MoDEE reserves the right to disregard any bid which is not submitted in
writing by the closing date of the tender. An electronic version of the
technical proposal will only be accepted if a written version has also been
submitted by the closing date.
 MoDEE reserves the right to disregard any bid which does not contain the
required number of proposal copies as specified in this RFP. In case of
discrepancies between the original hardcopy, the other copies and/or the
softcopy of the proposals, the original hardcopy will prevail and will be
considered the official copy.
 MoDEE reserves the right to enforce penalties on the winning bidder in case
of any delay in delivery defined in accordance with the terms set in the
sample Arabic contract. The value of such penalties will be determined in
the Sample Arabic contract for each day of unjustifiable delay.
 Bidders may not object to the technical or financial evaluation criteria set
forth for this tender.
 The winning bidder will be expected to provide a single point of contact to

which all issues can be escalated. ISTD will provide a similar point of contact.
 ISTD is entitled to meet (in person or via telephone) each member of the
consulting team prior to any work, taking place. Where project staff is not
felt to be suitable, either before starting or during the execution of the
60
contract, ISTD reserves the right to request an alternative staff at no extra
cost to ISTD.
 Each bidder will be responsible for providing his own equipment, office
space, secretarial and other resources, insurance, medical provisions, visas
and travel arrangements. ISTD will take no responsibility for any non-
Government of Jordan resources either within Jordan or during travel
to/from Jordan.
 Any documentation and software procured or developed under ‘National E-

Invoicing System’ are the property of ISTD upon conclusion of ‘National E-
Invoicing System’. Written consent of ISTD must be obtained before sharing
any part of this information as reference or otherwise.
 Bidders are responsible for the accuracy of information submitted in their

proposals. MoDEE reserves the right to request original copies of any
documents submitted for review and authentication prior to awarding the
tender.
 The bidder may modify or withdraw its proposal after submission, provided
that written notice of the modification or withdrawal is received by the
tendering committee prior to the deadline prescribed for proposal
submission. Withdrawal of a proposal after the deadline prescribed for
proposal submission or during proposal validity as set in the tender
documents will result in the bidder’s forfeiture of all of its proposal security
(bid bond).
 A bidder wishing to withdraw its proposal shall notify the Special Tenders
Committee in writing prior to the deadline prescribed for proposal
submission. A withdrawal notice may also sent by fax, but it must be
followed by a signed confirmation copy, postmarked no later than the
deadline for submission of proposals.
 The notice of withdrawal shall be addressed to the Special Tenders

Committee at the address in RFP, and bear the contract name “National E-
Invoicing System” and the words “Withdrawal Notice”.
 Proposal withdrawal notices received after the proposal submission

deadline will be ignored, and the submitted proposal will be deemed to be a
validly submitted proposal.
 No proposal may be withdrawn in the interval between the proposal

submission deadline and the expiration of the proposal validity period.
Withdrawal of a proposal during this interval may result in forfeiture of the
bidder’s proposal security.
 The Bidder accepts to comply with all provisions, whether explicitly stated in
this RFP or otherwise, stipulated in the Government Procurement By-Law
No. 28 of 2019 and its amendments and instructions, and any other
61
provisions stated in the Standard Contracting sample Arabic Contract
Agreement annexed to this RFP including general and special conditions.
 The winning bidder shall perform the Services and carry out their obligations
with all due diligence, efficiency, and economy, in accordance with the
highest generally accepted professional techniques and practices, and shall
observe sound management practices, and employ appropriate advanced
technology and safe methods. The Winning Bidder shall always act, in
respect of any matter relating to this Contract or to the Services, as faithful
advisers to ISTD, and shall at all times support and safeguard ISTD‘s
legitimate interests in any dealings with Sub-contractors or third parties.
 If there is any inconsistency between the provisions set forth in the Sample
Arabic Contract Agreement attached hereto or this RFP and the proposal of
Bidder; the Sample Arabic Contract Agreement and /or the RFP shall prevail
 ISTD reserves the right to furnish all materials presented by the winning
bidder at any stage of the project, such as reports, analyses or any other
materials, in whole or part, to any person. This shall include publishing such
materials in the press, for the purposes of informing, promotion,
advertisement and/or influencing any third party, including the investment
community. ISTD shall have a perpetual, irrevocable, non-transferable, paid-
up right and license to use and copy such materials mentioned above and
prepare derivative works based on them.
 Bidders (whether in joint venture or alone) are not allowed to submit more
than one proposal for this RFP. If a partner in a joint venture participate in
more than one proposal; such proposals shall not be considered and will be
rejected for being none-responsive to this RFP.
 Amendments or reservations on any of the Tender Documents: Bidders are

not allowed to amend or make any reservations on any of the Tender
Documents or the Arabic Sample contract agreement attached hereto. In
case any bidder does not abide by this statement, his proposal will be
rejected for being none-responsive to this RFP. If during the implementation
of this project; it is found that the winning bidder has included in his
proposal any amendments, reservations on any of the tender documents or
the Contract; then such amendments or reservations shall not be considered
and the items in the tender documents and the Contact shall prevail and
shall be executed without additional cost to ISTD and the winning bidder
shall not be entitled to claim for any additional expenses or take any other
legal procedures.
 Nothing contained herein shall be construed as establishing a relation of

principal and agent as between ISTD and the Winning Bidder. The Winning
Bidder has complete charge of Personnel and Sub-contractors, if any,
performing the Services and shall be fully responsible for the Services
performed by them or on their behalf hereunder.
62
 The Winning Bidder, their Sub-contractors, and the Personnel of either of
them shall not, either during the term or after the expiration of the
Contract, disclose any proprietary or confidential information relating to the
Project, the Services, the Contract, or The ISTD’s business or operations
without the prior written consent of The ISTD. The Winning Bidder shall sign
a Non-Disclosure Agreement with ISTD as per the standard form adopted by
the ISTD. A confidentiality undertaking is included in (Annex 7.5).
 PROHIBITION OF CONFLICTING ACTIVITIES
Neither the Winning Bidder nor their Sub-contractors nor their personnel shall engage, either directly
or indirectly, in any of the following activities:
o During the term of the Contract, any business or professional activities in

Jordan or abroad which would conflict with the activities assigned to them
under this bid; or
o After the termination of this Project, such other activities as may be
specified in the Contract.
 INTELLECTUAL PROPERTY RIGHTS PROVISIONS

o Intellectual Property for the purpose of this provision shall mean all
copyright and neighbouring rights, all rights in relation to inventions
(including patent rights), plant varieties, registered and unregistered
trademarks (including service marks), registered designs, Confidential
Information (including trade secrets and know how) and circuit layouts, and
all other rights resulting from intellectual activity in the industrial, scientific,
literary or artistic fields.
o Contract Material for the purpose of this provision shall mean all material
(includes documents, equipment, software, goods, information and data
stored by any means):
a) Brought into existence for the purpose of performing the Services;
b) incorporated in, supplied or required to be supplied along with the Material
referred to in paragraph (a); or
c) Copied or derived from Material referred to in paragraphs (a) or (b);
o Intellectual Property in all Contract Material vests or will vest in ISTD. This
shall not affect the ownership of Intellectual Property in any material owned
by the Winning Bidder, or a Sub-contractor, existing at the effective date of
the Contract. However, the Winning Bidder grants to ISTD, or shall procure
from a Sub-contractor, on behalf of ISTD, a permanent, irrevocable, royalty-
free, worldwide, non-exclusive license (including a right of sub-license) to
use, reproduce, adapt and exploit such material as specified in the Contract
and all relevant documents.
o If requested by ISTD to do so, the Winning Bidder shall bring into existence,
sign, execute or otherwise deal with any document that may be necessary or
desirable to give effect to these provisions.
o The Winning Bidder shall at all times indemnify and hold harmless ISTD, its
officers, employees and agents from and against any loss (including legal
costs and expenses on a solicitor/own client basis) or liability incurred from
any claim, suit, demand, action or proceeding by any person in respect of
63
any infringement of Intellectual Property by the Winning Bidder, its officers,
employees, agents or Sub-contractors in connection with the performance
of the Services or the use by ISTD of the Contract Material. This indemnity
shall survive the expiration or termination of the Contract.
o The Winning Bidder not to benefit from commissions discounts, etc. The
remuneration of the Winning Bidder stated in the Decision of Award of the
bid shall constitute the Winning Bidder sole remuneration in connection
with this Project and/or the Services, and the Winning Bidder shall not
accept for their own benefit any trade commission, discount, or similar
payment in connection with activities pursuant to this Contract or to the
Services or in the discharge of their obligations under the Contract, and the
Winning Bidder shall use their best efforts to ensure that the Personnel, any
Sub-contractors, and agents of either of them similarly shall not receive any
such additional remuneration.
 THIRD PARTY INDEMNITY

Unless specified to the contrary in the Contract, the Winning Bidder will indemnify ISTD, including its
officers, employees and agents against a loss or liability that has been reasonably incurred by ISTD as
the result of a claim made by a third party:
 Where that loss or liability was caused or contributed to by an unlawful, negligent or

wilfully wrong act or omission by the Winning Bidder, its Personnel, or sub-
contractors; or
 Where and to the extent that loss or liability relates to personal injury, death or
property damage.
 LIABILITY
o The liability of either party for breach of the Contract or for any other
statutory cause of action arising out of the operation of the Contract will be
determined under the relevant law in Hashemite Kingdom of Jordan as at
present in force. This liability will survive the termination or expiry of the
Contract. Winning bidder’s total liability relating to contract shall in no event
exceed the fees Winning bidder receives hereunder, such limitation shall not
apply in the following cases (in addition to the case of wilful breach of the
contract):
 gross negligence or wilful misconduct on the part of
the Consultants or on the part of any person or firm
acting on behalf of the Consultants in carrying out
the Services,
 an indemnity in respect of third party claims for
damage to third parties caused by the Consultants
or any person or firm acting on behalf of the
Consultants in carrying out the Services,
 infringement of Intellectual Property Rights
64
6.5 Conflict of Interest
 The Winning bidder warrants that to the best of its knowledge after making
diligent inquiry, at the date of signing the Contract no conflict of interest
exists or is likely to arise in the performance of its obligations under the
Contract by itself or by its employees and that based upon reasonable
inquiry it has no reason to believe that any sub-contractor has such a
conflict.
 If during the course of the Contract a conflict or risk of conflict of interest
arises, the Winning bidder undertakes to notify in writing ISTD immediately
that conflict or risk of conflict becomes known.
 The Winning bidder shall not, and shall use their best endeavours to ensure
that any employee, agent or sub-contractor shall not, during the course of
the Contract, engage in any activity or obtain any interest likely to conflict
with, or restrict the fair and independent performance of obligations under
the Contract and shall immediately disclose to ISTD such activity or interest.
 If the Winning bidder fails to notify ISTD or is unable or unwilling to resolve
or deal with the conflict as required, ISTD may terminate this Contract in
accordance with the provisions of termination set forth in the Contract.
6.6 Secrecy and Security
The Winning bidder shall comply and shall ensure that any sub-contractor complies, so far as
compliance is required, with the secrecy and security requirements of ISTD, or notified by ISTD to the
Winning bidder from time to time.
6.7 Documents Property
All plans, drawings, specifications, designs, reports, and other documents and software submitted by
the Winning bidder in accordance with the Contract shall become and remain the property of ISTD,
and the Winning bidder shall, not later than upon termination or expiration of the Contract, deliver all
such documents and software to ISTD, together with a detailed inventory thereof. Restrictions about
the future use of these documents, if any, shall be specified in the Special Conditions of the Contract.
6.8 Removal or/and Replacement of Personnel
 Except as ISTD may otherwise agree, no changes shall be made in the key
Personnel. If, for any reason beyond the reasonable control of the Winning
bidder, it becomes necessary to replace any of the key Personnel, the
Winning bidder shall provide as a replacement a person of equivalent or
better qualifications and upon ISTD approval.
 If ISTD finds that any of the Personnel have (i) committed serious
misconduct or have been charged with having committed a criminal action,
or (ii) have reasonable cause to be dissatisfied with the performance of any
of the Personnel, then the Winning bidder shall, at ISTD’ s written request
specifying the grounds thereof, provide as a replacement a person with
qualifications and experience acceptable to ISTD.
65
6.9 Other Project-related Terms
ISTD reserves the right to conduct a technical audit on the project either by ISTD resources or by third
party.
66
7 ANNEXES
7.1 Bylaw of organizing & controlling invoicing 34/ 2019 ( ‫نظام تنظيم شؤون‬
)2019 ‫ لسنة‬34 ‫الفوترة والرقابة عليها رقم‬
Bylaw No. (34) for the year 2019
Invoicing regulation and control system
Issued pursuant to paragraph (f) of Article (23) of the Income Tax Law No. 34 of 2014
Article 1:
This Regulation shall be cited “Invoicing Organization and Control Regulation of 2019” and come into
force after 60 days from the date of its publication in the Official Gazette.
Article 2:
A. The following terms and expressions shall have the meanings assigned there to unless
indicated otherwise:
Law: The effective Income Tax Law.
Minister: Minister of Finance.
Department: Income and Sales Tax Department.
Director: The Department’s Director-General.
Person: Natural or legal person.
Commodity : Each natural substance or animal, agricultural, or industrial product including electricity.
Service: Each paid or unpaid work done by the person including provision of a benefit to the others,
and such work does not include commodity provision unless such commodity is necessary to provide
such service.
Seller : Service seller or Item seller .
Invoice: A document issued by the seller whether the commodity seller or service provider to the
buyer or service recipient, indicating a description of the commodity/service, price, quantity, as well
as the general sales tax of taxpayers registered with general sales tax, that is issued under the terms
and conditions specified in this Regulation.
Commodity selling: is transference of the commodity’s ownership to the buyer whether for a return
or not, using the commodity by the taxpayer for their private purposes, enabling the others to do so
for a return or not, or any legal ownership transference disposition.
67
Service selling: is the provision of the service by the seller to the buyer for a return or not.
B. The definitions provided for in the Law wherever they appear in this Regulation shall be
used unless indicated otherwise.
Article 3:
A. The time and date on which the selling process takes place under Paragraphs (A, B) of this
Article shall be the time and date of occurrence of the commodity or service selling.
Article 4:
For the purposes of implementing the provisions of this system shall be adopted invoice in all forms,
whether paper, computer or electronic.
Article 5:
Each person selling a commodity or service for over one Dinar shall issue the invoice in duplicate
including the following information:
1. Invoice serial number.

2. Full name and address of the seller.
3. Tax identification number of the seller if registered with general sales tax and
the national identification number if not registered with general sales tax
4. Date of invoice issuance
5. Type, quantity, and value of the sold commodity or service, as well as total value
of the invoice.
In addition to the provisions of Paragraph (A) of this Article, the invoice shall clearly include the buyer
name in the case of deferred selling of the commodity/service or selling in instalment.
A copy of the invoice shall be delivered to the buyer in accordance with the method used by the seller
in organizing and issuing invoices, while the remaining copies shall be kept by the seller.
The seller shall confirm receipt of the invoice by the buyer If the value of it exceeds (10,000 JD).
The seller shall issue and regulate the invoice upon occurrence of the selling.
Article 6:
Each person required to organize and issue the invoice shall prepare a paper-based or computerized
log for commodity and/or service sales with the letterhead in the name of the seller with the following
contents:
A. Log page number

B. Buyer name
C. Invoice number
D. Total invoice value
Article 7:
The commercial markets or any other entity may organize a total invoice for each day, including all its
daily sales, with the prior approval of the Director at the request of these authorities. This shall be
regulated by instructions issued by the Minister for this purpose.
68
It is permissible for malls and shopping centers to organize a total invoice of their daily sales for the
purposes of this Regulation provided that pre-consent of the Director shall be obtained upon the
request of such entities. This shall be regulated by instructions issued by the Minister for this purpose.
Article 8:
Every person is obliged to organize and issue the invoice under the provisions of this Law:
A. Each person required to organize and issue the invoice under the provisions of this
Regulation shall keep them for four years as of the latest of the following dates:
1. Ending date of the tax period during which the invoice was organized and issued
2. Date of filing the tax return
3. Date of notification of an administrative assessment decision.
 In the case of any dispute over the invoice, amount of tax due, or
any penalties and related amounts, each person required to
organize and issue the invoice under the provisions of this
Regulation shall keep such invoice until the dispute is resolved or a
final court decision is made. In all cases, the period of retention
shall not be less that the period specified under Paragraph (A) of
this Article.
Article 9:
Each commodity/service seller shall enable the Department to transfer all invoice data and
information electronically to the Department, and the unit established in the Department shall be
responsible for this.
Article 10:
Responsibility of matching the data and information mentioned on the invoice with the real process
of commodity selling or service provision shall be on the seller and buyer alike, and each shall be
responsible for the invoices that do not match with the real process.
Article 11:
A. Subject to Paragraph (B) of this Article, the establishment whose purpose on the commercial
register, company register, or professional licensing is “grocery, minimarket, supermarket,
and shop” and actually practice this activity with annual turnover of less than 75,000 Dinar,
craftsmen whose annual turnover from the craft is less than 30,000 Dinar, as well as any
other groups specified by the executive instructions shall be excluded from invoice
organization and issuance.
B. If a person, not required to organize and issue the invoice, has sold a commodity/service and
has enough evidence that their turnover is not less than the threshold specified under
Paragraph (A) of this Article, the Director may require them to organize and issue the
invoice, and the provisions of this Regulation shall apply thereto.
C. Any of the entities provided for in Paragraph (A) of this Article may submit a written request
to the Department to issue the invoice, and in such case the provisions of this Regulation
shall apply thereto.
Article 12:
A. The Director, upon a recommendation of a technical committee to be established in the

Department, and under a written request from the seller or any other entity to which this
69
Regulation apply, may amend the data of the invoices or issue invoice templates in line with
the nature of the seller or entity’s activity.
B. In case the seller does not have an electronic invoicing system, the manual invoicing system
shall be used.
Article 13:
Notwithstanding the provisions of this Regulation, leasing contracts containing the data and
information specified under Article 5 of this Regulation shall be used in lieu of the invoices.
Article 14:
A. Department shall follow on with implementation of invoicing issues and control

implementation of the provisions of this Regulation by the persons and entities required to
implement its provisions.
B. A unit shall be established to be responsible for invoicing issues, including linking
commodity/service sellers to the Department and transferring data and information from
the invoicing electronic systems to a central system at the Department.
Article 15:
Each person failing to issue the invoice in accordance with the provisions of this Regulation shall be
penalized of tax evasion as provided by Law.
Article 16:
The Minister shall issue the executive instructions necessary to implement the provisions of this
Regulation, provided that they shall be published in the Official Gazette.
7.2 National e-Government Contact Centre Required Information
The offered e-service solution should provide contact center agents users with enough privileges and
access to Information for them to perform their required role.
In addition to the above, the winning bidder is required to deliver the following for contact center use:
Documentation and training on the following:
o Objectives and benefits of the E-Service (before /after description)

o Benefits of the E-Service
o Target population
o Provide support for the E-Service application – How to use it
o Provide information about the status – When will the end user see
the result
o Provide technical support in case of problems
o Or execute the whole transaction on behalf of the customer?
E-Service frequently asked questions
o Technical
o Business (informational)
70
Furthermore, a number of categories of queries / contact reasons and contact drivers are anticipated:
 Difference between e-Service and physical, traditional service

 How to use
 Payment
 Fulfilment (the paper work)
 Status information
 Technical support
 Complaints
The winning bidder is required to review the above contact reasons and add to them if necessary. In
addition to contact reasons types definition, the winning bidder to provide all related information to
the anticipated questions. (Answer to the questions illustrated in the matrix below)
Question & Answer Matrix - Illustrative
Moment: Pre-use During use Post use
Category:
Difference between “What are the benefits, “I have completed this “I used to receive
E-Service and compared to going to the process now, should I not notification via letter, is
traditional service relevant government go somewhere to pick up the e-mail I just received
entities?” the paperwork?” replacing the letter?”
How to use “How long will it take to “I have filled in this

complete the process? I information on that screen,
use dial-up Internet what do I do next?”
access and do not want
to spend a fortune of
phone costs”
“What kind of
information do I need to
have in order to
complete the process?”
Status information “I have completed the E- “I received confirmation

Service process, when will I last week that the process
receive confirmation that it was completed. Can you
went OK?” see where my request
is?”
Payment “I do not trust your “Can you please confirm

online payment; can I that you received my
make the payment payment?”
separately?”
Fulfilment “If I submit the request “It has been 2 weeks since
tomorrow, when will I I was supposed to receive
receive the output?” my paperwork. Why
71
haven’t I received it
already?”
Technical support “What are the minimum “I think my browser’s pop-

systems requirements?” up blocker is interfering
with the application, is that
“I cannot access the correct?”
application, is the
website down?” “The application crashed
while I was entering my
information, is everything
lost?”
Complaints “I do not have Internet “I am having problems “I have completed the

access and cannot use completing the transaction transaction but did not
the E-Service, this is and the person trying to receive the paperwork
discrimination” help me was very rude” and was charged for it,
this is scandalous”
The winning bidder should make the following information ready to the contact center team to learn
about:
o The Service
o The issues related to the current processes
o The changes and improvements made with the E-Service
o The processes surrounding the E-Service
o The remaining issues that people have to deal with around the E-
Service
o The impact on the Civil Servants population
o identify the as-is situation in the relevant government entities, as
well as the expected changes due to the introduction of E-Service
o Activities that the contact center could / need to “piggyback” in
order to complete the whole process.
7.3 Technical proposal response format
Introduction
Executive Summary
This includes the bidder’s understanding of the terms of reference, scope of work and necessary skills,
and company profile. This involves including an overview of the main points contained in the proposal
with references to sections where more detailed discussion of each point can be found (maximum 4
pages).
Approach
72
A detailed description of how the bidder will undertake each major area in the SCOPE OF THE PROJECT
and DELIVERABLES section (see section 4), required resources (bidder, ministry and third party) and
any special skills required, the deliverables (format and structure), use of any methodology and how
it will cover the scope, use of any standard tools, and duration of any work streams.
[Activity 1]
Implementation Approach
Actions Approach
Describes the bidder’s approach for implementing

the action; including
Provides a listing of the actions needed ▪ Process (i.e. steps)

for the Activity ▪ Standard methodologies
adopted
▪ Scope of involvement for each
stakeholders
… …
Deliverables
Deliverables Format and Structure
Provides a listing of the deliverables of Describes the format (e.g. MS Word document) and
the Activity Structure (e.g. Outline, indicating the scope and
content) of each deliverable.
… …
[Activity 2]
Actions Approach


adopted
stakeholders
… …
Deliverables
73
… …
[Activity…]
Actions Approach


adopted
stakeholders
… …
Deliverables
… …
Work Plan and Duration
The work plan and duration for the overall consulting work, including any dependencies between the
separate items in the scope. The bidder should provide milestones for each deliverable. The work
plan should break down the phases and tasks within each phase and indicate which resources will be
working on these tasks
Requirement Compliance Statement
Please include the attached compliance Excel file.
Track Record
The bidder’s track record on projects similar in both size and nature undertaken in the last five years,
and references of suitable client references with contact details
74
CVs of Project Staff
A summary of proposed team and a description of each project staff role and their relevant
experience. Brief resumes of the team who will work on the project (all detailed resumes should be
included in an Appendix). The bidder should also indicate the availability of the proposed staff and
indicate which phases of the project each team member is participating in, what role they will be
playing, and what their utilization rate will be (percentage of their time), below is the required
template to be filled for each team member
Curriculum Vitae
Proposed Position on the Project: ______________________
Name of Firm: ______________________
Name of Personnel: ______________________
Profession/Position: ______________________
Date of Birth ______________________
Years with the Company: __________ Nationality: ___________
Proposed Duration on Site: __________
Key Qualifications and Relevant Experience
________________________________________________________________________________
_
________________________________________________________________________________
_
________________________________________________________________________________
_
________________________________________________________________________________
_
________________________________________________________________________________
_
________________________________________________________________________________
_
75
________________________________________________________________________________
_
________________________________________________________________________________
_
________________________________________________________________________________
_
Expected Role in the Proposed Project
________________________________________________________________________________
_
________________________________________________________________________________
_
________________________________________________________________________________
_
________________________________________________________________________________
_
________________________________________________________________________________
_
________________________________________________________________________________
_
Education
________________________________________________________________________________
_
Employment Record:
(a) Employment Record From date — present
Employer ___________________________________
76
Position held ________________________________________________
(b) Employment record ____________ — ____________
Employer ___________________________________
Position held ________________________________________________
(c) Employment record ____________ — ____________
Employer ___________________________________
Position held ________________________________________________
Languages:
ReadingSpeaking Writing
Language 1
Language n
------------------------------------------------------ -----------------------------
Signature Date
7.4 Financial Proposal Response Format
Please indicate the overall estimated cost of your proposed solution.
Cost should be broken down as per the schedules below as well as the detailed scope of work
presented in section 3 of this document.
The price quotation should be all-inclusive fixed lump sum price and provided in Jordanian Dinars (JD).
All prices are inclusive of all fees and taxes. All prices are for site delivery.
Project Total Cost (Lump Sum Contract Amount) for the total compensation for the whole WORK
contemplated under this proposal: [ JD]
77
Services Amount
System Design, Installation and Configuration
Required Solution Infrastructure
Solution Security Requirements
Training and Knowledge Transfer
Operations, Maintenance and Support
Project Management
Quality Management
Total
Total Amount in Words: (Only ------------------------------------------------------------------------------Jordanian

Dinars)
Project Detailed Cost:
(Jordanian Dinars)
System Design, Installation and Configuration:
Unit cost Number of

System Installation and
Resource (man day Units (man
Configuration
cost) days) Total Cost Notes
[List all activities Skill 1

associated with System
Installation and
Configuration]
Skill 2
Skill 3
Skill N
TOTAL
78
Dinars)
Required Solution Infrastructure:
Unit cost Number of

Required Solution
Resource (man day Units (man Total Cost Notes
Infrastructure
cost) days)
[ List all activities Skill 1

associated with Required
Solution Infrastructure]
Skill 2
Skill N
TOTAL

Dinars)
79
Proposed Software Licenses
Software Supplier Name of License Metrics No Unit price Total One year maintenance Total (inc maint)
Software (i.e. by number of Licenses (24/7) and upgrade
clients, processor
power or other
TOTAL
(i) Use several lines in the table if the license complexity warrants
Total Amount in Words: (Only ------------------------------------------------------------------------------Jordanian Dinars)
80
Training and Knowledge Transfer
Training and Knowledge price per duration ( no.

Resource Total Cost Comments
Transfer year of years)

associated with Training
and Knowledge Transfer]
Skill 2
Skill n
TOTAL

Dinars)
Operations, Maintenance and Support
price per duration ( no.

Operations Support Resource Total Cost Comments
year of years)

associated with
Operation Maintenance
and Support]
Skill 2
Skill n
[ List all activities

associated with
Warranty]
TOTAL

Dinars)
Project Management:
Unit cost Number of

Project Management Resource (man day Units (man Total Cost Comments
cost) days)
81
associated with Project
Management]
Skill 2
Skill n
TOTAL

Dinars)
Quality Management:
Unit cost Number of

Quality Management Resource (man day Units (man Total Cost Comments
cost) days)

associated with Quality
Management]
Skill 2
Skill n
TOTAL
Other Costs (if any)
Note (1): The Itemized Financial Proposal will be examined prior Contract Award in order to ascertain
that the items are correctly calculated. The itemized prices are for reference only and the lump sum
price shall constitute all costs …etc incurred by the bidder for the execution of the project. Should any
arithmetical error be found, it will be corrected and the Proposal Value will be amended accordingly.
MoDEE encourages all bidders to study carefully their prices and to submit their final and lowest
prices.
Note (2): The bidder shall also take into account that all the rates quoted in his Price Proposal shall be
fixed throughout the Contract duration and that no adjustment to such rates shall be accepted by
MoDEE , except when otherwise provided for in the Contract.
82
7.5 Confidentiality Undertaking
Confidentiality Undertaking
___________________________________
This Undertaking is made on [DATE] by [NAME] “[Consultant]” to the benefit of ISTD, “[Principal]”
[Address XXXXXXX].
WHEREAS, ISTD possesses certain financial, technical, administrative and other valuable Information
(referred to hereinafter as Confidential Information)
WHEREAS, [Consultant], while performing certain tasks required by the Principal in connection with
the ………………. (the Project), did access such Confidential Information,
WHEREAS, the Principal considers the Confidential Information to be confidential and proprietary.
Confidential Information:
As used in this Agreement, the term “Confidential Information” means all information, transmitted by
Principal or any of its subsidiaries, affiliates, agents, representatives, offices and their respective
personnel, consultants and winning bidders, that is disclosed to the Winning bidder or coming to his
knowledge in the course of evaluating and/or implementing the Project and shall include all
information in any form whether oral, electronic, written, type written or printed form. Confidential
Information shall mean information not generally known outside the Principal, it does not include
information that is now in or hereafter enters the public domain without a breach of this Agreement
or information or information known to Winning bidder by Third Party who did not acquire this
information from Principal”.
The Consultant hereby acknowledges and agrees that;
1) The Confidential Information will be retained in the Principal’s premises and will not be
moved without the express written consent of the Principal. All Confidential Information
shall be and remain the property of the Principal, and such Confidential Information and any
copies thereof, as well as any summaries thereof, shall be promptly returned to the Principal
upon written request and/or destroyed at the Principal's option without retaining any
copies. The Winning bidder shall not use the Confidential Information for any purpose after
the Project.
2) It will use all reasonable means and effort, not less than that used to protect its own
proprietary information, to safeguard the Confidential Information.
3) the Winning bidder shall protect Confidential Information from unauthorized use,
publication or disclosure.
4) It will not, directly or indirectly, show or otherwise disclose , publish, communicate, discuss ,
announce, make available the contents of the Confidential Information or any part thereof
to any other person or entity except as authorized in writing by the Principal.
5) It will make no copies or reproduce the Confidential Information, except after the Principal’s
written consent.
Remedy and damages:
83
The Winning bidder acknowledges that monetary damages for unauthorized disclosure may not be
less than 20% of the Project and that Principal shall be entitled, in addition to monetary damages and
without waiving any other rights or remedies, to such injunctive or equitable relief as may be deemed
proper by a court of competent jurisdiction.
Employee Access and Control of Information
It is understood that the Winning bidder might need from time to time to discuss the details of
confidential Information with other individuals employed within its own or associated companies in
order to support, evaluate, and/or advance the interests of the subject business transaction. Any such
discussion will be kept to a minimum, and the details disclosed only on a need to know basis. Prior to
any such discussion, the Winning bidder shall inform each such individual of the proprietary and
confidential nature of the Confidential Information and of the Winning bidder’s obligations under this
Agreement. Each such individual shall also be informed that by accepting such access, he thereby
agrees to be bound by the provisions of this Agreement. Furthermore, by allowing any such access,
the Winning bidder agrees to be and remain jointly and severally liable for any disclosure by any such
individual that is not in accordance with this Agreement.
Miscellaneous
The obligations and rights of the Parties shall be binding on and inure to the benefit of their respective
heirs, successors, assigns, and affiliates. This Agreement may be amended or modified only by a
subsequent agreement in writing signed by both parties. Winning bidder may not transfer or assign
the Agreement or part thereof. No provision of this Agreement shall be deemed to have been waived
by any act or acquiescence on the part of the Principal, its agents or employees, nor shall any waiver
of any provision of this Agreement constitute a waiver of any other provision(s) or of the same
provision on another occasion. This Agreement shall be construed and enforced according to
Jordanian Law. The Winning bidder hereby agrees to the jurisdiction of the Courts of Amman, Jordan
and to the jurisdiction of any courts where the Principal deems it appropriate or necessary to enforce
its rights under this Agreement.
Term of Agreement
The obligations of the parties under this Agreement shall continue and survive the completion of the
Project and shall remain binding even if any or all of the parties abandon their efforts to undertake or
continue the Project.
IN WITNESS WHEREOF, the Winning bidder hereto has executed this Agreement on the date first
written above.
Consultant:
By:____________________________
Authorized Officer
84
7.6 Joint Venture Agreement Template
Standard Form of Joint-venture Agreement
JOINT-VENTURE AGREEMENT ‫اتفاقية ائتالف‬
/ ‫الموافق‬ ‫تم االتفاق في هذا اليوم‬ /

It is agreed on this day.............of…………..2008
between:-
..................... Represented by Mr. .............................. .............................. ‫ ويمثلها السيد‬............................
1- To form a Joint Venture to execute the works specified ( ‫ على تشكيل ائتالف فيما بينهم لتنفيذ أشغال عقد العطاء رقم‬-1
in the Contract of the Central Tender No. ( / ) ‫ المبرم أو الذي سوف‬.......................................‫) المتعلق بـ‬ /
......................................................... which was signed or .‫يبرم مع صاحب العمل‬
to be signed with the Employer.
‫ يلتزم جميع أطراف االئتالف بإنجاز جميع االشغال المتفق عليها مع‬-2
2- All parties of the Joint Venture shall be obliged to ‫صاحب العمل والمنصوص عليها في عقد العطاء ويكونون متضامنين‬
perform all works agreed upon with the employer which ‫ومتكافلين في مسئولياتهم نحو صاحب العمل فيما يخص كافة األشغال‬
are specified in the tender contract, and they are jointly ‫ وفي حالة تخلف أو‬.‫ ) والعقد الخاص به‬/ ( ‫المتعلقة بالعطاء رقم‬
and severally responsible for all works related to tender ً ‫تأخر أحد أطراف االئتالف عن إنجاز المسئوليات المناط به تنفيذها جزئيا‬
no. ( / ) and the contract pertaining thereto. Should ‫ أو منفردين دون تحفظ بإنجاز‬/ ‫أو كليا ً يلتزم بقية األطراف مجتمعين و‬
one party fails or delays to perform its obligations either ‫جميع االلتزامات المحددة بالعقد الموقع مع صاحب العمل بالشكل المتفق‬
partially or totally, it shall be the responsibility of all other .‫عليه في العقد‬
parties jointly and severally without reservation to
execute all obligations set under the contract with the
Employer to the same standards specified by the contract
.
3- The parties to the Joint Venture nominate .....................................،‫ يعين أطراف االئتالف رئيسا ً لالئتالف‬-3
............................................. as leader of the Joint ‫ وأي مراسالت تتم بين صاحب العمل‬، ) / ( ‫إلدارة العطاء رقم‬
Venture. Any correspondence between the Employer and ‫ التجمع او المشاركة توجه إليه‬،‫واالئتالف‬
the parties to the Joint Venture shall be addressed to such
leader.
‫ ممثالً لرئيس االئتالف‬.................. ‫ يسمي أطراف االئتالف السيد‬-4
‫ومفوضا" بالتوقيع نيابة عن االئتالف على كافة األوراق والعقود الخاصة‬
4- The parties to the Joint Venture nominate
Mr........................................ as a representative of the
‫ ) وبتمثيل االئتالف أمام المحاكم المختصة والدوائر‬/ ( ‫بالعطاء رقم‬
leader and he is authorized to sign on behalf of the Joint
‫والمالية‬ ‫الرسمية وغير الرسمية في كافة األمور العقدية واإلدارية‬
Venture all documents and contracts related to tender no. . ‫به‬ ‫الخاص‬ ‫ ) والعقد‬/ ( ‫والقضائية المتعلقة بالعطاء رقم‬
( / ) , and to represent the Joint Venture before all
competent courts and non-official bodies in all
85
contractual, administrative , financial and legal issues ‫ ال يحق ألطراف االئتالف أو أي طرف فيه فسخ االئتالف فيما بينهم أو‬-5
related to tender No. ( / ) and the contract pertaining ‫تبديل ممثل رئيس االئتالف إال بعد انتهاء األشغال المحالة عليهم بموجب‬
thereto. ‫العقد الخاص بهذا العطاء وتكون مسئولياتهم تجاه صاحب العمل قائمه إلى‬
‫حين تسليم األشغال استالما ً نهائيا حسب شروط االستالم المحددة في وثائق‬
5- The parties to the Joint Venture have no right to ‫ العطاء‬/ ‫العقد‬
terminate this agreement or substitute the leader’s
representative until the works awarded to them by the
contract to this tender are completed and shall remain
responsible before the employer until the works are ‫ حررت هذه االتفاقية باللغتين العربية واإلنجليزية في حالة نشوء أي‬-6
finally taken over as per the conditions of taking over ‫اختالف في تفسير أي من بنودها تعتبر لغة العقد المعتمدة هي اللغة العربية‬
specified in the Tender / Contract documents .
‫وملزمة للطرفين‬
6- This agreement is written in both Languages Arabic and
English should any discrepancy in interpretation arise the
Arabic text shall be considered the authentic.
‫الطرف الثالث‬
‫الطرف الثاني‬ ‫الطرف األول‬
Third Party Second Party First Party
ً ‫توقيع الشخص المخول بالتوقيع قانونيًا‬

................ ................ ................
Signature of the Authorized Personnel
‫الخاتم المعتمد‬
Seal
................ ................ ................
Notary Public Certification ‫تصديق كاتب العدل‬
7.7 E-Government Implementation Framework
Implementation Framework
This section provides a definition of a general framework for e-government infrastructure components
that is based on the concept of the e-Government Architecture Framework (eGAF) and Service
Oriented Architecture (SOA) as well as two other major initiatives – e-Government Portal and Secure
86
Government Network – that are major supporting infrastructure components for e-Services. In
addition to other important initiatives like the e-Government Contact Centre, National Payment
gateway(EFAWATEERcom), Government Service Bus (GSB), and National E-gov Portal.
e-Government Architecture
As the facilitator of the implementation and delivery of governmental e-Services, the e-Government
Program has been working diligently to define its target e-Government federated enterprise
architecture, which is meant to enable seamless integration and secure interoperability of services
between distributed entities cohesively and cost effectively using SOA. The responsibility of the
implementation and delivery of government e-Services lies upon the government and its various
entities:
The e-Government Program plays the role of the “e-Services enabler” by providing the components
that constitute the Central e-Government Service Delivery Platform;
The other governmental entities (mainly ministries) play the role of the “e-Services providers” by
composing and operating their e-Services, having the choice to either outsource these services, or
operate them in-house.
87
The following diagram presents a high-level view of the various e-Government stakeholders, and
depicts the federated, customer-centric nature of the e-Government architecture1:
E-Government of Jordan Conventional

Channels
Governmental Entities
E-Government Users
Governmental Portals
E-Government Portal
Services
E-Gov
Services
Contact
Center
E-Government
Program Businesses
Business Portals
Figure 5.4.1: e-Government of Jordan High-level View

The e-Government portal of Jordan is customer-centric, i.e. all e-Services are centered on customers’
needs. Currently, the e-Government Web Portal, which constitutes the central web informational
portal of the e-Government, co-exists with a number of other governmental portals. Ultimately, the
e-government’s portal will turn into a multi-channel, one-stop-shop for all government e-Services, and
will support various access and delivery channels (e.g. Web, SMS, Kiosks, etc.).
The following diagram depicts the main building blocks for the e-Government target architecture:
1
The diagram is meant to present a high-level view of the e-Government from a business perspective; hence
many businesses and technical details do not appear for the sake of the overall understanding.
88
Figure 5.4.2: e-Government Architecture High-level View
As shown in the above diagram, the e-Government Program will provide a central Government Service
Bus (GSB) that will serve as a unique point of traffic. It will take care of routing service invocations
towards service providers and of returning responses back to the service clients (which could be the
portal or some other service as in the case of cross-organizational e-Services). The e-Government
Program will also provide a set of shared services (for instance National Payment Gateway
,EFAWATEERcom, notification gateway, etc.) that can be invoked from within the context of any
e-Service, promoting reuse of components across the government and thus reducing the costs by
eliminating the needs for dedicated implementations of components that perform the same
functionalities offered by any of the central shared functionalities at the entities side. The services
directory will maintain an active list of all available services as well as their interface specifications. A
central identity management solution will be used to federate identities, provide (when applicable)
single-sign-on, facilitate propagation of user identities and attributes across the e-Government trust
domain, and enable account provisioning. Finally, a central technical performance model will be put
in place to enable concerned technical stakeholder at the e-Government Program to monitor the
health and performance of the overall e-Government and identify issues and bottlenecks as well as
potential areas for improvement. In order to prevent vendor lock-in, all of the above components will
be built solely upon open standards, such as Web Services, SOAP. Where necessary, all service
providers shall conform to the above standards in order to interoperate with other components within
the e-Government framework.
The e-Government of Jordan Program will also provide Government Entities with an Enterprise
Architecture Framework and methodology to help them in building their Enterprise Architecture in
respect of the above principles. The e-Government Program will also provide help and support on how
to apply this framework to aid the entities during the course of the framework implementation.
The e-Government Program will provide all necessary documentation and support in order to enable
project implementers to produce deliverables that are in line with the e-Government architecture
vision in the form of a Reference Model Winning PSPs shall have to access the necessary
documentation.
E-GAF & SOA

The primary delivery models for e-government are:
89
 Government-to-Citizen (G2C)
 Government-to-Business (G2B)
 Government-to-Government (G2G)
Jordan e-government program is capitalizing over the G2G, G2B, and G2C service models in order to
provide information integration between the different government entities to improve government
processes efficiency, easy end users accessibility, increase transparency and reduce total cost of
ownership.
The following figure depicts the different parties involved in the integration.
Figure 5.4.3: Government of Jordan Integrating Participating Parties

As seen in the figure above the following parties are involved in integration:
 Government entities: Government entities form the major customer and beneficiary for
the business integration service provided by the e-government central platform. G2G
integration model shall introduce efficient mechanism for integrating the government
entities in order to deliver G2C, G2E and G2B services.
 Telecommunication companies: Telecommunication companies are considered business
partners. The program will be responsible for providing the G2B integration services
between those companies and the government entities. One example of such services
can be the SMS notification.
 Business partners: The program will be responsible for providing the G2B integration
service between business partners and government entities. Example for such business
partners: payment service providers (PSP) and private banks.
 Contact center: Contact center’s business is to serve the government entities end users.
The program will be responsible for providing the G2B integration services between
those contact centers and the government entities.
The IT infrastructure in the government entities and other business partners in Jordan is
heterogeneous across operating systems, applications and software packages. Existing applications
are used to run current business processes; so starting from scratch to build new infrastructure is a
very expensive and non-practical option. Hence; government entities should quickly respond to
business changes with agility; leverage existing investments in applications and application
90
Infrastructure in order to address newer business requirements; support new channels of interactions
with clients and partners (other government entities); and feature an architecture that supports
business oriented model.
SOA is efficient for large and distributed systems where other types of integration are more complex
and costly.
Jordan e-Government Business Integration Patterns

The business integration patterns that will be enabled by the central platform infrastructure are:
 Vertical e-Services integration pattern: defines the pattern in which services are provided
end-to-end by one government entity. It’s true that such services are provided by one
government entity but their integration pattern may use some of the e-government central
platform shared services such as authentication, online payment, notification, contact
center … etc.
 Cross organizational e-Services integration pattern: defines the pattern in which a
government service requires the involvement of several government entities in order to be
delivered.
 Composite e-Services integration pattern: defines the pattern in which a service flows across
multiple government entities and contribute to e-Government overall objectives (e.g. GRP).
 Shared e-Services integration pattern: shared services are defined as the ‘’enablers’’,
providing technology-based functionality that are central to the provision of vertical and
cross-organizational services. Their ultimate ownership belongs to the e-government central
platform as part of the federated architecture framework.
Jordan Information Interoperability Framework (IIF)
The Jordan e-government program has initiated an information interoperability framework that will
manage and standardize the exchange of common and shared information between the different
parties involved in the e-government of Jordan such as the government entities, central platform and
business partners.
The IIF mandates that all the parties should speak the same language and this includes:
 Protocol: SOAP/HTTP(s)
 Content type: XML
 Standards: Jordan e-government standards
 Format: IIF format
Note : For any new service that will be integrate with GSP it’s recommended to be implemented using
the WCF standard.
E-GAF and Business Process Management (BPM)

The government entities in Jordan will provide cross organizational services whose logic is distributed
across other government entities and business partners including the central platform. The main
provider of a service [Principle Service Provider] will host the workflow of the Cross Organizational
Service. Hence, the national GSB of Jordan will not host the workflow of any Government Entity
Service, nevertheless, it should enable integration between different entities’ services to constitute a
Cross Organizational Service.
91
A government entity will utilize the central platform integration services published web services, and
other government entities published e-Services to compose the business processes for their cross
organizational e-service. The following figure depicts the relation between the integration
infrastructure provided by the e-government central platform and the BPM components at the
government entities premises.
Figure5.4.4: E-GAF and BPM

As depicted in the figure above, the application in government entity “A” starts a business process
that includes executing tasks at government entity “B”, “C” in addition to the notification services
provided by the e-government central platform. The application at “A” will communicate with the
Business Process Management System (BPMS) component2 at its premises to execute the complete
process. The BPMS component invokes the entity “B” Web service (WS-B1), entity “C” Web service
(WB-C1) and the Notification WS web services according to the rules that had been set earlier in its
rule engine.
E-GAF Integration Reference Model

The following figure depicts the E-GAF integration reference mode.
2
WFMS: A software application that stores process definitions and runs jobs based on those process definitions
via its workflow engine component. The workflow engine is the runtime execution module.
92
Figure 5.4.5: E-GAF Integration Reference Model
As depicted in the figure above; the reference model crosses the different parties involved in the SOA
architecture: service consumer; integration services (GSB), and the service provider.
The consumer will implement the Web service client application that contains either direct calls to
published Web services or calls to the orchestrated or choreographed or business processes.
The provider publishes his services (atomic and composite) through the GSB. The services are enabled
by a set of components (JavaBean, EJB, COM, DCOM, PLSQL … etc.). Such components form the bridge
between the backend applications, business applications and databases on one side and the web
services on the other side.
The integration services at the central platform represented by the GSB form the mediator between
the service consumer and service provider. The GSB provides several services and functionalities such
as integration hub, services registry, security, intelligent routing …etc.
Security, audit, high availability, manageability are quality of service attributes for the integration
model.
Secure Government Network
The Secure Government Network (SGN) is a large initiative linking all government entities to a secure
Government Network as a part of a recently developed Connectivity Strategy.
The main role of the SGN is to provide connectivity to government entities. Currently, the following
services are provided through the SGN:
 File sharing/exchange between government's entities connected through the

SGN.
 E-mail services (electronic services that include email messaging solution,
calendar, personal communications tools, etc.).
 Inter-application communication
Upon request, MoDEE will provide the winning bidder with related document(s) describing in detail
Connectivity Strategy and detailed requirements related to SGN.
Government Service Bus (GSB)
GSB Integration Requirements
93
The Government Service Bus (GSB) is the central enabling set of components of the e-Government
infrastructure that is based on Service Oriented Architecture (SOA). The GSB provides an infrastructure
that removes any direct connection between service consumers and providers. Consumers connect to
the bus and not the provider that actually implements the service. This provides location
independence to all services.
The GSB also implements further value add Infrastructure or “Fabric” services. For example, security,
transaction, scalability, directory, registry and delivery assurance are implemented centrally within
the bus instead of having these buried within the applications or at the government agency back-ends.
The GSB architecture enables governmental entities to connect and use ready-made components of
the e-Government. The diagram below shows the conceptual architecture of the GSB.
IBM WebSphere Data Power SOA Appliances are purpose-built, easy-to-deploy network devices that
simplify, secure, and accelerate your XML and Web services deployments while extending your SOA
infrastructure. Data Power provides configuration-based approach to meet MoDEE’s edge ESB
requirements. The DataPower Appliance provides many core functions to applications, such as
service-level management, routing, data and policy transformations, policy enforcement, access
control, and hardened security—all in a single “drop-in” device.
For MoDEE, Data Power provides the following key benefits.
 Platform for Vertical e-Services integration: Web services from different government entities
(service providers) can be securely exposed using Data Power.
 Cross Organizational e-Services Platform: Data Power provides role-based access control to
ensure the right level of secure access for cross-organizational e-Services.
 Composite e-Services integration platform: Data Power is the service composition layer that
exposes composite services to service consumers.
 Shared e-Services integration platform: Data Power supports modular service integration
architecture.
When deploying this IBM appliance in your network, you secure your enterprise at the Application
Layer vs. at the Network Layer. DataPower is a next-generation appliance that operates on MESSAGES
instead of PACKETS. This enables offloading security checks and structural checks from the service
providers, there by simplifying integration while minimizing performance degradation.
Solution Benefits
Using IBM Data Power as the ESB appliance, this provides the following benefits:
 Ease of implementing security and web services in a purpose-built appliance

resulting in reduced Development Lifecycle and implementation costs.
 Configuration, rather than coding: This approach offers faster time to market
compared to traditional coding approaches for service integration.
 Offloading tedious security tasks from Sevice Providers (Government entities),
preventing potential performance degradation
 Appliance approach provides greater security compared to software based
solutions (removes periodic operating system patches, OS vulnerabilities,
virtualization layer vulnerabilities, regular software patches, etc.)
94
 Purpose built firmware, offering wire-speed processing.
 Prepare your environment for the future: DataPower is ready for mobile and
web 2.0
 Extensible architecture: add-on modules can be turned on as required.
 Highly fault tolerant device (multiple power supplies, multiple network ports)
with in-built load balancing & clustering options.
The Data Power Appliance is purpose-built, easy to consume and easy to use. Data Power delivers
security, common message transformation, integration, and routing functions in a network device.
IBM approach helps you to leverage and scale your existing infrastructure investments.
Solution components and features
The below sections lists the used components and the utilized features within the Data Power
appliance during the implementation of the Edge ESG to help meet MoDEE requirements:
 Logging
IBM Data Power appliance offers a bunch of different options when it comes to logging. MoDEE’s main
concerns when it came to logging were:
- The ability to troubleshoot a problem when one arises: As for this point in the solution IBM
Data Power offers a feature called ‘debug probe’, this feature can be enabled to log the
messages temporarily and then view them at each stage within the policy execution, this
also offers information like the requested and source URL/IP which should be sufficient
when a problem arises at the message level.
- Being able to view and track events as they occur (mostly errors): As for this DataPower’s
out of the box logging behavior should suffice, it offers the ability to filter the logs based on
the component from which they originated and the ability to increase and decrease the level
of logging details based on the current need.
- DataPower auditing: Out of the box, DataPower offers the ability to log any administrational
actions, by which user where they performed and when (this also included some lower level
relevant action logging).
 Security using SSL certificates
When it comes to SSL, the solution includes two different implementations:
- Standard SSL over HTTP (for G2G services)

In this scenario DataPower is issued a certificate which the service consumers should trust and
accordingly be able to authenticate DataPower boxes and perform transport layer encryption. As for
between DataPower and the service providers, DataPower should receive a copy of the public
certificate of the entities it will connect to in order to trust them.
- SSL with mutual authentication (for G2B services)

As for this scenario the communication with the backend services is still done in the same manner but
the communication with the consumers is done differently. In this case the first part still stands true
where DataPower is still issued a certificate which the service consumers should trust but the
difference is that the service consumers themselves should also be issued certificates which the
DataPower should receive (public certificates) in order to perform a mutually authenticated
connection.
95
Mutual authentication or two-way authentication (sometimes written as 2WAY authentication) refers
to two parties authenticating each other at the same time. In technology terms, it refers to a client or
user authenticating themselves to a server and that server authenticating itself to the user in such a
way that both parties are assured of the others' identity. As for the certificates issuing three different
options were discussed:
- Purchasing internationally trusted certificates

- Using the new Jordan PKI to issue new certificates (in the future)
- Using self-signed certificates (this option will not be used)
DataPower supports four different formats when it comes to certificates and key:
 DER
 PEM
 PKCS #8
 PKCS #12
Note: DataPower offers notifications for the box administrators/developers when an SSL certificate is
going to expire within a month to insure minimized service downtime and a minimal impact of this
event.
 Web services proxy

A ‘Web Service Proxy’ provides security and abstraction for remote web services. It is the object where
most of the implementation will be performed and where the majority of the other features are
contained. A Web Service Proxy makes it easier to implement certain features for web services based
on a WSDL file.
The first step of implementing a web service in DataPower is always obtaining the WSDL (by uploading
to the device or fetching from WSRR), after doing so the Web Service Proxy starts offering options
starting with specifying the end point to be exposed and the protocol to be used. After that one can
start applying the required policy. In the current scenario we have two policies to be applied per
service the first (client to server) at the service level and another policy to apply on the way back but
on a lower level and that is the operation level.
On the client to server policy:
- Within the AAA action the service credentials will be extracted from the message
(Password-carrying UsernameToken element from WS-Security header), this identity
will be validated against LDAP to decide whether the consumer is eligible to
consume the service based on whether the identity is a member of the service group
or not.
- At this stage the SLA is enforced.
- An attribute containing the identity’s access level to the services is queried and
stored in context variables.
- The identity within the message is replaced with another identity which is meant to
authenticate DataPower boxes at the service provider’s side.
- The destination URL is replaced with the actual service provider’s URL instead the
one that came with the message here.
96
On the way back (server to client) each response to a consumer is filtered based on the consumer’s
access level to a service using a transformation action (an XSLT style sheet) and finally the response is
returned to the consumer here.Guidelines for web service integration
Government to Government - SGN
The below is a list containing all the guidelines for a service provider willing to expose a service or a
service consumer willing to integrate with the GSB:
1- Messages should comply with the XML + SOAP standards.

2- All the currently implemented services follow the SOAP standard version 1.1.
3- The SOAP header must contain a Password-carrying Username Token element from WS-
Security header.
4- The currently followed approach mandates that the Username Token should not be
signed.
5- The SOAP message should not be encrypted nor signed.
6- The current followed approach mandates not using Timestamp token so that consumers
with a different time or time zone settings could consume the service.
7- Both the service provider and consumer must implement and use transport layer
security
a. SSL version 2 should not be used
b. SSL version 3 should not be used
c. Weak ciphers and hashes should not be used
d. The usage of strong ciphers only is strongly recommended
e. It is mandatory to use TLS v1.0 , v1.1 or v1.2
f. The usage of message compression is not recommended
g. The usage of insecure legacy SSL should not be permitted
8- The recommended certificate format to be used is DER encoded binary X.509 certificates
(.cer)
9- The recommended RSA key length for the issued and used certificates and keys is 2048.
10- Services that can provide large chunks of data at once (ex. Search based services) are
recommended to use some sort of pagination and not to return all the data at once if
the result is considered large enough.
11- All the data fields within the message body should be marked as optional from the
provider’s side and the service consumer should be able to handle any missing or empty
fields appropriately (regardless of data type).
12- The message providers are free to build the message body structure as they see fit to
the service requirements as long as they comply with the relevant points mentioned
above.
13- Using any additional feature from WS-Security or WS-Standards in general is not
recommended unless verified and approved to be supported by the GSB.
Government to Business - Edge
In addition to all the above mentioned guidelines in the G2G section above, any entity outside the
government (outside the SGN network) who would like to integrate with the GSB must comply with
the below:
97
1- The entity must comply with the mutual authentication or two-way authentication
(sometimes referred to as 2WAY authentication) specifications.
Establishing the encrypted channel using certificate-based mutual authentication involves:
- A client requests access to a protected resource.

- The server presents its certificate to the client.
- The client verifies the server’s certificate.
- If successful, the client sends its certificate to the server.
- The server verifies the client’s credentials.
- If successful, the server grants access to the protected resource requested by the
client.
Note: To establish this approach the entity should provide its public certificate to the GSB team
(regardless of being a service provider or a service consumer) to ensure its trust as well as to receive
the public certificate from GSB and insure that it is trusted from the entity’s side as well.
98
Sample request message
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/" xmlns:u="http://docs.oasis-

open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
<s:Header>
<ActivityId CorrelationId="bcf08350-0ad0-4e6a-b596-9994e137b45c"
xmlns="http://schemas.microsoft.com/2004/09/ServiceModel/Diagnostics">9dc40624-0ae7-4984-
8806-4e251982b213</ActivityId>
<o:Security s:mustUnderstand="1"
xmlns:o="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" >
<o:UsernameToken u:Id="uuid-1349a92e-13f7-41d1-bdde-0021a9c1d276-79">
<o:Username>UserName</o:Username>
<o:Password>********</o:Password>
</o:UsernameToken>
</o:Security>
</s:Header>
<s:Body>
<operation xmlns="http://tempuri.org/" >
<NationalNo>123456789</FirmNationalNo>
</operation>
</s:Body>
</s:Envelope>
99
eFAWATEERcom:
eFAWATEERcom solution has the ability to connect different banks and PSPs with different billers
and/or financial houses or services providers, and at the same time, the solution integrates with the
RTGS and the ACH for settlement.
Figure 5.4.6 eFAWATEERcom Switch
Business Process Operations (BPOs) of eFAWATEERcom
The following workflow shows the main stages that eFAWATEERcom consists of:
 Bill Upload
 Bill Presentment
 Bill Payment
 Settlement and Reconciliation
Note:
The solution is capable of supporting different types of payments (periodic, one-off, non-existing bill,
non-banked customer payments) in addition to handling all payment status cycle (New, Updated,
Sent, Completed).
100
Figure 5.4.7 Business Process Operation
Bill Upload
101
Figure 5.4.8 Bill Upload Process
The previous workflow describes in general the bill upload process:
 Billers are required to upload bill summary data to eFAWATEERcom

on a regular basis using the Bill Upload Process; this process can be:
 Biller initiated (Push) via web service using XML file structure or file
transfer using different formats such as XML, CSV, or any other flat
file structure that can be defined as part of the gap analysis.
 eFAWATEERcom initiated (Pull) via web service using XML file
structure, and can be performed through eFAWATEERcom.
 On receiving the uploaded bills, eFAWATEERcom performs certain
validations on the bills to maintain bills data accuracy. These are:
 Data Validations.
 Business Validations.
 If the file/batch has errors/inconsistencies, the systems reject the
entire file/batch of records and return it to the biller for
reprocessing, and it will mention the rejection reason.
 Each bill on eFAWATEERcom database carries a code that shows the
status of the bill such as BillNew, BillUpdated, or BillExpired.
 The solution will response to billers after a successful bill upload
operation is performed successfully.
Bill Presentment (Bill Inquiry)
102
Figure 5.4.9 Bill Presentment
The previous workflow describes in general the bill presentment process:
 Bank applications may query eFAWATEERcom for bill and associated

payment data using a bill inquiry message. The query can take the
form of a Bill-Specific (single) Query in which the Bank wishes to
view bill data for a specific account or bill number. Conversely, a
Customer Profile query permits the Bank to query on any Customer
associated bills (multiple) within the eFAWATEERcom system using
a variety of parameters.
 The bill inquiry request contains a set of information that entered
by the customer such as ‘Bill No.’ plus a set of information that are
provided from the bank application such as [Biller Code, Billing No.].
 eFAWATEERcom verifies all the business rules (active, inactive,
etc…) to be validated for each request, and based on the
verification result, it either accepts or rejects the request.
 The response of bill inquiry may contain one or more records based
on the criteria used in the query and might return zero results as
well.
 All transactions occur across a wide range of channels such as Bank
ATM, Internet Banking, Bank Teller, Call Centre and Point of Sale.
Bill Payment
103
Figure 5.4.10 Bill Payment Sequence
The previous workflow describes in general the bill payment process:
 The Payment process permits Banks to create new payment records

in eFAWATEERcom. The process is intended to ensure the customer
pays according to Biller intent, and it involves a validation of Biller’s
payment rules.
 If the funds are not sufficient, the bank shouldn’t send a bill
payment request for eFAWATEERcom.
 A payment collection account will be set-up in each Settlement
Bank.
 Banks must record data about all payments in storage termed as
eFAWATEERcom Payment Log.
 All transactions occur across a wide range of channels such as Bank
ATM, Internet Banking, Bank Teller, Call Centre, and Point of Sale.
Settlement & Reconciliation
104
Figure 5.4.11 Settlement & Reconciliation Process
The previous workflow describes in general the settlement and reconciliation process:
 eFAWATEERcom sends a settlement file to RTGS (STMTR) that
includes all payments details in totals.
 CBJ “RTGS” will process the STMTR file and sends the response
(STMTA) to eFAWATEERcom system.
 Same operation is repeated for the purpose of the fees totals,
meaning that settlement with RTGS will happen for the payments
and the fees separately.
 eFAWATEERcom sends two settlement files to the Banks/PSPs
including the net total payments and total fees in CSV format,
where each file will contain one row for the total payments and in
the other file one row for the total fees.
 eFAWATEERcom will allow paying banks to reconcile their payment
transactions using the standalone application (Which is a website
that is used for reconciliation purposes) where each bank is
supposed to upload its data and match with eFAWATEERcom data.
 As for settlement banks, and for any unmatched payment
transaction (After receiving settlement payment and fees
notifications from RTGS end of that particular day), they can use the
standalone application for investigating their transactions statuses.
 Paying banks can send their reconciliation results to
eFAWATEERcom, where the result file will be placed automatically
105
on the bank inward FTP directory where eFAWATEERcom support
team will investigate unmatched payments.
More details will be given upon award.
E-Government PUSH SMS API Connectivity
1. Send SMS API:
http://bulksms.arabiacell.net/vas/http/send_sms_http?login_name=login&login_password=passwor
d&msg=messageText&mobile_number=9627XXXXXXXX&from=senderID&tag=X&delivery_date=XXX
X-XX-XXXX:XX&charset=XXXXXX&unicode=X&dlr=X&dlr-url=
http://xyz.com/get_status.php?msg_id=XXXXXX&status=%d
- Parameters:
Parameter Name Description
mobile_number Mobile number of the user. Mobile number should be in the

(Mandatory) international format, example 962790000000
msg (Mandatory) SMS text.
Message sending date, the date should be with format (yyyy-mm-dd

delivery_date (Optional)
hh:mm).
login_name (Mandatory) Login name used to access your account over the SMS PUSH Interface.
login_password
Password used to access your account over the SMS PUSH Interface.
(Mandatory)
Sender ID or name already reserved and defined over the SMS PUSH
from (Mandatory)
Interface.
Message Type :
1. ‫معاملة حالة عن اعالم‬
tag (optional) 2. ‫وارشادية توعوية‬
3. ‫ترويجية‬
4. ‫داخلي اتصال‬
Charset (Optional) Message characters-set, (windows-1256 or UTF-8).
Unicode (Optional) 1 for Arabic Message. 0 fro English Message.
Request delivery report on the sent messages,
dlr (Optional) 1. Delivered messages.
2. Undelivered messages.
106
3. All messages delivery statuses (Delivered and Undelivered).
URL to be fetched if the dlr parameter is present. eGov PUSH SMS

Sender will replace parameter ‘%d’ in the provided URL with 1 for
dlr-url (Optional)
delivery success or 2 for delivery failure, URL must be encoded and
length should not exceed 100 chars.
- API Responses:
In case of success message submitting to the eGov PUSH SMS Sender, the below are the possible
return messages:
- I01-Job (Job ID) queued for processing. (For messages with message date equal to
the current date and time)
- I02-Job (Job ID) has been scheduled. (For messages with message date greater than
the current date and time)
And below are listing of possible errors could be returned by the system.
- Errors:
- E01-Invalid USERNAME or PASSWORD.

- E02-Account Expired.
- E03-Account Inactive.
- E04-Empty SMS message.
- E05-Invalid mobile number.
- E06-SMS balance already expired.
- E07-SMS balance already consumed.
- E08-Database error.
- E09-One of the following parameters missing, USERNAME, PASSWORD, MESSAGE
TEXT OR MOBILE NUMBER.
- E010-Invalid delivery date.
- E011-Date and time for scheduled messages should be greater than the current date
and time.
- E012-You cannot schedule SMS job(s) after SMS expiry date.
- E013-You cannot schedule SMS job(s) after account expiry date
- E014-Not allowed to send SMS through HTTP interface.
- E015-SMS message exceeded the max size for the selected language.
- E016-Invalid sender ID, sender ID must be in English chars and less than or equal 11
in length, space and special characters not allowed.
- E-022- dlr values should be 1, 2 or 3 only.
- E-021- dlr-url length exceeded 100 chars.
2. View Account details and Scheduled Messages API:
http://bulksms.arabiacell.net/vas/http/sch_tasks_http?login_name=login&login_password=passwor
d&action=n
- Parameters:
107
Parameter Name Description
login name used to access your account over the

login_name (Mandatory)
SMS PUSH Interface.
Password used to access your account over the

login_password (Mandatory)
SMS PUSH Interface.
0 : to list all the scheduled messages. 1 : return

user credit details (SMS balance), SMS expiry
Action (Mandatory)
date, Sub-account expiry date and allowed
Sender IDs (Comma separated)
- API Responses:
In case of success request, the returned values will be one of the responses mentioned in the
description column for parameter (Action). In addition, below are listing of possible errors could be
returned by the system.
- Errors:
- E01-One of the following parameters missing, USERNAME, PASSWORD or ACTION.

- E02-Invalid USERNAME or PASSWORD.
- E03-no schedule tasks.
- E04-Sorry, Account Inactive.
- E05-Sorry, Account Expired.
- E06-Error, Invalid action number.
108
7.8 Sample Arabic Contract Agreement (Attached)
<Sample contract in Arabic attached>
109

E Invoicing - RFP - Re-Tendering PDF

Uploaded by

Copyright:

Available Formats

E Invoicing - RFP - Re-Tendering PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

E Invoicing - RFP - Re-Tendering PDF

Uploaded by

Copyright:

Available Formats

MINISTRY OF DIGITAL ECONOMY AND ENTREPRENEURSHIP (MODEE)

REQUEST FOR PROPOSAL (RFP)

NATIONAL E-INVOICING SOLUTION

PROPOSAL DEADLINE: 2-9-2020

RFP NO: 1F2019

TABLE OF CONTENTS ............................................................................................................................. 2

This section outlines the RFP’s purpose and its organization.

Section 2: Project Definition and Description

Section 3: System Features and Requirements

Section 4: Scope of Work for Project Delivery

Section 5: Submission Procedures and Requirements

Section 6: General Terms

This section includes all annexes to the RFP.

Types of transactions that need to be considered:

 It will help prevent fraud and detect tax evaders.

2.2 Legal Framework

2.3 Usage Statistics

Usage Types Number

Income Tax Registered persons 1343123

Sales Tax Registered entities 34506

Expected number of invoice issuer 356000

Expected Daily invoice issued per invoice issuer 50

Total expected number of invoices daily 17,800,000

ISTD Users 1000

Invoicing Increasing percentage yearly 5%

2.4 General Definitions

 Good /commodity: any natural material or animal, agricultural or industrial product

 Seller: the person who sells good, commodity, service.

3.1 User Groups

User type Description

Administrator A MoDEE or ISTD employee with administrative rights to the e-Invoicing

3.2 Access Channels

Access Channel Description

Mobile An iOS or Android smartphone with e-Invoicing application.

System Type Description

Taxpayer’s System chosen/owned by the seller or buyer that is responsible for

E-Government System to manage customer support and service related to e-Invoicing

3.4 Use Cases and Functional Requirements

3.4.1 Use Case 1: Receive e-Invoice

The System shall allow buyers to receive invoices electronically via:

The System shall allow the buyer/seller to retrieve a received/sent invoice by

3.4.3 Use Case 3: Send e-Invoice

The System shall allow for sending a generated invoice by:

3.4.4 Use Case 4: Create e-Invoice

R04.02 e-Invoice creation shall be possible via the Mobile application.

R04.03 e-Invoice creation shall be possible via the Web application.

R04.04 e-Invoice creation shall be possible via the Web API.

Invoice data shall include at least the following:

 identification number of the invoice,

Ability to handle international transactions and support invoices of different localized

3.4.6 Use Case 6: Sign/Register e-Invoice

3.4.7 Use Case 7: Perform System Administrative Functions

System administration includes the following default operations:

3.4.8 Use Case 8: Register for e-Invoice Service

3.4.9 Use Case 9: Handle claims and complaints

3.4.10 Use Case 10: Identify Audit Subjects

3.4.11 Use Case 11: Run audit reports

 Dynamic column define (at runtime).

3.5 Conceptual Architecture