- Thema
- VB.NET
- SDK-Mitglieder
- IsKosit Last_Error SaveXML() ZUGFeRD_Profile
- Business Terms
- BT-24 Spezifikationskennung BT-23 Geschäftsprozesstyp
- Codebeispiele
- VB.NET
- Veröffentlicht
Kurz: Manche Empfänger nehmen nur Rechnungen an, deren Kopf EN 16931 oder XRechnung ausweist, verlangen aber Angaben, die es nur in Factur-X EXTENDED gibt. Sobald Sie ein solches Feld setzen, schreibt das SDK die Rechnung als EXTENDED – und der Empfänger lehnt sie ab. Ab Version 11.0.0.18 lösen Sie das mit ForceEN16931Guideline: Der Aufruf direkt vor SaveXML schreibt die gewünschte Kennung in den Kopf (BT-24), die EXTENDED-Felder bleiben im XML.
Der Aufruf
| Mode | Kennung in BT-24 |
|---|---|
-1 (Standard) | folgt isKOSIT: XRechnung, wenn isKOSIT = True, sonst EN 16931 |
1 | EN 16931: urn:cen.eu:en16931:2017 |
2 | XRechnung 3.0: urn:cen.eu:en16931:2017#compliant#urn:xeinkauf.de:kosit:xrechnung_3.0 |
0 | aus: das SDK schreibt wieder die Kennung des tatsächlichen Profils |
' VB.NET
' ... Rechnung aufbauen, auch mit EXTENDED-Feldern ...
alo.ForceEN16931Guideline(1) ' Kopf = EN 16931; 2 = XRechnung
If Not alo.SaveXML("C:\Temp\RE-1001.xml", key) Then
MsgBox(alo.Last_Error)
End IfRufen Sie die Funktion direkt vor dem Speichern auf, also nach den Aufrufen, die auf EXTENDED umstellen. Diese Aufrufe schalten isKOSIT ab; ForceEN16931Guideline(2) schaltet die XRechnung-Angaben wieder ein. Ein unbekannter Mode liefert False und eine Meldung in Last_Error. LastWarning beschreibt die Folgen.
Was Sie dabei wissen müssen
Die Funktion ändert nur den Kopf. Die EXTENDED-Felder stehen weiter im XML. Ob der Empfänger das annimmt, hängt von seinem Prüfprogramm ab. Unsere Tests:
| Prüfung | Ergebnis |
|---|---|
| Eingebauter Validator des SDK | gültig, mit Warnungen zu den zusätzlichen Feldern (z. B. CII-SR-019, CII-DT-052, CII-DT-098) |
| KoSIT-Validator (XRechnung) | angenommen, mit denselben Warnungen |
| Mustang | abgelehnt: Das Schema für EN 16931 kennt die EXTENDED-Elemente nicht |
Klären Sie deshalb vorher mit dem Empfänger, womit er prüft, und testen Sie eine Beispielrechnung in seinem Portal.
Die saubere Alternative: Profil vor dem Speichern zurückstellen
Braucht der Empfänger die EXTENDED-Angaben gar nicht, stellen Sie das Profil direkt vor SaveXML zurück. Der Writer lässt dann alle Felder weg, die es nur in EXTENDED gibt, und die Rechnung ist ohne Warnungen gültig:
alo.ZUGFeRD_Profile = 1 ' EN 16931
alo.isKOSIT = True ' nur für eine XRechnung
alo.SaveXML("C:\Temp\RE-1001.xml", key)Welche Aufrufe eine Rechnung auf EXTENDED umstellen, steht in Warum wird meine XRechnung als Factur-X EXTENDED erstellt?
Häufige Fragen
Wie schreibe ich EN 16931 in den Kopf, obwohl die Rechnung EXTENDED-Felder enthält?
Mit ForceEN16931Guideline(1) direkt vor SaveXML (ab Version 11.0.0.18). Mode 2 schreibt die XRechnung-Kennung. Die EXTENDED-Felder bleiben im XML.
Ist eine solche Rechnung gültig?
Das hängt vom Prüfprogramm ab. Der KoSIT-Validator nimmt sie mit Warnungen an, Mustang lehnt sie ab, weil das Schema für EN 16931 die zusätzlichen Elemente nicht kennt. Testen Sie vorher beim Empfänger.
Gibt es einen Weg ohne Warnungen?
Ja, wenn der Empfänger die EXTENDED-Angaben nicht braucht: ZUGFeRD_Profile = 1 direkt vor SaveXML setzen. Dann lässt das SDK die Felder weg, die es nur in EXTENDED gibt.
Funktioniert das mit isKOSIT = True und False?
Ja. Mit Mode -1 folgt die Kennung isKOSIT, mit Mode 1 oder 2 legen Sie sie ausdrücklich fest.