Configuration
Every setting in Egypt ETA e-Receipt, and what each one changes.
What is configured elsewhere
The connection — URLs, client id and secret, taxpayer details, the signing service — lives in technovision_eta_einvoice, and so do the product, unit and tax code mappings. This module reuses both rather than keeping a second copy.
See that module's Configuration page. Everything below is what is specific to receipts.
The B2C tag
Not a setting in Odoo. It is a property of your ETA taxpayer profile, and without it ETA accepts no receipts at all.
Confirm it before you spend time on anything else here. A perfectly built receipt submitted under a profile with no B2C tag is refused, and the refusal does not necessarily say that is why.
Registered tills
Egypt ETA → Configuration → Registered Tills. One record per physical device.
| Field | Notes |
|---|---|
| Device serial number | Exactly as registered with ETA |
| Branch code | Your ETA branch |
| Payment method code | From ETA's own table |
| Chain position | Read-only — where this till has got to |
| Last accepted UUID | Read-only — the last one the Authority took |
The till is also where you see whether the chain is halted, and where a Manager resumes it.
Why the serial matters so much
previousUUID makes receipts a chain per till. The device serial is what identifies that till to ETA. A serial that is wrong by one character is a device the Authority has never heard of, and the whole till's output is refused.
The chain, and what it implies
Each receipt references the one before it from the same device. Four consequences this module takes seriously:
The chain links receipt to receipt, not receipt to "whatever was accepted last". So a batch built before any of it is submitted still forms a proper chain among itself.
That was not the first design. Pointing each new receipt at the last accepted uuid gave every receipt in a batch the same predecessor, and ETA would have rejected all but the first. A test caught it.
A receipt cannot be submitted before the one it follows. Attempting it is refused with the reason.
A mismatch halts the till. Not a warning — a halt. Once a receipt has been skipped, every later one references a predecessor the Authority never received, so continuing turns one problem into a day of them.
Cancelled and rejected receipts are skipped when the chain is computed. Neither was ever accepted, so neither is a valid predecessor.
Resuming a halted till
Restricted to an e-Receipt Manager, and it raises an activity so a person is told rather than it happening quietly.
That restriction is the point. Resuming a halted chain is a decision about tax filings, not a button to clear a red banner.
Rounding
Five decimal places, and the unit price is rounded before it is multiplied.
ETA never sees Odoo's stored figure — it recomputes quantity × unitPrice from the document — so the document has to agree with itself under the Authority's arithmetic rather than under Odoo's.
If you need genuine five-decimal unit prices, raise Odoo's Product Price decimal precision. No module can recover precision Odoo has already discarded.
The two scheduled jobs
| Job | What it does | Ships |
|---|---|---|
| ETA e-Receipt: submit ready receipts | Submits what is ready | Disabled |
| ETA e-Receipt: check submitted statuses | Polls for the real answer | Disabled |
Both off on install, deliberately. A module that began filing on install would submit unchecked documents under your tax registration.
Enable them once you have built a receipt, read it, submitted it by hand and seen it come back.
Groups
| Group | Can |
|---|---|
| e-Receipt User | Build receipts, submit, read status |
| e-Receipt Manager | The above, plus tills and resuming a halted chain |