Bei diesem Weg erzeugt Amagno je Rechnung ein IDoc vom Basistyp
ACC_DOCUMENT03 als XML-Datei. SAP verbucht es über den Baustein
BAPI_ACC_DOCUMENT_POST — ohne Batch-Input, ohne LSMW-Projekt und
ohne manuelles Anstoßen. Dafür ist die Einrichtung einmalig aufwendiger: Es
braucht ein logisches System, einen Port und eine Partnervereinbarung.
Wann dieser Weg passt
Die IDoc-Anbindung ist der Weg für den dauerhaften, automatisierten Betrieb.
Sie liefert echtes Monitoring (jedes IDoc hat einen Status und ist
nachvollziehbar), erlaubt gezieltes Wiederaufsetzen im Fehlerfall und kommt ohne
Anwenderinteraktion aus. Wer nur gelegentlich Belege übernimmt oder RFBIBL00
nicht freigegeben bekommt, ist mit dem LSMW-Weg besser bedient.
Voraussetzungen
- Berechtigung für die ALE-/IDoc-Transaktionen (
SALE,WE20,WE21,WE19). - Ein Verzeichnis auf dem SAP-Anwendungsserver, in das die XML-Dateien gelegt werden und das SAP lesen darf.
- Kreditorenstammsätze, Belegart und Steuerkennzeichen sind im Zielbuchungskreis gepflegt.
Schritt 1: Logisches System anlegen
Über SALE (bzw. BD54) ein logisches System für das
sendende Dokumentenmanagement anlegen, zum Beispiel DMSCLNT100.
Das empfangende System — der R/3-Mandant — hat in der Regel bereits eines.
Beide Namen brauchen wir für die Konfiguration auf unserer Seite: Sie werden im
Steuersatz des IDocs als SNDPRN und RCVPRN eingetragen.
Schritt 2: XML-Port einrichten
In WE21 einen Port vom Typ XML-Datei anlegen.
Einzutragen sind das Verzeichnis, in dem die Dateien erwartet werden, sowie die
Zugriffsart. Den Portnamen brauchen wir ebenfalls — er wird als
RCVPOR mitgegeben.
Wichtig ist an dieser Stelle die Betriebsfrage: Wer legt die Datei ab und wer räumt sie weg? Üblich ist, dass wir per FTP schreiben und SAP die verarbeitete Datei in ein Archivverzeichnis verschiebt.
Schritt 3: Partnervereinbarung
In WE20 unter Partnerart LS (logisches System)
den Partner aus Schritt 1 anlegen und einen Eingangsparameter
hinterlegen:
| Nachrichtentyp | ACC_DOCUMENT |
| Vorgangscode | BAPI |
| Verarbeitung | je nach Betriebsvorgabe sofort oder per Hintergrundjob |
Für den Produktivbetrieb empfiehlt sich die Verarbeitung per Hintergrundjob: Bei einem Massenlauf bleibt das System bedienbar, und fehlerhafte IDocs lassen sich gebündelt nachbearbeiten.
Schritt 4: Basistyp prüfen
Über WE60 die Dokumentation zum Basistyp
ACC_DOCUMENT03 aufrufen und mit dem Feldumfang abgleichen, den wir
liefern. Der Feldumfang der Segmente ist releaseabhängig — bitte
prüfen Sie, ob alle unten genannten Felder in Ihrem Release vorhanden sind, und
melden Sie Abweichungen. Auf unserer Seite ist der Feldkatalog reine
Konfiguration; Ergänzungen erfordern keine Programmänderung.
Was wir liefern
Je Rechnung eine XML-Datei mit einem <IDOC>-Knoten. Optional
lassen sich alle Belege eines Laufs in einer Datei bündeln.
EDI_DC40 | Steuersatz mit Absender und Empfänger | einmal je IDoc |
E1BPACHE09 | Belegkopf (Buchungskreis, Daten, Belegart, Referenz) | einmal je Beleg |
E1BPACAP09 | Kreditorzeile | einmal je Beleg |
E1BPACGL09 | Sachkontozeile | je Kontierungszeile |
E1BPACTX09 | Steuerzeile | je Kontierungszeile mit Steuerbetrag |
E1BPACCR09 | Betrag | zu jeder Position eine |
Zwei Eigenschaften sind für die Prüfung wichtig:
- Positionsnummern:
ITEMNO_ACCwird fortlaufend vergeben und verbindet jede Position mit ihrem Betragssegment. - Vorzeichen: Die Kreditorzeile trägt einen negativen Betrag (Haben), Sachkonto- und Steuerzeilen positive (Soll). Bei einer Gutschrift dreht sich das für den gesamten Beleg um.
Schritt 5: Testeinspielung
Vor dem ersten Produktivlauf eine von uns gelieferte Beispieldatei über
WE19 einspielen. Das ist die einzige belastbare Prüfung, ob
Segmentfolge, Positionsverkettung und Vorzeichen von
BAPI_ACC_DOCUMENT_POST akzeptiert werden. Wir stellen die Datei auf
Anfrage bereit.
Schritt 6: Monitoring und Fehlerbehandlung
WE02bzw.WE05: IDoc-Übersicht mit Status und Fehlermeldung.BD87: fehlerhafte IDocs erneut verarbeiten, nachdem die Ursache behoben ist — die Datei muss dafür nicht neu erzeugt werden.- Status 51 bedeutet „Anwendungsbeleg nicht gebucht": Die Meldung nennt den fachlichen Grund, etwa ein unbekanntes Sachkonto.
- Status 53 ist der Erfolgsfall; die Belegnummer steht im Statussatz.
Fachliche Voraussetzungen
- Buchungskreis und Belegart (in der Regel
KR, für GutschriftenKG) sind abgestimmt. - Die Steuerkennzeichen, die wir liefern, existieren im Zielsystem.
- Der technische Benutzer, unter dem gebucht wird, ist angelegt und
berechtigt — er wird im Belegkopf als
USERNAMEmitgegeben. - Kreditorennummern liegen in der Form vor, die SAP erwartet (gegebenenfalls mit führenden Nullen).
Häufige Fehler
- IDoc bleibt in Status 64: Es wurde angenommen, aber noch nicht verarbeitet — meist ist die Verarbeitung auf Hintergrundjob gestellt und der Job läuft nicht.
- Partner nicht gefunden: Der Absendername im Steuersatz und die Partnervereinbarung stimmen nicht überein.
- Beleg nicht ausgeglichen: Summe der Positionen passt nicht zum Bruttobetrag — häufig, weil die Steuer sowohl explizit geliefert als auch von SAP selbst ermittelt wird.