Inoffizielles deutsches Xbase-Forum

langsam kriege ich die Krätze.

Ist das irgendwo hinterlegt, das unterschiedliche SignDatums angaben innerhalb einer XML Datei berücksichtigt werden?

Folgendes Ereignis:

Mein Kunde ruft mich total nervös an. Er hat soeben eine Lastschriftanweisung für 30 Kunden erstellt und ProfiCash hat 7 Vorgänge daraus gemacht. keiner wußte wo das Problem lag. Nach längerer Forscherei kam dann zum Vorschein, dass die XML Datei in der Reihenfolge zwischendurch Sepa Sign Datum hatte von 2014, dann mal wieder ein paar mit 2015, dann wieder 2014 usw. Und nach jedem Wechsel wurde ein neuer Block erzeugt und somit auch ein neuer Vorgang, der zusammengefasst wurde.

Wo steht darüber denn was geschrieben in den Vorgaben für SEPA?

Hallo Manfred,

ich vermute, du meinst mit "Sign Datum" das Feld <DtOfSgntr>, also das Datum der Unterschrift auf dem Mandat. Das gehört normalerweise in den <DrctDbtTxInf>-Block (von dem es i.a. mehrere innerhalb eines <PmtInf>-Segments gibt).

Wie unter dem Topic "SEPA Sammler" würde ich auch hier untersuchen: Wird beim Wechsel des Jahres von <DtOfSgntr> fälschlich ein neues <PmtInf>-Segment eröffnet?

Gruß
Martin.

Hallo Martin,

verstehe ich jetzt nicht so genau. der jeweilige Vorgang steht immer innerhalb eines PmtInf.

Hallo, Manfred.

Die Anzahl der <PmtInf>-Blöcke bestimmt, wie viele einzelne Lastschriftvorgänge es gibt. Im Extremfall gibt es je Lastschrift einen, so dass im Ergebnis lauter Einzellastschriften erzeugt werden würden. Entscheidend hierfür sind das Zahlungsziel, also das Wertstellungsdatum jeder einzelnen Lastschrift, und das Merkmal, ob es sich um Erst- oder Folgelastschriften handelt.

Ich gehe davon aus, dass Du einfach falsch gruppierst, und zwar nach dem von Dir genannten Merkmal, dem Datum des SEPA-Mandats (Einwilligung in das Verfahren). Das ist falsch. Du musst nach Zahlungsziel + Erst-/Folgelastschrift gruppieren, also <PmtInf>-Segmente erzeugen.

Du hast da also 7 <PmtInf>-Segmente für deine 7 Vorgänge? Dann wäre die Frage: Warum hat das Programm nicht alle 30 Lastschriften in ein einziges <PmtInf>-Segment getan? (Mal unterstellt, dass diese im Erstmaligkennzeichen <SeqTp> und im Fälligkeitsdatum <ReqdColltnDt> übereinstimmen.) Unter welcher Bedingung eröffnet dein Programm ein neues <PmtInf>-Segment (und schließt das alte)?

...ah, Tom war schneller...

Alles wieder auf Null. Problem erkannt. Das war gestern ein dummer Zufall. Ich habe gerade mit dem Kunden telefoniert. Es war der Fehler, dass Erst und Folgelastschrift gemischt waren. Das das Sepa Sign Datum dann auch unterschiedlich war, war totaler Zufall. Wir haben das gestern in der Hektik gar nicht erkannt. Aber jetzt gerade ist der Kunde von selbst drauf gekommen. Manmanman. Ich sortiere das jetzt nach Einzugsdatum und dann dürfte das klappen. Und in der Vergangenheit war es alles neu und es gab diese Mischungen nicht. Also es waren nur Erstlastschriften und Folgelastschriften. Und da hat das Bankprogramm nicht gemurrt.

Du musst nach Erst- und Folgelastschriften und darin nach Einzugsdatum sortieren. Also:

1. Alle Erstlastschriften
1.1. Einzug am 9.8.
1.2. Einzug am 10.8.
usw.
2. Alle Folgelastschriften
2.1. Einzug am 9.8.
2.2. Einzug am 10.8.
usw.

1.1 ist ein PmtInf-Segment, 1.2 ist eines, 2.1 ist eines, 2.2 ist eines.

Edit: Das <DtOfSgntr>-Attribut (Datum der Unterschrift des SEPA-Mandats) ist völlig irrelevant, nur zur Information enthalten und ganz sicher kein Sortierkriterium!