Add-on für SAP ECC 7.4 und S/4
Dazwischen liegt genau eine Datei: das Mapping. Es sagt SAP, was zu lesen ist, und der API, was daraus zu rechnen ist. Dieselbe Datei, zwei Leser — damit wird Fachlichkeit nicht zweimal gepflegt.
8
fertige Mappings — SD-Faktura, MRRL, MRNB, MRIS, MIRO, MRKO, FB70, FB60
4
Quellarten im Mapping: Tabelle, Struktur, Text, Archivdokument
0
User-Exits für kundeneigene Z-Tabellen und Z-Felder — die Quelle steht im Mapping, nicht im Code
7.4
ECC-Mindeststand — kein S/4-Zwang, kein Releasewechsel
Die Leitidee
In SAP entsteht ein gebuchter Beleg. Ein festes ABAP-Konstrukt liest dazu genau die Daten, die das Mapping benennt, und schickt sie als XML an die API. Die API baut daraus die E-Rechnung, prüft sie, erzeugt das PDF und versendet sie. SAP bekommt den Status zurück.
Grundlage ist ein Satz in BKPF. Vorher gibt es nichts zu versenden, danach steht der Beleg fest. Alle Mappings haben dieselbe Kopfquelle — ein Einstiegspunkt statt ein Sonderweg je Modul.
Ein Hintergrundjob liest BKPF über den Erfassungszeitpunkt. Das hängt an der Tabelle, nicht am Buchungsweg: Dialog, Batch-Input, BAPI, IDoc und Fremdentwicklung verhalten sich gleich.
Es gibt keine Liste „wer bekommt eine E-Rechnung“, sondern nur eine Liste der Ausnahmen — mit Grund und Gültigkeit. Kein gebuchter Beleg fällt still durch.
Der Weg eines Belegs
Die Trennlinie liegt bewusst nicht bei „ABAP dumm, API klug“. Sie liegt dort, wo sich Dinge ändern: Formatversionen und Regelwerke in der Cloud, Tabellen und Zugriffe in SAP.
Arbeitsteilung
Ein Wechsel von XRechnung 3.x auf 4.x fasst SAP damit nicht an.
Das Mapping
Die Mapping-Datei enthält zwei Arten von Aussagen, und beide werden gebraucht. Wo stehen die Daten? — das liest ABAP. Was wird daraus? — das rechnet die API.
Eine neue Quelle, etwa eine weitere Z-Tabelle, ist damit eine Mapping-Änderung und kein Transport. Das ABAP-Konstrukt wertet das Mapping zur Laufzeit aus; es erzeugt keinen Code. Kundeneigene Z-Felder auf Standardtabellen kommen als Ergänzungsdatei dazu, ohne die mitgelieferte Bibliothek anzufassen.
source RBKP → RSEG on BELNR, GJAHR repeat RSEG je Position text VBBK / BELEG Kopftext document BKPF · ZENLIEF Beilage im PDF BT-3 wenn XRECH = X dann 381 sonst 380 BT-95 Steuerkennzeichen → Kategorie
Ein Mapping, vollständig
Das Folgende ist keine Skizze, sondern ein ausgeliefertes Mapping: die automatische Wareneingangsabrechnung. Dieselben Zugriffspfade, die sonst als Liste von Schritten dastehen, hier als Zusammenhang. Die Daten dafür sind ohnehin vorhanden — jeder Pfad kennt Ausgangspunkt, Zieltabelle und Verknüpfungsfelder.
FI-Beleg (MRRL) → EN 16931. Ausgangspunkt links ist der gebuchte Buchhaltungsbeleg BKPF. Jede Kante trägt die Verknüpfungsfelder, jeder Knoten die BT-Nummern, die er füllt: über RBKP und LFA1 nach ADRC für die Anschrift des Rechnungsstellers, über RSEG weiter nach EKPO, MARC und MKPF für Bestellbezug, Werk und Wareneingangszeitraum, über BSET zu den Steuerzeilen. Rund zwei Dutzend Tabellen und knapp dreißig Pfade — und keine Zeile Code. Wer ein Feld ergänzen will, ergänzt einen Pfad.
Was das kostet
Das ist der Punkt, an dem sich die Bauweise in Geld ausdrückt. In einer klassischen Anbindung ist jede zusätzliche Datenquelle eine Erweiterung im Code — und Erweiterungen kosten nicht einmal, sondern bei jedem Releasewechsel wieder.
Klassisch
Preis: Beratertage. Je Feld.
Mit dem Add-on
Preis: Minuten. Im eigenen Haus.
Der Grund dafür steckt in einer einzigen Entscheidung: Das ABAP-Konstrukt wertet das Mapping zur Laufzeit aus — es erzeugt keinen Code. Ein Codegenerator würde für jede Mapping-Änderung wieder Transport, Syntaxprüfung und Entwicklungsberechtigung verlangen. Der Interpreter wird einmal installiert, danach ist jede weitere Quelle Customizing.
Vier Quellarten
Anhänge
Im XML · BG-24
Der Empfänger bekommt es zwangsläufig mit. Dafür gelten Formatgrenzen: XRechnung lässt nur bestimmte Dateitypen zu, ein TIFF aus dem Scanarchiv ist nicht zulässig, und die Größe geht voll in die Nachricht ein.
Im PDF
Die Seiten werden an das Sichtbild angehängt — kein Formatzwang, keine Größengrenze der Nachricht. Empfehlung als Voreinstellung; der Anhang im XML nur, wenn der Empfänger ihn verlangt.
Größe und Anzahl werden geprüft, bevor gesendet wird. Sonst entstehen Ablehnungen, deren Ursache erst am Ende der Kette sichtbar wird.
Kennungsprüfung
In den Stammdaten. Eine falsche USt-IdNr. kommt gar nicht erst ins System — formal sofort beim Sichern, inhaltlich auf Knopfdruck.
Formal · offline · in ABAP
IBAN, BIC-Form, GLN und GTIN, DUNS, Leitweg-ID, SEPA-Gläubiger-ID, USt-IdNr.-Muster je Land. Kein Netz, kein Datenschutzthema, in Millisekunden — und auch dann, wenn die API nicht erreichbar ist.
Inhaltlich · online · über die API
USt-IdNr. über VIES, LEI über GLEIF, SIRET über Sirene, Peppol-Teilnehmer über SML/SMP. Eine Online-Prüfung, die in ein Timeout läuft, führt nie zu einem Fehler — nur zu „nicht prüfbar“.
Abfragenummer und Zeitstempel werden archiviert, nicht nur das Ergebnis — bei Reverse Charge ist die qualifizierte Bestätigungsabfrage Nachweispflicht, nicht Kür.
Eigene Prüfregeln
Das offizielle Regelwerk prüft Struktur und Rechenwerk. Ob die Rechnung Ihren eigenen Anforderungen genügt, prüft es nicht — und ein Teil der Pflichtangaben aus § 14 UStG fällt schlicht durch, weil das Feld im Standard optional ist.
Leistungszeitpunkt, vollständige Anschrift, Steuernummer oder USt-IdNr., handelsübliche Bezeichnung, der Wortlaut bei Steuerbefreiung — im Standard alles optional oder gar nicht geprüft.
Firmierung, Anschrift, gültige Bankverbindung, Nummernkreise. Im Rechnungseingang: Wird bei Lastschrift wirklich Ihr Konto belastet?
Sichtbarkeit
Neu, ausgeschlossen, gesammelt, gesendet, abgelehnt, zugestellt, Fehler, manuell erledigt. Fortgeschrieben, nicht überschrieben.
Was die Validierung meldet, kommt als erklärter Satz zurück nach SAP — mit Rechtsgrundlage, nicht als Regel-ID.
Die Rückläufer sind der Beleg. Sie liegen unveränderbar am Geschäftsvorfall — das ist GoBD, nicht Komfort.
Betriebsform
Dieselbe Schnittstelle läuft an zwei Orten. Der Unterschied ist größer, als er zunächst aussieht — und er liegt nicht im Betriebsort, sondern darin, was die Firewall passiert.
| Cloud | Beim Kunden | |
|---|---|---|
| Extract mit Rohdaten — Bankverbindungen, Anschriften, Belegtexte, Archivdokumente | geht nach außen | bleibt intern |
| Erzeugung von XML und PDF | außen | intern |
| Validierung | außen | intern |
| Was schließlich nach außen geht | Rohdaten und Rechnung | nur die fertige Rechnung |
Im Betrieb beim Kunden verlässt die Rechnung das Haus erst, wenn sie vollständig und geprüft ist — und sie geht dorthin, wohin sie ohnehin geht: zum Empfänger. Damit entfällt die gesamte Diskussion über Auftragsverarbeitung, Datenübermittlung und Aufbewahrung bei Dritten. Es gibt keinen Zwischenschritt, an dem ein Dritter mehr sieht als der Rechnungsempfänger.
Drei Wege
Der Regelfall. Das Extract geht an die API, die fertige Rechnung kommt zurück. Einrichtung: eine RFC-Destination, fertig.
Dieselben Bausteine, dieselbe Schnittstelle, nur im Haus — als WordPress-Installation oder als Container. Für alle, die Rechnungsdaten nicht herausgeben dürfen.
XML und PDF entstehen intern, nur die fertige Rechnung geht an den Zugangspunkt. Für alle, die Peppol nicht selbst betreiben, aber die Rohdaten behalten wollen — im gehobenen Mittelstand vermutlich der häufigste Fall.
Auch im eigenen Haus gibt es drei Verbindungen nach außen, und für jede gibt es eine Antwort:
Das hängt an drei Fragen: Dürfen Rechnungsdaten das Haus verlassen, betreiben Sie Peppol selbst, und wie ist Ihr Archiv eingerichtet. Mehr braucht es für ein erstes Gespräch nicht.