Functionality

Delivery Processing
This Business Application Interface (BAPI) is for internalcommunication between Advanced Planner and Optimizer (APO) and the SAPLogistics Execution System (LES). It has not been released for externaluse. We reserve the right to change the interface and the functions inthe interface without prior notification.
Only the items from the preceding document of a shipment for deliveryare specified when this interface is called up.
(Meeting 16.12.99, APO, LE-TRA, LE-SHP)
Combining two preceding-document items from two different shipments ina delivery (which would be an error) is therefore ruled out by thecalling program.
You can use this function module to carry out the following functionswithin the context of delivery processing:

• Deliver preceding objects

Deliver sales-order items with specification of date/time and quantity
Deliver purchase-order items with specification of date/time andquantity
The preceding document can be in another system. To ensure that theentire requested quantity is generated in the delivering system and thecorresponding requirements are planned in the planning system, forexample, for cross-system deliveries SAP recommends creating uncheckeddeliveries (techn_control-check_mode = 'A'). This does require theadditional step of converting the unchecked deliveryinto a checked delivery, but also has the advantage that the requestedquantity in the delivering system will definitely create an issueelement in requirments planning.
Delivery items whose preceding document is in another system areflagged in the interface parameter REQUEST in theLESHP_DOCUMENT_TYPE field (see fixedvalues for the relevant domain LESHP_DOCUMENT_TYPE).

• Add to a delivery

Add packaging items to a delivery

Description

This BAPI is still being tested and only meant for internal use!
This parameter specifies the deliveries that are to be added to.


• You must enter the delivery number


• For each delivery, you can also specify a control parameter that is
valid for additions to this delivery
Detailed information:

• Document identification:

Key that was used to save this delivery in the database of the systemthat was called up.
DELIVERY_NUMBER:
Business key from the number range interval for deliveries. It isunique in the client that was called up in the SAP System.

• Control parameter

NEW_DELIVERY_ALLOWED:
If the system recognizes that the delivery item that is to be createdcannot be added to the delivery that was specified because of splitcriteria (ship-to party, route, or shipping point, for example), youcan still allow the requested delivery-item creation by allowing thesystem to create a new delivery. To accomplish this, set this indicatorto "X".

Default
If you do not specify this parameter, new deliveries will be created(in other words, existing deliveries will not be added to).

Description
Control Parameters for Program Flow

Value range
You can enter the following attributes:


• DEBUG_FLG

The value in this field controls the program flow as described below.The value from the interface is replaced by the value from the userparameter LE_SHP_BAPI_DEBUG, where this has been set.
The flag was designed to allow you to conduct error analysis indebugging in inbound processing of the IDoc, despite automaticasynchronous communication via IDoc.
X: The program stops at the predefined points. You make the settingsfor error analysis in the delivering system.
Y: The program terminates with a termination message, as long as theflag is not set in the user parameter. This is used in asynchronousprocessing (using an IDoc) to cancel automatic posting with anon-specified user during IDoc inbound processing. After this, a userwith an 'X' set in the user parameters can post the IDoc that was partof the canceled inbound processing, and can analyze the errors.
Recommendations for Error Analysis:
Tell the calling system that this field should be set to 'Y' in theoutboud IDoc. Preceding objects (sales order, purchase order) can, forexample, evaluate these user parameters when filling the IDoc interfacein the SAP environment (for example, using the function moduleLE_SHP_BAPI_DEBUG_CONTROL).
Alternatively, you can maintain your ALE Customizing settings in thedelivering system, so that the corresponding IDoc is no longer postedautomatically, but must be triggered manually instead.
Set the user parameter LE_SHP_BAPI_DEBUG to 'X' for theuser who should perform error analysis in the delivering system.
Start inbound processing for the IDoc with messagetype DELIVERYPROCESSING_EXECUTE in the delivering system, and analyzethe errors in debugging mode.

• SENDER_SYSTEM

This can be used to construct a communication link with the callingsystem. This system does not have to be the same as the system thatcontains the preceding documents (sales order, purchase order) for thedelivery to be created. For example, the system CRMCLNT100 can containa sales order that will be delivered in system LESCLNT200. However, youcan trigger cretion of the delivery from a planning system APOCLNT300.The Sender_System field would then contain the value APOCLNT300.

• PROCESS_GUID

Is a unique number that connects a transaction across several systemsand also during asynchronous communication.
Example:
A planning system uses a transaction with Process_GUID 1 from systemAPOCLNT300 (APO) to create a delivery for an order in system CRMCLNT100(CRM). Transaction 1 is finished in system APO before the delivery wascreated in system LESCLNT200 (LES) (asynchronous communication).
If delivery creation is now triggered in LES, it can report itself toAPO with the Process_GUID 1, and can create a reference to the peggedtransaction.
This is used, for example, to transfer sales order requirements fromthe ordering system CRM in planning system APO into deliveryrequirements for the delivering system LES.

• ERROR_TOLERANCE

Not used.

• CHECK_MODE

space: Delivery items are being created for the entire scope of check.
'A': Unchecked delivery items are being created.

• IDOCNUM

Within the BAPI, the IDoc number is linked to the generated deliveries.This means that the deliveries are accessible via the object servicesfrom the IDoc. This field is transferred in the generated coding forthe inbound IDoc function module, from the IDoc to the BAPI interface.Each time the inbound IDoc function module is regenerated (transactionBDBG), this population with values is lost and must be repeated. For adescription of this, see Note 317216.

Description
Attributes for Classification

Value range
When you save the sales order/PO from the classification system, thesevalues are copied from the sales order/PO system into the interface,and are transferred to the classification system in the delivery systemwhen delivery processing begins. The COMMIT statement from deliverygeneration also updates the Controlling information.
Delivery processing itself does not have any algorithms implemented forthis data. The BAPI is only used as a container for transporting databetween the classification system in the preceding system, and theclassification system in the delivering system.
This is used, for example, in batch determination. Only an ID for batchdetermination is transferred in the request interface. This ID is thenused to find the classification data for batch determination, which isthen used to find the batches. It is possible that the classificationsystem arrives in the delivering system only after the first time theBAPI is called. This part of the interface is the most important.
The same applies for the Controlling data.

Description
Text-like contents of the transferred classifying attributes.

Value range
See description of classifying attributes.

Description
Value-type contents of the classifying attributes.

Value range
See description of classifying attributes.

Description
Number-type contents of the classifying attributes.

Value range
See description of classifying attributes.

Description
For exchanging characteristics across system boundaries.

Description
Return Log for the Deliveries Created

Value range


• ID

Link between request record (REQUEST) and return log (CREATEDITEMS). Ifthe REQUEST IDs were initial, the system uses their line numberinstead.
Example:
There are two records in the request interface for delivering the salesorder items 4711/10 and 4711/20. There is also a request record for4711/10 with the request ID = 1 and a request record for 4711/20 withthe request ID = 2. If only one delivery item was created withreference to order item 20, for example due to lack of availability,then the return log contains only one record. You can create a link tothe corresponding request record using CreatedItems-ID = 2
A reference using the predecessor number/item would not be sufficientif you wanted to create several delivery items for one order item, forexample, one schedule line for each delivery item.

• DOCUMENT_CATEGORY_SD

Slaes document type of the delivery created. See fixed values fordomains VBTYP (J,T,G,7)

• DOCUMENT_NUMB

Document number of the delivery created.

• DOCUMENT_ITEM

Item number of the delivery item created.

• QUANTITY_SALES_UOM

Delivery quantity in alternative delivery/sales unit.

Description
Partners that should be copied into the delivery.

Description
BAPI reference structure for addresses (organization/company).

Description

This BAPI is in the testing phase and only meant for internal use!
Incompatible changes may occur!
Request for creating or changing deliveries. Rows in this table referto document items that are being processed. The following processingactions are currently implemented:


• Delivering a document whose preceding document is a delivery


• Creating a delivery item for packing in an existing delivery without
reference to a preceding document
Depending on their connections, the fields are contained for thefollowing logical units in the following sequence:

• Identification of the item to process, including the item structure
information

• Standard partners and partner groups


• Organizational units


• Quantities, weights, and volumes


• Materials and material groups


• Standard dates


• Tax information delivery processing of the item to create


• General fields

Description of the general parameters:


• ID: Optional parameter. Unique number of a request for delivery
processing. This number is used to create a reference between therequest and the result log in the return parameter CreatedItems. Eachnumber can only be used once in each call for the BAPI.
If you do not enter a number, a number is assigned internally and isthe same as the current number of the line.

• DOCUMENT_TYPE: Describes the type of document that is being processed.
The following types are currently implemented:
A: R/3 sales order
B: R/3 purchase order
L: R/3 delivery
You cannot add the values '1' and '2' for preceding objects in anothersystem after SAP R/3 4.6C. For more information, see the description ofcross-system flows of goods below.

• DOCUMENT_NUMB: Number of the document that is being processed.


• DOCUMENT_ITEM: Number of the item that is being processed.


• QUANTITY_SALES_UOM: Quantity that is valid for processing. This
quantity refers to the alternative unit of measure for the document inquestion. The quantity may only be specified in either the alternativeunit of measure or the base unit of measure.
For sales orders, this is the sales order's sales unit.
For purchase orders, this is the order unit.
For deliveries, this is the delivery unit, which is also called thesales unit in the delivery. A different unit may be used in deliveryprocessing than the one that appears in the preceding document. In thiscase, a unique reference is only possible if you use the base unit ofmeasure.

• QUANTITY_BASE__UOM: Quantity in the base unit of measure. The quantity
may only be specified in either the alternative unit of measure or thebase unit of measure.

• QUAN_NO_CHECK: Indicator for deactivating the availability check and/or
requirement allocation. The following settings are possible:
(space) Availability check and requirements according to Customizingin the delivery
W - No availability check/no requirements
X - No availability check, but requirements
2 - Availability check, but no requirements

• MATERIAL: Unique number for the material. You can only make this
specification if processing does not refer to an item from a precedingdocument.

• PLANT: Supplying plant. You can only make this specification if
processing does not refer to an item from a preceding document.

• STGE_LOC: Storage location in which the delivery item is picked. You
can only make this specification if processing does not refer to anitem from a preceding document, or if the preceding document is inanother system (see below cross-system flow of goods).

• ITEM_TYPE: Type of delivery item that is created. You can only make
this specification if processing does not refer to an item from apreceding document. The following types are currently implemented:
C: Packaging items

Information about the standard dates in the delivery:


• If you want to redetermine the schedule in all cases, you must specify
which date you want to start with in order to recalculate the otherdates, or you must specify the exact date on which you want to performscheduling. In both cases, rescheduling is only possible from amaterial availability date or a desired delivery date (arrival atcustomer).

• If you want to pre-set the dates and times as you create the delivery,
fill in the date and time fields for the five standard dates: inbounddelivery date at customer, material staging, transportation planning,loading, and planned goods issue.
More specifically:
DATE_USAGE: Specify date for scheduling
* (space) Copy default dates
* 1 Rescheduling should be based on the planned material staging date
* 2 Rescheduling should be based on the planned delivery date
DATE: Date that rescheduling is to be based on
TIME: Time that rescheduling is to be based on
MAT_AVAILABIL_DATE: Planned material staging date
MAT_AVAILABIL_TIME: Planned material staging time
TRANSP_PLAN_DATE: Planned transportation planning date
TRANSP_PLAN_TIME: Planned transportation planning time
LOADING_DATE: Planned loading date
LOADING_TIME: Planned loading time
GOODS_ISSUE_DATE: Planned goods issue date
GOODS_ISSUE_TIME: Planned goods issue time
DELIVERY_DATE: Planned delivery date
DELIVERY_TIME: Planned delivery time
As an alternative to date and time, each point in time can also beentered as a UTC time stamp together with thetime zone that is to be used. The above fields arereplaced with the following alternative date and time fields:
MAT_AVAILABIL_TIME_STAMP: Planned material staging date
MAT_AVAILABIL_TIME_ZONE: Time zone for material staging date
TRANSP_PLAN_TIME_STAMP: Planned transportation planning date
TRANSP_PLAN_TIME_ZONE: Time zone for transportation planning date
LOADING_TIME_STAMP: Planned loading date
LOADING_TIME_ZONE: Time zone for loading date
GOODS_ISSUE_TIME_STAMP: Planned goods issue date
GOODS_ISSUE_TIME_ZONE: Time zone for goods issue date
DELIVERY_TIME_STAMP: Planned delivery date
DELIVERY_TIME_ZONE: Time zone for delivery date

Creating deliveries
You can specify the following attributes when you create inbounddeliveries with reference to purchase orders:


• TRANS_CAT: Means-of-transport category


• TRANSP_ID: Shipment ID


• EXTDELV_NO: External ID for the delivery note


• ORDCOMBIND: Combining items from different documents into one delivery
is allowed

Creating packaging items
You can enter weight- and volume information when you create packagingitems for the first handling unit:


• TARE_WGHT: Handling unit's tare weight


• UNIT_OF_WT: Weight unit


• UNIT_OF_WT_ISO: Weight unit in ISO code


• TARE_VOL: Handling unit's tare volume


• VOLUMEUNIT: Volume unit


• VOLUMEUNIT_ISO: Volume unit in ISO code

Cross-system flow of goods
For cross-system flow of goods in releases after SAP R/3 4.6C,you can create outbound deliveries that have a preceding document in adifferent system. These preceding objects are flagged in the interfaceas follows:


• The preceding document (DOCUMENT_NUMB), its item (DOCUMENT_ITEM), and
also a logical system are shown (DOCUMENT_SYSTEM). This logical systemcan be used to call the preceding document from the delivery system.

• The processing in the BAPI refers to two additional values for the
document type (DOCUMENT_TYPE):
1: Sales order in external system
2: Purchase order in external system
The existing scenarios, where the preceding document is in the samesystem as the delivery, are called integrated scenarios. The values A,B, and L (above), are valid for these scenarios.

• The preceding objects for sales orders can be described in more detail
by the sales document type in the attribute DOCUMENT_CATEGORY_SD. Youcan see the fixed values in the domain VBTYP for thedata element VBTYP, for example 'C' = order.
In this scenario, there are other functions based around the data inthe interface. The most important of these are described below:
Determining copy control
Copy control requires an order type and a delivery type.
If the delivery type (DOCUMENT_TYPE_DELIVERY) is missing, for example,for an outbound delivery with reference to a standard order, the systemcopies the default value for the vendor (LF) fromCustomizing for the order type.
If the order type (DOCUMENT_TYPE_PREDECESSOR) is missing, for example,a replenishment delivery with reference to a purchase order, the systemcopies the default order type (DL) from Customizingfor the delivery type (NL, NLCC).
In the replenishment scenario, the delivery type is determined in theordering system from the purchase order type (ViewV_161V for table T161V). This is because only thepurchase order knows the company code of the ship-to party (thereceiving plant). However, the goods movement must be posteddifferently. This means that the delivery type must be used toinfluence movement type determination.
If both entries are missing, processing is canceled with an error log.
The document types in the interface can be converted before they areinterpreted in Customizing for the supplyingsystem. This is made possible depending on the calling system, in orderto enable you to transfer customer-specific document types in theordering systems to the delivering system in a consistent process.
This results in the following determination for copy control:
,,TA -> LF
,,DL <- NL
,,DL <- NLCC
Determining the movement type
The following fields in the interface have an influence on thedetermination:
ITEM_CATEGORY_DELIVERY
ITEM_CATEGORY_PREDECESSOR
MATERIAL
SALES_ORGANISATION
DISTRIBUTION_CHANNEL
DIVISION
Other fields are relevant if the sales area is not entered in theinterface and therefore a suitable entry must be determined for thedelivering plant.
The movement type is taken from the corresponding schedule line.Schedule line category determination requires a delivery item category.
Determining the delivery item category:
Default item categories can be converted for each system according toyour Customizing settings. This occurs for thepreceding item category before it is used in the determinations.
If there is no default value for the delivery item category(ITEM_CATEGORY_DELIVERY), the category is determined as follows:
with a reference to a sales order, the delivery item category iscopied from the order item category (ITEM_CATEGORY_PREDECESSOR).
,,TAN -> TAN
,,TAC -> TAX
with a reference to a purchase order, the system determines anitem category with the usage 'V' and the material master data from thesales area. The item category is determined according to theCustomizing settings for table T184L.
* ,,Delivery type (see above)
* ,,Item category group from the sales view of the material (mvke-mtposfor material, sales organization, distribution channel). The sales areais determined in the same way as if you were performing a replenishmentdelivery in the supplying plant, from the supplying system to theship-to party.
* ,,Usage 'V': (with next-level principle: if there is no entry in theitem category group, then use item category group = space.)
,,NL, NORM, V ,,-> NLN
,,NLCC, NORM, V ,,-> NLC
Determining the schedule line category according to Customizing fortable V_TVEPZ:
Item category
MRP type (material master for the supplying plant MARC-DISMM). Withnext-level principle: if no entry exists for the MRP type, then MRPtype = space.)
,,TAN, PD ,,-> CP
,,TAX, space ,,-> CX
,,NLN, space ,,-> NN
,,NLC, space ,,-> NC
The movement type is determined from the schedule line (
v_tvep, TVEP-BWART)
,,CP -> 601
,,CX -> space
,,NN -> 641
,,NC -> 643
Cross-system conversion of the movement type
For a replenishment delivery with reference to a purchase order in adifferent system, you must post the goods movement in two steps. In thesupplying system, the goods issue is posted into nothingness (6A1, 6A3)and an IDoc is sent to the ordering system that then posts acorresponding goods movement from nothingness into the stock in transit(6B1, 6B3). For the duration of the IDoc correspondence, the stock is,for all intents and purposes, contained in the IDoc. The conversion iscarried out according to entries in table T156N using the viewv_156n_vz with FCODE CROSS_SYSTEM.
,,641 -> 6A1
,,643 -> 6A3
This results in determination of movement type, delivery type, defaultorder type, and item category.
TA -> ,,LF ,,,,-> TAN -> CP ,,,,-> 601
DL <- ,,NL ,,,,-> NLN -> NN -> 641,,-> 6A1
DL <- ,,NLCC ,,-> NLC -> NC -> 643 -> 6A3
Determining the unit of measure
As an enhancement to the integrated scenario, the cross-system scenarioenables you to enter a unit of measure for the delivery quantity thatcan also be different from the alternative unit of measure in thepreceding document (sales unit of the order, purchase order unit in thepurchase order: SALES_UNIT, SALES_UNIT_ISO). However, the supplyingsystem must either know the unit of measure for the given material anda batch, where applicable, or the conversion factors between the unitof measure and the base unit of measure must be entered as numerators(SALES_QTY_NUM) and denominators (SALES_QTY_DENOM) in such a way thatthe following formula is fulfilled:
QUANTITY_BASE__UOM = QUANTITY_SALES_UOM * SALES_QTY_NUM /SALES_QTY_DENOM
If the alternative unit of measure from the ordering system is notknown in the supplying system, you can use a conversion in the BAPIinterface. To do this, enter the ISO unit of measure (SALES_UNIT_ISO)and leave the system-dependent unit (SALES_UNIT) blank. The systemdetermines the internal unit of measure for the supplying system fromthe ISO unit of measure.
If you have not entered an alternative unit of measure, but you haveentered a delivery quantity in base unit of measure for the deliveryquantity, then the alternative unit of measure is also used as the baseunit of measure. The conversion factor is then 1 : 1.
The data type for the quantity fields offers more precision than thetransaction entries in the integrated order entry transaction. However,you should note that stocks in SAP R/3 are always managed in a baseunit of measure with three decimal places. In the same way, availablequantities are also determined to three decimal places. In certaincircumstances, you can use the more precise entry for summations andconversions between different units of measure within deliveryprocessing. However, total consistency within SAP R/3 can only beachieved if the quantities are entered in such a way that they can bedisplayed in the base unit of measure to three decimal places.
Delivery items with a quantity of 0 are rejected as being incorrect.
Special stocks
No special stocks are allowed in cross-system replenishment.
Determining the shipping data
The following shipping data is determined in the BAPI shell, as long asit has not been entered by the initiator (shipping data can also bedetermined within the core delivery processing). This is performed inthe same way as in the integrated scenario for replenishment deliveriesor deliveries without reference to a preceding object.
Sales organization
Distribution channel
Division
Shipping condition
Shipping point
Route
Delivery priority
Order combination indicator
Loading group
Sold-to party
Forwarding agent
Transportation group
Weights
If the weights are default entries in the interface, then they are notdetermined from the material master data.

Description
Error log

Value range
Contains all messages (error, warning, information) from deliverygeneration.

Description
Delivery text header.

Description
Delivery text lines.

Description
CSL: Data element CSL_TR_EXT as structure (for BAPI table arg.).