E-Invoicing im Länderrollout

Eine elektronische Rechnung ist im SAP-Standard kein Formular, sondern ein eigener Beleg. Aus dem Quellbeleg — einer Debitorenrechnung aus FI, einer Faktura aus SD — entsteht ein eDocument: ein Satz mit Rückverweis auf den Quellbeleg, mit Art, Prozess und Status. Ein Länderrollout heißt deshalb nicht, ein Formular zu übersetzen, sondern denselben Rahmen je Land anders auszuprägen.

Der Einschalter steht vor allem anderen

Ob überhaupt ein eDocument entsteht, entscheidet eine Aktivierung je Buchungskreis und Quellenart. Welche Belege als Quelle taugen, steht in einem eigenen Katalog: FI-Rechnung, SD-Faktura, Bestellung, Auslieferung, Warenbewegung und weitere, jede mit eigener Datenstruktur und eigener auslesender Klasse. Ohne diesen Aktivierungssatz passiert nichts.

Land, Prozess und Art sind drei Ebenen

Die technische Ländereinstellung bestimmt, welche Landesklasse ausgeführt wird. Darunter liegt der Prozess: ein Land trägt meist mehrere davon — Ausgang, Eingang, Versand per E-Mail, externe Belege, Bestellungen. Jeder Landesprozess verweist auf einen gemeinsamen Referenzprozess, und dort liegen Statuswerte und Schnittstellenfindung. Wer nur unter dem Landesschlüssel sucht, findet leere Tabellen und hält die Einrichtung für nicht vorhanden. Die dritte Ebene ist die eDocument-Art: Rechnung, Gutschrift, Eingangsbeleg, Bestellung.

Die Typfindung ist die stillste Falle

Zwischen aktivierter Quellenart und eDocument-Art steht eine Findung, und die ist je Quellenart eine andere Tabelle: Verkaufsbelegart, Einkaufsbelegart, Abrechnungsbelegart, Bewegungsart. Fehlt dort der Eintrag zur konkreten Belegart, entsteht kein eDocument.

Dieser Fehler meldet sich nicht. Im Rechnungswesen ist der Beleg gebucht und grün, im Cockpit fehlt er einfach. Aktivierung ohne Typfindung schließe ich in einem Rollout als Erstes aus — je Belegart, nicht je Buchungskreis.

Der Weg nach außen wird gefunden, nicht verdrahtet

Der Prozess besteht aus einzelnen Prozessschritten, jeder an eine Klasse und eine Methode gebunden: anlegen, Senden anfordern, an die Schnittstelle senden, Antworten der Meldungs- und Geschäftsebene verarbeiten, XML herunterladen, stornieren, neu starten. Welche Schnittstelle ein Schritt aufruft, steht nicht fest, sondern wird je Prozessschritt und eDocument-Art gefunden und dann auf einen AIF-Namensraum oder ein Kommunikationsszenario aufgelöst. Der technische Weg selbst steht im Schnittstellentyp: Standardimplementierung mit AIF, AIF für die XML-Erzeugung, AIF-Proxy für Web-Services, Cloud-Edition oder kundenspezifisch.

Hier liegt die zweite Falle. Die Findung wird mit tausenden Einträgen ausgeliefert und sieht vollständig aus, aber der referenzierte AIF-Namensraum muss im System nicht installiert sein. Zeigt die Zuordnung ins Leere, ist der Sendeschritt nicht ausführbar: das eDocument bleibt auf „Angelegt“ stehen, es entsteht keine Datei und kein Historiensatz. Geprüft wird gegen die Interface-Definition, nicht gegen die Findungstabelle — die sagt nur, was gerufen würde.

Status ist keine Zustellung

Gearbeitet wird im eDocument-Cockpit oder in der Fiori-App für elektronische Belege. Die Ampel dort ist ein verdichteter Metastatus mit drei Zuständen: abgeschlossen, in Bearbeitung, Aktion erforderlich. Darunter liegt der fachliche Prozessstatus. Er läuft nicht auf einen Endpunkt zu, sondern über zwei Rückmeldeebenen.

  • Meldungsebene: an den Empfänger-Access-Point gesendet, dort akzeptiert, mit Validierungsfehler zurück oder abgelehnt
  • Geschäftsebene: bestätigt, in Bearbeitung, akzeptiert, bedingt akzeptiert, Abfrage offen, abgelehnt, bezahlt, teilweise bezahlt
  • Rückwärtsfälle: eDocument storniert und Quellbeleg storniert — das Storno des Quellbelegs schlägt durch

Jede Änderung wird am Beleg fortgeschrieben und als eigener Satz historisiert. Eine übertragene Rechnung ist damit noch keine angenommene. Wer nur bis zum Versand plant, hat den kleineren Teil gebaut: eine Ablehnung auf der Geschäftsebene, die niemand liest, fällt erst im Mahnlauf auf.

Die Gutschriftsstrecke bleibt die offene Frage

Im Gutschriftsverfahren rechnet der Kunde ab. Der Zulieferer nimmt die Abrechnung als Eingangsnachricht entgegen und gleicht sie gegen Lieferung und Faktura ab; eine eigene Ausgangsrechnung stellt er nicht. Was eine gesetzliche Pflicht zur elektronischen Rechnungsstellung für diese Strecke bedeutet, lässt sich nicht pauschal beantworten. Denkbar ist, dass der Abrechnende das elektronische Dokument im Namen des Leistenden erzeugt — das Verfahren setzt umsatzsteuerlich ohnehin eine Vereinbarung und ein Widerspruchsrecht voraus, und beides müsste auf den elektronischen Weg übertragen werden. Denkbar ist auch, dass der Zulieferer ein eigenes Ausgangsdokument erzeugen muss — dann fehlt ihm der Quellbeleg, denn in seinem System steht keine Ausgangsrechnung, sondern eine eingehende Abrechnung. Ich gebe darauf keine pauschale Zusage, sondern arbeite den Fall durch, bevor ein Termin darauf steht.


Wo mein Anteil endet

Abgedeckt wird die Kette vom Rechnungsbeleg über die Erzeugung des elektronischen Dokuments, die Validierung gegen die formalen Vorgaben, die Statusverwaltung und die Fehlerbehandlung — bis zur Übergabe an die letzte Meile. Die letzte Meile ist die Zustellung über die zugelassene Plattform beziehungsweise den zertifizierten Provider; dort endet mein Anteil bewusst, weil dieser Schritt zulassungsgebunden ist.

Woran ich zuerst nachsehe

  • „Es entsteht gar kein eDocument.“ — Aktivierung je Buchungskreis und Quellenart, danach die Typfindung zur konkreten Belegart
  • „Der Beleg steht auf Angelegt und bewegt sich nicht.“ — Schnittstellenfindung zum Sendeschritt, danach die Frage, ob die gefundene Schnittstelle existiert
  • „Zum Land ist nichts eingerichtet.“ — Statuswerte und Findung hängen am Referenzprozess
  • „Der Quellbeleg wurde storniert, das eDocument lebt weiter.“ — die beiden Storno-Prozessschritte
  • „Die Rechnung ist raus, das Geld kommt nicht.“ — Geschäftsebene statt Sendeebene, und wer sie liest

Geprüft wird am konkreten Beleg, gespiegelt an einer funktionierenden Strecke. Jede Änderung am Customizing geht in einen Transport, auch die kleine.