ekwo-os 0.4.1

package/dist/pack/upgrade.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"upgrade.d.ts","sourceRoot":"","sources":["../../src/pack/upgrade.ts"],"names":[],"mappings":"AAAA;;;;;;;;;GASG;AAGH,OAAO,KAAK,EAAE,SAAS,EAAE,MAAM,WAAW,CAAC;AAE3C,4EAA4E;AAC5E,MAAM,WAAW,iBAAiB;IAChC,SAAS,EAAE,MAAM,CAAC;IAClB,IAAI,EAAE,MAAM,CAAC;IACb,OAAO,EAAE,MAAM,CAAC;IAChB,SAAS,EAAE,MAAM,GAAG,IAAI,CAAC;IACzB,+BAA+B;IAC/B,WAAW,EAAE,MAAM,GAAG,IAAI,CAAC;IAC3B,iFAAiF;IACjF,WAAW,EAAE,MAAM,GAAG,IAAI,CAAC;IAC3B,MAAM,EAAE,OAAO,CAAC;IAChB,gFAAgF;IAChF,WAAW,CAAC,EAAE;QAAE,SAAS,EAAE,MAAM,CAAC;QAAC,QAAQ,EAAE,MAAM,CAAC;QAAC,MAAM,EAAE,MAAM,CAAA;KAAE,CAAC;CACvE;AAED,MAAM,WAAW,gBAAgB;IAC/B,KAAK,EAAE;QAAE,OAAO,EAAE,MAAM,CAAC;QAAC,OAAO,EAAE,MAAM,CAAC;QAAC,IAAI,EAAE,MAAM,CAAA;KAAE,EAAE,CAAC;IAC5D,SAAS,EAAE,iBAAiB,EAAE,CAAC;CAChC;AAED,wCAAwC;AACxC,MAAM,WAAW,UAAU;IACzB,MAAM,EAAE,MAAM,CAAC;IACf,GAAG,EAAE,MAAM,CAAC;IACZ,MAAM,EAAE,MAAM,CAAC;IACf,IAAI,EAAE,UAAU,GAAG,SAAS,GAAG,QAAQ,CAAC;IACxC,MAAM,EAAE,MAAM,CAAC,MAAM,EAAE,OAAO,CAAC,CAAC;CACjC;AAED,MAAM,WAAW,iBAAiB;IAChC,UAAU,EAAE,MAAM,CAAC;IACnB,OAAO,EAAE,MAAM,CAAC;IAChB,UAAU,EAAE,MAAM,CAAC;IACnB,YAAY,EAAE,MAAM,CAAC;IACrB,UAAU,EAAE,MAAM,CAAC;IACnB,aAAa,EAAE,OAAO,CAAC;IACvB,OAAO,EAAE,UAAU,EAAE,CAAC;IACtB,MAAM,EAAE,UAAU,EAAE,CAAC;IACrB,aAAa,EAAE,UAAU,EAAE,CAAC;CAC7B;AAED;;;;;;GAMG;AACH,wBAAsB,UAAU,CAAC,EAAE,EAAE,SAAS,GAAG,OAAO,CAAC,gBAAgB,CAAC,CAiDzE;AAED;;;;;;;GAOG;AACH,wBAAsB,cAAc,CAAC,EAAE,EAAE,SAAS,EAAE,MAAM,EAAE,MAAM,GAAG,OAAO,CAAC;IAAE,EAAE,EAAE,MAAM,CAAC;IAAC,IAAI,EAAE,MAAM,CAAA;CAAE,CAAC,CAMzG;AAED,MAAM,WAAW,cAAc;IAC7B,mEAAmE;IACnE,KAAK,CAAC,EAAE,OAAO,CAAC;IAChB,4EAA4E;IAC5E,OAAO,CAAC,EAAE,MAAM,CAAC;CAClB;AAED,wBAAsB,WAAW,CAC/B,EAAE,EAAE,SAAS,EACb,SAAS,EAAE,MAAM,EACjB,OAAO,GAAE,cAAmB,GAC3B,OAAO,CAAC,iBAAiB,CAAC,CAQ5B;AAED,8CAA8C;AAC9C,wBAAsB,QAAQ,CAC5B,EAAE,EAAE,SAAS,EACb,SAAS,EAAE,MAAM,EACjB,OAAO,CAAC,EAAE,MAAM,GACf,OAAO,CAAC,UAAU,EAAE,CAAC,CAKvB"}

package/dist/pack/upgrade.js

@@ -0,0 +1,76 @@
+/**
+ * `ekwo pack status` and `ekwo pack upgrade` — the database half of `pack`.
+ *
+ * `build`, `check` and `list` read a checkout and touch no database. These two
+ * do the opposite: they read an installation and know nothing about `packs/`.
+ * The difference between what a company copied and what the installation now
+ * holds is computed by the schema — `pack_upgrade_diff()` — and not here, so
+ * that an application, a module or an assistant asking the same question gets
+ * the same answer.
+ */
+import { matchCompany } from '../company.js';
+/**
+ * Where every company stands against the packs this installation holds.
+ *
+ * The differences are counted per company, which is one query each. A company
+ * whose country has no pack loaded gets no count rather than a zero: nothing
+ * is known about it, and a zero would read as "up to date".
+ */
+export async function packStatus(db) {
+    const packs = await db.query('select country, version, name from country_packs order by country');
+    const companies = await db.query(`select c.id as company_id, c.name, c.country, cp.chart_code,
+            cp.version as held_version, p.version as pack_version
+       from companies c
+       left join company_packs cp on cp.company_id = c.id and cp.country = c.country
+       left join country_packs p on p.country = c.country
+      order by c.name`);
+    const report = [];
+    for (const row of companies) {
+        const entry = {
+            companyId: row.company_id,
+            name: row.name,
+            country: row.country,
+            chartCode: row.chart_code,
+            heldVersion: row.held_version,
+            packVersion: row.pack_version,
+            behind: row.held_version !== null && row.pack_version !== null && row.held_version !== row.pack_version,
+        };
+        if (row.held_version !== null && row.pack_version !== null) {
+            const counts = await db.query(`select rule::text as rule, count(*)::text as count
+           from pack_upgrade_diff($1) group by rule`, [row.company_id]);
+            const at = (rule) => Number(counts.find((c) => c.rule === rule)?.count ?? '0');
+            entry.differences = {
+                additions: at('addition'),
+                closures: at('closure'),
+                review: at('review'),
+            };
+        }
+        report.push(entry);
+    }
+    return { packs, companies: report };
+}
+/**
+ * The company a name or an id refers to.
+ *
+ * A name is what an operator types and a uuid is what a script passes, so both
+ * are accepted; an ambiguous name is refused rather than resolved to the first
+ * match, because upgrading the wrong company is not a mistake anybody notices
+ * the same day.
+ */
+export async function resolveCompany(db, wanted) {
+    const companies = await db.query('select id::text as id, name from companies order by name');
+    // The matching is in one place, where `ekwo use` reads it too.
+    return matchCompany(companies, wanted);
+}
+export async function packUpgrade(db, companyId, options = {}) {
+    const rows = await db.query('select pack_upgrade($1, $2, $3) as pack_upgrade', [companyId, options.country ?? null, options.apply === true]);
+    const result = rows[0]?.pack_upgrade;
+    if (result === undefined)
+        throw new Error('pack_upgrade returned nothing');
+    return result;
+}
+/** What would change, without changing it. */
+export async function packDiff(db, companyId, country) {
+    return db.query('select object, key, change, rule::text as rule, detail from pack_upgrade_diff($1, $2)', [companyId, country ?? null]);
+}
+//# sourceMappingURL=upgrade.js.map

package/dist/pack/upgrade.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"upgrade.js","sourceRoot":"","sources":["../../src/pack/upgrade.ts"],"names":[],"mappings":"AAAA;;;;;;;;;GASG;AAEH,OAAO,EAAE,YAAY,EAAE,MAAM,eAAe,CAAC;AA4C7C;;;;;;GAMG;AACH,MAAM,CAAC,KAAK,UAAU,UAAU,CAAC,EAAa;IAC5C,MAAM,KAAK,GAAG,MAAM,EAAE,CAAC,KAAK,CAC1B,mEAAmE,CACpE,CAAC;IAEF,MAAM,SAAS,GAAG,MAAM,EAAE,CAAC,KAAK,CAQ9B;;;;;sBAKkB,CACnB,CAAC;IAEF,MAAM,MAAM,GAAwB,EAAE,CAAC;IACvC,KAAK,MAAM,GAAG,IAAI,SAAS,EAAE,CAAC;QAC5B,MAAM,KAAK,GAAsB;YAC/B,SAAS,EAAE,GAAG,CAAC,UAAU;YACzB,IAAI,EAAE,GAAG,CAAC,IAAI;YACd,OAAO,EAAE,GAAG,CAAC,OAAO;YACpB,SAAS,EAAE,GAAG,CAAC,UAAU;YACzB,WAAW,EAAE,GAAG,CAAC,YAAY;YAC7B,WAAW,EAAE,GAAG,CAAC,YAAY;YAC7B,MAAM,EAAE,GAAG,CAAC,YAAY,KAAK,IAAI,IAAI,GAAG,CAAC,YAAY,KAAK,IAAI,IAAI,GAAG,CAAC,YAAY,KAAK,GAAG,CAAC,YAAY;SACxG,CAAC;QACF,IAAI,GAAG,CAAC,YAAY,KAAK,IAAI,IAAI,GAAG,CAAC,YAAY,KAAK,IAAI,EAAE,CAAC;YAC3D,MAAM,MAAM,GAAG,MAAM,EAAE,CAAC,KAAK,CAC3B;oDAC4C,EAC5C,CAAC,GAAG,CAAC,UAAU,CAAC,CACjB,CAAC;YACF,MAAM,EAAE,GAAG,CAAC,IAAY,EAAU,EAAE,CAAC,MAAM,CAAC,MAAM,CAAC,IAAI,CAAC,CAAC,CAAC,EAAE,EAAE,CAAC,CAAC,CAAC,IAAI,KAAK,IAAI,CAAC,EAAE,KAAK,IAAI,GAAG,CAAC,CAAC;YAC/F,KAAK,CAAC,WAAW,GAAG;gBAClB,SAAS,EAAE,EAAE,CAAC,UAAU,CAAC;gBACzB,QAAQ,EAAE,EAAE,CAAC,SAAS,CAAC;gBACvB,MAAM,EAAE,EAAE,CAAC,QAAQ,CAAC;aACrB,CAAC;QACJ,CAAC;QACD,MAAM,CAAC,IAAI,CAAC,KAAK,CAAC,CAAC;IACrB,CAAC;IAED,OAAO,EAAE,KAAK,EAAE,SAAS,EAAE,MAAM,EAAE,CAAC;AACtC,CAAC;AAED;;;;;;;GAOG;AACH,MAAM,CAAC,KAAK,UAAU,cAAc,CAAC,EAAa,EAAE,MAAc;IAChE,MAAM,SAAS,GAAG,MAAM,EAAE,CAAC,KAAK,CAC9B,0DAA0D,CAC3D,CAAC;IACF,+DAA+D;IAC/D,OAAO,YAAY,CAAC,SAAS,EAAE,MAAM,CAAC,CAAC;AACzC,CAAC;AASD,MAAM,CAAC,KAAK,UAAU,WAAW,CAC/B,EAAa,EACb,SAAiB,EACjB,UAA0B,EAAE;IAE5B,MAAM,IAAI,GAAG,MAAM,EAAE,CAAC,KAAK,CACzB,iDAAiD,EACjD,CAAC,SAAS,EAAE,OAAO,CAAC,OAAO,IAAI,IAAI,EAAE,OAAO,CAAC,KAAK,KAAK,IAAI,CAAC,CAC7D,CAAC;IACF,MAAM,MAAM,GAAG,IAAI,CAAC,CAAC,CAAC,EAAE,YAAY,CAAC;IACrC,IAAI,MAAM,KAAK,SAAS;QAAE,MAAM,IAAI,KAAK,CAAC,+BAA+B,CAAC,CAAC;IAC3E,OAAO,MAAM,CAAC;AAChB,CAAC;AAED,8CAA8C;AAC9C,MAAM,CAAC,KAAK,UAAU,QAAQ,CAC5B,EAAa,EACb,SAAiB,EACjB,OAAgB;IAEhB,OAAO,EAAE,CAAC,KAAK,CACb,uFAAuF,EACvF,CAAC,SAAS,EAAE,OAAO,IAAI,IAAI,CAAC,CAC7B,CAAC;AACJ,CAAC"}

package/dist/pack/vat-codes.d.ts

@@ -0,0 +1,273 @@
+/**
+ * What a treatment obliges a tax to say on an invoice, and where.
+ *
+ * A tax carries three things that are three tellings of one fact: its
+ * `treatment`, which is Ekwo's own word for what the operation is; its
+ * `vat_category`, which is BT-118 and BT-151 of EN 16931, taken from the
+ * UNCL5305 subset the standard publishes; and its `exemption_code`, which is
+ * BT-121, taken from the VATEX list. Nothing until now compared them, so a
+ * pack could declare an export taxed at the standard rate, or an
+ * intra-Community supply with the reverse-charge reason code, and every test
+ * in the repository would pass — because neither column is read by the ledger
+ * or by the declaration. They are read by whoever renders the invoice, which
+ * is the one reader that is not in this repository.
+ *
+ * The tables below are transcribed, not decided. Three sources say all of it:
+ *
+ * - **UNCL5305 (UN/CEFACT D.16B, OpenPEPPOL subset)** for what each category
+ *   code means. `K` is *VAT exempt for EEA intra-community supply of goods and
+ *   services* — goods **and services**, which is what settles the question the
+ *   Ekwo vocabulary asks twice; `AE` is *VAT reverse charge*; `G` is *free
+ *   export item, VAT not charged*; `O` is *services outside scope of tax*.
+ * - **Technical guidance for tax codes in EN 16931, version 1** (European
+ *   Commission, Technical Advisory Group on Electronic Invoicing, use cases
+ *   dated 1 July 2024), whose six use cases give the pair to use for each
+ *   case: exemption in general `E` + a VATEX code, intra-Community supply
+ *   between Member States `K` + `VATEX-EU-IC`, reverse charge **within** a
+ *   Member State `AE` + `VATEX-EU-AE`, and the case it calls export outside the
+ *   Union `G` + `VATEX-EU-G` — which is the Union's border because the seller
+ *   the guidance addresses is established in a Member State. What UNCL5305
+ *   itself says of `G` is *free export item, VAT not charged*: the goods leave
+ *   the territory of whoever levies the tax.
+ * - **The VATEX code list itself**, which carries the pairing as a remark on
+ *   eight of its codes: `VATEX-EU-AE` *only use with category code AE*,
+ *   `VATEX-EU-IC` with `K`, `VATEX-EU-G` with `G`, `VATEX-EU-O` with `O`, and
+ *   `VATEX-EU-D`, `-F`, `-I`, `-J` with `E`.
+ *
+ * Four decisions were taken where the sources leave a choice, and all four are
+ * written up in `docs/packs.md`.
+ *
+ * **The table above is the Union's, and it applies where the Union's VAT
+ * does.** EN 16931 is a European standard and the VATEX list is published by
+ * the European Commission: its own codes name articles of Directive
+ * 2006/112/EC and its national codes belong to Member States that publish
+ * them. A pack for a country the common system does not reach may therefore
+ * carry no code from it — `VATEX-EU-G` on an export from a third country
+ * claims an article of the Directive that does not bind the seller — and what
+ * an exempt line states there is its own article, in `legal_reference`, with
+ * BT-121 left empty. The categories are unaffected: UNCL5305 is a UN/CEFACT
+ * list, `E`, `G`, `O` and `AE` keep their meanings, and a pack outside the
+ * Union goes on being held to them. The treatments of the common system
+ * itself — the five `intracom_*` values — are refused there outright, because
+ * an intra-Community supply is an operation of a system the country is not in.
+ * Whether it is in it is not a fact this file holds: it is a row of
+ * `territories`, read through `./territories.js`, on the day the pack's
+ * manifest says it speaks of.
+ *
+ * **A category is required where a category is read.** The rule above says
+ * what a category may be, and it holds everywhere. What does not is the
+ * obligation to name one: BT-151 is a term of an invoice governed by EN 16931,
+ * and the first pack of a country that levies no value added tax was asked for
+ * one on every tax that can reach a sale although no American invoice carries
+ * the field, no administration there publishes a category list, and nobody
+ * would have read the answer. So the requirement is asked where the invoice
+ * exists — inside the common system, or where the pack declares an e-invoicing
+ * profile, each of which carries BT-151 — and `readsCategories` is the
+ * caller's answer. Outside both, the column is free and everything it may say
+ * is unchanged: a value that contradicts the treatment is refused there
+ * exactly as it is here. This is the same border ST38-1 drew for the reason
+ * code, one field over: the Union's lists reach the packs the Union's law
+ * reaches.
+ *
+ * **A category is a term of the invoice, so on a purchase it is the
+ * supplier's.** An Ekwo purchase tax describes how the buyer books and
+ * declares somebody else's invoice; BT-151 on that invoice was chosen by the
+ * seller. An intra-Community acquisition is therefore `K`, because the
+ * supplier made an intra-Community supply and rule BR-IC-10 binds them to `K`
+ * and `VATEX-EU-IC` — not `AE`, which is the guidance's case for a reverse
+ * charge *within* one Member State. A pack that does not want to record the
+ * seller's category may leave it null on a purchase-only tax; a value that
+ * contradicts the treatment is refused either way.
+ *
+ * **Where no invoice governed by the standard exists, the category is
+ * absent.** An import of goods is assessed on a customs document, and a
+ * service received from a supplier the Union's rules do not reach comes on an
+ * invoice the Directive does not govern. There is no seller's category to
+ * record, so `import` and `foreign_services_received` carry none: `S` there
+ * would claim the supplier levied the standard rate, which is the one thing
+ * that certainly did not happen.
+ *
+ * **A triangular supply is `K`, not `AE`.** The guidance gives `AE` for a
+ * reverse charge *within* one Member State, where the supplier is established
+ * in the buyer's country and national law moves the liability. The middle
+ * supply of a triangular arrangement is the opposite shape: the goods leave
+ * the seller's State, article 141 of Directive 2006/112/EC relieves the seller
+ * of registering where they arrive, and article 197 puts the tax on a customer
+ * in a third State. What the line is, in the words of UNCL5305, is *VAT exempt
+ * for EEA intra-community supply of goods and services* — `K`, with
+ * `VATEX-EU-IC`, which the VATEX list reserves for it. That the *sentence* on
+ * that invoice is the reverse-charge one is a different question in a different
+ * vocabulary, and it is answered by `applies_when`.
+ *
+ * The rate is checked on the sale side only. On a sale the pack's `rate` is
+ * the BT-152 the seller prints, and the business rules of EN 16931 fix it per
+ * category — BR-S-05 wants a standard-rated line above zero, BR-Z-05,
+ * BR-E-05, BR-AE-05, BR-IC-05, BR-G-05 and BR-O-05 want zero everywhere else.
+ * On a purchase the rate is the one the buyer self-assesses at, which is
+ * 21 % on a line the supplier invoiced at zero, so the same rule applied there
+ * would refuse every reverse charge in every pack.
+ *
+ * What this does **not** do is hold a copy of the VATEX list. The list grows,
+ * two published renderings of it already disagree on which codes it holds, and
+ * a code this file has not heard of is not a contradiction — it is a code this
+ * file has not heard of. So an exemption code is checked for its shape, and
+ * for the pairings the list itself states.
+ *
+ * The same limit applies to the other end. No country outside the Union
+ * publishes a list of exemption reason codes today; one may, and PINT is where
+ * it would surface. So the field is provided for and the content is not: a pack
+ * outside the common system may carry a reason code that is not a VATEX one,
+ * on the condition that its register declares a published list — the entry of
+ * `certification.sources` that says so of itself, with `reason_codes`. What is
+ * checked is that a list is named, not that the code is in it, which is exactly
+ * what is checked of a VATEX code inside the Union.
+ *
+ * That flag is new and it closes a trap. `reasonList` used to be the title of
+ * the **first** entry whose `kind` was `standard`, and `standard` means "a
+ * technical norm or code list" — which the FASB Accounting Standards
+ * Codification and FRS 102 both are. Naming an accounting standard therefore
+ * authorised a reason code on any tax of the pack, silently, in declaration
+ * order. No pack ever carried one and nothing wrong was emitted; an entry now
+ * says which list it is, and `ekwo pack check` refuses a second one.
+ */
+/** What one treatment may be declared on, and what its invoice may say. */
+export interface TreatmentCodes {
+    /**
+     * The sides of a document the treatment exists on. A tax whose `scope` is
+     * `both` is never refused here: `both` says the pack has not narrowed it.
+     */
+    scopes: ('sale' | 'purchase')[];
+    /**
+     * The categories the invoice may carry. Empty where no invoice governed by
+     * EN 16931 exists, in which case the column has to stay null.
+     */
+    categories: string[];
+    /** Why, in the words of the source, for the message. */
+    because: string;
+    /**
+     * True where the treatment is an operation of the common system of VAT and
+     * exists nowhere else — the five `intracom_*` values, which name a supply
+     * between two Member States. A pack for a country the system does not reach
+     * is refused one of these before anything else about it is looked at.
+     */
+    commonSystem?: true;
+    /**
+     * True where the operation is a supply or an acquisition of **goods**, and
+     * not of services.
+     *
+     * Only one territory has ever needed the distinction and it is the one the
+     * Withdrawal Agreement invented: `eu_vat_scope` of `XI` is `goods`, so the
+     * common system reaches a tax applying in Northern Ireland exactly where its
+     * treatment is marked here and nowhere else. Everywhere the scope is `full`
+     * or `none` this field is not read.
+     */
+    goods?: true;
+}
+/**
+ * Treatment to category, keyed by the values of the `tax_treatment` enum.
+ *
+ * A treatment missing from here is a gap the check cannot see, so
+ * `tests/vat_codes.test.ts` asks the database for the enum and refuses a
+ * value this table does not cover.
+ */
+export declare const TREATMENT_CODES: Record<string, TreatmentCodes>;
+/** What a category obliges the exemption reason to be. */
+interface CategoryCodes {
+    /** The one code the VATEX list reserves for this category, where it does. */
+    exemption: string | null;
+    /** A reason is required. False where the line is taxed and has none. */
+    needsReason: boolean;
+    /** The rate a sale of this category carries: above zero, or exactly zero. */
+    rate: 'positive' | 'zero';
+    /** The business rule of EN 16931 that fixes the rate. */
+    rateRule: string;
+}
+/**
+ * Category to exemption reason and to rate.
+ *
+ * The four reserved codes are the pairings the VATEX list publishes as a
+ * remark on the code itself. `E` takes any other reason, because the whole
+ * point of the general case is that the seller picks the article.
+ */
+export declare const CATEGORY_CODES: Record<string, CategoryCodes>;
+/** One tax, as much of it as this check reads. */
+export interface TaxCodes {
+    code: string;
+    scope: string;
+    amount_type: string;
+    rate: number;
+    treatment: string;
+    vat_category: string | null;
+    exemption_code: string | null;
+    /**
+     * The article the tax claims. Outside the common system it is what an exempt
+     * line has instead of a reason code, so the check reads it there.
+     */
+    legal_reference?: string | null;
+}
+/**
+ * Which VAT a pack's country levies, as far as these three lists are concerned.
+ *
+ * Resolved by the caller, because the answer is a row of `territories` and a
+ * date out of the manifest, and neither belongs in a table of code lists.
+ * `because` is quoted verbatim in every refusal that turns on it, so a reader
+ * of the message is told the country, the day and the scope rather than being
+ * left to guess why a code they read in the standard was refused.
+ */
+export interface VatRegime {
+    /** Whether the common system of VAT reached the country on the day the pack speaks of. */
+    commonSystem: boolean;
+    /** Said in the words of the table, for the message. */
+    because: string;
+    /**
+     * Whether an invoice this country's sellers issue carries BT-151 at all.
+     *
+     * The categories themselves are UNCL5305, a UN/CEFACT list, and they hold
+     * everywhere: an export is `G` in California as in Belgium, and a value that
+     * contradicts the treatment is refused wherever the pack is. What does not
+     * hold everywhere is the *requirement*. BT-151 is a term of an invoice
+     * governed by EN 16931, and a country outside the common system of VAT whose
+     * sellers issue no such invoice has no seller's category to demand: the
+     * requirement would be a European standard asking a question nobody reads
+     * the answer to. So it is asked where a category is read — inside the common
+     * system, or where the pack declares an e-invoicing profile, every one of
+     * which carries BT-151 — and a pack that issues no standardised invoice may
+     * leave the column null, the way a purchase-only tax already may.
+     *
+     * Resolved by the caller, because the answer is a row of `territories` and a
+     * field of the manifest, neither of which belongs in a table of code lists.
+     */
+    readsCategories: boolean;
+    /**
+     * The published list of reason codes the pack's register declares — the
+     * title of the entry of `certification.sources` that says so of itself, with
+     * `reason_codes`. Null where the pack declares none, which outside the Union
+     * means BT-121 has no list to come from and stays empty.
+     */
+    reasonList: string | null;
+}
+/**
+ * The regime every pack was held to until a country outside the Union arrived.
+ *
+ * The default of `taxCodes`, so that a caller with no opinion gets the table as
+ * the European Commission publishes it. `readPack` always has an opinion.
+ */
+export declare const COMMON_SYSTEM: VatRegime;
+/** A problem, in the shape `readPack` collects. */
+export interface CodeIssue {
+    path: string;
+    message: string;
+}
+/**
+ * The taxes of a pack, against the three code lists.
+ *
+ * Every refusal names the tax, the treatment, what the tax says, what the
+ * source says instead, and the source. A pack author who has never read
+ * EN 16931 should be able to fix the line from the message alone.
+ *
+ * `regime` says whether the Union's own lists reach this pack at all. It
+ * defaults to the case every pack was in before a third country arrived.
+ */
+export declare function taxCodes(taxes: TaxCodes[], regime?: VatRegime | ((tax: TaxCodes) => VatRegime)): CodeIssue[];
+export {};
+//# sourceMappingURL=vat-codes.d.ts.map

package/dist/pack/vat-codes.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"vat-codes.d.ts","sourceRoot":"","sources":["../../src/pack/vat-codes.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAmIG;AAOH,2EAA2E;AAC3E,MAAM,WAAW,cAAc;IAC7B;;;OAGG;IACH,MAAM,EAAE,CAAC,MAAM,GAAG,UAAU,CAAC,EAAE,CAAC;IAChC;;;OAGG;IACH,UAAU,EAAE,MAAM,EAAE,CAAC;IACrB,wDAAwD;IACxD,OAAO,EAAE,MAAM,CAAC;IAChB;;;;;OAKG;IACH,YAAY,CAAC,EAAE,IAAI,CAAC;IACpB;;;;;;;;;OASG;IACH,KAAK,CAAC,EAAE,IAAI,CAAC;CACd;AAED;;;;;;GAMG;AACH,eAAO,MAAM,eAAe,EAAE,MAAM,CAAC,MAAM,EAAE,cAAc,CA+F1D,CAAC;AAEF,0DAA0D;AAC1D,UAAU,aAAa;IACrB,6EAA6E;IAC7E,SAAS,EAAE,MAAM,GAAG,IAAI,CAAC;IACzB,wEAAwE;IACxE,WAAW,EAAE,OAAO,CAAC;IACrB,6EAA6E;IAC7E,IAAI,EAAE,UAAU,GAAG,MAAM,CAAC;IAC1B,yDAAyD;IACzD,QAAQ,EAAE,MAAM,CAAC;CAClB;AAED;;;;;;GAMG;AACH,eAAO,MAAM,cAAc,EAAE,MAAM,CAAC,MAAM,EAAE,aAAa,CAQxD,CAAC;AA4BF,kDAAkD;AAClD,MAAM,WAAW,QAAQ;IACvB,IAAI,EAAE,MAAM,CAAC;IACb,KAAK,EAAE,MAAM,CAAC;IACd,WAAW,EAAE,MAAM,CAAC;IACpB,IAAI,EAAE,MAAM,CAAC;IACb,SAAS,EAAE,MAAM,CAAC;IAClB,YAAY,EAAE,MAAM,GAAG,IAAI,CAAC;IAC5B,cAAc,EAAE,MAAM,GAAG,IAAI,CAAC;IAC9B;;;OAGG;IACH,eAAe,CAAC,EAAE,MAAM,GAAG,IAAI,CAAC;CACjC;AAED;;;;;;;;GAQG;AACH,MAAM,WAAW,SAAS;IACxB,0FAA0F;IAC1F,YAAY,EAAE,OAAO,CAAC;IACtB,uDAAuD;IACvD,OAAO,EAAE,MAAM,CAAC;IAChB;;;;;;;;;;;;;;;;;OAiBG;IACH,eAAe,EAAE,OAAO,CAAC;IACzB;;;;;OAKG;IACH,UAAU,EAAE,MAAM,GAAG,IAAI,CAAC;CAC3B;AAED;;;;;GAKG;AACH,eAAO,MAAM,aAAa,EAAE,SAK3B,CAAC;AAEF,mDAAmD;AACnD,MAAM,WAAW,SAAS;IACxB,IAAI,EAAE,MAAM,CAAC;IACb,OAAO,EAAE,MAAM,CAAC;CACjB;AAkGD;;;;;;;;;GASG;AACH,wBAAgB,QAAQ,CACtB,KAAK,EAAE,QAAQ,EAAE,EACjB,MAAM,GAAE,SAAS,GAAG,CAAC,CAAC,GAAG,EAAE,QAAQ,KAAK,SAAS,CAAiB,GACjE,SAAS,EAAE,CA+Jb"}