write_checked_invoice.json
The JSON file of the “An invoice that asks before it claims” example. The library reads the invoice as it stands and names, clause by clause, everything between it and Factur-X. Two things stand in the way, then one, then none — and only then is a file written.
This file is a request: an application sends it over the network to the server, which creates the PDF and sends it back. It makes the same page as the Rust and Python versions of this example. A request names every file it uses, never its content; the call carries the request and the files together. A font the server already holds, such as DejaVuSans, is named with nothing attached. Send the request to the address the API page gives.
This request names files it does not carry: invoice_xml. Each one travels beside the request, in the same call, as a supplied part named exactly as the request names it here — the description says which name plays which role, so you name your files as you like. A request naming a file the call carries nothing of is refused.
What this example is for
Every other document here reaches a standard by declaring it: the file says it is Factur-X, and it is written as Factur-X. Declaring is easy; being right is not. A document can name an invoice it never attached, claim a level of detail the XML inside it does not follow, and sit in a container the standard does not allow — and go out saying all three, to come back refused by the accounting department it was sent to.
What this example shows
- Every finding at once, each naming the clause it comes from and the file it is about.
- Two in the way as first composed, one once the file is carried and the archival standard claimed, none once the level of detail claimed is the one the XML follows.
- The document measured before a byte of it goes out, and refused rather than written while anything stands.