diff --git a/README.md b/README.md index 51b150d..18540aa 100644 --- a/README.md +++ b/README.md @@ -15,6 +15,8 @@ Before this package, `taxBreakdown.ts` and `correctionInvoicePdf.tsx` were hand- One canonical implementation, consumed by both repos, makes this class of drift structurally impossible instead of relying on manual vigilance. +**2026-07-23, Phase 2:** `InvoiceSeller.bankDetails` (a free-text textarea on `company-settings`) became structured `iban`/`bic` fields — EN16931 e-invoicing wants discrete PaymentMeans data, not a paragraph a human formatted by hand. The footer's bank-details line also changed from "Bankverbindung (für Überweisung): …" to plain "Bankverbindung: IBAN … · BIC …", shown whenever either is set — it was never actually conditional on the order's payment method (that label was misleading), and there's no reason to hide it from a card/PayPal customer who might still want it (e.g. for a refund). + ## How this is consumed Not published to npm — installed as a git dependency: diff --git a/src/correctionInvoicePdf.tsx b/src/correctionInvoicePdf.tsx index cc70988..8f1397a 100644 --- a/src/correctionInvoicePdf.tsx +++ b/src/correctionInvoicePdf.tsx @@ -300,7 +300,13 @@ function CorrectionInvoiceDocument({ kind, order, seller }: { kind: CorrectionIn {seller.registerCourt && seller.registerNumber ? ` · ${seller.registerCourt} · ${seller.registerNumber}` : ""} {seller.managingDirector ? ` · Geschäftsführung: ${seller.managingDirector}` : ""} - {seller.bankDetails ? Bankverbindung (für Überweisung): {seller.bankDetails} : null} + {/* Always shown when set, regardless of payment method — see + invoicePdf.tsx's own comment on this same line. */} + {(seller.iban || seller.bic) && ( + + Bankverbindung: {[seller.iban && `IBAN ${seller.iban}`, seller.bic && `BIC ${seller.bic}`].filter(Boolean).join(" · ")} + + )} diff --git a/src/invoicePdf.tsx b/src/invoicePdf.tsx index 78fe802..f72c2a4 100644 --- a/src/invoicePdf.tsx +++ b/src/invoicePdf.tsx @@ -334,7 +334,15 @@ export function InvoiceDocument({ order, seller }: { order: InvoiceOrder; seller {seller.registerCourt && seller.registerNumber ? ` · ${seller.registerCourt} · ${seller.registerNumber}` : ""} {seller.managingDirector ? ` · Geschäftsführung: ${seller.managingDirector}` : ""} - {seller.bankDetails ? Bankverbindung (für Überweisung): {seller.bankDetails} : null} + {/* Always shown when set, regardless of payment method — not + gated on "Überweisung" specifically (a customer who paid by + card can still want the seller's bank details for other + reasons, e.g. a refund) — see this package's README. */} + {(seller.iban || seller.bic) && ( + + Bankverbindung: {[seller.iban && `IBAN ${seller.iban}`, seller.bic && `BIC ${seller.bic}`].filter(Boolean).join(" · ")} + + )} diff --git a/src/seller.ts b/src/seller.ts index 799a5e0..9e4fe01 100644 --- a/src/seller.ts +++ b/src/seller.ts @@ -11,7 +11,12 @@ export type InvoiceSeller = { sellerEmail: string; vatId: string; taxRatePercent: number; - bankDetails?: string | null; + // Structured (Phase 2 of the e-invoicing migration — EN16931 wants + // discrete PaymentMeans data, not a free-text paragraph a human + // formatted by hand) — replaces what used to be a single `bankDetails` + // textarea field. + iban?: string | null; + bic?: string | null; // Pflichtangaben in Geschäftsbriefen for registered legal forms (§37a // HGB / §35a GmbHG) — optional because a sole proprietorship (the // default legalForm in company-settings) has neither.