xml Datei effektiv erstellen?

[kirchfritz]

Ansonsten sehe ich nichts außergewöhnliches, das es mit XMLConfig nicht gehen soll.

Ich habe es mit XMLConfig nicht geschafft, einen XML-Knoten in dieser Art zu erzeugen:

<Knoten attribute="123">abcdefg</Knoten>

Vielleicht kann das ja jemand zeigen, wie dies mit XMLConfig geht.

[KoBraSoft]

Hallo,
ich habe mir erlaubt, den Quellcode von XMLBuilder zu manipulieren.
dort habe ich eine neue Methode AddNodeText implementiert.
Damit konnten die Anforderungen einen XML-Knoten mit Text und mit Attribut zu versehen, umgesetzt werden.
Du kannst alles im Quellcode nachvollziehen.
Das Thema "XML als unerwünschte einzeilige Zeichenkette" habe ich so nebenbei miterledigt.

Schöne Weihnachten
Fritz

Vielen Dank Fritz.
Ich habe mir die Änderungen gerade angesehen. Ich hätte das nicht (jedenfalls nicht so schnell und so sauber) hinbekommen. Du solltest unbedingt diese Erweiterung bei Vinicius Sanchez https://github.com/viniciussanchez/xml-builder einreichen.

Ebenfalls schöne Weihnachten
Konrad

[Mathias]

Ich habe es mit XMLConfig nicht geschafft, einen XML-Knoten in dieser Art zu erzeugen:

Jetzt muss ich mal fragen, sind dies XML in der Struktur immer gleich, oder variieren diese.

ZB. die project1.lpi isst immer gleich aufgebaut und sollte sich mit XMLConfig auslesen lassen.

[KoBraSoft]

Dein Vorhaben, das XRechnungs-XML als Text mit Platzhaltern vorzuhalten, und dann nur die Platzhalter zu ersetzen, klingt zwar einfach und gut.
Ich schätze aber, dass Du Probleme bekommst, wenn die XRechnung eine variable Anzahl von Rechnungspositionen enthalten soll.
Dann ist schnell Schluss mit Platzhaltern, die der Einfachheit halber ersetzt werden.
Fritz

Einfach finde ich immer gut.
Ich hatte mir das so vorgestellt, dass ich drei Stringlisten mit Platzhaltern habe. Einen Musterrechnungskopf, eine Musterrechnungsposition und einen Musterrechnungsfuß. Die XRechnung hätte ich aus einem Rechnungskopf, einer oder mehreren Rechnungsposition und einem Rechnungsfuß zusammengesetzt.
Diese Lösung habe ich aber ohnehin wieder verworfen, da ich befürchte dass einzelne Knoten optional sein müssen. Das wäre dann nicht mehr einfach.

ich werde höchstwahrscheinlich mit deinem verbesserten XMLBuilder weiterarbeiten.

[kirchfritz]

Ich habe es mit XMLConfig nicht geschafft, einen XML-Knoten in dieser Art zu erzeugen:

Jetzt muss ich mal fragen, sind dies XML in der Struktur immer gleich, oder variieren diese.

ZB. die project1.lpi isst immer gleich aufgebaut und sollte sich mit XMLConfig auslesen lassen.

Es geht nicht darum ein XML mit XMLConfig auszulesen, sondern mit XMLConfig das XML zu erstellen!
Und einen Knoten mit Textinhalt und Attribut zu erstellen, habe ich bisher noch nicht hingekriegt.

[Moderationshinweis: ChatBot-Ausgabe gelöscht]

[KoBraSoft]

Ich habe nun mein Programm soweit fertig, dass es eine xml für Zugferd Basic erstellt. Die Daten sind fiktiv, aber die Feldnamen sind (hoffentlich) korrekt.

Was ich nicht hinbekommen habe ist, dass Elemente in der Erstellungsreihenfolge geschrieben werden. Sie werden aktuell alphabetisch sortiert. Die xml sollte dennoch korrekt sein.

Als nächsten Schritt habe ich geplant, eine passende Datenbankstruktur zu erstellen und die xml damit zu füllen.
Der letzte (und schwierigste) Schritt wird sein die xml mit einer aufgebohrten fcl-pdf in eine pdf einzubetten.
Anbei die aktuelle Version:

zugferdGenerator.zip

(143.42 KiB) 139-mal heruntergeladen

Ich habe vor das Programm unter eine freie Lizenz zu stellen. Ich muss mich noch einlesen welche geeignet ist.

[kirchfritz]

Was ich nicht hinbekommen habe ist, dass Elemente in der Erstellungsreihenfolge geschrieben werden. Sie werden aktuell alphabetisch sortiert. Die xml sollte dennoch korrekt sein.

Ich fürchte ich muss Dich enttäuschen. Die Reihenfolge der XML-Knoten ist haarklein in den ZUGFeRD-Schemata vorgeschrieben. Jede Abweichung davon führt zur "Invalidität" des XMLs. Wird also vom Empfänger unter keinen Umständen akzeptiert werden.

Warum XMLBuilder die Erstellungsreihenfolge bei der XML-Ausgabe nicht einhält, ist mir ein Rätsel.

Ich glaube, dass dies bei der Verwendung der "normalen" DOM-Verwendung nicht der Fall ist.
Schade, weil ich den XMLBuilder-Ansatz vom Prinzip her gut finde.

Vielleicht findet ja jemand heraus, warum die Erstellungsreihenfolge nicht eingehalten wird.

[KoBraSoft]

Ich fürchte ich muss Dich enttäuschen. Die Reihenfolge der XML-Knoten ist haarklein in den ZUGFeRD-Schemata vorgeschrieben. Jede Abweichung davon führt zur "Invalidität" des XMLs. Wird also vom Empfänger unter keinen Umständen akzeptiert werden.

Ich habe die Test1.xml die die jetzige Version meines Programms erzeugt bei https://www.elster.de/eportal/e-rechnung hochgeladen. Die Datei wurde akzeptiert und visualisiert. Fehlermeldung wurde keine ausgegeben.

[kirchfritz]

Ich habe die Test1.xml die die jetzige Version meines Programms erzeugt bei https://www.elster.de/eportal/e-rechnung hochgeladen. Die Datei wurde akzeptiert und visualisiert. Fehlermeldung wurde keine ausgegeben.

Dass die Datei von Elster.de akzeptiert und visualisiert wurde, bedeutet erst mal gar nix.
Auf der visualisierten Rechnung steht als GesamtRechnungsbetrag 0 Euro, obwohl bei Rechnungsposition 1 2 Einheiten "Programm" zu je 1100 Euro aufgeführt sind zum PositionsGesamtpreis von 2200 Euro.

Screenshot 2024-12-27 131926.png (27.51 KiB) 2347 mal betrachtet

Screenshot 2024-12-27 132700.png (54.21 KiB) 2347 mal betrachtet

Ich fürchte, (Ironieanfang) Deine Kunden freuen sich über derartige Rechnungen (Ironieende)

Was ich damit sagen möchte: Es ist Dir zwar gelungen eine einigermaßen syntaktisch korrekte XML-Datei zu erstellen, sie ist aber immer noch nicht valide und inhaltlich falsch.

[KoBraSoft]

Die Reihenfolge der XML-Knoten ist haarklein in den ZUGFeRD-Schemata vorgeschrieben. Jede Abweichung davon führt zur "Invalidität" des XMLs. Wird also vom Empfänger unter keinen Umständen akzeptiert werden.

Kannst Du mir bitte die Stelle zeigen wo das steht. Die Zugferd doku ist sehr umfangreich.

Warum XMLBuilder die Erstellungsreihenfolge bei der XML-Ausgabe nicht einhält, ist mir ein Rätsel.
Ich glaube, dass dies bei der Verwendung der "normalen" DOM-Verwendung nicht der Fall ist.
Schade, weil ich den XMLBuilder-Ansatz vom Prinzip her gut finde.
Vielleicht findet ja jemand heraus, warum die Erstellungsreihenfolge nicht eingehalten wird.

Das wäre sehr hilfreich.

[kirchfritz]

Guckst Du hier:
https://www.ferd-net.de/standards/zugferd
oder hier:
https://www.ferd-net.de/publikationen-p ... 32-deutsch

[KoBraSoft]

Guckst Du hier:
https://www.ferd-net.de/standards/zugferd
oder hier:
https://www.ferd-net.de/publikationen-p ... 32-deutsch

Die Doku habe ich. Die Volltext suche findet das Wort "Reihenfolge" nicht.
In welcher Datei / ab welcher Zeile ist die " Reihenfolge der XML-Knoten ist haarklein in den ZUGFeRD-Schemata vorgeschrieben"?

[kirchfritz]

Wenn Du z.B. in diese Schema-Datei schaust:

Screenshot 2024-12-28 164958.png (45.59 KiB) 2202 mal betrachtet

dann findest zu zum Beispiel:

Code: Alles auswählen

  <xs:element name="CrossIndustryInvoice" type="rsm:CrossIndustryInvoiceType"/>
  <xs:complexType name="CrossIndustryInvoiceType">
    <xs:sequence>
      <xs:element name="ExchangedDocumentContext" type="ram:ExchangedDocumentContextType"/>
      <xs:element name="ExchangedDocument" type="ram:ExchangedDocumentType"/>
      <xs:element name="SupplyChainTradeTransaction" type="ram:SupplyChainTradeTransactionType"/>
    </xs:sequence>
  </xs:complexType>
  

Die Bedeutung davon ist:
Der Wurzelknoten heißt CrossIndustryInvoice
mit den drei Unterknoten
ExchangedDocumentContext
ExchangedDocument
SupplyChainTradeTransaction

Wie die drei Unterknoten aufgebaut sind, findest sich im Namensraum xmlns:ram="urn:un:unece:uncefact:data:standard:ReusableAggregateBusinessInformationEntity:100"
also in der SchemaDatei mit dem furchtbar langen Dateinamen:
Factur-X_1.07.2_BASIC_urn_un_unece_uncefact_data_standard_ReusableAggregateBusinessInformationEntity_100.xsd

Mit anderen Worten:
Der Aufbau der ZUGFeRD-XML Datei ist genauestens in XSD-SchemaDateien festgelegt.
Die SchemaDateien kannst Du dem ScreenShot hier entnehmen.
Lesen mußt Du die selbst. Ist halt so.

[m.fuchs]

Der Schlüssel ist das hier:

Code: Alles auswählen

<xs:sequence>

Damit wird festgelegt, dass die Reihenfolge der Elemente einzuhalten ist. Ob deswegen irgendein Interpreter aussteigt oder es trotzdem akzeptiert, ist eine ganze andere Sache. Aber wenn das XML nicht diese Reihenfolge einhält darf es abgelehnt werden.

[kirchfritz]

Ich empfehle für das Studium von XSD-Dateien Wikipedia:

Screenshot 2024-12-28 182855.png

(83.53 KiB) Noch nie heruntergeladen