Finance teams invoicing in Tanzania run a split process: the sale is recorded in ERPNext, but the fiscal receipt is produced somewhere else — a physical EFD terminal on the counter, a vendor portal, or a spreadsheet the accountant re-keys at month end. ERPNext core has no concept of a fiscal device. A Sales Invoice submits happily whether or not TRA ever saw it, the naming series bears no relationship to the fiscal receipt number, and the Tanzanian VAT breakdown lives in Sales Taxes and Charges in a shape no fiscal endpoint accepts. The result is the familiar pattern: invoices posted in the ERP that were never fiscalized, fiscal receipts issued that were never posted, and a reconciliation exercise before every VAT return that nobody enjoys.

We build a proper Frappe app — its own module, its own DocTypes, its own git repository — that makes fiscalization a first-class step of the ERPNext posting lifecycle rather than a parallel process. A TRA EFD Settings single DocType holds the per-company device credentials, VFD registration details, endpoint URLs and certificate material, with secrets stored as Password fieldtype so they are encrypted at rest and never rendered back to the browser. A TRA Fiscal Document DocType is created for each fiscalization attempt and carries the full request payload, the raw response, the fiscal receipt number, verification code, verification URL, TRA timestamp and the resulting status. A hooks.py doc_events handler on Sales Invoice on_submit enqueues the fiscalization through frappe.enqueue so a slow or unreachable device never blocks a cashier's submit, and a companion handler blocks on_cancel for any invoice that already holds a successful fiscal receipt — because a fiscalized document is corrected with a credit note, never quietly cancelled.

Tax mapping is driven from your existing ERPNext master data rather than a hard-coded table. We map each Item Tax Template and Sales Taxes and Charges Template to the TRA tax code it represents — standard-rated, zero-rated, exempt, special rate — so a change in the master data changes the fiscal output without touching code. Line-level rounding is computed to the tolerance the endpoint expects rather than inherited from ERPNext's display precision, which is the single most common cause of rejection on first go-live. Human-readable and machine formats come out of the same posting: the signed payload goes to TRA, and a customised Print Format renders the fiscal receipt number, verification code and a QR code pointing at the TRA verification URL onto the customer-facing invoice, so one submit produces both the fiscal record and the document the customer actually receives.

Rejections are treated as a workflow, not an exception in a log. A failed fiscalization leaves the TRA Fiscal Document in a Failed state with the TRA error code and message parsed onto named fields, an indicator on the linked Sales Invoice, and a retry action exposed as a whitelisted method (@frappe.whitelist()) so an authorised finance user can re-attempt after correcting the underlying data. A scheduler_events hourly job sweeps stuck and pending documents, refreshes the device token before expiry, and raises an exception report of anything that has aged past your tolerance. Permissions ship as a dedicated TRA Compliance Officer role with a matching Role Profile, so operators can fiscalize and retry without gaining rights to edit the credentials in Settings. Everything is reachable over the standard Frappe REST API for your own integrations, and archiving is real archiving — every request and response is retained immutably against the fiscal document with a versioned audit trail, exportable for a TRA audit.

This is build-to-order, not a marketplace download. We start with a short scoping call to confirm your TRA registration and device model, your ERPNext version (v15 or v16), your VAT template structure and your branch or POS topology. From confirmed scope, typical delivery is 2 to 4 weeks: we build against a staging copy of your site, run UAT with your finance team on real invoice shapes, then install on production with a documented rollback. You receive the installable source for your version, the git repository, technical and user documentation, a training session, and a post-go-live support window while the first VAT period runs through the new flow.