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

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

@@ -10,6 +10,48 @@ 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
@@ -246,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.2.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.2.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,12 +39,13 @@ 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.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.
+- **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).
 
@@ -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.
@@ -247,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
 
@@ -256,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
@@ -300,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.
@@ -358,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.2.0 → mock_einvoice-0.3.0}/README.md

@@ -9,12 +9,13 @@ 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.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.
+- **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).
 
@@ -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.
@@ -217,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
 
@@ -226,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
@@ -270,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.
@@ -328,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.

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

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: mock-einvoice
-Version: 0.2.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,12 +39,13 @@ 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.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.
+- **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).
 
@@ -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.
@@ -247,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
 
@@ -256,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
@@ -300,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.
@@ -358,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.2.0 → mock_einvoice-0.3.0}/mock_einvoice.egg-info/SOURCES.txt

@@ -12,6 +12,7 @@ mockeinvoice/__init__.py
 mockeinvoice/__main__.py
 mockeinvoice/buyer.py
 mockeinvoice/model.py
+mockeinvoice/order.py
 mockeinvoice/response.py
 mockeinvoice/server.py
 mockeinvoice/specification.py
@@ -40,6 +41,7 @@ tests/test_business_rules.py
 tests/test_buyer.py
 tests/test_code_rules.py
 tests/test_model.py
+tests/test_order.py
 tests/test_peppol_de_rules.py
 tests/test_peppol_national_rules.py
 tests/test_peppol_rules.py

{mock_einvoice-0.2.0 → mock_einvoice-0.3.0}/mockeinvoice/__init__.py

@@ -3,8 +3,9 @@
 So far: UBL 2.1 invoices and credit notes in and out, the rules of the
 EN 16931 core, all of Peppol's, and XRechnung's; the
 Peppol Invoice Response; and over HTTP a buyer that takes invoices in and
-answers them, and a supplier that sends them and takes the answers
-(`mockeinvoice.buyer`, `mockeinvoice.supplier`, `mockeinvoice.server`).
+answers them, and a supplier that sends them, writes one itself for an order
+it is told of, and takes the answers (`mockeinvoice.buyer`,
+`mockeinvoice.supplier`, `mockeinvoice.order`, `mockeinvoice.server`).
 
     from mockeinvoice import read, validate, write
 
@@ -36,7 +37,7 @@ from .response import Response
 from .rules import Report, check, check_response
 from .ubl import parse, parse_tree, write
 
-__version__ = "0.2.0"
+__version__ = "0.3.0"
 
 __all__ = ["Document", "Finding", "Group", "Refused", "Report", "Response", "Value", "check",
            "read", "read_response", "validate", "validate_response", "write", "write_response",

{mock_einvoice-0.2.0 → mock_einvoice-0.3.0}/mockeinvoice/model.py

@@ -454,3 +454,40 @@ TERMS_IMPLYING: Dict[str, List[str]] = {INVOICED_OBJECT_REFERENCE: ["BT-18"],
 for _term in TERMS:
     for _group in implied(_term):
         TERMS_IMPLYING.setdefault(_group, []).append(_term)
+
+
+def term_described(term: str) -> Optional[dict]:
+    """What is known of one business term, as plain data, or None: its name,
+    the group the standard puts it in (None for the document itself) and
+    its kind, all as `TERMS` has them. `attributes` names the terms the
+    syntax writes as attributes of this one's element, and `attribute_of` the
+    term and attribute this one is written as, where either applies."""
+    if term not in TERMS:
+        return None
+    name, group, kind = TERMS[term]
+    said: dict = {"id": term, "name": name, "group": group or None, "kind": kind}
+    attributes = {attribute: other for other, (holder, attribute) in ATTRIBUTE_TERMS.items()
+                  if holder == term}
+    if attributes:
+        said["attributes"] = attributes
+    if term in ATTRIBUTE_TERMS:
+        holder, attribute = ATTRIBUTE_TERMS[term]
+        said["attribute_of"] = {"term": holder, "attribute": attribute}
+    return said
+
+
+def group_described(group: str) -> Optional[dict]:
+    """What is known of one business group, as plain data, or None: its name,
+    whether it is kept as a group that repeats, the group it is written
+    inside, and its terms, as `GROUPS`, `GROUP_INSIDE` and `TERMS` have them."""
+    if group not in GROUPS:
+        return None
+    name, repeats = GROUPS[group]
+    return {"id": group, "name": name, "repeats": repeats, "inside": GROUP_INSIDE.get(group),
+            "terms": [term for term, (_name, inside, _kind) in TERMS.items() if inside == group]}
+
+
+def catalogue() -> dict:
+    """Every business term and group this package knows, in the standard's order."""
+    return {"terms": [term_described(term) for term in TERMS],
+            "groups": [group_described(group) for group in GROUPS]}