Eigenen Funktionsbaustein anlegen. Vorschlag: master_idoc_create_<Nachrichtentyp>. In der Schnittstelle sind die Beispiel-Parameter appl_head und appl_item sind durch die eigenen Anwendungsdaten, aus denen das IDoc erstellt werden soll, zu ersetzen.
Variablendefinition: Die erste data-Anweisung kann übernommen werden. Die zweite data-Anweisung muß an das eigene IDoc angepaßt werden.
Der Block, in dem das Verteilungsmodell gelesen wird, kann übernommen oder sogar noch erweitert werden, falls gewünscht. In diesem Beispiel wurde der Baustein ale_model_determine_if_to_send verwendet.
Für alle IDoc-Segmenttypen mit Währungsbeträgen kann die Form-Routine e1xitem_currency_sap_to_idoc als Vorlage verwendet werden, um eine eigene Konvertierungsroutine zu schreiben. Vorschlag für den Namen: <Segmenttyp>_currency_sap_to_idoc.
Für alle IDoc-Segmenttypen mit Feldern, für die ISO-Codes existieren, kann die Form-Routine e1xitem_codes_sap_to_iso als Vorlage verwendet werden, um eine eigene Konvertierungsroutine zu schreiben. Vorschlag für den Namen: <Segmenttyp>_codes_sap_to_iso.
Für alle IDoc-Segmenttypen mit linksbündig zu setzenden Feldern, kann die Form-Routine e1xhead_condense als Vorlage verwendet werden, um eine eigene Routine zu schreiben. Vorschlag für den Namen: <Segmenttyp>_condense. Das linksbündig Setzen sollte nach den Kovertierungen erfolgen.
Die Programmteile, in denen aus den Anwendungsdaten das IDoc aufgebaut wird, müssen an die eigenen Anwendungsstrukturen und die IDoc-Segmente angepaßt werden.
Falls die Anwendung über den Verbucher geht, muß eventuell master_idoc_distribute auch in update task aufgerufen werden.
COMMIT WORK nicht vergessen, wenn auf einer höheren Ebene keiner erfolgt. Der Datenbank-Commit am Transaktionsende reicht nicht aus.