@getpeppr/cli 0.8.4 → 0.10.0

package/CHANGELOG.md

@@ -4,12 +4,61 @@ All notable changes to `@getpeppr/cli` are documented here.
 
 The CLI bundles `@getpeppr/sdk` into its published artifact (tsup `noExternal`), so `validate`, `convert` and `init` run the SDK's validators, country rules and UBL builder locally — an SDK release only reaches CLI users once the CLI is rebundled. Rebundle-only releases are listed with the SDK version they ship.
 
+## [0.10.0] — 2026-08-28
+
+Bundles SDK **5.0.0**. Minor rather than patch because inputs that used to pass
+now change the exit code — if you gate a pipeline on `getpeppr validate`, read
+this before upgrading.
+
+**What `validate` now refuses:**
+
+| Input | 0.9.0 | 0.10.0 |
+| --- | --- | --- |
+| `"currency": "BGN"` or `"HRK"` | accepted, exit 0 | `Invalid currency code`, exit 1 |
+| a negative allowance or charge `amount` | accepted, exit 0 | refused, exit 1 |
+
+Bulgaria and Croatia joined the euro, and Peppol BIS Billing 3.0.21 — mandatory
+on the network since 2026-08-17 — dropped both codes from `BR-CL-04`/`BR-CL-05`.
+Use `EUR`. Separately, `XCG` (Caribbean guilder) is now accepted; it is the
+successor to `ANG`, not a replacement for either of the two dropped codes.
+
+⚠️ **`vatCategory: "L"` and `"M"` are NOT part of this change.** Measured on the
+published 0.9.0: `validate` already exits 1 on both, because it bundles an SDK
+newer than 3.2.0. And `convert` without `--validate` still renders them, as it
+should — an IGIC document is valid EN 16931, it simply cannot travel our JSON
+send path.
+
+**And a fix this CLI never carried.** 0.9.0 bundled SDK 4.8.0, one release
+behind, so it missed the `baseQuantity` correction from 4.8.1. Measured on the
+published 0.9.0 against this build, same input — a 24-unit order priced "€30 per
+box of 12":
+
+```
+0.9.0   <cbc:LineExtensionAmount currencyID="EUR">720.00</cbc:LineExtensionAmount>
+0.10.0  <cbc:LineExtensionAmount currencyID="EUR">60.00</cbc:LineExtensionAmount>
+```
+
+720 instead of 60 is a fatal `PEPPOL-EN16931-R120` violation. `getpeppr convert`
+gets it right now (GPR-1212).
+
+## [0.9.0] — 2026-08-23
+
+Before every sandbox send, the CLI now reads the exact sender profile from
+`GET /v1/identity`. Its own generated fixture is adapted to O/0 for a
+routing-only sender or AE/0 for a sender carrying a Tax Identifier. A
+user-authored file is never rewritten silently: an incompatible tax mode is
+refused locally before the invoice API is called.
+
+This replaces the incomplete static O/0 assumption in 0.8.4. It also bundles
+SDK 4.8.0 and fails closed when the provider inventory or scheme role cannot be
+verified (GPR-1149).
+
 ## [0.8.4] — 2026-08-22
 
-`getpeppr init` now scaffolds an invoice that a fresh sandbox account can send:
-the SPF Economie test receiver plus out-of-scope `O/0` lines. The previous
-template targeted the correct receiver but still carried VAT-bearing and
-reverse-charge lines, so a new sender with no VAT identifier received 422.
+`getpeppr init` scaffolded the SPF Economie test receiver plus out-of-scope
+`O/0` lines. That fixed routing-only senders but incorrectly assumed every
+sandbox sender lacked a Tax Identifier; 0.9.0 supersedes the static choice with
+the exact sender profile.
 
 Every generated `O` line includes the builder-only exemption reason required by
 the SDK's local validator. The quick `getpeppr send --to …` payload remains on

package/README.md

@@ -237,11 +237,11 @@ The CLI runs three validation engines from the [@getpeppr/sdk](https://www.npmjs
 2. **Business Rules** — Peppol BIS 3.0 / EN 16931 compliance (BR-xx, BR-CO-xx, PEPPOL-xx rules)
 3. **Country Rules** — Belgium (BE), France (FR), Italy (IT), Netherlands (NL), Germany (DE)
 
-Scaffolding (`init`), validation, and conversion run fully offline — no API key or network connection required. Only `lookup`, `send`, and `whoami` need a network connection.
+Scaffolding (`init`), validation, and conversion run fully offline — no API key or network connection required. Only `lookup`, `send`, and `whoami` need a network connection. Before a sandbox `send`, the CLI reads `GET /v1/identity`: its own generated fixture is adapted to the returned O/0 or AE/0 profile, while a user-edited file is never rewritten silently and is refused locally if its tax mode conflicts with the sender.
 
 ## Invoice format
 
-The input file must be a JSON object matching the getpeppr `InvoiceInput` type. `number`, `to`, and `lines` are required for API sends. The `from` party is included in the scaffold because offline validation and UBL conversion need seller metadata; API sends use the legal entity linked to your key. The generated file is an integration fixture: a fresh sandbox sender has no VAT identifier, so every line uses category `O` at rate `0`.
+The input file must be a JSON object matching the getpeppr `InvoiceInput` type. `number`, `to`, and `lines` are required for API sends. The `from` party is included in the scaffold because offline validation and UBL conversion need seller metadata; API sends use the legal entity linked to your key. The generated file starts as an O/0 integration fixture. At send time the CLI verifies it against the actual sender profile and never forwards an incompatible tax mode.
 
 ```json
 {