SAP SD Upload Templates

Structurally identical to the quotation interface with INQUIRY_ in place of QUOTATION_. Every underlying structure is the same.

What to watchEvery structure here is identical to the quotation BAPI, but every parameter name differs. INQUIRY_ITEMS_IN, not QUOTATION_ITEMS_IN. Reusing the quotation mapping unchanged is the documented failure mode: it binds to nothing and fails silently.

Structurally the sales order interface with quotation naming. Note the parameter names use ITEMS and SCHEDULES in the plural, unlike the order BAPIs.

What to watchThe parameter names differ from the sales order BAPI even though every underlying structure is identical. It is QUOTATION_ITEMS_IN here and ORDER_ITEM_IN there, plural versus singular. A mapping copied from the order template binds to nothing and the quotation is created with only its document type.

The standard sales order interface. Same pricing, same availability check and same credit check as VA01.

What to watchPartners are not optional and they are not on the header structure. The sold-to party goes into ORDER_PARTNERS with partner role AG, not into ORDER_HEADER_IN. A file that puts the customer number on the header and nowhere else produces an order with no sold-to and fails.

Step by step VA01 upload guide

The change counterpart to the sales order create BAPI. It uses a two part update convention that is unlike the MM change BAPIs.

What to watchUPDATEFLAG takes a letter, not an X. It is I to insert, U to update and D to delete, and it sits at the front of every X structure in this BAPI. A template that labels the column X and fills it with X will not update anything. The other fields in those structures are ordinary X flags, so the two conventions sit side by side in one row.

A sales order shaped interface with one extra table for the contract data, and no schedule lines at all.

What to watchThe contract validity is not on the header. BAPISDHD1 has one hundred and twenty two fields and not one of them is a contract start or end date. They live in CONTRACT_DATA_IN, keyed by item number, with header level validity carried on the row whose item number is zero. A sheet modelled as header plus items will produce contracts with no validity period at all.

The same interface as a sales order. What makes it a return is the document type and the reference to the original order.

What to watchOrder reason is what makes a return reportable. On most configurations it is mandatory on the header for document type RE, and it is the field the business reads afterwards to understand why goods came back. A bulk return load with everything defaulted to one reason code destroys that analysis.

The sales order interface with a different document type and an order reason, and with the quantity in a different place.

What to watchThe quantity does not go where it does on a sales order. Credit and debit memo request item categories are not schedule line relevant, so there is no schedule line to carry it and the quantity has to sit in TARGET_QTY on the item with its flag set in the X structure. Check the item category in VOV7 on your own system: if yours is schedule line relevant, fill both.

A deliberately small interface. It takes shipping point, a due date and a list of sales order items, and works out the rest.

What to watchRead the result from the DELIVERIES and CREATED_ITEMS tables, not from the DELIVERY export field. The BAPI can split one call into several deliveries, and when it does, the single export field is not the answer. Reading it alone is how a load appears to create one delivery when it created four.

Step by step VL01N upload guide

A control-structure interface rather than an X-flag one. The control structures use named booleans and lead with real keys.

What to watchThe delivery number has to be passed three times: as the DELIVERY parameter, in HEADER_DATA and in HEADER_CONTROL. Leave it out of the control structure and the call returns no error and does nothing. And CHG_DELQTY is overloaded: it is the switch for batch and storage location changes too, not only quantity.

A deliberately small interface for the goods issue step. For a plain PGI the whole payload is four fields.

What to watchFor a plain goods issue the entire payload is four fields: the delivery number three times, and POST_GI_FLG set to X. Leave POST_GI_FLG blank, or leave the delivery number out of HEADER_CONTROL, and the call returns no error and posts nothing. SAP has a Knowledge Base Article dedicated to exactly this.

A replica interface: you send the whole document and it is created wholesale. There are no update flags anywhere in it.

What to watchTwo things are not where you would look for them. The header has no date field at all: every date goes in HEADER_DEADLINES as a fourteen digit UTC timestamp with a time type saying which deadline it is and a time zone beside it. And the item has no purchase order field: the link to the order lives in ITEM_REF_PURCHASE_ORDER. Miss either and the delivery is created but useless.

A shipment item is a delivery number. There is no material anywhere in this interface.

What to watchITEMDATA is not what the name suggests. BAPISHIPMENTITEM has exactly two fields, a delivery number and an itinerary position, and neither is a material or a quantity. A shipment item is a whole delivery. The transport content, meaning origin, destination, legs, agent and distance, lives in STAGEDATA, and the deliveries have to exist before you start.

A list-based interface. It takes a table of reference documents and creates a billing document for each, which is why it is named CREATEMULTIPLE.

What to watchThis BAPI has no exporting document number, and errors arrive in two places. Success comes back in the SUCCESS table as BILL_DOC, and failures can be in RETURN or in the separate ERRORS table. An empty SUCCESS table is the only reliable signal that nothing was created, so check all three.

Step by step VF01 upload guide