Finance teams invoicing in Türkiye carry a split obligation that ERPNext core does not model. A buyer registered on the GİB e-Fatura user list must receive an e-Fatura routed through the registered-user channel; every other buyer — domestic retail, unregistered companies, and typically export scenarios — must receive an e-Arşiv, reported on a different cadence and retained under different rules. ERPNext gives you a Sales Invoice, an Item Tax Template and a print format. It does not know which of the two document types a given customer requires, does not carry the exemption and scenario codes the profile expects, cannot receive a buyer's rejection, and has nowhere structured to keep the machine-readable original that an audit will actually ask for. The result is the pattern we see repeatedly: invoices posted in ERPNext, then re-keyed into a portal or an integrator's own screen, with the two systems drifting apart by month-end.

We build a proper Frappe app — its own repository, its own module, installed with bench get-app and bench --site <site> install-app — that makes ERPNext both the system of record and the point of issue. A Turkey e-Invoice Settings single DocType holds company-level configuration: tax office, VKN/TCKN identifiers, integrator or gateway endpoint and credentials (stored as Password fieldtype, never plain text), a test-versus-production environment toggle, and the numbering series reserved for each document type. A Turkey e-Invoice Document DocType is created per outgoing invoice and is the durable record: resolved document type, scenario, serialized payload, returned identifier and timestamps, current lifecycle state, and every response received. Customer-side data lives on custom fields against Customer and Address — identifier type and value, registered-user status, and the alias or postbox where one applies — so the routing decision is made from master data rather than from a spreadsheet a controller maintains on the side.

The flow hangs off hooks.py doc events rather than a button someone must remember to press. Sales Invoice validate runs the completeness checks — identifier present and well formed, the address fields the profile requires, every line resolving to a tax rate and, where zero-rated, to an exemption reason — and blocks submission with a specific message instead of letting a malformed document reach the gateway. on_submit resolves the correct document type from the customer's registered status, builds the payload from ERPNext master data (Item Tax Template, Sales Taxes and Charges, UOM, currency and exchange rate), and enqueues transmission through frappe.enqueue so a slow or unavailable gateway never blocks a user's submit. on_cancel refuses to cancel a document already accepted downstream and directs the user to the correction path instead. A scheduler event declared in hooks.py polls for state changes — acceptance, rejection and application-response messages — and writes them back onto the Turkey e-Invoice Document, so a buyer's rejection surfaces in ERPNext as a task with an owner rather than as an email nobody opened. Rejection then opens a controlled correction workflow: the original stays intact and archived, a linked corrective document is raised against it, and the chain from original to correction is queryable from either end.

One posting produces both faces of the invoice. The machine-readable payload goes to the gateway and is stored verbatim on the document record; the human-readable rendering is a Jinja print format carrying the mandated visual elements, generated from the same data so the two can never disagree. Both are attached as File records against the Turkey e-Invoice Document with a checksum, giving you an archive that can be produced on demand and verified as unaltered. Access follows Frappe's permission model: a Turkey e-Invoice User role profile for the finance team who issue and correct, and a read-only auditor role that can retrieve archived originals without touching live invoicing. Whitelisted methods (@frappe.whitelist()) expose retry, status refresh and archive retrieval to the desk and, where you need it, over the Frappe REST API so a portal or middleware can query invoice status without a database login. A client script on Sales Invoice shows the resolved document type and live status inline, so the person issuing sees the outcome on the form they already work in.

This is build-to-order, not a marketplace download. We start with a scoping call — your GİB registration position, which integrator or gateway you use or intend to use, your Frappe/ERPNext version (v15 or v16), the scenarios you actually issue, and how corrections are handled today. We then build against your site, install on your staging bench first, and run UAT with your own customers and invoice patterns in the gateway's test environment before anything touches production. Typical delivery is 2–4 weeks from confirmed scope. You receive the full source repository — your code, on your git remote, with no obfuscation and no runtime licence phone-home — plus installation and configuration documentation, a user guide, a live training session for the finance team, and a post-go-live support window for defects and regulatory adjustments.