Egyptian retailers and restaurants under the ETA e-receipt mandate face a specific gap: ERPNext gives you a solid POS Invoice and Sales Invoice flow, but it has no concept of the Egyptian Tax Authority's e-receipt schema, its device/POS registration model, or the near-real-time submission the mandate expects for high-volume B2C sales. The ETA e-receipt system is deliberately different from the B2B e-invoice track — it works per registered POS device, expects each receipt UUID and cryptographic serialization, and issues the QR code your cashiers must print at the counter. Out of the box, ERPNext cannot produce any of that, so most shops end up re-keying every sale into a portal or a middleware they cannot see inside.

We build a proper Frappe application (ecosire_eta_ereceipt) installed onto your existing ERPNext v15/v16 bench — not a hosted black box. The app adds an ETA E-Receipt DocType that mirrors the Tax Authority's receipt document (header, seller/branch, buyer where present, line items, tax totals, and payment breakdown), plus an ETA POS Device DocType that holds the registration, activation code, and credentials for each physical or virtual POS your branches run. A hooks.py doc_events handler fires on POS Invoice submit to serialize the sale into the ETA e-receipt JSON, request the receipt UUID, sign/submit through the ETA e-receipt SDK endpoint, and write the returned UUID and status straight back onto the source document. Item and tax mapping is handled with a configurable ETA Item Code Map that resolves each ERPNext Item to its EGS or GS1 code and the correct ETA tax-type/sub-type, so cashiers never touch a tax code.

Submission is designed for the reality of a busy counter. The doc-event path attempts an immediate submit so the QR prints on the receipt; anything that fails to reach the ETA — network blips, token expiry, a device that dropped offline — is queued and retried by a Frappe scheduler_events background job, with each attempt and the ETA response logged against the receipt for audit. Whitelisted API methods expose submit, re-submit, and status-check so your own POS UI (or ERPNext POS) can call them via the Frappe REST API, and a role profile (ETA Receipt Manager / cashier) keeps device credentials and cancellation out of ordinary users' hands. Client scripts render the UUID and QR on the print format and surface a clear success/queued/rejected badge to the cashier.

Because every business codes items, branches, and tax differently, this is a build-to-order engagement, not a marketplace download. We start from a short scoping call, confirm your ETA registration profile (taxpayer/branch/device structure), your item and tax mapping, and your POS flow, then build and hand over a versioned app tailored to it. Typical delivery is one working week from confirmed scope. You receive the installable source, a git repository, UAT on a staging bench with a rollback plan, and a defined post-go-live support window so real ETA traffic is watched, not assumed.