import { ReceiptType, KeckPaymentMethod, CreditCardProvider } from '../enums/index.js';
import { type ReceiptItem, type ReceiptItemPayload, type ReceiptItemPayloadRead } from './receipt-item.js';
import { type Voucher, type VoucherPayload } from './voucher.js';
import { type Cancellation, type CancellationOf, type CancellationReason } from './cancellation.js';
import { type ZeroKind } from './receipt-summary.js';
import { type ReceiptPayment, type ReceiptPaymentPayload } from './receipt-payment.js';
/**
 * Beleg — Zwilling der Beleg-Nutzlast von `KasseneckReceipt` in
 * kasseneck_api/lib/models/kasseneck_receipt.dart (nur der signatur-/
 * positionsrelevante Teil, den `toReceiptJson()`/die `receipt`-Map von
 * `fromJson()` traegt — nicht die Firmen-/Druckdaten wie Firma, Adresse oder
 * Fusszeilen: die betreffen ausschliesslich das Beleg-Rendering und gehoeren
 * nicht zum RKSV-Kernbeleg. Sie stehen als eigenes Modell daneben, siehe
 * `ReceiptCompany` in ./receipt-company.ts).
 *
 * `timeStamp` bleibt bewusst der rohe Zeitstempel-String aus der Nutzlast;
 * `parseServerTimeStamp` (`../vienna-time.js`) deutet ihn auf Wunsch in einen
 * echten Zeitpunkt um (uneinheitliches Server-Format, siehe dort).
 *
 * `paymentMethod`/`receiptType`/`creditCardProvider` sind beim Lesen entweder
 * der bekannte Enum-Eintrag oder, bei einem der Nutzlast unbekannten
 * Schluessel, der rohe String (siehe `enum-payload.ts`, `readEnumKey`).
 *
 * **Zahlungen stehen in `payments`.** `paymentMethod` vergibt der Server
 * (`mixed` bei mehreren Zahlarten); gesendet wird es unter `/v3` nie. Die
 * Anbieterdaten (`payments[].providerPaymentId`/`providerData`, bei
 * Altbelegen `cardPaymentId`/`cardPaymentData`) liefert nur der Kassenweg
 * (Kanal `app`, `kasse.kasseneck.at/api/v3`); am oeffentlichen Weg fehlen
 * sie. Darum sind sie hier optional.
 */
export interface Receipt {
    receiptId: string;
    cashregisterId: string;
    timeStamp: string;
    items: ReceiptItem[];
    vouchers: Voucher[];
    paymentMethod: KeckPaymentMethod | string;
    turnoverCounterAES256ICM: string;
    signaturePreviousReceipt: string;
    certificateSerialNumber: string;
    receiptType: ReceiptType | string;
    sig: string;
    qr: string;
    fullReceiptId: string;
    creditCardProvider?: CreditCardProvider | string;
    cardPaymentId?: string;
    cardPaymentData?: Record<string, unknown>;
    customerDetails: string[];
    legalMessage: string[];
    signatureSuccess?: boolean;
    customProjectId?: string;
    /**
     * Summe aller Trinkgeld-Positionen in Cent (Storno negativ) — abgeleitetes
     * Lesefeld des Backends, nur vorhanden, wenn der Beleg Trinkgeld traegt.
     */
    tipCents?: number;
    /** Nur am Storno-Beleg: das stornierte Original. */
    cancellationOf?: CancellationOf;
    /** Nur am Storno-Beleg: Grund-Code aus [CANCELLATION_REASONS]. */
    cancellationReason?: CancellationReason | string;
    /** Nur am Original: alle (Teil-)Stornos, Quelle der Restmengen. */
    cancellations?: Cancellation[];
    /** Nur an Nullbelegen: Anlass (monthly, annual, annual_replacement, outage_end, final, manual). */
    zeroKind?: ZeroKind;
    /**
     * Zahlungsliste (mehrere Zahlungen je Beleg), nur vorhanden, wenn der Beleg
     * sie traegt. Altbelege haben keine; dort gelten `paymentMethod` und die
     * Kartenfelder. Siehe [ReceiptPayment].
     */
    payments?: ReceiptPayment[];
    /** Kennung der Kopf-Version (Firmenkopf, wie er fuer diesen Beleg galt). */
    headerVersionId?: string;
    /** Layout-Regelwerk, in dem der Beleg ausgestellt wurde. */
    layoutRuleset?: number;
    /** Nur an Nullbelegen: Registrierdaten fuer den Block „Prüfangaben“. */
    registrationInfo?: RegistrationInfo;
}
/** Registrierdaten von Signaturkarte und Kasse (Zeitstempel oder `null`, wenn unbekannt). */
export interface RegistrationInfo {
    cardRegisteredAt: string | null;
    cashregisterRegisteredAt: string | null;
}
export interface ReceiptPayload {
    qr: string;
    sig: string;
    certificateSerialNumber: string;
    signaturePreviousReceipt: string;
    turnoverCounterAES256ICM: string;
    paymentMethod: string;
    items: ReceiptItemPayload[];
    vouchers: VoucherPayload[] | null;
    timeStamp: string;
    cashregisterId: string;
    receiptType: string;
    receiptId: string;
    fullReceiptId: string;
    creditCardProvider: string | null;
    cardPaymentId: string | null;
    cardPaymentData: Record<string, unknown> | null;
    customerDetails: string;
    legalMessage: string;
    signatureSuccess: boolean | null;
    customProjectId: string | null;
    /** Nur bei Belegen mit Trinkgeld (siehe [Receipt.tipCents]). */
    tipCents?: number | null;
    /** Nur bei Belegen mit Zahlungsliste (siehe [Receipt.payments]). */
    payments?: ReceiptPaymentPayload[] | null;
}
/**
 * Nutzlast-Form, die dieses Paket **liest**. Unterscheidet sich von
 * [ReceiptPayload] bei den Positionen: ein gespeicherter Beleg traegt sie in
 * der v1-Form, die das Backend ablegt (siehe [ReceiptItemPayloadRead]).
 * Nullbelege haben ueberhaupt keine Positionen.
 */
export interface ReceiptPayloadRead extends Omit<ReceiptPayload, 'items' | 'vouchers'> {
    items?: ReceiptItemPayloadRead[] | null;
    vouchers?: VoucherPayload[] | null;
    cancellationOf?: CancellationOf | null;
    cancellationReason?: string | null;
    zeroKind?: string | null;
    cancellations?: Cancellation[] | null;
    headerVersionId?: string | null;
    layoutRuleset?: number | null;
    registrationInfo?: {
        cardRegisteredAt?: string | null;
        cashregisterRegisteredAt?: string | null;
    } | null;
}
/**
 * Schreibt die Nutzlast in der **neuen** Form — sie **normalisiert, statt zu
 * spiegeln**: ein Beleg, der in der v1-Positionsform gelesen wurde, geht hier
 * in der v2-Form wieder hinaus (wie im Flutter-Vorbild, dessen `toJson` v2
 * schreibt und dessen `fromJson` beide Formen liest). Nutzlast rein -> Beleg
 * -> Nutzlast raus ist deshalb kein Rundtrip, wenn die Eingabe v1 war.
 *
 * Fuer dieses Paket ohne Folgen: Belege gehen ausschliesslich ueber
 * `createReceipt` an den Server, das seine Nutzlast selbst baut.
 */
export declare function toReceiptPayload(receipt: Receipt): ReceiptPayload;
export declare function fromReceiptPayload(payload: ReceiptPayloadRead): Receipt;
/** Registrierdaten lesen; ein fehlender oder leerer Zeitstempel wird `null`. */
export declare function readRegistrationInfo(roh: {
    cardRegisteredAt?: unknown;
    cashregisterRegisteredAt?: unknown;
}): RegistrationInfo;
/**
 * Vorzeichen der Wertgutscheine am Beleg: am Storno-Beleg -1, sonst 1.
 *
 * Das Backend spiegelt Wertgutscheine beim Vollstorno mit UNVERAENDERTER
 * `action` und positivem Wert (storno-core.stornoVouchers); der Fluss dreht
 * sich am Storno um (zahlungen-core.wertgutscheinFlussCents, hier
 * `receiptDueCents`): ein verkaufter Gutschein wird zurueckgezahlt, ein
 * eingeloester mindert die Rueckzahlung.
 */
export declare function receiptValueVoucherSign(receipt: Receipt): 1 | -1;
/**
 * Zwischensumme in **Cent** — Positionen plus verkaufte Wertgutscheine minus
 * eingeloeste Aktionsgutscheine. Wertgutschein-Einloesungen wirken erst auf
 * [receiptSumCents], nicht hier (siehe Dart-Vorbild `subSumCents`/`sumCents`).
 * Am Storno-Beleg zaehlen Wertgutscheine mit umgekehrtem Vorzeichen
 * ([receiptValueVoucherSign]), und ein gespiegelter Aktionsgutschein
 * mindert nichts: den Rabatt nimmt der Server dort ueber Ausgleichspositionen
 * (`kind: 'discount'`) zurueck, und belegToepfe verteilt einen Promo-Eintrag
 * nur auf eine positive Topfsumme, die ein Storno nie hat.
 *
 * Gutscheine der neuen Form (Spec 2026-10-14): ihr Betrag steht als Position
 * (`kind: 'voucher'` bei Einzweck/Leistung, `'voucher_float'` im 0-%-Topf) und
 * zaehlt hier schon mit den Positionen. Ein Eintrag mit `zeroRateBucket`
 * (Server: `imNullTopf`, Mehrzweck-Verkauf ab dem Stichtag, Auszahlung) zaehlt
 * darum nicht noch einmal -- sonst stuende der Betrag doppelt am Bon
 * (Vorfall 16.10.2026: Verkauf ueber 30 € mit „Gesamt 60,00“). Eintraege der
 * Arten `single_purpose`/`service` tragen keinen Fluss (wie
 * gutschein-beleg.zahlbetrag, das nur `value`/`promo` an den Fluss gibt).
 */
export declare function receiptSubSumCents(receipt: Receipt): number;
/**
 * Gesamtsumme in **Cent** — Zwischensumme minus eingeloeste Wertgutscheine
 * (am Storno-Beleg plus, siehe [receiptValueVoucherSign]). Zwilling von
 * zahlungen-core.wertgutscheinFlussCents: eine Auszahlung (`payout`) eines
 * Wertgutscheins ohne `zeroRateBucket` mindert wie eine Einloesung; mit
 * `zeroRateBucket` steht sie als Position und zaehlt nur dort.
 */
export declare function receiptSumCents(receipt: Receipt): number;