import { ReceiptType, type ReceiptTypeKey, KeckPaymentMethod, type KeckPaymentMethodKey } from '../enums/index.js';
import { type Receipt, type ReceiptCompany, type ReceiptItem, type Voucher, type ReceiptSummary, type ReportMonth, type CancellationItem, type CancellationOf, type CancellationReason, type TipRefundSource, type ReturnDisposition, type ReceiptPaymentInput, type RegistrationInfo, type ReceiptEmailVia } from '../models/index.js';
import { type ReceiptOutput, type ReceiptOutputEntryErrorCode, type ReceiptOutputLogKind, type ReceiptOutputResult } from '../models/receipt-output.js';
import type { InternerTransport } from './aufrufe.js';
import { type ReceiptLayout } from '../receipt/layout.js';
import type { PosPaperSize } from '../printing/escpos.js';
import type { SheetLogoSize } from '../receipt/blatt.js';
/**
 * Beleg-Endpunkte — Zwilling der Beleg-Aufrufe in
 * kasseneck_api/lib/kasseneck_api.dart.
 *
 * **Draht `/v3`, englisch.** Verkauf und Nullbeleg laufen ueber den
 * Endpunkt `createReceipt`; `sellReceipt` und `zeroReceipt` legen den
 * Belegtyp fest und reichen den Rest durch. Bezahlt wird immer ueber
 * `payments[]` (Pflicht unter `/v3`); `paymentMethod` und die Kartenfelder am
 * Beleg gibt es nicht mehr, die Kartenangaben stehen in der einzelnen
 * Zahlung. Den Zahlbetrag rechnet `receiptDueCents` vorher aus.
 * **[cancelReceipt] geht an den eigenen Endpunkt `cancelReceipt`**: der
 * Server negiert die Positionen des Originals, prueft Restmengen und Rechte
 * und verkettet beide Belege. Einen Storno ueber `createReceipt` gibt es
 * nicht mehr.
 *
 * **Kein Wiederholen fehlgeschlagener Aufrufe** (siehe transport.ts): ein
 * Beleg ist nicht folgenlos wiederholbar. Bei `outcome: 'unknown'`
 * (`receipt_outcome_unknown`, `cancellation_outcome_unknown`, Netz- oder
 * Serverfehler nach dem Senden) erst nachlesen, und bei
 * `payments_sum_mismatch` nennt [paymentsExpectedCents] den Betrag des
 * Servers; auch dann wiederholt das Paket nie selbst.
 *
 * **Kassen-Benutzer-Weg (`registerUserAuth`, Browser-Kasse):** Von den
 * Endpunkten dieser Datei setzen [listMyReceipts], [getReceipt],
 * [createReceipt] und [generateFullReceiptId] ein `allowRegisterUser` — der
 * Browser-Kasse steht hier also alles offen ausser [getFirstReceiptDate];
 * siehe den Hinweis dort. Dieses Paket bildet das **nicht** nach — wer darf,
 * entscheidet allein das Backend. Der Hinweis steht hier, damit ein Leser
 * nicht raten muss.
 */
/** Gemeinsame Zusatzangaben aller Belegarten (Nutzlast von `createReceipt`). */
export interface ReceiptCommonOptions {
    /** Kundendaten fuer den Belegkopf; gehen als `\n`-verbundene Zeichenkette raus. */
    customerDetails?: string[];
    /** Rechtshinweise (z. B. Reverse Charge); gehen als `\n`-verbundene Zeichenkette raus. */
    legalMessage?: string[];
    /** Freier Bezeichner des Aufrufers (Projekt, Auftrag, Schicht). */
    customProjectId?: string;
    /**
     * Trinkgeld in Cent — als Zahl (an den angemeldeten Kassen-Benutzer, Zahlart
     * des Belegs) oder als [TipOptions]. Das Backend bucht daraus signierte
     * Positionen `kind:'tip'` (Mitarbeiter 0 % als Durchlaeufer, Inhaber
     * anteilig je Steuersatz). Nur auf `standard` und `training`.
     */
    tip?: number | TipOptions;
    /**
     * Lade, in deren Kassenstand der Beleg zaehlt (Schichtbetrieb, Geraete-
     * Einstellung `drawerId`). Ohne Angabe gilt die Lade des Geraets bzw. die
     * Hauptlade der Kasse. Leer oder kein Text: wirft vor dem Senden.
     */
    drawerId?: string;
}
/** Trinkgeld mit eigener Zahlart und/oder Empfaengern (Kassen-Benutzer-IDs, Summe = cents). */
export interface TipOptions {
    cents: number;
    /** Zahlart des Trinkgelds; bei mehreren Zahlarten Pflicht (`tip_payment_method_required`). */
    paymentMethod?: KeckPaymentMethod | KeckPaymentMethodKey;
    /** Empfaenger; ohne Angabe der angemeldete Kassen-Benutzer. Summe der cents = cents. */
    recipients?: TipRecipientShare[];
    /**
     * Hat der Empfaenger das Geld schon? `true` = ja (Bargeld mitgenommen,
     * Kartentrinkgeld sofort aus der Lade ausgezahlt), `false` = der Betrieb
     * behaelt es und schuldet es.
     *
     * Entscheidend ist NICHT die Zahlart, sondern der Besitz -- § 2j Abs 2 AVRAG
     * kennt beide Faelle. Ohne Angabe gilt die Voreinstellung des Betriebs (bar:
     * schon erhalten, bargeldlos: einbehalten); diese Angabe braucht es nur fuer
     * die Ausnahme.
     *
     * NUR mit dem Recht `tipAssign` bei persoenlicher Anmeldung: das Merkmal
     * entscheidet, ob der Betrieb Geld schuldet, und gewoehnliches Personal soll
     * das nicht am Geraet umstellen koennen. Ueber einen Geraete-API-Schluessel
     * (ohne angemeldeten Kassen-Benutzer) gilt die Einschraenkung nicht.
     */
    receivedImmediately?: boolean;
    /**
     * Bar-Trinkgeld „gleich behalten“: die Mitarbeiterin steckt das Trinkgeld
     * beim Verkauf gleich ein. Der Beleg bleibt, wie er ist (signiert, im DEP);
     * nur im Kassenstand zaehlt der Betrag nicht ins Bar-Soll und gilt sofort als
     * „schon genommen“. Nur `true` geht hinaus. Der Server nimmt es nur bei
     * Mitarbeiter-Trinkgeld, bar und sofort erhalten; sonst faellt es still weg.
     * Vorbelegung des Schalters: [posTipKeptByDefault] der Kassen-Einstellungen.
     */
    keptByEmployee?: boolean;
}
export interface TipRecipientShare {
    registerUserId: string;
    cents: number;
}
/** Belegtyp und Inhalt, die vollstaendige Eingabe von [createReceipt]. */
export interface CreateReceiptOptions extends ReceiptCommonOptions {
    receiptType: ReceiptType | ReceiptTypeKey;
    /**
     * Zahlungen (siehe [ReceiptPaymentInput]); bei `standard` und `training`
     * Pflicht, auch leer, wenn der Zahlbetrag 0 ist. Null- und Startbeleg
     * nehmen keine (`payments_not_allowed`). Die Summe muss
     * [receiptDueCents] treffen.
     */
    payments?: ReceiptPaymentInput[];
    items?: ReceiptItem[];
    vouchers?: Voucher[];
}
/**
 * Verkauf: Positionen, Gutscheine, Trinkgeld und die Zahlungen. Die
 * Kartenangaben (`provider`, `providerPaymentId`, `providerData`) stehen in
 * der einzelnen Zahlung; die Summe der Zahlungen ist [receiptDueCents].
 */
export interface SellReceiptOptions extends ReceiptCommonOptions {
    payments: ReceiptPaymentInput[];
    items?: ReceiptItem[];
    vouchers?: Voucher[];
}
/**
 * Storno ueber den Endpunkt `cancelReceipt` (Backend: storno-endpoints.js).
 * Der Server negiert die Positionen, prueft Restmengen und Rechte, verkettet
 * Original und Storno-Beleg. Bezug entweder als Beleg-Objekt (`receipt`) oder
 * als Kasse + Beleg-ID.
 */
export type CancelReceiptOptions = {
    /** Grund aus dem Katalog — Pflicht, nur der Anzeigetext landet am Bon. */
    reason: CancellationReason;
    /** Teilstorno: Positionen (Index im Original) und Mengen. Fehlt = Vollstorno der Restmengen. */
    items?: CancellationItem[];
    /** Interne Anmerkung (≤ 200 Zeichen), wird gespeichert, nie gedruckt. */
    note?: string;
    /**
     * Wohin die Ware der stornierten Artikelzeilen geht (Lager-Kern Stufe 2):
     * Vorgabe fuer alle Positionen, je Position abweichend ueber
     * `items[].returnDisposition`. Fehlt beides, bucht der Server `restock`.
     * Zeilen ohne `articleId` bucht er nie. Ein falscher Wert geht nicht hinaus;
     * der Server meldete ihn als `invalid_return_disposition`.
     */
    returnDisposition?: ReturnDisposition;
    /**
     * Rueckzahlung je Zahlung (Betraege negativ, `refundOf` = `id` der
     * Originalzahlung). Ohne Angabe spiegelt der Server die Restbetraege jeder
     * Originalzahlung (Ausnahme Storno einer Gutschein-Auszahlung: genau eine
     * positive Barzahlung ohne `refundOf`); ein Teilstorno eines Belegs mit
     * mehreren Zahlungen braucht sie (`cancellation_payments_required`).
     *
     * **Karten-Storno:** `provider`, `providerPaymentId` und `providerData`
     * beschreiben die ERSTATTUNG am Terminal, nie die Originalzahlung. Die
     * Kennung der Originalzahlung (fuer die Rueckbuchung am Terminal) steht in
     * `payments[].providerPaymentId` des Originals; die liefert nur der
     * Kassenweg (Kanal `app`, `registerUserAuth`).
     */
    payments?: ReceiptPaymentInput[];
    /** Lade, in deren Kassenstand der Storno zaehlt; wie bei [ReceiptCommonOptions.drawerId]. */
    drawerId?: string;
    /**
     * Antwort auf „Trinkgeld auch zurueckgeben?“ (Schichten-Spec, Nachtrag 5). `false`: ohne das
     * Mitarbeiter-Trinkgeld (ohne `items` = alle Restmengen ausser dem Trinkgeld); `true` mit `items`:
     * das noch offene Trinkgeld kommt dazu. Fehlt = wie bisher (ein Vollstorno nimmt es mit). Die
     * Positionen dazu rechnet [cancellationItemsForTip]. An einem Beleg mit Wertgutschein gibt es
     * `false` nicht (`tip_keep_not_possible_with_voucher`, siehe [asksRefundTip]).
     */
    refundTip?: boolean;
    /**
     * Antwort auf „Woher kommt das Trinkgeld zurueck?“, nur bei Barrueckgabe ([asksTipRefundSource]):
     * `drawer` aus der Lade, `employee` gibt die Mitarbeiterin direkt. Nicht zusammen mit
     * `refundTip: false`. Der Server weist eine Quelle ohne Bargeld-Deckung ab
     * (`tip_refund_source_requires_cash`). `refundTip: true` ohne Quelle heisst bei Barrueckgabe:
     * aus der Lade (kein „gibt die Mitarbeiterin direkt“).
     */
    tipRefundSource?: TipRefundSource;
} & ({
    receipt: Receipt;
    cashregisterId?: string;
    originalReceiptId?: string;
} | {
    receipt?: undefined;
    cashregisterId: string;
    originalReceiptId: string;
});
/** Antwort von [cancelReceipt]: Storno-Beleg, Bezug, Restmengen des Originals danach. */
export interface CancelReceiptResult {
    receipt: Receipt;
    cancellationOf: CancellationOf;
    remaining: number[];
}
/**
 * Beleg **und** die Firmen-/Druckdaten derselben Antwort — das Ergebnis der
 * `…WithCompany`-Varianten. Das Backend liefert beides in einem Aufruf
 * (functions/index.js); wer den Beleg drucken oder anzeigen will, braucht
 * beides und soll dafuer keinen zweiten Aufruf machen muessen.
 */
export interface ReceiptWithCompany {
    receipt: Receipt;
    /** Kopf/Fuss, wie sie fuer DIESEN Beleg gelten (eingefrorene Version des Backends). */
    company: ReceiptCompany;
    /** Beleg einer Testumgebung (Aufdruck TESTKASSE). */
    testCashregister: boolean;
    /** Produktionskonto mit Test-Signatureinheit (Aufdruck TESTSIGNATUR). */
    testSignature: boolean;
    /** Kennung der Kopf-Version; null bei Altbeleg ohne Zuordnung. */
    headerVersionId: string | null;
    /**
     * Vom Backend gebautes Zeilenmodell (`data.layout`, Regelwerk des Belegs,
     * 80 mm); null, wenn nicht mitgeliefert. Es geht unveraendert an
     * `escPosLayoutBytes`, `eposPrintXml`, `receiptSheet` und die React-Ansichten.
     * Drucken und anzeigen ueber [receiptLayoutFromResult].
     */
    layout: ReceiptLayout | null;
    /**
     * Registrierdaten fuer den Block „Prüfangaben“ (Nullbelege, Regelwerk 2),
     * fuer Clients, die das Layout selbst bauen; null bei anderen Belegen.
     */
    registrationInfo: RegistrationInfo | null;
    /**
     * Groesse des Firmenlogos am Beleg (`logo_scale`). Bildschirm, Bon und PDF
     * setzen das Logo in genau dieser Stufe; fehlt der Wert, gilt `M`.
     */
    logoScale: SheetLogoSize;
    /**
     * Ausgaben des Belegs (`data.outputs`, nur `getReceipt` unter `/v3`): die
     * neuesten 20, neueste zuerst. Fehlt, wenn die Antwort keine Liste traegt
     * (Verkauf, `/api`). Gelesen nach [ReceiptOutput]; ein kaputter Eintrag
     * faellt weg, der Beleg bleibt lesbar.
     */
    outputs?: ReceiptOutput[];
}
/**
 * Das Zeilenmodell zum Drucken und Anzeigen eines Belegs aus einer Antwort.
 *
 * **Ein Server-Layout gewinnt immer.** Liefert der Server `data.layout`, gilt
 * genau dieses, in seiner Breite (80 mm): im oeffentlichen Kanal traegt nur
 * es den Kartenblock (der Beleg selbst kommt dort ohne Anbieterdaten), und
 * Bildschirm, Bon und PDF zeigen so denselben Beleg. Fehlt es, wird das
 * Layout hier gebaut, mit den Angaben derselben Antwort (`testCashregister`,
 * `testSignature`, `registrationInfo`) und in `fallbackPaperSize` (Vorgabe
 * `mm58` wie in 0.x). Die Druckbreite waehlt allein der Druckweg
 * (`paperSize` bei `escPosLayoutBytes`, `charsPerLine` bei ePOS und Blatt), nie
 * dieser Helfer.
 */
export declare function receiptLayoutFromResult(result: ReceiptWithCompany, options?: {
    fallbackPaperSize?: PosPaperSize;
}): ReceiptLayout;
/**
 * Gemeinsame Umsetzung aller Belegarten (Zwilling von `_createReceipt`).
 * Bewusst **nicht** Teil der Paketoberflaeche: der Belegtyp gehoert nicht in
 * die Hand des Aufrufers, sondern zu einem der benannten Aufrufe darunter.
 */
export declare function createReceipt(rufen: InternerTransport, options: CreateReceiptOptions): Promise<Receipt>;
/**
 * Baut die Nutzlast von `createReceipt` und prueft die Eingabe. Wirft, bevor
 * irgendetwas rausgeht — ein Beleg ist nicht folgenlos wiederholbar.
 */
export declare function createReceiptParams(options: CreateReceiptOptions): Record<string, unknown>;
/** Normalbeleg (Verkauf) nach RKSV. */
export declare function sellReceipt(transport: InternerTransport, options: SellReceiptOptions): Promise<Receipt>;
/**
 * Normalbeleg wie [sellReceipt], liefert zusaetzlich die Firmen-/Druckdaten
 * aus derselben Antwort — alles, was ein Belegdruck braucht, in einem Aufruf.
 */
export declare function sellReceiptWithCompany(transport: InternerTransport, options: SellReceiptOptions): Promise<ReceiptWithCompany>;
/**
 * Storno-Beleg zu einem bestehenden Beleg — voll oder in Teilen. Prueft die
 * Eingabe, bevor etwas hinausgeht; der Server haelt die Restmengen und die
 * Reichweite des Rechts (eigene/alle) und antwortet mit dem fertigen,
 * signierten Storno-Beleg. Gutscheine des Originals wandern nicht mit.
 */
export declare function cancelReceipt(transport: InternerTransport, options: CancelReceiptOptions): Promise<CancelReceiptResult>;
/** Nullbeleg (RKSV-Pruefbeleg) — ohne Positionen und ohne Zahlungsart. */
export declare function zeroReceipt(transport: InternerTransport): Promise<Receipt>;
/** Belegliste einer Kasse samt der Kennzahlen, die dieselbe Antwort mitliefert. */
export interface ReceiptList {
    /** Letzte Belege, neueste zuerst (Backend: nach `counter` absteigend). */
    receipts: ReceiptSummary[];
    stats: ReceiptListStats;
}
/**
 * Kennzahlen zur Kasse, die `listMyReceipts` neben der Liste liefert. Sie
 * kommen aus den Tages-Aggregaten des Backends, nicht aus den gelisteten
 * Belegen — die Reihe umfasst sieben Tage, die Liste nur die letzten `limit`
 * Belege.
 */
export interface ReceiptListStats {
    /** Heutiger Umsatz in Cent und Belegzahl (Wiener Kalendertag). */
    today: {
        revenueCents: number;
        count: number;
    };
    /** Veraenderung gegenueber gestern in Prozent; `null`, wenn gestern 0 war. */
    trendPercent: number | null;
    /** Sieben Tage, aeltester zuerst; `date` als `YYYY-MM-DD` (Wiener Kalender). */
    days: Array<{
        date: string;
        revenueCents: number;
    }>;
}
export interface ListMyReceiptsOptions {
    /** Kasse, deren Belege gelistet werden (Parameter `cashregisterId`). */
    cashregisterId: string;
    /**
     * Anzahl Belege; ohne Angabe nimmt das Backend 50. Es begrenzt den Wert
     * selbst auf 1 bis 200 — ein groesserer Wunsch wird still gekappt.
     */
    limit?: number;
    /** Zeitfenster (Wiener Wanduhr, `YYYY-MM-DD` oder voller Zeitstempel); der Server deckelt auf 90 Tage. */
    from?: string;
    to?: string;
}
/**
 * Belege einer Kasse auflisten — die Grundlage jeder Belegliste in der
 * Browser-Kasse (Nachdruck, Storno, Tagesuebersicht).
 *
 * Die Eintraege sind **Zusammenfassungen**, keine vollstaendigen Belege (siehe
 * [ReceiptSummary]); fuer Nachdruck oder Storno gehoert der Beleg ueber
 * [getReceipt] bzw. [getReceiptWithCompany] einzeln geholt.
 *
 * **Anmeldeweg:** Der Endpunkt laeuft im Backend unter
 * `checkRequest(req, 'customer', …, {allowRegisterUser: true})`, der Bearer
 * muss also ein ID-Token des Anmeldediensts sein — mit `apiKeyAuth` ist er nicht
 * erreichbar. Ausserdem prueft das Backend die Kassenzuweisung hier im Rumpf
 * (der Endpunkt laeuft mit `checkCashRegister: false`), ein Kassen-Benutzer
 * bekommt also nur die ihm zugewiesenen Kassen.
 */
export declare function listMyReceipts(transport: InternerTransport, options: ListMyReceiptsOptions): Promise<ReceiptList>;
/** Einzelnen Beleg der angemeldeten Kasse holen. */
export declare function getReceipt(transport: InternerTransport, receiptId: string): Promise<Receipt>;
/**
 * Wie [getReceipt], liefert zusaetzlich die Firmen-/Druckdaten aus derselben
 * Antwort (Firma, Anschrift, Steuernummer, UID, Fusszeilen, Logo-Adresse,
 * Kleinunternehmer-Kennzeichen) — die Angaben, die ein Beleg im Kopf und Fuss
 * traegt (siehe models/receipt-company.ts).
 */
export declare function getReceiptWithCompany(transport: InternerTransport, receiptId: string): Promise<ReceiptWithCompany>;
/**
 * Verschluesselte Volltext-Belegnummer erzeugen — der Bezeichner, unter dem der
 * Beleg oeffentlich abrufbar ist (Beleg-Download, Pruefportal).
 */
export declare function generateFullReceiptId(transport: InternerTransport, receiptId: string): Promise<string>;
/**
 * Berichtsmonat des allerersten Belegs dieser Kasse — die untere Grenze aller
 * Monatsberichte.
 *
 * **Nicht fuer den Kassen-Benutzer-Weg (`registerUserAuth`):** dieser Endpunkt
 * fuehrt kein `allowRegisterUser`, das Backend weist die Browser-Kasse hier ab
 * (siehe Modulkommentar oben). Mit `apiKeyAuth` ist er offen.
 */
export declare function getFirstReceiptDate(transport: InternerTransport): Promise<ReportMonth>;
/**
 * Beleg per E-Mail an den Endkunden — die Eingabe von [sendReceiptEmail].
 *
 * `cashregisterId` steht hier bewusst **nicht**: der Geraeteweg bindet die
 * Kasse ueber die Kopfzeile `cashregister-token`, der Kassen-Benutzer-Weg
 * ueber den Parameter, den `registerUserAuth` ohnehin schon setzt. Eine
 * dritte Stelle waere nur eine Gelegenheit, eine andere Kasse zu behaupten,
 * als die, an der man angemeldet ist — und das Backend nimmt den Belegpfad aus
 * der angemeldeten Kasse, nicht aus der Nutzlast.
 */
export interface SendReceiptEmailOptions {
    /** Verschluesselte Volltext-Belegnummer (siehe [generateFullReceiptId]). */
    fullReceiptId: string;
    /** Empfaengeradresse, wie der Gast sie am Tresen nennt. */
    to: string;
    /**
     * Sprache der Mail. Heute wertet das Backend genau `'de'` aus; der Parameter
     * steht im Vertrag, damit eine zweite Sprache spaeter kein neuer Vertrag ist.
     * Ohne Angabe geht das Feld gar nicht erst hinaus.
     */
    language?: string;
}
/** Was der Versand bestaetigt (Backend: beleg-mail-endpoints.js). */
export interface SendReceiptEmailResult {
    /**
     * Adresse in der Form, in der das Backend sie protokolliert hat (getrimmt,
     * klein). Nennt die Antwort keine, die gesendete (getrimmte) Adresse.
     */
    to: string;
    /**
     * Zeitpunkt des Versands, ISO mit Wiener Zonenoffset
     * (`2026-09-11T14:05:00+02:00`). `null`, wenn die Antwort keinen nennt: der
     * Versand ist trotzdem bestaetigt.
     */
    at: string | null;
    /**
     * Versandweg: `own` (Postfach des Betriebs), `platform` oder
     * `platform_fallback` ([RECEIPT_EMAIL_VIAS]). `null`, wenn die Antwort ihn
     * nicht oder mit einem unbekannten Wert nennt: das ist eine Auskunft ueber
     * den Weg, keine ueber den Erfolg, und darf den bestaetigten Versand nicht
     * zu einem Fehler machen.
     */
    via: ReceiptEmailVia | null;
}
/**
 * Schickt einen bereits ausgestellten Beleg als **Link auf die oeffentliche
 * Belegseite** an eine Adresse (Endpunkt `sendReceiptEmail`, Backend
 * beleg-mail-endpoints.js). Kein PDF im Anhang: die Belegseite fuehrt dasselbe
 * Zeilenmodell wie Bildschirm und Bon und liefert dort auf Wunsch ein PDF.
 *
 * **Der Beleg bleibt unberuehrt** (BAO §131/RKSV): das Versandprotokoll fuehrt
 * das Backend in einer Unter-Sammlung neben dem Beleg.
 *
 * **Am Code entscheiden, nie am Text:** fachliche Fehler kommen als
 * [KasseneckApiError] mit `code` aus [RECEIPT_EMAIL_ERROR_CODES] heraus:
 * `invalid_address`, `receipt_not_found` (auch fuer einen Beleg einer
 * fremden Kasse: das Backend gibt darueber bewusst keine Auskunft),
 * `too_many_requests` (5 Mails je Beleg in 24 Stunden, 30 je Kasse und
 * Stunde) und `send_failed`. Dieses Paket reicht sie unveraendert durch und
 * legt keine eigenen Codes an.
 *
 * **Kein Wiederholen ohne Zutun des Bedieners:** ein zweiter Versuch schickt
 * eine zweite Mail und zaehlt auf die Schleuse.
 */
export declare function sendReceiptEmail(transport: InternerTransport, options: SendReceiptEmailOptions): Promise<SendReceiptEmailResult>;
/**
 * Eine Ausgabe, wie die Kasse sie puffert und meldet: ein Druck oder ein
 * Teilen des Belegs. Siehe [logReceiptOutputs].
 */
export interface ReceiptOutputEntry {
    /**
     * Idempotenzschluessel des Eintrags, am Geraet beim Puffern vergeben und
     * beim Nachsenden unveraendert: ein zweites Melden legt keinen zweiten
     * Eintrag an. 8–64 Zeichen `[A-Za-z0-9_-]` (Regel des Servers); ein anderer
     * Schluessel wirft vor dem Senden.
     */
    key: string;
    /** Beleg in der Kasse der Anmeldung; ein Beleg einer anderen Kasse ist `receipt_not_found`. */
    receiptId: string;
    /** `print` (Erstdruck), `reprint` (Duplikat, gedruckt mit `markAsDuplicate`), `link_shared`, `pdf_shared`. */
    kind: ReceiptOutputLogKind;
    /**
     * Zeitpunkt am Geraet: Millisekunden seit 1970 oder ISO 8601 **mit Zone**
     * (`new Date().toISOString()`); Text ohne Zone wirft vor dem Senden. Eine
     * falsch gehende Geraeteuhr lehnt der Server nicht ab: er klemmt die Zeit auf
     * Belegzeit bis Eingang.
     */
    at: number | string;
    /**
     * Ergebnis eines Drucks: `ok`, `failed` (sicher nicht gedruckt) oder
     * `unclear` (Ausgang offen). Pflicht bei `print` und `reprint` (sonst lehnt
     * der Server den Eintrag mit `validation` ab); beim Teilen ohne Angabe `ok`.
     */
    result?: ReceiptOutputResult;
}
/** Eingabe von [logReceiptOutputs]. Die Kasse bindet die Anmeldung (wie bei [sendReceiptEmail]). */
export interface LogReceiptOutputsOptions {
    /** 1–50 Eintraege ([RECEIPT_OUTPUT_ENTRIES_MAX]); ein groesserer Puffer geht in mehreren Aufrufen hinaus. */
    entries: ReceiptOutputEntry[];
}
/** Ein abgelehnter Eintrag: dauerhaft, aus dem Puffer nehmen und nicht noch einmal senden. */
export interface RejectedReceiptOutput {
    key: string;
    /** Aus [RECEIPT_OUTPUT_ENTRY_ERROR_CODES]; ein Code, den das Paket nicht kennt, bleibt lesbar. */
    code: ReceiptOutputEntryErrorCode | (string & {});
}
/** Antwort von [logReceiptOutputs]. */
export interface LogReceiptOutputsResult {
    /** Angenommene Eintraege, auch die schon frueher gemeldeten (gleicher Schluessel). */
    accepted: number;
    rejected: RejectedReceiptOutput[];
}
/**
 * Meldet Drucke und das Teilen eines Belegs an das Protokoll „Ausgaben“
 * (Endpunkt `logReceiptOutputs`, nur ueber den Kassenweg `/api/v3`; mit
 * `registerUserAuth` und mit `apiKeyAuth`). Registrierkassen-Erlass
 * BMF-AV Nr. 2/2026, Abschnitt 4.2: die Belegerteilung ist zu dokumentieren.
 * Der Beleg selbst bleibt unberuehrt; das Protokoll steht nie im DEP.
 *
 * **Ein Eintrag scheitert nie die anderen.** Der Server nimmt jeden Eintrag
 * einzeln an oder lehnt ihn mit Code ab (`rejected`, Codes
 * [RECEIPT_OUTPUT_ENTRY_ERROR_CODES]); nach einer Erfolgsantwort ist jeder
 * gesendete Eintrag erledigt. Die Kasse puffert die Eintraege (offline,
 * Neustart) und sendet sie spaeter; der Puffer blockiert nie Druck oder Teilen.
 *
 * **Wiederholen ist gefahrlos:** jeder Eintrag traegt seinen Schluessel. Bei
 * unklarem Ausgang (`outcome: 'unknown'`) dieselben Eintraege mit denselben
 * Schluesseln noch einmal senden.
 *
 * **Vor dem Senden abgewiesen** wird nur, was die ganze Anfrage scheitern
 * liesse oder ohne Netz sicher falsch ist: keine oder mehr als 50 Eintraege,
 * ein unbekanntes Feld (oben oder im Eintrag), ein fehlender Beleg, ein
 * Schluessel ausserhalb der Regel des Servers, eine Art oder ein Ergebnis
 * ausserhalb des Katalogs, eine Zeit, die weder ganze Millisekunden noch
 * ISO 8601 mit Zone ist. `email` und `opened` gehen hinaus und kommen als
 * `invalid_output_kind` zurueck: so verwirft der Puffer genau diesen Eintrag.
 * Fehler der ganzen Anfrage: [RECEIPT_OUTPUT_ERROR_CODES].
 */
export declare function logReceiptOutputs(transport: InternerTransport, options: LogReceiptOutputsOptions): Promise<LogReceiptOutputsResult>;
/**
 * Prueft die Gutschein-Kombination eines Belegs und liefert den ersten
 * Regelverstoss als Text (oder `null`) — Zwilling von
 * `checkVoucherCombinationError`. Bewusst als Rueckgabewert statt als Fehler:
 * eine Kassenoberflaeche will das pruefen, **bevor** sie den Beleg abschickt.
 */
export declare function checkVoucherCombinationError(vouchers: Voucher[], items: ReceiptItem[]): string | null;
/**
 * Kennung der Originalzahlung fuer die Rueckbuchung am Terminal (Hobex
 * `originalTransactionId`, SumUp-Transaktion, ...): `providerPaymentId` der
 * Zahlung `paymentId` des Originals. Die liefert nur der Kassenweg (Kanal
 * `app`, `registerUserAuth`); am oeffentlichen Weg fehlt sie, und dann wirft
 * dieser Aufruf, statt `undefined` an ein Terminal weiterzugeben.
 */
export declare function cardRefundReference(receipt: Receipt, paymentId: string): string;
/**
 * `createReceipt` und `getReceipt` liefern den Beleg unter `data.receipt`,
 * daneben die Firmen-/Druckdaten (Firma, Anschrift, Fusszeilen). Diese Lesart
 * nimmt nur den Beleg: die Druckdaten gehoeren nicht zum RKSV-Kernbeleg (siehe
 * models/receipt.ts), und die bestehenden Aufrufe sollen ihre Zusage behalten.
 * Wer beides braucht, nimmt [belegMitFirmaAusHuelle] ueber die
 * `…WithCompany`-Varianten.
 *
 * Paketintern exportiert, damit `./stored` gespeicherte Belege mit demselben
 * Leser liest; nicht Teil der Paketoberflaeche.
 */
export declare function belegAusHuelle(daten: unknown, functionName: string): Receipt;
/**
 * Beleg **und** Firmendaten aus derselben Huelle. Der Beleg entscheidet:
 * fehlt er, ist die Antwort unbrauchbar. Die Firmendaten duerfen dagegen
 * luecken haben — ein Kundendokument ohne gepflegte Fusszeile ist kein Grund,
 * einen ausgestellten Beleg nicht anzuzeigen (siehe models/receipt-company.ts).
 * Paketintern exportiert wie [belegAusHuelle].
 */
export declare function belegMitFirmaAusHuelle(daten: unknown, functionName: string): ReceiptWithCompany;
/**
 * Zahlbetrag des Servers aus einem `payments_sum_mismatch`
 * (`details.expectedCents`), sonst `undefined`. Das Paket wiederholt nie
 * selbst mit diesem Betrag: eine Kartenzahlung ist schon belastet. Die Kasse
 * entscheidet (Differenz nachkassieren oder erstatten) und schickt dann einen
 * neuen Verkauf.
 */
export declare function paymentsExpectedCents(error: unknown): number | undefined;