Difference between revisions of "Releasenotes 2026 OS.Interchange"

Revision as of 10:26, 29 October 2026

--> zurück zu Releasenotes

Version 5.3.0.20261029

Schwerpunkt dieses Zeitraums ist der Speicherverbrauch von BDI: Mit einer Testrechnung wurden XRechnung und ZUGFeRD wiederholt erzeugt und der Speicher nach jeder Anfrage vermessen. Gefunden und behoben wurden ein Rechnungsdatensatz, den FreeMarker festhalten konnte, und offene Transaktionen nach abgewiesenen oder fehlgeschlagenen Anfragen. Daneben startete BDI an einer Konsole zeitweise ohne REST-Dienste, und Überwachungseinträge gingen auf älteren Datenbanken verloren. Zum Abschluss wurden XRechnung und ZUGFeRD mit den offiziellen Validatoren (KoSIT, Mustang/veraPDF) geprüft; die dabei gefundenen Fehler sind behoben, beide Formate werden nun angenommen.

• Build mit aktueller Softwarefactory
  Änderung siehe OS.Softwarefactory 5.3.0.20261012 und früher
• Fix: Anhänge in der XRechnung leer
• Fix: Rechnungs-XML im ZUGFeRD-PDF falsch benannt - es wurde der vollständig Pfad der Datei eingetragen. (factur-x.xml) wird nun wie erwartet verwendet
• Fix: verschiedene Speicherlöcher in OS.interchange / XRechnung und Zugferd Funktionalität
• Fix: offene Transaktionen verbleiben in verschiedenen Bearbeitungssituationen. Betroffen sind
  • abgewiesene Anfrage
  • bei XRechnung-Import: wenn Problem beim Speichern der empfangenen Daten auftritt
  • bei unerwarteten Fehlern wurden Transaktionen nicht zurückgerollt
• Fix: Rest Dienste wurden gelegentlich nicht gestartet. Ein Reihenfolgproblem beim Start der OSGI Bundles wurde gefixt.
• Fix: Falsche Gesamtsteuer in ZUGFeRD / Factur-X: Das Feld TaxTotalAmount wurde aus dem ersten Steuer-Teilbetrag statt aus der Gesamtsteuer gefüllt. Bei einer Rechnung mit mehreren Steuersätzen stand dort die Steuer nur eines Satzes (Testrechnung: 3,50 € statt 22,50 €), was die Regel BR-CO-14 der EN 16931 verletzt. Nun wird die gespeicherte Gesamtsteuer übernommen, wie es die XRechnung bereits tat. In beiden Vorlagen wird kein Wert berechnet; alle Beträge kommen unverändert aus der Datenbank.
• Fix: Zahlenformate: Das Format der Vorlagen wirkte bisher nur auf den Ersatzwert 0, gespeicherte Werte erschienen im allgemeinen Format (19 statt 19.00, 171.5 statt 171.50). Beträge, Steuersätze und Faktoren stehen nun mit zwei Nachkommastellen, Einzelpreise mit vier, Mengen wie gespeichert ohne Auffüllen.
• Fix: Steuerkategorie der Rechnungszeilen in Factur-X: Das Pflichtfeld CategoryCode einer Zeile wurde ausgelassen, wenn ProductTaxCategoryCode leer war; die Datei war dann schemaungültig. Ersatzweise wird nun die Steuerkategorie des Artikels verwendet, wie in der XRechnung.
• Fix: USt-IdNr. und Steuernummer fehlten: Die Vorlagen lasen die Umsatzsteuer-Identifikationsnummer von Verkäufer und Käufer nur aus den Steuerschema-Zeilen der Partei und übergingen die Felder VAT_ID und TAX_ID der Partei selbst; im Factur-X-XML fehlte die USt-IdNr. des Käufers ganz. Der KoSIT-Validator wies solche Rechnungen mit BR-S-02, BR-CO-26 und BR-DE-16 zurück. Gibt es keine Steuerschema-Zeilen, werden nun VAT_ID (BT-31 bzw. BT-48, Schema VAT/VA) und TAX_ID (BT-32, Schema FC) der Partei übernommen.
• Fix: Name von Verkäufer und Käufer fehlte in der XRechnung: Die Pflichtfelder BT-27 und BT-44 (PartyLegalEntity/RegistrationName) wurden nur geschrieben, wenn ein Registername gepflegt war (BR-06, BR-07). Fehlt er, steht nun der Name der Partei darin.
• Fix: Kontakt: Als Ansprechpartner des Verkäufers erschien der Firmenname und als Kontakt-E-Mail die Adresse der Partei. Verwendet werden nun C_NAME und C_EMAIL, ersatzweise Name und Adresse der Partei.
• Fix: ZUGFeRD-PDF war kein PDF/A: Das Farbprofil sRGB.icc für den OutputIntent lag nicht im Bundle, und der Kontext-Classloader eines OSGi-Threads hätte es auch nicht gefunden. Das PDF blieb ohne Meldung ohne OutputIntent und damit nicht PDF/A-3-konform (veraPDF: „DeviceRGB/DeviceGray … without output intent“). Das Bundle enthält nun das zlib-lizenzierte sRGB-Profil von Apache FOP (resources/icc/) und lädt es über den eigenen Classloader; fehlt es, wird eine Warnung protokolliert.
• Start steht für 20: Im Log erschien bei jedem Start „Getting a lock required more than 20000 ms“, an zwei Stellen. Behoben

• ToDo: aus früheren Installationen können DB Indizes vorhanden sein, die das Schreiben von Monitoringeinträgen der aktuellen Version verhindern.
  • vor Update: Die Datenbank muss bereinigt werden:

  ALTER TABLE monitor_sub_category  DROP INDEX MONITOR_SUB_CATEGORYMSC_NAME_INDEX;
  ALTER TABLE monitor_category      DROP INDEX MONITOR_CATEGORYMCA_NAME_INDEX;
  ALTER TABLE monitor_category      DROP INDEX MONITOR_CATEGORYDK_INDEX;
  ALTER TABLE monitor_main_category DROP INDEX MONITOR_MAIN_CATEGORYMMCA_NAME_INDEX;
  ALTER TABLE monitor_component     DROP INDEX MONITOR_COMPONENTI1;
  CREATE UNIQUE INDEX MONITOR_COMPONENTI1 ON monitor_component (MCO_NAME, MCO_INSTALLATION);

• • alternativ in der Eclipse.ini der Installation vor dem Update im Verzeichnis bdi-conf den Eintrag -DFlyway.active=true ergänzen.

Version 5.2.0.20261006

• Build mit aktueller Softwarefactory
  Änderung siehe OS.Softwarefactory 5.3.20261006 und früher

Version 5.2.0.20260707

• Build mit aktueller Softwarefactory
  Änderung siehe OS.Softwarefactory 5.3.20260707 und früher