Security
What Egypt ETA e-Receipt can read and write, what it stores, and what leaves your instance.
The eSeal key never touches Odoo
ETA requires a CAdES-BES signature from an eSeal certificate held on a USB token or HSM, outside Odoo, by a local signing service.
That is the Authority's requirement rather than our design, and it is a good one: the key that signs your tax filings is in hardware — not in a database column, not in a backup, not in an environment variable.
No signature, no submission. There is no software-only fallback.
Credentials are inherited, not duplicated
This module holds no credentials of its own. Authentication and transport come from eta.connection in technovision_eta_einvoice, where the Client Secret is on a field restricted to an ETA Administrator and masked.
Duplicating them here would have meant a second copy of a secret and a second place to rotate it.
The jobs ship disabled
ETA e-Receipt: submit ready receipts and ETA e-Receipt: check submitted statuses are both off on install.
This module talks to a tax authority. One that began filing on install would submit unchecked documents under the customer's registration — before anybody had looked at a single receipt.
The chain is a safety mechanism
previousUUID makes receipts a chain per till, and this module treats a break in it as a halt rather than a warning.
Once a receipt has been skipped, every later one references a predecessor the Authority never received. Continuing would file a day of documents that are all individually well-formed and collectively wrong.
Resuming is restricted to an e-Receipt Manager and raises an activity, so the decision is deliberate and recorded. It is a decision about tax filings, not a way to clear a banner.
Six things it refuses to do
Each of these is a place where being helpful would mean being wrong:
- Report a 202 as a filing. ETA says "accepted for further processing" and that validation is not complete.
- Submit without a signature.
- Guess a code. An uncoded product, a missing unit code or a blank payment-method code are refused with the field named.
- Invent a status. Anything ETA has not published verbatim is stored exactly as received and leaves the state alone.
- Cancel a submitted receipt locally. Odoo's state would then disagree with the Authority's.
- File two receipts for one invoice. The same revenue filed twice is not fixed by a correction.
Groups
| Group | Can |
|---|---|
| e-Receipt User | Build receipts, submit, read status |
| e-Receipt Manager | The above, plus tills and resuming a halted chain |
Multi-company
Record rules on every model, and the connection it inherits is company-scoped too.
Named plainly: the uuid canonicalisation
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, and we have not had sight of them.
What is implemented 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.
The code says so where it matters. It is stated here as well because it is the kind of thing that is easy to discover too late.
What has not been verified
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 the development account.
The suite runs against a mock ETA service replaying the documented shapes. Acceptance by ETA itself, and signing against a physical token, are unverified.
Every documented fact is recorded with its source URL and the date read in docs/eta_requirements.md Part 2, including a table of what could not be confirmed.
Reporting a vulnerability
info@technovision.dev. We acknowledge within two business days.
Not affiliated with or endorsed by the Egyptian Tax Authority.