When Inbound deliveries split no quantity found to pack

Question

Hi,
My client is using the DELVRY03 Idoc to create inbound deliveries for purchases from vendors. The materials being purchased are batch managed and HU managed. Currently the set up runs without issue provided that there is no delivery split when for items with batch splits. If a delivery split occurs and the items on the second delivery have split batches then the second delivery is incorrectly copied.
Since the current configuration for the copy control does not copy the line item number that is populated on PO, the main item of the second delivery gets a new number but the batch split lines have the PO reference number populated in UECHA. So if the delivery split occurs between the first 2 main items, then the second PO item is copied to the new delivery with item 10 as the line item number  the batch sub item lines are created with a reference to line item 20 in UECHA. In this case the delivery gets created. Line 10 is packed. But there are no batch sub items for line 10. Additionally there is no line 20 but when you look at LIPS the batch sub items are all created with the line 20 reference. In short the second delivery is a mess.
I would like to change the copy control so that the line number for PO item 20 copies in to the second delivery as line item 20. Then all my batch sub items would be correctly linked. Unfortunately, when I turn on copy line number in the copy control the IDOC still fails. This time it fails with the message no quantity to be packed.
I looked at OSS notes 380657, 678464, and 682506 which were all applied in our system. In these notes it states that the second delivery can be created when batch splits occur providing that the IDOC is maintained with the correct data. This comment leads me to wonder if there is something being populated incorrectly in the IDOC. For instance, should the IDOC be populated with the actual PO item in POSNR and HIPOS or is there some form of wild card that should be used that lets the system determine the correct line numbers?
Has anyone had an experience similar to this that can provide some insight?
Thanks,
Paul

Answer 1

Steffen,
What I understand from the code:
If your stock is specified exactly (=as much as it is possible) you can pack your materials, if not, you will get error message.
If material is split valuated and not batch managed and valuation type is defined in the delivery then you won't get error message since the stock is specified as much as possible ("ls_lips-bwtar <> space" is TRUE) .
If the valuation type is not given for this material in the delivery, you will get message HUDIALOG102; "ls_lips-bwtar <> space" is FALSE)
If your material is batch managed and batch is specified then the stock is specified as much as possible (with quantity of course; ("ls_lips-charg <> space" is TRUE).
If batch is not sepcified for the same (batch managed) material, then again you will get message HUDIALOG102 (ls_lips-charg <> space is FALSE)
If material is neither batch managed nor subject to split valuation then "ls_lips-xchar <> 'X'" is TRUE and you won't get any message.
If your material is batch managed AND also split valuated, then you always specify the stock via the batch and from the batch valuation type comes. So, if batch is given for the (main) item then "ls_lips-charg <> space" is TRUE --> you won't get error message.
If you use batch split then neither batch nor valuation type are defined for the item, so all of these are false...:
ls_lips-xchar '<' '>' 'X'
ls_lips-charg '<' '>' space
ls_lips-bwtar '<' '>' space
...and system will try to read whether batch is defined for batch split items / whether batch split items exist:
      READ TABLE it_lips WITH KEY uecha = ls_lips-posnr
                         TRANSPORTING NO FIELDS.
and if there are such batch split items then it means the stock is specified and you can pack the goods.
(using serial number management we can specify the stock more exactly but from this point of view serial numbers don't play any role):
Edited by: Csaba Szommer on Aug 23, 2010 9:25 PM