mock-einvoice 0.1.0__tar.gz → 0.3.0__tar.gz

{mock_einvoice-0.1.0 → mock_einvoice-0.3.0}/CHANGELOG.md

@@ -10,6 +10,82 @@ says so where it does.
 
 Nothing yet.
 
+## [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
+Denmark, Greece, Iceland, Italy, the Netherlands, Norway or Sweden were the
+last. **It changes what such a document gets:** it was "not judged" and the
+server turned it away, and it is now `valid` or `invalid`.
+
+### Added
+
+- **Peppol's rules for a seller in Denmark, Greece, Iceland, Italy, the
+  Netherlands, Norway and Sweden** ([#18]): 71 rules, 61 fatal, in
+  `mockeinvoice/rules/peppol_national.py`. Every rule Peppol BIS Billing
+  3.0.21 publishes is now built, 165 in all. All 282 cases Peppol publishes
+  for these rules agree. Iceland's ten have no published cases and rest on
+  this project's tests. **Changes behaviour:** a Peppol document from one of
+  those seven countries was `not judged`, and the server turned it away with
+  `NOT-JUDGED`. It is now `valid` or `invalid`. Peppol's own Swedish example
+  is `valid`.
+- `tools/fetch_peppol.py` fetches the unit tests for those countries and
+  Peppol's three national examples as well: 167 files, from 101.
+
+### Changed
+
+- **No document is `not judged` any more.** The verdict, the server's
+  `NOT-JUDGED` and `Report.not_built` are kept for a rule a specification
+  publishes before this package has it. `Report.not_applicable` is empty for
+  a Peppol document, where it listed the 71.
+
+### Removed
+
+- `mockeinvoice.rules.peppol.SCOPES`, `sellers_countries` and `from_`, which
+  said which unbuilt national rules a document could wait on. Nothing is
+  left for them to say.
+
 ## [0.1.0] - 2026-10-07
 
 The first release. It reads and writes UBL invoices and credit notes and
@@ -212,3 +288,5 @@ 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

{mock_einvoice-0.1.0/mock_einvoice.egg-info → mock_einvoice-0.3.0}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: mock-einvoice
-Version: 0.1.0
+Version: 0.3.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: Repository, https://github.com/rseufert/mock-einvoice
@@ -39,13 +39,14 @@ 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 Peppol's own 63 and the 31 it has for Germany, 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.1.0 is not:**
+**What 0.3.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.
-- **A Peppol document from a seller in Denmark, Greece, Iceland, Italy, the Netherlands, Norway or Sweden is at best "not judged"**, and the server does not take it in: Peppol's 71 rules for those countries are not built ([#18](https://github.com/rseufert/mock-einvoice/issues/18)). An XRechnung document, and a Peppol document from Germany or from a country Peppol has no national rules for, can be "valid".
+- **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`, which is on its `main` and in no release of it yet.
+- **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).
 
 ## What is built
@@ -67,7 +68,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.
@@ -100,12 +101,14 @@ A document names its specification, and that decides its layers:
 | Layer | Pinned to | Published rules | Built |
 | --- | --- | --- | --- |
 | EN 16931 core | [validation artefacts 1.3.16](https://github.com/ConnectingEurope/eInvoicing-EN16931/tree/validation-1.3.16) | 979 (281 fatal) | all 979: what a document must have in it (`BR-01` to `BR-65`), the calculation rules (`BR-CO-*`), the decimals rules (`BR-DEC-*`), the ten families of VAT category rules, the code lists (`BR-CL-*`), and the 756 rules about the UBL document itself (`UBL-CR-*`, `UBL-DT-*`, `UBL-SR-*`) |
-| Peppol BIS Billing 3.0 | 3.0.21, at commit [`806866b`](https://github.com/OpenPEPPOL/peppol-bis-invoice-3/commit/806866bd2bd91d7e9623b68f08164e8fbe9e67a0) (it has no tag) | 165 (139 fatal) | 94: Peppol's own 63 (`PEPPOL-EN16931-*`, `PEPPOL-COMMON-*`) and Germany's 31 (`DE-R-*`). Not the 71 for a seller in another country (`DK-R`, `GR-R`, `IS-R`, `IT-R`, `NL-R`, `NO-R`, `SE-R`) |
+| Peppol BIS Billing 3.0 | 3.0.21, at commit [`806866b`](https://github.com/OpenPEPPOL/peppol-bis-invoice-3/commit/806866bd2bd91d7e9623b68f08164e8fbe9e67a0) (it has no tag) | 165 (139 fatal) | all 165: Peppol's own 63 (`PEPPOL-EN16931-*`, `PEPPOL-COMMON-*`), Germany's 31 (`DE-R-*`), and the 71 for a seller in Denmark, Greece, Iceland, Italy, the Netherlands, Norway or Sweden (`DK-R`, `GR-R`, `GR-S`, `IS-R`, `IT-R`, `NL-R`, `NO-R`, `SE-R`) |
 | XRechnung 3.0 | [Schematron 2.6.0](https://github.com/itplr-kosit/xrechnung-schematron/tree/v2.6.0) | 56 (46 fatal) | 34: every rule of a standard XRechnung document (`BR-DE-*`, `BR-TMP-2`, `BR-TMP-6`). Not the 22 of XRechnung Extension and CVD (`BR-DEX-*`, `BR-DE-CVD-*`), whose documents are refused by name |
 
-**Not built is said, never assumed.** `mockeinvoice/rules/published.py` lists every published rule of every layer by identifier and flag, and a report lists the ones that did not run. A document nothing was found wrong with is `not judged`, not `valid`, for as long as a fatal rule that could apply to it is unbuilt.
+**Not built is said, never assumed.** `mockeinvoice/rules/published.py` lists every published rule of every layer by identifier and flag, and a report lists the ones that did not run. A document nothing was found wrong with is `not judged`, not `valid`, for as long as a fatal rule that could apply to it is unbuilt. Every rule that can apply to a document this package takes is built, so no document is `not judged` today; the verdict is kept for the day a specification publishes a rule before this package has it.
 
-**A rule that could not apply is not waited on.** Peppol's rules for a seller in one country say nothing of a document from another, and the rules of XRechnung Extension and CVD say nothing of a standard XRechnung document. A report lists them apart, as `not_applicable`, and they do not hold back its verdict. A document counts as one of a country's if the seller's VAT identifier, its tax representative's, or its address says so: all three at once, which is never narrower than the published rules' own test, so nothing is waved through that a national rule could have caught.
+**A rule that could not apply is not waited on.** The rules of XRechnung Extension and CVD say nothing of a standard XRechnung document. A report lists them apart, as `not_applicable`, and they do not hold back its verdict.
+
+**Where a seller is, is not one question.** Peppol's rules for a seller's country do not agree on what makes a document one of theirs. Norway, Italy and Greece go by the first two letters of the seller's VAT identifier, then its tax representative's, and only then by the country of its address. Denmark, Iceland and Sweden go by the address, written exactly (`dk` is not Denmark). The Netherlands goes by the address however it is written. Each rule here goes by what its published test goes by, and `mockeinvoice/rules/peppol_national.py` says which.
 
 **Two things a rule is asked of.** Most rules are asked of the model. The 756 about the UBL document itself are asked of its elements, because they are about elements the standard has no term for and the model does not hold: `validate(xml)` asks them of the document as it was sent. `check(document, specification)`, given a model and no XML, asks them of the document that model would be written as. Where one of them reports an element, the reader's own finding about that element (`UNHELD`, `REPEATED`) is left out, so an element is reported once, under the published rule's name where there is one.
 
@@ -245,7 +248,69 @@ $ 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
 
@@ -254,8 +319,17 @@ The supplier writes no invoices. It sends what it is given.
 | `GET /_mock/health` | that it is up, its version, and how many documents it holds and has sent |
 | `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`) |
 | `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.
+
 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
@@ -298,6 +372,7 @@ A group with nothing in it is still there: an empty `TaxSubtotal` is a VAT break
 - **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.
@@ -336,15 +411,16 @@ The rules, the reader and the writer are tested against files this project did n
 | EN 16931 examples | 17 documents | read, written back, and compared element for element by a reader that is not this one |
 | XRechnung test suite | 39 valid XRechnung 3.0 documents | read with nothing to say, written back element for element, and every one is `valid`: no rule of the core's 979 or XRechnung's 34 fails or warns. Seventeen are told, as information, that they do not say when they were delivered (`BR-DE-TMP-32`) |
 | XRechnung test suite | 5 Extension and 1 CVD document | refused by name |
-| Peppol unit tests | 400 cases | all 396 agree: 331 for Peppol's own rules and 65 for Germany's. The other 4 are about a UBL Order |
+| Peppol unit tests | 673 cases, with 678 things said of a rule | all 678 agree: 331 for Peppol's own rules, 65 for Germany's and 282 for the other six countries that have any. 4 cases are about a UBL Order. Iceland's ten rules have none |
 | Peppol Invoice Response | 14 examples and 13 unit test cases | every example is read with nothing to say, written back element for element, and no rule has anything to say of it; all 13 cases agree. The structure and the code lists here are compared with the ones Peppol describes |
-| Peppol examples | 10 documents | read with nothing to say, written back element for element, and no rule has anything to say of them. Nine are `valid`; the tenth is from a seller in Sweden, whose rules are not built, and is `not judged` |
+| Peppol examples | 10 documents | read with nothing to say, written back element for element, and no rule has anything to say of them. All ten are `valid` |
+| Peppol national examples | 3 documents, kept by Peppol's national authorities | two are `valid` with a warning each; the third, a Greek invoice through a tax representative, is `invalid` by the core's `BR-06`, because its seller has no legal name |
 
 - **A case for a rule that is not built is never counted as agreeing.** The counts are written out in `tests/test_upstream.py`, so building a rule moves a number there on purpose.
 - **A disagreement is a failure here** until the published rule shows the case to be wrong; then it is listed in `tests/upstream.py` by name, with the reason. None is.
 - **To read the counts:** `python -m tests.upstream`. CI prints them on every run.
 
-Peppol's files are not in this repository (see Licences). `python tools/fetch_peppol.py` fetches the 101 listed in `tools/peppol-files.tsv` (billing's examples, its unit tests, and the rule file itself, which a test reads Peppol's code lists from) and the 28 in `tools/peppol-response-files.tsv` (the Invoice Response's examples, unit tests, hand-written rules, code lists and the description of its structure) from the pinned commit, checks each against the git hash listed for it, and puts them where the tests look. Without them those two tests are skipped and say so. CI fetches them on two of its jobs.
+Peppol's files are not in this repository (see Licences). `python tools/fetch_peppol.py` fetches the 167 listed in `tools/peppol-files.tsv` (billing's examples and national examples, its unit tests, and the rule file itself, which a test reads Peppol's code lists from) and the 28 in `tools/peppol-response-files.tsv` (the Invoice Response's examples, unit tests, hand-written rules, code lists and the description of its structure) from the pinned commit, checks each against the git hash listed for it, and puts them where the tests look. Without them those two tests are skipped and say so. CI fetches them on two of its jobs.
 
 Two things were checked while building and are not tests, because their sources are not here:
 
@@ -355,6 +431,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.1.0 → mock_einvoice-0.3.0}/README.md

@@ -9,13 +9,14 @@ 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 Peppol's own 63 and the 31 it has for Germany, 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.1.0 is not:**
+**What 0.3.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.
-- **A Peppol document from a seller in Denmark, Greece, Iceland, Italy, the Netherlands, Norway or Sweden is at best "not judged"**, and the server does not take it in: Peppol's 71 rules for those countries are not built ([#18](https://github.com/rseufert/mock-einvoice/issues/18)). An XRechnung document, and a Peppol document from Germany or from a country Peppol has no national rules for, can be "valid".
+- **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`, which is on its `main` and in no release of it yet.
+- **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).
 
 ## What is built
@@ -37,7 +38,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.
@@ -70,12 +71,14 @@ A document names its specification, and that decides its layers:
 | Layer | Pinned to | Published rules | Built |
 | --- | --- | --- | --- |
 | EN 16931 core | [validation artefacts 1.3.16](https://github.com/ConnectingEurope/eInvoicing-EN16931/tree/validation-1.3.16) | 979 (281 fatal) | all 979: what a document must have in it (`BR-01` to `BR-65`), the calculation rules (`BR-CO-*`), the decimals rules (`BR-DEC-*`), the ten families of VAT category rules, the code lists (`BR-CL-*`), and the 756 rules about the UBL document itself (`UBL-CR-*`, `UBL-DT-*`, `UBL-SR-*`) |
-| Peppol BIS Billing 3.0 | 3.0.21, at commit [`806866b`](https://github.com/OpenPEPPOL/peppol-bis-invoice-3/commit/806866bd2bd91d7e9623b68f08164e8fbe9e67a0) (it has no tag) | 165 (139 fatal) | 94: Peppol's own 63 (`PEPPOL-EN16931-*`, `PEPPOL-COMMON-*`) and Germany's 31 (`DE-R-*`). Not the 71 for a seller in another country (`DK-R`, `GR-R`, `IS-R`, `IT-R`, `NL-R`, `NO-R`, `SE-R`) |
+| Peppol BIS Billing 3.0 | 3.0.21, at commit [`806866b`](https://github.com/OpenPEPPOL/peppol-bis-invoice-3/commit/806866bd2bd91d7e9623b68f08164e8fbe9e67a0) (it has no tag) | 165 (139 fatal) | all 165: Peppol's own 63 (`PEPPOL-EN16931-*`, `PEPPOL-COMMON-*`), Germany's 31 (`DE-R-*`), and the 71 for a seller in Denmark, Greece, Iceland, Italy, the Netherlands, Norway or Sweden (`DK-R`, `GR-R`, `GR-S`, `IS-R`, `IT-R`, `NL-R`, `NO-R`, `SE-R`) |
 | XRechnung 3.0 | [Schematron 2.6.0](https://github.com/itplr-kosit/xrechnung-schematron/tree/v2.6.0) | 56 (46 fatal) | 34: every rule of a standard XRechnung document (`BR-DE-*`, `BR-TMP-2`, `BR-TMP-6`). Not the 22 of XRechnung Extension and CVD (`BR-DEX-*`, `BR-DE-CVD-*`), whose documents are refused by name |
 
-**Not built is said, never assumed.** `mockeinvoice/rules/published.py` lists every published rule of every layer by identifier and flag, and a report lists the ones that did not run. A document nothing was found wrong with is `not judged`, not `valid`, for as long as a fatal rule that could apply to it is unbuilt.
+**Not built is said, never assumed.** `mockeinvoice/rules/published.py` lists every published rule of every layer by identifier and flag, and a report lists the ones that did not run. A document nothing was found wrong with is `not judged`, not `valid`, for as long as a fatal rule that could apply to it is unbuilt. Every rule that can apply to a document this package takes is built, so no document is `not judged` today; the verdict is kept for the day a specification publishes a rule before this package has it.
 
-**A rule that could not apply is not waited on.** Peppol's rules for a seller in one country say nothing of a document from another, and the rules of XRechnung Extension and CVD say nothing of a standard XRechnung document. A report lists them apart, as `not_applicable`, and they do not hold back its verdict. A document counts as one of a country's if the seller's VAT identifier, its tax representative's, or its address says so: all three at once, which is never narrower than the published rules' own test, so nothing is waved through that a national rule could have caught.
+**A rule that could not apply is not waited on.** The rules of XRechnung Extension and CVD say nothing of a standard XRechnung document. A report lists them apart, as `not_applicable`, and they do not hold back its verdict.
+
+**Where a seller is, is not one question.** Peppol's rules for a seller's country do not agree on what makes a document one of theirs. Norway, Italy and Greece go by the first two letters of the seller's VAT identifier, then its tax representative's, and only then by the country of its address. Denmark, Iceland and Sweden go by the address, written exactly (`dk` is not Denmark). The Netherlands goes by the address however it is written. Each rule here goes by what its published test goes by, and `mockeinvoice/rules/peppol_national.py` says which.
 
 **Two things a rule is asked of.** Most rules are asked of the model. The 756 about the UBL document itself are asked of its elements, because they are about elements the standard has no term for and the model does not hold: `validate(xml)` asks them of the document as it was sent. `check(document, specification)`, given a model and no XML, asks them of the document that model would be written as. Where one of them reports an element, the reader's own finding about that element (`UNHELD`, `REPEATED`) is left out, so an element is reported once, under the published rule's name where there is one.
 
@@ -215,7 +218,69 @@ $ 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
 
@@ -224,8 +289,17 @@ The supplier writes no invoices. It sends what it is given.
 | `GET /_mock/health` | that it is up, its version, and how many documents it holds and has sent |
 | `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`) |
 | `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.
+
 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
@@ -268,6 +342,7 @@ A group with nothing in it is still there: an empty `TaxSubtotal` is a VAT break
 - **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.
@@ -306,15 +381,16 @@ The rules, the reader and the writer are tested against files this project did n
 | EN 16931 examples | 17 documents | read, written back, and compared element for element by a reader that is not this one |
 | XRechnung test suite | 39 valid XRechnung 3.0 documents | read with nothing to say, written back element for element, and every one is `valid`: no rule of the core's 979 or XRechnung's 34 fails or warns. Seventeen are told, as information, that they do not say when they were delivered (`BR-DE-TMP-32`) |
 | XRechnung test suite | 5 Extension and 1 CVD document | refused by name |
-| Peppol unit tests | 400 cases | all 396 agree: 331 for Peppol's own rules and 65 for Germany's. The other 4 are about a UBL Order |
+| Peppol unit tests | 673 cases, with 678 things said of a rule | all 678 agree: 331 for Peppol's own rules, 65 for Germany's and 282 for the other six countries that have any. 4 cases are about a UBL Order. Iceland's ten rules have none |
 | Peppol Invoice Response | 14 examples and 13 unit test cases | every example is read with nothing to say, written back element for element, and no rule has anything to say of it; all 13 cases agree. The structure and the code lists here are compared with the ones Peppol describes |
-| Peppol examples | 10 documents | read with nothing to say, written back element for element, and no rule has anything to say of them. Nine are `valid`; the tenth is from a seller in Sweden, whose rules are not built, and is `not judged` |
+| Peppol examples | 10 documents | read with nothing to say, written back element for element, and no rule has anything to say of them. All ten are `valid` |
+| Peppol national examples | 3 documents, kept by Peppol's national authorities | two are `valid` with a warning each; the third, a Greek invoice through a tax representative, is `invalid` by the core's `BR-06`, because its seller has no legal name |
 
 - **A case for a rule that is not built is never counted as agreeing.** The counts are written out in `tests/test_upstream.py`, so building a rule moves a number there on purpose.
 - **A disagreement is a failure here** until the published rule shows the case to be wrong; then it is listed in `tests/upstream.py` by name, with the reason. None is.
 - **To read the counts:** `python -m tests.upstream`. CI prints them on every run.
 
-Peppol's files are not in this repository (see Licences). `python tools/fetch_peppol.py` fetches the 101 listed in `tools/peppol-files.tsv` (billing's examples, its unit tests, and the rule file itself, which a test reads Peppol's code lists from) and the 28 in `tools/peppol-response-files.tsv` (the Invoice Response's examples, unit tests, hand-written rules, code lists and the description of its structure) from the pinned commit, checks each against the git hash listed for it, and puts them where the tests look. Without them those two tests are skipped and say so. CI fetches them on two of its jobs.
+Peppol's files are not in this repository (see Licences). `python tools/fetch_peppol.py` fetches the 167 listed in `tools/peppol-files.tsv` (billing's examples and national examples, its unit tests, and the rule file itself, which a test reads Peppol's code lists from) and the 28 in `tools/peppol-response-files.tsv` (the Invoice Response's examples, unit tests, hand-written rules, code lists and the description of its structure) from the pinned commit, checks each against the git hash listed for it, and puts them where the tests look. Without them those two tests are skipped and say so. CI fetches them on two of its jobs.
 
 Two things were checked while building and are not tests, because their sources are not here:
 
@@ -325,6 +401,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.