E-Rechnung im Shopware-Kern: was 6.7 erzeugt
Shopware schreibt XRechnung 3 und kennt in 6.7 zehn Dokumenttypen statt sechs. Zwei Stellen im Erzeuger sind gemessen und im Alltag relevant.
Dieser Text ist eine technische Beschreibung, keine Rechtsauskunft. Gemessen wurde, was der Shopware-Kern erzeugt. Ob eine konkrete Rechnung damit den Anforderungen genügt, die für Ihr Unternehmen gelten, ist eine juristische Frage — sie wird hier weder beantwortet noch zugesichert. Die unten benannten Lücken sind technische Befunde; welche rechtliche Bedeutung sie haben, bewerten wir nicht.
E-Rechnung ist im deutschsprachigen B2B ein Dauerthema, und die erste Frage lautet fast immer: Kann Shopware das von sich aus? Die Antwort ist ja, mit zwei Stellen, an denen man hinsehen sollte.
Was 6.7 gegenüber 6.6 dazubekommen hat
Die Dokumenttypen liegen in der Datenbank. Ausgelesen aus beiden Runtimes:
| Dokumenttyp | 6.6.10.6 | 6.7.13.1 |
|---|---|---|
invoice | ✓ | ✓ |
delivery_note | ✓ | ✓ |
credit_note | ✓ | ✓ |
storno | ✓ | ✓ |
zugferd_invoice | ✓ | ✓ |
zugferd_embedded_invoice | ✓ | ✓ |
zugferd_cancellation_invoice | — | ✓ |
zugferd_embedded_cancellation_invoice | — | ✓ |
zugferd_credit_note | — | ✓ |
zugferd_embedded_credit_note | — | ✓ |
| Summe | 6 | 10 |
Der Sprung besteht also nicht darin, dass E-Rechnung neu wäre — die Rechnung gab es schon in 6.6. Neu sind Stornorechnung und Gutschrift, jeweils in zwei Ausführungen: als eigenständige XML-Datei und als in ein PDF eingebettete Fassung.
Das schließt eine Lücke, die in der Praxis schnell auffällt: Wer elektronisch fakturiert, muss auch elektronisch stornieren und gutschreiben können.
Das Format
Der Erzeuger wählt das Profil fest:
ZugferdDocumentBuilder::createNew(ZugferdProfiles::PROFILE_XRECHNUNG_3)
XRechnung 3 — nicht konfigurierbar, nicht je Verkaufskanal wählbar. Wer ein anderes ZUGFeRD-Profil braucht, bekommt es vom Kern nicht.
Zwei Stellen, an denen der Kern eine Annahme trifft
Die Buyer Reference trägt die Bestellnummer
Im Erzeuger steht:
->withBuyerReference($order->getOrderNumber() ?? '')
Die Buyer Reference ist das Feld, in dem bei Rechnungen an öffentliche Auftraggeber üblicherweise die Leitweg-ID des Empfängers steht — eine Kennung, die der Empfänger vorgibt und die der Rechnungssteller nicht erfinden kann.
Shopware trägt dort die eigene Bestellnummer ein. Das ist eine sinnvolle Vorbelegung für den Normalfall und genau das Falsche, wenn der Empfänger eine eigene Kennung erwartet. Wer sie braucht, muss das Feld selbst setzen — der Kern löst ein Ereignis aus, an dem sich das erledigen lässt.
Zahlungsmittel nur für drei von vier Zahlarten
Der Kern liefert vier Zahlarten aus. Der Erzeuger kennt drei davon namentlich:
| Zahlart | im Kern | im Erzeuger zugeordnet |
|---|---|---|
payment_cashpayment (Barzahlung) | ✓ | ✓ |
payment_invoicepayment (Rechnung) | ✓ | ✓ |
payment_prepayment (Vorkasse) | ✓ | ✓ |
payment_debitpayment (Lastschrift) | ✓ | — |
Für Rechnung und Vorkasse schreibt er zusätzlich IBAN und BIC aus der Dokumentkonfiguration. Für Lastschrift schreibt er nichts — und für jede Zahlart eines Drittanbieters, also PayPal, Stripe, Mollie, Klarna und alle anderen, ebenso wenig.
In einem Shop mit externen Zahlarten — also den meisten — enthält die erzeugte Datei damit keinen Zahlungsmitteleintrag. Ob das im konkreten Fall stört, entscheidet der Empfänger, nicht wir.
Was der Kern sonst aus der Bestellung nimmt
| Angabe | Herkunft |
|---|---|
| Käuferdaten | Bestellkunde und Rechnungsadresse |
| Verkäuferdaten | Dokumentkonfiguration |
| Währung | Währung der Bestellung |
| Lieferdatum | spätestes Versanddatum der Lieferung |
| Steuerlage | Steuerstatus der Bestellung; brutto und netto werden unterschieden |
| Bezahltbetrag | nur wenn die Transaktion im Status paid steht |
| Rechnungsbezug | bei Storno und Gutschrift: Nummer und Datum der Ursprungsrechnung |
Die Rechnungsnummer selbst stammt aus einem Nummernkreis, und der lässt sich je Verkaufskanal einstellen.
Bei negativem Gesamtbetrag erlaubt der Erzeuger ausdrücklich negative Positionen — das ist der Gutschriftfall.
Eine Versionsgrenze, die man kennen sollte
Beim Zugriff auf Lieferung und Transaktion verhält sich der Erzeuger je nach
Funktionsschalter unterschiedlich: Mit aktivem v6.8.0.0-Schalter nutzt er die
als primär markierte Lieferung und Transaktion, ohne ihn die erste Lieferung
und die letzte Transaktion.
Bei einer Bestellung mit mehreren Zahlungsversuchen kann das einen Unterschied machen. Die Spalten für diese primären Verweise legt bereits eine V6_7-Migration an; gefüllt werden sie erst unter dem 6.8-Schalter.
Was hier nicht geprüft wurde
Ehrlich benannt, weil es den Wert der Aussagen begrenzt:
- Kein erzeugtes Dokument. Die Demoinstallation enthielt keine Bestellungen; gelesen wurde der Erzeuger, nicht sein Ergebnis. Die Aussagen zu Profil, Buyer Reference und Zahlungsmitteln folgen aus dem Code.
- Keine Prüfung gegen einen Validator. Ob eine erzeugte Datei eine XRechnung-Prüfung besteht, ist eine eigene Messung.
- Keine rechtliche Bewertung. Siehe der Hinweis ganz oben.
- Keine Aussage zu 6.8. Der Funktionsschalter ist im Code sichtbar; wie sich 6.8 tatsächlich verhält, ist nicht gemessen.
Wenn Sie das aufsetzen
Der schnellste Weg zu einer belastbaren Aussage für Ihren Shop: eine Testbestellung mit der Zahlart erzeugen, die Sie tatsächlich einsetzen, das ZUGFeRD-Dokument erstellen lassen und in die XML-Datei sehen. Was dort steht, ist der tatsächliche Stand — unabhängig davon, was die Konfiguration vermuten lässt.
Wie wir solche Themen im Shop umsetzen, gehört zu Shopware-Agentur; der laufende Betrieb danach zu Shopware-Support.
Häufige Fragen
- Welches Format schreibt Shopware?
- Das Profil XRechnung 3. Es ist im Erzeuger fest gewählt, nicht konfigurierbar.
- Welche Dokumenttypen gibt es in 6.7?
- Zehn: Rechnung, Lieferschein, Gutschrift und Storno als klassische Dokumente, dazu sechs ZUGFeRD-Varianten — Rechnung, Stornorechnung und Gutschrift jeweils als eigenständiges XML und als in ein PDF eingebettete Fassung.
- Was steht in der Buyer Reference?
- Die Bestellnummer. Der Kern setzt sie dort ein; eine Leitweg-ID oder eine andere Empfängerkennung kommt nicht von selbst hinein.
- Warum fehlt bei manchen Rechnungen das Zahlungsmittel?
- Weil der Erzeuger nur drei Zahlarten namentlich kennt: Barzahlung, Rechnung und Vorkasse. Für Lastschrift und für jede Zahlart eines Drittanbieters schreibt er keinen Zahlungsmitteleintrag.