flfeders/FEDEO
2
1
Fork 0
Code Issues 95 Pull Requests Actions Packages Projects 22 Releases Wiki Activity

Export einer Datei für SEPA Einzüge #182

New Issue
Open
opened 2026-05-15 15:27:05 +00:00 by flfeders · 3 comments
flfeders commented 2026-05-15 15:27:05 +00:00
Owner
Copy Link

Es soll möglich sein, eine Datei zu exportieren, die in Bankportalen gelesen werden kann um Einzüge zu starten. Dabei sollen alle Ausgangsbelege gefiltert werden auf noch nicht bezahlt sowie Zahlungsmethode SEPA. Das einzuziehende Konto findest du im Kunden. Die Export maske sollte vor dem Export eine Auswahl bereitstellen über die zu exportierende Rechnungen sodass der nutzer vor der erstellung der datei noch an und abwählen kann. es sollten default alle angewählt sein.

Es soll möglich sein, eine Datei zu exportieren, die in Bankportalen gelesen werden kann um Einzüge zu starten. Dabei sollen alle Ausgangsbelege gefiltert werden auf noch nicht bezahlt sowie Zahlungsmethode SEPA. Das einzuziehende Konto findest du im Kunden. Die Export maske sollte vor dem Export eine Auswahl bereitstellen über die zu exportierende Rechnungen sodass der nutzer vor der erstellung der datei noch an und abwählen kann. es sollten default alle angewählt sein.
flfeders commented 2026-05-15 15:28:51 +00:00
Author
Owner
Copy Link

KI-AGENT: Plan für die Umsetzung:

  1. Bestehende SEPA-Strecke vervollständigen
  • Vorhandene Dateien nutzen: frontend/pages/export/create/sepa.vue, backend/src/routes/exports.ts, backend/src/utils/export/sepa.ts.
  • Backend-Export so umbauen, dass eine echte pain.008.001.02 XML-Datei erzeugt, in S3 gespeichert und als generatedexports-Eintrag vom Typ sepa abgelegt wird.
  1. Kandidaten sauber serverseitig ermitteln
  • Neuen Backend-Endpunkt für exportierbare SEPA-Ausgangsbelege ergänzen, z. B. GET /exports/sepa/candidates.
  • Filter: Mandant, type in (invoices, advanceInvoices), state = Gebucht, nicht archiviert, payment_type = direct-debit, nicht vollständig bezahlt/offener Betrag > 0.
  • Stornierte Belege ausschließen, analog zur bestehenden useSum().hasCancellationInvoice-Logik.
  • Offenen Betrag serverseitig berechnen, damit Frontend und Export dieselbe Entscheidungsgrundlage haben.
  1. Kunden- und Bankdaten validieren
  • Für jeden Beleg den Kunden laden und prüfen: infoData.hasSEPA, infoData.sepaSignedAt, infoData.bankAccountIds.
  • Zugehöriges entitybankaccounts-Konto laden und entschlüsseln (iban, bic, bankName).
  • Belege ohne gültige Mandats-/Bankdaten entweder nicht exportierbar markieren oder in der Maske mit Grund anzeigen.
  1. Gläubigerdaten klären/ergänzen
  • Prüfen, wo Gläubiger-ID und eigenes Einzugskonto liegen sollen. Aktuell referenziert sepa.ts tenantData.creditorId, das Feld existiert im Tenant-Schema aber nicht sichtbar.
  • Falls noch nicht vorhanden: Konfiguration für Gläubiger-ID sowie eigene IBAN/BIC ergänzen (Tenant-/Banking-Einstellungen) und Migration erstellen.
  1. Exportmaske ausbauen
  • Tabelle auf frontend/pages/export/create/sepa.vue mit echten Spalten: Auswahl, Rechnungsnummer, Kunde, Belegdatum, offener Betrag, Mandatsdatum, IBAN maskiert, Status/Fehler.
  • Standardmäßig alle gültigen Kandidaten auswählen.
  • Ungültige Kandidaten sichtbar, aber nicht auswählbar machen oder separat ausweisen.
  • Gesamtsumme und Anzahl der ausgewählten Einzüge anzeigen.
  • Nach Start Toast anzeigen und zurück zur Exportliste bzw. Exportliste aktualisieren.
  1. XML-Erzeugung umsetzen
  • GrpHdr.NbOfTxs und CtrlSum korrekt berechnen.
  • PmtInf mit Gläubigername, Gläubigerkonto, Gläubiger-ID, Collection-Date und CORE/RCUR befüllen.
  • Pro Rechnung ein DrctDbtTxInf mit EndToEndId, Betrag, Mandatsreferenz, Signaturdatum, Debtor-Name, IBAN/BIC und Verwendungszweck erzeugen.
  • Beträge als EUR mit zwei Nachkommastellen und Punkt formatieren.
  • XML-Dateiname z. B. SEPA_Einzug_YYYY-MM-DD_<uuid>.xml.
  1. Absicherung und Tests
  • Backend-Logik für Betragsermittlung, Filter und XML-Struktur mit fokussierten Tests absichern, falls im Projekt bereits Teststruktur vorhanden ist.
  • Manuell prüfen: Kandidatenliste, Auswahl/Abwahl, Exportstart, Eintrag in /exports, Download und XML-Struktur.

Offene Punkte vor Umsetzung:

  • Welche Mandatsreferenz soll verwendet werden? Vermutlich Kundennummer oder eigenes Feld in customer.infoData.
  • Wo soll das eigene SEPA-Einzugskonto konfiguriert werden, falls es nicht bereits im Mandanten hinterlegt ist?
  • Soll nach Export ein Status am Beleg gespeichert werden, damit derselbe offene Beleg nicht versehentlich mehrfach exportiert wird?
KI-AGENT: Plan für die Umsetzung: 1. Bestehende SEPA-Strecke vervollständigen - Vorhandene Dateien nutzen: `frontend/pages/export/create/sepa.vue`, `backend/src/routes/exports.ts`, `backend/src/utils/export/sepa.ts`. - Backend-Export so umbauen, dass eine echte `pain.008.001.02` XML-Datei erzeugt, in S3 gespeichert und als `generatedexports`-Eintrag vom Typ `sepa` abgelegt wird. 2. Kandidaten sauber serverseitig ermitteln - Neuen Backend-Endpunkt für exportierbare SEPA-Ausgangsbelege ergänzen, z. B. `GET /exports/sepa/candidates`. - Filter: Mandant, `type in (invoices, advanceInvoices)`, `state = Gebucht`, nicht archiviert, `payment_type = direct-debit`, nicht vollständig bezahlt/offener Betrag > 0. - Stornierte Belege ausschließen, analog zur bestehenden `useSum().hasCancellationInvoice`-Logik. - Offenen Betrag serverseitig berechnen, damit Frontend und Export dieselbe Entscheidungsgrundlage haben. 3. Kunden- und Bankdaten validieren - Für jeden Beleg den Kunden laden und prüfen: `infoData.hasSEPA`, `infoData.sepaSignedAt`, `infoData.bankAccountIds`. - Zugehöriges `entitybankaccounts`-Konto laden und entschlüsseln (`iban`, `bic`, `bankName`). - Belege ohne gültige Mandats-/Bankdaten entweder nicht exportierbar markieren oder in der Maske mit Grund anzeigen. 4. Gläubigerdaten klären/ergänzen - Prüfen, wo Gläubiger-ID und eigenes Einzugskonto liegen sollen. Aktuell referenziert `sepa.ts` `tenantData.creditorId`, das Feld existiert im Tenant-Schema aber nicht sichtbar. - Falls noch nicht vorhanden: Konfiguration für Gläubiger-ID sowie eigene IBAN/BIC ergänzen (Tenant-/Banking-Einstellungen) und Migration erstellen. 5. Exportmaske ausbauen - Tabelle auf `frontend/pages/export/create/sepa.vue` mit echten Spalten: Auswahl, Rechnungsnummer, Kunde, Belegdatum, offener Betrag, Mandatsdatum, IBAN maskiert, Status/Fehler. - Standardmäßig alle gültigen Kandidaten auswählen. - Ungültige Kandidaten sichtbar, aber nicht auswählbar machen oder separat ausweisen. - Gesamtsumme und Anzahl der ausgewählten Einzüge anzeigen. - Nach Start Toast anzeigen und zurück zur Exportliste bzw. Exportliste aktualisieren. 6. XML-Erzeugung umsetzen - `GrpHdr.NbOfTxs` und `CtrlSum` korrekt berechnen. - `PmtInf` mit Gläubigername, Gläubigerkonto, Gläubiger-ID, Collection-Date und `CORE/RCUR` befüllen. - Pro Rechnung ein `DrctDbtTxInf` mit `EndToEndId`, Betrag, Mandatsreferenz, Signaturdatum, Debtor-Name, IBAN/BIC und Verwendungszweck erzeugen. - Beträge als EUR mit zwei Nachkommastellen und Punkt formatieren. - XML-Dateiname z. B. `SEPA_Einzug_YYYY-MM-DD_<uuid>.xml`. 7. Absicherung und Tests - Backend-Logik für Betragsermittlung, Filter und XML-Struktur mit fokussierten Tests absichern, falls im Projekt bereits Teststruktur vorhanden ist. - Manuell prüfen: Kandidatenliste, Auswahl/Abwahl, Exportstart, Eintrag in `/exports`, Download und XML-Struktur. Offene Punkte vor Umsetzung: - Welche Mandatsreferenz soll verwendet werden? Vermutlich Kundennummer oder eigenes Feld in `customer.infoData`. - Wo soll das eigene SEPA-Einzugskonto konfiguriert werden, falls es nicht bereits im Mandanten hinterlegt ist? - Soll nach Export ein Status am Beleg gespeichert werden, damit derselbe offene Beleg nicht versehentlich mehrfach exportiert wird?
flfeders commented 2026-05-15 15:33:20 +00:00
Author
Owner
Copy Link

KI-AGENT: Ergänzung zum Umsetzungsplan: Vor dem eigentlichen SEPA-Export sollte zuerst #183 umgesetzt werden.

Der Export soll danach nicht mehr direkt aus verstreuten Kundenfeldern (infoData.hasSEPA, infoData.sepaSignedAt, Bankkonto-Liste) ableiten, welches Konto und welche Mandatsdaten verwendet werden. Stattdessen sollen Rechnungen und Verträge ein konkretes "Ausgehendes SEPA-Mandat" referenzieren.

Angepasste Reihenfolge:

  1. #183 umsetzen: Entität für ausgehende SEPA-Mandate einführen.
  2. Verträge und Rechnungen um Mandatsreferenz erweitern.
  3. Rechnungserstellung so anpassen, dass ein passendes aktives Mandat vom Kunden oder Vertrag vorbelegt werden kann.
  4. SEPA-Export aus #182 auf offene Rechnungen mit Zahlungsmethode SEPA und aktivem Mandat aufbauen.

Damit bleibt die Mandatsdefinition sauber von Kundenstammdaten, Verträgen und konkreten Rechnungen getrennt.

KI-AGENT: Ergänzung zum Umsetzungsplan: Vor dem eigentlichen SEPA-Export sollte zuerst #183 umgesetzt werden. Der Export soll danach nicht mehr direkt aus verstreuten Kundenfeldern (`infoData.hasSEPA`, `infoData.sepaSignedAt`, Bankkonto-Liste) ableiten, welches Konto und welche Mandatsdaten verwendet werden. Stattdessen sollen Rechnungen und Verträge ein konkretes "Ausgehendes SEPA-Mandat" referenzieren. Angepasste Reihenfolge: 1. #183 umsetzen: Entität für ausgehende SEPA-Mandate einführen. 2. Verträge und Rechnungen um Mandatsreferenz erweitern. 3. Rechnungserstellung so anpassen, dass ein passendes aktives Mandat vom Kunden oder Vertrag vorbelegt werden kann. 4. SEPA-Export aus #182 auf offene Rechnungen mit Zahlungsmethode SEPA und aktivem Mandat aufbauen. Damit bleibt die Mandatsdefinition sauber von Kundenstammdaten, Verträgen und konkreten Rechnungen getrennt.
flfeders commented 2026-05-15 16:36:55 +00:00
Author
Owner
Copy Link

KI-AGENT: Der SEPA-Export erzeugt jetzt eine echte pain.008-XML-Datei aus den ausgewählten Lastschrift-Ausgangsrechnungen. Die Daten kommen aus den ausgehenden SEPA-Mandaten inklusive Mandatsreferenz, Mandatstyp, Sequenz, Unterschriftsdatum und Bankverbindung; als Gläubigerkonto wird beim Export ein eigenes Bankkonto ausgewählt. Die erzeugte XML wird wie DATEV-Exporte im Export-Speicher abgelegt und in der Exportliste mit Download-URL gespeichert. Damit ist die Mandatsreferenz in der Datei vorhanden und kann später sehr gut für die automatische Zuordnung importierter Bankbuchungen genutzt werden. Backend- und Frontend-Build wurden erfolgreich ausgeführt.

KI-AGENT: Der SEPA-Export erzeugt jetzt eine echte pain.008-XML-Datei aus den ausgewählten Lastschrift-Ausgangsrechnungen. Die Daten kommen aus den ausgehenden SEPA-Mandaten inklusive Mandatsreferenz, Mandatstyp, Sequenz, Unterschriftsdatum und Bankverbindung; als Gläubigerkonto wird beim Export ein eigenes Bankkonto ausgewählt. Die erzeugte XML wird wie DATEV-Exporte im Export-Speicher abgelegt und in der Exportliste mit Download-URL gespeichert. Damit ist die Mandatsreferenz in der Datei vorhanden und kann später sehr gut für die automatische Zuordnung importierter Bankbuchungen genutzt werden. Backend- und Frontend-Build wurden erfolgreich ausgeführt.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
Doppelte
Dieses Issue existiert schon
 Funktionswunsch
Etwas was es noch nicht gibt
 Hilfe benötigt
Problem
Etwas funktioniert nicht
 Verbesserung
Etwas was schon funktioniert aber noch nicht perfekt ist
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
codexflfeders nico flfeders
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: flfeders/FEDEO#182
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?