Classic message control for EDI

Most EDI outputs in a converted system still run on message control, so an EDI consultant needs to read NACE fluently. Transaction NACE lists the applications; each one holds its output types, access sequences, condition tables and procedures. The ones that matter for order-to-cash and procure-to-pay EDI are V1 (sales), V2 (shipping), V3 (billing) and EF (purchase orders).

The output type for EDI

An output type defines which media are allowed, which partner functions may receive it, its default values, and the processing routine per medium. For EDI, the processing routine for medium 6 points to the standard EDI program (program RSNASTED with form routine EDI_PROCESSING in the standard), which passes the output to the IDoc interface. If medium 6 has no processing routine in the output type, EDI output for it cannot work at all, which is a classic gap when a custom output type is copied from a print-only one.

Dispatch time

The dispatch time on the condition record says when the output is processed: 4 sends immediately when the document is saved; 3 waits for the application's own send transaction (for deliveries, the "Output from Deliveries" function); 1 and 2 wait for a periodically scheduled job running report RSNAST00, with 2 adding a time specification. Contoso sets BA00 and LAVA for Great Lakes to 4 so the 855 and 856 leave within minutes. A dispatch time of 1 without a scheduled RSNAST00 job is one of the most common reasons why "no IDoc went out".

Contoso's condition records

Two details deserve attention. First, the partner function on the record must be one the output type allows and must match the outbound row in WE20. SAP's documentation adds a rule that surprises people: when the medium is EDI, message control only proposes the output if the output partner is set up as a partner in the IDoc interface. So a missing WE20 profile can make the output disappear from determination instead of failing loudly. Second, condition records are master data, maintained per system with VV11, VV21 and MN04 (and VV31 for billing where it still runs on NAST), not transported Customizing. Cutover must load them into CMP.

Where the procedure comes from

Message control only considers output types that are in the output determination procedure assigned to the document. For sales documents the procedure is assigned to the sales document type (the standard header procedure is V10000), for deliveries to the delivery type, and for purchase orders per purchasing document category. When Contoso created a new order type for fleet contracts during the conversion, the first test showed no 855 at all: the new type had been assigned a procedure without BA00. The output type, records and partner profile were all fine; the document type simply never asked for BA00. Checking the procedure assignment belongs in every test of a new document type.

Requirements and change output

A requirement routine on the procedure can stop an output from being determined, for example until the order is complete or free of credit blocks. Great Lakes wants an 855 only for orders without incompletion, so Contoso's procedure keeps the standard requirement that checks the order status before BA00 is proposed. Output types can also allow multiple issuing and send change output when the document changes, which is how an order change can produce a second 855. Whether that is right depends on the partner: Great Lakes accepts a changed 855, and its guide says so.