UAE retailers and restaurants running high-volume checkout on ERPNext hit a wall the moment the FTA's e-invoicing mandate and Peppol interoperability enter the picture. Stock ERPNext POS issues a simplified sales receipt and a generic print format — it does not produce a legally structured UAE tax invoice with mandatory TRN, bilingual Arabic/English fields, correct rounding, and a machine-readable Peppol/PINT-AE payload. Restaurants layering service charges, mixed 5%-VAT and zero-rated/exempt items, and split payments on a single ticket make this worse: the native tax templates and print formats simply were not designed for the FTA layout or for emitting a UBL-based e-invoice to an Access Point. Bolting this on with ad-hoc client scripts leaves you with fragile, unauditable receipts.

ECOSIRE builds a proper Frappe app — its own module with versioned DocTypes, hooks.py doc events, server scripts, whitelisted API methods, and print formats — installed on your bench alongside ERPNext. We model an E-Invoice (or extend POS Invoice / Sales Invoice) with the fields the FTA requires: seller and buyer TRN, invoice type code, line-level tax categories, and the reference chain for credit notes. A validate and on_submit hook wired through doc_events runs TRN format/checksum validation, computes 5% VAT against per-item tax categories (standard-rated, zero-rated, exempt, out-of-scope), applies FTA-conformant rounding, and generates the Peppol/PINT-AE UBL XML. The bilingual tax-invoice print format renders Arabic and English side by side for the customer receipt, and the POS flow is kept fast so cashiers see no lag at the till.

On the interoperability side, a whitelisted method (@frappe.whitelist()) and the Frappe REST API expose e-invoice submission and status, so the generated document can be transmitted to your chosen Peppol Access Point / FTA channel and the response (acceptance, clearance reference, errors) is stored back on the record and shown in the POS. Scheduler events (scheduler_events in hooks.py) handle ret/retry of failed transmissions and periodic reconciliation, and everything is guarded by ERPNext role profiles and permissions so only authorized roles can re-issue or void a compliant invoice. Client scripts add the cashier-facing TRN capture and validation prompts inside the POS UI. The app targets Frappe/ERPNext v15 and v16.

Because this is build-to-order, nothing ships until we agree on scope. We start with a short scoping call, confirm your exact FTA/Peppol channel, item tax structure, receipt language rules, and POS profiles, then build against a staging copy of your instance. You get UAT on staging with a rollback plan, installable source in a Git repo we hand over, install and configuration on your production bench, technical and user documentation, a training session, and a post-go-live support window. Typical delivery is one working week from confirmed scope.