FAQ
The questions asked most often about Egypt ETA e-Receipt, answered.
Why is this not part of the e-Invoice module?
Because a receipt is not an invoice with a new label. The Authority publishes different structures for the two:
| e-Invoice | e-Receipt | |
|---|---|---|
| Endpoint | /api/v1.0/documentsubmissions/ | /api/v1/receiptsubmissions |
| Body wrapper | documents | receipts |
| Submission id | submissionId | submissionUUID |
| Line: unit price | amountEGP | unitPrice |
| Line: gross | salesTotal | totalSale |
| Line: net | netTotal | netSale |
A shared builder would produce a document each endpoint rejects.
What is shared is authentication and HTTP transport, which are genuinely identical — so this module depends on the e-Invoice one and reuses eta.connection and the code mappings rather than duplicating them.
Has this been tested against the real ETA?
No receipt has ever been submitted to the Egyptian Tax Authority from this module. There are no base URLs, client credentials or eSeal certificate on our development account.
The suite runs against a mock ETA service replaying the documented shapes, and covers receipt building in v1.2, the per-device chain, rounding, status handling and every refusal.
We would rather say this here than have you discover it after paying.
My receipts are all refused and the document looks right
Check the B2C tag on your ETA taxpayer profile. Without it ETA accepts no receipts at all, however correct they are, and the refusal does not necessarily say that is why.
It is a property of your ETA registration, not something this module can set.
What is the chain, and why does it matter so much?
previousUUID makes receipts a chain per till: each references the one before it from the same device.
If one receipt is skipped, every later one references a predecessor the Authority never received. So a mismatch halts the till rather than warning — continuing would turn one problem into a day of them.
Why does the chain link receipt to receipt rather than to the last accepted one?
Because a batch built before any of it is submitted still has to form a proper chain among itself.
Pointing each new receipt at the last accepted uuid was the first design here, and it gave every receipt in a batch the same predecessor — ETA would have rejected all but the first. A test caught it.
A till is halted. How do I resume?
An e-Receipt Manager resumes it, and doing so raises an activity so a person is told.
Before you press it, find out which receipt was skipped and why. Resuming a halted chain is a decision about tax filings, not a way to clear a red banner.
Why did my receipt not file when ETA answered 202?
ETA documents that reply as "accepted for further processing" and states that validation is not complete when it answers.
A submitted receipt sits in Submitted until a status read from the Authority moves it. This module will not tell you something is filed on the strength of a 202.
ETA returned a status I do not recognise
It is stored exactly as received, flagged in the chatter, and the state is left alone. ETA publishes only valid verbatim, so inventing a meaning for anything else would be guessing about a tax filing.
Can I cancel a receipt I already submitted?
Not locally. Changing a state in Odoo would not cancel anything at the Authority, and the two records would then disagree — which is worse than the problem you were trying to fix.
Can I file two receipts for one invoice?
No, refused. The same revenue filed twice is not fixed by a correction.
Why do the scheduled jobs arrive switched off?
Because this module talks to a tax authority. One that began filing on install would submit unchecked documents under your registration.
Build a receipt, read it, submit it by hand, see it come back. Then enable them.
Why is the unsigned warning shown so prominently?
Because it is an honest state and it blocks submission. ETA requires a CAdES-BES signature from an eSeal certificate on a token or HSM outside Odoo. No signature, no submission.
Is the UUID hash the Authority's algorithm?
No, and this is worth knowing. ETA's CanonicalJSON rules live inside its Integration Toolkit rather than on the documentation site.
What is implemented here is deterministic and makes the chain coherent and testable, but the hash used in a live submission must come from the signing service, which holds the eSeal and implements the Authority's actual rules.
What do I still need to supply?
- The B2C tag on your taxpayer profile
- Preproduction and production base URLs, client id and secret
- An eSeal certificate and the token or HSM holding it
- Each till's registered device serial number
- ETA's payment-method code table
- Product and unit codes
Are you affiliated with ETA?
No. Not affiliated with or endorsed by the Egyptian Tax Authority.