Purpose and Use of These Guidelines

These guidelines are provided to support the Procuring Entity in the preparation, review, and execution of the procurement process for digital transformation and information technology solutions. They are intended to serve as a practical reference based on recognized international good practices and lessons learned from similar projects.

The objective of these guidelines is to help the Procuring Entity define clear, complete, and future-proof requirements; promote fair and transparent competition; and reduce implementation, operational, and vendor lock-in risks. They provide recommendations on key considerations that are frequently overlooked during procurement planning and solution evaluation.

The guidelines are not intended to replace applicable procurement laws, regulations, policies, or internal procedures. Rather, they complement existing procurement frameworks by highlighting important technical, operational, architectural, security, interoperability, and sustainability considerations that should be assessed throughout the procurement lifecycle.

By following these recommendations, the Procuring Entity can reduce the risk of:

• Procuring solutions that do not meet long-term business needs;
• Overlooking critical interoperability, security, data governance, or scalability requirements;
• Creating dependencies on a single vendor or proprietary technology stack;
• Acquiring solutions that are difficult or costly to integrate, maintain, or extend;
• Underestimating operational, capacity-building, and change-management requirements; and
• Limiting future competition and innovation within the digital ecosystem.

The Procuring Entity remains solely responsible for all procurement decisions. These guidelines should be applied using professional judgment and adapted to the specific legal, institutional, and technical context of each procurement.

1     Definitions

Term	Description
SHALL and MUST	In this specification, the terms SHALL and MUST are used as synonyms, and both represent a mandatory requirement.
CAN	In this specification, the term CAN means that the approach referred to in the requirement is acceptable to the Buyer.
Configurable parameters and settings	Any reference to the configurable settings and parameters contained within this specification refers to the configuration via Administrator user interface, a component of the Internal portal.
E-Invoicing System (EIS)	E-Invoicing System means electronic invoicing Backend system used by tax officers to receive, control, and monitor User business transactions recorded by Invoicing Solutions interfaced to it and to generate various required reports for the purposes of tax revenue administration.
Receipt	For the purpose of this document, Invoice is equivalent to a receipt
Invoice	For the purpose of this document, Invoice is equivalent to a receipt
Document	Information unit submitted by the device, representing fiscal operation. Invoice/receipt, credit note, debit note, Z-report are different types of documents.
Device	Device is defined as a software- or hardware-based solution used to issue receipts and/or invoices and other documents and datasets as will be required by the legislative framework.
Taxpayer Information Management System	Core tax management system of the Revenue Authority.
CSV	Comma-separated values file format.
System	System refers to E-Invoicing System. When mentioned in the requirements, System refers to any component of the system which might be utilized to implement the requirement.
Standard Software	Off-the-shelf software solutions required to operate the system, including but not limited to operating systems, database management systems, backup solutions, application servers, BI solutions, etc.

2     Project Introduction

Government of ____ represented by Tax Authority intends to acquire, customize, deploy and operate Fiscal Data Management System (EIS), a solution implementing Virtual Fiscal Device concept and serving as a central hub for collection and validation of VAT related taxation data.

The Revenue Authority additionally has been mandated to collect levies on behalf of Government’s agencies. The new system must enable accurate reporting of levy collection information to the Tax Authority and be flexible to accommodate other tax and government fee types in the future.

EIS shall enable different scenarios for invoice and receipt information submission and processing by the Tax Authority, enabling taxpayer operating in retail sales (B2C) and taxpayers working with other business entities (B2B and B2G) to timely report sales and VAT amounts, different tax tariffs applied as well as other information, as will be defined in the Regulations on system use. The information collected will be utilized by the Tax Authority to monitor and enforce taxpayer compliance, as well as to provide taxpayers with timely feedback, automated VAT reconciliation and prepopulated VAT and VAT return declaration data.

An important element of the solution will be a software-based Point-of-Sale (POS) solution, which can be rolled out rapidly at no additional compliance cost to the businesses, and which will cover basic needs of most users out of the box. The POS cannot and should not be a feature-rich platform covering all business use cases. A simple feature set will reduce the support burden on MoF and will allow commercial providers space to develop their own more specialized feature-rich solutions for different market segments.

A two-phase approach will be used to introduce EIS across the country, taking into consideration the demand for a rapid launch of the system and receipt of early feedback from pilot users.

Phase I includes the core components of EIS as well as the POS solutions, which enable adoption of the solution by different groups of taxpayers. The functionalities will include registration flows and fiscal device lifecycle services, as well as the data validation and processing capabilities. It is Phase I when the datacenter infrastructure shall be established or extended to run the e-invoicing solutions.

Phase II shall focus on extended functionality, including VAT filing, VAT refund filing, reconciliation functions, integration with additional datasources and reporting and BI capabilities.

2.1     Project Introduction

The Bidder must provide details of any system, software, client, or user licensing. The expectation is that the Buyer will receive a full site license covering everything needed to run the system in _____, with no user-based costing for either internal or external users.

Detailed licensing requirements are outlined further in this document.

3     High-Level Architecture

The conceptual architecture of the system is shown in the diagram below with different types of users accessing the EIS via different channels – internal and external portals as well as an API Gateway.

Component	Description
Android POS (virtual fiscal device)	Mobile POS application for Android, for registering sales and issuing invoices. More details about this component are provided in section 4.5 Android POS.
Windows POS (virtual fiscal device)	POS application for Microsoft Windows, for registering sales and issuing invoices. More details about this component are provided in section 4.6 Windows POS.
Web POS / Invoicing App (virtual fiscal device)	A web-based application for registering sales and issuing the invoices. More details about this component are provided in section 4.7 Online Invoicing Application.
APIS for fiscal devices operations	An API for fiscal devices, virtual fiscal devices, other retail, and accounting systems, which integrates with E-Invoicing System. More details about this component are provided in 3.1 APIs and Fiscal Data Processing.
Invoice validation portal	Invoice validation portal is designed for buyers to check received invoices are they valid or not. Invoices can be validated by scanning QR code on invoice or by opening portal manually and entering required data. More details about this component are provided in 3.2 Invoice validation by buyer.
Receipt/Invoice lottery portal	A component for implementation of invoice lotteries, allowing the buyers to register their receipts for the scheduled draws, and thus allowing the buyers who registered compliant invoices to win prizes, established by the Revenue Authority. More details about this component are provided in
Self-service portal	Self-service portal is designed to be used by manufacturers, suppliers, and taxpayers for management of solutions models, solutions, incidents, orders management, and to access registered invoices of the taxpayer. More details about this component are provided in 3.5 Self-Service Portal.
Monitoring	Monitoring component is responsible for E-Invoicing System health monitoring. More details about this component are provided in 3.7 Monitoring.
BI and Reporting	BI and reporting is a component which is responsible for providing business intelligence and standard reports. More details about this component are provided in 3.6 BI and Reporting.
Internal portal	Internal portal is designed for tax officers to review data stored in the system, manage taxpayers, suppliers and manufacturers, review issued invoices, reported incidents. Internal portal is also used by administrators to change various settings and classifiers. More details about this component are provided in 3.4 Internal Portal.
Integrations	Integrations component is responsible for integrations with other systems for data exchange.
Data storage	Data storage component is responsible for storing data. It consists of Operational database and data warehouse (DWH).
Current fiscal devices / Virtual fiscal devices / other retail and accounting systems	These 3rd party devices implemented by manufacturers and used by taxpayers are designed to issue invoices. Each issued invoice must be registered in E-Invoicing System. In order to submit issued invoice to E-Invoicing System, device needs to send it using APIS for fiscal devices operations.
Tax Administration System	Tax Administration System will provide essential taxpayer registration data as well as will consume and provide tax amount related information. More details about these integrations are provided in 3.4 Internal Portal.
Active Directory	Existing Active Directory system will be used for user’s authentication when they want to login to Internal Portal.

The system is envisioned to apply modern means of security and trust via digital signatures and document trust chains. The principles introduced by the system will have to be adopted by POS solutions which will be used by the retailers to exchange fiscal information with the revenue authority.

The EIS will have a long lifetime – of at least 10 years, although it will change and evolve in that time. This means it is essential to have an architecture that can evolve as technologies and community expectations change. International and open standards must be used wherever they are applicable.

To ensure long system lifetime, it must adhere to a set of common enterprise architecture principles:

• Single source of truth
• Data integrity and consistency – keep data in perpetuity
• Compliance with standards and policies to support good governance
• Ownership of the data always remains with ___ (the country) ___
• Computerized support for all relevant stakeholders provided
• World class privacy and security ensured
• Use best practices for architecture and design of IT systems
• Ensure business continuity
• Provide highly usable systems for all users
• Allow data to be processed, reported, and shared as needed
• Systems must be supportable and maintainable over the longer term
• Be considerate of current IT and communications capability in ___ (the country) ___
• Fit into broader government IT initiatives as they evolve
• Take account of the full lifecycle of products and services

The EIS must be future proof in that it can be reasonably expected to be able to support likely changes and initiatives such as these:

• Expansion of online services offered to the public
• Expansion of the groups of taxpayers adopting the system
• Introduction of new POS solutions and technologies
• Integration with new systems
• More advanced reporting and analysis
• Ongoing changes to business processes including changes in the registration processes and entity lifecycle
• Modernization of user interfaces and adoption of new user interface technologies

Bidders must explain how they will meet these challenges and future proof the system.

4     Document Types

Each taxpayer transaction is registered to EIS using a document, which is submitted to EIS from the taxpayer’s business system via EIS API.

The following document types, representing the business transactions, must be supported by the system and are further referenced in this document:

• VAT Invoice
• Receipt (Simplified invoice) – a receipt is either an invoice issued by non-VAT taxpayer, or a cash register receipt provided to the non-VAT taxpayer
• Credit Note – partial and full credit notes are permitted
• Debit Note
• Payout document – a registration of a payout to the customer, e.g. a cash-out from a digital wallet, or return of a deposit.

5     Functional Requirements

5.1     APIs and Fiscal Data Processing

This section defines functionalities of Fiscal Data Management System’s API layers and data processing (backend) layer.

The API layer is the interface of EIS providing system-to-system access from fiscal devices, POS systems and to the E-Invoicing System.

The data processing layer is a component of the solution responsible for registration, validation and processing of the information received via API layer, and transmission of the information to the devices via the API layer.

FR-1. The API layer must ensure smooth functioning of the core flows of the system:

FR-1.1. Device registration (activation).

FR-1.2. Device communication with the E-Invoicing System for configuration and status update.

FR-1.3. Receipt/invoice submission and signing (acknowledgement by the E-Invoicing System server that invoice is received and accepted) (used by devices working in online mode).

FR-1.4. Receipt / invoice acceptance from devices working in offline mode.

FR-1.5. End of fiscal day reporting.

FR-2. The API layer must ensure secure connection between a device and EIS.

FR-2.1. The connection security must be ensured via a dual-purpose SSL certificate, issued by EIS.

FR-2.2. Transport certificate must identify device, device model and version, taxpayer.

FR-3. The API layer must provide RESTful web services with JSON payload towards devices.

FR-4. The APIs must be fully documented, and the documentation must be publicly available.

FR-4.1. The documentation must describe operational principles and principal data flows, API methods, data structure and validation rules used by the APIs.

FR-4.2. APIs shall be accessible using Swagger interface or other API online documentation tool with request, successful response message examples, possible error codes description.

FR-4.3. Additionally, the documentation shall be provided in a document format.

FR-5. The EIS must implement the device registration process.

FR-5.1. Device registration process must be based on the taxpayer and device registration records in the EIS.

FR-5.2. Device registration shall be enabled using activation keys issued by the EIS via Taxpayer Self-service portal, subject to registration of the taxpayer and device in the system.

FR-5.3. The system must ensure that Device activation key is valid only for configurable period after issuance (time-restricted).

FR-5.4. The system must ensure that Device activation key is of single-use type, however duplicate request within configurable time after initial use shall be permitted (to allow resolving internet connectivity issues).

FR-5.5. The system must ensure that all connected devices/solutions are provided with the PKI certificates for connecting to the system and digitally signing the data.

FR-5.6. There must be mechanisms in place to ensure that the certificate can be successfully downloaded after connection breakdown.

FR-6. The system must possess functionality for device certificate renewal.

FR-6.1. The system must have an effective mechanism to renew the certificates prior to their expiry.

FR-6.2. The system shall require device information and certificate signing request for which certificate shall be generated.

FR-6.3. The system must ensure that there is only 1 active certificate for a given device at a given time, and activation of a new certificate must automatically deactivate the previous certificate.

FR-7. The API Gateway must implement control of device data in the API requests.

FR-7.1. Device model name and version information must be part of the device request to the API.

FR-7.2. The API Gateway must have optional control of device model and version information. If enabled, the requests will be accepted only when model and version information match the corresponding values of device registration records.

FR-7.3. The solution must have the capability to automatically update device version record if newer version is provided in the request. This capability must be manageable by the system administrator.

FR-8. The system must allow devices to receive configuration data/settings from E-Invoicing System.

FR-8.1. The system must provide the settings via Pull-type requests initiated by the devices.

FR-8.2. The Vendor must establish jointly with the Buyer the final list of settings to be supported by EIS.

FR-8.3. The minimal set of settings is as follows:

• fiscal day (period) length,
• certificate validity period,
• information on applicable taxes (tax types and tariffs).

FR-9. The system must provide an API for devices to provide fiscal day (period) opening information.

FR-9.1. The device must provide fiscal day number and opening date when opening the fiscal day.

FR-9.2. The system must verify if fiscal day can be opened. The fiscal day can be opened only if the previous fiscal day has been closed successfully, and device has received from EIS notification of the successful closure.

FR-10. The system must provide an API for devices to initiate fiscal day closure.

FR-10.1. Fiscal day closure procedure requires submission of fiscal day counters.

FR-10.2. The Vendor must establish jointly with the Buyer the final list of fiscal counters to be supported by EIS.

FR-10.3. The minimal set of fiscal counters is as follows:

• Total sales and number of invoices,
• Number and total amount of credit notes,
• Number and total amount of debit notes,
• Currencies operated and amount by currency,
• Tax types operated and amount by tax type,
• Payment means and amounts by payment means.

FR-10.4. The system shall prevent from closing the fiscal day automatically if there are invoices/receipts with high severity level issues are submitted and not resolved.

FR-11. The system shall allow submitting B2C and B2B invoices, credit notes and debit notes via API.

FR-11.1. The API shall support one by one upload of the data collected on invoices/receipts to the backend system automatically in real time if device has good internet connection.

FR-11.2. The API shall support batch submission of data for the period not exceeding the periods configured in EIS.

FR-12. The system shall allow reporting device status via API.

FR-12.1. The devices shall be able to notify their mode of operation – online or offline.

FR-12.2. The API response shall indicate mandatory status reporting frequency to the device.

FR-12.3. The backend solution must verify timeliness of device status reports and inform users on overdue status reports.

FR-13. The system must validate any data received via APIs.

FR-13.1. There shall be synchronous and asynchronous validations.

FR-13.1. Full list of validations shall be determined during detailed system analysis phase, the minimal set of validations shall include:

• Structure of the data submitted must correspond to the predefined format,
• No submissions can be registered for the closed fiscal day.

FR-14. The system must automatically assign severity level to the validation issue.

FR-15. The system must prevent from closing fiscal period if any critical validation issues are pending.

FR-16. The system shall permit closing fiscal period with a warning if medium severity issues are pending.

FR-17. The system must implement the concept of fiscal counters.

FR-17.1. EIS must track counters of each device on a fiscal day (fiscal period) basis.

FR-17.2. Minimal set of counters to be supported are:

• sales amounts per different tax types and currencies,
• tax amounts per different tax types and currencies,
• accepted payments by different payment means and currencies,
• credit notes per different tax types and currencies,
• tax amounts in credit notes per different tax types and currencies,
• debit notes per different tax types and currencies,
• tax amounts in debit notes per different tax types and currencies.

FR-18. The system must employ digital signatures to establish trust level for the data managed by the devices and the system.

FR-18.1. EIS must apply digital signature to the validated invoices, receipts, credit/debit notes, Z-Reports. The hash value of a digital signature must be returned to the device.

FR-18.2. EIS must validate the digital signatures of the submitted invoice/receipt or another document.

FR-18.3. The digital signature of a receipt/invoice generated by the devices and verified by EIS shall be based on a hash of this information at least:

• Total amount of the receipt,
• Total amount taxes paid,
• Receipt datetime,
• Device ID,
• Receipt type,
• Currency,
• Global receipt number,
• Hash of a previous document in the change.

FR-18.4. The digital signature of a Z-report generated by the devices and verified by EIS shall be based on a hash of this information at least:

• Report datetime,
• Device ID,
• Day number,
• Fiscal day date,
• Values of the Fiscal day counters.

FR-19. The system shall implement document chain concept and be capable of validating document chains established by the devices.

FR-19.1. The system must implement a traceable receipt chain, whereas the devices are responsible for building the chain based on data of the previous and ongoing receipt in the chain.

FR-19.2. If the receipts are submitted out of chain, e.g. single receipt is submitted outside of batch file with the daily list of receipts, such receipt must be revalidated within the context of the chain (thus verifying consistency of the chain when new receipt is added).

FR-20. The system shall support batch multipart submissions from the devices.

FR-20.1. For offline device operations, the system shall be able to accept, validate and track batch files, which can be submitted in arbitrary order.

FR-20.2. The system shall be able to process multiple files for the same fiscal day (period). The system must be able to track the sequence order of the files and wait for the full set to be submitted.

FR-21. The system shall implement data reconciliation with the devices, based on fiscal day (period).

FR-21.1. The system must be able to process multiple files for the same fiscal day (period).

FR-21.2. The system must be able to track the sequence order of the files and wait for the full set to be submitted.

FR-21.3. The system must restrict the period for continuous submission of data to a single fiscal day and indicate an error if there are missing submissions based on the sequence order information.

FR-21.4. The system must have a means to identify duplicate data submissions and prevent from creating duplicate entries in the database.

FR-21.5. EIS must reconcile all the counters within the system with the counter values within the Z-report at the closure of the fiscal day.

5.2     Invoice Verification by the Buyers

This section defines functionalities of the public portal component for receipt verification and underlying data processing capabilities of the system.

Invoice validation portal’s main function is to allow users to validate received invoices, receipts, credit and debit notes issued by the taxpayers. The requirements for the device operations will include the content and structure of the QR code and textual code for manual entry, which must be present on each compliant receipt, invoice, credit note, etc.

FR-22. The receipt verification functionality must be available to non-authenticated users of the system.

FR-23. The receipt verification portal shall have configuration settings to define its behavior and notify the users if those settings are in effect.

FR23.1. It shall be possible to configure the period for which the invoices can be validated.

FR23.2. The user must be notified if the invoice being verified is older than the validation period set.

FR-24. The verification page shall allow the user to enter textual verification code from the receipt.

FR-25. The portal shall implement processing of the information provided within QR code so, that by scanning the QR code using QR code reader app (or standard camera functionality of a mobile phone), user will be redirected to this Verification page with prefilled data taken from QR code.

FR-26. The system shall find the receipt and validate it based on the code provided.

FR-27. All searches and validation results shall be saved by the system and accessible for internal users via Internal Portal and/or reporting module.

FR-28. The system shall allow verification of the receipt based on the manually entered control data values -invoice date, invoice number, amount, device ID.

FR-29. The system shall notify the user on the outcomes of the receipt validation and provide additional information:

FR-29.1. The system shall provide confirmation message and display receipt content if the receipt is found.

FR-29.2. The system shall display notification that the receipt is not found and indicate the due date to receive the receipt if the receipt is not yet received in EIS (according to the allowed threshold).

FR-29.3. The system shall display failure message if the invoice is not found in the system and submission period has expired already.

FR-29.4. The system shall display failure notification if the receipt is found but contains validation errors.

FR-30. The portal shall allow the user to submit a complaint regarding receipt issues if the data presented is incorrect or does not match the printed copy of the receipt.

FR-30.1. Complaint submission shall be initiated via ‘Report Issue’ button.

FR-30.2. There must be a complaint form available, which shall allow entering user contact details, issue description as scanned/photographed original receipt.

FR-30.3. Complaint form shall allow the user to choose the reason for the complaint, such as receipt not found, receipt total amount does not match, total amount of tax does not match, etc.

5.3     Internal Portal

The Internal Portal will be used by the tax officers to access EIS information and to manage the information according to the users’ role and permissions given. The key entities to be managed are:

• Taxpayers,
• Devices,
• Manufacturers and Suppliers,
• Device submissions: receipts, invoices, credit, and debit notes.

Internal Portal will provide tools for the administrators to manage portal users, system settings, text translations and classifiers.

FR-31. Internal Portal must provide user authentication via username and password.

FR-32. Internal Portal must support integration with Active Directory for validation of user credentials.

FR-33. Internal Portal must permit to assigned roles to the users, whereas single users may have multiple roles assigned.

FR-34. Internal Portal users permit access to the functions permitted by the roles assigned.

FR-35. The Internal Portal shall provide functionality to create different types of user accounts.

FR-35.1. Technical system user accounts shall be used for system-to-system integration.

FR-35.2. Personal user accounts shall be used by the tax officers to login to the system.

FR-36. Internal Portal shall present and manage user account information: username for all account types, name, surname and email for personal user accounts, user status.

FR-37. Internal Portal shall provide capability for the administration of user roles:

FR-37.1. It must be possible to create user roles by specifying role name.

FR-37.2. It must be possible to assign roles to the users.

FR-37.3. It must be possible to remove the role from the user.

FR-37.4. It must be possible to assign and remove specific functions (rights) to/from the role.

FR-38. Internal Portal shall provide capability to register and manage device vendors.

FR-38.1. Device vendor information shall include at least company name, company registration number, contact information, registration, and business addresses, as well as vendor status.

FR-38.2. The system must send email notifications to the related parties once the vendor status is changed. Related parties are the vendor and suppliers of vendor’s devices.

FR-38.3. There must be an API to allow vendor status management from other systems.

FR-39. Internal Portal shall provide capability to register and manage device suppliers.

FR-39.1. Device supplier information shall include at least company name, company registration number, contact information, registration, and business addresses, as well as vendor status.

FR-39.2. The system must send email notifications to the related parties once the vendor status is changed. Related parties are the vendors, working with the supplier, supplier itself and taxpayers working with the supplier.

FR-39.3. There must be an API to allow supplier status management from other systems.

FR-40. Internal Portal shall provide capability to register device models and to manage their status.

FR-40.1. Internal Portal shall support hardware and software-based device model registration.

FR-40.2. The system shall support device model registration and management when initial registration is done via Self-service Portal by the Vendor.

FR-40.3. There must be an API to allow device status management from other systems.

FR-40.4. Internal Portal shall display and manage main device information: name, version, type, subtype, manufacturer main information, supplier main information, status.

FR-40.5. The system must send email notifications to the related parties once the device model status is changed. Related parties are the vendor, supplier, and users of the devices.

FR-40.6. It must be possible to import device model information from a file.

FR-40.7. The system must control assignment of devices to the vendors and suppliers – only active vendors and suppliers can be assigned as device manufacturer and suppliers respectively.

FR-40.8. Single device model must have single device vendor.

FR-40.9. One device model may have multiple suppliers registered.

FR-40.10. The system must ensure that device models which are inactive cannot be used as devices.

FR-41. Internal Portal shall provide capability to register devices and to manage their status.

FR-41.1. Internal Portal shall support device registration by tax officers.

FR-41.2. The system shall support device registration and management when initial registration is done via Self-service Portal.

FR-41.3. There must be an API to allow device registration from other systems.

FR-41.4. Internal Portal shall display and manage main device information: id, serial number, last communication date and time, status, last fiscal day main information (status, opening/closure date and time, number), device model information, taxpayer (device user) information, location (store information, location address) where the device is being used, supplier information.

FR-41.5. Internal Portal shall allow to manage device status.

FR-41.6. There must be an API to allow device status management from another system.

FR-41.7. The system must send email notifications to the related parties once the device status is changed.

FR-41.8. The system must not accept information from the device which is not active.

FR-42. Internal Portal shall provide capability to register taxpayers and to manage their status.

FR-42.1. Internal Portal shall support taxpayer registration by tax officers.

FR-42.2. The system shall support taxpayer information import from Taxpayer Information Management System.

FR-42.3. There must be an API to allow taxpayer registration from other systems.

FR-42.4. Internal Portal shall display and manage main taxpayer information: name, company registration code, TIN, VAT taxpayer code, contact information, address information, status.

FR-42.5. The system must send email notifications to the related parties once the taxpayer status is changed.

FR-42.6. The system shall prevent carrying out activities by the taxpayer and with the taxpayer if the taxpayer status is inactive.

FR-43. Internal Portal shall allow to review device operations and submitted documents.

FR-43.1. Internal Portal shall allow to review the details of all documents which have been submitted via APIs.

FR-43.2. Internal Portal shall provide the following information about the documents:

• Document number,
• Operation date,
• Document type,
• Document validation information,
• Document validation issues, if any have been identified,
• Taxpayer (seller) information,
• Taxpayer (buyer) information,
• Device information.

FR-43.3. Internal Portal shall allow to view full document content in a print preview mode.

FR-44. Internal Portal shall allow tax officers to change the severity level of document validation issue.

FR-44.1. The change of severity level shall trigger processing of the document according to the new severity level.

FR-45. Internal Portal shall allow tax officers to review device orders submitted by the taxpayers.

FR-45.1. It must be possible to review details of the orders submitted via Self-service portal.

FR-45.2. The minimal set of information to be presented includes order number, order placement date, order status, order comments, amount ordered, device model ordered, taxpayer, supplier.

FR-46. Internal Portal shall allow tax officers to review the reports of invoice issues submitted via Invoice Validation Portal.

FR-46.1. It must be possible to review case details with the following data to be presented at least: case registration date, status, case type, description, attachments, contact information, details of related taxpayer (invoice issuer).

FR-46.2. The system must allow assigning new cases to the tax officers.

FR-46.3. The system must allow the user to release the case (change the state to unassigned).

FR-46.4. The system must allow assigned cases to be resolved.

FR-46.5. The system must send email notification to the user when the case is resolved, if contact email has been provided upon case registration via Validation Portal.

FR-46.6. The system must allow the user to enter user comment when case assignment and status are being changed.

FR-47. Internal Portal shall allow tax officers to review device-related incidents submitted by the taxpayers.

FR-47.1. The incidents must be submitted via the Self-service Portal.

FR-47.2. It must be possible to review incident details with the following data to be presented at least: incident registration date, status, incident type, description, attachments, taxpayer information, device information, supplier information and resolution information.

FR-47.3. Incidents shall have expected resolution date and time assigned.

FR-47.4. Incident resolution must be accompanied by the date, resolution commend and responsible person’s data.

FR-47.5. The system must indicate the incidents which are not resolved on time.

FR-48. Internal Portal shall allow tax officers to review the requests to extend incident resolution deadline.

FR-48.1. Internal Portal shall allow tax officers to accept and reject extension requests.

FR-48.2. The system must ask for entering decision comment upon acceptance and rejection of the extension request.

FR-49. Internal Portal shall allow users to manage system settings. The full list of system settings shall be established during the project.

FR-50. Internal Portal shall allow managing the following settings:

FR-50.1. Allowed time difference between provided receipt timestamp value and current time.

FR-50.2. Maximum fiscal day duration in hours set to taxpayer by default when taxpayer is created.

FR-50.3. Activation key expiration in minutes from its generation.

FR-50.4. Allowed time in minutes to use activation key after first successful usage.

FR-50.5. The default validity period set for a certificate during issuance of a new certificate.

FR-50.6. Remind about the forthcoming end of fiscal day before X hours.

FR-50.7. Device status reporting frequency in minutes.

FR-50.8. Allowed time in months to issue a credit or debit note after an original invoice.

FR-50.9. The threshold in days for devices operating in Online mode.

FR-50.10. The threshold in days for devices operating in Offline mode.

FR-50.11. Incident resolution status thresholds.

FR-50.12. Device model version verification mode (on/off).

FR-50.13. Period to consider device inactive.

FR-51. Internal Portal shall allow users to manage system classifiers.

FR-52. Minimal list of classifiers to be supported by the system:

FR-52.1. List of currencies.

FR-52.2. List of taxes types.

FR-52.3. List of HS codes.

FR-53. The tax type definition shall support configuration of taxes which shall be registered by taxpayers. The attributes of tax type shall include at least:

FR-53.1. Tax name (title)

FR-53.2. Type of tax – percentage or flat

FR-53.3. Tax value – percentage value or fixed amount.

FR-54. Internal Portal shall allow users to manage system text translations.

FR-55. Internal Portal shall provide access to the reports which will be built using BI and Reporting component.

FR-55.1. The system shall allow export of the reports to Microsoft Excel or CSV format.

FR-55.2. The system shall allow filtering report data using the filter fields to be agreed during the project implementation.

FR-56. Internal Portal shall allow management of device blacklist.

FR-56.1. Internal Portal shall provide function to review list blacklisted device models.

FR-56.2. Internal Portal shall allow to add and remove devices to/from the blacklist.

FR-56.3. The system shall reject any requests from the blacklisted devices and shall not allow any registration of such devices.

FR-56.4. The system must send email notifications to the related parties once the device model status is changed. Related parties are the vendor, supplier, and users of the devices.

5.4     Self-Service Portal

The Self-Service Portal will be used by all external authorized users to manage device and taxpayer related information. The user groups to be supported by the system are:

• Taxpayers – device users,
• Device manufacturers,
• Device suppliers.

The Portal shall enable all major flows supported by the system – device model registration, device registration, access to documents, incident reports, device ordering, etc.

FR-57. The Self-Service Portal shall be accessible to authorized users only.

FR-57.1. The Portal shall support username and password as authentication credentials.

FR-57.2. Self-service Portal users shall be created from Internal Portal.

FR-57.3. Upon creation of the user, temporary password for first login shall be sent via an email.

FR-57.4. Temporary password must be valid for the first login only.

FR-57.5. The system must ensure that the user creates a new password upon first login.

FR-58. The Self-Service Portal shall provide password recovery facility, which can send a new temporary password to the user’s email address.

FR-59. The system shall prevent user deletion.

FR-59.1. Removal of users shall be done as suspension of the user.

FR-59.2. Suspended users shall not be permitted to log in to the system.

FR-60. The Self-Service Portal shall ensure role-based access to the system menus.

FR-60.1. The system shall not display menus which the user does not have rights to access.

FR-61. The Self-Service Portal shall allow registering device models (accessible to device manufacturers).

FR-61.1. The Portal shall allow entering new device model information manually via dedicated form.

FR-61.2. The Portal shall allow import of device model information from Microsoft Excel of CSV file.

FR-62. The Self-Service Portal shall allow registering devices (accessible to device suppliers).

FR-62.1. The Portal shall allow entering new device information manually via dedicated form.

FR-62.2. The Portal shall allow import of device information from Microsoft Excel of CSV file.

FR-63. The Self-Service Portal shall allow reviewing information of the user’s organization and related entities – taxpayers, device manufacturers and device suppliers.

FR-64. The Self-Service Portal shall allow reviewing device stock information.

FR-64.1. Device models which do not have stock information (e.g. software-based devices) shall always be shown.

FR-64.2. Devices with stock information shall be displayed only if there are any devices in stock.

FR-65. The Self-Service Portal shall allow users to manage device stock for hardware-based devices.

FR-65.1. Stock information shall include unique device IDs.

FR-65.2. Device ordering and assignment shall assign serial number to the device.

FR-66. The Self-Service Portal shall allow reviewing information on registered devices, device operations and documents, and fiscal day information.

FR-66.1. The Portal shall provide list of devices based on the user profile:

• Taxpayers shall have access to information related to their registered devices,
• Device suppliers shall have access to information related to their supplied devices.

FR-66.2. The information shall be presented in the same way as it will be done by Internal Portal.

FR-67. The Self-Service Portal shall allow taxpayers to change their device suppliers.

FR-68. The Self-Service Portal shall allow taxpayers to submit and manage orders for devices.

FR-68.1. The taxpayers shall be entitled to submit device orders.

FR-68.2. The new order shall include device model, quantity, supplier, and order comments.

FR-68.3. The Portal shall allow reviewing of the orders and their status.

• The taxpayers shall see the orders they have submitted,
• The suppliers shall see the orders submitted to them.

FR-68.4. The suppliers shall have the possibility to accept, partially accept or reject the order.

FR-68.5. Patrial acceptance of the order is applicable to hardware-based devices only, as it is based on the availability of the devices for the delivery to the taxpayers.

FR-69. The Self-Service Portal shall provide the ability to manage incident reports.

FR-69.1. The Portal shall allow the taxpayers to submit incident reports to the Revenue Authority.

FR-69.2. The System shall automatically assign the incident resolution deadline (based on the system settings).

FR-69.3. The Portal shall allow suppliers to review the incident reports assigned to them.

FR-69.4. The Portal shall allow to reject the incident report:

• The suppliers can reject the incident reports which have been assigned to them,
• The taxpayers can reject the incident reports which they have submitted.

FR-69.5. The Portal shall allow suppliers to request extension of the incident resolution deadline.

FR-70. The Self-Service Portal shall provide the ability to review document submission issues.

FR-70.1. the Self-Service Portal shall clearly present the issues and severity levels assigned.

FR-71. The Self-Service Portal shall provide the ability to review submitted documents (invoices, credit notes, debit notes, daily reports, etc.).

FR-72. The Self-Service Portal shall provide the ability to review documents where the taxpayer is indicated as a buyer (invoices, credit notes and debit notes).

FR-73. The Self-Service Portal shall provide the ability to upload the file with documents issued by the device, so that data from devices with internet connection issues can be provided timely.

FR-74. The Self-Service Portal shall allow the users to review settings which were received by the devices.

FR-75. Internal Portal shall provide access to the reports which will be built using BI and Reporting component.

FR-75.1. The system shall allow export of the reports to Microsoft Excel or CSV format.

FR-75.2. The system shall allow filtering report data using the filter fields to be agreed during the project implementation.

5.5     Stock Management Capabilities

Ability to track the goods stock of the taxpayers is an important capability of an E-Invoicing system. It allows to map the actual stock levels to the business transaction reports and to verify the validity of such transactions. Stock Management is a cross-cutting component of an e-invoicing system, accessible via variety of modules and channels.

Unless stated otherwise, all functions below must be accessible via APIs, Self-Service Portal and Invoicing Application. Access to the functionality from Internal Portal may be restricted, with only reporting (data access) functions available to internal users.

FR-76. The EIS must support stock management capabilities with the solution.

FR-76.1. The EIS must track stock information based on a unified coding system to be defined.

FR-76.2. It must be possible to exclude specific codes and/or services from stock management reporting and monitoring scope.

FR-76.3. The EIS must track stock information based on taxpayer branches.

FR-77. The EIS must support automated adjustment of stock levels:

FR-77.1. An invoice and a debit note shall decrease seller’s stock and increase buyer’s stock.

FR-77.2. A credit note shall increase seller’s stock and decrease buyer’s stock.

FR-78. The EIS must provide means to notify the system on stock level adjustments due to transportation of goods, reallocation, destruction and manufacturing and/or repackaging of goods. This functionality must be available via API and Self-service channel.

FR-79. The EIS must provide access to the stock levels of a taxpayer by branches and by classification items.

FR-80. The EIS must be capable to exchange goods import and export information with Customs.

FR-81. The EIS shall support handling of unique goods identifiers:

FR-81.1. The EIS must allow specific goods codes as requiring entry of serial numbers. This will enable additional validation of the invoices to verify if serial numbers are provided for the goods in such marked categories.

FR-81.2. The EIS must require registering serial numbers of the goods for further tracking during stock-taking or goods transfer.

FR-81.3. For initial sourcing of goods (e.g. manufacturing or importation), the taxpayers should be able to upload list of serial numbers to be associated with specific goods.

FR-81.4. The Invoice validation must include verification if serial numbers for the goods, and verification if serial numbers are provided when mandatory, and if such serial numbers are valid (have been registered in the system).

FR-81.5. Internal Portal must allow the users to find all transactions associated with a serial number.

FR-81.6. Self-Service Portal must allow finding taxpayer’s transactions associated with a serial number.

FR-81.7. Taxpayers should have the ability to remove the serial numbers with an indication of the reason for such removal.

5.6     Android POS

The Retail Point of Sales (POS) applications for Android is an important element of the solution ecosystem, as it allows the Tax Authority to target small and medium taxpayers with a complimentary solution for e-Invoicing, which caters for all basic sales needs.

Android POS application must support most common Android devices, have a user experience familiar to the mobile phone users and must have the functionality described below.

The functionality of the POS solutions must fully comply with the requirements for the POS solutions (Technical Regulations) which will be prepared during the project.

FR-82. The POS application shall have security controls built in to prevent operation on unsecure devices.

FR-82.1. The application shall have root detection controls.

FR-82.2. If a rooted device is detected, the application shall display an error message and shall not allow to proceed further with the operations.

FR-82.3. This procedure shall be run every time the App is launched and shall prevent operation of registered POS as well as shall prevent registration of such.

FR-83. The POS application must support full device registration flow, as described in APIs section of this document, and as will be defined in POS implementation and integration guidelines.

FR-83.1. The POS application must support entry of POS user (taxpayer) data and activation key to enable the device registration.

FR-84. The POS application must support certificate renewal flow.

FR-84.1. Certificate renewal must be initiated 1 month prior to the expiry of the current certificate.

FR-84.2. Certificate renewal process must be repeated until the certificate has been downloaded and activated successfully.

FR-85. The POS application must be protected from unauthorized access by the means of application features (not related to the device security and privacy settings).

FR-85.1. The POS application must be protected with a PIN, which must be created by the user on the first use of the application.

FR-85.2. The POS application shall provide optional (upon users’ preferences) protection with the fingerprint.

FR-85.3. The POS application must feature PIN reset capability.

FR-85.4. PIN reset capability shall rely upon taxpayer contact information to provide reset links.

FR-86. The application must provide access to Usage Terms & Conditions information.

FR-86.1. Terms & Conditions must be presented and agreed to by the user prior to the application registration.

FR-86.2. Terms & Conditions must be accessible on-demand via the application menu.

FR-87. The application must provide functionality to review account information which is stored in EIS and is provided based on device assignment to the taxpayer.

FR-88. The application must create a master user upon first registration.

FR-89. All user accounts shall be per taxpayer; they shall be stored centrally and accessible from all POS devices of a taxpayer.

FR-90. Master user shall be offered following functions via the application:

FR-90.1. Create new user

FR-90.2. Review list of registered users

FR-90.3. Block user

FR-90.4. Activate user

FR-90.5. Update user details

FR-91. The application shall allow each user to update his/her email address and phone number.

FR-92. The application must support fiscal day information flow according to the POS requirements.

FR-92.1. The application must provide capability to open fiscal day.

FR-92.2. The application must provide capability to close fiscal day and submit all the receipts and Z-report to the EIS.

FR-92.2. The application must provide notifications to the user about the upcoming end of the fiscal day.

FR-92.4. The application must provide notifications to the user about pending closure of the fiscal day.

FR-93. The application must allow the user to issue a receipt.

FR-93.1. The application must permit this action only when the fiscal day is open.

FR-93.2. The application must allow the user to add the receipt lines manually.

FR-93.3. The application must allow the user to add receipt lines based on items from the product list.

FR-93.4. The application must allow the user to issue a receipt by scanning item barcode using device barcode scanner or an attached barcode scanner.

FR-93.5. The application must allow the user to add and remove the receipt lines.

FR-93.6. The application must allow the user to add itemized and total discounts, which do not exceed item and receipt value respectively.

FR-93.7. The application must allow the user to specify the tax type applicable to the receipt line.

FR-93.8. The application must calculate the receipt totals.

FR-93.9. The application must allow the user to add buyer information manually.

FR-93.10. The application must allow the user to add a buyer from the list of buyers.

FR-93.11. The application must allow the user to specify payment method used to pay for the invoice, e.g. cash, card, bank transfer, etc.

FR-93.12. The application must register and digitally sign the receipt.

FR-94. The application must allow the user to issue a credit note and a debit note based on the receipt.

FR-94.1. The application must permit this action only when the fiscal day is open.

FR-94.2. All POS regulations relevant for credit and debit notes must be implemented accordingly.

FR-94.3. Partial and full credit notes shall be validated against the amount of the invoice being credited.

FR-95. The application must implement the receipt chain logic as prescribed by the POS regulations.

FR-96. The application must implement fiscal counters, as defined by the APIs section of this document and as prescribed by the POS regulations.

FR-97. The application must allow the user to review receipt details immediately after the receipt has been issued and at any arbitrary time.

FR-98. The application must allow the user to send the receipt to the buyer using the operating system’s standard file sharing capabilities.

FR-99. The application must allow the user to print the receipt using the connected printer (if any is available).

FR-100. The application must allow the user to import products and buyers lists from a Microsoft Excel file. The file structure shall be established during detailed system analysis.

FR-101. The application must allow the user to export products and buyers lists to the Microsoft Excel files.

FR-102. The application must allow the user to enter and manage products list and buyers list manually.

FR-103. The application must allow the user to create a list of available currencies. This should be restricted to the currency values supported by the EIS configuration.

FR-104. The application must allow the user to review fiscal day reports.

FR-104.1. The user must be able to review the total net sales, total amounts of tax by tax type, total gross sales, total quantities of documents issued.

FR-105. The application must allow the user to share the report using operating system’s standard file sharing features.

FR-106. The application must allow the user to print the report using the connected printer (if any is available).

5.7     Windows POS

The Retail Point of Sales (POS) applications for Windows are an important element of the solution ecosystem, as they allow the Tax Authority to target MSME group taxpayers with a complimentary solution for e-Invoicing, which caters for all basic sales needs. Windows POS application must support most common Microsoft Windows operating system versions and present familiar experience for desktop-based POS users.

The functionality of the POS solutions must fully comply with the requirements for the POS solutions which will be prepared during the project.

FR-107. The POS application must support full device registration flow, as described in APIs section of this document, and as will be defined in POS implementation and integration guidelines.

FR-107.1. The POS application must support entry of POS user (taxpayer) data and activation key to enable the device registration.

FR-108. The POS application must support certificate renewal flow.

FR-108.1. Certificate renewal must be initiated 1 month prior to the expiry of the current certificate.

FR-108.2. Certificate renewal process must be repeated until the certificate has been downloaded and activated successfully.

FR-109. The POS application must be protected from unauthorized access by the means of application features (not related to the device security and privacy settings).

FR-109.1. The POS application must be protected with a password, which must be created by the user on the first use of the application.

FR-109.2. The POS application must feature password reset capability, which should be start automatically after configured number of incorrect attempts has been done.

FR-109.3. Password reset capability shall rely upon taxpayer contact information to provide reset links.

FR-110. The application must provide access to Usage Terms & Conditions information.

FR-110.1. Terms & Conditions must be presented and agreed to by the user prior to the application registration.

FR-110.2. Terms & Conditions must be accessible on-demand via the application menu.

FR-111. The application must provide functionality to review account information which is stored in EIS and is provided based on device assignment to the taxpayer.

FR-112. All user accounts shall be per taxpayer; they shall be stored centrally and accessible from all POS devices of a taxpayer.

FR-113. Master user shall be offered following functions via the application:

FR-113.1. Create new user

FR-113.2. Review list of registered users

FR-113.3. Block user

FR-113.4. Activate user

FR-113.5. Update user details

FR-114. The application must support fiscal day information flow according to the POS requirements.

FR-114.1. The application must provide capability to open fiscal day.

FR-114.2. The application must provide capability to close fiscal day and submit all the receipts and Z-report to the EIS.

FR-114.3. The application must provide notifications to the user about the upcoming end of the fiscal day.

FR-114.4. The application must provide notifications to the user about pending closure of the fiscal day.

FR-115. The application must allow the user to issue a receipt.

FR-115.1. The application must permit this action only when the fiscal day is open.

FR-115.2. The application must allow the user to add the receipt lines manually.

FR-115.3. The application must allow the user to add receipt lines based on items from the product list.

FR-115.4. The application must allow the user to issue a receipt by scanning item barcode using device barcode scanner or an attached barcode scanner.

FR-115.5. The application must allow the user to add and remove the receipt lines.

FR-115.6. The application must allow the user to specify the tax type applicable to the receipt line.

FR-115.7. The application must allow to add per-item and total discounts.

FR-115.8. The application must calculate the receipt totals.

FR-115.9. The application must verify that discounts do not exceed the amounts being discounted.

FR-115.10. The application must allow the user to add buyer information manually.

FR-115.11. The application must allow the user to add a buyer from the list of buyers.

FR-115.12. The application must allow the user to specify the payment method used.

FR-115.13. The application must register and digitally sign the receipt.

FR-116. The application must allow the user to issue a credit note and a debit note based on the receipt.

FR-116.1. The application must permit this action only when the fiscal day is open.

FR-116.2. All POS regulations relevant for credit and debit notes must be implemented accordingly.

FR-116.3. Partial and full credit notes shall be validated against the amount of the invoice being credited.

FR-117. The application must implement the receipt chain logic as prescribed by the POS regulations.

FR-118. The application must implement fiscal counters, as defined by the APIs section of this document and as prescribed by the POS regulations.

FR-119. The application must allow the user to review receipt details immediately after the receipt has been issued and at any arbitrary time.

FR-120. The application must allow the user to send the receipt to the buyer using the operating system’s standard file sharing capabilities.

FR-121. The application must allow the user to print the receipt using the connected printer (if any is available).

FR-122. The application must allow the user to import products and buyers lists from a Microsoft Excel file. The file structure shall be established during detailed system analysis.

FR-123. The application must allow the user to export products and buyers lists to the Microsoft Excel files.

FR-124. The application must allow the user to enter and manage products list and buyers list manually.

FR-125. The application must allow the user to create a list of available currencies. This should be restricted to the currency values supported by the EIS configuration.

FR-126. The application must allow the user to review fiscal day reports.

FR-126.1. The user must be able to review the total net sales, total amounts of tax by tax type, total gross sales, total quantities of documents issued.

FR-127. The application must allow the user to share the report using operating system’s standard file sharing features.

FR-128. The application must allow the user to print the report using the connected printer (if any is available).

5.8     Online Invoicing Application

The Online Invoicing Application shall be a web-based invoicing application, fully integrated with EIS, manageable via Self-Service Portal. The target users for Online Invoicing Application are small businesses operating in areas with decent to good internet connectivity and having any web-browser capable device to register the business transactions.

The functionality of the Online Invoicing Application solutions must fully comply with the requirements for the POS solutions which will be prepared during the project.

FR-129. Management functions of the Online Invoicing Application shall be integrated into Self-Service Portal (Portal) of EIS.

FR-130. The Portal shall allow a user to register a new Online Invoicing Application for the taxpayer they represent.

FR-131. Online Invoicing Application must be and assigned to the registered taxpayer’s branch during registration.

FR-132. It must be possible to create a user for online invoicing application by entering user credentials (username, password) and contact details (email, phone) via the Portal.

FR-133. It must be possible to view list of users of online invoicing applications and modify user details via the Portal.

FR-134. It must be possible to block and activate online invoicing application users via the Portal.

FR-135. It must be possible to review the product list and edit product information (name and barcode) via the Portal

FR-136. It must be possible to create a new product in a product list and remove a product from the list via the Portal.

FR-137. It must be possible to export product list from the Portal into CSV file format.

FR-138. It must be possible to import product list from CSV file format into the Portal.

FR-139. It must be possible to review and update the list of buyers via the Portal.

FR-140. It must be possible to export list of buyers from the Portal into CSV file format.

FR-141. It must be possible to import list of buyers from CSV file format into the Portal.

FR-142. The Online Invoicing Application (Application) shall require users to login first time using users’s credentials and unique application registration ID.

FR-143. Online Invoicing Application shall allow only users created via Portal to connect. The Self-Service Portal user accounts shall not be accepted by the Online Invoicing Application.

FR-144. The user must be requested to confirm the contact details upon first login to the Application.

FR-145. The user must be provided with a password reset feature utilising OTP via any of the user contact options.

FR-146. The user must be able to change the password in the Application.

FR-147. The user must be able to change the taxpayer’s branch to which the Application is assigned by choosing the branch from the list of registered branches.

FR-148. The Application must allow the user to open a fiscal day.

FR-149. The Application must allow the user to close the fiscal day.

FR-150. The application shall close the fiscal day automatically once the fiscal day duration has been lapsed and there are no connected users.

FR-151. The application must allow the user to issue an invoice.

FR-151.1. The application must permit this action only when the fiscal day is open.

FR-151.2. The application must allow the user to add the receipt lines manually.

FR-151.3. The application must allow the user to add receipt lines based on items from the product list.

FR-151.4. The application must allow the user to add and remove the receipt lines.

FR-151.5. The application must allow the user to specify the tax type applicable to the receipt line.

FR-151.6. The application must allow to add per-item and total discounts.

FR-151.7. The application must calculate the receipt totals.

FR-151.8. The application must verify that discounts do not exceed the amounts being discounted.

FR-151.9. The application must allow the user to add buyer information manually.

FR-151.10. The application must allow the user to add a buyer from the list of buyers.

FR-151.11. The application must allow the user to specify the payment method used.

FR-151.12. The application must register and digitally sign the receipt.

FR-152. The application must allow the user to issue a credit note and a debit note based on the receipt.

FR-152.1. The application must permit this action only when the fiscal day is open.

FR-152.2. All POS regulations relevant for credit and debit notes must be implemented accordingly.

FR-152.3. Partial and full credit notes shall be validated against the amount of the invoice being credited.

FR-153. The application must implement the receipt chain logic as prescribed by the POS regulations.

FR-154. The application must implement fiscal counters, as defined by the APIs section of this document and as prescribed by the POS regulations.

FR-155. The application must allow the user to review fiscal day reports.

FR-155.1. The user must be able to review the total net sales, total amounts of tax by tax type, total gross sales, total quantities of documents issued.

FR-156. The application must allow the user to share the save or download the report.

FR-157. The application must allow the user to print the report using the connected printer (if any is available).

5.9     Invoice Lottery Application

This section defines functionalities of the components implementing receipt/invoice draws (lotteries). Receipt lotteries will play an important role in the education of the population and explaining the importance of asking for a valid fiscal receipt or an invoice.

To serve its purpose, the Lotter Application shall feature random selection of the winners, registration and management of participant data, and management of drawing process.

FR-158. The solution shall allow to define lottery schedules – weekly, bi-weekly, monthly.

FR-159. The solution must allow running several lotteries in parallel (based on different schedules or different selection criteria).

FR-160. The draw period must always start at 0:00 on the first day of the period and end at 23:59 on the last day of the period.

FR-161. The draw shall be based on random number generator, which will be used to select the winning receipts.

FR-162. The solution must allow to define and edit a lottery. The following configuration parameters and rules must be supported:

FR-162.1. It must be possible to specify the name of the lottery.

FR-162.2. It must be possible to specify the description of the lottery.

FR-162.3. It must be possible to specify whether a receipt, which won in a draw is eligible for a parallel lottery.

FR-162.4. It must be possible to specify number of winners per lottery draw.

FR-162.5. It must be possible to configure criteria for eligible receipts: minimal and maximal amount, business type of the taxpayer, tax tariff included.

FR-162.6. It must be possible to specify the winning payout period.

FR-162.7. It must be possible to define the schedule of draws (or enable manual draws).

FR-163. The solution must be accessible via and integrated with the Receipt Verification Portal.

FR-164. Registration shall be available for any invoice which has passed the verification or is pending invoice registration in E-Invoicing.

FR-164.1. If an invoice pending verification has been submitted for the lottery, the entry will be valid only if the invoice has been submitted by the vendor and the verification has been successful.

FR-164.2. If invoice verification fails or invoice is not submitted to the system on time, the user shall be notified of such failure.

FR-165. The following rules shall apply for the lottery registration process:

FR-165.1. Registration for participation in the lottery draw shall be optional.

FR-165.2. User/buyer must provide his email address and/or phone number for successful registration.

FR-165.3. The user must have possibility to review the Terms & Conditions of the lottery and participation.

FR-165.4. The user must confirm that he agrees with the Terms & Conditions.

FR-165.5. The user must confirm that the email/phone number he provided are correct.

FR-166. Each participating invoice shall get a unique internal lottery ID assigned.

FR-167. There must be a dedicated page for receipt lotteries, accessible to the unauthenticated users.

FR-168. The page shall provide information on ongoing lotteries and receipt/invoice inclusion and validity rules.

FR-169. The page must contain the draw schedule and list of winners.

FR-170. Draw winner information shall include invoice identification numbers, the last 4 digits of the winner’s phone number or first 4 letters of the winner’s email address (based on what data was submitted by the participant) and the data of the receipt, so that fraudulent winner claims can be rejected.

FR-171. Internal users shall be able to review all invoice registration data, including emails/phone numbers, invoice IDs, unique IDs assigned by the lottery module, registration date and time, invoice submission time

FR-172. There shall be configurable user roles, based on combination of functions below:

FR-172.1. search invoices registered for the lottery by phone number, email, automatically assigned unique number and date and time of lottery registration.

FR-172.2. review of data on selected winning receipts, confirmation of the compliance of the winning receipt with the Lottery conditions.

FR-172.3. confirm the winning invoice or reject a winning invoice if it is determined that the winnings cannot be paid out (sample reasons for a rejection – it was established that the person who filled out the application for payment of the winnings on behalf of the player whose registered receipt has been drawn in the Lottery is not a parent, guardian or authorized person; the winner of the Lottery did not come to the Revenue authority to submit a request to pay out the winnings; it was determined that the invoice was submitted by the seller).

FR-172.4. review the list of winning invoices,

FR-172.5. confirm decision on winning invoice,

FR-172.6. confirm decision on ineligibility of the invoice for payout,

FR-172.7. review all invoices submitted for the lottery, including grouping by period,

FR-172.8. extend payout period for a winning,

FR-172.9. review lottery statistics (invoice registrations by period),

FR-172.10. enter confirmation of the payout,

FR-172.11. review the winnings by payout date and deadline, including filtering of paid out/unpaid winnings.

5.10     BI and Reporting

BI and Reporting module will be used for creating, managing, and presenting reports on EIS data. The module shall operate consume the data from Data Warehouse only, so that reporting does not influence the performance of the Operational database all functional system components.

The reports defined in the system will be accessible via Internal Portal and Self-Service Portal, subject to permissions assigned to the report.

The module shall have capability to provide standard reports (detailed itemized reports) and BI reports operating aggregated data.

FR-173. The System shall allow creating different kinds of reports and charts used for decision-making.

FR-174. All reports shall be exportable to Microsoft Excel and PDF formats.

FR-175. The System shall contain data analysis capabilities and allow users to set up data-driven alerts based on parameters to be agreed during the design phase.

FR-176. The System shall allow the internal users to create custom reports and customize existing reports.

FR-177. The System must provide Sales invoice and Purchase invoice reports on a taxpayer level.

FR-178. The System shall allow users to choose a period and check invoices with abnormalities/errors in that period.

FR-179. The System shall provide a report on invoice validation using the Invoice Validation Portal.

FR-180. The System shall provide a report on device errors when using APIs.

FR-181. The System shall provide a report on online and offline devices and device offline operation periods.

FR-181.1. The report shall be based on the usage of the APIs for device operations.

FR-181.2. The system shall consider a device being offline if the device did not call any APIs within predefined period.

5.11     Common Business Requirements

5.11.1     Currency

FR-182. The solution must operate in a single-currency mode. All transactions can be registered in XXX only.

FR-183. The solution must support multiple currencies.

FR-183.1. Internal portal shall allow the users to identify which currencies can be used in the data submitted to the system.

FR-183.2. Validations shall include validation of currencies used in transaction reporting – only permitted currencies can be used by the devices.

FR-183.3. All transaction data must be kept in their original format.

FR-183.4. EIS must be integrated with _______ to retrieve currency exchange rates for reporting purposes.

FR-183.5. EIS must store historical currency rates so that the currency conversions for calculating amounts in selected currency are done using a currency rate applied for a specific date.

5.11.2     Audit Trail

FR-184. All user activities within the system which have impact on the system data must be logged in an audit trail.

FR-185. Log records shall identify the user, contain the timestamp of the event, and event type at least with relevant event data provided as well.

6     Non-Functional Requirements

6.1     Architecture

FR-186. The EIS must be based on Service-Oriented Architecture patterns.

FR-186.1. The use of microservices and containerization approaches is highly endorsed.

FR-187. There shall be clear separation of solution tiers into user interface, business layer (functional and data access) and data layer.

FR-188. The EIS must support horizontal scalability thus allowing to distribute workloads across different servers and data centers.

FR-189. The EIS must support vertical scalability patterns.

FR-190. The EIS must be set up in high-availability mode.

FR-191. The EIS must feature component robustness, thus errors in one functional component shall not cause disruption of the operations of the whole system.

FR-192. The EIS must operate on containerization platform.

6.2     Operating Systems

FR-193. The system (server) must operate on Linux operating systems.

FR-194. The Android POS must support the current and 2 previous versions of Android OS, as of date of signing the agreement.

FR-195. The Windows POS version must support Windows 11 and newer versions of Microsoft Windows, if any are available.

6.3     Databases

FR-196. The EIS must rely on relational databases for data and information processing and storage. Preferred databased are MySQL Enterprise Edition, Oracle, Postgre DB.

FR-197. The database must be set up in high-availability deployment.

FR-198. Data must be stored and presented using Unicode UTF-8 encoding.

FR-199. There must be separation of operational database and data warehouse.

FR-199.1. The System must implement automated transfer of data from operational database into Data Warehouse.

FR-199.2. All reporting and BI components must use Data Warehouse as their data source.

6.4     Licensing and Source Code Ownership

FR-200. EIS shall rely on an industry-proven platform.

FR-201. If EIS is a licensed solution, the following licensing terms shall apply:

FR-201.1. The Buyer shall get perpetual license for the solution.

FR-201.2. The license must not limit the number of internal and external users nor can be limited in any other way which will prevent scaling the system to support more taxpayers and larger data volumes.

FR-201.3. The license must be valid for up to 3 Buyer’s environments.

FR-202. EIS can rely on 3rd party standard software and frameworks, given that the following requirements are met:

FR-202.1. If any licensed standard software is required to ensure operation of EIS in compliance with the architecture and performance requirements, the cost of licenses, including not less than 3 years of support and maintenance shall be included into the financial proposal, and such licenses shall be clearly indicated in the technical proposal.

FR-202.2. If any open-source software is required to ensure operation of EIS, such software must have commercial support available.

FR-202.3. The proposal shall include 3 years of commercial support for the open-source software proposed.

FR-202.4. The licenses for standard software must be sized to support 3 customer environments: Testing, Pre-production, Production.

FR-203. The Bidder must confirm readiness to provide the source code of the EIS solution, whereas the following conditions shall apply:

• The source code must be provided for the whole system, except 3^rd-party components.
• The source code must be provided at the end of the implementation project, with additional delivery of the source code at the end of the Annual Maintenance Contract.
• The source code cannot be used by the Customer to create competing or derivative solutions and can be used only within the Customer’s environments.
• The source code will be provided as confidential material and the Customer will ensure proper sensitivity labelling of such source code. The source code can be disclosed to the 3^rd parties only if such 3^rd parties are contracted by the Customer for the purpose of further extending, modifying or supporting the solution.

6.5     Performance

FR-204. The EIS must be capable to manage the workloads as per projection below without modifications to the system:

	Y+0	Y+1	Y+2	Y+3	Y+4
External users via Self-service portal	5.000	17.000	40.000	70.000	100.000
Concurrent external users	1.000	2.000	4.000	7.000	10.000
External users (devices/solutions) via API	5.000	25.000	100.000	400.000	800.000
Concurrent API users (requests within 1 minute)	500	2.000	10.000	25.000	50.000
Internal portal users	…	…	…	…	…
Concurrent internal users	…	…	…	…	…
# of invoices and other documents per year	200.000.000	1.000.000.000	4.000.000.000	16.000.000.000	40.000.000.000

FR-205. The EIS must provide response to 80% of the data-related calls (search, filtering, grouping, sorting of the data by taxpayer, period, etc.) within 3 seconds.

FR-206. The EIS must provide response to 80% of the portal navigation requests within 1 second.

FR-207. The EIS must meet zero data loss requirement.

6.6     Security Policy

FR-208. The system must use Privacy by Design principles, ensuring that no person or system is trusted.

FR-209. The EIS shall strictly adhere to the Buyer’s ICT Policy and Application Security Standard. The solution must have standard security features to ensure confidentiality and integrity of data. The External Partner shall ensure that the solution is secure such that it will not expose other systems it will integrate with. The solution shall be scanned for vulnerabilities, and it is the responsibility of External Partner to fix issues discovered.

FR-210. The EIS must implement Roles-based Access Controls (RBAC). The definition of roles (naming and specific rights/functions assigned to the role) shall be fully configurable by the system administrator and provide fine-grained permission control.

FR-211. The functions accessible to non-authenticated users must have DDOS protection features, e.g. CAPTCHA. The Bidder must offer the suitable means of protection.

FR-212. The EIS must not store any passwords in plain text nor in an encrypted form which allows to decrypt the password value.

6.7     Data Security

FR-213. The EIS must support secure connections using TLS1.3.

FR-214. For encryption and digital signatures, the following algorithms and key types shall be supported:

• ECC ECDSA on SECG secp256r1 curve (also named as ANSI prime256v1, NIST P-256); signature algorithm: ecdsa-with-SHA256.
• RSA 2048; signature algorithm – SHA256WithRSA.

6.8     System Backup

FR-215. The system shall have backup and archiving features to facilitate maintenance and upgrading requirements.

6.9     Integrations

FR-216. All integrations with the internal systems must rely on available integration specifications if available.

FR-217. All new integrations must be documented, and the implemented interfaces/APIs must not restrict the Buyer from using them as required.

FR-218. For any APIs to be provided by the system, they must follow REST API standards and support JSON payload.

6.10     Monitoring

FR-219. Health monitoring of Fiscal Data Management System shall be implemented using Zabbix or equivalent solution.

FR-220. The monitoring solution shall track standard operating system, database, and network metrics for EIS infrastructure platform.

FR-221. The monitoring solution shall monitor API availability and response times.

FR-222. The monitoring solution shall track custom metrics, which will be agreed upon during the project implementation and the means for receiving the data will be provided.

FR-223. The monitoring solution shall be able to monitor system process health, by measuring request processing time within the system. The Bidder shall propose the method and tools required for such measurement.

FR-223.1. System process health measurement shall provide evidence that all system layers are operating successfully, including APIs, business logic layer and database layer.

FR-223.2. Integration health assessment shall be done if there will be critical integrations for FDSM operations.

6.11     Logging

FR-224. Logs shall be recorded in real time.

FR-225. The log review tool shall be easily understandable, created using best practices, with the ability to filter data and export logs to Microsoft Excel.

6.12     Data entry

FR-226. The system shall notify the users if any mandatory data entry fields are missing.

FR-227. The system shall provide placeholders in the data entry fields, which allow to understand the expected field context.

FR-228. Wherever a new data record is being made, the system shall assign a unique record identifier automatically.

6.13     Data integrity

FR-228. The EIS must ensure the integrity and confidentiality of the transmitted and received data, that the data from being distorted or illegitimately disclosed during its transmission.

6.14     User interface and User experience

FR-230. The portals must feature multi-lingual interfaces, support English and ___ at least.

FR-230.1. The System must offer English language interfaces.

FR-230.2. The System must provide tools for translation of texts visible to the users (internal and external).

FR-230.3. The Portals must provide users with the ability to choose the preferred language.

FR-231. External portals shall be easily accessible from smartphones.

FR-232. The portals must operate on all major web browsers – Microsoft Edge, Mozilla Firefox, Google Chrome, Apple Safari, Opera Browser.

FR-233. The data can be submitted via form to the system only if all mandatory data fields have been filled in.

FR-234. The portals shall feature responsive design, and thus be able to function on different screen form factors and resolutions.

FR-235. The portals shall provide online help capability, whereas function help is displayed in a respective window and specific fields can have their help information.

FR-236. All lists presented in Internal and Self-service portals must have filtering options based on the main fields of the list.

FR-237. It shall be possible to filter list data by multiple fields simultaneously.

FR-238. All lists shall support list data sorting based on the main fields.

7     Advisory Services

The Supplier shall deliver advisory services in the following areas to support the Buyer:

• Legal Advisory
• Operational Capacity Building
• Change Management and Capacity Building

7.1     Legal Advisory

AR-1. Legal advisory shall focus on the regulatory aspects of the introduction of e-Invoicing system.

AR-2. The Supplier shall review the existing primary and secondary legislation and formulate proposed legislative changes pursuant to introduction of e-Invoicing system. It is expected that the supplier will base the recommendations according to relevant practices abroad.

AR-3. The Supplier shall assist the Buyer in defining and setting up the certification schema for the devices, if any.

AR-4. The Supplier shall assist the Buyer in defining and setting up device registration schema.

AR-5. The Supplier shall assist the Buyer in defining the requirements for legally compliant fiscal devices, including mandatory operations, reporting and information registration standards. These requirements shall be based on the requirements to implement APIs for fiscal devices operations and shall define what are the mandatory capabilities of such devices.

AR-6. Based on the approved regulations and requirements, the Supplier shall prepare the following:

• Registration (accreditation) form templates
• Supplier self-assessment checklist/API compliance checklist

7.2     Operational Capacity Building

AR-7. The Supplier shall facilitate definition of the operational model of E-Invoicing.

AR-8. The Supplier shall facilitate orientation workshops for the Revenue Authority, focused on key concepts in E-Invoicing, best practices in E-Invoicing implementation and operations and key capabilities of EIS.

AR-9. The Supplier shall conduct business process, and operating procedures review to identify necessary changes in the current organizational and process model, which will be required to support e-Invoicing implementation. This includes the identification of all relevant internal/external stakeholders involved in the processes.

AR-10. The Supplier shall prepare and validate a training plan based operational model and operating procedures, identify target groups and conduct system trainings for the Revenue Authority employees.

AR-11. The Supplier shall support the Buyer in defining engagement and compliance enforcement strategies for the e-Invoicing based on the data collected by a newly developed digital solution.

AR-12. The Supplier shall define data quality assurance plan and provide recommendations to align data operations of EIS with the Data Governance Framework of the Revenue Authority.

AR-13. Technical capacity building requirement

7.3     Change Management and Capacity Building

AR-14. The Supplier shall support the Buyer in defining the scope and impact changes required and preparing change management plan and structure, according to a dedicated methodology that includes clear understanding how the supplier will support stakeholder management, leadership alignment, and resistance management during change management process, The change management plan shall address internal and external change management needs.

AR-15. The Supplier shall assign staff that will continuously support strong ownership and leadership of the newly introduced digital solution inside the organization, including early and continuous involvement of internal stakeholders to have full support for system implementation and change management activities.

AR-16. The Supplier shall support pilot solution user groups – pilot users for Mobile/Windows/Online POS solution, as well as the pilot device suppliers.

AR-17. The Supplier shall support preparation of the stakeholder engagement plan to ensure timely launch of the solution and market readiness. This activity includes engagement with external stakeholders – taxpayers and solution providers – to ensure timely readiness for the use of the digital solution.

AR-18. The Supplier shall prepare a training plan for workshops and trainings sessions to transmit and share subject specific knowledge and capacities throughout the implementation of the project.

8     Project Requirements

PM-1. The project shall be structured into 3 development and delivery phases followed by support and maintenance.

PM-2. The total project duration shall not exceed 18 months.

PM-3. Phase I shall be preceded by the Project Inception phase. The duration for the Inception phase is set to 1 month.

PM-4. Phase I shall encompass implementation of core functionalities of the system and launch of the system.

PM-5. The duration of Phase I activities shall not exceed 7 months, including launch of the system.

PM-6. The Bidder is responsible for the implementation of the system. Systems implementation is the process of defining how the information system should be built (i.e., physical system design), ensuring that the information system is operational, ensuring that the information system meets quality standards and is secure. Implementation activities include architecture verification, process verification, test deployment, production deployment, training provision, support for penetration testing.

PM-7. The Bidder shall provide a project plan outline reflecting implementation activities and Advisory services.

PM-8. The Bidder must provide the technical documents of the system configuration and development such as API document, database design document, data dictionary, application coding architecture document, service configuration, etc.

PM-9. The Bidder must define the deliverables for the project. The list of deliverables per activity and phase and their description shall be indicated in the proposal and aligned with the proposed project plan.

PM-10. The System Delivery activity shall encompass the development and configuration and deployment of a fully functional system for acceptance.

PM-11. The indicative list of deliverables for the System Delivery includes:

• EIS deployed to the Buyers’ environments as per agreement
• Detailed functional specifications of the system, as per definition of a respective phase
• High-level process maps and flow descriptions
• Integrations to identified external systems
• Configure the system to support each operational flow
• Configure the roles to support all user types
• Updated release based on UAT ready for Phase to commence
• Weekly, monthly, and quarterly meetings to review the project status
• Report on the development and configuration and deployment of a fully functional system for acceptance
• System reports and dashboards
• Training of Tax Authority employees, split by different roles (infrastructure administration, system administration, customer services, monitoring)
• Support for pilot POS users and integrators of APIs.

PM-12. The Bidder shall actively support User Acceptance Testing, including providing a complete set of test scenarios. The Buyer will augment these with their operationally focused test scenarios and provide testers as needed.

PM-13. The Bidder must have support in place to fix critical defects during UAT to allow it to proceed.

PM-14. The Bidder must provide system support and maintenance services.

PM-15. The Bidder’s proposal shall include proposed scope of support and maintenance services, including the SLA and presenting cost and scope options for these scenarios:

• Corrective support and maintenance of the system (issue resolution)
• Preventive support and maintenance of the system
• System monitoring and support
• System enhancement services (up to 2.000 hours annually)
• Capacity building for the internal team

PM-16. The final SLA for such services shall be agreed upon during the Inception phase.

9     Proposal Requirements

Provide item-by-item commentary of the requirements or provide commentary for essential requirements only. Indicate whether the functionality is available out of the box (for better scoring).

Provide description of proposal advisory services approach. Indicate how long each stage of advisory services will take.

Provide proposed project plan and fit advisory services into overall project planning.

Demonstration of system:

• System demo including at least one POS option – 60 – 100 points (subject to quality of demo and specific functions to be shown)
• System demo without a POS option – 40 – 60 points
• Prototype-level demo – 20 – 40 points
• Mockup (visual prototypes of the system) – 0 – 20 points