Delivery processing

 

1. Outbound delivery processing
2. Determination routines
• Partner determination for Shipping Point in Outbound Delivery 
• Route determination
• Storage location determination 
• Material Staging
• Delivery type determination
• Item category determination 
3. Functions
• Delivery split ( LOG + EWM)
• Delivery group 
• Collective delivery processing
4. Fixing inconsistency
• RVDELSTA: Redetermination of the Status in the Delivery
5. Additional information 
• 355404 - Why was there a delivery split during creation?
• 546719 - FAQ: Delivery group and BOM in the delivery

Outbound delivery processing 

An outbound delivery can be created as follows:

• With reference to a sales order
• With reference to a stock transport order
• With reference to a subcontract order
• With reference to a project
• Without any reference

Depending on your requirements, you can create outbound deliveries automatically using worklists, or manually. You can make agreements with your customers for complete and partial deliveries and for order combinations . Outbound deliveries can be combined to form a single group of deliveries .

Determination routines

Partner determination for Shipping Point in Outbound Delivery

Reproducing the Issue

• Delivery Type is customized for Partner Determination Procedure (PARGR) in SPRO -> Logistics Execution -> Shipping -> Deliveries -> Define Delivery Types
• Here you define which Partner Determination Procedure you want to assign to the Delivery Type
• Partner Functions are assigned in Partner Determination Procedure in SPRO -> Logistics Execution -> Shipping -> Basic Shipping Functions -> Partners -> Set up Partner Determination for Deliveries
• When the Delivery is created it will determine the Partners that are maintained here
• There is no customizing to determine Partners for a specific Shipping Point

Cause

Partner Determination cannot be customized for a specific Shipping Point during Outbound Delivery creation. This is standard system behaviour

Resolution

User-exit USEREXIT_SAVE_DOCUMENT_PREPARE in Include MV50AFZ1 could be used for this purpose. You could use your own coding here. SAP Note 415716 provides information on User exits in delivery processing

Material Staging

Either the Warehouse Number or the Storage Location is blank and consequently field Material Staging (LIPS-LGBZO) is clear.

• Follow the below path (SPRO > Enterprise Structure > Logistics Execution > Assign Warehouse Number to Plant / Storage Location) and maintain the missing Warehouse Number.
• Follow the below path (SPRO > Logistics Execution > Decentralized WMS Integration > Central Processing > Application > Define Interface to Inventory Management and Delivery-Relevant Data > Delivery-Relevant Data for Warehouse Number) and maintain the missing Warehouse Number.

Delivery type determination

thru t code vov8 u can assign the del type .

 

Delivery type considers different business transactions in delivery processing. Delivery types defined in the standard SAP system include:

• LB: Delivery for subcontract order；
• LD: Decentralized shipping (used in decentralized shipping in connection with R/2 RV)
• LF: Outbound delivery；
• LO: Delivery without reference (no sales order necessary in order to create a delivery)；
• LP: Delivery from project；
• LR: Returns delivery；
• NL: Replenishment delivery；
• RL: Returns vendor；

With control elements, we can configure each delivery type to perform different functions. In the project practice, we can adjust the delivery types in the standard system to meet your business needs, or copy the standard delivery types to create new delivery types.

Item category determination

Delivery item category controls how items are operated and processed in the shipping process. The available control elements provide advanced and flexible automation and inspection. In project practice, it is often necessary to configure item categories to meet the special needs of business departments.

Copying item categories from the order

• When copying an order item to delivery, the system also copies the item category of the order item to delivery item;
• If the item category of the order or the schedule line assigned to it is related to delivery, define the same item category for delivery item;

Route determination 

Criteria

• the country and transportation zone of the shipping point / Customization
• the shipping condition / Default value based on Sales Document Type or from Customer Master of Sold-To Party
• the transport group / Default Value from Material Master
• the country and transportation zone of Ship-To-Party/ Default Value from the Customer Master of Ship-To-Party.
• the Weight group ( if the route determination is carried out again at the delivery note level ) / Customization

Specifics for inbound delivery

• Inbound deliveries require Route determination with Weight Group as it does route determination in the delivery. Without weight, group does determination in the sales order and copies to the delivery, therefore do not work for inbound deliveries.
• Check the assignment in the customizing, SM30: V_TWLVZ
•  the use of a goods receipt point is required if you want to work with the function of the route determination in case of inbound deliveries.

Bear in mind that the departure country and transportation zone of the vendor are used as initial data in the case of the inbound delivery and that the goods receiving point is used as the destination.

Fields transportation group (LIKP-TRAGR) and shipping condition (LIKP-VSBED) are not filled in the header of the inbound delivery since the data is sales-specific here. 

• You must define corresponding entries without shipping condition and transportation group in the route determination or supply the fields with the values you require via the copying control so that the route determination works.  

We can set the route determination for inbound deliveries for each vendor, transportation service agent, and receiving plant.

If route determination should be repeated, we can have the SAP System check whether the actual route found for the delivery is allowed instead of the original proposed route. 

• Activate the switch for new route determination for inbound deliveries. For information, see SAP Note 1933274.
• Specify for each delivery type whether route determination should be repeated and whether a found actual route should be checked to ascertain whether it is allowed.
• The proposed route is the route determined by the system. The actual routes are the permitted alternative routes that we enter manually in the sales document in place of the proposed route found by the system.

How to find it in the code? 

• SD_ROUTE_DETERMINATION
• BADI: badi_sd_route
• User exit: EXIT_SAPL0VRF_001

if the route has been found in BADI, skip processing 

Table: TROLZ Routes: Determination in Deliveries

Storage location determination 

• Storage location determination must be activated for the relevant delivery item category in transaction 0VLP
• AND a determination rule must be assigned for the relevant delivery type in SPRO → Logistics Execution → Shipping → Picking → Determine Picking Location → Define Rules for Picking Location Determination

There are three standard determination rules that can be used: MALA, RETA, and MARE.

Let's take a closer look on the above mentioned rules.

In case of rule MALA, the system determines a storage location based on:

• the shipping point,
• the delivering plant,
• and the storage condition.

The shipping point and the plant are very straightforward, these data are (mostly) copied from the predecessor document (for which the delivery note is being created). The storage condition can be maintained in the material master, on the 'Plant data / stor. 1' tab.

Please be aware that the 'Plant data / stor. 1' tab will not be accessible until you specify the plant AND the storage location when entering transaction MM02.

Storage conditions can be created under SPRO → Logistics Execution → Shipping → Picking → Determine Picking Location → Define Storage Conditions.

In case of rule RETA, the system determines a storage location based on:

• the delivering plant,
• the situation,
• and the storage condition.

The situation can be assigned under SPRO → Logistics Execution → Shipping → Picking → Determine Picking Location → Storage Location Determination with Situation.

If you want to define a new situation, you can do so under SPRO → Logistics Execution → Shipping → Picking → Determine Picking Location → Define Situations.

In case of rule MARE, the system chooses rule MALA first, and if the predetermined storage location cannot be applied (like for instance the respective material is not created / maintained for the concerned storage location, or there is no storage location determined in transaction OVL3), it switches to rule RETA. If there is no storage location maintained for the combination of plant / situation / storage condition, storage location determination will not give back any storage location and the delivery document will be created without this parameter.



If you want to use RETA rule for this business process, then
-> add Storage condition ( MARA-RAUBE ), and add an entry for the Situation 21 to determine a Storage location into customizing.
Otherwise, the Default storage location for external procurement (MARC-LGFSB) is filled by default.
Even the Default storage location for external procurement (MARC-LGFSB) is not filled, then the program will change the situation from 21 to 01 to find the storage location.
Reference: FM SD_STORAGE_LOCATION_DETERMINE/ 'PM_GET_STORAGE_LOC_INBOUND'

Delivery group 

Consolidation of items in a sales order so that they can be delivered on the same date. The delivery group can be assigned to an item manually or automatically.

An item that is confirmed for several delivery dates can be confirmed for a single delivery date if it is assigned to a delivery group. This is the latest delivery date of all the confirmation schedule lines of this item.

If the sales order is marked in the header for complete delivery, then all items will be assigned to the same delivery group.

The delivery group is entered in the sales order item and/or subitem.

The sales order is automatically marked for complete delivery if the complete delivery indicator is set in the business partner record for the sold-to party.

Scenarios:

• Delivering Several Items With One Delivery
• Delivering All Items With One Delivery (Complete Delivery)
• Delivering One Item With One Delivery

A delivery group is seen as incomplete when

• for the current delivery, at least one item of the delivery group cannot be created
• this item was not fully dealt with by a preceding delivery.

The quantity correlation is active if you specify a higher-level item in the order for an item and both items belong to the same delivery group. This can be entered manually or it happens automatically, for example, for BOMs if, in the respective order item category, you set in the Customizing that a delivery group should be created. If the delivery quantity of the main item is changed in the delivery, all the subitems are adjusted quantitatively. However, if you change the delivery quantity of a subitem, no correlation takes place within the delivery group.

Delivery split function 

How can the split be affected via the copy control?

Via the copy control, the data is copied from the preceding document to the header of the delivery and therefore acts as splitting criterion. Two routines are relevant for the data transfer for outbound deliveries with order reference in the standard:

• FORM routine DATEN_KOPIEREN_001 (include FV50C001) for the transfer of the data from header (CVBAK) and item (CVBAP) of the sales order.
• FORM routine DATEN_KOPIEREN_002 (include FV50C002) for the transfer of the data from the business data of the sales order.

With all other outbound delivery types as well as with inbound deliveries, the data transfer is carried out via FORM routine DATEN_KOPIEREN_301 (include FV50C301) or DATEN_KOPIEREN_201 (include FV50C201).

In the table with delivery header data LIKP, there is field ZUKRL which can be filled with any values via the copying control.

Why does a split occur per schedule line for scheduling agreements?

You can find a detailed explanation concerning the system behavior in note 137937. Here, the system also offers solution options in order to be able to prevent the delivery split by time/release date.

Note 399912 - Split analysis activation during delivery creation

Reason: Causes for delivery splits in existing deliveries cannot always be traced.
Create the user parameter LESHP_SPLIT_ANALYSIS.
a) Call transaction SM30 for the table maintenance.
b) Enter the table name TPARA and choose "Maintain".
c) Enter the name of the new user parameter LESHP_SPLIT_ANALYSIS and confirm the entry. In a dialog box, the system asks you to enter a short text. Assign the short text "Activate split analysis for deliveries".
d) Save your entries. Assign the parameter to the development class VL.

Using transaction SE91 for the message maintenance, change the short text of message VL033 to 'Item <(>&<)>1: Delivery split because of deviating header data (<(>&<)>2: &3 <-> &4)'
Assign the user parameter LESHP_SPLIT_ANALYSIS to your user master record and enter the value 'X' for it (without inverted commas). For this purpose, you must branch to the function "System -> User Defaults -> Own Data" and select the tab page "Parameter".

If the split analysis is activated, the system displays message VL 033 in the collective processing log for a document item that could not be supplied together with the other items of the same document. In the short text of the message, the system displays the technical name of the field responsible for the split. In general, there is a field with the same name in table LIKP with the header data of the delivery so that you can use the ABAP Dictionary (transaction SE11) to determine the description of the field name. 

The following field names are not included in the table LIKP but they may be displayed in the split log of the delivery:

• KUNNR Customer Number
• LIFNR Account Number of Vendor or Creditor
• PERNR Personnel number
• PARNR Number of contact person
• ADRNR Address
• KUNWE Customer number of goods recipient
• ADRNR_WE Address number of goods recipient

Field ZUKRL has a special status. Using the copying routine, you can fill it with any data in order to control the delivery split. In the unchanged standard system, in case of order-related deliveries, this field is filled with the distribution channel and the division from the order header. This means that the split returns to a different sales area due to the field ZUKRL.
Apart from the field name, the system displays the two different field values that cause the split in message VL033. The second value in the short text of the message relates to the field value in the item to be delivered, and the first value relates to the checked comparison delivery.

 [EWM] 2666457 - How to perform outbound delivery split and undo it

Create Outbound Delivery (OD) split for packed batch subitem & Undo a delivery item split for packed product.

Create Outbound Delivery (OD) split for unpacked product

Fixing inconsistency

RVDELSTA: Redetermination of the Status in the Delivery (04.06.2021)

RVDELSTA is a standard report that corrects inconsistent statuses on a delivery. It checks the document flow of a delivery and calculates new statuses based on the document flow.

• At the beginning of the report, RVDELSTA reads the current data from tables LIKP, LIPS, VBFA, VBUK & VBUP.
• The report loops through all of the selected delivery items from table LIPS and recalculates the status of the item according to the entries contained in the document flow table (VBFA).
• As the incompleteness of a delivery can be influenced by the item status, the system executes a new incompletion check after calculating the new item status.
• Following the incompletion check, the system calculates the new header status (based on the new item statuses).
• Finally, the system then compares the newly calculated status with the status stored on the database. If there is a difference between the old status & the new status, the system will

Note! RVDELSTA is completely dependent on the document flow entries stored in VBFA. Therefore, if the VBFA table is inconsistent (e.g. missing entries), RVDELSTA will not update the statuses of the delivery correctly. If the VBFA table is inconsistent, then you must look at alternative ways to correct that inconsistency. RVDELSTA does not fix an inconsistent document flow.

SAP notes

• 355404 - Why was there a delivery split during creation?
• 546719 - FAQ: Delivery group and BOM in the delivery