Main Calculations

Main calculations are list of predefined validation checks and calculations required to check the validity of receipt content before submitting the receipt.

Click here to view validation rules for all the field values.

Local Validations

The following validations can be done offline on the receipts before storing them locally:

Validation of receipt/return receipt base structure

Validation of the issued document type version to check its structure matching what is required by the document type version. (Only JSON format supported). The structure will be checked against the receipt base structure.

Code Validator

Code validator enables validation of various codes used in issued documents to make sure they are referencing valid codes, for example Payment Methods, Currency Codes, Tax Types, Tax SubTypes, GS1, EGS, Unit Types, Activity Codes, buyer Types, Order Delivery Mode, Branches Codes, allowed receipt types for taxpayer as per activity code.

Code validator depends on cache of code table information that allows it to validate the documents quicker.

Note: System must validate goods and services codes used by the taxpayer against goods and services codes defined for usage by the taxpayer (if access to APIs to retrieve and cache this information is available)

Core Fields Validator

Core fields validator is used to validate that the receipt contains at least the main fields that any receipt should have to be processed by the system.

Core fields validation rules:

1. tax type must be unique
2. issuer Id must be the same in the token (submitter of the document must be the issuer)
3. issuer Id is required
4. issuer name is required
5. receiver type is required
6. if receiver type is not [P], receiver id is required
7. if receiver type is not [P], receiver name is required
8. document type is required
9. document type version is required
10. internal id is required
11. issuance date time format must be valid
12. issuance date time can’t be in the future
13. issuance date time value must be in the range of submission workflow parameter unless the ReferenceOldUUID is provided
14. ReferenceOldUUID cannot be equal to the UUID
15. receiver type is [B], issuer and receiver can’t be the same
16. issuer branch id is required
17. if currency is not EGP, currency exchange rate is required, else, currency exchange rate is not required
18. issuer id owning the POS is the same issuer in the receipt
19. POS is allowed to submit at the time of receipt issuance
20. taxpayer is allowed to submit using the submission channel
21. reference sales receipt can’t be supplied for the document type [s]
22. document UUID is 64 alphanumeric string that is a valid hash of the content of the serialized receipt with all content excluding the UUID itself.
23. document previous UUID is a 64 alphanumeric string
24. if submitted by a POS, validate that all receipts within the submission are issued by the same POS

National ID Validator

National ID validator is used to check recipients of type person to verify that they are specified when required and they have valid values supplied. The validator depends on minimal amount parameter that defines when national ID information becomes mandatory for recipients of type person.

National ID becomes mandatory when buyer type is P and totalAmount equals to or greater than a configured value (ex. 50000 EGP)

Taxpayer Validator

Taxpayer validator is the tool that validates if the taxpayers referenced in the submitted document are valid at the date of issuance of the document. It also performs checks on the issuer taxpayer that require async processing and cannot be done synchronously in core fields validator.

Duplicate Document Validator

Duplicate document validator can be used for both validation (that invalidates documents) and for alerting (that generate alerts to employees) as all other processors, but this one is targeted primarily at the alerting pipelines.

Processor tries to find documents submitted recently that are like the document that is being processed to identify cases where the same document (often) by mistake has been submitted twice or even more than twice.

Processor enables configuration of parameters used to identify the match by allowing process administrators to define the combination of attributes that need to match from the list of offered attributes.

How to generate receipt UUID?

Receipt UUID is a unique key on system level, it is generated based on receipt content as per receipt base schema through the following procedure:

1. Make sure to include all key fields in receipt object including UUID of previous receipt issued by same POS device.
2. If receipt type is return then make sure to include referenceUUID of the receipt in this return object.
3. Make sure receipt object has empty receipt UUID which is being generated.
4. Serialize and normalize receipt object and flatten all its properties in one line text.
5. Create a hash value of the normalized text using SHA256.
6. Convert the hash value from array of 32 bytes to hexadecimal string of 64 characters.
7. Use the hexadecimal string as receipt UUID.

How to sign a receipt batch?

Click here to get the detailed information about signing a receipt batch.

Receipt QR Code

The taxpayer should generate a QR code and place it on the printed receipt. This QR code represents a URL to the receipt details in the eInvoicing portal.

QR Code Content

QR code content is described as per the following sections:

1. Technical

Name	Description
URL	URL of Receipt Details Page. URL format: {eInvoicingPortalURL}/receipts/search/{UUID}/share/{ReceiptDateAndTime}

Note {ReceiptDateAndTime} is the receipt issuance date and time in UTC.

You may pick eInvoicing Portal URL from here

URL Example: http://invoicing.eta.gov.eg/receipts/search/68e656b251e67e8358bef8483ab0d51c6619f3e7a1a9f0e75838d41ff368f320/share/2022-02-19T02:00Z

2. Receipt Type

Name	Description	Value example
Receipt Type Value	Receipt Type Value such as sale/return	sale

3. Seller Information

Name	Description	Value example
Registration Number	Registration Number of Seller	674859545
Branch Code	Code of Seller’s Branch	0
Device Number	Serial Number of POS Device (source of receipt)	MD1234567890

4. Receipt Data

Name	Description	Value example
Receipt Number	Receipt Number	374638
Total VAT	Value added tax	500.000
Net Amount	Receipt’s Net Amount	1000.000

QR Code Template

All QR code content should be included in one line text as per the following template:

{URL}#Receipt Type:{Receipt Type},RIN:{Registration Number},Device Number:{Device Number},Branch Code:{Branch Code},Receipt Number:{Receipt Number},VAT:{Total VAT},Total:{Net Amount}

Example of formated QR Code Content

http://invoicing.eta.gov.eg/receipts/search/68e656b251e67e8358bef8483ab0d51c6619f3e7a1a9f0e75838d41ff368f320/share/2022-02-19T02:00Z#Receipt Type:Sales,RIN:674859545,Device Number:MD1234567890,Branch Code:0,Receipt Number:374638,VAT:500.000,Total:1000.000

Receipt batch Schema and Structure

Click here to download sample of the receipt batch schema and structure in the JSON format.

Limitations on receipt submission

The following limitations are managed by the IT Operator for the process of receipt submission:

1. Maximum Submission Size is 500 receipts (1.5 Mbytes)
2. Minimum Submission Size is 1 receipt
3. Average number of lines per receipt (10)
4. Maximum number of line Items per receipt is 80
5. The receipt is allowed to be submitted within the allowed duration (24 hours), unless this receipt is being resubmitted and has the OLD UUID added to the receipt/return receipt
6. Submission datetime can’t be in the future
7. Supported content type: application/json
8. Submit with allowed branch
9. Submit with valid/active document type and document type version

Limitations on POS device

1. The length of POS Serial Number can be up to 100 characters.
2. POS device issuing the receipt has to have been registered and linked to the issuer RIN before the receipt is issued.
3. The issuer should have been allowed to issue receipts by assigning the B2C tag on the system.
4. The taxpayer should not be blocked.