@formfeed/engine 0.3.10 → 0.3.12

package/types/lib/einvoice/check.d.ts

@@ -0,0 +1,181 @@
+import { type EinvoiceProfile, type VatCategory } from './schema.js';
+/**
+ * Reads an `_invoice` block against EN 16931 (spec 17 §4.3): the shape first, then the rules a
+ * request can be held to before anything is rendered. What comes out is either the invoice with
+ * every number as exact decimal text, ready for the XML, or the list of what is wrong, each finding
+ * with the field and the rule it breaks.
+ *
+ * Nothing is computed for the caller and nothing is rounded into place. A total that is a cent off
+ * is a finding, because an e-invoice whose XML disagrees with the seller's books is a tax problem,
+ * and correcting it here would hide exactly that.
+ *
+ * The full rule set (the official schematron, some 430 assertions) runs in the sidecar on every
+ * document. This is the part worth knowing early: it needs no JVM, so the gateway answers a bad
+ * request at once, and the editor and the CLI say the same thing offline.
+ */
+export interface InvoiceProblem {
+    /** What kind of finding, for a caller that words it in its own language. */
+    code: InvoiceProblemCode;
+    /** The field inside `_invoice`, dotted, list items as `lines[1]` (zero-based). */
+    path: string;
+    /** The rule of EN 16931 (`BR-CO-15`) or of the French specifications (`BR-FR-10`), where one applies. */
+    rule?: string;
+    /** The same in English, naming the field and the rule. */
+    message: string;
+    /** The values `message` was built from. */
+    args: Record<string, string | number>;
+}
+export type InvoiceProblemCode = 'missing' | 'invalid' | 'not_a_number' | 'decimals' | 'negative' | 'code_list' | 'date' | 'date_order' | 'scheme_required' | 'vat_id_prefix' | 'iban' | 'sum' | 'breakdown_missing' | 'breakdown_duplicate' | 'rate_required' | 'rate_positive' | 'rate_zero' | 'rate_forbidden' | 'amount_zero' | 'exemption_reason_required' | 'exemption_reason_forbidden' | 'seller_tax_id_required' | 'buyer_tax_id_required' | 'vat_id_forbidden' | 'only_category' | 'delivery_required' | 'account_required' | 'means_code_required' | 'due_or_terms_required' | 'seller_identifier_required' | 'siren_mismatch' | 'fr_seller_siren' | 'fr_buyer_siren' | 'fr_operation' | 'fr_vat_on_debits' | 'profile';
+export interface Identifier {
+    value: string;
+    scheme?: string;
+}
+export interface InvoiceAddress {
+    street?: string;
+    street2?: string;
+    street3?: string;
+    postcode?: string;
+    city?: string;
+    country: string;
+    subdivision?: string;
+}
+export interface InvoiceParty {
+    name: string;
+    trading_name?: string;
+    id?: Identifier;
+    legal_registration?: Identifier;
+    vat_id?: string;
+    address: InvoiceAddress;
+    contact?: {
+        name?: string;
+        phone?: string;
+        email?: string;
+    };
+    electronic_address?: Required<Identifier>;
+}
+export interface InvoiceAllowance {
+    amount: string;
+    reason?: string;
+    reason_code?: string;
+    base_amount?: string;
+    percent?: string;
+}
+export interface InvoiceTax {
+    category: VatCategory;
+    /** Percent as decimal text; absent for category O only. */
+    rate?: string;
+}
+export interface InvoiceLine {
+    id: string;
+    name: string;
+    description?: string;
+    quantity: string;
+    unit_code: string;
+    net_price: string;
+    price_base_quantity?: string;
+    net_amount: string;
+    tax: InvoiceTax;
+    period?: {
+        start?: string;
+        end?: string;
+    };
+    allowances: InvoiceAllowance[];
+    charges: InvoiceAllowance[];
+    buyer_accounting_reference?: string;
+    note?: string;
+    seller_item_id?: string;
+    buyer_item_id?: string;
+    standard_item_id?: Identifier;
+    order_line_reference?: string;
+}
+export interface InvoiceBreakdown extends InvoiceTax {
+    basis: string;
+    amount: string;
+    exemption_reason?: string;
+    exemption_reason_code?: string;
+}
+/**
+ * An invoice that passed: every amount is decimal text with at most two places, every code is in
+ * its list, and the totals add up. The XML is written from this and from nothing else.
+ */
+export interface Invoice {
+    number: string;
+    issue_date: string;
+    type_code: string;
+    currency: string;
+    accounting_currency?: string;
+    buyer_reference?: string;
+    order_reference?: string;
+    contract_reference?: string;
+    notes: Array<{
+        text: string;
+        subject_code?: string;
+    }>;
+    period?: {
+        start?: string;
+        end?: string;
+    };
+    preceding_invoices: Array<{
+        number: string;
+        issue_date?: string;
+    }>;
+    /** The business process (BT-23); French invoices carry their billing framework here. */
+    business_process?: string;
+    seller: InvoiceParty & {
+        tax_number?: string;
+        legal_info?: string;
+        vat_on_debits?: boolean;
+    };
+    buyer: InvoiceParty;
+    delivery?: {
+        name?: string;
+        date?: string;
+        address?: InvoiceAddress;
+    };
+    lines: InvoiceLine[];
+    allowances: Array<InvoiceAllowance & {
+        tax: InvoiceTax;
+    }>;
+    charges: Array<InvoiceAllowance & {
+        tax: InvoiceTax;
+    }>;
+    breakdown: InvoiceBreakdown[];
+    totals: {
+        line_net: string;
+        allowances?: string;
+        charges?: string;
+        tax_basis: string;
+        tax_total: string;
+        tax_total_accounting?: string;
+        grand: string;
+        prepaid?: string;
+        rounding?: string;
+        due: string;
+    };
+    payment?: {
+        means_code?: string;
+        iban?: string;
+        bic?: string;
+        account_name?: string;
+        reference?: string;
+        terms?: string;
+        due_date?: string;
+        mandate_id?: string;
+        creditor_id?: string;
+        debited_iban?: string;
+    };
+}
+export type InvoiceCheck = {
+    ok: true;
+    invoice: Invoice;
+    problems: [];
+} | {
+    ok: false;
+    invoice: null;
+    problems: InvoiceProblem[];
+};
+export interface CheckOptions {
+    /** The profile the XML will be written in; `basic` cannot carry everything `en16931` can. */
+    profile?: EinvoiceProfile;
+}
+export declare function checkInvoice(data: unknown, options?: CheckOptions): InvoiceCheck;

package/types/lib/einvoice/cii.d.cts

@@ -0,0 +1,18 @@
+import type { Invoice } from './check.cjs';
+import type { EinvoiceProfile } from './schema.cjs';
+/**
+ * A checked invoice as Cross Industry Invoice XML, the syntax ZUGFeRD and Factur-X embed (spec 17
+ * §3, §5). The element order is the schema's: the XSD of a profile is a sequence, and an element in
+ * the wrong place fails before any business rule is looked at.
+ *
+ * The output is a function of the invoice and the profile alone. No date of writing, no generator
+ * comment, no locale: two renders of the same data embed the same bytes, and the golden files in
+ * `fixtures/` pin them.
+ */
+/** The identifier a document names its profile by (BT-24). */
+export declare const CII_GUIDELINES: Record<EinvoiceProfile, string>;
+/** The name the XML has inside the PDF, under either of the specification's two names. */
+export declare const EINVOICE_XML_NAME = "factur-x.xml";
+export declare function invoiceToCii(invoice: Invoice, options: {
+    profile: EinvoiceProfile;
+}): string;

package/types/lib/einvoice/cii.d.ts

@@ -0,0 +1,18 @@
+import type { Invoice } from './check.js';
+import type { EinvoiceProfile } from './schema.js';
+/**
+ * A checked invoice as Cross Industry Invoice XML, the syntax ZUGFeRD and Factur-X embed (spec 17
+ * §3, §5). The element order is the schema's: the XSD of a profile is a sequence, and an element in
+ * the wrong place fails before any business rule is looked at.
+ *
+ * The output is a function of the invoice and the profile alone. No date of writing, no generator
+ * comment, no locale: two renders of the same data embed the same bytes, and the golden files in
+ * `fixtures/` pin them.
+ */
+/** The identifier a document names its profile by (BT-24). */
+export declare const CII_GUIDELINES: Record<EinvoiceProfile, string>;
+/** The name the XML has inside the PDF, under either of the specification's two names. */
+export declare const EINVOICE_XML_NAME = "factur-x.xml";
+export declare function invoiceToCii(invoice: Invoice, options: {
+    profile: EinvoiceProfile;
+}): string;

package/types/lib/einvoice/codes.generated.d.cts

@@ -0,0 +1,14 @@
+/** The Factur-X release these lists were taken from. */
+export declare const CODE_LIST_RELEASE = "1.09.2";
+/** Invoice type code (BT-3), UNTDID 1001. 62 codes. */
+export declare const documentTypeCodes: ReadonlySet<string>;
+/** Country codes (BT-40, BT-55, BT-80), ISO 3166-1 alpha-2. 253 codes. */
+export declare const countryCodes: ReadonlySet<string>;
+/** Units of measure (BT-130, BT-150), UN/ECE Recommendation 20 with 21. 2162 codes. */
+export declare const unitCodes: ReadonlySet<string>;
+/** Electronic address schemes (BT-34, BT-49), the EAS list. 102 codes. */
+export declare const electronicAddressSchemes: ReadonlySet<string>;
+/** Currencies (BT-5, BT-6), ISO 4217. 178 codes. */
+export declare const currencyCodes: ReadonlySet<string>;
+/** Payment means (BT-81), UNTDID 4461. 84 codes. */
+export declare const paymentMeansCodes: ReadonlySet<string>;

package/types/lib/einvoice/codes.generated.d.ts

@@ -0,0 +1,14 @@
+/** The Factur-X release these lists were taken from. */
+export declare const CODE_LIST_RELEASE = "1.09.2";
+/** Invoice type code (BT-3), UNTDID 1001. 62 codes. */
+export declare const documentTypeCodes: ReadonlySet<string>;
+/** Country codes (BT-40, BT-55, BT-80), ISO 3166-1 alpha-2. 253 codes. */
+export declare const countryCodes: ReadonlySet<string>;
+/** Units of measure (BT-130, BT-150), UN/ECE Recommendation 20 with 21. 2162 codes. */
+export declare const unitCodes: ReadonlySet<string>;
+/** Electronic address schemes (BT-34, BT-49), the EAS list. 102 codes. */
+export declare const electronicAddressSchemes: ReadonlySet<string>;
+/** Currencies (BT-5, BT-6), ISO 4217. 178 codes. */
+export declare const currencyCodes: ReadonlySet<string>;
+/** Payment means (BT-81), UNTDID 4461. 84 codes. */
+export declare const paymentMeansCodes: ReadonlySet<string>;

package/types/lib/einvoice/decimal.d.cts

@@ -0,0 +1,29 @@
+/**
+ * Exact decimals for an invoice. Totals are compared to the cent and written into the XML as text,
+ * so nothing here goes through floating-point arithmetic: a value is read once into its decimal
+ * text and from there into a `bigint` of the smallest unit the comparison needs.
+ */
+/**
+ * The decimal text of a JSON number or a numeric string, without an exponent and without trailing
+ * zeros; `null` when it is not a plain decimal.
+ *
+ * A number is taken at fifteen significant digits, which is every digit a double holds exactly: a
+ * request built with ordinary arithmetic sends `0.30000000000000004` for thirty cents, and refusing
+ * that as "more than two decimals" would punish the language, not the invoice. A string is taken
+ * as written, since whoever sends `"0.300000000000000004"` typed those digits.
+ */
+export declare function decimalText(value: unknown): string | null;
+/** How many decimal places a decimal text carries. */
+export declare function decimalPlaces(text: string): number;
+/**
+ * A decimal text as an integer of `10^-scale` units. The text must not carry more places than
+ * `scale`; callers check that first and name the field, because that is a finding about the data.
+ */
+export declare function toUnits(text: string, scale: number): bigint;
+/** Integer units back to decimal text with exactly `places` decimals (`376040n, 2` → `3760.40`). */
+export declare function fromUnits(units: bigint, scale: number, places?: number): string;
+/** A decimal text padded to at least `min` decimals, as the XML writes amounts (`3760.4` → `3760.40`). */
+export declare function withPlaces(text: string, min: number): string;
+/** `value / divisor`, rounded half away from zero, as the standard rounds a VAT amount. */
+export declare function divideRounded(value: bigint, divisor: bigint): bigint;
+export declare const abs: (value: bigint) => bigint;

package/types/lib/einvoice/decimal.d.ts

@@ -0,0 +1,29 @@
+/**
+ * Exact decimals for an invoice. Totals are compared to the cent and written into the XML as text,
+ * so nothing here goes through floating-point arithmetic: a value is read once into its decimal
+ * text and from there into a `bigint` of the smallest unit the comparison needs.
+ */
+/**
+ * The decimal text of a JSON number or a numeric string, without an exponent and without trailing
+ * zeros; `null` when it is not a plain decimal.
+ *
+ * A number is taken at fifteen significant digits, which is every digit a double holds exactly: a
+ * request built with ordinary arithmetic sends `0.30000000000000004` for thirty cents, and refusing
+ * that as "more than two decimals" would punish the language, not the invoice. A string is taken
+ * as written, since whoever sends `"0.300000000000000004"` typed those digits.
+ */
+export declare function decimalText(value: unknown): string | null;
+/** How many decimal places a decimal text carries. */
+export declare function decimalPlaces(text: string): number;
+/**
+ * A decimal text as an integer of `10^-scale` units. The text must not carry more places than
+ * `scale`; callers check that first and name the field, because that is a finding about the data.
+ */
+export declare function toUnits(text: string, scale: number): bigint;
+/** Integer units back to decimal text with exactly `places` decimals (`376040n, 2` → `3760.40`). */
+export declare function fromUnits(units: bigint, scale: number, places?: number): string;
+/** A decimal text padded to at least `min` decimals, as the XML writes amounts (`3760.4` → `3760.40`). */
+export declare function withPlaces(text: string, min: number): string;
+/** `value / divisor`, rounded half away from zero, as the standard rounds a VAT amount. */
+export declare function divideRounded(value: bigint, divisor: bigint): bigint;
+export declare const abs: (value: bigint) => bigint;

package/types/lib/einvoice/display.d.cts

@@ -0,0 +1,43 @@
+import type { Invoice } from './check.cjs';
+/**
+ * The display check (spec 17 §5.2). In a hybrid invoice the XML is the invoice, and a PDF that shows
+ * other details can count as a second one. Nothing makes a template print `_invoice`: one that adds
+ * up its own totals, or shows another field's number, renders without complaint. So the text of the
+ * finished PDF is searched for what the XML says: the invoice number and the totals.
+ *
+ * It finds a value that is missing, not a wrong one printed beside the right one. It is a net, not
+ * a proof, and it errs towards "shown": signs are ignored, because a credit note prints as negative
+ * what its XML states as positive, and a number counts in either notation, `1.234,56` or `1,234.56`.
+ *
+ * One function for the worker (the text the sidecar extracts), the editor (the preview's text) and
+ * the CLI, so all three agree on what "shown" means.
+ */
+export interface DisplayValue {
+    /** The business term of EN 16931, `BT-112`. */
+    term: string;
+    /** Where the value sits in `_invoice`. */
+    path: string;
+    /** The value as the XML states it. */
+    value: string;
+    shown: boolean;
+}
+export interface DisplayCheck {
+    /** The terms that were looked for, in the order they were checked. */
+    checked: string[];
+    /** Those of them the text does not show. */
+    missing: string[];
+    values: DisplayValue[];
+}
+/** What a term is called where a message names it. */
+export declare const DISPLAY_TERMS: Record<string, string>;
+/**
+ * Every amount the text shows, in cents and without its sign. A run of digits and separators is
+ * read each way it can be read: `3.760` is three thousand seven hundred and sixty and also three
+ * point seven six, and `8 120,00` is both that number and `120,00` after an `8`. A line break never
+ * joins two numbers, so a page number above a total does not become part of it.
+ */
+export declare function shownAmounts(text: string): Set<bigint>;
+/** The text of a PDF (one string, or one per page) against the invoice its XML states. */
+export declare function displayCheck(text: string | readonly string[], invoice: Invoice): DisplayCheck;
+/** The values a check did not find, as one sentence for a problem or a warning; `null` when all are shown. */
+export declare function displayMissingText(check: DisplayCheck): string | null;

package/types/lib/einvoice/display.d.ts

@@ -0,0 +1,43 @@
+import type { Invoice } from './check.js';
+/**
+ * The display check (spec 17 §5.2). In a hybrid invoice the XML is the invoice, and a PDF that shows
+ * other details can count as a second one. Nothing makes a template print `_invoice`: one that adds
+ * up its own totals, or shows another field's number, renders without complaint. So the text of the
+ * finished PDF is searched for what the XML says: the invoice number and the totals.
+ *
+ * It finds a value that is missing, not a wrong one printed beside the right one. It is a net, not
+ * a proof, and it errs towards "shown": signs are ignored, because a credit note prints as negative
+ * what its XML states as positive, and a number counts in either notation, `1.234,56` or `1,234.56`.
+ *
+ * One function for the worker (the text the sidecar extracts), the editor (the preview's text) and
+ * the CLI, so all three agree on what "shown" means.
+ */
+export interface DisplayValue {
+    /** The business term of EN 16931, `BT-112`. */
+    term: string;
+    /** Where the value sits in `_invoice`. */
+    path: string;
+    /** The value as the XML states it. */
+    value: string;
+    shown: boolean;
+}
+export interface DisplayCheck {
+    /** The terms that were looked for, in the order they were checked. */
+    checked: string[];
+    /** Those of them the text does not show. */
+    missing: string[];
+    values: DisplayValue[];
+}
+/** What a term is called where a message names it. */
+export declare const DISPLAY_TERMS: Record<string, string>;
+/**
+ * Every amount the text shows, in cents and without its sign. A run of digits and separators is
+ * read each way it can be read: `3.760` is three thousand seven hundred and sixty and also three
+ * point seven six, and `8 120,00` is both that number and `120,00` after an `8`. A line break never
+ * joins two numbers, so a page number above a total does not become part of it.
+ */
+export declare function shownAmounts(text: string): Set<bigint>;
+/** The text of a PDF (one string, or one per page) against the invoice its XML states. */
+export declare function displayCheck(text: string | readonly string[], invoice: Invoice): DisplayCheck;
+/** The values a check did not find, as one sentence for a problem or a warning; `null` when all are shown. */
+export declare function displayMissingText(check: DisplayCheck): string | null;

package/types/lib/einvoice/html-text.d.cts

@@ -0,0 +1,17 @@
+/**
+ * The text of a rendered HTML document, for the display check before anything is rendered to PDF
+ * (spec 17 §5.2, §8): the editor holds the preview's document against the invoice, and the CLI the
+ * document it renders locally. The render itself checks the text of the finished PDF, which the
+ * sidecar extracts; this is the early warning, and it reads the markup, not the page.
+ *
+ * So it does not know what CSS hides or generates. What it must get right is where one number ends
+ * and the next begins: two table cells are two amounts, and an amount set in two `<span>`s is one.
+ * Elements that flow in a line join their text; every other element ends the line.
+ *
+ * No DOM is used: the engine runs in a Worker and in Node as well as in the browser.
+ */
+/**
+ * The text a reader of `html` sees, as far as the markup says: comments, scripts and styles left
+ * out, references decoded, and a line break wherever an element that is not inline starts or ends.
+ */
+export declare function htmlText(html: string): string;

package/types/lib/einvoice/html-text.d.ts

@@ -0,0 +1,17 @@
+/**
+ * The text of a rendered HTML document, for the display check before anything is rendered to PDF
+ * (spec 17 §5.2, §8): the editor holds the preview's document against the invoice, and the CLI the
+ * document it renders locally. The render itself checks the text of the finished PDF, which the
+ * sidecar extracts; this is the early warning, and it reads the markup, not the page.
+ *
+ * So it does not know what CSS hides or generates. What it must get right is where one number ends
+ * and the next begins: two table cells are two amounts, and an amount set in two `<span>`s is one.
+ * Elements that flow in a line join their text; every other element ends the line.
+ *
+ * No DOM is used: the engine runs in a Worker and in Node as well as in the browser.
+ */
+/**
+ * The text a reader of `html` sees, as far as the markup says: comments, scripts and styles left
+ * out, references decoded, and a line break wherever an element that is not inline starts or ends.
+ */
+export declare function htmlText(html: string): string;

package/types/lib/einvoice/index.d.cts

@@ -0,0 +1,45 @@
+/**
+ * `@formfeed/engine/einvoice` (spec 17): the `_invoice` block, the rules it is held to, the CII XML
+ * written from it and the display check. No template engine is imported here and nothing of Node,
+ * so the gateway Worker, the render-worker, the editor and the CLI all run the same code: what the
+ * API refuses, the editor has already said.
+ */
+import { type Invoice, type InvoiceProblem } from './check.cjs';
+import type { EinvoiceFlavour, EinvoiceProfile } from './schema.cjs';
+export { checkInvoice, type CheckOptions, type Identifier, type Invoice, type InvoiceAddress, type InvoiceAllowance, type InvoiceBreakdown, type InvoiceCheck, type InvoiceLine, type InvoiceParty, type InvoiceProblem, type InvoiceProblemCode, type InvoiceTax, } from './check.cjs';
+export { CII_GUIDELINES, EINVOICE_XML_NAME, invoiceToCii } from './cii.cjs';
+export { CODE_LIST_RELEASE } from './codes.generated.cjs';
+export { DISPLAY_TERMS, displayCheck, displayMissingText, shownAmounts, type DisplayCheck, type DisplayValue, } from './display.cjs';
+export { EINVOICE_FLAVOURS, EINVOICE_PROFILES, VAT_CATEGORIES, defaultEinvoiceOptions, einvoiceOptionsSchema, invoiceSchema, resolveEinvoiceOptions, type EinvoiceFlavour, type EinvoiceOptions, type EinvoiceOptionsInput, type EinvoiceProfile, type InvoiceInput, type ResolvedEinvoice, type VatCategory, } from './schema.cjs';
+export { invoicePathSegments, locateJsonPath, type JsonLocation, } from './locate.cjs';
+export { EINVOICE_FLAVOUR_NAMES, EINVOICE_MAX_MESSAGES, EINVOICE_PROFILE_NAMES, capMessages, einvoiceResult, invoiceLineOf, type EinvoiceDisplay, type EinvoiceMessage, type EinvoiceResult, type EinvoiceValidation, } from './report.cjs';
+export { htmlText } from './html-text.cjs';
+export { invoiceSkeleton } from './skeleton.cjs';
+/** Where the invoice sits in the render data. */
+export declare const INVOICE_DATA_KEY = "_invoice";
+/**
+ * The release of the specification the XML is written for, under each of its two names: ZUGFeRD 2.5
+ * and Factur-X 1.09 are one document. The sidecar pins the same release (its validator is what a
+ * file is held to); `codes.generated.ts` carries that release's code lists.
+ */
+export declare const EINVOICE_SPEC_VERSIONS: Record<EinvoiceFlavour, string>;
+/**
+ * An amount of a checked `Invoice` as the XML writes it and a reader expects it: `3760.40`. The
+ * invoice itself keeps the digits it was given (`3760.4`), which is one value all the same.
+ */
+export declare function invoiceAmountText(amount: string): string;
+export type EinvoiceXml = {
+    ok: true;
+    xml: string;
+    invoice: Invoice;
+} | {
+    ok: false;
+    problems: InvoiceProblem[];
+};
+/**
+ * The `_invoice` block of some render data as XML: checked, then written. A block that is absent is
+ * one finding, since a template that declares an e-invoice cannot render without one.
+ */
+export declare function einvoiceXml(data: unknown, options: {
+    profile: EinvoiceProfile;
+}): EinvoiceXml;

package/types/lib/einvoice/index.d.ts

@@ -0,0 +1,45 @@
+/**
+ * `@formfeed/engine/einvoice` (spec 17): the `_invoice` block, the rules it is held to, the CII XML
+ * written from it and the display check. No template engine is imported here and nothing of Node,
+ * so the gateway Worker, the render-worker, the editor and the CLI all run the same code: what the
+ * API refuses, the editor has already said.
+ */
+import { type Invoice, type InvoiceProblem } from './check.js';
+import type { EinvoiceFlavour, EinvoiceProfile } from './schema.js';
+export { checkInvoice, type CheckOptions, type Identifier, type Invoice, type InvoiceAddress, type InvoiceAllowance, type InvoiceBreakdown, type InvoiceCheck, type InvoiceLine, type InvoiceParty, type InvoiceProblem, type InvoiceProblemCode, type InvoiceTax, } from './check.js';
+export { CII_GUIDELINES, EINVOICE_XML_NAME, invoiceToCii } from './cii.js';
+export { CODE_LIST_RELEASE } from './codes.generated.js';
+export { DISPLAY_TERMS, displayCheck, displayMissingText, shownAmounts, type DisplayCheck, type DisplayValue, } from './display.js';
+export { EINVOICE_FLAVOURS, EINVOICE_PROFILES, VAT_CATEGORIES, defaultEinvoiceOptions, einvoiceOptionsSchema, invoiceSchema, resolveEinvoiceOptions, type EinvoiceFlavour, type EinvoiceOptions, type EinvoiceOptionsInput, type EinvoiceProfile, type InvoiceInput, type ResolvedEinvoice, type VatCategory, } from './schema.js';
+export { invoicePathSegments, locateJsonPath, type JsonLocation, } from './locate.js';
+export { EINVOICE_FLAVOUR_NAMES, EINVOICE_MAX_MESSAGES, EINVOICE_PROFILE_NAMES, capMessages, einvoiceResult, invoiceLineOf, type EinvoiceDisplay, type EinvoiceMessage, type EinvoiceResult, type EinvoiceValidation, } from './report.js';
+export { htmlText } from './html-text.js';
+export { invoiceSkeleton } from './skeleton.js';
+/** Where the invoice sits in the render data. */
+export declare const INVOICE_DATA_KEY = "_invoice";
+/**
+ * The release of the specification the XML is written for, under each of its two names: ZUGFeRD 2.5
+ * and Factur-X 1.09 are one document. The sidecar pins the same release (its validator is what a
+ * file is held to); `codes.generated.ts` carries that release's code lists.
+ */
+export declare const EINVOICE_SPEC_VERSIONS: Record<EinvoiceFlavour, string>;
+/**
+ * An amount of a checked `Invoice` as the XML writes it and a reader expects it: `3760.40`. The
+ * invoice itself keeps the digits it was given (`3760.4`), which is one value all the same.
+ */
+export declare function invoiceAmountText(amount: string): string;
+export type EinvoiceXml = {
+    ok: true;
+    xml: string;
+    invoice: Invoice;
+} | {
+    ok: false;
+    problems: InvoiceProblem[];
+};
+/**
+ * The `_invoice` block of some render data as XML: checked, then written. A block that is absent is
+ * one finding, since a template that declares an e-invoice cannot render without one.
+ */
+export declare function einvoiceXml(data: unknown, options: {
+    profile: EinvoiceProfile;
+}): EinvoiceXml;

package/types/lib/einvoice/locate.d.cts

@@ -0,0 +1,21 @@
+import type { Position } from '../types.cjs';
+/**
+ * Where a finding sits in the JSON a data set is written as, so that the editor can mark the place
+ * and the CLI can print `data/default.json:38:5` instead of a path to count out by hand.
+ *
+ * `JSON.parse` keeps no positions, so the text is walked here. It only has to find its way through
+ * JSON that already parsed, not to judge it: anything unexpected ends the walk and the answer is
+ * what was reached until then.
+ */
+export interface JsonLocation extends Position {
+    /** How many segments of the path exist in the text; fewer than asked means the rest is missing. */
+    depth: number;
+}
+/** `lines[1].tax.rate` as the keys and indexes it names. */
+export declare function invoicePathSegments(path: string): Array<string | number>;
+/**
+ * The position of `path` in `text`: of the key (or the list item) the path ends on, or, when the
+ * text does not go that far, of the deepest part that is there. A field that is missing is thereby
+ * marked at the object it is missing from. `null` when the text has no value at all.
+ */
+export declare function locateJsonPath(text: string, path: ReadonlyArray<string | number>): JsonLocation | null;

package/types/lib/einvoice/locate.d.ts

@@ -0,0 +1,21 @@
+import type { Position } from '../types.js';
+/**
+ * Where a finding sits in the JSON a data set is written as, so that the editor can mark the place
+ * and the CLI can print `data/default.json:38:5` instead of a path to count out by hand.
+ *
+ * `JSON.parse` keeps no positions, so the text is walked here. It only has to find its way through
+ * JSON that already parsed, not to judge it: anything unexpected ends the walk and the answer is
+ * what was reached until then.
+ */
+export interface JsonLocation extends Position {
+    /** How many segments of the path exist in the text; fewer than asked means the rest is missing. */
+    depth: number;
+}
+/** `lines[1].tax.rate` as the keys and indexes it names. */
+export declare function invoicePathSegments(path: string): Array<string | number>;
+/**
+ * The position of `path` in `text`: of the key (or the list item) the path ends on, or, when the
+ * text does not go that far, of the deepest part that is there. A field that is missing is thereby
+ * marked at the object it is missing from. `null` when the text has no value at all.
+ */
+export declare function locateJsonPath(text: string, path: ReadonlyArray<string | number>): JsonLocation | null;

package/types/lib/einvoice/report.d.cts

@@ -0,0 +1,59 @@
+import type { DisplayCheck } from './display.cjs';
+import type { EinvoiceFlavour, EinvoiceOptions, EinvoiceProfile } from './schema.cjs';
+/**
+ * What a render says about its e-invoice (spec 17 §4.1, §5): the validator's report and the display
+ * check. One shape for the render-worker that builds it, the database row that keeps it, the API
+ * that returns it, the render log and the CLI that show it.
+ */
+/** One finding of the validator: a rule of the XML (schematron, XSD) or of PDF/A (veraPDF). */
+export interface EinvoiceMessage {
+    part: 'xml' | 'pdf';
+    severity: 'error' | 'warning';
+    /** `BR-CO-15`, `CII-SR-465`, or a clause of PDF/A such as `6.2.11.4.1-1`. */
+    rule: string | null;
+    message: string;
+    /** Where: an XPath into the XML, or the object of the PDF. */
+    location: string | null;
+}
+export interface EinvoiceValidation {
+    valid: boolean;
+    /** The rule set the XML was held to, as the validator names it. */
+    schematron: string;
+    /** `PDF/A-3b` once the file was checked; `null` when validation ended at the XML. */
+    pdfa: string | null;
+    messages: EinvoiceMessage[];
+    /** More findings than the render keeps. */
+    truncated?: boolean;
+}
+export interface EinvoiceDisplay {
+    /** The business terms looked for in the text of the PDF (`BT-1`, `BT-112`). */
+    checked: string[];
+    /** Those the text does not show. */
+    missing: string[];
+}
+/** `einvoice` of a render as the row keeps it; the API adds `xml_url`. */
+export interface EinvoiceResult {
+    profile: EinvoiceProfile;
+    flavour: EinvoiceFlavour;
+    /** The release of the specification under the flavour's name: `1.09` or `2.5`. */
+    spec_version: string;
+    validation: EinvoiceValidation | null;
+    display: EinvoiceDisplay | null;
+}
+/**
+ * A render row travels in every list and webhook, so it keeps this many findings and says when there
+ * were more. Errors go first: a report cut short must not lose the reason it failed to warnings.
+ */
+export declare const EINVOICE_MAX_MESSAGES = 50;
+export declare function capMessages(messages: readonly EinvoiceMessage[], max?: number): Pick<EinvoiceValidation, 'messages' | 'truncated'>;
+/** The result of a render that got as far as `validation` and `display` say. */
+export declare function einvoiceResult(options: Pick<EinvoiceOptions, 'profile' | 'flavour'>, specVersion: string, validation: EinvoiceValidation | null, display: DisplayCheck | null): EinvoiceResult;
+/** The names a person reads: `Factur-X` and `EN 16931` for `factur-x` and `en16931`. */
+export declare const EINVOICE_FLAVOUR_NAMES: Record<EinvoiceFlavour, string>;
+export declare const EINVOICE_PROFILE_NAMES: Record<EinvoiceProfile, string>;
+/**
+ * Where in the invoice a finding of the XML sits, for a reader who knows `_invoice` and not CII:
+ * `line 2` for anything inside the second line item, `null` where the path names no line. The XPath
+ * itself stays beside it; this only spares the reader counting brackets.
+ */
+export declare function invoiceLineOf(location: string | null): number | null;