If you use getpeppr lookup with the symbolic form of a scheme — GB:VAT,
DE:LWID, IE:VAT — upgrade. Your lookups were resolving against a scheme
the network does not know, and nothing said so.
One colon too many
The official Peppol code list publishes every scheme twice: under a numeric EAS
code (9932) and under a symbolic form (GB:VAT). 98 of its 105 entries
contain a colon in that symbolic form — the very character that separates a
scheme from its value.
So this cannot be split by position, and we were splitting it by position:
GB:VAT:123456789 → scheme "GB" value "VAT:123456789" ⛔ both wrong
GB is not a scheme. The lookup went out under it, found nothing, and reported
nothing found — which is indistinguishable from a participant who really is not
registered.
lookup, the directory client and the send template all carried that same
split. They now resolve it against the code list itself rather than by counting
characters.
Why the CLI was late
The gateway and the SDK were fixed in SDK 4.4.0, on 20 August. The CLI has
its own copy of that logic — it does not call the SDK for it — so the fix did
not reach you until this release. If you were comparing behaviour between
getpeppr lookup and your own SDK integration and finding them inconsistent,
that is why.
Also in this release
This build rebundles @getpeppr/sdk 4.5.0 (was 4.4.0). Nothing in the CLI
uses what changed there — importFile({ sender }), for platforms sending raw
UBL on behalf of a customer — so no CLI behaviour changes because of it. It is
mentioned because the CLI ships the SDK inside its own artifact: an SDK release
only reaches CLI users when this package is republished.