How the order gets created

Once the IDoc is accepted and its partner profile row found, process code ORDE calls function module IDOC_INPUT_ORDERS. SAP's description of inbound SD processing lists what happens next: technical and application-specific checks on the IDoc data, automatic determination of what the IDoc does not contain (organizational data, the SAP material from the customer material), the creation of the sales order, and a status record on the IDoc. The order is created with the same business checks as an order a user enters: partner determination, incompletion, pricing, availability and credit.

Pricing: whose price is right?

Great Lakes sends a unit price in every PO1 line: 240.00 USD for CMC-ALT-100, Contoso's list price. Contoso's SAP pricing determines its own price from condition records. These two prices are meant to agree, and the mechanism that checks them is the customer expected price. Contoso's map passes the partner's price into the IDoc as the customer's expected price, which the order stores as condition EDI1 (expected net price per item); EDI2 would carry an expected item value instead. SAP's documentation states the consequence: if the customer expected price differs from the automatically determined net price or value, the system marks the sales order as incomplete.

SAP describes the same pattern for EDI with external buyers: if the customer-expected price is fine, the system can send the order confirmation automatically; if not, a user can send a confirmation with a changed price or with rejected items. Contoso's BA00 requirement waits for a complete order, so a price mismatch holds the 855 until someone has decided. The worst design is the opposite: overwriting SAP's price with the partner's price to make orders flow, which silently gives every partner the right to set its own prices.

Dates

The requested delivery date from E1EDK03 002 becomes the order's requested delivery date. SAP then schedules backward and forward with transportation, loading, picking and material availability times, and the confirmed date on the schedule line may be later. That difference is not an error, but it is exactly what Great Lakes wants to know, so the 855 sends the confirmed date back (course sap-edi-204). Test cases must check both: that the requested date was taken over unchanged, and that the confirmed date comes from real availability.

Availability and credit run as they do for any order. If CMC-ALT-100 is short in plant 1710, the schedule line confirms a later date or a partial quantity, and that is what the 855 reports. If Great Lakes exceeds its credit limit, the order is created but blocked for delivery by credit management, and Contoso's BA00 requirement holds the 855 until the block is released, because confirming an order that cannot ship would mislead the customer. Neither case is an EDI error; both are business outcomes that the EDI flow must report faithfully.

Messages, exits and the "do not ask" settings

• Handle Messages for Inbound Orders (Sales and Distribution > Electronic Data Interchange > EDI Messages): lets you control how specific dialog messages behave when the order is created from an IDoc. SAP's own example setup lists VA01 messages VG 200 and 201 here so that pricing conditions transmitted by EDI are accepted without query.
• Customer exits: enhancement VEDA0001 (SD EDI incoming orders) offers function exits such as EXIT_SAPLVEDA_001, called while the segments are read, for partner-specific data that the standard does not handle. Order changes have their own enhancement for IDOC_INPUT_ORDCHG. Use them for genuine gaps, keep the logic partner-specific and documented, and never to bypass a check.
• Duplicate purchase orders: the sales document type can check whether the customer's purchase order number already exists. For EDI that check matters, because a resent 850 would otherwise create a second order for the same purchase.