Troubleshooting
What goes wrong with Egypt ETA e-Receipt, how to recognise it, and what to do.
Everything is refused and the documents look correct
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 so.
Check it first. It is a property of your ETA registration and nothing in Odoo can set it or detect it.
The till is halted
Deliberate, and not a warning you can dismiss.
A receipt was skipped, so every later one references a predecessor the Authority never received. Continuing would turn one problem into a day of them.
To resolve it:
- Find the skipped receipt. The till shows its chain position and the last UUID ETA accepted; the gap is between those.
- Work out why it was skipped — rejected, cancelled, or never submitted.
- An e-Receipt Manager resumes the till. It raises an activity, so the decision is recorded rather than quiet.
Resuming is a decision about tax filings. It is not a button to clear a banner.
"A receipt cannot be submitted before the one it follows"
Working as intended. Submit them in chain order.
If the predecessor is stuck, fix that one first. If it was cancelled or rejected, it is skipped when the chain is computed — neither was ever accepted — and the successor should then be submittable.
Local validation refuses the receipt
It names the field, which is the whole point of it happening here:
| Message | Fix |
|---|---|
| Product has no ETA item code | Code it in the e-Invoice mapping screen (GS1 or EGS) |
| Unit of measure has no ETA unit code | Likewise |
| Payment method code is blank | Set it on the till, from ETA's own table |
Finding these here costs a field. Finding them at the Authority costs a filing.
The device is not recognised
The device serial number on the till must match what ETA holds exactly. One character out and it is a device the Authority has never heard of, and the whole till's output is refused.
It will not submit: "not signed"
ETA requires a CAdES-BES signature from an eSeal certificate, held on a token or HSM by your local signing service. No signature, no submission.
On the signing host:
- Is the service running?
- Is the token or HSM connected and unlocked? A token locked after failed PIN attempts looks identical to one that is absent.
- Has the certificate expired? They do, without warning.
There is no software-only fallback, and there cannot be — the key being in hardware is the point of an eSeal.
Submitted, and the status never changes
202 does not mean filed. ETA documents it as "accepted for further processing" and says validation is not complete when it answers.
Check ETA e-Receipt: check submitted statuses is enabled — it ships disabled, on purpose, and stays that way until you enable it. Without it, nothing polls and receipts sit in Submitted forever.
A status came back that I do not recognise
It is stored exactly as received and flagged in the chatter, and the state is left alone. ETA publishes only valid verbatim, so anything else is not interpreted.
If you see one regularly, send it to us with the receipt — an undocumented status we can confirm is one we can handle properly.
Nothing is being submitted at all
ETA e-Receipt: submit ready receipts ships disabled. Enable it once you have built a receipt, read it, submitted it by hand and seen it come back.
A module that began filing on install would submit unchecked documents under your registration.
Totals disagree with the lines
ETA recomputes quantity × unitPrice from the document, so the document has to agree with itself under the Authority's arithmetic: five decimal places, unit price rounded before multiplying.
If the difference is fractions, raise Odoo's Product Price decimal precision. This module cannot recover precision Odoo has already discarded.
I tried to file a second receipt for one invoice
Refused. The same revenue filed twice is not fixed by a correction.
I want to cancel a receipt I submitted
Not from Odoo. Changing a state here would not cancel it at the Authority, and the two records would then disagree — which is worse than the problem.
Use ETA's own process.
The uuid does not match what the signing service produces
Expected, and documented. The canonicalisation in this module is not ETA's published algorithm — ETA's CanonicalJSON rules live inside its Integration Toolkit rather than on the documentation site.
What is here is deterministic and makes the chain coherent and testable. The hash used in a live submission must come from the signing service, which holds the eSeal and implements the Authority's actual rules.