Zwei Fragen werden regelmäßig vermischt: ob überhaupt etwas ausgegeben wird, und wie das Ergebnis aussieht. Die erste beantwortet die Nachrichtenfindung, die zweite die Formulartechnik. Auf S/4HANA kommt eine dritte dazu: welche der beiden Ausgabesteuerungen für diese Belegart überhaupt zuständig ist.
Auf S/4HANA laufen zwei Ausgabesteuerungen nebeneinander
Die klassische Nachrichtenfindung mit der Nachrichtentabelle NAST ist nicht verschwunden. Daneben steht die neue Ausgabesteuerung, und welche von beiden greift, entscheidet eine Customizing-Tabelle je Anwendungsobjektart. Ihr Aktivierungskennzeichen hat genau drei Festwerte: „Applikation aktiv“, „Anwendung inaktiv“ und „Standard“.
In meinem S/4-System sieht das gemessen so aus:
| Anwendungsobjektart | Eintrag |
|---|---|
| BILLING_DOCUMENT | Applikation aktiv |
| SALES_DOCUMENT | Applikation aktiv |
| PURCHASE_ORDER | Anwendung inaktiv |
| OUTBOUND_DELIVERY | kein Eintrag |
Gleichzeitig ist NAST bebucht, und der mit Abstand größte Block liegt auf der Auslieferung: Nachrichtenart LD00 (Lieferschein), daneben LAVA für das Lieferavis; auf der Fakturaseite RD00. Es ist also keine Entweder-oder-Frage. Sie wird je Belegart beantwortet, und die Antwort steht in einer Tabelle, nicht in einem Releasestand.
Was am Beleg hängt
In der klassischen Findung hängt das Nachrichtenschema am Belegkopf: die Lieferart trägt es in TVLK, die Fakturaart in TVFK, jeweils zusammen mit der Anwendung. Gemessen trägt die Lieferart LF das Schema V10000 zur Anwendung V2, die Fakturaart F1 dasselbe Schema zur Anwendung V3 samt Nachrichtenart RD00. Bei der Fakturaart F2 sind diese Felder leer — wer dort eine fehlende Rechnungsausgabe sucht, sucht in der klassischen Findung vergeblich.
Was tatsächlich gefunden wurde, steht danach als Satz in NAST, mit Verarbeitungsstatus: 0 nicht verarbeitet, 1 erfolgreich verarbeitet, 2 fehlerhaft verarbeitet. Der Unterschied zwischen 0 und 2 ist der Unterschied zwischen „wartet noch“ und „ist gelaufen und gescheitert“. Beides sieht im Belegfluss gleich unfertig aus.
Das Medium entscheidet über die Formulartechnik
Eine Nachrichtenart ist nicht an eine Ausgabeform gebunden. Das Nachrichtenmedium kennt unter anderem Druckausgabe, Telefax, externes Senden, EDI, einfaches Mail, Sonderfunktion und Verteilung über ALE. Je Nachrichtenart und Medium steht ein eigener Eintrag in TNAPR — mit eigenem Ausgabeprogramm und eigenem Formular. Gemessen im Standard:
| Nachrichtenart | Medium | Programm | Formular |
|---|---|---|---|
| LD00 | Druckausgabe | RVADDN01 | SAPscript RVDELNOTE |
| LD00 | Telefax | RLE_DELNOTE | Smart Form LE_SHP_DELNOTE |
| RD00 | Druckausgabe | RVADIN01 | SAPscript RVINVOICE01 |
| RD00 | Telefax | SD_INVOICE_PRINT01 | PDF-Formular SD_INVOICE_FORM01 |
| RD00 | EDI | RSNASTED | Routine EDI_PROCESSING |
| LAVA | Verteilung (ALE) | RSNASTED | Routine ALE_PROCESSING |
Drei Generationen Formulartechnik in einer Tabelle: RVDELNOTE und RVINVOICE01 liegen in der SAPscript-Formularablage, SD_INVOICE_FORM01 ist ein PDF-basiertes Druckformular. Unterschieden werden Smart Form und PDF-Formular über ein eigenes Feld mit genau zwei Festwerten. Beim Umstellen einer Ausgabe gehören deshalb immer drei Angaben zusammen: Ausgabeprogramm, Formularname und dieser Formulartyp — einen davon allein zu tauschen, reicht nicht.
EDI ist hier kein eigener Mechanismus, sondern ein weiteres Medium derselben Findung. Wer eine fehlende Ausgangsnachricht sucht, sucht in derselben Tabelle wie beim fehlenden Ausdruck — nur mit einem anderen Medium in der Zeile.
Die neue Ausgabesteuerung: Kanal statt Medium, BRFplus statt Konditionstechnik
Die Ausgabesteuerung in S/4HANA trennt drei Dimensionen: Anwendungsobjektart, Ausgabeart und Kanal. Gemessen sind für den Fakturabeleg die Kanäle PRINT, EMAIL und EDI hinterlegt; für die Auslieferung gilt das für den Lieferschein ebenso, für Kommissionier- und Packliste dagegen nur PRINT.
Die Formulartechnik hat dort vier Festwerte: Ausgabeformulare über die Gateway-Schnittstelle, Ausgabeformulare über die DDIC-Schnittstelle, Smart Form und SAPscript. In der ausgelieferten Formularzuordnung kommen nur die ersten beiden vor — der Regelfall ist die Gateway-Schnittstelle.
Der größere Unterschied liegt in der Findung selbst: Sie steckt nicht mehr in einer Konditionstechnik mit Zugriffsfolgen, sondern in BRFplus. Das Rahmenwerk sieht je Anwendungsobjektart getrennte Entscheidungsfunktionen vor — für Ausgabeart, Empfänger, Kanal, Drucker, E-Mail-Absender, E-Mail-Empfänger und Formular, jede mit eigener Ergebnisstruktur.
Für ein Projekt ist das keine technische Randnotiz. Wer im ECC eine Konditionstabelle gepflegt hat, pflegt hier eine Entscheidungstabelle. Das ändert die Rollen, die Testfälle und das Transportverhalten — und es gehört in den Fit-Gap, nicht in die Hypercare.
Das Etikett ist keine Nachricht
Das Global Transport Label ist ein Kennzeichnungsstandard, kein Nachrichtenformat. Es hat keine Nachrichtenart und keinen Basistyp, und es taucht in keiner Findungstabelle auf. Was es mit dem Lieferavis teilt, ist die Datenquelle: beide lesen dieselbe Packstruktur. Deshalb schlägt ein Packfehler an zwei Stellen gleichzeitig durch — siehe Etiketten und, für den Umstieg auf die neuen Empfehlungen, VDA-Umstellung.
Woran ich zuerst nachsehe
- Gibt es überhaupt einen NAST-Satz — und steht er auf 0 oder auf 2?
- Trägt die Belegart ein Nachrichtenschema, oder ist die Belegart auf die neue Ausgabesteuerung gedreht?
- Stimmt der TNAPR-Eintrag für genau dieses Medium — oder wurde nur der Druckzweig gepflegt?
Nachgestellt wird über die Wiederholung: VL71 für Nachrichten aus Auslieferungen, VF31 für Nachrichten aus Fakturen. Der Customizing-Einstieg ist NACE. Getestet wird am echten Beleg, nicht durch Direktschreiben in NAST.