Lesson 4 — Two ways to produce a document, and why one of them no longer waits
There are two routes to the same PINT AE document. Most days you will use the fast one; the days that matter are the ones where you use the other.
The obligation. An in-scope document has to be issued and transmitted. Nothing in the mandate says the person issuing it should be the one absorbing a third party's bad afternoon, and the design of this module takes that seriously.
The mental model. Send & Print does the whole sequence for you: it generates the PINT AE XML, validates it, queues it for transmission and hands you the PDF. The UAE E-Invoicing tab on a posted invoice exposes the same work as separate buttons, so you can stop between the steps and look at what was produced. Same document, same checks — one path is automatic and one is deliberate.
The click path — the fast one. Post the invoice, press Send & Print. Any error comes back to you in the wizard and is never silently swallowed, which is worth saying plainly because the alternative design — a document that quietly fails somewhere behind the scenes — is how businesses discover in February that January never went anywhere.
The click path — the deliberate one. On a posted invoice, open the UAE E-Invoicing tab. It shows the e-invoice status and the FTA status, and carries five buttons.
| Button | What it does | When you use it |
|---|---|---|
| Generate | Builds the PINT AE XML from the invoice | You want to see the document before anything leaves |
| Validate | Checks it against the mandatory-field and business rules | You are correcting data and want the error list again |
| Send via ASP | Hands the document to the provider | It is validated and you are ready |
| Retry | Attempts the send again | Enabled only when the document has failed or been rejected |
| View Documents | Opens the e-invoice document records for this invoice | You want the states, the history and the XML |
Send & Print no longer waits for the ASP, and that is the right design. Pressing it queues the document and returns your PDF immediately; a scheduled action transmits it in the background. Consider the alternative honestly: a person stands at a counter, holding a customer's invoice, while a network call to a third party either returns or does not. Under the queueing design a slow or unavailable provider delays the transmission, not the person issuing the invoice. A provider outage stops being a reason your front desk cannot hand a customer their paperwork, and the transmission still happens — it simply stops sitting on the critical path of somebody's afternoon.
The worked example. At month end the clerk at Marina Ridge posts and sends forty invoices in one sitting. Each Send & Print returns at the speed of an ordinary print job, because none of them is waiting for a provider to answer. Two of the forty come back with validation errors, which she reads, fixes and re-sends in the same sitting. The remaining thirty-eight are queued, and what happens to them next is not her job.
The failure mode. Two of them, and both are expectations rather than defects. Retry is disabled on a document that has not failed or been rejected, which surprises people who reach for it as a general "send again" button — it exists to resume something that stopped, not to repeat something that worked. And the FTA outcome does not arrive in the Send & Print wizard: this module is corner 1, and it learns the outcome when the provider tells it. Everything between queued and cleared — the dispatcher, the retry backoff, the attempt ceiling and the E-Invoicing Status report — is course 3.3, on the Odoone course list.