xInvoice Zahlungsdetails

mseDoc365 erzeugt die EN16931-Zahlungsdetail-Gruppen in beiden Syntaxen — CII (XRechnung) und UBL (XRechnung-UBL) — indem die Zahlungsmethode des Belegs klassifiziert und die SEPA-spezifischen Daten aus den BC-Standardtabellen aufgelöst werden. Diese Seite beschreibt, wie eine gebuchte Verkaufsrechnung oder Verkaufsgutschrift auf der BC-Seite in den korrekten Zahlungsdetail-Block auf der Empfängerseite übersetzt wird.

Zahlungsmethode → Zahlungsdetail-Klassifizierung

Der Klassifikator liest das Feld Zahlungsmethode → mseBC mseDoc365 UNECE Code (BT-81). Dieser Code bestimmt, welche Zahlungsdetail-Gruppe in der XML erzeugt wird:

UNECE-Code	Bedeutung	XML erzeugt
30	Generische Überweisung	BG-17 — PayeePartyCreditorFinancialAccount (CII) / PayeeFinancialAccount (UBL)
58	SEPA-Überweisung	BG-17
59	SEPA-Lastschrift	BG-19 — PayerPartyDebtorFinancialAccount / PaymentMandate + BT-89 (Mandatsreferenz) + BT-90 (Gläubiger-ID)
sonstige (z. B. 42 Scheck, 48/54/55 Karte)	Nicht-SEPA / keine Bankverbindung	Weder BG-17 noch BG-19 — nur das Element TypeCode / PaymentMeansCode

Ist die Zahlungsmethode des Belegs leer (oder der UNECE-Code darauf leer), setzt das System den UNECE-Code vor der Klassifizierung standardmäßig auf 30. Um beide Gruppen bewusst zu unterdrücken, konfigurieren Sie den UNECE-Code der Zahlungsmethode auf einen anderen Wert als 30 / 58 / 59.

SEPA-Lastschrift (BG-19) — Datenermittlung

Für den Code 59 benötigt das System drei SEPA-spezifische Werte:

• BT-89 Mandatsreferenz — die ID des SEPA-Lastschriftmandats
• BT-90 Gläubiger-Identifikationsnummer — die SEPA-Gläubiger-Nr. des Firmenbankkontos
• BT-91 Zahler-IBAN — die IBAN des im Mandat hinterlegten Kundenbankkontos

Mandat (BT-89) — Auflösungsreihenfolge

Für Verkaufsrechnungen:

1. Das direkt am Beleg gesetzte Mandat (Sales Invoice Header."Direct Debit Mandate ID").
2. Eine Suche über die SEPA-Lastschriftmandate des Rechnungsempfänger-Debitors, die offen sind (Closed = Nein, Blocked = Nein), am Fälligkeitsdatum gültig sind und entweder Ignore Expected Number of Debits = Ja oder Expected Number of Debits > Debit Counter aufweisen. Der erste Treffer gewinnt.
3. Dieselbe Suche über den Auftraggeber-Debitor, falls Rechnungsempfänger und Auftraggeber unterschiedlich sind.

Für Verkaufsgutschriften: Die BC-Standardtabelle Sales Cr.Memo Header führt kein Mandatsreferenz-Feld. Stattdessen liest das System Applies-to Doc. Type = Invoice + Applies-to Doc. No., ermittelt die zugehörige gebuchte Rechnung und übernimmt deren Mandatsreferenz. Ist die Gutschrift keiner Rechnung zugewiesen, läuft dieselbe Rechnungsempfänger → Auftraggeber-Suche.

Liefert keiner der Schritte ein Mandat, wird ein aussagekräftiger Fehler ausgelöst und die XML nicht erzeugt.

Zahler-IBAN (BT-91) — Auflösungsreihenfolge

1. Das im Mandat hinterlegte Kundenbankkonto (SEPA Direct Debit Mandate."Customer Bank Account Code").
2. Das erste Kundenbankkonto mit nicht-leerer IBAN des Rechnungsempfänger-Debitors.
3. Dieselbe Suche über den Auftraggeber-Debitor, falls die beiden unterschiedlich sind.

Die IBAN selbst stammt aus Customer Bank Account.IBAN. Liefert keiner der Schritte eine IBAN, wird ein Fehler ausgelöst.

Gläubiger-Identifikationsnummer (BT-90) — Auflösungsreihenfolge

1. Das am Beleg gesetzte Firmenbankkonto (Sales Header."Company Bank Account Code").
2. Ein Bankkonto mit Use as Default for Currency = Ja, dessen Währungscode dem Belegwährungscode entspricht.
3. Das LCY-Standard-Bankkonto (Default-for-Currency mit leerem Währungscode) — wenn der Beleg in einer Fremdwährung ist und kein währungsspezifisches Default-Konto konfiguriert ist.
4. Als letzte Möglichkeit ein beliebiges Bankkonto, das eine Creditor No. gesetzt hat.

Jeder Schritt schließt gesperrte (Blocked) Bankkonten aus. Der BT-90-Wert selbst kommt aus Bank Account."Creditor No.".

Ist das Firmenbankkonto explizit am Beleg gesetzt und gesperrt, löst das System einen Fehler aus, statt still ein anderes Konto zu wählen — die explizite Auswahl gewinnt, und ein gesperrtes Konto ist nie der richtige Wert.

Überweisung (BG-17) — Erzeugung

Für die Codes 30 und 58 wird BG-17 mit der IBAN (Company Information.IBAN) und dem BIC (Company Information.SWIFT Code) der eigenen Firma als Zahlungsempfänger erzeugt. Das gilt für Rechnungen und Gutschriften gleichermaßen — Gutschriften nutzen denselben Zahlungsdetail-Workflow wie Rechnungen, lediglich die Geldflussrichtung unterscheidet sich (was unabhängig von der XML-Struktur ist).

Fehler und Lösungen

Ist ein Beleg für SEPA-Lastschrift konfiguriert und ein BG-19-Pflichtfeld kann nicht aufgelöst werden, löst das System einen aussagekräftigen Fehler aus. Die Ausgabe wird auf der BC-Seite gestoppt, damit Sie die Daten korrigieren können, bevor der Empfänger eine ungültige Rechnung sieht.

Fehlermeldung	Wo Sie es beheben
No SEPA Direct Debit Mandate could be resolved … on customer X	Setzen Sie Mandatsreferenz am Beleg oder legen Sie ein aktives Mandat (offen, gültig, mit verbleibenden Abbuchungen) für den Kunden an.
SEPA Direct Debit Mandate %1 referenced by the document does not exist	Die Mandatsreferenz am Beleg zeigt auf ein gelöschtes oder umbenanntes Mandat — wählen Sie ein gültiges Mandat aus.
SEPA Direct Debit Mandate %1 has no Customer Bank Account Code	Öffnen Sie das Mandat und tragen Sie sein Customer Bank Account Code ein.
Customer Bank Account … has no IBAN	Tragen Sie die IBAN auf dem Kundenbankkonto ein.
Customer X has no bank account with an IBAN	Legen Sie ein Kundenbankkonto mit IBAN unter der Debitorenkarte an.
Company Bank Account %1 is blocked	Das Firmenbankkonto am Beleg ist gesperrt — wählen Sie ein anderes Konto oder entsperren Sie es.
Bank Account %1 has no Creditor No. set	Tragen Sie Creditor No. auf der Firmenbankkonto-Karte ein (die SEPA-Gläubiger-ID, typischerweise DE…).
No company Bank Account with a Creditor No. could be found	Mindestens ein Firmenbankkonto muss die SEPA-Gläubiger-Nr. tragen — üblicherweise das mit Use as Default for Currency markierte Konto.

Technische Referenz

Der Klassifikator ist die öffentliche Prozedur SetPaymentMeansFlags auf der Puffer-Tabelle mseBC mseDoc365 S. Inv.Buffer (Tabelle 5563231). Sie schreibt fünf Pufferfelder, die von den Schemazeilen gelesen werden:

Feld-Nr.	Feldname	Rolle
30	Is Credit Transfer	Boolean-Gate für die BG-17-Erzeugung (CII + UBL)
31	Is Direct Debit	Boolean-Gate für die BG-19-Erzeugung (CII + UBL) sowie für die BT-90-Hülle in UBL
32	Direct Debit Mandate ID	BT-89
33	Bank Assigned Creditor ID	BT-90
34	Debtor IBAN	BT-91

Die Schemazeilen der getrennten Gruppen tragen Data Type = TypeBoolean, Source Table No. = 5563231 und Check to Process or Ignore = Ja. Siehe XML Schema Line, wie dieses Flag die Unterdrückung des Unterbaums steuert.

Anpassung kundenseitig

Da SetPaymentMeansFlags innerhalb von CreateBuffer vor OnAfterCreateBuffer ausgeführt wird, können Erweiterungen die fünf Pufferfelder in ihrem OnAfterCreateBuffer-Abonnenten lesen oder überschreiben, wenn ein Sonderfall andere Daten benötigt.

Um die Schemazeilen selbst anzupassen, setzen Sie Locked = Ja auf den BG-17- / BG-19- / BT-89- / BT-90- / BT-91-Zeilen in der Seite "XML Schema Lines". Ihre Anpassungen bleiben dann über Schema-Refreshes vom Standard erhalten — Details im Abschnitt Locking auf der XML-Schema-Line-Seite.