Offene Posten — Forderungen
Zweck
Die OP-Liste Forderungen zeigt alle offenen Verkaufsbelege (SalesDocument) gruppiert nach Kunde. Werte wie Bruttosumme, gezahlter Betrag und Restbetrag werden aus den Buchungen (AccountEntries und TransactionAllocation) on read berechnet. Sie ist damit read-only für die Stammdaten — geändert wird über Buchungs-Aktionen (Zahlung erfassen, Storno).
Pendant für Lieferanten-Verbindlichkeiten: /supplier-open-items.
Voraussetzungen
Berechtigungen (CASL)
| Action | Subject | Wirkung | Keycloak-Rolle |
|---|---|---|---|
view | FE_OpenItem | Seite aufrufbar | — |
view | OpenItem | OP-Daten lesen | APP_SPEAMCORE_VIEW_OPEN_ITEM |
view | SalesDocument | Quell-Beleg sichtbar | APP_SPEAMCORE_VIEW_SALES_DOCUMENT |
view | Transaction + TransactionAllocation | Zahlungsverlauf sichtbar (sonst ausgeblendet) | APP_SPEAMCORE_VIEW_TRANSACTION / …_VIEW_TRANSACTION_ALLOCATION |
create | Transaction | Zahlung, Skonto-Zahlung oder Storno verbuchen | APP_SPEAMCORE_CREATE_TRANSACTION |
Schritt-für-Schritt-Anleitung
Forderungen einsehen
- Kunden-Offene Posten (
/customer-open-items) öffnen. - Die obere Liste (
CounterpartyGrid) listet alle Kunden mit offenen Posten — Spalten Kd.-Nr., Kunde, Offene Pos. (Anzahl), Offener Betrag, Überfällig, Bezahlt (30T). - Kunde anklicken — links erscheint die Beleg-Liste (Spalten Belegnummer, Status, Bruttobetrag, Bezahlt, Offener Betrag, Fälligkeit), rechts das Detail-Panel (
OpenItemDetailPanel). - Die vier KPI-Karten oben filtern die Kundenliste — siehe KPI-Cards.
- Der Netto-Schalter blendet die Listen-Beträge zwischen Brutto und Netto um. Über Filter (Standard: „3 Filter ausgewählt") lässt sich nach Settlement-Status (offen/teilweise/…) ein- und ausschalten.
Detail-Panel „Offener Posten"
Rechts zeigt das Panel pro markiertem OP:
| Angabe | Beispiel | Bedeutung |
|---|---|---|
| Status-Badge | „Offen" | settlementStatus (offen / teilweise / beglichen / überzahlt). |
| Offener Betrag | 2.719,15 € | outstandingAmount — noch zu zahlen. |
| Fälligkeit | 29.06.2026 | dueDate aus dem Quell-Beleg. |
| Aktualisiert am | 02.06.2026 | Letzte Neuberechnung. |
| Zahlungsziel | „30 Tage / 2% Skonto bei 10 Tagen" | Aus dem Zahlungsziel des Belegs. |
| Skonto | 2,00 % | Skonto-Prozentsatz, falls Skonto-Frist noch läuft. |
| Zahlbetrag mit Skonto | 2.664,77 € | Reduzierter Betrag bei Zahlung innerhalb der Skonto-Frist. |
| Noch X Tage | „Noch 8 Tage" | Verbleibende Tage der Skonto-Frist. |
Zahlung erfassen
- Kunde und OP markieren.
- Zahlung erfassen klicken —
OpenItemTransactionModalöffnet sich (mode = "payment"). - Transaktionsdatum und Referenz eintragen. Als Quelle wählbar: manuelle Buchung oder Zuordnung zu einer bereits importierten Bank-Transaktion.
- In der Zuordnungs-Tabelle den Betrag je Position eintragen.
- Speichern. Es entsteht eine
Transaction+TransactionAllocation;paidAmountundoutstandingAmountwerden neu berechnet.
Zahlung mit Skonto erfassen
Solange die Skonto-Frist läuft (Detail-Panel zeigt „Noch X Tage"), steht der Button Zahlung mit Skonto erfassen bereit. Er öffnet dasselbe Modal, vorbefüllt mit dem Zahlbetrag mit Skonto (payableWithSkonto); die Skonto-Differenz wird als Skonto-Buchung mit verbucht.
Zahlung stornieren
Zahlung stornieren ist nur aktiv, wenn bereits eine Zahlung verbucht ist. Es öffnet OpenItemTransactionModal mit mode = "reversal" und verbucht eine Gegenbuchung.
Toolbar (Detail-Seite)
Schlanke Toolbar oben rechts:
| Icon | Aktion (aria-label) | CASL | Wirkung |
|---|---|---|---|
| ← | Zurückgehen | — | Zurück zur Liste. |
| 🏠 | Zur Startseite gehen | — | Springt auf das Dashboard / /. |
| ⏮/◀/▶/⏭ | Pagination | — | Navigation durch die gefilterte Liste — Massen-Bearbeitung ohne Liste-Sprung. |
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
Filter: KPI-Cards
Vier Karten oben (activeKpi-State, filtert die Kunden-Liste):
| Karte (UI) | activeKpi | Zeigt |
|---|---|---|
| Gesamt Offen | all | Summe aller offenen Beträge. |
| Überfällig | overdue | Beträge mit dueDate in der Vergangenheit. |
| Heute fällig | dueToday | Beträge, die heute fällig werden. |
| Bezahlt (30T) | paidLast30Days | In den letzten 30 Tagen eingegangene Zahlungen. |
<KIHinweis titel="„Geplant" ist kein KPI-Filter">
Frühere Doku nannte eine Karte „geplant". Tatsächlich heißt die vierte Karte Bezahlt (30T) (paidLast30Days). „geplant" (planned) existiert nur als interner Fälligkeits-Zustand (dueState: overdue / dueToday / planned) eines einzelnen Postens, nicht als Filter-Karte.
Modal: OpenItemTransactionModal
Modi: payment (Zahlung, auch mit Skonto-Vorbelegung) und reversal (Storno). Eingaben: Transaktionsdatum, Referenz, Quelle (manuell oder bestehende Bank-Transaktion) sowie eine Zuordnungs-Tabelle mit Betrag je Position und Skonto-Schalter. Erstellt eine Transaction samt TransactionAllocation und triggert die Re-Berechnung der Read-only-Felder.
Zahlungsverlauf (Buchungs-Historie)
Unter den Buttons listet Zahlungsverlauf die Buchungssätze zum OP (Spalten Datum, Konto, Menge) mit Soll-/Haben-Kennung (S/H) — z. B. S 1400 · Forderungen aus Lieferungen und Leistungen, H 8400 · Erlöse 19% USt, H 1776 · Umsatzsteuer 19%. Das sind dieselben AccountEntries, die beim Sperren bzw. bei der Auto-Sperre nach Übernahme erzeugt werden. Der Block ist nur mit view:Transaction und view:TransactionAllocation sichtbar.
Felder und Eingaben
OpenItem hat keine eigene Edit-Form — alle Felder sind read-only und werden aus Belegen + Buchungen berechnet.
| Feldname | Datentyp | Beschreibung | Wirkung beim Ausfuellen | Voraussetzung |
|---|---|---|---|---|
parentId | UUID | Polymorpher Verweis auf den Quell-Beleg. | Identifiziert den SalesDocument. | — |
parentType | Enum | SalesDocument (Forderung) oder PurchaseDocument (Verbindlichkeit). | Steuert Direction-Logik. Für Forderungen immer SalesDocument. | — |
direction | Enum (derived) | receivable (Forderung) / payable (Verbindlichkeit). | Wird aus parentType abgeleitet. | — |
totalGross | Decimal (computed) | Bruttosumme des Belegs. | Berechnet aus AccountEntries. | — |
paidAmount | Decimal (computed) | Bereits gezahlter Betrag. | Berechnet aus TransactionAllocation. | — |
outstandingAmount | Decimal (computed) | totalGross - paidAmount. | Wird live neu berechnet. | — |
settlementStatus | Enum (computed) | open, partial, settled, overpaid. Schwelle 0,01 € (Rundung). | Steuert Status-Badge und Filter. | — |
dueDate | Datum | Faelligkeitsdatum aus dem Quell-Beleg. | Speist die Karten Überfällig/Heute fällig. | Vom Beleg übernommen. |
dueState | Enum (computed) | overdue, dueToday oder planned — interner Fälligkeits-Zustand. | Nicht mit den KPI-Karten verwechseln (planned ist keine Karte). | Aus dueDate. |
Skonto-Angaben (Skonto-Prozent, Zahlbetrag mit Skonto, Restfrist) stammen nicht aus dem OpenItem selbst, sondern aus dem Zahlungsziel (PaymentTarget: discountPercentage, discountDays, paymentTermDays) des Quell-Belegs und werden im Detail-Panel berechnet angezeigt.
Workflows und Zustaende
Wiederverwendbare Konzepte
Verknuepfungen zu anderen Modulen
- Verkaufsbelege — Quelle der OPs (
parentType = 'SalesDocument'). - Buchhaltung —
TransactionAllocationundAccountEntriesliefern die berechneten Werte. - Mahnwesen — laeuft auf Basis von
dueDateundsettlementStatus. - /supplier-open-items — Pendant für Verbindlichkeiten.
Häufige Fehler und Lösungen
| Fehler | Lösung |
|---|---|
outstandingAmount weicht vom Beleg ab | Eine Teilzahlung ist verbucht (TransactionAllocation) — prüfen Sie den Zahlungsverlauf. |
| Beleg nicht in OP-Liste | Beleg nicht gebucht/gesperrt (kein offener Posten erzeugt); paranoid-Soft-Delete; oder SalesDocument:view fehlt. |
| Zahlung nicht erfasst, obwohl Geldeingang | Zahlung muss explizit über das Modal verbucht sein — automatisches Matching läuft über Transaktions-Vorschläge. |
| Zahlungsverlauf-Block fehlt | view:Transaction und/oder view:TransactionAllocation fehlt. |
| „Bezahlt (30T)" statt „geplant" gesucht | Die vierte KPI-Karte heißt Bezahlt (30T) (paidLast30Days); „geplant" ist kein Filter (siehe KPI-Cards). |
API/Schnittstellen
| Methode | Endpoint | Zweck | CASL |
|---|---|---|---|
GET | /api/open-items?direction=receivable (legacy) | Liste der Forderungen | view OpenItem |
GET | /api/open-items?parentType=SalesDocument | Aequivalent (neue API) | view OpenItem |
POST | /api/transactions (intern, aus Modal) | Zahlung/Skonto/Storno verbuchen — erzeugt Transaction + TransactionAllocation | create Transaction |
Stand der Doku (Code-Lookup): direction und parentType sind redundant — parentType (SalesDocument/PurchaseDocument) reicht aus, um die Richtung zu bestimmen. Aktuell nutzen FE und BE noch beide Felder. Eine Migration auf nur parentType waere Refactor-Arbeit; bis dahin bleibt direction als Komfort-Feld bestehen.
Versionshinweise
- 2026-06-02: Echter Screenshot aus dem Demo-Mandant (mit Daten) ersetzt den Platzhalter. Drift-Fixes gegen FE/BE-master: vierte KPI-Karte korrekt Bezahlt (30T) (
paidLast30Days) statt „geplant"; Skonto im Detail-Panel + Button „Zahlung mit Skonto erfassen" dokumentiert; CASL korrigiert (Zahlungsverlauf brauchtview:Transaction+view:TransactionAllocation, Buchen brauchtcreate:Transactionstattcreate:TransactionAllocation); Detail-Panel-, Grid- und Modal-Felder ergänzt; Zahlungsverlauf = Buchungssätze (Soll/Haben) mit Bezug zur Auto-Sperre;dueState(planned) klar von der KPI-Karte abgegrenzt; Mahnwesen-Abwesenheit am OpenItem notiert. - 2026-04-29: Initiale Veroeffentlichung mit FE-Tiefen-Standard.