Stock transfer/transport process (STO)

Scenarios

Intra-company stock transfers (domestic)
Intra-company stock transfers (cross-border)
Cross-company stock transfers (domestic)
Cross-company stock transfers (cross-border)
Stock transfer order processing
Purchase requisition
Stock transfer order
Valuated Stock in Transit

Functions

Stock Transfer from Plant to MRP Area
Stock Transfer with Handling Units
ATP
Shipping data determination ( please, see the note )
Outbound delivery creation for STO
Grouping PR-s into a single STO
Delivery scheduling in Stock transfer order (STO)
Partner determination
Control the reduction of Planned Independent Requirements
Automatic inbound delivery creation for stock transfers

Stock in transit
Troubleshooting STO
Additional information

2843362 - No ATP check via Tcode VL10 with the delivery scenario STOA
1777808 - One stock transfer order item is separated into several delivery items
2810822 - Inbound Delivery is not created automatically in two step stock transfer process with STO
2908161 - New scheduling for replenishment deliveries from STO
2408523 - Outbound delivery not appearing in MD04
2481964 - Complete delivery for STO not working in every case
2531733 - Multiple Deliveries created for STO exceed committed quantity
842829 - Characteristics of replenishment deliveries from STOs
303453 - User exits for shipping data determination in STO
1688902 - 2 Step STO Returns with Handling Units

303453 - User exits for shipping data determination in STO
1119073 - FAQ: Automatic inbound delivery creation for stock transfers

Scenarios

Intra-company stock transfers (domestic)

The issuing and the receiving plant belong to the same organizational unit and are located in the same country.

Creation of a stock transport order with an excise duty related material in the item (transaction MEPO).
Entering of scenario-relevant excise duty goods issue and excise duty goods receipt parameters for the purchase order item.
Creation of delivery note for the stock transport order (transaction VL10G).
The following goods movements take place when you post the goods issue:
One-step stock transfer — goods receipt and goods issue are posted at the same time in VL02N. The goods movements from one plant to another plant are therefore in one material document with the following movement types:
Intra-company stock transfer (647/101) ; reversal (648/102)
Two-step stock transfer — goods issue is posted in transaction VL02N. The goods receipt in transaction MIGO must be created separately after the goods issue has been posted. The goods movements from one plant to another plant are therefore in two separate material documents with the following movement types:
Intra-company stock transfer (641/101); reversal (642/102)

Intra-company stock transfers (cross-border)

The issuing and the receiving plant belong to the same organizational unit and are located in different countries.

Creation of a stock transport order with an excise duty related material in the item (transaction MEPO).
Entering of scenario-relevant excise duty goods issue and excise duty goods receipt parameters for the purchase order item.
Creation of delivery note for the stock transport order (transaction VL10G).
The following goods movements take place when you post the goods issue:
One-step stock transfer — goods receipt and goods issue are posted at the same time in VL02N. The goods movements from one plant to another plant are therefore in one material document with the following movement types:

Intra-company stock transfer (647/101) ; reversal (648/102)

Two-step stock transfer — goods issue is posted in transaction VL02N. The goods receipt in transaction MIGO must be created separately after the goods issue has been posted. The goods movements from one plant to another plant are therefore in two separate material documents with the following movement types:

Intra-company stock transfer (641/101); reversal (642/102)

Cross-company stock transfers (domestic)

The issuing and the receiving plant belong to different organizational units and are located in the same country.

Creation of a purchase order with an excise duty related material in the item (transaction MEPO).
Entering of scenario-relevant excise duty goods issue and excise duty goods receipt parameters for the purchase order item.
Creation of delivery note for the purchase order (transaction VL10G).
The following goods movements take place when you post the goods issue:
One-step stock transfer — goods receipt and goods issue are posted at the same time in VL02N. The goods movements from one plant to another plant are therefore in one material document with the following movement types:
Cross-company stock transfer (645/101) ; reversal (646/102)
Two-step stock transfer — goods issue is posted in transaction VL02N. The goods receipt in transaction MIGO must be created separately after the goods issue has been posted. The goods movements from one plant to another plant are therefore in two separate material documents with the following movement types:
Cross-company stock transfer (643/101); reversal (644/102)

Cross-company stock transfers (cross-border)

The issuing and the receiving plant belong to different organizational units and are located in different countries.

Creation of a purchase order with an excise duty related material in the item (transaction MEPO).
Entering of scenario-relevant excise duty goods issue and excise duty goods receipt parameters for the purchase order item.
Creation of delivery note for the purchase order (transaction VL10G).
The following goods movements take place when you post the goods issue:
One-step stock transfer — goods receipt and goods issue are posted at the same time in VL02N. The goods movements from one plant to another plant are therefore in one material document with the following movement types:
Cross-company stock transfer (645/101) ; reversal (646/102)
Two-step stock transfer — goods issue is posted in transaction VL02N. The goods receipt in transaction MIGO must be created separately after the goods issue has been posted. The goods movements from one plant to another plant are therefore in two separate material documents with the following movement types:
Cross-company stock transfer (643/101); reversal (644/102)

Stock transfer order processing

Stock transfer is the act of moving goods from one part of the distribution chain to another.

Purchase requisition

Either select item category U or enter a vendor with plant reference. Then we convert a saved and released stock transport requisition to a stock transport order

Stock transport scheduling agreement

The agreement type LU is defined in the standard system. The item category must be U. Enter the validity end date.

Stock transfer order

Cross and Intra

For intra-company events, supplying plant and receiving plants in the same company code, you have to use a stock transfer document type. That is, the BSAKZ control indicator is set to "T" for the document type in Customizing (this is document type UB in the standard system).
For cross-company code events, supplying plant and receiving plants in different company codes, you can use both a document type with BSAKZ = 'T' and also BSAKZ = ' '. Then control indicator BSAKZ defines the posting logic in inventory management.

Stock Transfer Between Plants in One Step

The transfer posting can be planned by creating a reservation.
The quantity of the stock transferred is posted immediately from the unrestricted-use stock of the issuing plant to the unrestricted-use stock of the receiving plant.

Movement Type: 301

Stock Transfer Between Plants in Two Steps

The transfer posting cannot be planned by creating a reservation.
The quantity posted from stock is first of all managed as stock in transfer in the receiving plant. The quantity is first posted to the unrestricted-use stock of the receiving plant in the goods receipt posting.

Movement types:

Goods issue: 303 (Remove from storage to plant)
Goods receipt: 305 (Put away in a plant)

Stock Transport Order Without Delivery

Why does it make sense to use the stock transport order?

A goods receipt can be planned in the receiving plant.
We can enter a vendor (freight vendor) in the stock transport order.
Delivery costs can be entered in the stock transport order.
The stock transfer order is part of MRP: Purchase requisitions that were created in MRP can be converted into stock transport orders.
The system can run an availability check for the stock transfer.
If you want to withdraw materials for stock transfers from different storage locations and stocks according to a particular strategy, we can use stock determination.
The goods receipt (GR) can be posted directly to consumption.
The entire process can be monitored via the purchase order history.

A stock transport order without delivery is possible only in a two-step procedure.

We can enter delivery costs in the stock transport order.

The receiving plant enters a stock transport order with order type Stock Transport Order, item category U
The material is posted to transit stock of the receiving plant with movement type 351.
The goods receipt is entered with reference to the purchase order.

Stock Transport Order with Delivery via Shipping

The receiving plant enters a stock transport order with order type UB and item category U
Delivery in the issuing plant ( delivery type NL )

two-step procedure, use movement type 641.
one-step procedure (movement type 647), no goods receipt needs to be posted when the goods arrive in the receiving plant.

Note: If we post the receipt of the goods with reference to the order (movement type 101), the delivery is not updated.

Stock Transport Order with Delivery and Billing Document/Invoice

Order type NB: Item category BLANK (cross-company-code), Item category U (intra-company-code without billing document)
Delivery (NLCC): GI: 643 (2 steps), GI: 645(1 step) GR: 101
IR: RE

*The document type (NB or UB) determines the posting logic – in other words, whether a stock in transit is set up. The item category (U or BLANK) determines whether billing takes place.

Return stock transport order

Returning plant RPLN creates a return PO by ticking the return field on line;
Change the delivery address to plant GPLN, so that it will print the Ship-to address.
Update Header text with the referenced data;
Do the GR for this PO to post stock in-transit;
Create a delivery;
....

Item cat. Config (NCRN ( Inter-Company ), NLRN (Intra ): switch the availability check off.
Purchasing -> Purchase Order -> Returns Order -> Store Return / Return Plant to Plant (NLR, NCR).

Valuated Stock in Transit

We use stock transfers with valuated stock in transit to pinpoint the exact time of the transfer of title. The transfer of title depends on the delivery type.

Stock Transfer with Valuated Stock in Transit

Creating the Purchase Order and Outbound Delivery

Transfer of title at goods issue: NBCR (stock transfer to valuated stock in transit of the receiving plant)
Transfer of title at goods receipt: NBC2 (stock transfer from the valuated stock in transit of the issuing plant to the unrestricted-use stock of the receiving plant)
Transfer of title during transit: Document type NBC3 (stock transfer from the valuated stock in transit of the issuing plant via the valuated stock in transit of the receiving plant to the unrestricted-use stock of the receiving plant)

Stock Transfer with Transfer of Title at Goods Issue

Document type NBCR, post the material from the unrestricted-use stock of the issuing plant to the valuated stock in transit of the receiving plant.
Post the material for the outbound delivery to the unrestricted-use stock of the receiving plant, using movement type 109 (Goods Receipt from Valuated Goods Receipt Blocked Stock).

Stock Transfer with Transfer of Title at Goods Receipt

Document type NBC2, post the material from the unrestricted-use stock of the issuing plant to the valuated stock in transit of the issuing plant.
Confirm the proof of delivery by posting the material into the unrestricted-use stock of the receiving plant.

Stock Transfer with Transfer of Title During Transit

VL02N: Document type NBC3, post the material from the unrestricted-use stock of the issuing plant to the valuated stock in transit of the issuing plant.
VLPOD: Confirm the proof of delivery on the POD Overview tab, you post the material into the valuated stock in transit of the receiving plant.
MIGO: use movement type 109 (Goods Receipt from Valuated Goods Receipt Blocked Stock) to post the material to the unrestricted-use stock of the receiving plant.

Reversal:

Postings in transaction VL02N (Change Outbound Delivery) are reversed in transaction VL09 (Reverse Goods Movement).
Postings in transaction VLPOD (Proof of Delivery - Change Outbound Delivery) are reversed in the same transaction: VLPOD.
Postings in transaction MIGO (Goods Receipt) is reversed in the same transaction: MIGO (Reversal for Material Document).

Returns Stock Transfer with Valuated Stock in Transit

Creating the Purchase Order with Returns Items, and the Outbound Delivery

Transfer of title at goods receipt (NBCR)
Transfer of title at goods issue (NBC2)
Transfer of title during transit (NBC3)

Inbound Delivery with Valuated Stock in Transit

Stock transfer with transfer of title at goods issue
Stock transfer with transfer of title during transit

Customer Delivery with Valuated Stock in Transit

Process:

Order type ORNC is assigned to delivery type NCCU.
Create the outbound delivery with reference to the order.
Post the material from the unrestricted-use stock of the issuing plant to the valuated stock in transit of the issuing plant.
Confirm the proof of delivery on the POD Overview tab, you post the goods issue of the material to the customer: on the POD Overview tab, the selection field specifying the issuing valuated stock in transit contains the value 3 (Goods Issue from Issuing Stock in Transit with Order Reference).

The transfer of title has thereby taken place, and the sales order is complete.

Reversal:

Postings in transaction VL02N (Change Outbound Delivery) are reversed in transaction VL09 (Reverse Goods Movement).
Postings in transaction VLPOD (Proof of Delivery - Change Outbound Delivery) are reversed in the same transaction: VLPOD.

Functions

Stock Transfer from Plant to MRP Area

If you want to plan material requirements for a storage location separately, you can create an MRP area for this storage location. We can then procure materials that are planned for this MRP area using Stock transfer from plant to MRP area.

In Customizing for MRP, we have created the special procurement key (40) for Stock transfer from plant to MRP area for the plant in which the MRP area is located.

Procurement type: F for External procurement
Special procurement: U for Stock transfer
Plant: Number of a plant, to which the MRP area belongs.

Stock Transfer with Handling Units

If we want to transfer handling units from one plant to another plant, we can post them to the stock in transit in the issuing plant and place them in storage with the same HU number in the receiving plant.

Create HUs with a reference to the stock transport order/stock transport scheduling agreement.
Transaction VL10HU: Create a replenishment delivery using the new HUs.
Post goods issue.
...

Shipping data

Materials Management - Purchasing - Purchase Order - Set up Stock Transport Order - Define Shipping Data for Plants

ATP

If the value "A" is maintained for the field "Incl.Purchase orders" in the scope of the check (transaction OVZ9), the available quantity in the receiving plant is then increased by the confirmed quantity in the stock transport order.
For the value "X", the available quantity in the receiving plant is increased by the requested quantity.

Invoice verification in the stock transfer order by EDI

Make the system settings for both processes as described in Note 31126. However, you only need one output type RD04.
Create two outbound parameter entries per partner profile (point 6. of Note 31126) -- one with output variant FI and one with output variant MM. Here, you can only maintain the output control (application, output type, transaction code) in one outbound parameter entry.
Implement the attached correction.
Activate customer function '001' of function group VEDF by including enhancement LVEDF001 in a project using Transaction CMOD.

Outbound delivery creation for STO

Assign a delivery type to the purchase order document type/supplying plant combination (Purchase Order > Set Up Stock Transport Order> Assign Delivery Type and Checking Rule"

NL (Replenishment delivery) is provided for intra-company-code stock transfers and NLCC (Replenishment delivery cross-company) for cross-company-code stock transfers.

Assign sales and distribution (SD) organizational units to the supplying plant (Purchasing --> Purchase order > Set up Stock Transport Order > Plant.)
Assign a customer master record to the receiving plant (Purchasing --> Purchase Order --> Set Up Stock Transport Order\> Plant). You require a customer master record for the receiving plant. This customer master record must be created for the organizational units of the supplying plant (point 2) (Logistics > Sales and Distribution > Master Data > Business Partners > Customers > Create > sales and distribution VD01 or total XD01).

For the intra-company-code stock transport, it is sufficient to create the customer master record as the recipient of a good (VD01).
For the cross-company-code stock transport with shipping and billing documents, a complete customer master record is required (XD01).

If there is a cross-company-code stock transport, create a vendor master record for the purchasing organization of the receiving plant. Assign the supplying plant to the vendor master record. The assignment is executed in the vendor master record from the purchasing organization screen using "Extras --> Additional Purchasing Data".
Enter a shipping point for the combination of shipping condition (from the customer master record of the ordering plant,) - loading group (from the material master) - supplying plant, IMG: Logistics Execution --> Shipping --> Basic Shipping Functions --> Shipping Point and Goods Receiving Point Determination --> Assign shipping points.

Grouping PR-s into a single STO

Purchase requisitions are not grouped together if they don't have the same values for the following fields:

FLIEF - Fixed Vendor
RESWK - Supplying (Issuing) Plant in Stock Transport Order
EKORG - Purchasing Organization
BSART - Purchase Requisition Document Type

EXIT_SAPLME59_001 user exit.

Delivery scheduling in Stock transfer order (STO)

New schedule line logic

"Transfer of confirmed schedule line quantities from orders" is set in the customizing of Configure Global Shipping Data (IMG > Logistics Execution > Shipping > Basic Shipping Functions > Configure Global Shipping Data).

If a new schedule line procedure is activated or TVSHP-KZUBEBE is flagged, the system will only consider committed quantity in STO as quantity to be delivered.
If the STO item has no committed quantity (EKET-MNG02), the STO will have an entry in the delivery due index (VETVG), but there is no quantity to deliver.

Delivery date calculation

Activate shipment scheduling and the route schedule. (IMG for purchasing under Purchase Order --> Set Up Stock Transfer Order --> Assign delivery type/checking rule). if it is not activated, the system calculates the delivery creation date from the delivery schedule date - planned delivery time of the item, taking the plant calendar into account.

Stock transfer order intercompany: copying price from PO to intercompany billing

To have it worked we need to check if the customizing is complete:

The same condition type, for example, PB00, must be defined both in SD and in MM. It must be present in MM pricing procedure of the purchase order and in SD pricing procedure of the intercompany billing
In customizing copy control replenishment delivery > intercompany billing (transaction VTFL) the field Price source (TVCPF-PRSQU) must be 'A' or 'B'

Partner determination

During a (company code internal) stock transfer order no vendor is involved, therefore there is no possibility to carry out a partner determination. We must enter all partner roles (also possible mandatory functions) manually.

Control the reduction of Planned Independent Requirements

For the STO delivery item category and MRP type combination we should assign the value '1' to the field 'Assignment of Requirement types to Transaction'. A requirement type for which the required class is to be assigned to this delivery item category and MRP type combination.

Automatic inbound delivery creation for stock transfers

The output type SPED.

If you use automatic inbound delivery creation for two-step stock transfers, this data is copied from the outbound delivery to the inbound delivery, which you can use to post the receipt of the goods in the receiving plant. The automatically created inbound delivery saves you from entering the actual quantities manually and, in addition, provides a preview of the receipt of the expected goods in the receiving plant.

Automatic inbound delivery creation is mandatory if the receiving plant is managed using a decentralized Warehouse Management system (WMS) or an Extended Warehouse Management (EWM) system; in this case, the inbound delivery is required as a communication document for the decentralized system. Automatic inbound delivery creation is also required if Handling Unit Management (HUM) is activated for the receiving storage location. In this case, the inbound delivery serves as a reference document for the HUs that are transferred by the preceding replenishment delivery.

If a receiving storage location is specified in the stock transport order, it is transferred to the inbound delivery. If it is not specified, the receiving storage location is determined according to the standard storage location determination rules.

If there are HUs in the outbound delivery for the stock transport order, these can pass over to the subsequent inbound delivery during the goods issue. However, the HUss are only transferred from the outbound delivery if either the lean HU status update or unique number assignment are active for HUs.

Before the goods issue of the replenishment delivery can be reversed, the subsequent inbound delivery must first be deleted. Note 1083602 describes the required procedure, particularly if you are using HUM. If you use an Extended Warehouse Management system (EWM) in the delivering and receiving plant, you can use the delivery output SPER to automatically request the deletion of the inbound delivery. In this case, no further manual steps are required. The output SPER must be assigned to the output determination procedure of the delivery along with condition routine 409.

If we use the shipping notification IDoc DESADV to transfer the outbound delivery information to the receiving warehouse, you cannot use cross-delivery handling units in this process. Neither outbound processing and inbound processing of the IDoc nor the message itself (basis type DELVRY03 or higher) are prepared for the transfer of the corresponding HU attributes.

Stock in transit

The stocks do not physically exist in "Stock in Transfer," but it is displayed in MMBE / MB52.

The Stock in Transfer at plant level is read from table MARC field UMLMC. This happens when a two-step transfer posting is started with movement 303/603 but is never completed with subsequent movement 305/605.

The Stock in Transfer at storage location level is read from table MARD field UMLME. This happens when a two-step transfer posting is started with movement 313 but is never completed with subsequent movement 315.

For fixing the stock in transit by means of MB11 / VL32N transaction, we should post a stock adjustment by using the movement types '557/558' to clear the MARC-TRAME field in MB11 transaction. It should be used to fix rounding issues. If we cannot allocate this cost to any cost center, please go to the OMJJ transaction and set the cost center field (KOSTL) as 'optional entry' to the affected movement type. This option is not valid for Stock Transfer Order-cross-company scenario.

For fixing a wrong stock in transit created by an inconsistency between EKET x EKBE tables, you should go through the topics 3, 5, and 6 from the SAP note 100690 to fix the inconsistency.

Troubleshooting STO

Missing vendor data: the Intercompany vendor does not have a plant assignment. This can be added in the Vendor data ( purchasing view: Supplying plant ).
Missing storage location in an outbound delivery:

The Storage Condition is missing from the material master (Plant Data / Storage 1 view)
In Picking Location Determination (Logistics Execution> Shipping> Picking> Determine Picking Location> Assign Picking Locations), an entry is missing for the ShpgPt/Plant/Storage Condition/SLoc combination

Zero Quantity in Outbound Delivery: not sufficient stock in the source plant/storage location.
STO Does Not Appear in Delivery Due List

usually, this is because of the delivery date. You can override logic by activating the shipment schedule for the document type and delivery type combination in customizing (Materials Management> Purchasing> Purchase Order> Set up Stock Transport Order> Assign Delivery Type and Checking Rule).

Not Possible to Determine Shipping Data for Material

The customer for the receiving plant is not assigned in the Shipping Data for Plant customizing activity ( Materials Management> Purchasing> Purchase Order> Set up Stock Transport Order>Define Shipping Data for Plants ).
The material master is not extended – the sales views must be created for the shipping plant and sales area
No shipping point is assigned to the shipping plant in Enterprise Structure customizing (Enterprise Structure> Assignment> Logistics Execution> Assign shipping point to plant).
The shipping point may not be properly maintained in Shipping Point Determination – the entry must be maintained for the storage condition and loading group combination of the shipping plant that is proposed for the STO.

2843362 - No ATP check via Tcode VL10 with the delivery scenario STOA

You create replenishment deliveries from STO (stock transfer order) via Tcode VL10 with the delivery scenario STOA (auto delivery creation).
The ATP (availability check) was not executed and the delivery could be created even if there is no stock available.

The reason of this behaviour is the code which was added by the SAP note:1245447.

The availability check is deactivated for the automatic creation of deliveries for technical reasons. Since the delivery is created immediately after you save the purchase order, the system may call the ATP check in APO before APO receives information about the purchase order on which the delivery is based. As a result, an error occurs and the delivery cannot be created.

If you use automatic creation for a replenishment delivery, you must therefore ensure that the ATP check in the purchase order already covers the relevant areas.
Or please use other scenario for the delivery creation and not STOA. The scenarios can be seen in the main screen of the Tcode VL10X if you push the button F4.

1777808 - One stock transfer order item is separated into several delivery items

It's not possible to combine all the schedule lines into one delivery item with list type '1'. To combine all the schedule lines into one delivery item, the only option is to use list type '2' (item list) in user role setting. With proper user role setting (e.g. with tcode VL10D), all the schedule lines will be combined into one delivery item.

2810822 - Inbound Delivery is not created automatically in two step stock transfer process with STO

Error 1:

Note: Log not from current processing run VN 112
Processing log for program /SPE/STO_ID_PROCESSING routine STO_ID_CREATION VN 56
No goods receiving point for the combination of plant <plant number> and stor.loc. <storage location> VL 377
No inbound delivery created for the replenishment delivery <delivery number.> /SPE/STO_HANDLING 2

or

Error 2:

Note: Log not from current processing run
Processing log for program /SPE/STO_ID_PROCESSING routine STO_ID_CREATION
No item category exists (Table T184L ECR CHSP ) VL320
Enter a material or an item category VL383
No inbound delivery created for the replenishment delivery <delivery number.> /SPE/STO_HANDLING 2

or

Error 3:

Processing log for program /SPE/STO_ID_PROCESSING routine STO_ID_CREATION VN 56

Error during copy of partner: Partner role VN VL 864

Error during copy of partner: Partner role VN VL 864

Error during copy of partner: Partner role VN VL 864

No inbound delivery created for the replenishment delivery & /SPE/STO_HANDLING 2

2908161 - New scheduling for replenishment deliveries from STO

You are creating replenishment delivery against STOs and you notice a new scheduling is execute to determine new planning and delivery dates. You just want to copy the delivery dates from STO directly to the delivery without a new determination of dates.
This is happening even if you deactive the flag 'rescheduling' for the Delivery Type via transaction 0VLK.

There is an important difference between creating an outbound delivery for sales documents and creating a replenishment delivery for STOs. In case of sales documents, if field V_TVLK-NEUTE (transaction 0VLK) is blank, the system will only copy the scheduling dates from the sales order into the delivery, so there will not be a new scheduling.

If you create a delivery for an STO the system will perform a new scheduling, even if field V_TVLK-NEUTE (transaction 0VLK) is set to blank.

In case of STOs there is no such functionality. When a delivery is created, the delivery creation date from the STO is used exclusively for the selection. The system transfers only the delivery date to the delivery (EKET-EINDT). The system redetermines all other dates using backward scheduling (and after this, if required, forward scheduling). In this case, you do not have the option to simply transfer all dates instead of rescheduling them, as you can do in the sales order.

2408523 - Outbound delivery not appearing in MD04

The delivery will be shown in the requirement list only when the item category is linked to a requirement type and the LIPS-BEDAR_LF field is filled for the delivery.

Maintain the customization in the following path:

IMG -> Sales & Distribution -> Basic Functions -> Availability Check and Transfer of Requirement -> Transfer of Requirements -> Determination of Requirement types Using Transactions -> Define the requirement Type for the Delivery item category and MRP type.

2481964 - Complete delivery for STO not working in every case

Within standard system it is not possible maintain 'complete delivery' indicator on the stock transfer purchase order header.

According to attached note 842829, it is not possible to customize the PO in a way that only one delivery is created with the full quantity.
The only indicator for PO is the EKPO-KZTLF and this can only control that only one partial delivery is created but never take the quantity
into consideration.

As of release 4.0A, there is a logic that permits to interpret KNVV-KZTLF for stock transport orders as well (cf. EKPO-KZTLF), but only
for three fixed values:

' ' : partial deliveries allowed
'A' : only one delivery (quantity <> 0)
'B' : only one delivery (quantity may be 0 too)

In case of 'A' or 'B' the purchase order item will be closed after creating one delivery item of it (complete delivery indicator EKPO-EGLKZ is set also). It does not work for value "C" (see note 842829, symptom 1).

Please note: The corrections from Note 2131601 - Indicator for complete delivery in the purchase order pertain only to the scenario of normal PO's and are not intended for the STO scenario. Further to this, the product will not support Complete Delivery functionality in the case of an STO scenario.

498143 - FAQ: Stock transfer with delivery in purchasing

1. Question:

Why is it not possible to change the shipping data in the purchase order or scheduling agreement?

Answer:

For Release R/3 Enterprise, this was implemented for EnjoySAP transactions ME21N/ME22N and was not supported previously (ME22, ME32L). Furthermore, the delivery data fields VSBED, VSTEL, LFART, ROUTE, LPRIO have been grouped together. This means that you can only protect all of these fields or decide to change all of these fields together. This can be implemented in a 4.6B/4.6C customer system as part of remote consulting. See also SAP Note 769579.

Alternatively, you can define the shipping data by modifying the standard release; for more information, see Note 303453.

------------------------------------------------------------------------

2. Question:

How is the delivery creation date determined?

Answer:

As of Release 4.5A, you can activate shipment scheduling and the route schedule. (IMG for purchasing under Purchase Order --> Set Up Stock Transfer Order --> Assign delivery type/checking rule). See also Notes 120481, 146829 and 197221. Notes 374424, 451320 and 453127 are relevant for transactions ME21N and ME22N. Otherwise, the system calculates the delivery creation date from the delivery schedule date - planned delivery time of the item, taking the plant calendar into account.

------------------------------------------------------------------------

3. Question:

The purchase order is not in the delivery due list (transaction VL04, VL10B), or the message "Not possible to determine shipping data for material &" is displayed in the purchase order.

Answer:

If no shipping data can be determined in the purchase order, check the necessary settings as described under points 1 to 6 above. The purchase order is not in the delivery due list (table VETVG) if no item is relevant for delivery (that is, with no shipping data) or is deleted (LOEKZ), or has the "Delivery completed" indicator (ELIKZ) or is finally delivered (EGLKZ) or blocked or completely delivered.

No error message is displayed and you cannot create a delivery. Check if you set the KZUBEBE indicator in the 'Shipping parameters at client-level' (transaction 0SHP). This ensures that a delivery can only be created using the confirmed quantity. If the purchasing document does not contain a confirmed quantity, no delivery can be created.

If the purchase order is not included in the delivery due list, although it should be, search for notes with the terms VETVG or EGLKZ or EKPV.

------------------------------------------------------------------------

4. Question:

While processing a stock transport order, a termination occurs when accessing the VETVG table. Why?

Answer:

You can use the report contained in SAP Note 61148 to correct the table VETVG. For information about the cause, see SAP Notes 381114, 302375, and 61148 or search using the keyword VETVG.

------------------------------------------------------------------------

5. Question:

The stock transport order display in transaction MD04 is incorrect. Why is the document relevant to MRP/not relevant to MRP?

Answer:

Search for notes on this topic using the keyword EKUB, there can be various reasons for this problem. The first version of the report from Note 128399, which deletes unnecessary EKUB entries for performance reasons, may delete too many entries. The EKUB can be restored again using the report from Note 369732. Also refer to Notes 146979 and 328832.

-----------------------------------------------------------------------

6. Question:

In which situation (intra-company or cross-company) can you use which document type? What logic is used in inventory management when posting the goods issue/goods receipt?

Answer:

For intra-company events, supplying plant and receiving plant in the same company code, you have to use a stock transfer document type. That is, the BSAKZ control indicator is set to "T" for the document type in Customizing (this is document type UB in the standard system). The posting logic in inventory management is always that of the internal stock transfer, this means there is a stock in transit (not only arithmetical) and the value transfer occurs during the goods issue.

For cross-company code events, supplying plant and receiving plant in different company codes, you can use both a document type with BSAKZ = 'T' and also BSAKZ = ' '. Then control indicator BSAKZ defines the posting logic in inventory management.

------------------------------------------------------------------------

7. Question:

What is the process for stock transfer returns (store returns)?

Answer:

The supplying plant and receiving plant entities are not swapped. The scheduling runs as for non-return items. For a detailed description, refer to Note 430074.

------------------------------------------------------------------------

8. Question:

In internal stock transfers, why is the valuation type set as a required entry field for a material valuated separately?

Answer:

The value transfer is executed during the goods issue and therefore the valuation type must be known. Refer to Note 66953 for a detailed description.

------------------------------------------------------------------------

9. Question:

You change the shipping data in an EnjoySAP purchase order (possibly implemented as of Release 4.70 or during a customer project for 4.6B/4.6C). Why does the system not determine the route automatically?

Answer:

In the R/3 standard release, the system does not determine the route again if the shipping data is changed. Only a check is carried out. This is because SAP provides a more flexible solution with the "ME_PROCESS_PO_CUST" BAdI.

Customers can adjust the shipping data individually to meet their requirements in the PROCESS_ITEM method.

------------------------------------------------------------------------

10. Question:

You create a stock transport order in Release 4.70 or higher. The shipping data tab page is not displayed even though it should be. Why?

Answer:

There is an incomplete entry for the plant or the storage location in the shipping point determination. Incomplete means that you maintained the entry "shipping condition, loading group and supplying plant" or "shipping condition, loading group, supplying plant and storage location" but did not assign default shipping points to these combinations. For the function that changes the shipping data to work, a valid shipping point must be determined automatically by the system. A free entry without automatic determination is not provided for due to technical restrictions. Delete the incomplete entry or enter a shipping point.

2531733 - Multiple Deliveries created for STO exceed committed quantity

You deliver 30 as per the STO delivery quantity. When you deliver the next 30, the system is unaware of the previous Replenishment delivery and allows the user to deliver another 30, bringing the overall delivery quantity to 60. 30 more than is in the STO scheduled quantity
The following options can be considered:

Note 548914 as this provides a modification option to ensure that an error is received at GR
Use USEREXIT_PREPARE_FIELDCATALOG (called from SAPLV50R_VIEW / Form FELDKATALOG_AUFBAUEN) to the KUMNG field to not be editable. This would ensure that the user would never be able to change this particular field and therefore would not be able to 'over' deliver the order
Use one of the delivery user exits during the delivery processing to implement a custom logic that checks the quantity, see Note 415716

842829 - Characteristics of replenishment deliveries from STOs

In the standard SAP system, the creation of outbound deliveries was initially designed and developed from the point of view of sales orders. The option to generate replenishment deliveries from stock transport orders (STOs) was added later.

It is more limited than the sales order-specific functions.

In replenishment deliveries, the system does not read the purchase order (PO) history. Furthermore, you do not know which other replenishment deliveries exist for the same underlying STO and STO item, or what quantity they contain. Therefore, there is no equivalent for open order quantities (LIPSD-OFMNG) in deliveries for sales orders. As a result, the following fields are not transferred because they are irrelevant, and the following functions are not developed for replenishment deliveries:

Underdelivery tolerance and overdelivery tolerance, UEBTO, UNTTO, UEBTK, TVLP-UEBPR
Complete delivery AUTLF and the number of partial deliveries ANTLF
KZTLF is active only for the characteristic values A and B.

The system does not transfer the partner data from the STO to the replenishment delivery. This particularly applies to the forwarding agent.

The replenishment delivery uses only the customer of the receiving plant (EKPO-WERKS) as a partner.
In the replenishment delivery, this customer (EKPV-KUNNR) is the direct goods recipient. The customer is not the sold-to party or a general debtor, for whom the system would determine a (different) goods recipient using the customer master in the replenishment delivery.
If the PO header contains a vendor, you can use a modification to transfer the vendor as a partner to the replenishment delivery, if required. However, this is not the standard system behavior. There is no known modification for transferring the forwarding agent.

In deliveries for sales orders, the system carries out intercompany billing between the sales area of the issuing plant and the customer of the sales organization (=customer for intercompany billing). Similarly, the system carries out intercompany billing for the STO between the sales area of the issuing plant and the customer of the receiving plant (=customer for intercompany billing). In the standard SAP system, this customer (LIKP-KUNIV) is always the same as the goods recipient for replenishment deliveries.
The order unit is directly transferred as a sales unit to the replenishment delivery. Other sales units (for example, from the material master) are irrelevant. Automatic rounding to full units or to minimum delivery quantities (MINLF) is also irrelevant.
The delivery creation date (LEDAT) is usually calculated using the delivery date (LFDAT) minus the planned delivery time (or the working day before it).

In the STO, you can activate shipment scheduling instead, which determines the following dates for each PO schedule line:

Material availability date and material availability time
Loading date and loading time
Transportation planning date and transportation planning time
Goods issue date and goods issue time

In this case, the delivery creation date is the minimum of the material availability date and the transportation planning date. Shipment scheduling was added to the STO for two reasons:

To give you the option to make a selection using a delivery creation date that corresponds to SD scheduling in transaction VL10* or VL04.
To enable you to determine a route schedule in the STO. However, the system takes the route schedule into account when the replenishment delivery is created, only if the delivery date is not in the past.

When a delivery is created, the delivery creation date from the STO is used exclusively for the selection. The system transfers only the delivery date to the delivery (EKET-EINDT). In this case, EKET-EINDT is the planned(!) delivery date of the purchase order. However, the delivery requires a realistic "actual" delivery date from the outset, irrespective of any rescheduling settings. Therefore, all selected overdue schedule lines for a purchase order item are grouped into one purchase order item on a quantity basis and the delivery date for this item is set to the current date. All other schedule lines are each assigned their own delivery item. During the creation process, the system redetermines all other dates using backward scheduling (with subsequent forward scheduling, if required). In this case you do not have the option to transfer all dates unchanged instead of rescheduling them, as you can do in the sales order.
In STOs (as in sales orders), the system determines the routes weight-independently. For this, the system uses only the customer master of the goods recipient to determine the transportation zone that is required for determining the route; the standard SAP system never uses the delivery address of a PO item.
The system does not transfer fragments of delivery addresses (for example, street names) from STOs to replenishment deliveries. In transactions VL10* and VL04, the formal logic for transferring delivery addresses from STOs (or plant returns or vendor returns) to replenishment deliveries (or returns deliveries) is as follows:a) Take the address from EKPO-ADRNR. If this field is empty,b) Take the address from EKPO-ADRN2. If this field is empty,c) Take the address from the vendor master for EKPO-EMLIF. If this field is empty,d) Take the address from the customer master for EKPO-KUNNR. If this field is empty,e) Take the address from the goods recipient EKPV-KUNNR.
There are no delivery blocks that would prevent the creation of replenishment deliveries in a way that would prevent the selection of the corresponding worklist in VL10*. You can use the release strategy logic for POs instead.
When the delivery header and delivery items are created in replenishment deliveries, the system runs the usual copy routines only (FV50C301 and FV50C302 in the standard system). Unlike for sales orders, the system does not run any requirement routines.
You cannot select products with STOs.
Only the bill of material (BOM) for empties from SAP Retail is supported when you create replenishment deliveries from STOs.
When you use transaction VL10* or VL04 to create deliveries, the system uses the shipping due date index (VETVG) instead of the shipping due date index for the sales order (VEPVG). Out of the nine key fields, the standard SAP system never fills the fields for the forwarding agent (SPDNR) and the goods issue date (WADAT). If the other fields (shipping point, delivery priority, route, goods recipient, PO number) are the same for several PO items of a PO, the system enters only one value for the index VETVG for these items, which contains the earliest of all delivery creation dates. You can only use transaction VL10* or Vl04 to select one of these items if the delivery creation date that is specified as a selection criterion is in line with the delivery creation date of the relevant PO schedule line, and with the delivery creation date of its corresponding VETVG index.
You cannot create a replenishment delivery individually from a STO in the way you can for sales orders using transaction VL01 or VL01N. In addition, you cannot add further PO items to an existing replenishment delivery in dialog mode.
In SD billing documents, the transfer of conditions from preceding documents was developed for sales orders. However, you can configure the control ("price source") to enable you to transfer conditions that have the same name from STOs to billing documents that relate to replenishment deliveries.
In the document flow for replenishment deliveries (VBFA), the system creates the entry for the STO dynamically when it displays the document flow, instead of storing it in the database. For this, the system uses only the tables for the delivery to extract the data that corresponds to the PO; it does not use the PO itself. As a result, the creation date that is connected to the delivery in the document flow is the creation date of the first replenishment delivery item, and not the creation date of the delivery (because this is not known).

303453 - User exits for shipping data determination in STO

Two form routines are proposed as user exits.

Implement the attached modification with the corresponding calls in the function module SD_TRANSFERDATA_DETERMINE.

Do not implement the modification in the include MM06EFPV_PTV_FUELLEN unless you also want the results of the user exits to be taken into account in change mode. Otherwise, these results may cause overlapping with manual changes that were carried out at the same time for the relevant shipping data.

First, define the form routines in connection with the form routines in the include LV50NF01 or in a user-defined include LV50NFZZ, for example.

Then regenerate SAPLV50N.

1. Form zz_sales_area_determine:

In this routine, you can change the sales area that is used for delivering. Check if Note 170082 is sufficient for your purposes. For consistency reasons, set the sales area as fixed or determine it only depending on

the following parameters:

Issuing plant (LLWERK)

Goods recipient (LKUNWE).

The sales area determined up to now is in the following fields:

Sales organization (LVKORG)

Distribution channel (LVTWEG)

Division (LSPART)

If required, reset these fields with the sales area that you have determined.

Note that an entry exists in the distribution chain plant assignment (table TVKWZ) for the distribution chain that have you set and the issuing plant.

In addition, note that a corresponding customer master segment (table KNVV) is defined for the sales area.

2. Form zz_shipping_data_determine:

You can change various shipping data in this routine:

Delivery priority (FEKPV-LPRIO)

Shipping point (FEKPV-VSTEL)

Route (FEKPV-ROUTE)

Shipping condition (FEKPV-VSBED)

depending on the following parameters:

Issuing plant (LLWERK)

Goods recipient (LKUNWE)

Material (LMATNR)

Fields of the internal table FEKPV.

In particular, note that by changing the shipping condition, no new standard shipping point determination can be started, and changing the shipping point does not result in a new standard route determination. The values are hard-coded, as is normal in user exits.

In addition, ensure that the shipping data you have set is consistent throughout so that no errors occur when you generate deliveries. In particular, this affects the shipping point plant assignment (table TVSWZ) and the shipping point determination or manual assignment (table TVSTZ).

1119073 - FAQ: Automatic inbound delivery creation for stock transfers

1. What is the purpose of automatic inbound delivery creation for stock transfers?

Answer: If you use stock transfers according to the two-step procedure, you must post the goods receipt separately in the receiving plant after posting the goods issue of the replenishment delivery from the delivering plant. In the standard process, you use a goods receipt transaction of inventory management for this posting (for example, transaction MIGO "Goods Receipt for Replenishment Delivery"). However, replenishment delivery data is ignored in goods receipt posting using inventory management, for example:

Quantities
Serial numbers
Batches
Handling units (HUs)

Automatic inbound delivery creation is mandatory if the receiving plant is managed using a decentralized Warehouse Management system (WMS) or an Extended Warehouse Management (EWM) system; in this case, the inbound delivery is required as a communication document for the decentralized system. Automatic inbound delivery creation is also required if Handling Unit Management (HUM) is activated for the receiving storage location. In this case, the inbound delivery serves as a reference document for the HUs that are transferred by the preceding replenishment delivery.

2. What is the process flow of the stock transfer process like when you use automatic inbound delivery creation?

Answer:The stock transport order and the subsequent outbound delivery are created and processed using standard transactions. The outbound delivery is picked, packed as and when required and then goods issued posted. An output condition works in goods issue posting and ensures that the special output SPED is added to the header outputs of the delivery. The output SPED generates the inbound delivery during processing in the background. Processing can take place either using immediate processing or using reports for output issue.

You then carry out putaway and goods receipt posting using the inbound delivery.

If the receiving plant is managed using a decentralized Warehouse Management system or an Extended Warehouse Management system, after creation, the inbound delivery is automatically distributed to this system. Putaway and goods receipt posting then take place in the decentralized system.

The inbound delivery is updated in the document flow of the outbound delivery. In addition, the external delivery number of the inbound delivery (LIFEX) refers to the outbound delivery. Therefore, you can use the search help "E: External delivery number of vendor" in transaction VL32N or VL33N to determine the inbound delivery belonging to the outbound delivery if you know the outbound delivery number. Add the prefix "*" to the delivery number to ignore potential leading zeros of the outbound delivery number during the search.

3. When is the function "Automatic inbound delivery creation for stock transfers" available (as of which release)?

Answer: You can use the function as of ERP Release 6.00 in the standard system. If you use an ERP release lower than 6.00, a consulting solution is available for the automation of inbound delivery creation (see Note 497287).

4. What data is copied to the automatically created inbound delivery?

Answer: The automatically created inbound delivery is based on outbound delivery data and the underlying stock transport order. Therefore, it receives a purchase order reference; however, it copies the data relevant for logistical processing from the outbound delivery, in particular

Materials
Quantities
Batches and batch splits
Serial numbers
Handling units (HUs)
Header and item texts

If a receiving storage location is specified in the stock transport order, it is transferred to the inbound delivery. If it is not specified, the receiving storage location is determined according to the standard storage location determination rules.

5. How is the function set up?

Answer: See Note 965176 for a detailed description about the steps required to set up the function. Using the procedure described in Note 1095322, you can delay automatic inbound delivery creation and make it dependent on the planned delivery date in the receiving plant.

6. How can inbound delivery creation be controlled depending on certain criteria?

Answer: Since inbound delivery creation is triggered using a delivery output, you can use the output determination options to control inbound delivery creation based on specific criteria. In the standard system, the delivery type is used to control whether the output SPED is relevant; however, you can use any other criteria using the condition technique. For example, you can change the access sequence in the definition of the output type SPED. If inbound delivery creation depends on complex criteria, you can also use your own condition routine. In this case, use standard condition routine 408 (include LV61B408) for the template. For more information about the configuration of output determination, call transaction SPRO and go to "Logistics Execution" -> "Shipping" -> "Basic Shipping Functions" -> "Output Control". If you want to influence the time of inbound delivery creation, proceed as described in Note 1095322.

7. What must be noted if handling units (HUs) are used?

Answer: If there are HUs in the outbound delivery for the stock transport order, these can pass over to the subsequent inbound delivery during the goods issue. However, the HUss are only transferred from the outbound delivery if either the lean HU status update or unique number assignment are active for HUs. You can find the relevant settings in the Implementation Guide under "Logistics Execution -> Service Parts Management (SPM) -> Cross-Process Settings -> Handling Unit Management -> Set Lean HU Status Update in Non-unique HU Numbering Scenario". You should only activate unique numbering if you want to use HUM, otherwise you should use lean HU status update. If lean HU status update is active, the status and the history of the handling units are updated, but there is no check to see if the HU number is unique.

If you use cross-delivery HUs (as they can be created in EWM), they can also be transferred from the outbound delivery to the inbound delivery if the receiving warehouse is also managed by an EWM system. Note however that this process does not work if you have activated unique number assignment for HUs. You cannot use both HUM and cross-delivery HUs in ERP.

When you use batch splits with handling units, note that HUs can only be reassigned from the outbound delivery to the inbound delivery when the batch split items are themselves packed. You cannot use the "Pack accumulated batches / movement type item" indicator (TVLP-CHHPV) in the item category of the delivery together with the two-step transfer scenario via the output SPED. In this case, the system displays error message HUFUNCTIONS191 "Handling unit &1 is already assigned to outbound delivery &2" when you create the inbound delivery.

8. How do you know which inbound delivery was created by the system?

Answer: The inbound delivery created appears in the document flow of the outbound delivery. In the inbound delivery, you recognize the assigned outbound delivery by the external delivery number that corresponds to the number of the outbound delivery You find this information in the inbound delivery dialog (transaction VL33N) on the tab page "Header" -> "Administration".

9. What must you check if the inbound delivery was not created automatically?

Answer: First check whether the inbound delivery exists by displaying the document flow of the replenishment delivery. If the inbound delivery does not exist, check the assignment of the output SPED to the header outputs of the outbound delivery (menu: "Extras" -> "Delivery Output" -> "Header").

If the output does not appear there, the condition record is usually missing. Therefore, use transaction VV22 to check whether a condition record exists for the condition SPED and the delivery type of the outbound delivery. Create the missing condition record if required. As an exception, you can also assign the output SPED to the outbound delivery and save the delivery. The output is then either processed immediately according to the default settings of the output type SPED or it can be processed using standard reports, for example, using transaction VL71.

If the system rejects the manual assignment of the output SPED for the outbound delivery, assign the appropriate output determination procedure to the delivery type as described in Note 965176.

If the output appears but is still unprocessed (yellow traffic light), you can start processing using a standard report a standard report, for example, using the report RSNAST00 or transaction VL71.

If the output appears and is incorrect (red traffic light), you can release the processing log of output processing for error analysis. You can use transaction VL71 for output postprocessing (processing mode 3).

10. What must you do if the inbound delivery created cannot be goods receipt posted?

Answer: If the goods receipt for the inbound delivery cannot be posted, the appropriate confirmation control key is usually missing in the stock transport order. Therefore, check whether a confirmation control key was assigned to the items of the stock transport order (item tab page "Confirmations" in transaction ME23N). Make sure that the goods receipt relevance and goods receipt assignment are activated for the chosen confirmation control key. The corresponding settings are available in the Implementation Guide (IMG) under "Materials Management" -> "Purchasing" -> "Basic Functions" -> "Confirmations" -> "Set Up Confirmation Control".

11. Can you create the inbound delivery manually with regard to the stock transport order?

Answer: You can use a procedure described in Notes 421276 and 490865 to manually create the inbound delivery with regard to the stock transport order. You can continue to use this procedure but it is not advised since a whole host of restrictions occur as a result, particularly due to the missing data transfer from the outbound delivery. For detailed information about these restrictions, see the notes mentioned above.

If the inbound delivery for the stock transport order was not created using message control and a subsequent creation is required, you can implement the report Z_IBDLV_CREATE_FROM_OBDLV from the correction instructions in your system and execute it. The report requires you to enter the outbound delivery number and generates the inbound delivery if the corresponding prerequisites exist. A log is output in the case of errors.

12. Can you delete the automatically created inbound delivery again?

Answer: You can delete the automatically created inbound delivery again after you have deleted the HUs of the inbound delivery or the assignment of the HUs for the inbound delivery. Note 1083602 is a prerequisite if you want to reassign the HUs to the outbound delivery in this step to facilitate the regeneration of the inbound delivery or the goods issue reversal of the outbound delivery. Support Packages SAPKH60011 and SAPKH60201 contain the corrections from Note 1083602 or they are found as standard in SAP_APPL 6.03 (ERP 6.00 with Enhancement Package 3).

13. How can you reverse the goods issue of a replenishment delivery if an inbound delivery was already created for it?

Answer: Before the goods issue of the replenishment delivery can be reversed, the subsequent inbound delivery must first be deleted. Note 1083602 describes the required procedure, particularly if you are using HUM.

If you use an Extended Warehouse Management system (EWM) in the delivering and receiving plant, you can use the delivery output SPER to automatically request the deletion of the inbound delivery. In this case, no further manual steps are required. The output SPER must be assigned to the output determination procedure of the delivery along with condition routine 409.

14. Can you create the inbound delivery for the outbound delivery repeatedly?

Answer: Usually, it is not useful to create the inbound delivery repeatedly since, for example, the HUs and the serial numbers from the outbound delivery can only be passed on to one inbound delivery. In addition, the stock in transit created during the goods issue for the replenishment delivery can be goods receipt posted only once. However, as an exception, you can create another inbound delivery by carrying out repeat processing of the output SPED after you delete the outbound delivery created previously or set the quantities of this outbound delivery to zero. The report

Z_IBDLV_CREATE_FROM_OBDLV

also enables you to create another inbound delivery. In this case, the prerequisites are not checked.

Before you create another inbound delivery, you must check whether the inbound delivery exists using the document flow of the outbound delivery or by searching for the inbound delivery using the outbound delivery number as an external delivery identification. Note 1312812 provides additional information.

15. Which restrictions apply if, instead of the outbound delivery message SPED, the shipping notification IDoc DESADV is used to create the inbound delivery?

Answer: If you use the shipping notification IDoc DESADV to transfer the outbound delivery information to the receiving warehouse, you cannot use cross-delivery handling units in this process. Neither outbound processing and inbound processing of the IDoc nor the message itself (basis type DELVRY03 or higher) are prepared for the transfer of the corresponding HU attributes.

1688902 - 2 Step STO Returns with Handling Units

You process 2-Step replenishment stock transfers involving handling units.
For some reason it is necessary to return the material and handling units back to the issuing plant.

Processing Store Returns with deliveries in both steps is somehow tricky especially in releases before 604 (Enhancement Pack 4)

OPTION 1:

Create a new 2Step STO purchase order where the issuing and receiving plant are swapped. Process as usual.

OPTION 2:

Create a Purchase order with same characteristics as the original purchase order but flag the item(s) as 'Return'.

To obtain a delivery for the 161 goods movement which is the 1st Step outbound delivery you need to trick a little:

Use transaction MIGO to make a GR (!) for the purchase order returns item(s)

Check whether the storage location under the 'where' tabstrip is a handling unit requiring one (HUM).

Should this be a nonHUM storage location do not save but change it to a handling unit requirering storage location (HUM) where MIGO always will create a delivery

Do not forget to flag the 'Item(s) OK'.

Press SAVE and the delivery will be created.

In the so created delivery you will need to set the storage location value back to the one initially obtained out of the purchase order. Do this using the standard delivery transactions (ex. Vl02n).

You can now process the first returns step for the handling units by processing this delivery as ususal.

Create the delivery for the second step based on your purchase order using VL04 or VL10B.

Process this delivery as usual. (you might reuse the HUs from the first step delivery when handling unit management is active (unique EXIDV))

REMARK:

SPED is not supported for the 2 step returns process in releases before 604 (EHP4).

Both options suggested before might also be used in higher releases.

OPTION 3:

Starting from Enhancement Pack 604 ARM became available which provides another option - please find in the release notes for EHP4 the documentation on how to set up store returns (not to be mixed up with full ARM) with inbound & outbound deliveries: http://help.sap.com/erp2005_ehp_04/helpdata/en/a5/52015ed0ea4d19a1ef0ae36f1b34e6/frameset.htm

PREREQUISITES for using option 2 & 3:

The delivery item type must allow packing (default delivered customizing for returns items disallows)

Customizing path: LE-shipping-deliveries-define item categories for deliveries.

Set one of the following values for parameter packing control:

- blank = can be packed

- 'A' = MUST be packed

RESTRICTIONS:

For the SIT scenario involving handling units option 1 is supported.

Please see notes 1822497 & 1842901 for further details about the SIT process and restrictions with regard to handling units.