Kostenpflichtige Erweiterung für den Viewer

Die gelesene Rechnung als Excel-Datei.

Der Exporter ergänzt den (e)Invoice Viewer um zwei Dinge: einen Knopf Export nach Excel und eine Konvertierung zwischen UBL und CII. Aus der Rechnung, die der Besucher ohnehin gerade hochgeladen hat, entsteht eine XLSX-Datei nach einer mitgelieferten EN-16931-Vorlage – jedes Feld in der Zeile, die die Norm dafür vorsieht. Kein zweiter Upload, kein externer Dienst, nichts wird gespeichert.


Echte Ausgabe, kein Mockup

Excel-Export der gelesenen Rechnung: je Zeile die ID, die CII-Rückgabe, die XSD-Ebene, die EN-16931-Kardinalität, die semantische Bezeichnung und der XML-Wert

Die Excel-Datei aus dem Export: jede Zeile mit ID, CII-Rückgabe, XSD-Ebene, Kardinalität nach EN 16931, semantischer Bezeichnung und dem tatsächlichen Wert aus dem XML.

So läuft der Export

Ein Knopf, direkt im Ergebnis.

Search Search

Kein zweiter Dialog

Der Exporter bringt weder ein eigenes Shortcode noch einen eigenen Upload mit. Er erscheint als Knopf im Ergebnisbereich des Viewers – nach jedem erfolgreichen Upload, PDF wie XML.

Note Note

Feste EN-16931-Vorlage

Die Werte werden in eine mitgelieferte Excel-Vorlage eingetragen: eine Zeile je Business Term, eingerückt nach Ebene, mit Kardinalität, Bezeichnung und dem gelesenen Wert nebeneinander.

Tools Tools

Wiederholungen bleiben Wiederholungen

Eine Gruppe, die in der Rechnung mehrfach vorkommt, steht auch in der Datei mehrfach – vier Freitexte werden zu vier Blöcken, zwei Positionsrabatte zu zwei. Kommt sie nicht vor, fällt der Block ganz weg.

Woher die Werte kommen

Aus demselben Lesevorgang wie die Ansicht.

Der Exporter liest die Rechnung nicht selbst. Er greift auf das Datenmodell zu, das der Viewer beim Anzeigen ohnehin schon aufgebaut hat, und ordnet es der Vorlage zu. Damit gibt es keine zweite, unabhängig driftende Auslese-Logik: Was in der Ansicht steht, steht auch in der Datei.

Getestet gegen sechs echte Rechnungen mit unabhängiger Gegenzählung direkt auf dem XML – Positionen, Notizen, Dokument- und Positionsnachlässe, Steuerkategorien; auch der heikle Fall, dass Position 1 zwei Rabatte trägt und Position 2 keinen, landet sauber getrennt.

Voraussetzungen und Grenzen

Erfordert den (e)Invoice Viewer for PEPPOL & EN16931 – WordPress erzwingt das selbst und lässt den Viewer nicht deaktivieren, solange der Exporter aktiv ist.

Vorlage in dieser Fassung die deutsche EN-16931-Vorlage. Englisch, Französisch und EXTENDED liegen bei, sind aber noch nicht angebunden.

Einmalig Anhänge, Referenzdokumente und Klassifikationscodes werden bislang nur einmal statt mehrfach exportiert – eine Grenze der Ausleseschicht, nicht des Exports.

Die zweite Funktion

Dieselbe Rechnung, die andere Syntax.

Eine E-Rechnungs-XML geht hinein, dieselbe Rechnung kommt in der jeweils anderen Syntax der UN/CEFACT-Familie heraus: UBL zu CII oder CII zu UBL. Nützlich überall dort, wo der Empfänger auf einer Syntax besteht, die das eigene System nicht erzeugt.

Liegt das Dokument bereits in der gewünschten Zielsyntax vor, kommt es unverändert zurück – kein überflüssiger Konvertierungslauf. Eine PDF-Eingabe wird mit klarer Meldung abgewiesen statt still falsch verarbeitet: die Konvertierung braucht die rohe XML, die ein PDF-Leser so nicht herausgibt.

Nachgezählt, nicht behauptet

0 Abweichungen Die Konvertierung wurde an drei echten Rechnungen Business Term für Business Term gegengeprüft – über 151, 177 und 176 verglichene Terme hinweg blieb kein einziger Wert auf der Strecke.

Dieselbe Bibliothek die der Viewer ohnehin schon benutzt, um UBL-Eingaben zu lesen. Keine zweite Abbildung, die eigene Wege gehen könnte.

Zwei Wege hinein die REST-Routen /einvoice/v1/export und /einvoice/v1/convert oder die gleichwertigen AJAX-Aktionen.

Erst ansehen, dann exportieren.

Der Exporter setzt auf dem freien (e)Invoice Viewer auf. Probieren Sie zuerst dort eine eigene Rechnung aus – der Export ist derselbe Datenbestand, nur als Datei.

11,90  inkl. 19 % MwSt. · Sofort-Download nach dem Kauf