mock-einvoice 0.2.0__tar.gz → 0.4.0__tar.gz

{mock_einvoice-0.2.0 → mock_einvoice-0.4.0}/CHANGELOG.md

@@ -10,6 +10,99 @@ says so where it does.
 
 Nothing yet.
 
+## [0.4.0] - 2026-10-22
+
+The binding is served, and the clock can be moved. **Every stamp changes**:
+it ends in `Z` now.
+
+### Added
+
+- **The UBL binding over HTTP** ([#39]). `GET /_mock/binding/Invoice` and
+  `/_mock/binding/CreditNote` give where each business term and group is in
+  the document, as a tree of elements: each node its element and its term,
+  group or fixed value, the elements UBL requires that have no term among
+  them. It is made from `mockeinvoice.ubl.BINDINGS`, the reader's and
+  writer's own table, when asked. Where one element has several entries
+  (an allowance or a charge), each says the test that picks it, as words and
+  as data. A test reads this project's samples and fifty published documents
+  by the served binding alone and comes to what the reader comes to. In
+  Python, `ubl.described`.
+- **A clock that can be moved** ([#41]). `POST /_mock/advance` takes
+  `seconds` or a time `to` move to, in the query string or as JSON, and what
+  is received or said afterwards is stamped then: the stamps, the date and
+  time in an Invoice Response, and the dates of an invoice the supplier
+  writes. It does not go backwards. In Python, `mockeinvoice.clock.Clock`,
+  which a `Buyer` and a `Supplier` take as their `now`.
+- `GET /_mock/health` says what time it is by the clock, as `"now"`.
+- `--clock` takes a time with `Z` or an offset (`2026-10-07T11:00+02:00`),
+  and a date alone.
+- A time whose `+` offset a query string turned into a space
+  (`?to=2026-10-07T11:00+02:00`) is refused with a word saying a `+` is
+  written `%2B` there ([#44]). Only such a time: one wrong another way is
+  not sent looking for a `+`.
+
+### Changed
+
+- The README and the package's page on PyPI point at the project's page on
+  rickseufert.com ([#43](https://github.com/rseufert/mock-einvoice/pull/43)).
+- **A stamp says its zone.** `"received"` and `"sent"` were
+  `2026-10-07T09:00:00` and are `2026-10-07T09:00:00Z`. They were UTC before
+  and are UTC now; a client that parsed them as a time with no zone has to
+  take the `Z`.
+- **What `--clock` means is written down, and is what it did**: the clock is
+  pinned to that moment, in UTC, and stands still until it is advanced. A
+  `now` given to a `Buyer` or a `Supplier` with a zone other than UTC is said
+  in UTC, where its own wall time was written before.
+- `--clock` refuses what is not a time with a sentence, and no longer takes
+  the other forms `datetime.fromisoformat` does (a space for the `T`,
+  fractions of a second).
+- The tests that pick an entry of the binding (`ubl.sepa`,
+  `ubl.in_accounting_currency`, and what `ubl.indicator` and
+  `ubl.document_type` return) are `ubl.When` objects, called as the
+  functions were. Nothing is read or written differently.
+
+## [0.3.0] - 2026-10-10
+
+The supplier writes an invoice itself, and the business terms can be read
+from the running mock. Nothing changes for a document sent with
+`POST /_mock/sent`, but for one key more in what is said of it.
+
+### Added
+
+- **A supplier that is told of an order, and writes and sends the invoice for
+  it** ([#33]). `POST /_mock/orders` takes an order as JSON, and
+  `POST /_mock/orders/<id>/invoices` writes a Peppol BIS Billing 3.0 invoice
+  for it, holds it to its rules, and sends it to `--buyer-url` like any other;
+  for all of the order, or for so much of some of its lines. The invoice
+  names the order (BT-13) and each line's order line (BT-132). In Python,
+  `Supplier.take` and `Supplier.bill`, and `mockeinvoice.order`.
+  - An order is this mock's own JSON and not Peppol's UBL `Order`, whose
+    rules are not built.
+  - Who is selling, where to pay, the rate of VAT, the days until payment and
+    the invoice numbers are the supplier's own: `GET` and
+    `PATCH /_mock/supplier`. Until it is changed it is the seller of this
+    project's sample invoice, and what it writes is `valid`.
+  - An order whose invoice would not be `valid` is not taken
+    (`422 UNBILLABLE`, with the findings).
+  - Every line is VAT category `S` at the supplier's one rate. No allowances,
+    charges, credit notes or XRechnung. The README lists what is made up, and
+    from what.
+- **The business terms over HTTP** ([#34]). `GET /_mock/terms` gives every
+  business term and group the package knows (164 and 32), each with its
+  number, name and kind, and `GET /_mock/terms/BT-13` or `/BG-25` gives one.
+  It is made from `mockeinvoice.model.TERMS` and `GROUPS` when asked, so a
+  client that cannot import the package reads the same table. In Python,
+  `model.catalogue`, `term_described` and `group_described`. A finding still
+  names a term by number alone.
+
+### Changed
+
+- **A document that was sent says which order it was written for**:
+  `"order"` in `POST /_mock/sent`, `GET /_mock/sent` and `/_mock/sent/<id>`,
+  `null` for one that was given finished. `GET /` lists eight paths more.
+- A JSON number with a fraction in a request is read as the decimal it was
+  written as, and not as a float. No request took such a number before.
+
 ## [0.2.0] - 2026-10-07
 
 Every rule Peppol BIS Billing publishes is now built: the 71 for a seller in
@@ -246,3 +339,8 @@ built, and was in no release.
 [#23]: https://github.com/rseufert/mock-einvoice/issues/23
 [#25]: https://github.com/rseufert/mock-einvoice/issues/25
 [#27]: https://github.com/rseufert/mock-einvoice/issues/27
+[#33]: https://github.com/rseufert/mock-einvoice/issues/33
+[#34]: https://github.com/rseufert/mock-einvoice/issues/34
+[#39]: https://github.com/rseufert/mock-einvoice/issues/39
+[#41]: https://github.com/rseufert/mock-einvoice/issues/41
+[#44]: https://github.com/rseufert/mock-einvoice/issues/44

{mock_einvoice-0.2.0/mock_einvoice.egg-info → mock_einvoice-0.4.0}/PKG-INFO

@@ -1,8 +1,9 @@
 Metadata-Version: 2.4
 Name: mock-einvoice
-Version: 0.2.0
+Version: 0.4.0
 Summary: A mock e-invoicing partner: EN 16931 invoices in and out, with the responses that follow. Zero dependencies.
 License: MIT AND EUPL-1.2
+Project-URL: Homepage, https://rickseufert.com/mock-einvoice/
 Project-URL: Repository, https://github.com/rseufert/mock-einvoice
 Project-URL: Issues, https://github.com/rseufert/mock-einvoice/issues
 Project-URL: Changelog, https://github.com/rseufert/mock-einvoice/blob/main/CHANGELOG.md
@@ -34,17 +35,21 @@ A mock e-invoicing partner: EN 16931 invoices in and out, with the responses tha
 
 A sibling of [mock-sap](https://github.com/rseufert/mock-sap), [mock-edi](https://github.com/rseufert/mock-edi) and [mock-bank](https://github.com/rseufert/mock-bank), and of [mock-acme](https://github.com/rseufert/mock-acme), the integration between them.
 
+By [Rick Seufert](https://rickseufert.com). Its [page](https://rickseufert.com/mock-einvoice/)
+has the features and how to start it.
+
 ```
 python3 -m pip install mock-einvoice
 mock-einvoice --port 8100
 ```
 
-It reads and writes UBL invoices and credit notes, and the Peppol Invoice Response that answers one, and holds them to their published rules: invoices to all 979 rules of the EN 16931 core, to all 165 of Peppol's (its own 63, the 31 it has for Germany and the 71 for seven other countries), and to the 34 of a standard XRechnung document; responses to all 82 of theirs. Over HTTP it is a buyer that takes invoices in and answers the Peppol ones, and a supplier that sends them and takes the answers.
+It reads and writes UBL invoices and credit notes, and the Peppol Invoice Response that answers one, and holds them to their published rules: invoices to all 979 rules of the EN 16931 core, to all 165 of Peppol's (its own 63, the 31 it has for Germany and the 71 for seven other countries), and to the 34 of a standard XRechnung document; responses to all 82 of theirs. Over HTTP it is a buyer that takes invoices in and answers the Peppol ones, and a supplier that sends them, writes the invoice for an order it is told of, and takes the answers.
 
-**What 0.2.0 is not:**
+**What 0.4.0 is not:**
 
-- **It writes no invoices of its own.** The supplier sends the documents it is given.
-- **It knows nothing of the other mocks.** Writing an invoice from one of mock-sap's billing documents, and saying "paid" when SAP has cleared it, is integration, and belongs in [mock-acme](https://github.com/rseufert/mock-acme) with the rest of it. It is not built there yet.
+- **It writes one kind of invoice of its own, and no other.** The supplier writes the invoice for an order it is told of: every line at one standard rate of VAT, no allowances or charges, no credit note, no XRechnung ([An order, and the invoice for it](#an-order-and-the-invoice-for-it)). Anything else it sends as it is given.
+- **It takes no order off the network.** An order is this mock's own JSON on a `/_mock` path. Peppol's UBL `Order` and its rules are not built.
+- **It knows nothing of the other mocks.** Writing an invoice from one of mock-sap's billing documents, and saying "paid" when SAP has cleared it, is integration, and belongs in [mock-acme](https://github.com/rseufert/mock-acme) with the rest of it: its `order_to_cash`, since mock-acme 0.6.0.
 - **Peppol's ten rules for a seller in Iceland are held to this project's tests only.** Peppol publishes unit tests for its rules for Denmark, Greece, Italy, the Netherlands, Norway and Sweden, and every case agrees here; for Iceland it publishes none. Those ten were written from the same reading of the rule file as the tests that hold them, so a misreading would be in both.
 - **No CII, no XRechnung Extension, no ZUGFeRD**, and no transport: see [What it refuses](#what-it-refuses) and [Known to be wrong, or not real](#known-to-be-wrong-or-not-real).
 
@@ -67,7 +72,7 @@ for line in document.all("BG-25"):  # the lines
 xml = write(document)               # UBL again, in the schema's order
 ```
 
-- **Terms by number.** `BT-1` is the invoice number in an invoice and in a credit note, whatever UBL calls the element. `mockeinvoice.model.TERMS` names all of them.
+- **Terms by number.** `BT-1` is the invoice number in an invoice and in a credit note, whatever UBL calls the element. `mockeinvoice.model.TERMS` names all of them, and the server gives the same table to a client that cannot import it: `GET /_mock/terms`.
 - **Decimals.** Every amount, quantity, price and percentage is a `decimal.Decimal` made from the text as written. `10.50` stays `10.50`. There is no float anywhere, and making a value from one is a `TypeError`.
 - **Groups that repeat are groups**: lines (`BG-25`), the VAT breakdown (`BG-23`), allowances and charges, notes, payment instructions, supporting documents. A group that occurs once (the seller, the totals) has its terms on the document or the line itself.
 - **Findings.** What the reader has to say about a document, each with a level, a code and the path it is about.
@@ -247,17 +252,132 @@ $ curl -s --data-binary @tests/samples/peppol-invoice.xml http://127.0.0.1:8101/
 
 A document's `"status"` is the last thing its buyer said. **A response out of order is taken and ignored.** Peppol's guide says of a response that follows a rejection or a payment in full, or follows an acceptance with anything but paid, that the seller may ignore it. So the supplier does: the response is `201` and kept, marked `"ignored"` with the rule it broke, and the status does not move. The same for one that goes back in the order.
 
-The supplier writes no invoices. It sends what it is given.
+#### An order, and the invoice for it
+
+The supplier can be told of an order, and writes and sends the invoice for it itself.
+
+```
+$ curl -s -d '{"number": "4500000017",
+    "buyer": {"name": "ACME Corporation", "endpoint": "0088:4098765000003",
+              "city": "Berlin", "postal_code": "10115", "country": "DE"},
+    "lines": [{"line": "10", "name": "Widget", "quantity": 40, "unit": "C62", "price": "20.00"}]}' \
+    http://127.0.0.1:8101/_mock/orders
+{
+  "id": "1",
+  "number": "4500000017",
+  ...
+  "status": "open",
+  ...
+}
+$ curl -s -X POST http://127.0.0.1:8101/_mock/orders/1/invoices
+{
+  "id": "1",
+  "kind": "Invoice",
+  "number": "GLX-0001",
+  ...
+  "verdict": "valid",
+  "delivery": {
+    "to": "http://127.0.0.1:8100/invoices",
+    "status": 201
+  },
+  "order": "/_mock/orders/1",
+  ...
+}
+```
+
+| | |
+| --- | --- |
+| `POST /_mock/orders` | Tell the supplier of an order: `{"number", "reference", "buyer", "currency", "lines"}`. The buyer is `{"name", "endpoint", "vat", "legal_id", "street", "city", "postal_code", "country"}` and needs its name, its country, and its endpoint written `scheme:identifier`. A line is `{"line", "name", "seller_item", "buyer_item", "quantity", "unit", "price"}` and needs its name, a quantity above nought, a unit (a code of UN/ECE Recommendation 20: `C62` is "one") and a price for one unit, without VAT. A line with no number has its place in the order for one. `201` and it is held; nothing is billed. `400` for what it lacks or does not know. `422` `UNBILLABLE` with the findings where the invoice it would be billed with is not `valid`: the invoice is written and held to its rules when the order comes, and thrown away. |
+| `GET /_mock/orders`, `/_mock/orders/<id>` | the orders; one, with what is billed and what is open of each line, and the invoices sent for it |
+| `POST /_mock/orders/<id>/invoices` | Write the invoice for all that is not yet billed, and send it as `POST /_mock/sent` would: the answer is the same, and the document is at `/_mock/sent/<id>` with the rest. `{"lines": [{"line": "10", "quantity": 15}]}` bills that much of those lines and no more. `409` `OVER-BILLED` for more than is open of a line, `409` `BILLED` when nothing is. `422` `NOT-VALID` with the findings if the invoice is not `valid`, which can only be because the supplier was changed since the order came; it is not sent, nothing is counted as billed, and there is no forcing it. |
+| `GET`, `PATCH /_mock/supplier` | who the supplier is, and changing it: any of the fields below. `POST /_mock/reset` forgets the orders and starts the invoice numbers again, and leaves this alone. |
+
+**An order is JSON here, and not a document of any standard.** Peppol has one, the UBL `Order` of its ordering profiles, with rules of its own. None of them is built, and taking the document in without holding it to them would be half of it. So the order is on a `/_mock` path, where the test's own controls are, and says no more than an invoice needs.
+
+**A number is never a float.** A quantity or a price is taken as text or as a JSON number, and a JSON number is read as the decimal it was written as.
+
+**Nothing is billed until it is asked for**, as nothing else here happens by itself.
+
+**What the supplier makes up, and from what.** An order does not say who is selling, where to pay, or what the invoice is called. The invoice is a Peppol BIS Billing 3.0 invoice (type `380`, billing's profile `01`), and what is in it comes from:
+
+| In the invoice | From |
+| --- | --- |
+| The seller: name (BT-27), electronic address (BT-34), VAT identifier (BT-31), legal registration (BT-30), address (BT-35, 37, 38, 40), contact (BT-41, 42, 43) | the supplier: `name`, `endpoint`, `vat`, `legal_id`, `street`, `city`, `postal_code`, `country`, `contact`, `telephone`, `email`. Until it is changed it is Globex GmbH of Hamburg, the seller of this project's sample invoice. |
+| The invoice number (BT-1) | the supplier's `number_prefix` and a count of the invoices it has written: `GLX-0001`. A document sent with `POST /_mock/sent` is not counted. |
+| The issue date (BT-2) and the due date (BT-9) | the clock, and the clock plus the supplier's `payment_days` (30) |
+| The currency (BT-5) | the order's, or the supplier's `currency` (`EUR`) |
+| The order (BT-13) and each line's order line (BT-132) | the order's number and its lines' numbers |
+| The buyer reference (BT-10) | the order's `reference`; **where it has none, the order's number again.** Peppol's rules for Germany want a buyer reference on every invoice between two German parties, and an order number is what a supplier with nothing else has. |
+| The buyer (BT-44, 47, 48, 49, 50, 52, 53, 55) | the order's buyer |
+| How to pay (BG-16): a credit transfer (code `30`) to the account (BT-84, 85, 86), quoting the invoice number (BT-83) | the supplier's `iban`, `name` and `bic` |
+| Each line: quantity, unit, item name, the seller's and the buyer's item number, price | the order's line. The line's net amount (BT-131) is quantity times price, rounded to the cent with a half going up. |
+| VAT: category `S` on every line at one rate (BT-151, 152), and one breakdown (BG-23) | the supplier's `vat_rate` (19). The tax is the rate on the sum of the lines, rounded once. |
+| The totals (BT-106, 109, 110, 112, 115) | the sums of the above. Nothing is prepaid, and there are no allowances or charges. |
+
+**What it does not write:** a line at any VAT category but `S` (exempt, nought, reverse charge, an intra-community supply), allowances and charges, a delivery date, notes, payment terms as text, a credit note, an XRechnung. A rate of nought is refused for that reason. An invoice that needs one of these is written by whoever drives the mock and sent with `POST /_mock/sent`, as before.
 
 ### Both
 
 | | |
 | --- | --- |
-| `GET /_mock/health` | that it is up, its version, and how many documents it holds and has sent |
+| `GET /_mock/health` | that it is up, its version, what time it is by its clock (`"now"`), and how many documents it holds and has sent |
+| `POST /_mock/advance` | move the clock forward: `?seconds=90`, or `?to=2026-10-08T08:00`, in the query string or as JSON. It answers `{"from", "to", "seconds", "pinned"}`. `400` for a time behind the clock, a fraction of a second, or more than ten years at once |
 | `GET /_mock/turned-away` | what was not taken in, on which side, and why |
 | `POST /_mock/validate` | an invoice, a credit note or an Invoice Response held to its rules, and not kept |
+| `GET /_mock/terms` | the business terms and groups this package knows, by number: `{"terms": [{"id", "name", "group", "kind"}], "groups": [{"id", "name", "repeats", "inside", "terms"}]}`, 164 terms and 32 groups, in the standard's order |
+| `GET /_mock/terms/BT-13`, `/_mock/terms/BG-25` | one term or one group, as in the list. `404` `NO-SUCH-TERM` for anything else, written any other way (`bt-13`) |
+| `GET /_mock/binding/Invoice`, `/_mock/binding/CreditNote` | where each term and group is in that UBL document: the binding as a tree of elements. `GET /_mock/binding` names the two. `404` `NO-SUCH-KIND` for anything else |
 | `POST /_mock/reset` | forget every document and response, on both sides |
 
+**The terms are the package's own table, served.** `GET /_mock/terms` is made from `mockeinvoice.model.TERMS` and `GROUPS` when it is asked, so what a client reads is what the reader, the writer and the rules go by.
+
+- A term's `kind` is one of `amount`, `binary`, `code`, `date`, `identifier`, `percentage`, `price`, `quantity`, `text`. Its `group` is `null` where the standard puts it on the document itself.
+- A group's `repeats` says how this package holds it and not how often the standard allows it: `true` where it is kept as a group of its own (the lines, the VAT breakdown), `false` where its terms are held by the document or the line. `inside` is the group it is written within, if any.
+- Three terms are written as an attribute of another's element (`BT-130`, the unit, is `BT-129`'s `unitCode`) and say so in `attribute_of`. Sixteen more, the scheme identifiers and their like (`BT-29-1`), have a number and no entry of their own here: each is listed under `attributes` on the term that holds it, and asked for by itself is `404` saying where it is.
+- A finding still gives a term by its number alone. Its path is not always a term (a rule about the XML gives an XPath), and a client that wants the name has this to look it up in.
+
+**The binding is the reader's own table, served.** `GET /_mock/binding/Invoice` is made from `mockeinvoice.ubl.BINDINGS` when it is asked: the table the reader reads a document by and the writer writes one by. A client that walks a document beside it names every element as the reader does, and a test does just that, with `xml.etree` and the served JSON alone, over this project's samples and fifty documents from EN 16931 and XRechnung, and comes to the same terms, values and groups.
+
+```
+{"kind": "Invoice", "element": "Invoice", "namespace": "urn:oasis:...:Invoice-2",
+ "prefixes": {"cbc": "urn:oasis:...", "cac": "urn:oasis:..."},
+ "children": [
+   {"element": "cbc:CustomizationID", "term": "BT-24"},
+   ...
+   {"element": "cac:AllowanceCharge", "group": "BG-20", "repeats": true,
+    "when": {"text": "cbc:ChargeIndicator is false or 0", "path": "cbc:ChargeIndicator", "in": ["false", "0"]},
+    "children": [{"element": "cbc:ChargeIndicator", "fixed": "false", "accepts": ["false", "0"]}, ...]},
+   ...]}
+```
+
+A node has its `element` and what it is:
+
+| | |
+| --- | --- |
+| `term` | the business term its text is the value of. `attributes` names each attribute the element may carry, and the term that attribute is (`"unitCode": "BT-130"`) or `null` where the standard has none for it (`currencyID`). `on_document` marks a term that is the document's whatever element it is in: a credit note's due date is inside `PaymentMeans`. |
+| `group`, `repeats` | the business group the element is, and whether it is one of many, as `/_mock/terms` has it |
+| `fixed`, `accepts` | the one value the binding gives the element (`TaxScheme/ID` is `VAT`), and what is read as that value |
+| `ubl` | something UBL requires or tells things apart by, that the standard has no term or group for, under the name this package holds it by: `ubl:NetworkID` on a payment card, the scheme of a tax registration that is not VAT, the two document references known by their type code |
+| `once_per` | the term the element is written once for each value of: one `PartyIdentification` to an identifier |
+| `subject` | on `cbc:Note`, the term of the code written before the text between two `#` (`#AAI#the note`) |
+| `children` | the elements in it, in the order the schema has them |
+| *none of these* | an element that only holds others: `cac:Party`, `cac:TaxTotal` |
+
+- **One element, several entries.** `cac:AllowanceCharge` is an allowance or a charge; `cac:AdditionalDocumentReference` is the invoiced object, a supporting document, or on a credit note the project. Such entries are in the reader's order, and each but the last has a `when`: the first whose test holds has the element, and one with no `when` takes what is left. A `when` has its `text` in words, and where it can be computed, a `path` under the element (and an `attribute` of what is there), the values it is `in`, and `ignoring_case`. An element's text is compared with the space around it taken off.
+- **One test is not data.** Which of two `cac:TaxTotal` is the VAT total in the accounting currency (BT-111) depends on two currency codes at the head of the document. Those two entries have their test in words and a `name` (`tax-total-in-document-currency`, `tax-total-in-accounting-currency`), and a client has to know them by that.
+- **A tax registration is served as two entries**, the VAT identifier and whatever else, told apart by `cac:TaxScheme/cbc:ID`. In the package it is one piece of code and not a row of the table, so those nodes are written out by hand beside it. A buyer and a tax representative have no term for another registration: theirs is held as the VAT identifier, and the second entry says so by naming the same term.
+- **What has no node has no business term.** An element of a document that the binding has no node for is what the reader reports as `UNHELD`.
+- **Not in it:** which place a value is written back to when a term has two (the creditor identifier, on the seller or the payee), and how often an element may occur.
+
+**The clock.** Every stamp (`"received"`, `"sent"`, `"now"`), the date and time in an Invoice Response, and the dates on an invoice the supplier writes come from one clock.
+
+- **It is UTC, and every stamp says so**: `2026-10-07T09:00:00Z`, to the second.
+- **`--clock` pins it, and a pinned clock stands still.** `--clock 2026-10-07T09:00` is that moment in UTC. `--clock 2026-10-07T11:00+02:00` is the same moment, and is said back in UTC; a `Z` may be written and changes nothing. In a query string a `+` is a space, so `?to=` writes that offset `%2B02:00`; a time whose `+` became a space is refused with a word saying so, and not repaired. Every stamp and every response carries that one instant until the clock is moved, so that what a run writes does not change from run to run. It does not tick on between advances, as mock-sap's pinned clock does: a second that depends on how fast the run went is what pinning is there to take away.
+- **`POST /_mock/advance` moves it**, pinned or not, by whole seconds or to a time, written as `--clock` is (a date alone is its midnight). What is received or said after that is stamped then. Without `--clock` the clock is real time plus whatever it was advanced by.
+- **It does not go backwards.** A time it is already at moves it nowhere and is no error. `POST /_mock/reset` forgets the documents and leaves the clock where it is.
+- **The time inside an Invoice Response has no zone written on it** (`cbc:IssueTime` is `09:00:00`). It is UTC like the rest.
+- Two of the mock run as two processes have two clocks, and each is advanced by itself.
+
 To see the two sides talk, run two: a buyer with `--seller-url http://127.0.0.1:8101/responses`, and a supplier with `--buyer-url http://127.0.0.1:8100/invoices`.
 
 ## What it refuses
@@ -296,10 +416,11 @@ A group with nothing in it is still there: an empty `TaxSubtotal` is a VAT break
 
 - **No transport.** A real Peppol invoice goes by AS4, signed and encrypted, between access points that find each other by SMP lookup. Here it is a `POST`, and the other party is a URL. The paths and status codes are this mock's own; nothing published defines an HTTP interface for any of it.
 - **An invalid document is turned away at the door and gets no Invoice Response.** On the real network the sender's access point validates before it sends, and Peppol's guide puts the status of a transmission outside what an Invoice Response is for. That this is how a failed validation should look from the seller's side is this project's reading and not a published rule.
-- **Nothing happens with time.** A real buyer moves an invoice to in process, accepted and paid over days, and Peppol asks for a first response within three working days. Here each status after the first is asked for.
+- **Nothing happens with time**, though the clock can be moved (`POST /_mock/advance`): moving it changes what is stamped next and nothing else. A real buyer moves an invoice to in process, accepted and paid over days, and Peppol asks for a first response within three working days. Here each status after the first is asked for.
 - **A duplicate is taken like the first.** A second document with a seller and a number already held is held too. A real buyer's system would likely reject it; with which status and reason is not known here, and is not guessed.
 - **Any buyer an invoice names is this mock**, and no document is turned away because its buyer is unknown. Nor does the supplier compare who a response is from with who its invoice was for: a response is matched by the invoice's number and type code alone, and of two documents sent with one number it is taken to be about the later.
 - **A response about a document that was never sent is turned away**, and so is one that names a type code other than its document's (`OP-BR111-R014`). The guide says the code must be the document's own and not what a seller does when it is not; and on the real network a response would be delivered whatever it was about. Both are this project's choices.
+- **How a real supplier bills an order is not known here, and the supplier's way is this project's own.** That it bills when asked and not on shipping, numbers its invoices by counting, takes a second order with a number it already holds, counts an invoice as billed though the buyer's system could not be reached or turned it away, and gives the order number as the buyer reference where it was given none: none of it is from a published source. An order's prices are also taken as they are; there is no price list to hold them to.
 - **Nothing is kept on disk.** Documents and responses are gone when the server stops.
 - **No XML Schema validation.** The published validators check the UBL schema before any rule. The standard library cannot, so this reads what it understands and reports what it did not. A document that is not schema-valid is not refused for that.
 - **The writer does not promise the same bytes.** Reading what was written gives an equal document. The order among repeats of different kinds (allowances and charges, say), the namespace prefixes, white space, comments and anything `UNHELD` are not kept.
@@ -358,6 +479,8 @@ Two things were checked while building and are not tests, because their sources
 
 The code values of UNTDID 1001, the United Nations' list of kinds of document, are in `mockeinvoice/rules/untdid.py`: 727 numbers from edition D.17A as UNECE publishes it, and none of the names or descriptions, which are the United Nations'. The directory's pages say "Copyright United Nations, all rights reserved"; the numbers are taken to be facts and not text.
 
+The names of the 164 business terms and 32 business groups in `mockeinvoice/model.py` are, by that file's own account, the standard's names for them, typed in by hand ("Invoice number", "Seller postal address"). None of the standard's descriptions or usage notes is there. They have been in the package since 0.1.0, and the server now gives them out as well (`GET /_mock/terms`).
+
 Nothing of Peppol's is in the package. Its rules are written here by hand from reading the tests, each under its published identifier and in this project's words. Where a Peppol rule holds a value to a code list, the list is the EN 16931 one already in the package, with the differences named: one currency code, twenty-one electronic address schemes, and two short lists of document type codes. A test compares the result with Peppol's own lists whenever its files have been fetched.
 
 The package is MIT, with two files that are not. `mockeinvoice/rules/codelists.py` holds the code lists of the EN 16931 code list rules (currencies, countries, units of measure and the rest), generated from the published rules by `tools/code_lists.py` and kept exactly as published. `mockeinvoice/rules/ublsyntax.py` holds the paths of the rules about the UBL document itself, generated by `tools/ubl_syntax.py`. Both are from the EN 16931 validation artefacts and are under the EUPL 1.2, whose text is beside them and goes into the wheel with them. One list more is in `rules/en16931.py`, the country prefixes `BR-CO-09` searches, and is from the same source. The wheel holds the package and nothing else.

{mock_einvoice-0.2.0 → mock_einvoice-0.4.0}/README.md

@@ -4,17 +4,21 @@ A mock e-invoicing partner: EN 16931 invoices in and out, with the responses tha
 
 A sibling of [mock-sap](https://github.com/rseufert/mock-sap), [mock-edi](https://github.com/rseufert/mock-edi) and [mock-bank](https://github.com/rseufert/mock-bank), and of [mock-acme](https://github.com/rseufert/mock-acme), the integration between them.
 
+By [Rick Seufert](https://rickseufert.com). Its [page](https://rickseufert.com/mock-einvoice/)
+has the features and how to start it.
+
 ```
 python3 -m pip install mock-einvoice
 mock-einvoice --port 8100
 ```
 
-It reads and writes UBL invoices and credit notes, and the Peppol Invoice Response that answers one, and holds them to their published rules: invoices to all 979 rules of the EN 16931 core, to all 165 of Peppol's (its own 63, the 31 it has for Germany and the 71 for seven other countries), and to the 34 of a standard XRechnung document; responses to all 82 of theirs. Over HTTP it is a buyer that takes invoices in and answers the Peppol ones, and a supplier that sends them and takes the answers.
+It reads and writes UBL invoices and credit notes, and the Peppol Invoice Response that answers one, and holds them to their published rules: invoices to all 979 rules of the EN 16931 core, to all 165 of Peppol's (its own 63, the 31 it has for Germany and the 71 for seven other countries), and to the 34 of a standard XRechnung document; responses to all 82 of theirs. Over HTTP it is a buyer that takes invoices in and answers the Peppol ones, and a supplier that sends them, writes the invoice for an order it is told of, and takes the answers.
 
-**What 0.2.0 is not:**
+**What 0.4.0 is not:**
 
-- **It writes no invoices of its own.** The supplier sends the documents it is given.
-- **It knows nothing of the other mocks.** Writing an invoice from one of mock-sap's billing documents, and saying "paid" when SAP has cleared it, is integration, and belongs in [mock-acme](https://github.com/rseufert/mock-acme) with the rest of it. It is not built there yet.
+- **It writes one kind of invoice of its own, and no other.** The supplier writes the invoice for an order it is told of: every line at one standard rate of VAT, no allowances or charges, no credit note, no XRechnung ([An order, and the invoice for it](#an-order-and-the-invoice-for-it)). Anything else it sends as it is given.
+- **It takes no order off the network.** An order is this mock's own JSON on a `/_mock` path. Peppol's UBL `Order` and its rules are not built.
+- **It knows nothing of the other mocks.** Writing an invoice from one of mock-sap's billing documents, and saying "paid" when SAP has cleared it, is integration, and belongs in [mock-acme](https://github.com/rseufert/mock-acme) with the rest of it: its `order_to_cash`, since mock-acme 0.6.0.
 - **Peppol's ten rules for a seller in Iceland are held to this project's tests only.** Peppol publishes unit tests for its rules for Denmark, Greece, Italy, the Netherlands, Norway and Sweden, and every case agrees here; for Iceland it publishes none. Those ten were written from the same reading of the rule file as the tests that hold them, so a misreading would be in both.
 - **No CII, no XRechnung Extension, no ZUGFeRD**, and no transport: see [What it refuses](#what-it-refuses) and [Known to be wrong, or not real](#known-to-be-wrong-or-not-real).
 
@@ -37,7 +41,7 @@ for line in document.all("BG-25"):  # the lines
 xml = write(document)               # UBL again, in the schema's order
 ```
 
-- **Terms by number.** `BT-1` is the invoice number in an invoice and in a credit note, whatever UBL calls the element. `mockeinvoice.model.TERMS` names all of them.
+- **Terms by number.** `BT-1` is the invoice number in an invoice and in a credit note, whatever UBL calls the element. `mockeinvoice.model.TERMS` names all of them, and the server gives the same table to a client that cannot import it: `GET /_mock/terms`.
 - **Decimals.** Every amount, quantity, price and percentage is a `decimal.Decimal` made from the text as written. `10.50` stays `10.50`. There is no float anywhere, and making a value from one is a `TypeError`.
 - **Groups that repeat are groups**: lines (`BG-25`), the VAT breakdown (`BG-23`), allowances and charges, notes, payment instructions, supporting documents. A group that occurs once (the seller, the totals) has its terms on the document or the line itself.
 - **Findings.** What the reader has to say about a document, each with a level, a code and the path it is about.
@@ -217,17 +221,132 @@ $ curl -s --data-binary @tests/samples/peppol-invoice.xml http://127.0.0.1:8101/
 
 A document's `"status"` is the last thing its buyer said. **A response out of order is taken and ignored.** Peppol's guide says of a response that follows a rejection or a payment in full, or follows an acceptance with anything but paid, that the seller may ignore it. So the supplier does: the response is `201` and kept, marked `"ignored"` with the rule it broke, and the status does not move. The same for one that goes back in the order.
 
-The supplier writes no invoices. It sends what it is given.
+#### An order, and the invoice for it
+
+The supplier can be told of an order, and writes and sends the invoice for it itself.
+
+```
+$ curl -s -d '{"number": "4500000017",
+    "buyer": {"name": "ACME Corporation", "endpoint": "0088:4098765000003",
+              "city": "Berlin", "postal_code": "10115", "country": "DE"},
+    "lines": [{"line": "10", "name": "Widget", "quantity": 40, "unit": "C62", "price": "20.00"}]}' \
+    http://127.0.0.1:8101/_mock/orders
+{
+  "id": "1",
+  "number": "4500000017",
+  ...
+  "status": "open",
+  ...
+}
+$ curl -s -X POST http://127.0.0.1:8101/_mock/orders/1/invoices
+{
+  "id": "1",
+  "kind": "Invoice",
+  "number": "GLX-0001",
+  ...
+  "verdict": "valid",
+  "delivery": {
+    "to": "http://127.0.0.1:8100/invoices",
+    "status": 201
+  },
+  "order": "/_mock/orders/1",
+  ...
+}
+```
+
+| | |
+| --- | --- |
+| `POST /_mock/orders` | Tell the supplier of an order: `{"number", "reference", "buyer", "currency", "lines"}`. The buyer is `{"name", "endpoint", "vat", "legal_id", "street", "city", "postal_code", "country"}` and needs its name, its country, and its endpoint written `scheme:identifier`. A line is `{"line", "name", "seller_item", "buyer_item", "quantity", "unit", "price"}` and needs its name, a quantity above nought, a unit (a code of UN/ECE Recommendation 20: `C62` is "one") and a price for one unit, without VAT. A line with no number has its place in the order for one. `201` and it is held; nothing is billed. `400` for what it lacks or does not know. `422` `UNBILLABLE` with the findings where the invoice it would be billed with is not `valid`: the invoice is written and held to its rules when the order comes, and thrown away. |
+| `GET /_mock/orders`, `/_mock/orders/<id>` | the orders; one, with what is billed and what is open of each line, and the invoices sent for it |
+| `POST /_mock/orders/<id>/invoices` | Write the invoice for all that is not yet billed, and send it as `POST /_mock/sent` would: the answer is the same, and the document is at `/_mock/sent/<id>` with the rest. `{"lines": [{"line": "10", "quantity": 15}]}` bills that much of those lines and no more. `409` `OVER-BILLED` for more than is open of a line, `409` `BILLED` when nothing is. `422` `NOT-VALID` with the findings if the invoice is not `valid`, which can only be because the supplier was changed since the order came; it is not sent, nothing is counted as billed, and there is no forcing it. |
+| `GET`, `PATCH /_mock/supplier` | who the supplier is, and changing it: any of the fields below. `POST /_mock/reset` forgets the orders and starts the invoice numbers again, and leaves this alone. |
+
+**An order is JSON here, and not a document of any standard.** Peppol has one, the UBL `Order` of its ordering profiles, with rules of its own. None of them is built, and taking the document in without holding it to them would be half of it. So the order is on a `/_mock` path, where the test's own controls are, and says no more than an invoice needs.
+
+**A number is never a float.** A quantity or a price is taken as text or as a JSON number, and a JSON number is read as the decimal it was written as.
+
+**Nothing is billed until it is asked for**, as nothing else here happens by itself.
+
+**What the supplier makes up, and from what.** An order does not say who is selling, where to pay, or what the invoice is called. The invoice is a Peppol BIS Billing 3.0 invoice (type `380`, billing's profile `01`), and what is in it comes from:
+
+| In the invoice | From |
+| --- | --- |
+| The seller: name (BT-27), electronic address (BT-34), VAT identifier (BT-31), legal registration (BT-30), address (BT-35, 37, 38, 40), contact (BT-41, 42, 43) | the supplier: `name`, `endpoint`, `vat`, `legal_id`, `street`, `city`, `postal_code`, `country`, `contact`, `telephone`, `email`. Until it is changed it is Globex GmbH of Hamburg, the seller of this project's sample invoice. |
+| The invoice number (BT-1) | the supplier's `number_prefix` and a count of the invoices it has written: `GLX-0001`. A document sent with `POST /_mock/sent` is not counted. |
+| The issue date (BT-2) and the due date (BT-9) | the clock, and the clock plus the supplier's `payment_days` (30) |
+| The currency (BT-5) | the order's, or the supplier's `currency` (`EUR`) |
+| The order (BT-13) and each line's order line (BT-132) | the order's number and its lines' numbers |
+| The buyer reference (BT-10) | the order's `reference`; **where it has none, the order's number again.** Peppol's rules for Germany want a buyer reference on every invoice between two German parties, and an order number is what a supplier with nothing else has. |
+| The buyer (BT-44, 47, 48, 49, 50, 52, 53, 55) | the order's buyer |
+| How to pay (BG-16): a credit transfer (code `30`) to the account (BT-84, 85, 86), quoting the invoice number (BT-83) | the supplier's `iban`, `name` and `bic` |
+| Each line: quantity, unit, item name, the seller's and the buyer's item number, price | the order's line. The line's net amount (BT-131) is quantity times price, rounded to the cent with a half going up. |
+| VAT: category `S` on every line at one rate (BT-151, 152), and one breakdown (BG-23) | the supplier's `vat_rate` (19). The tax is the rate on the sum of the lines, rounded once. |
+| The totals (BT-106, 109, 110, 112, 115) | the sums of the above. Nothing is prepaid, and there are no allowances or charges. |
+
+**What it does not write:** a line at any VAT category but `S` (exempt, nought, reverse charge, an intra-community supply), allowances and charges, a delivery date, notes, payment terms as text, a credit note, an XRechnung. A rate of nought is refused for that reason. An invoice that needs one of these is written by whoever drives the mock and sent with `POST /_mock/sent`, as before.
 
 ### Both
 
 | | |
 | --- | --- |
-| `GET /_mock/health` | that it is up, its version, and how many documents it holds and has sent |
+| `GET /_mock/health` | that it is up, its version, what time it is by its clock (`"now"`), and how many documents it holds and has sent |
+| `POST /_mock/advance` | move the clock forward: `?seconds=90`, or `?to=2026-10-08T08:00`, in the query string or as JSON. It answers `{"from", "to", "seconds", "pinned"}`. `400` for a time behind the clock, a fraction of a second, or more than ten years at once |
 | `GET /_mock/turned-away` | what was not taken in, on which side, and why |
 | `POST /_mock/validate` | an invoice, a credit note or an Invoice Response held to its rules, and not kept |
+| `GET /_mock/terms` | the business terms and groups this package knows, by number: `{"terms": [{"id", "name", "group", "kind"}], "groups": [{"id", "name", "repeats", "inside", "terms"}]}`, 164 terms and 32 groups, in the standard's order |
+| `GET /_mock/terms/BT-13`, `/_mock/terms/BG-25` | one term or one group, as in the list. `404` `NO-SUCH-TERM` for anything else, written any other way (`bt-13`) |
+| `GET /_mock/binding/Invoice`, `/_mock/binding/CreditNote` | where each term and group is in that UBL document: the binding as a tree of elements. `GET /_mock/binding` names the two. `404` `NO-SUCH-KIND` for anything else |
 | `POST /_mock/reset` | forget every document and response, on both sides |
 
+**The terms are the package's own table, served.** `GET /_mock/terms` is made from `mockeinvoice.model.TERMS` and `GROUPS` when it is asked, so what a client reads is what the reader, the writer and the rules go by.
+
+- A term's `kind` is one of `amount`, `binary`, `code`, `date`, `identifier`, `percentage`, `price`, `quantity`, `text`. Its `group` is `null` where the standard puts it on the document itself.
+- A group's `repeats` says how this package holds it and not how often the standard allows it: `true` where it is kept as a group of its own (the lines, the VAT breakdown), `false` where its terms are held by the document or the line. `inside` is the group it is written within, if any.
+- Three terms are written as an attribute of another's element (`BT-130`, the unit, is `BT-129`'s `unitCode`) and say so in `attribute_of`. Sixteen more, the scheme identifiers and their like (`BT-29-1`), have a number and no entry of their own here: each is listed under `attributes` on the term that holds it, and asked for by itself is `404` saying where it is.
+- A finding still gives a term by its number alone. Its path is not always a term (a rule about the XML gives an XPath), and a client that wants the name has this to look it up in.
+
+**The binding is the reader's own table, served.** `GET /_mock/binding/Invoice` is made from `mockeinvoice.ubl.BINDINGS` when it is asked: the table the reader reads a document by and the writer writes one by. A client that walks a document beside it names every element as the reader does, and a test does just that, with `xml.etree` and the served JSON alone, over this project's samples and fifty documents from EN 16931 and XRechnung, and comes to the same terms, values and groups.
+
+```
+{"kind": "Invoice", "element": "Invoice", "namespace": "urn:oasis:...:Invoice-2",
+ "prefixes": {"cbc": "urn:oasis:...", "cac": "urn:oasis:..."},
+ "children": [
+   {"element": "cbc:CustomizationID", "term": "BT-24"},
+   ...
+   {"element": "cac:AllowanceCharge", "group": "BG-20", "repeats": true,
+    "when": {"text": "cbc:ChargeIndicator is false or 0", "path": "cbc:ChargeIndicator", "in": ["false", "0"]},
+    "children": [{"element": "cbc:ChargeIndicator", "fixed": "false", "accepts": ["false", "0"]}, ...]},
+   ...]}
+```
+
+A node has its `element` and what it is:
+
+| | |
+| --- | --- |
+| `term` | the business term its text is the value of. `attributes` names each attribute the element may carry, and the term that attribute is (`"unitCode": "BT-130"`) or `null` where the standard has none for it (`currencyID`). `on_document` marks a term that is the document's whatever element it is in: a credit note's due date is inside `PaymentMeans`. |
+| `group`, `repeats` | the business group the element is, and whether it is one of many, as `/_mock/terms` has it |
+| `fixed`, `accepts` | the one value the binding gives the element (`TaxScheme/ID` is `VAT`), and what is read as that value |
+| `ubl` | something UBL requires or tells things apart by, that the standard has no term or group for, under the name this package holds it by: `ubl:NetworkID` on a payment card, the scheme of a tax registration that is not VAT, the two document references known by their type code |
+| `once_per` | the term the element is written once for each value of: one `PartyIdentification` to an identifier |
+| `subject` | on `cbc:Note`, the term of the code written before the text between two `#` (`#AAI#the note`) |
+| `children` | the elements in it, in the order the schema has them |
+| *none of these* | an element that only holds others: `cac:Party`, `cac:TaxTotal` |
+
+- **One element, several entries.** `cac:AllowanceCharge` is an allowance or a charge; `cac:AdditionalDocumentReference` is the invoiced object, a supporting document, or on a credit note the project. Such entries are in the reader's order, and each but the last has a `when`: the first whose test holds has the element, and one with no `when` takes what is left. A `when` has its `text` in words, and where it can be computed, a `path` under the element (and an `attribute` of what is there), the values it is `in`, and `ignoring_case`. An element's text is compared with the space around it taken off.
+- **One test is not data.** Which of two `cac:TaxTotal` is the VAT total in the accounting currency (BT-111) depends on two currency codes at the head of the document. Those two entries have their test in words and a `name` (`tax-total-in-document-currency`, `tax-total-in-accounting-currency`), and a client has to know them by that.
+- **A tax registration is served as two entries**, the VAT identifier and whatever else, told apart by `cac:TaxScheme/cbc:ID`. In the package it is one piece of code and not a row of the table, so those nodes are written out by hand beside it. A buyer and a tax representative have no term for another registration: theirs is held as the VAT identifier, and the second entry says so by naming the same term.
+- **What has no node has no business term.** An element of a document that the binding has no node for is what the reader reports as `UNHELD`.
+- **Not in it:** which place a value is written back to when a term has two (the creditor identifier, on the seller or the payee), and how often an element may occur.
+
+**The clock.** Every stamp (`"received"`, `"sent"`, `"now"`), the date and time in an Invoice Response, and the dates on an invoice the supplier writes come from one clock.
+
+- **It is UTC, and every stamp says so**: `2026-10-07T09:00:00Z`, to the second.
+- **`--clock` pins it, and a pinned clock stands still.** `--clock 2026-10-07T09:00` is that moment in UTC. `--clock 2026-10-07T11:00+02:00` is the same moment, and is said back in UTC; a `Z` may be written and changes nothing. In a query string a `+` is a space, so `?to=` writes that offset `%2B02:00`; a time whose `+` became a space is refused with a word saying so, and not repaired. Every stamp and every response carries that one instant until the clock is moved, so that what a run writes does not change from run to run. It does not tick on between advances, as mock-sap's pinned clock does: a second that depends on how fast the run went is what pinning is there to take away.
+- **`POST /_mock/advance` moves it**, pinned or not, by whole seconds or to a time, written as `--clock` is (a date alone is its midnight). What is received or said after that is stamped then. Without `--clock` the clock is real time plus whatever it was advanced by.
+- **It does not go backwards.** A time it is already at moves it nowhere and is no error. `POST /_mock/reset` forgets the documents and leaves the clock where it is.
+- **The time inside an Invoice Response has no zone written on it** (`cbc:IssueTime` is `09:00:00`). It is UTC like the rest.
+- Two of the mock run as two processes have two clocks, and each is advanced by itself.
+
 To see the two sides talk, run two: a buyer with `--seller-url http://127.0.0.1:8101/responses`, and a supplier with `--buyer-url http://127.0.0.1:8100/invoices`.
 
 ## What it refuses
@@ -266,10 +385,11 @@ A group with nothing in it is still there: an empty `TaxSubtotal` is a VAT break
 
 - **No transport.** A real Peppol invoice goes by AS4, signed and encrypted, between access points that find each other by SMP lookup. Here it is a `POST`, and the other party is a URL. The paths and status codes are this mock's own; nothing published defines an HTTP interface for any of it.
 - **An invalid document is turned away at the door and gets no Invoice Response.** On the real network the sender's access point validates before it sends, and Peppol's guide puts the status of a transmission outside what an Invoice Response is for. That this is how a failed validation should look from the seller's side is this project's reading and not a published rule.
-- **Nothing happens with time.** A real buyer moves an invoice to in process, accepted and paid over days, and Peppol asks for a first response within three working days. Here each status after the first is asked for.
+- **Nothing happens with time**, though the clock can be moved (`POST /_mock/advance`): moving it changes what is stamped next and nothing else. A real buyer moves an invoice to in process, accepted and paid over days, and Peppol asks for a first response within three working days. Here each status after the first is asked for.
 - **A duplicate is taken like the first.** A second document with a seller and a number already held is held too. A real buyer's system would likely reject it; with which status and reason is not known here, and is not guessed.
 - **Any buyer an invoice names is this mock**, and no document is turned away because its buyer is unknown. Nor does the supplier compare who a response is from with who its invoice was for: a response is matched by the invoice's number and type code alone, and of two documents sent with one number it is taken to be about the later.
 - **A response about a document that was never sent is turned away**, and so is one that names a type code other than its document's (`OP-BR111-R014`). The guide says the code must be the document's own and not what a seller does when it is not; and on the real network a response would be delivered whatever it was about. Both are this project's choices.
+- **How a real supplier bills an order is not known here, and the supplier's way is this project's own.** That it bills when asked and not on shipping, numbers its invoices by counting, takes a second order with a number it already holds, counts an invoice as billed though the buyer's system could not be reached or turned it away, and gives the order number as the buyer reference where it was given none: none of it is from a published source. An order's prices are also taken as they are; there is no price list to hold them to.
 - **Nothing is kept on disk.** Documents and responses are gone when the server stops.
 - **No XML Schema validation.** The published validators check the UBL schema before any rule. The standard library cannot, so this reads what it understands and reports what it did not. A document that is not schema-valid is not refused for that.
 - **The writer does not promise the same bytes.** Reading what was written gives an equal document. The order among repeats of different kinds (allowances and charges, say), the namespace prefixes, white space, comments and anything `UNHELD` are not kept.
@@ -328,6 +448,8 @@ Two things were checked while building and are not tests, because their sources
 
 The code values of UNTDID 1001, the United Nations' list of kinds of document, are in `mockeinvoice/rules/untdid.py`: 727 numbers from edition D.17A as UNECE publishes it, and none of the names or descriptions, which are the United Nations'. The directory's pages say "Copyright United Nations, all rights reserved"; the numbers are taken to be facts and not text.
 
+The names of the 164 business terms and 32 business groups in `mockeinvoice/model.py` are, by that file's own account, the standard's names for them, typed in by hand ("Invoice number", "Seller postal address"). None of the standard's descriptions or usage notes is there. They have been in the package since 0.1.0, and the server now gives them out as well (`GET /_mock/terms`).
+
 Nothing of Peppol's is in the package. Its rules are written here by hand from reading the tests, each under its published identifier and in this project's words. Where a Peppol rule holds a value to a code list, the list is the EN 16931 one already in the package, with the differences named: one currency code, twenty-one electronic address schemes, and two short lists of document type codes. A test compares the result with Peppol's own lists whenever its files have been fetched.
 
 The package is MIT, with two files that are not. `mockeinvoice/rules/codelists.py` holds the code lists of the EN 16931 code list rules (currencies, countries, units of measure and the rest), generated from the published rules by `tools/code_lists.py` and kept exactly as published. `mockeinvoice/rules/ublsyntax.py` holds the paths of the rules about the UBL document itself, generated by `tools/ubl_syntax.py`. Both are from the EN 16931 validation artefacts and are under the EUPL 1.2, whose text is beside them and goes into the wheel with them. One list more is in `rules/en16931.py`, the country prefixes `BR-CO-09` searches, and is from the same source. The wheel holds the package and nothing else.