EN16931 (e)Rechnungen für Gravity-PDF – Factur-X, XRechnung und PEPPOL aus einem Feed
Ab 2025 muss ein deutsches Unternehmen dazu in der Lage sein erhalten strukturierte elektronische Rechnungen und von 2028 bis Ausgabe ihnen. Frankreich, Italien, Belgien und die nordischen Länder sind auf dem gleichen Weg. Eine Rechnung, die nur ein PDF ist, wird nicht mehr gezählt.
Dieses Add-on übernimmt die Rechnung Gravity PDF produziert bereits und verwandelt es in
Factur-X / ZUGFeRD (ein EN 16931 XML eingebettet in a
PDF/A-3 Hybrid), XRechnung und/oder PEPPOL BIS Billing 3.0
(jeweils eine eigenständige UBL-XML-Datei neben dem PDF) – beliebige Kombination, pro Feed ausgewählt. Ihr Kunde öffnet ein PDF, das genauso aussieht wie zuvor, und seine Buchhaltungssoftware liest die Datei, die er als Daten erwartet.
An Ihrem Formular, Ihrer PDF-Vorlage oder Ihrem Workflow muss sich nichts ändern.
Was Sie bekommen
- Ein echter Hybrid, kein PDF mit einer daran gehefteten Datei. Das XML wird als PDF-Anhang mit der Beziehung und den XMP-Metadaten eingebettet, die die Spezifikation erfordert, und das Dokument wird tatsächlich als PDF/A-3 umgeschrieben.
- Drei Formate, beliebige Kombination, aus einem Feed. Factur-X/ZUGFeRD, XRechnung und PEPPOL BIS Billing 3.0 – alle basieren auf der gleichen zusammengesetzten Rechnung, sodass es nie zu Meinungsverschiedenheiten kommen kann. Vier Factur-X-Profile: EN 16931 (Komfort), EXTENDED, BASIC und XRechnung 3.0.
- Standalone-XML erhält einen eigenen Download-Link und einen eigenen Benachrichtigungsanhang. Jede von einem Feed erzeugte XRechnung/PEPPOL-Datei erscheint auf dem Eintragsdetailbildschirm und kann zusammen mit dem PDF an Benachrichtigungs-E-Mails angehängt werden.
- XSD-validiert bei jedem einzelnen Build. Wenn das XML nicht validiert werden würde, bleibt Ihr PDF unberührt. Das Add-on versendet niemals eine fehlerhafte Rechnung und ersetzt Ihr Dokument niemals durch eine Fehlerseite.
- Es überlebt eine Korrektur. Bearbeiten Sie einen Eintrag im Backend und rufen Sie das PDF erneut ab: Dokument und XML werden aus dem aktuellen Eintrag neu erstellt. Ansätze, die das XML zum Zeitpunkt der Übermittlung erstellen, stellen weiterhin die Werte bereit, die der Eintrag damals hatte – für immer.
-
Eine Nummer, ein Ort. Die Rechnungsvorlage von Gravity PDF enthält bereits eine Rechnungsnummer, ein Fälligkeitsdatum und einen Mehrwertsteuersatz. Das Add-on liest sie und entfernt die eigenen Felder vom Bildschirm, sodass die gedruckte Rechnung und das eingebettete XML nicht übereinstimmen können. Der
gfpdf_invoice_numberDer Filter wird berücksichtigt, sodass ein Zähler-Plugin, das die gedruckte Rechnung neu nummeriert, das XML damit neu nummeriert. - Das Zahlungsmittel folgt dem Zahlungsgateway. Bezahlt über PayPal oder Stripe? Im XML steht „Online-Zahlungsdienst“. Per Karte? „Bankkarte“. Gar kein Gateway? Ihr gewählter Fallback. Ein Filter erweitert die Karte auf jedes Add-on.
- Arithmetik, die Sie verteidigen können. Zeilensummen, Zulagen, Gebühren, die Aufschlüsselung der Mehrwertsteuer und die Gesamtsumme werden anhand der in EN 16931 definierten Identitäten überprüft – einschließlich des unangenehmen Falles, dass eine unversteuerte Versandgebühr eine zweite eigene Mehrwertsteuerkategorie mit Nullsatz benötigt.
- Geben Sie einmal den Verkäufer ein. Firmenname, Adresse, Umsatzsteuer-Identifikationsnummer, Steuernummer und Kontaktdaten befinden sich auf einer gemeinsamen Einstellungsseite, nicht in jedem Feed.
- Deutsche, englische und französische Benutzeroberfläche. Die Feldnamen werden wörtlich aus der Factur-X-Spezifikation übernommen und nicht von Hand übersetzt, sodass ein Buchhalter sie erkennt.
- Kein externer Service. Kein API-Schlüssel, kein Konto, keine ausgehende Verbindung, keine Gebühr pro Rechnung. Alles geschieht auf Ihrem eigenen Server.
Nur das, was die Norm verlangt, ist verpflichtend
Die Einstellungsbildschirme folgen der tatsächlichen Kardinalität von EN 16931, anstatt zu raten. Ein Verkäufername und ein Ländercode sind erforderlich; Eine Straße ist es nicht. Ein Feld, dessen Wert das Add-on bereits kennt – die Rechnungsnummer, das Rechnungsdatum, die Währung – wird niemals von Ihnen verlangt, denn die Forderung nach einem bereits bekannten Wert ist nur Theater.
Und wenn wirklich etwas fehlt, verrät es der Feed-Bildschirm in einem Satz vor Sie konfigurieren ein einzelnes Feld: einen verlorenen Bibliotheksordner, einen unvollständigen Verkäuferblock, ein Formular ohne Gravity-PDF. Zum Zeitpunkt des Renderns werden dieselben Sätze im Gravity Forms-Protokoll gespeichert.
Anforderungen
- WordPress — 6.0 oder neuer
- PHP — 8.2 oder neuer
- Schwerkraftformen — 2.5 oder neuer, mit einem Produkt- oder Zahlungsfeld auf dem Formular
- Schwerkraft-PDF — 6.0 oder neuer. Die Rechnungsvorlage wird empfohlen, ist jedoch nicht erforderlich
- Sonst nichts. Die XML-Bibliothek wird mit dem Plugin geliefert
Was diese Version bewusst nicht tut
Ehrlichkeit ist billiger als eine Rückerstattung, deshalb hier die Liste:
- Eine Mehrwertsteuerkategorie und ein Satz pro Rechnungzuzüglich einer Nullsteuerlinie für den unversteuerten Versand. Die Rechnungsvorlage ermöglicht durch CSS-Klassen auch einen unterschiedlichen Tarif pro Feld; Diese werden erkannt und in das Protokoll geschrieben und nicht zu einem Fehler gemittelt.
- Keine Gutschriften. UBL modelliert eine Gutschrift als eigenes Wurzelelement und nicht als Typcode auf einer Rechnung; Der Bauherr stellt lediglich eine Rechnung aus.
- Keine Gebühren/Zulagen auf Dokumentebene (BG-20/BG-21) über den oben bereits abgedeckten Einzelversandfall hinaus. Der Anhang mit unterstützenden Dokumenten (BG-24) wird für die eigenständigen XRechnung/PEPPOL-Dateien angeboten, nicht für Factur-X, das die PDF-Datei bereits als eigenen Container enthält.
- PDF/A-3 Level B ist die Standardeinstellung und die einzige Ebene, die das Add-on ehrlich behaupten kann. Level A benötigt zusätzlich ein getaggtes, strukturiertes Dokument, das von Ihrer PDF-Vorlage abhängt.
- Validiert gegen XSD, nicht gegen Schematron. Die XSD fängt strukturelle Fehler ab, nicht jede Geschäftsregel. Bevor Sie live gehen, lassen Sie eine generierte Rechnung durch einen Schematron-Validator laufen – und durch den Viewer, den Ihr Empfänger verwendet.
Für Entwickler
Die Arithmetik- und Validierungsschicht (SP_EInvoice_Invoice) ist Framework-frei und löst nie aus: Jedes Problem kommt als String zurück, da es ausgeführt wird, während eine PDF-Datei erstellt wird und oft auch, während eine Benachrichtigung gesendet wird. Ein zusammengestelltes Rechnungsarray speist alle drei Ausgabeformate; genau eine Datei (SP_EInvoice_Builder) berührt die zugrunde liegende Bibliothek.
Es stehen drei Filter zur Verfügung: sp_zugferd_payment_means_map um das Gateway-Mapping zu erweitern,
sp_zugferd_full_code_lists um eine vollständige Codeliste anstelle der kuratierten Teilmenge und die eigene von Gravity PDF anzubieten gfpdf_invoice_numberwas das Add-on für BT-1 respektiert.
Änderungsprotokoll
2.1.2 (aktuell)
- Behoben: Die elektronische Adresse des Verkäufers (BT-34) ist jetzt in der generierten XRechnung und PEPPOL BIS Billing XML enthalten – überprüft anhand eines echten KoSIT-Validator-Laufs. Füllen Sie die neuen Felder „Elektronische Adresse“ unter „(e)Rechnungseinstellungen“ aus, wenn Sie XRechnung- oder PEPPOL-Rechnungen versenden.
2.1.1
- Umbenannt von „Gravity Forms ZUGFeRD / Factur-X Extension“, um den folgenden Umfang widerzuspiegeln – dies ist kein reines Factur-X-Add-on mehr.
- XRechnung und PEPPOL BIS Billing 3.0jeweils eine eigenständige UBL-Datei, auswählbar pro Feed neben oder anstelle von Factur-X. PHP 8.2 ist jetzt erforderlich.
- Bankdaten (BT-84/85/86) wurden den gemeinsamen Verkäufereinstellungen hinzugefügt und mit dem EPC-QR-Add-on geteilt.
- Die neun Referenzcodelisten können nun aus einem gemeinsam genutzten, zentral verwalteten Paket stammen, mit automatischem Fallback auf die gebündelten Kopien.
- Die Seite mit den gemeinsamen Einstellungen erhielt eine Reihe neuer optionaler Felder (Registerdetails, GLN/DUNS, eine verschlüsselte SEPA-Gläubiger-ID und mehr), die von anderen Add-ons der Familie verwendet werden.
1.0.0
- Erstveröffentlichung.
- EN 16931 CII XML eingebettet in ein PDF/A-3-Dokument; vier Profile.
- Die Rechnung wird zum Zeitpunkt des Renderns zusammengestellt, sodass ein korrigierter Eintrag zu einer korrigierten Rechnung führt.
- Rechnungsnummer, Fälligkeitsdatum, Mehrwertsteuersatz und Versandsteuer werden der Gravity-PDF-Rechnungsvorlage entnommen, wenn diese angegeben ist.
- Vom Zahlungsgateway abgeleitete Zahlungsmittel mit einer filterbaren Karte.
- Eine unversteuerte Versandkostenpauschale führt zu einem zweiten Mehrwertsteueraufschlüsselungseintrag mit Nullsatz.
- Deutsche und französische Schnittstelle enthalten.
Bewertung: 0
Verkäufe bisher: 0
Be the first to leave a review.