Can outbound delivery pick update be sent from Decentralized WM to ERP?

[andy_austin]

(I moved this thread from the ERP -Logistics Materials Management (MM) forum)

We are running batch management and DWM/ERP both on ECC 6.0

I have a request to be able to have the DWM pick information on an outbound delivery reflected as "scheduled for delivery" in the ERP system. Specifically, i need to show in the ERP system which batches have been already picked on the outbound delivery.

i've read the documentation on the "subsequent changes to distributed deliveries". The SHP_OBDLV_CHANGE idoc seems like the right method to pass the "pick quantity" and "batch" from the line item on the delivery. However, it is not part of the standard IDOC. Ultimately, i would like to see MMBE in ERP reflect the batches that have been picked on the DN in DWM.

Has anyone successfully done this?

Is what I'm proposing even possible?

[Former Member · Accepted solution]

Hey Andy

Once the delivery is picked (TO created and confirmed) in the DWM system, the delivery confirmation Idoc must trigger to update the ERP system. BAPI SHP_OBDLV_CONFIRM_DECENTRAL should update the ERP system where the PGI is posted. If the batch is changed in the ERP while the IDoc has been to DWM, there could be errors while posting the PGI since the batch number in the ERP system and DWM may not be the same. When the batch number is changed in the DWM system during the picking, we had someone to monitor those Idoc's that failed to update the ERP and had them manually edit the Idoc with the correct batch numbers before saving it. Hope this helps. Revert back if you have more questions and I will see if I am able to help you out.

Thanks

Anandha

[andy_austin · Accepted solution]

Anandha,

First off, thank you for your comments. You noted a couple of things that i still have a questions about.

1. "Once the delivery is picked (TO created and confirmed) in the DWM system, the delivery confirmation Idoc must trigger to update the ERP system. BAPI SHP_OBDLV_CONFIRM_DECENTRAL should update the ERP system where the PGI is posted."

Currently, we use the SHP_OBDLV_CONFIRM_DECENTRAL iDOC to send PGI data from DWM to ERP. Are you saying that I can trigger an "initial" update of the delivery with the "pick" information (batch split, quantity)? BAPI SHP_OBDLV_CONFIRM_DECENTRAL would be the way I would do that? Would this BAPI create an iDOC?

2. "If the batch is changed in the ERP while the IDoc has been to DWM, there could be errors while posting the PGI since the batch number in the ERP system and DWM may not be the same. When the batch number is changed in the DWM system during the picking, we had someone to monitor those Idoc's that failed to update the ERP and had them manually edit the Idoc with the correct batch numbers before saving it."

Currently, we do not allow changes to the Delivery in ERP once it has distributed to DWM. Thus, i don't think that we will have the same problems as you have had. However, in order to enable the Delivery update of pick information in #1, what would be required to allow the Delivery to be modifiable in ERP?

Thanks again,

Andy

[Former Member]

Andy

SHP_OBDLV_CONFIRM_DECENTRAL is the BAPi verification. That's what triggers the Idoc. The pick quantities will not get updated in the ERP system unless the TO is confirmed in the DWM system. May be you can consider creating a custom development but the effort will be high on the technical side.

Second, changes can we made on the Idoc segments when it tries to confirm in the ERP system. For ex: Delivery 12345 has a batch1 in ERP which gets replicated in DWM. After picking and confirmation in DWM, if the user changes the batch number from 1 to 2, the confirmation Idoc will carry the batch 2 in the one of the IDoc segments. The Idoc will fail since the batch number will not match. In those cases, try editing the IDoc segments using WE19. Once you update the correct batch number, click and inbound the Idoc, a copy of the old Idoc will get created with the changes that you manually made. You can set the old IDoc to status 68 (Error-no further processing). We had a custom program that changed the status to 68.

Thanks

Anandha