Release Notes zur Formatumstellung 10.2026
Important: Bitte beachten Sie die am Release angegebene Kompatibilität zur B2B-Version!
Important: Bitte testen Sie die Anpassungen für die nächste Formatumstellung rechtzeitig. Fehler und Fragen können über unser Ticketsystem kommuniziert werden.
Release Planung
FLEE und VC werden in der Regel zusammen mit gleichen Versionsnummern veröffentlicht.
Das letzte Release zur vorherigen FU wird nur der Vollständigkeit halber aufgeführt um den Bruch in der Kompatibilität sichtbar zu machen.
| Release | Datum der Veröffentlichung | VC | FLEE | B2B-Release | Beschreibung |
|---|---|---|---|---|---|
| 2610.0.0 | 22.05.2026 | edi.validation-2610.0.0-nlc.jar | FAST-LANE-EdiEditor-2610.0.0.jar | ab Ende Mai 2026-KW21 | Das erste Release, dass grundsätzlich die Formatumstellung im Oktober unterstützt. Alle kommenden Formatversionen werden auf CONTRL Ebene erkannt und richtig verarbeitet. Für die ersten umgesetzten APERAK prüfungen siehe hier mehr Details. |
| 2604.7.0 | 12.05.2026 | edi.validation-2604.7.0-nlc.jar | FAST-LANE-EdiEditor-2604.7.0.jar | ab Dezember 2025-KW50 | Das geplant letzte Release für die Formatumstellung April 2026, für mehr Details siehe hier. |
Inhalte der Releases
2610.0.0
Hier die einzelnen Anpassungen in diesem Release.
| Task | Beschreibung |
|---|---|
| EDIFU-8670 | Aus sicherheitsrelevanten Gründen wurden Versions-Updates von verwendeten Programmbibliotheken vorgenommen. |
| EDIFU-8671 | UTILMD S2.1: Die Prüfung nach gültigen MPIDs in bestimmten CAV-Segmenten wird nun für die einzelnen CAV-Segmente und nicht mehr für die gesamte Nachricht ausgeführt. Zusätzlich werden BlinazkreisClearinglisten nicht mehr überprüft, da historische MPIDs verwendet werden könnten. |
| EDIFU-8686 | INVOIC AHB 1.0b: 31001: Die Bedingung X[903] wurde an folgenden Feldern implementiert: SG26/LIN+Z01, |
| EDIFU-8688 | Nicht mehr genutzte Bedingungen aus INVOIC AHB 1.0b entfernt |
| EDIFU-8691 | Nicht mehr genutzte Bedingungen aus PRICAT AHB 2.1 entfernt |
| EDIFU-8695 | Nicht mehr genutzte Bedingungen aus IFTSTA AHB 2.1 entfernt |
| EDIFU-8699 | MSCONS AHB 3.2: 13009: Die Bedingung X(([902] UND [937][46] UND [573]) ODER ([902] UND [907][48] UND [62]) ODER ([910] UND [906][62])[152]) XOR ([902] UND [906] UND [151]) wurde an folgenden Feldern implementiert: SG10/QTY+220, |
| EDIFU-8700 | MSCONS AHB 3.2: 13009: Die Bedingung X([152] UND [51] UND [501]) XOR ([151] UND [501]) wurde an folgenden Feldern implementiert: SG9/PIA+5, |
| EDIFU-8701 | MSCONS AHB 3.2: 13009: Die Bedingung X([951][510] UND ([522] ODER [524])) XOR ([950][514] UND ([151] XOR [152] UND (([523] ODER [525])))) wurde an folgenden Feldern implementiert: SG6/LOC+172, |
| EDIFU-8702 | Nicht mehr genutzte Bedingungen aus MSCONS AHB 3.2 entfernt |
| EDIFU-8703 | Nicht mehr genutzte Bedingungen aus ORDCHG AHB 1.1 entfernt |
| EDIFU-8704 | ORDRSP AHB 1.1b: 19114: Die Bedingung X[15] X [14] X [4] X [16] wurde an folgenden Feldern implementiert: SG2/AJT+E_0003, |
| EDIFU-8709 | ORDRSP AHB 1.1b: 19005: Die Bedingung X[83] UND [15] X [83] UND [4] X [82] UND [15] X [82] UND [4] wurde an folgenden Feldern implementiert: SG2/AJT+E_0003, 19006: Die Bedingung X[83] UND [15] X [83] UND [4] X [82] UND [15] X [82] UND [4] wurde an folgenden Feldern implementiert: SG2/AJT+E_0003, |
| EDIFU-8711 | Nicht mehr genutzte Bedingungen aus ORDRSP AHB 1.1b entfernt |
| EDIFU-8716 | Nicht mehr genutzte Bedingungen aus QUOTES AHB 1.1a entfernt |
| EDIFU-8717 | Nicht mehr genutzte Bedingungen aus REQOTE AHB 1.2 entfernt |
| EDIFU-8718 | ORDERS AHB 1.1b: 17126: Die Bedingung Muss[13] UND [183] wurde an folgenden Feldern implementiert: SG2/NAD+Z07, |
| EDIFU-8720 | ORDERS AHB 1.1b: 17113: Die Bedingung Muss[19] UND [109] wurde an folgenden Feldern implementiert: SG3/RFF+AGK, |
| EDIFU-8721 | ORDERS AHB 1.1b: 17113: Die Bedingung Muss[24] XOR [18] XOR ([108] UND [19]) wurde an folgenden Feldern implementiert: SG2/LOC+172, |
| EDIFU-8722 | ORDERS AHB 1.1b: 17102: Die Bedingung X([950][521] UND ([21] XOR [24] XOR [51] XOR ([18] UND [493]))) XOR ([951][522] UND ([2] UND [18]) XOR [19]) XOR ([950][523] UND [492] UND [51]) wurde an folgenden Feldern implementiert: SG2/LOC+172, |
| EDIFU-8735 | Nicht mehr genutzte Bedingungen aus ORDERS AHB 1.1b entfernt |
| EDIFU-8738 | Nicht mehr genutzte Bedingungen aus PARTIN AHB 1.1 entfernt |
| EDIFU-8742 | Nicht mehr genutzte Bedingungen aus UTILMD Gas AHB 1.2 entfernt |
| EDIFU-8745 | Nicht mehr genutzte Bedingungen aus UTILTS AHB 1.1 entfernt |
| EDIFU-8806 | Nicht mehr genutzte Bedingungen aus UTILMD AHB Strom 2.2 entfernt |
2604.7.0
Hier die einzelnen Anpassungen in diesem Release.
| Task | Beschreibung |
|---|---|
| EDIFU-8475 | UTILMD: 55613, 55670, 55674 Der Widerspruch, dass nach Paketierung mindestens eine SG8 SEQ Daten der Marklokation mit der Ausprägung Z01 vorhanden sein muss, obwohl keine gültigen Daten vorliegen (kein RFF+Z49, bzw. nur ein RFF+Z53), wurde aufgelöst. Entsprechend der Antwort 2025-00494 wird eine Wiederholung der SG8 mit Ausprägung bzw. Qualität Z98/informative Daten immer gefordert und exakt so viele mit der Ausprägung Z01 wie auch Zeitraum-IDs mit gültigen Daten vorliegen, was keine einzige sein kann. In diesem Fall folgt keine Ablehnung mehr wegen unterschrittener Mindestwiederholbarkeit 1, wie sie in der Paketierung angegeben ist. |
| EDIFU-8671 | UTILMD S2.1: Die Prüfung nach gültigen MPIDs in bestimmten CAV-Segmenten wird nun für die einzelnen CAV-Segmente und nicht mehr für die gesamte Nachricht ausgeführt. Zusätzlich werden BlinazkreisClearinglisten nicht mehr überprüft, da historische MPIDs verwendet werden könnten. |
| EDIFU-8748 | UTILMD, ORDERS, ORDRSP, QUOTES: Die Prüfung, ob der Code der herausgebenden Stelle zur angegebenen MP-ID passt wurde im NAD+VY ergänzt. |
| EDIFU-8749 | UTILMD S2.1: 55218: Die Bedingungen [149] und [169] wurde in ihrer Logik angepasst, so dass für die Prüfung nur Artikel-IDs der gleichartigen SG8 mit der selben Zeitraum-ID verwendet werden. |
| EDIFU-8750 | MSCONS: Es kommt nicht mehr zu Verarbeitungsfehlern von Nachrichten, die der Zeitreihenprüfung unterliegen und, obwohl das nicht gestattet ist, mehr als eine SG5 Liefer-, bzw. Bezugsort haben. |