Digitale Formate (XML, XRechnung, ZUGFeRD)
Dieses Kapitel behandelt die Verarbeitung von digitalen Formaten, die nicht mit visuellen Repräsentation eines Dokumentes (also Bilder, Scans, PDFs) zusammenhängen. Das sind Formate wie XRechnung, ZUGFeRD usw. die üblicherweise als XML- oder JSON-Dateien verschickt werden.
- Einführung Digitale Formate: XML, XRechnung und ZUGFeRD in der Software Squeeze
- XML-Pipeline
- XRechnung und ZUGFeRD
- Auswertungstabellen XRechnung und ZUGFeRD
- Konfiguration XML-Auswertung
- XML Formate in Squeeze
- Mandanten- und Lieferanten- Erkennung
- Umschlüsselung von Codes eines elektronischen Beleges
Einführung Digitale Formate: XML, XRechnung und ZUGFeRD in der Software Squeeze
Willkommen zur Dokumentation von Squeeze, insbesondere des Moduls Elektronische-Daten, einer leistungsstarken Komponente zur Verarbeitung digitaler Formate.
In dieser Dokumentation erfahren Sie alles Wichtige zur Nutzung und Verwaltung dieses Moduls, der Schwerpunkt liegt hierbei auf der Verarbeitung von gängigen, digitalen, Formate wie ZUGFeRD und XRechnung. Obwohl die Unterstützung für benutzerdefinierte XML-Formate (Customized XMLs) noch nicht verfügbar ist, wird diese Funktionalität in zukünftigen Updates bereitgestellt.
Digitale Formate im Überblick
In der heutigen digitalen Geschäftswelt sind effiziente und standardisierte Datenformate unerlässlich. Die folgenden Formate spielen dabei eine besonders wichtige Rolle:
XML (Extensible Markup Language) XML ist ein vielseitiges und weit verbreitetes Datenformat, das speziell für die strukturierte Datenspeicherung und -übertragung entwickelt wurde. Es ermöglicht die Definition eigener Tags und Strukturen, was es zu einem flexiblen Werkzeug für unterschiedlichste Anwendungen macht. Der Einsatz von XML sorgt für eine effiziente und transparente Datenkommunikation.
XRechnung XRechnung ist ein speziell für elektronische Rechnungen entwickeltes Format, das in vielen europäischen Ländern, einschließlich Deutschland, gesetzlich vorgeschrieben ist. Es basiert auf XML und erfüllt die Anforderungen der Europäischen Norm EN 16931. Durch die Standardisierung von Rechnungsdaten ermöglicht XRechnung eine einfache und effiziente Verarbeitung und Archivierung elektronischer Rechnungen.
ZUGFeRD (Zentraler User Guide des Forums elektronische Rechnung Deutschland) ZUGFeRD ist ein hybrides Rechnungsformat, das sowohl ein menschenlesbares PDF-Dokument, als auch maschinenlesbare XML-Daten kombiniert. Dieses Format vereinfacht die Rechnungsverarbeitung, indem es die Vorteile beider Formate nutzt. Es ist besonders nützlich für Unternehmen, die mit unterschiedlichen Geschäftspartnern zusammenarbeiten und verschiedene Anforderungen an Rechnungsformate erfüllen müssen.
Squeeze: Ihre Lösung für die Verarbeitung digitaler Formate
Squeeze ist darauf ausgelegt, die Verarbeitung von ZUGFeRD- und XRechnung-Formaten nahtlos zu integrieren. Mit Squeeze können Unternehmen ihre Rechnungsprozesse effizient automatisieren und sicherstellen, dass sie den aktuellen gesetzlichen Anforderungen entsprechen. Die Unterstützung für benutzerdefinierte XML-Formate ist in der Entwicklung und wird in einer zukünftigen Version von Squeeze verfügbar sein, hier finden Sie die aktuell unterstützten Formate.
Hauptfunktionen von Squeeze:
- Verarbeitung von ZUGFeRD-Rechnungen: Squeeze kann ZUGFeRD-Rechnungen problemlos einlesen und die enthaltenen Daten sowohl aus dem PDF- als auch aus dem XML-Teil extrahieren.
- Unterstützung für XRechnung: Squeeze ermöglicht die einfache Handhabung von XRechnungen, was die Konformität mit europäischen Vorschriften sicherstellt.
- Prüfbericht der Koordinierungsstelle für IT-Standards(KoSIT): Squeeze generiert auf Kundenwunsch Konformitätsnachweise für XML-Daten gemäß den KoSIT-Standards.
- Umschlüsselung von technischen Codes in Werte:
Mit Squeeze können Codes die in elektronischen Belegen genutzt werden in hausinterne Werte umgeschlüsselt werden.
Weiterführende Informationen
In den folgenden Kapiteln dieser Dokumentation finden Sie detaillierte Anleitungen zur Funktionsweise, Konfiguration und Verwaltung des Moduls Digitale Formate.
Wir empfehlen, diese Dokumentation gründlich zu lesen und bei Bedarf als Referenz zu verwenden, um das volle Potenzial von Squeeze auszuschöpfen.
XML-Pipeline
In der XML-Pipeline von Squeeze werden XML-Dokumente durch speziell angepasste Verarbeitungsstufen geführt, um den unterschiedlichen Anforderungen der Datenextraktion und Dokumentenkategorisierung gerecht zu werden.
Schritt | Aktuelle Pipeline |
---|---|
Einganskanäle |
- Alle Eingangskanäle prüfen die Dokumente auf ihre Validität in Bezug auf die EN16931-Spezifikationen. |
Initialisierungs-Schritt |
- Hochgeladene XML-Dateien werden in ein internes Standard-XML-Format ( - Je nach Kundenwunsch wird in diesem Schritt ein KoSIT-Prüfbericht erstellt. |
Barcode- Extraktions-Schritt |
- Viewer-Bilder auf Basis der PDF werden erstellt, gilt auch für ZUGFeRD und XRechnung |
OCR-Schritt |
- PDF-Dateien mit eingebetteten XML werden normal verarbeitet, um ein OCR-Ergebnis zu erstellen. - Dieser Schritt wird für reine XML-Dateien übersprungen. |
Klassifizierungs-Schritt |
- Die Klassifizierung von XML-Dokumenten ist derzeit nicht möglich. Eine Fehler wird erzeugt, sobald das Dokument keine Dokumentenklasse nachweist |
Extraktions-Schritt |
- Übliche Extraktionsmechanismen werden ausgeführt oder übersprungen durch die Stapelklasseneigenschaft: - |
Extraktion von XMLs
In der XML-Pipeline von Squeeze erfolgt die XML-Extraktion als letzter Schritt vor der Autovalidierung/Validierung und hat dabei eine besondere Rolle: Sie überschreibt extrahierte Feldwerte aus den KI-Extraktionen und den Lokatoren-Ergebnissen. Die Extraktion von XML-Daten basiert auf dem Mapping, welches im Administrationsbereich angepasst werden kann. Alternativen werden gemäß der Definition im Mapping verarbeitet.
Rendering von XMLs
Das XML-Rendering in Squeeze bezieht sich auf den Prozess der Erstellung von PDF-Dokumenten aus XML-Dateien. Dieser Prozess unterscheidet sich je nach Art des XML-Dokuments und umfasst spezifische Anforderungen für standardisierte und benutzerdefinierte XML-Formate.
Rendering von Spezifischen XML-Dokumenten
Für standardisierte XML-Formate wie XRechnung und ZUGFeRD, die der Norm EN16931 entsprechen, erfolgt das Rendering nach den folgenden Schritten:
-
Erstellung des Zwischenformats: Im InitStep wird aus der XML-Datei ein Zwischenformat erstellt, das als Basis für das PDF-Rendering dient. Dieses Zwischenformat wird aus der
intermediate.xml
generiert, die die für die PDF-Erstellung benötigten Daten enthält. -
PDF-Erzeugung: Basierend auf dem Zwischenformat wird ein PDF-Dokument erstellt, das die strukturierten Daten aus der XML übersichtlich darstellt. Dies ermöglicht die Generierung von PDFs, die den Anforderungen der jeweiligen Spezifikation entsprechen und für den Austausch und die Archivierung verwendet werden können.
Ausblick
In einer zukünftigen Version von Squeeze ist geplant, auch für XML-Dokumente, die nicht den EN16931-Spezifikationen entsprechen, eine vollständige Verarbeitung zu ermöglichen. Diese Weiterentwicklung wird es erlauben, alle Arten von XML-Dokumenten einheitlich und umfassend zu behandeln, wodurch die Integration und Handhabung von benutzerdefinierten XML-Formaten weiter verbessert wird.
XRechnung und ZUGFeRD
XRechnung und ZUGFeRD sind digitale Rechnungsformate, welche in der Praxis als XML-Dateien oder PDFs mit eingebetteten XML-Daten verschickt werden.
Validierung von digitalen Rechnungen
Nicht alle digitalen Rechnungen, die Sie erhalten erfüllen die öffentlichen Standards. In der Praxis kann es daher passieren, dass Lieferanten digitale Rechnungen senden, die nicht durch Squeeze verarbeitet werden, weil die Dateien nicht valide sind.
Eine digitale Rechnung ist valide, wenn sie diese zwei Kriterien erfüllt:
- Die Datei (i. d. R. XML) ist korrekt formatiert. Sie enthält also gültiges XML
- Die fachlichen Kriterien an eine EN-16931 + Extension XML sind erfüllt. Beispiel: Die Rechnung enthält eine gültige Kombination aus Netto-, Steuer- und Brutto-Beträgen.
In der Validierung (UI) weist ein Icon darauf hin, dass ein Dokument als XRechnung verarbeitet wurde.
Validatoren
Hier ein Liste von Validatoren, mit denen Sie prüfen können, ob eine digitale Rechnung valide ist:
- https://erechnungsvalidator.service-bw.de/
- https://validator.invoice-portal.de/
- https://ecosio.com/en/peppol-and-xml-document-validator/
- https://peppol.munich-enterprise.com/xrechnung/
- https://www.zugferd-community.net/de/dashboard/validation (Speziell auch alle ZugFERD Varianten)
Extraktion
Schritt |
|
---|---|
Extraktion |
|
Konfiguration von XML-Auswertungen
Ab der Version 2.13 und nach Freischaltung durch Dexpro oder einen der Partner, können Sie in die Extraktion von XML-Werten bei EN16931 konformen XML-Dokumenten eingreifen.
Siehe auch XRechnung und ZUGFeRD Auswertungstabellen
PDF-Rendering
Das PDF-Rendering für XRechnung und ZUGFeRD hat sich ebenfalls geändert:
-
EN-16931 konforme XML-Dokumente: Für standardisierte XML-Dokumente wie XRechnung und ZUGFeRD wird eine PDF aus dem Zwischenformat erstellt, das im InitStep generiert wurde. Dieses Zwischenformat basiert auf der
intermediate.xml
und wird genutzt, um alle relevanten Daten in einer übersichtlichen PDF-Darstellung zu präsentieren.
In der zukünftigen Version von Squeeze wird die vollständige Unterstützung für die PDF-Erzeugung von nicht EN16931-konformen XML-Dokumenten implementiert. Dies wird die Flexibilität und Integration für benutzerdefinierte XML-Formate weiter verbessern.
XML-Prüfbericht KoSIT
Ab Version 2.15 von Squeeze bietet unsere Squeeze-Lösungen die Möglichkeit, automatisch Prüfberichte für verarbeitete ZUGFeRD und XRechnung-Daten zu erstellen. Diese Berichte entsprechen den KoSIT-Standards und gewährleisten die Datenqualität. Während bei XRechnungen eine strikte Fehlerprüfung erfolgt, um die Datenintegrität zu schützen, bietet das System für ZUGFeRD-Belege eine größere Flexibilität. Dies ermöglicht eine individuelle Anpassung der Verarbeitungsprozesse an die spezifischen Anforderungen der Kunden.
Die Aktivierung der Funktionalität erfolgt durch unsere Partner oder unserer Berater. Den KoSIT Prüfbericht, können Sie sich in der Validierung des Dokumentes anzeigen lassen oder direkt über das Kontext-Menü in der Validierung herunterladen.
Umschlüsselung von Codes in Werte
Ab der Version 2.16 ist es möglich, Codes die in elektronischen Belegen genutzt werden in eigene Werte umzuschlüsseln. Solche Codes werden z.B. verwendet um Mengeneinheiten festzulegen, Steuerfälle zu definieren oder auch um den Vorgang festzulegen.
Hier die Anleitung, wie die Umschlüsselung der Codes aus elektronischen Belegen konfiguriert werden kann.
Auswertungstabellen XRechnung und ZUGFeRD
Standardmäßig werden bereits viele Felder automatisch erkannt und extrahiert. Eine Übersicht der standardmäßig unterstützten Felder finden Sie in den folgenden Tabellen:
Kopfdaten:
Dokumentenklassen-Feld | Xpath |
---|---|
VatId | /xr:invoice[1]/xr:SELLER[1]/xr:Seller_VAT_identifier[1] |
DocumentReference | /xr:invoice[1]/xr:Invoice_number[1] |
DocumentDate | /xr:invoice[1]/xr:Invoice_issue_date[1] |
IBAN | /xr:invoice[1]/xr:PAYMENT_INSTRUCTIONS[1]/xr:CREDIT_TRANSFER[1]/xr:Payment_account_identifier[1] |
CreditorName | /xr:invoice[1]/xr:SELLER[1]/xr:Seller_name[1] |
CreditorCountry | /xr:invoice[1]/xr:SELLER[1]/xr:SELLER_POSTAL_ADDRESS[1]/xr:Seller_country_code[1] |
ServiceDate | /xr:invoice[1]/xr:DELIVERY_INFORMATION[1]/xr:Actual_delivery_date[1] |
TotalAmount | /xr:invoice[1]/xr:DOCUMENT_TOTALS[1]/xr:Invoice_total_amount_with_VAT[1] |
Currency | /xr:invoice[1]/xr:Invoice_currency_code[1] |
OrderNumber | /xr:invoice[1]/xr:Purchase_order_reference[1] |
NetAmount | /xr:invoice[1]/xr:VAT_BREAKDOWN[1]/xr:VAT_category_taxable_amount[1] |
TaxAmount | /xr:invoice[1]/xr:VAT_BREAKDOWN[1]/xr:VAT_category_tax_amount[1] |
TaxRate | /xr:invoice[1]/xr:VAT_BREAKDOWN[1]/xr:VAT_category_rate[1] |
NetAmount2 | /xr:invoice[1]/xr:VAT_BREAKDOWN[2]/xr:VAT_category_taxable_amount[1] |
TaxAmount2 | /xr:invoice[1]/xr:VAT_BREAKDOWN[2]/xr:VAT_category_tax_amount[1] |
TaxRate2 | /xr:invoice[1]/xr:VAT_BREAKDOWN[2]/xr:VAT_category_rate[1] |
NetAmount3 | /xr:invoice[1]/xr:VAT_BREAKDOWN[3]/xr:VAT_category_taxable_amount[1] |
TaxAmount3 | /xr:invoice[1]/xr:VAT_BREAKDOWN[3]/xr:VAT_category_tax_amount[1] |
TaxRate3 | /xr:invoice[1]/xr:VAT_BREAKDOWN[3]/xr:VAT_category_rate[1] |
DueDate | /xr:invoice[1]/xr:Payment_due_date[1] |
CreditorName | /xr:invoice[1]/xr:SELLER[1]/xr:Seller_trading_name[1] |
CreditorName | /xr:invoice[1]/xr:SELLER[1]/xr:SELLER_CONTACT[1]/xr:Seller_contact_point[1] |
TotalAmount | /xr:invoice[1]/xr:DOCUMENT_TOTALS[1]/xr:Amount_due_for_payment[1] |
IBAN | /xr:invoice[1]/xr:PAYMENT_INSTRUCTIONS[1]/xr:DIRECT_DEBIT[1]/xr:Debited_account_identifier[1] |
TaxRate3 | /xr:invoice[1]/xr:VAT_BREAKDOWN[3]/xr:VAT_category_tax_rate[1] |
TaxRate2 | /xr:invoice[1]/xr:VAT_BREAKDOWN[2]/xr:VAT_category_tax_rate[1] |
TaxRate |
|
Positionen:
Spalte | Xpath |
---|---|
PosQuantity | xr:Invoiced_quantity[1]/text() |
PosDescription | xr:ITEM_INFORMATION[1]/xr:Item_name[1]/text() |
PosSinglePrice | xr:PRICE_DETAILS[1]/xr:Item_net_price[1]/text() |
PosTotalAmount | xr:Invoice_line_net_amount[1]/text() |
PosTaxRate | xr:LINE_VAT_INFORMATION[1]/xr:Invoiced_item_VAT_rate[1]/text() |
Um ein erfolgreiches Mapping von Spalten zu gewährleisten muss die Tabelle in der die Spalten angelegt werden den technischen Namen "LineItems" besitzen.
Doppelte Felder werden als Alternativen dem Feldwert angehängt
Sollte der Standard nicht ausreichen, so lesen sie hier wie sie die Auswertung erweitern können
Konfiguration XML-Auswertung
Ab Version 2.13 verfügbar und nach Freischaltung durch Partner oder Dexpro !
Standardmäßig liefert Squeeze eine Vielzahl von vordefinierten Mappings zur Extraktion von Kopfdaten aus Rechnungen. Um die bestmögliche Datenerfassung zu gewährleisten, können Sie diese Mappings individuell anpassen und erweitern. Diese Seite bietet eine Anleitung zur Konfiguration von Kopfdaten/Positionsdaten-Mappings im XML-Format.
In der Administration finden Sie einen neuen Unterpunkt (ZUGFeRD und XRechnung):
2. Sobald Sie den Menüpunkt gewählt haben, kommen Sie in eine tabellarische Übersicht. Auf dieser sollten Sie bereits einige Einträge sehen, die sie nicht bearbeiten können, denn dabei handelt es sich um die Standard-Auswertungen; beschrieben in: XRechnung und ZUGFeRD Auswertungstabellen:
Priorisierung der Mappings
Die Reihenfolge der Mappings spielt eine wichtige Rolle bei der Auswertung der Kopffelder. Squeeze verwendet ein hierarchisches System, um zu bestimmen, welches Mapping für ein bestimmtes Feld verwendet werden soll.
Hierarchie:
- Spezifische Mappings: Mappings, die für einen bestimmten Mandanten, Kreditor und eine Dokumentenklasse definiert sind, haben die höchste Priorität.
- Mandanten- und Kreditor-spezifische Mappings: Sind keine spezifischen Mappings vorhanden, werden Mappings verwendet, die für einen Mandanten und Kreditor definiert sind, unabhängig von der Dokumentenklasse.
- Allgemeine Mappings: Danach folgen Mappings, die nur für die Dokumentenklasse definiert sind, unabhängig von Mandant und Kreditor.
- Standard Mappings: Mappings, die für alle Mandanten, Kreditoren und Dokumentenklassen gelten (Auslieferungszustand), haben die niedrigste Priorität.
Siehe:
Prio |
Mandant |
Kreditor |
Dokumentenklasse |
System-Konfiguration |
1 |
definiert |
definiert |
definiert |
false vor true |
2 |
definiert |
definiert |
* |
false vor true |
3 |
* |
definiert |
definiert |
false vor true |
4 |
* |
definiert |
* |
false vor true |
5 |
definiert |
* |
definiert |
false vor true |
6 |
* |
* |
definiert |
false vor true |
7 |
definiert |
* |
* |
false vor true |
8 |
* |
* |
* |
false vor true |
Anlage neuer Mappings für Kopffelder
Im Tab Kopffelder können Sie neue Mappings anlegen. Dabei wählen Sie die Filterkriterien wie gewünscht.
Beachten Sie dabei, solange keine Dokumentenklasse gewählt wurde, werden ihnen unter Feldname alle Felder aller verfügbaren Dokumentenklassen aufgelistet.
Anlage neuer Mappings für Positionsfelder
Im Tab Positionen können Sie neue Mappings anlegen, dabei wählen Sie die Filterkriterien wie gewünscht.
Beachten Sie dabei, solange keine Dokumentenklasse gewählt wurde werden ihnen unter Spaltenname alle Spalten der verfügbaren ("LineItems-Tabellen") Dokumentenklassen angezeigt.
Wichtig: Es werden nur Spalten aus Dokumentenklassen angezeigt, deren technischer Tabellenname "LineItems" ist.
Bei der der Ermittlung der Spalten werden die konfigurierten Xpath-Ausdrücke mit folgendem Tabellenknotenpunkt ausgewertet: /xr:invoice/xr:INVOICE_LINE
.
Das hat zur folge, dass sie nur Kindelemente des Tabellenknotenpunktes /xr:invoice/xr:INVOICE_LINE
zur Auswertung der Spalten verwenden dürfen.
Beispiel:
Tabellenknotenpunkt-Xpath: /xr:invoice/xr:INVOICE_LINE
Spalten-Xpath-Ausdruck: xr:PRICE_DETAILS[1]/xr:Item_net_price[1]/text()
Daher achten Sie darauf bei den Spalten-Xpath-Audrücken kein "/
" am Anfang zu setzen.
XML-Konformitäts-Prüfung
Seit Version 2.15 bietet die Konfigurationsoberfläche eine integrierte Funktion zur Überprüfung von ZUGFeRD/XRechnung-Dokumenten. Hiermit kann die Konformität des XML-Dokuments mit den spezifischen Anforderungen der gewählten XRechnung-Version bewertet werden.
Sobald sie ein Dokument hochgeladen haben, erhalten Sie in einem das Ergebnis der Prüfung.
Sollte das Ergebnis, negativ ausfallen, wird das Dokument dennoch von Squeeze verarbeitet.
Eine PDF-Prüfbericht steht Ihnen ab Version 2.15 und nach Freischaltung unserer Berater oder Partner in der Validierung zur Verfügung, siehe hier.
Allgemeine Infos
Kontrollieren Sie ihren eingegeben XPath auf einer geeigneten Seite wie zum Beispiel:
http://xpather.com/
Die Auswertung der Xpaths erfolgt auf dem intermediate.xml . Die XML-Datei kann durch ein Download der Anhänge aus der technischen Warteschlange gewonnen werden.
XML Formate in Squeeze
Dieser Artikel beschreibt die allgemeine Verarbeitung von E-Rechnungen im XML-Format und welche EN16931-konformen XML-Dokumente Squeeze verarbeiten kann.
Die folgende Tabelle listet die aktuellsten Versionen der Formate auf, die Squeeze prüft, wenn ein XML-Dokument als eingebettete XML in einem PDF (z. B. ZUGFeRD) oder als einzelnes Dokument (z. B. XRechnung) vorliegt.
Standard | Version |
Factur-X | 1.0 bis 1.0.07 |
ZUGFeRD | 1.0 bis 2.3 |
XRechnung | 1.0 bis 3.0.2 |
In Zukunft wird Squeeze unabhängig von Formaten, XML-Dokumente verarbeiten können
Mandanten- und Lieferanten- Erkennung
Einleitung
Sowohl bei elektronischen Rechnungen im XRechnung- oder ZUGFeRD-Format als auch bei der Verarbeitung beliebiger XML-Dokumente (generische XML-Verarbeitung) wird die Extraktion von Lieferanten- (Kreditoren) und Mandanten-Schlüsseln nach demselben grundlegenden Prinzip durchgeführt. Ziel ist es, die in den elektronischen Rechnungen enthaltenen Informationen zu Geschäftspartnern effizient und zuverlässig in unser internes System zu überführen, um eine weitere Verarbeitung zu ermöglichen.
Prozessbeschreibung
- Identifikation relevanter Daten: In den eingehenden XML-Dokumenten werden die für Geschäftspartner relevanten Daten (z.B. Name, Adresse, Steuernummer) identifiziert.
- Zuordnung zu einem Feldkatalog: Die identifizierten Daten werden anhand eines vordefinierten Feldkatalogs den entsprechenden Feldern in unserem internen System zugeordnet.
- Mapping auf interne Schlüssel: Die zugeordneten Daten werden anschließend unseren internen Schlüsseln für Geschäftspartner zugewiesen.
Detaillierte Betrachtung der Zuordnung für Mandanten und Kreditoren
Mandanten
- Suche in der companysearch: Zunächst wird der in der XML angegebene Mandantenname in unserer internen Firmensuche (companysearch) abgeglichen. Falls ein Treffer gefunden wird, wird der zugehörige interne Schlüssel verwendet.
- Suche nach der VAT-ID: Wenn keine Übereinstimmung in der Firmensuche gefunden wird, wird die in der XML angegebene Umsatzsteuer-Identifikationsnummer (VAT-ID) in unserer Tabelle "Companies" gesucht. Falls hier ein Eintrag existiert, wird der entsprechende interne Schlüssel verwendet.
- Kein Treffer: Wenn keine der beiden Bedingungen erfüllt ist, bleibt der Eintrag für den Mandanten leer.
Kreditoren
- Suche in der creditorsearch: Analog zur Mandantenidentifikation wird zunächst der in der XML angegebene Kreditorenname in unserer internen Kreditoren-Suche (creditorsearch) abgeglichen. Falls ein Treffer gefunden wird, wird der zugehörige interne Schlüssel verwendet.
- Suche nach der VAT-ID des Kreditors: Wenn keine Übereinstimmung in der Kreditoren-Suche gefunden wird, wird die in der XML angegebene Umsatzsteuer-Identifikationsnummer (VAT-ID) des Kreditors in unserer Tabelle "Creditors" gesucht. Falls hier ein Eintrag existiert, wird der entsprechende interne Schlüssel verwendet.
- Kein Treffer: Wenn keine der beiden Bedingungen erfüllt ist, bleibt der Eintrag für den Kreditoren leer.
Zusammenfassung der Mechanismen
Geschäftspartner | Bedingung | Aktion |
---|---|---|
Mandant/Kreditor | Name gefunden in entsprechender Suche | Interner Schlüssel aus der Suche verwenden |
Mandant/Kreditor | Name nicht gefunden, VAT-ID gefunden | Interner Schlüssel aus der entsprechenden Tabelle verwenden |
Mandant/Kreditor | Keine Übereinstimmung | Eintrag bleibt leer |
Umschlüsselung von Codes eines elektronischen Beleges
Diese Seite erklärt das Verfahren, wie Codes eine elektronischen Beleges in andere Werte umgeschlüsselt werden können.
Das Beispiel orientiert sich auf den Vorgang des Beleges z. B. Rechnung oder Gutschrift. Es kann aber auf jeden anderen Wert angewendet werden.
Voraussetzung
Diese Umschlüsselung bezieht sich auf die elektronischen Formate ZUGFeRD und XRechung.
Damit ein Code aus der XML-Datei in einen neuen Wert umgeschlüsselt werden kann, muss zunächst sichergestellt werden, dass der Code aus der XML-Datei stammt. In diesem Beispiel wohlen wir die Standard Vorgänge
- Code 380 = Rechung
- Code 381 = Gutschrift
um weitere Vorgangsarten ergänzen.
Im Standard wird die Zuordnung der Codes 380 und 381 bereits durch die Invoice-Solution von Squeeze durchgeführt.
Um dieses Verhalten anzupassen muss zunächst eine neues Feld-Mapping hinzugefügt werden:
Dieses Mapping ermöglicht, dass beim Auslesen des Codes der XML Datei, eine Umschlüsselung durchgeführt werden kann, da sonst der Standard der Invoice Solution genutzt wird.
Umschlüsselung anderer Codes
Ab der Version 2.16 wurde eine neue Tabelle eingeführt, die genutzt werden kann, um individuell andere Werte statt der Codes zu nutzen und selbst festlegen zu können. Die Tabelle befindet sich unter dem Menüpunkt Stammdaten:
In dieser Tabelle lassen sich die Umschlüsselungen sehr genau konfigurieren. Ähnlich wie bei den Mappings lassen sie die Umschlüsselungen je Unternehmen, Lieferant, Dokumentenklasse und Feld konfigurieren. Hier ein Beispiel, wie die Standard-Codes 380 (Rechnung) und 381 (Gutschrift) um einen weiteren Eintrag 384 (Rechnungskorrektur) erweitern lassen:
Dieses Vorgehen lässt sich nicht nur auf Kopffelder anwenden, sondern auch auf Positionsangaben. So lässt sich mit dieser Möglichkeit auch gut die Umschlüsselung von Mengeneinheiten realisieren.
Hier ein weiteres Beispiel für Mengeneinheiten:
Die Listen lassen sich exportieren und auch wieder importieren, was die Übertragung von Test in Produktivsysteme oder andersherum sehr vereinfacht.