SEPA-Sammellastschrift, Fehler: SEPAException: Name des Zahlungsempfängers ist noch nicht gefüllt

[KlausB]

Hallo zusammen,
nach der Installation des forks, jetzt JVerein-Version 2.8.20, kommt bei Erstellung von Sammellastschriften der Fehler
de.jost_net.OBanToo.SEPA.SEPAException: Name des Zahlungsempfängers ist noch nicht gefüllt
wenn die erstellte .tmp-Datei eingelesen wird.
Ich habe versucht den Vereinsnamen einzukürzen bzw. Umlaute, usw. zu entfernen. Das ändert nichts.
In der .tmp-Datei ist der Name m.E. richtig hinterlegt:
<GrpHdr>
<MsgId>1677008489995</MsgId>
<CreDtTm>2023-02-21T20:41:35</CreDtTm>
<NbOfTxs>xx</NbOfTxs>
<CtrlSum>xxx.xx</CtrlSum>
<InitgPty>
<Nm>Diagnose Funk</Nm>
</InitgPty>
</GrpHdr>
("xx.." = Summen unkenntlich gemacht)
Weiß jemand, was der Fehler sein könnte?
Herzlichen Gruß
KlausB
PS: Ich muss morgen eigentlich den Abrechnungslauf für März machen, also es eilt, wie immer, in so Situationen ...

[NicoB77]

Hallo Klaus,

ohne Traceback (sollte in der Log-Datei stehen) ist das schwierig. Wenn es schnell gehen soll, würde ich wieder die alte Version installieren und die Datenbank aus einem Backup vor dem Wechsel wieder herstellen (in der 2.8.20-Version wird die interne Datenbank angepasst).

Viele Grüße
Reinhard

PS: Der interessante Teil aus dem Log sieht so aus:

Code: Alles auswählen

[Mon Feb 13 18:31:16 CET 2023][ERROR][main][de.willuhn.jameica.gui.input.DecimalInput.getNumber] unable to parse text as decimal number: -
java.text.ParseException: Unparseable number: "-"
	at java.base/java.text.NumberFormat.parse(NumberFormat.java:431)
	at de.willuhn.jameica.gui.input.DecimalInput.getNumber(DecimalInput.java:196)
	at de.willuhn.jameica.gui.input.DecimalInput.getValue(DecimalInput.java:153)
	at de.willuhn.jameica.gui.input.AbstractInput.update(AbstractInput.java:319)
	at de.willuhn.jameica.gui.input.AbstractInput$1.handleEvent(AbstractInput.java:197)
	at de.willuhn.jameica.gui.util.DelayedListener$1$1.run(DelayedListener.java:96)
	at org.eclipse.swt.widgets.Display.timerProc(Display.java:5700)
	at org.eclipse.swt.internal.gtk.OS._g_main_context_iteration(Native Method)
	at org.eclipse.swt.internal.gtk.OS.g_main_context_iteration(OS.java:1596)
	at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:4581)
	at de.willuhn.jameica.gui.GUI.loop(GUI.java:925)
	at de.willuhn.jameica.gui.GUI.init(GUI.java:328)
	at de.willuhn.jameica.system.Application.init(Application.java:145)
	at de.willuhn.jameica.system.Application.newInstance(Application.java:87)
	at de.willuhn.jameica.Main.main(Main.java:75)

[KlausB]

Ich bin schon auf der Suche, Moment bitte ...

[KlausB]

Hier der Fehler:

Code: Alles auswählen

[Wed Feb 22 13:52:34 CET 2023][ERROR][bg-task:][de.jost_net.JVerein.gui.control.AbrechnungSEPAControl$3.run] error while reading objects from C:\Users\User\AppData\Local\Temp\sepafrst13312193074545308320.tmp
de.jost_net.OBanToo.SEPA.SEPAException: Name des Zahlungsempfängers ist noch nicht gefüllt
	at de.jost_net.OBanToo.SEPA.Basislastschrift.Basislastschrift.getName(Basislastschrift.java:593)
	at de.jost_net.OBanToo.SEPA.Basislastschrift.Basislastschrift2Pdf.outputHeader(Basislastschrift2Pdf.java:148)
	at de.jost_net.OBanToo.SEPA.Basislastschrift.Basislastschrift2Pdf.<init>(Basislastschrift2Pdf.java:95)
	at de.jost_net.JVerein.io.AbrechnungSEPA_hbci4java.ausdruckenSEPA(AbrechnungSEPA_hbci4java.java:750)
	at de.jost_net.JVerein.io.AbrechnungSEPA_hbci4java.<init>(AbrechnungSEPA_hbci4java.java:351)
	at de.jost_net.JVerein.gui.control.AbrechnungSEPAControl$3.run(AbrechnungSEPAControl.java:480)
	at de.willuhn.jameica.gui.GUI$7.run(GUI.java:1081)

[NicoB77]

Entferne mal den Haken bei "SEPA-Datei drucken", dann könnte es funktionieren. Der Fehler scheint erst beim Erzeugen der PDF-Dateien aufzutreten.

[KlausB]

Haken entfernt und schon ein Stück besser. Es entsteht kein Fehler mehr, der Abrechnungslauf wird erstellt.
Allerdings war/ist das eigentliche Problem, dass ein direkter Übertrag zu Hibiscus mit der Einstellung "Abbuchungsausgabe: Hibiscus" nicht gelingt.
Erst mit der Einstellung "Abbuchungsausgabe: Datei" wird eine xml-Datei erstellt, die in Hibiscus importiert werden kann.
So weit, so gut. Ich hoffe, das kann irgendwann gelöst werden.
Herzlichen Gruß
KlausB

[sbuer]

Hi,

du hast Recht. In der Vorabversion vom mir jverein 2.8.20.20220924 kann zwar der Abrechnungslauf mit aktualisierten SEPA Schematas erzeugt werden (PDF-Drucken ist dabei deaktiviert), aber egal ob man Hibiscus oder Datei als Ausgabe wählt, es wird grundsätzlich nur die Dateiausgabe genutzt. Das ist natürlich ein Fehler und sollte so nicht sein. Das muß ich nochmal näher prüfen - deswegen ist das auch nur eine Vorabversion, weil der Code sehr komplex ist und das ganze steht und fällt mir sorgfälltigen Testen.

Um Deinen Abrechnungslauf durchzuführen, kannst Du natürlich die XMLs in Hibiscus oder aber zurück auf die 2.8.19 wechseln und dort wird der Abrechnungslauf sauber gegen Hibiscus erzeugt.

Gruß,
Stefan

[sbuer]

Hi,

ich habe mir das Problem nochmal angesehen und den Fehler behoben. Einen PR habe ich erzeugt.
Die Vorab-Version kann aus meinen Repository (welches ein Openjverein Fork ist) installliert werden. (Achtung diese Version hat keinen produktiven Charakter).

Die AbrechnungSEPA Klasse war die ursprüngliche Hauptklasse, die die Abrechnungen durchführt. Damit man aber hbci4java (Auswahl der SEPA XML-Versionen bei Ausgabe DATEI) nutzen kann, habe ich die entsprechende Klasse in AbrechnungSEPA_hbci4java kopiert und dort die Änderungen integriert. Leider sind einige Funktionen immer noch mit dem obantoo verdrahtet. Das wird noch etwas dauern, bis das vollständig in der Klasse autark läuft. Was definitiv noch nicht funktioniert, ist das Ausdrucken der SEPA (Schalter im Abrechnungslauf). Hier muß man etweder die XML aus dem Filesystem heraus drucken oder über Hibiscus (das ist sogar viel komfortabler). Der Programmcode ist sehr komplex und es geht nur dürftig vorran.

Gruß,
Stefan

[NicoB77]

Ich schlage vor, stattdessen auf den alten Code zurückzugehen und die Zeile 140

Code: Alles auswählen

lastschrift.write(param.sepafileFRST, param.sepafileRCUR);

durch eine Funktion zu ersetzen, die die neue XML-Ausgabe nutzt. Das ist weniger Aufwand, schneller fertig und hat weniger Potential, Fehler zu verursachen.