Inbound Delivery: Inbound WHSCON IDoc with Batch Split - HowTo...?

[Former Member]

Hello

We have another tricky problem to solve on our ERP 6.0 system.

My colleagues of Lindt UK create manually inbound deliveries (VL33N) which are replicated to the warehouse (DESADV IDoc -> TRADACOMS.ORDHDR).

When the goods arrive at the warehouse they send back a good receipts message (TRADACOMS.DLCHDR -> WHSCON IDoc).

In some cases we have a batch split because the goods have been put into different storage locations. Example:

- item 10: 200 Cases of product 4711, batch 10-2011, in storage location '0001' (free available for Sale)

- item 10: 5 Cases of product 4711, batch 10-2011, in storage location '0004' (damaged)

I am aware that in the inbound WHSCON item 10 is a main position and the two actual batch split positions are sub-items (900001 & 900002 with HIPOS = '10'). I tried to used E1EDL19-QUALF = 'BAS' (= batch split) with the sub-items but failed so far to update the inbound delivery that I can see the batch split.

I have managed to get one sub-item but not 2 of them. Somehow the system aggregates the quantities for both sub-items into the single item that shows up in the inbound delivery.

When we send the inbound delivery to the warehouse the item looks like this:

- item 10: 200 Cases (no batch yet, Putaway quantity = 0, because these data are coming from the warehouse).

QUESTION: Has anybody else been faced with a similar (if not identical) problem and how did you solve it?

Thanks a lot in advance for your valuable input.

Regards

Uwe

[uwe_schieferstein]

Hello

I have debugged the fm IDOC_INPUT_DELVRY which processes the inbound WHSCON IDoc in our system.

Although the IDoc contains different storage locations ( E1EDL24-LGORT ) for the same batch these locations are basically ignored during processing.

Using the Online help [Delivery Interface|http://help.sap.com/saphelp_crm40/helpdata/en/e2/654b15a9f411d184ec0000e81ddea0/content.htm]

I can get a batch split when I have the SAME storage location but DIFFERENT batches.

However, I would need a batch split having DIFFERENT storage locations for the SAME batch.

Whereas in the dialog transaction VL32N it is possible to make such a batch split for different storage locations it seems to me that this is not possible using the IDoc.

Regards

Uwe

[Former Member]

Hi Uwe,

I am wondering did you ever solve this problem. We have the same requirement and unable to get it to work.

Our deliveries are sent to an external system. No batch splits are done initially in our system as the external system will tell us what batches to pick. We are using WHSCON to try an update the delivery to create the batch split lines but so far we have failed.

We are populating as follows:

In E1EDL24

POSNR 900001

MATNR AA303858

MATWA AA303858

ARKTX JS CHEDDAR WHT MILD/MOZZARELLA GTD 500G

MATKL 80300

WERKS 0280

LGORT OSFG

CHARG 13041019

KDMAT 5010012225402

LFIMG 6.000

VRKME CAS

LGMNG 6.000

MEINS CAS

NTGEW 30.000

BRGEW 30.000

GEWEI KGM

HIPOS 10

HIEVW 1

LADGR 0002

TRAGR 0001

VKGRP 000

POSEX 900001

In E1EDL19

QUALF BAS

Any ideas what we are doing wrong?

Regards,

Finbarr

[uwe_schieferstein]

Hello Finbarr

I assume that you do NOT send any (suggested) batches to your warehouse. Otherwise you would have the same problem like we have that the WHSCON cannot overwrite a (suggested) batch.

However, if you just send the quantity per item then the batch split is much simpler than you suggested:

"First E1EDL24 segment:

POSNR	50
MATNR	000000000000602006
MATWA	000000000000602006
CHARG	L1519   " <<< first batch
LFIMG	37.000
VRKME	CT

"Second E1EDL24 segment:

POSNR	50
MATNR	000000000000602006
MATWA	000000000000602006
CHARG	L1880   " <<< second batch
LFIMG	37.000
VRKME	CT

Well, and as qualifier we use: E1EDL19-QUALF = 'XYZ' " a dummy

The SAP system is smart enough the realize that these two E1EDL24 segment belong to the same item yet have different batches and, therefore, yield a batch split in the delivery. The system generated the 9xxxxx numbers for this sub-item lines automatically.

Although I believe that it is not possible to change a batch in the delivery using an inbound WHSCON I would appreciate to have a final proof of this assumption. I could imagine that if you first delete the item containing the suggested batch and then add a new item with the actual batch from the warehouse it might works. However, this would require to implement a user-exit which I do not prefer.

Regards

Uwe

PS: It seems I gave an answer to the wrong question (should be )

[Former Member]

Hi Uwe,

Thank you for your relpy. We achieved the batch split by populating the following

E1EDL19-QUALF = 'BAS', E1EDL19-QUALF = 'PIC' and setting E1EDL18-QUALF to be 'CHA'. It is doing the batch split correctly for us.

Just wondering, have to worked with Handling units? We have the issue now, where along with the batch split, we need to pack the delivery. The idoc contains the handling units that were picked, but the idoc fails with the error message:

"There is already a handling unit 150002460000009708 posted for GR without stock

Message no. HUSELECT005

Diagnosis

Handling unit 150002460000009708 already exists in the system with the status 'Posted for GI without stock information (at a non-HU storage location)'.

Procedure

Check whether the existing handling unit can be deleted or assign a new number to the current handling unit to ensure that both handling units can be clearly identified."

Have you seen this before?

Thanks,

Finbarr

[Former Member]

Hi everyone,

We also need to create a batch split, and this topic has been very helpful to me.

Can anyone point me to documentation on the possible values for E1EDL19, and their meaning? - Never mind, I found the permitted values for EDI_VTDL19.

Thanks.

Edited by: Edith Maor on Jun 23, 2010 1:08 PM

[former_member753156]

Hi,

We have a similar issue, the system is giving error message when Inbound IDOC posted, saying "There is already a handling unit 20000000003017 posted for GR without stock"

Message Type: WHSCON

IDoc Type: DELVRY03

Issue: Assigning HU to Delivery

Could you please let me know if you have come across such issue before and how did you resolve the same?

Thanks,

Kumar.

[uwe_schieferstein]

Hello Kumar

We got similar error messages ("There is already a handling unit...") in the recent past. Error cause was that our supplier used the same SSCC number twice in its DESADV message. However, SSCC numbers must be unique and, therefore, the system prevented processing of the IDoc.

Regards

Uwe

[uwe_schieferstein]

Hello Finbarr

Seems that I missed to notice your answer. If I find the time I will check this out.

So far we have implemented the following solution:

(1) When the same item should be booked into 2 different storage locations, the XSLT mapping (on SAP-PI) fills POSNR with a sub-item number (9xxxxx) and HIPOS with the original item number (e.g. 000010).

(2) The inbound WHSCON fails because the sub-item numbers are missing in the inbound delivery.

(3) The users manually create the batch-split for the affected item in the inbound delivery.

(4) Reprocessing of the the failed WHSCON IDoc. A user-exit takes overwrites the sub-item numbers in the IDoc with the actual numbers in the inbound delivery.

Regards

Uwe

[former_member753156]

Hi Uwe,

Thank you very much for your reply.

With best regards,

Kumar.

[uwe_schieferstein]

Hello Finbarr

Would it be possible for you to send a few screenshots showing how the delivery before and after the inbound WHSCON IDoc processing looks like and how the IDoc looks like?

I cannot reproduce your results. You find my e-mail address at the SDN business card.

Best Regards & Happy Christmas

Uwe

[Former Member]

Hello Uwe,

We also have the same problem to split the same batch in 2 different storage locations.

Do you have a solution for this?

Thank you and regards

Chutima

[Former Member]

Hello,

See OSS note 773677.  SAP recommended to use the V55K0011 SAP enhancement in FM IDOC_INPUT_DESADV1 to copy storage location from the IDOC.

Regards

Chtuima

[sauvageot]

Hi,

I have also faced this issue today and it took me a few hours to reach a solution.

After investigation ; 
SAP is doing a collect on  batch numbers lines/POsnr despite you have tried to specify LGORT in following preparation : EXIT_SAPLV55K_002

Mostly since he does not plan to care about LGORT In standard following this EXIT.
Which means : 

SAP Is reforming a XLIPS table to prepare future LIPS insertion, right after that exit and no badi/other exit seems to exist
Here is my technical solution to avoid implicit enhancement after that analysis:

At every POSNR_VL, check if you encounter several times the same batch number as you have entered multiples lines in your WHSCON idoc using QUA and BAS qualifiers.

For every CHARG/ Batch number, that is refered more than once on a same item,  modify the batch number and give it a fictiv one in the prepared_item internal table of the exit. Store The changes in memory or use a table declared as a class-attribute for your work instance and fill it during the swap in that exit.

Implement BADI : LE_SHP_DELIVERY_UPDATE METHOD CHANGE ITEMS.
Read your table attribute with key  POSNR_VL = lips-posnr CHARG = yourfictifCHARG and retrieve the right batch Number. Swap the right Batch number with fictiv one before commit in the method listed above.

Let me know if it has helped, also let me know if i would have missed anything!

Regards

Victor Sauvageot