Verkaufsbelege

Zweck

Verkaufsbelege bilden den kompletten Verkaufsprozess ab — von der Anfrage des Kunden bis zur Schlussrechnung. Eine Belegart kennt elf documentType-Auspraegungen, jede mit eigenem Status-Set und eigenen Pflichtfeldern.

documentType	Bedeutung	Abrechenbar
request	Anfrage des Kunden	nein
offer	Angebot	nein
orderConfirmation	Auftragsbestätigung	nein
deliveryNote	Lieferschein	nein
creditNote	Gutschrift	ja
depositInvoice	Anzahlungsrechnung	ja
invoice	Standardrechnung	ja
interimInvoice	Abschlagsrechnung	ja
correctionInvoice	Korrekturrechnung	ja
customsInvoice	Zollrechnung	ja
finalInvoice	Schlussrechnung	ja

Voraussetzungen

- Eingerichteter Nummernkreis für den jeweiligen `documentType` (Setup-Wizard, Schritt 11). - Eingerichtete **Zahlungsbedingungen** (Setup-Wizard, Schritt 8) — ausser bei `creditNote`. - Buchhaltungskonten und Steuersätze (Setup-Wizard, Schritt 4). - Empfaenger: Kunde oder Standort.

Berechtigungen (CASL)

Frontend-Page-Guard:

Action	Subject	Keycloak-Rolle
view	FE_SalesDocument	—
view	SalesDocument	APP_SPEAMCORE_VIEW_SALES_DOCUMENT

Tab-Subjects:

Tab	Subject
Positionen	SalesDocumentItem:view
Textbloecke	TextBlock:view, TextBlockParent:view
Dokumente	Document:view, DocumentParent:view

API-Datenzugriff:

Action	Subject	Endpoint	Keycloak-Rolle
view	SalesDocument	GET /api/sales-documents, GET /api/sales-documents/:id, GET /api/sales-documents/available-filter-values	APP_SPEAMCORE_VIEW_SALES_DOCUMENT
create	SalesDocument	POST /api/sales-documents	APP_SPEAMCORE_CREATE_SALES_DOCUMENT
update	SalesDocument	PATCH /api/sales-documents/:id	APP_SPEAMCORE_UPDATE_SALES_DOCUMENT
delete	SalesDocument	DELETE /api/sales-documents/:id	APP_SPEAMCORE_DELETE_SALES_DOCUMENT

Schritt-für-Schritt-Anleitung

Verkaufsbeleg anlegen

1. Öffnen Sie Verkaufsbelege (/sales-documents).
2. Klicken Sie + Neu.
3. Wählen Sie documentType.
4. Setzen Sie den Empfaenger (parentId + parentType — Kunde oder Standort).
5. Pflegen Sie die typenspezifischen Pflichtfelder.
6. Wechseln Sie auf Positionen und ergaenzen Sie Artikel.
7. Speichern. Status startet auf created.

Beleg sperren (GoBD)

locked = true blockiert weitere Änderungen und Löschung — Pflicht für GoBD-konforme Archivierung.

Im Code-Lookup geklärt (SalesDocumentPrintButton.tsx): locked wird automatisch auf true gesetzt, sobald der reguläre Druck-Button ausgelöst wird (PrintService.printPdf ohne protocol-Parameter). Das gilt für Beleg-Drucke wie Rechnungen, Auftragsbestätigungen, Lieferscheine. Druck-Aktionen mit protocol = "PackagingList" | "ExportList" sind interne Hilfs-Drucke und sperren den Beleg nicht. Es gibt zudem ein Schloss-Icon in der Beleg-Toolbar (oben rechts), das den Lock auch manuell setzen kann.

Auto-Sperre nach Übernahme (Juni 2026)

Über die Einstellung lockSalesDocumentAfterTakeover (Setting in der Anpassung) lässt sich festlegen, dass der Quell-Beleg automatisch gesperrt wird, sobald er über „Übernehmen in" in den Folgebeleg überführt wird (z. B. Rechnung → wird übernommen → Quelle sperrt).

Wichtig ist die Gleichbehandlung mit dem regulären Sperren: Seit Juni 2026 erzeugt die Auto-Sperre nach Übernahme — wie der reguläre Lock — zusätzlich

• die Buchungssätze (AccountEntries),
• die Fälligkeit (dueDate, berechnet aus documentDate + Zahlungsziel-Tagen paymentTermDays) und
• den offenen Posten (OpenItem).

Vorher wurde nur locked = true gesetzt — finalisierte Belege landeten dann ohne offenen Posten und ohne Buchung in der OP-Liste. Jede dieser drei Aktionen läuft best-effort: Ein Fehler dabei bricht die Übernahme selbst nicht ab (identisch zum regulären Lock-Flow).

Belege, die **vor** diesem Fix per Auto-Sperre finalisiert wurden, haben keinen offenen Posten. Für diese gibt es einen **Backfill** — als BE-Skript oder über den Endpoint `POST /sales-documents/backfill-open-items` (`create:AccountEntry`) mit Parameter **`fromDate`** (filtert auf das Rechnungsdatum); legt für gelockte, abrechenbare Belege nachträglich Buchungen + offene Posten an und meldet die Zahl (`booked`). Ob ein Nachzug nötig ist, klären Sie mit der Buchhaltung.

Lock-Tracking & Buchen bei Druck/Versand (Juni 2026)

• Lock-Tracking: Beim Sperren wird festgehalten, wie, von wem und wann der Beleg gesperrt wurde (lockSource, sperrender Mitarbeiter, Zeitpunkt) — sichtbar als Lock-Event-Anzeige im Beleg-Detail.
• Druck/Versand getrennt: Druck und Mail-Versand werden jetzt getrennt getrackt und im Beleg-Detail angezeigt (man sieht, ob ein Beleg gedruckt und/oder per Mail versendet wurde).
• Sperre = Buchung — auch bei Druck/Versand: Löst Druck oder Mail-Versand die Sperre aus, werden — wie beim regulären Lock — Buchungssätze (AccountEntries) und der offene Posten erzeugt (vorher konnte ein Beleg beim Drucken gesperrt werden, ohne zu buchen).
• Buchhaltungs-Checks bei jeder PDF-Ausgabe: Bei jeder Beleg-PDF-Ausgabe (Download, Vorschau, Mail) laufen Buchhaltungs-Prüfungen mit — so fallen fehlende Buchungen/Posten früh auf.

Unlock-Guard auf billable Belegtypen (Welle 116)

Das Entsperren eines bereits versendeten Belegs (status = sent) ist aus GoBD-Gründen für steuerlich relevante Belege blockiert. Bis Welle 116 traf der Guard alle Belegtypen pauschal — Auftragsbestätigungen, Angebote und Lieferscheine konnten nach dem Versand nicht mehr entsperrt werden, obwohl sie für GoBD-Archivierung gar nicht relevant sind.

Seit 84f3ab45 greift der Guard nur noch für billable Belegtypen:

billableDocumentTypes = [
  "invoice",
  "interimInvoice",
  "finalInvoice",
  "creditNote",
  "correctionInvoice",
  "depositInvoice"
]

Für offer (Angebot), confirmation (Auftragsbestätigung), deliveryNote (Lieferschein) und andere nicht billable Typen ist das Entsperren nach Versand wieder möglich. Implementiert in salesDocument.controller.ts:1107-1117 (BE).

GoBD-Entsperren: harte Sperren vs. Override (Juni 2026)

Beim Entsperren (POST /sales-documents/:id/unlock, CASL do UnlockSalesDocument) ermittelt SpeamCore alle zutreffenden Sperrgründe (kein Short-circuit) und unterscheidet harte von override-fähigen Sperren:

Sperrgrund	Auslöser	Override möglich?
inAccounting	im abgeschlossenen Monat festgeschrieben (AccountingMonthEntry)	nein — harte Sperre
hasPayments	bereits Zahlungen zugeordnet (TransactionAllocation)	nein — harte Sperre
alreadySent	versendete, billable Rechnung/Gutschrift	ja — einziger override-fähiger Fall

Eine harte Sperre lässt sich unter keinen Umständen entsperren — eine rückwirkende Änderung wäre nicht GoBD-konform. Nur der Fall alreadySent ist per GoBD-Override entsperrbar, und nur, wenn alle drei Bedingungen erfüllt sind:

1. Setting aktiv: allowGobdUnlockOverride in den Rechnungsausgang-Einstellungen ist eingeschaltet.
2. Berechtigung: Der Mitarbeiter hat do GobdUnlockOverride.
3. Ausdrückliche Bestätigung: Im Modal wird der Override doppelt bestätigt (confirmed = true) — mit optionaler Begründung. Der Request-Body lautet { force, confirmed, reason }.

Jede Anwendung wird im Compliance-Audit protokolliert (Aktion salesDocumentGobdUnlockOverride, mit Sperrgrund, Status und Begründung).

Der GoBD-Override umgeht bewusst eine Festschreibung — er ist für seltene, begründete Ausnahmefälle gedacht (z. B. versehentlich zu früh versendet, noch ohne Zahlung/Monatsabschluss). Der **reguläre** Weg, eine versendete Rechnung zu ändern, bleibt der **Korrektur-Flow** (Korrekturrechnung + Storno-Gutschrift, siehe unten). Belege mit Zahlung oder Monatsabschluss sind nie entsperrbar.

Rechnung korrigieren — Korrektur-Flow (Juni 2026)

Der „Korrektur"-Flow (früher ausgeblendet, Welle 116) ist seit Juni 2026 wieder aktiv und GoBD-konform umgesetzt. Eine bereits gesperrte Rechnung wird nicht verändert — stattdessen erzeugt SpeamCore ein Paar:

1. eine Korrekturrechnung (correctionInvoice, entsperrt, beliebig bearbeitbar) und
2. eine Storno-Gutschrift (creditNote, gesperrt), die die Originalrechnung gegenbucht.

So funktioniert es:

1. An der gesperrten Rechnung Korrigieren wählen → das Beleg-Paar wird angelegt; die Zahlungen der Originalrechnung werden auf die Korrekturrechnung umgehängt.
2. Die Korrekturrechnung im Modal anpassen.
3. Bestätigen sperrt die Korrekturrechnung (GoBD), oder Abbrechen verwirft Korrekturrechnung + Storno wieder.

Die Originalrechnung bleibt unverändert erhalten — der Audit-Trail ist lückenlos.

Anzahlungsrechnung → Schlussrechnung (Juni 2026)

SpeamCore unterstützt jetzt den rechtskonformen Ablauf von Anzahlungsrechnung(en) zur Schlussrechnung mit korrekter Absetzung (§ 14 Abs. 5 UStG, EN 16931).

• Anzahlungsrechnung (depositInvoice): Der Kunde sieht eine Position „Anzahlung X % gem. Auftrag". Intern hängen die vollen Auftragsprodukte als Kalkulations-Positionen (für Kosten/Marge). Bei mehreren Steuersätzen entsteht eine Anzahlungsposition pro Steuersatz. Auch Text- und Rabatt-Positionen des Auftrags werden mit unter die Anzahlungs-Position gezogen (als Kalkulations-Kinder) — sonst würden sie auf dem Kundenbeleg als eigene Zeilen neben der einen „Anzahlung X %"-Zeile auftauchen.
• Schlussrechnung (finalInvoice): zeigt die volle Leistung und setzt je geleistete Anzahlung den Betrag ab (Netto + USt + Brutto) → es bleibt der Restbetrag. Der Leistungs-Umfang wird aus der Auftragsbestätigung der Prozess-Kette gezogen, nicht aus der Anzahlung kopiert.
• E-Rechnung: Die Brutto-Summe der Anzahlungen wird als vorausgezahlter Betrag (BT-113) ausgewiesen; die USt-Aufstellung bezieht sich auf die volle Leistung; der zahlbare Betrag ergibt sich als Brutto minus vorausgezahltem Betrag.

Die Umwandlung erfolgt über die Aktion In Schlussrechnung umwandeln (Endpoint POST /sales-documents/:id/convert-to-final); sie ist nur auf einem noch nicht gesperrten Beleg möglich.

Rabatt in der Anzahlung — Reihenfolge der Berechnung

Enthält der Auftrag eine Beleg-Rabatt-Position (Typ Discount, siehe Verkaufsbeleg-Positionen), mindert dieser Rabatt das Auftrags-Netto vor der Anzahlungs-Quote. Die Anzahlungs-Position übernimmt als Basis das bereits rabattierte Netto, dann greift die Prozent-Quote:

Auftrags-Netto 100 €, Beleg-Rabatt 10 €, Anzahlung 50 % → Basis (100 − 10) = 90 €, Anzahlungsbetrag 90 × 50 % = 45 €.

Technisch trägt die Anzahlungs-Zeile den vollen (rabattierten) Auftragspreis und die Anzahlungs-Quote als inversen Rabatt (100 − %); der berechnete Netto-Betrag entspricht damit Preis × Anzahlungs-%. Text-Positionen tragen keinen Wert bei.

Der genaue Wortlaut des Absetzungs-Blocks auf der Schlussrechnung (Ausweis der abgesetzten Anzahlungs-USt) sollte vor dem produktiven Einsatz vom Steuerberater abgenommen werden. Nicht im Funktionsumfang: kumulative VOB-/Bau-Abschlagsrechnungen nach Leistungsstand.

Toolbar (Detail-Seite)

Die Verkaufsbeleg-Detailseite hat eine umfangreiche Toolbar oben rechts mit allen Folgeaktionen, die ein Beleg ausloesen kann. Pro Icon eine eigene Aktion:

Icon	Aktion (aria-label)	CASL	Wirkung
←	Zurückgehen	—	Zurück zur Verkaufsbeleg-Liste.
🏠	Zur Startseite gehen	—	Springt auf das Dashboard / /.
↻	Prozess anzeigen	view:SalesDocument	Visualisiert den aktuellen Status im Lifecycle (Entwurf → Versendet → Bezahlt).
📄	Verkaufsbeleg Vorschau	view:SalesDocument	PDF-Vorschau des Belegs (ZUGFeRD bei Rechnungen) ohne Druck/Download.
🖨	Verkaufsbeleg ausdrucken	view:SalesDocument	Generiert finales PDF und triggert Download/Druck. Bei Rechnung mit ZUGFeRD-XML embedded. Setzt printedAt.
📋	Verkaufsbeleg kopieren in	create:SalesDocument	Belegtyp-Kopie: Erzeugt einen neuen Verkaufsbeleg desselben oder anderen Typs (z. B. „Angebot kopieren in Auftragsbestätigung") mit gleichen Empfaenger-/Positions-Daten. Quell-Beleg bleibt unangetastet.
↗	Verkaufsbeleg übernehmen in	create:SalesDocument	Folgebeleg-Kette: Erzeugt den nächsten Beleg im Lifecycle (Angebot → Auftragsbestätigung → Lieferschein → Rechnung). Setzt parentSalesDocumentId als Referenz; Quell-Beleg wird ggf. gesperrt.
🛒	Einkaufsbeleg(e) erstellen	create:PurchaseDocument	Erzeugt Bestellung(en) beim/bei den Lieferanten der enthaltenen Produkte (Streckengeschaeft). Mehrere Bestellungen, wenn Positionen verschiedene Lieferanten haben.
🔧	Arbeitsauftrag erstellen	create:Workorder	Erzeugt einen Wartungs-/Montage-Auftrag aus dem Verkaufsbeleg. Standort, Mitarbeiter und Betreff werden übernommen.
🔒	Verkaufsbeleg sperren	update:SalesDocument	Setzt locked = true. Beleg ist read-only. Wichtig: Drucken und „übernehmen in" setzen locked = true automatisch (siehe SalesDocumentPrintButton.tsx, Zeile 50).
⏮/◀/▶/⏭	Pagination	—	Navigation durch die gefilterte Belegliste — Massen-Bearbeitung ohne Liste-Sprung.

„**Kopieren in**" vs „**Übernehmen in**" ist eine kritische Unterscheidung: - **Kopieren in** = Klon. Quelle bleibt aktiv, Ziel ist eigenstaendig. Für paralleles Angebot an mehrere Kunden o. ae. - **Übernehmen in** = Folgebeleg. Quelle bekommt `lockedAt` und wird zu Verlauf; Ziel hat Quelle als `parentSalesDocumentId`-Referenz. Steuerung der Belegkette im Verkaufsprozess.

Globale Floating-Drawer (links)

Wie auf jeder Detail-Seite verfuegbar — siehe Floating-Quickbar:

• KAL. (Mini-Kalender)
• ZEIT (Persoenliche Wochen-Arbeitszeit)
• ARBEIT (Eigene bevorstehende Aufträge)

UI-Elemente (Listenseite)

Button: „+ Verkaufsbeleg hinzufuegen"

Listenseite. Öffnet ein Dropdown mit Belegtypen (Anfrage, Angebot, Auftragsbestätigung, Lieferschein, Rechnung, Gutschrift). Klick auf Belegtyp legt direkt den Beleg an, ohne Modal-Dialog. Erfordert create:SalesDocument.

Button: „Dokument hochladen"

Listenseite. Öffnet einen Datei-Upload-Dialog für eingehende Belege (z. B. eingescannte Rechnung, externe Belege). Erzeugt einen Beleg mit Datei-Anhang im Tab Dokumente. Erfordert create:Document.

Filter-Dropdown „documentType + Status"

Listenseite. Wird über GET /api/sales-documents/available-filter-values befuellt — gibt DISTINCT-Pairs zurück.

Felder und Eingaben (Auswahl)

Feldname	Pflicht	Sichtbarkeit	Wirkung beim Ausfuellen	Voraussetzung
documentType	ja (disabled nach Create)	immer	Bestimmt Belegart, Statusoptionen, Sichtbarkeit weiterer Felder und Nummernkreis. Nach Anlage nicht änderbar.	—
salesDocumentNo	automatisch	immer	Wird aus Nummernkreis pro documentType vergeben. Erscheint auf PDF und in Reports.	Nummernkreis für den jeweiligen documentType.
status	ja	immer	Steuert Sichtbarkeit von Aktionen (Sperren, Drucken). Wechsel auf sent macht den Beleg ausserhalb der UI sichtbar (E-Rechnung, OP-Liste).	Erlaubte Status pro documentType (siehe Workflow).
documentDate	ja	immer	Default: heute. Anker für dueDate-Berechnung. Änderung verschiebt Faelligkeit.	—
parentId + parentType	ja	immer	Empfaenger des Belegs (Kunde oder Standort). Setzt im beforeCreate-Hook die parentName/Street/Zip/City/CountryId-Snapshot-Felder.	view:Customer oder view:Location.
parentName/Street/Zip/City/CountryId	—	wenn parent gesetzt	Wird vom Parent übernommen (denormalisiert). Änderungen am Parent wirken nicht rueckwirkend auf bestehende Belege.	—
paymentTargetId	nein	nicht bei creditNote	Bestimmt dueDate über documentDate + paymentTarget.days.	view:PaymentTarget; Zahlungsbedingung muss existieren.
revenueAccountId	nein	immer	Erloeskonto für Buchung. Wird beim Buchen als Kreditseite verwendet.	view:Account.
costCenterId	nein	immer	Kostenstelle für Verrechnung.	view:CostCenter.
dueDate	berechnet	immer	documentDate + paymentTarget.days.	—
resubmissionDate	nein	nur offer	Steuert Wiedervorlage-Liste. Bei Erreichen des Datums erscheint das Angebot in der Wiedervorlage-Anzeige.	—
limitedUntilDate	nein	nur offer	Angebot wird nach diesem Datum als „abgelaufen" markiert.	—
performancePeriodFromDate / performancePeriodToDate	nein	nur abrechenbare	Leistungszeitraum auf der Rechnung. Pflichtangabe nach UStG.	Bei B2B-Belegen verbindlich.
bookingPeriodDate	nein	nur abrechenbare	Buchungs-Stichtag für Periodenabgrenzung.	—
workorderId	nein	immer	Ursprungs-Auftrag. Verknuepft Beleg mit Auftrags-Lifecycle.	view:Workorder.
locked	—	immer	true blockiert alle Updates und Loeschung. Wird typischerweise durch Buchhaltungs-Archivierung gesetzt.	—
paypalTransactionCode	automatisch	nur Rechnung (read-only)	Wird nach erfolgreicher PayPal-Zahlung mit der Capture-ID gefüllt und verlinkt auf die PayPal-Transaktion.	PayPal-Zahlung über die Bezahlseite.

Bezahlung per PayPal-Link

Eine Rechnung kann der Kunde über die öffentliche Bezahlseite per PayPal (oder per GiroCode-Überweisung) begleichen — ohne Login.

• Bezahllink: Beim Drucken/Versenden mit dem QR-Modus „Jetzt bezahlen" (payLinkQr, siehe Rechnungsausgang-Einstellungen) entsteht ein Bezahllink (InvoicePaymentLink); der QR auf dem PDF führt auf /pay/:ref.
• Automatischer Ausgleich: Nach erfolgreicher PayPal-Zahlung bucht SpeamCore eine Transaktion samt Zuordnung gegen die Rechnung — der offene Posten ist ausgeglichen, und paypalTransactionCode wird mit der Capture-ID gestempelt. Idempotenz (Capture + Webhook) ist über die Transaktions-externalId sichergestellt.
• Skonto: Liegt ein gültiges Skonto-Fenster vor, wird der rabattierte Betrag eingezogen und als Skonto-Zahlung gebucht (offener Posten gilt trotzdem als voll ausgeglichen).
• Gebühren-Weitergabe (optional): Ist sie aktiv, entsteht zusätzlich eine separate Gebühren-Rechnung (eigener Beleg) für den PayPal-Aufschlag.
• Keine Teilzahlung: Eine PayPal-Order deckt immer den kompletten offenen Betrag ab.

Die genaue Mechanik beschreibt das Konzept PayPal-Zahlungsannahme.

Workflows und Zustaende

Status-Werte und -Uebergaenge variieren pro documentType. Beispiel offer:

invoice-Lifecycle ist anders: nach sent folgen typischerweise Buchungs-Trigger und schliesslich locked = true.

Stand der Doku: Die vollständige Statusmatrix pro documentType (Anfrage, Angebot, Auftragsbestätigung, Lieferschein, Rechnung, Anzahlungsrechnung, Gutschrift, Zwischenabrechnung) ist im Code in isStatusAllowed() (FE) verteilt. Die wichtigsten Workflows sind oben für offer und invoice skizziert; eine vollständige Matrix über alle 9+ Belegtypen waere ein eigenes Audit, das bei Bedarf aus den Test-Cases von salesDocument.test.ts zusammengetragen werden kann.

Wiederverwendbare Konzepte

• Polymorpher Parent-Pattern
• Berechtigungen verstehen (CASL)

Verknuepfungen zu anderen Modulen

• Empfaenger — Kunde oder Standort (parentType ∈ {Customer, Location}).
• Aufträge — workorderId referenziert Ursprungsauftrag.
• Positionen — SalesDocumentItem (1:N).
• Textbloecke — polymorph (TextBlockParent.parentType = 'SalesDocument').
• Dokumente — polymorph (DocumentParent.parentType = 'SalesDocument').
• Buchhaltung — revenueAccountId, paymentTargetId, costCenterId, AccountingMonthEntry für Items.
• Online-Zahlung — öffentliche Bezahlseite und PayPal-Zahlungsannahme (Feld paypalTransactionCode).

Häufige Fehler und Lösungen

Fehler	Lösung
Beleg nicht änderbar	locked = true durch Buchhaltungs-Archivierung. Korrekturbeleg (correctionInvoice) anlegen.
dueDate weicht ab	Ergibt sich aus documentDate + paymentTarget.days. PaymentTarget prüfen.
paymentTargetId nicht wählbar	documentType = creditNote — bei Gutschriften nicht erforderlich.
Status declined nicht wählbar	Nicht alle Status sind für alle documentType zugelassen.

API/Schnittstellen

Methode	Endpoint	Zweck	CASL
GET	/api/sales-documents	Liste mit Filter	view SalesDocument
GET	/api/sales-documents/:id	Detail	view SalesDocument
POST	/api/sales-documents	Anlegen	create SalesDocument
PATCH	/api/sales-documents/:id	Ändern (Block bei locked)	update SalesDocument
DELETE	/api/sales-documents/:id	Soft-Delete (Block bei locked)	delete SalesDocument
GET	/api/sales-documents/available-filter-values	DISTINCT documentType+Status	view SalesDocument
POST	/api/sales-documents/backfill-open-items	Offene Posten für gelockte abrechenbare Belege nachbuchen (Param fromDate)	create AccountEntry
POST	/api/sales-documents/:id/unlock	Entsperren; mit force+confirmed (+ GobdUnlockOverride + Setting) auch GoBD-Override	do UnlockSalesDocument

Sub-Resources (eigene Routen):

• GET /api/sales-document-items?salesDocumentId=:id — Positionen
• GET /api/text-block-parents?parentId=:id&parentType=SalesDocument — Textbloecke
• GET /api/document-parents?parentId=:id&parentType=SalesDocument — Anhänge

Versionshinweise

• 2026-06-22: GoBD-Entsperren mit Override dokumentiert — harte Sperren (inAccounting, hasPayments) vs. override-fähig (alreadySent); Override nur mit Setting allowGobdUnlockOverride + Berechtigung do GobdUnlockOverride + Bestätigung, protokolliert im Compliance-Audit. Endpoint POST /sales-documents/:id/unlock ({force, confirmed, reason}). Verifiziert an salesDocument.controller.ts (unlockSalesDocument), salesDocument.router.ts, casl.ts (GobdUnlockOverride).
• 2026-06-22: Bezahlung per PayPal-Link ergänzt — neues read-only-Feld paypalTransactionCode (Capture-ID), Abschnitt „Bezahlung per PayPal-Link" und Verweis auf die öffentliche Bezahlseite sowie das Konzept PayPal-Zahlungsannahme. Verifiziert an salesDocument.model.ts (paypalTransactionCode) und paypalOrders.service.ts (Settlement).
• 2026-06-09: Lock-Tracking (wie/von wem/wann gesperrt, lockSource + Lock-Event-Anzeige), Druck und Mail-Versand getrennt getrackt, Sperre bei Druck/Versand bucht jetzt (AccountEntries + OpenItem), Buchhaltungs-Checks bei jeder PDF-Ausgabe (Download/Vorschau/Mail). Neuer Endpoint POST /sales-documents/backfill-open-items (fromDate) zum Nachbuchen offener Posten. Verifiziert an salesDocument.router.ts, print.controller.ts, salesOpenItemBackfill.service.ts.
• 2026-06-02 (nachmittags): Anzahlung verfeinert — Text- und Rabatt-Positionen werden als Kalkulations-Kinder unter die Anzahlungs-Position gezogen; Beleg-Rabatt mindert das Auftrags-Netto vor der Anzahlungs-Quote (Beispiel (100 − 10) × 50 % = 45). Neu: Abschnitt „Auto-Sperre nach Übernahme" (lockSalesDocumentAfterTakeover) — erzeugt jetzt Buchungssätze, Fälligkeit und offenen Posten wie der reguläre Lock (best-effort), inkl. Backfill-Hinweis für Altbestand. EPC-/SEPA-Zahlungs-QR im PDF von unten-rechts auf rechtsbündig-inline umgestellt (reine Layout-Kosmetik). Quelle: BE salesDocument.controller.ts (wrapDepositInvoiceItems, recalculateDepositWrapperPrice, lockSalesDocumentAfterTakeover-Block).
• 2026-06-02: Korrektur-Flow wieder aktiv (GoBD-konform: Korrekturrechnung + Storno-Gutschrift statt Original-Änderung) — ersetzt die Welle-116-„ausgeblendet"-Notiz. Neu: Anzahlung→Schlussrechnung mit Absetzung (§ 14 Abs. 5 UStG, EN-16931-BT-113) über convert-to-final. Endpoints convert-to-final, correct, cancel-correction ergänzt. Steuerberater-Vorbehalt vermerkt. Quelle: BE salesDocument.router.ts, tasks/anzahlung-schlussrechnung/TASK.md.
• 2026-04-29: Initiale Veröffentlichung.
• 2026-05-12 (Welle 116): Korrektur-Button im Beleg-Header vorerst ausgeblendet (BE-Fehler bei Gutschrift-Erzeugung). Unlock-Guard auf billableDocumentTypes eingeschränkt — Auftragsbestätigung, Angebot und Lieferschein lassen sich nach Versand wieder entsperren.