Updating Picking Requests in the Delivery Document 
Updating Picking Requests in the Delivery Document
You can use the IDoc SDPIID01 to update confirmed quantities, batch splits and movement-type splits in the delivery.
The partner profile input must be maintained for the message type SDPICK for this purpose.
The IDoc SDPIID01 comprises the segments E2VPDLH (header data) and E2VPDLLI (item data). The structure of these segments is described below.
E2VPDLH
Fields |
Format |
Designation |
Req. |
Comments |
VBELN_VL |
CHAR 10 |
Delivery |
X |
|
VBELN |
CHAR 10 |
Subsequent sales and distribution document |
X |
Picking request, KOMAU field |
LGNUM |
CHAR 3 |
Warehouse number |
Function currently not implemented | |
TANUM |
NUMC N 10 |
Transfer order number |
X |
Input as for VBELN |
KODAT |
DATS D 8 |
Picking date |
||
KOUHR |
TIMS T 6 |
Entry time |
||
BRGEW |
CHAR 15 |
Gross weight |
Planned, function currently not implemented | |
NTGEW |
CHAR 15 |
Net weight |
Planned, function currently not implemented | |
GEWE |
CHAR 3 |
Unit of weight |
Planned, function currently not implemented | |
VOLUM |
CHAR 15 |
Volume |
Planned, function currently not implemented | |
VOLEH |
CHAR 3 |
Volume unit |
Planned, function currently not implemented | |
KOMUE |
CHAR 1 |
Automatically overwrite delivery quantity with picking qty |
If no further quantities for the item are reported | |
WABUC |
CHAR 1 |
Automatic goods issue |
Indicator X |
E2VPDLI
Fields |
Format |
Designation |
Req. |
Comments |
VBELN_VL |
CHAR 10 |
Delivery |
X |
|
POSNR_VL |
NUMC N 6 |
Delivery item |
X |
|
VBELN |
CHAR 10 |
Subsequent sales and distribution document |
X |
See above, input as for KOMAU |
POSNN |
NUMC N 6 |
Subsequent item of an SD document |
X |
New item for batch split |
VBTYP_N |
CHAR 1 |
Document category of subsequent document |
Input is always ‘Q’ | |
PIKMG |
CHAR 15 |
Picked quantity |
X |
|
MEINS |
CHAR 3 |
Unit of measure |
Function currently not implemented | |
NDIFM |
CHAR 15 |
Difference quantity |
Quantity 0 allowed | |
TAQUI |
CHAR 1 |
Confirmation |
Is always confirmed | |
BRGEW |
CHAR 15 |
Gross weight |
Function currently not implemented | |
NTGEW |
CHAR 15 |
Net weight |
Function currently not implemented | |
GEWEI |
CHAR 3 |
Unit of weight |
Function currently not implemented | |
VOLUM |
CHAR 15 |
Volume |
Function currently not implemented | |
VOLEH |
CHAR 3 |
Volume unit |
Function currently not implemented | |
CHARG |
CHAR 10 |
Batch number |
||
MATNR |
CHAR 18 |
Material number |
X |
For testing purposes |
ORPOS |
NUMC N 6 |
OR item from which the current OR item originates |
See example |
The verification notice must always refer to a pick order that was sent to an external system (via the field KOMAU in segment E2VPPIH). That way, no new item number is issued for the pick order since it is the same as the item number in the delivery. The fields POSNN and POSNR VL are in agreement if this is processed without splitting the item. On the other hand, if several records are verified for one item (for example, due to a batch split) the records in field POSNN must contain a new item number. In this case, the field ORPOS contains a reference to the old item number, that is, to the contents POSNR VL.
The field NDIFM displays the quantity that cannot be picked. The field is only analyzed if items are split (fields POSNN and ORPOS)(see the example below). If no new items are verified, the difference between the requested and verified quantities are automatically calculated. If there are items in the delivery that have been fully supplied after verification has taken place, the system creates a new picking message. When the new message is processed, the system creates a new pick order. If you do not want this to happen, you must indicate this in the header field KOMUE. By doing this, the delivery quantities in all items are adjusted to match the picking quantities. If there is an open picking message, it is deleted.
The reaction to the fields XCHPF and XCHAR in the picking request is as follows: If the indicator XCHPF is set, then the material requires batch handling and the external system must send the batch in the field CHARG of the item when the data is being verified. Here a particular batch can already be preset in the picking request. Otherwise, the batch determination must take place in the external system. If the indicator XCHAR is set, then this is not a request batch but a special valuation type. Then the valuation type must be supplied in the field CHARG.