Make Outbound Deliveries Editable again with external Warehouse

[Jack_Johnson]

Hello everyone,

In our current implementation project with our customer, we have found that in some cases the delivery that has already been distributed has to be changed.

It is an outbound delivery that was created using a normal sales order. The delivery is sent to the external warehouse system and in the S / 4HANA Cloud we only receive the confirmation of the the GI. (Scope Item 1ZQ)

The picking etc. takes place in the external warehouse system. Usually this process works fine and no action is required. But sometimes we have to change the delivery after it's been distributed. The root cause can be deverse but in our case it is really time critical.

It is not possible in the standard system because the outbound delivery has already been distributed and is therefore blocked for editing. In the old R3 system it was possible to remove the indicator that the outbound delivery was being distributed, and then it was possible to change fields as would be possible without distributing the outbound delivery. Unfortunately there is also no way to manipulate this delivery via API or something like that.

- Have you ever processed such a request?

- Is there a solution for such a situation?

- In discussions with SAP, we were told that there is no plan to provide a possibility to make distributed deliveries changeable. Would this possibility bring advantages for your S / 4HAAN cloud system?

I would be very happy to receive feedback on whether there are solutions or whether the need for such a functionality would also be helpful for you!

Thank you in advance and best regards,

Jonas

[GeovanaLettnin]

Dear jonas.engesser,

We helped you to accept your answer. You can unaccept it anytime if the answer provided was not helpful enough and you have further questions.

Best regards,

Geovana

[Jack_Johnson · Accepted solution]

Dear All,

we got a Solution from SAP and a SSCUI will be delviered within the next HF to turn on the option to make the Outbound deliveries editable again.

Kind regards,

Jonas

[Daniel_Kesenhei]

Dear Jonas,

thank you very much for your very detailed explanation of the different use cases. This helps a lot to understand it better. I structure my response along your Use Cases.

Use Case A: I agree with you, that due to serial number inconsistencies the goods issue process and the subsequent steps shouldn't be blocked. Could you please check your serial number profile, which you have assigned to these material masters? I would recommend to set the serialization procedure SDCC to optional and the stock check to warning. This should not block the SOAP Message from getting processed during Goods Issue.

Use Case B: All your mentioned examples should be available in the SOAP Message to and from the WMS. This means, it is possible to adjust the transactional data in the S/4HC Delivery. As the documents are printed after/with the goods issue, all relevant information has been updated according to the WMS information with GI. Did you identify an information, which is not available in the SOAP Message and can be updated with GI?

As mentioned in my previous answer, Product Development is working on an intermediate update from WMS to S/4HC. This could help you further to update the delivery related information before posting GI.

Use Case C: Instead of solving the problem (Stock inconsistencies) I would highly recommend to resolve the root cause of the stock inconsistencies. Why did the preceding stock type change run into errors? Otherwise your customer is bothered with unnecessary manual stock corrections, which could be prevented. It is very important to keep stock information in sync between the two systems. This is also the reason, why SAP has decided to communicate all stock changes via Deliveries distribution and confirmation. This minimizes the risk of stock inconsistencies, as all movements have been confirmed by the WMS.

Providing end users with a feature to increase stock inconsistencies between the systems is in my opinion aggravating and not improving the situation. Reprocessing the initial failed Message, which caused the inconsistency is the correct solution to you situation. S/4HC provides E-Mail notification for failed Messages in the Message Dashboard to notify the responsible person immediately.

Having said this, there is an option in the Material Document API available to post physical inventory documents to S/4HC, without creating a Delivery in case of an WM managed Storage location. This is controlled via the flag "CtrlPostgForExtWhseMgmtSyst".

Best regards,
Daniel

[Daniel_Kesenhei]

Dear Jonas,

as you mentioned the process is very time-critical, I would suggest doing changes directly in the leading system for the delivery data, which is in your case the external WMS.

This has the advantage, that no inconsistencies can occur and the business user has the opportunity to adjust their actions based on the current processing status in their WMS. (E.g starting putaway processes or repacking)

Currently, it is planned to provide an additional API from WMS to S/4HC to update the delivery in S/4HC. Thereby early changes are replicated back not at the time of goods issue, but at every change of the WMS Delivery.
Important, this action is always triggered at the WMS:

Best regards,

Daniel

[Jack_Johnson]

Dear Daniel,

thank you for your response!

We cannot handelt the time critical issue in the WMS system because it is an external service provider.

The rot cause of this isses are nromally in the S/4HANA Cloud System itself.

There are many usecases we had in the past.

The route cause of the defect is not a technical or content issue within the electronic shipping confirmation file but caused by very different issues within the ERP system itself. Therefor the solution would require adaptations within the leading ERP system, not at the 3PL WMS or the electronic EDI file.

If the on-time goods issue is not possible, this leads in worse case to loading and delivery delays because central shipping documents and automated follow-up processes (export documents / compliance screening / export notifications / ...) are blocked, in case of need.

Penalty sums and additional transport costs can easily run into the tens of thousands of euros, depending on customer contract and shipping mode (air/sea/….).

Use Case A:

For only a part of our product portfolio serial numbers are monitored within our system. However, for most of our customers the serial number is not of any relevance. Our customers do not need to know the serial number of the device received and we don`t need to know to which customer a serial number has been delivered, in case it remains to be an exception and it`s in line with the customer expectations.

Example for the E-Shop B2C-Online Business with thousands of individual shipments, a very few electronic shipping confirmation fail due to for example a wrong “status” of one single serial number within the ERP.

It`s not of any interest of our customer to clarify the route cause and to correct the status of the serial number as the cost benefit balance shows it`s nonsensical to work on. Neither from commercial point of view nor an logistic quality point of view. The partly wrong status will not induce any “relevant” consequences.

In such a case the delivery is released, and goods issued manually by editing the delivery itself, not the highly complex IDOC to make situation quite clear.

The same would happen, in case there is a shipment about 99 pallets, 10.000 devices with a serial number each, out of which 1 serial number looks to have a defect. It`s ridiculous to spend to much time on clarification as it is on SN out of 10k SNs. – Above all, if the customer is not affected.

Use Case B:

The order to cash and delivery processing is fully automated from delivery creation, goods issue, invoicing and document output and transmission.

In case of missing or wrong information within the „blocked“ delivery, it need to be possible to add and change prior to the goods issue certain content, to have the results effected and reflected within the automated event triggered process steps after.

Content can be different from wrong or missing export attributes and texts or shipping advices up-to routing or packaging information's within text or parameter id`s.

Use Case C:

There is a stock type difference between the ext. WMS and SAP MM due to any unknown booking failure before. SAP MM is showing volumes at stock type Q, whereas within the ext. WMS system it was available stock. Due to this a “customer shipment” related electronic shipping confirmation failed due to missing available stock, missing only within the ERP system.

Example process: Within the ERP there are shown some units at stock type Q which have been obviously available stock at the ext. WMS.

Today's stock correction process to be able to immediately process the goods issue:

Clearing of stock difference/stock booking error:

1.Stock transfer movement mvt type 321 from plant/sloc 0100/0104 to 0100/0104 means from Q to available stock type will be initiated

2.By default, this mvt advice generates a delivery which is distributed to the external WMS, but of course can and should not be processed there.
Therefor the “delivery not editable” will be released, picked and goods issued manually. The formerly Q stock is now at status available stock 0100/0104

3.Advice will be given to the 3PL to simply delete/flag the obsolete delivery within his ext. WMS

4.As a result, the electronic shipment confirmation, related to the “customer shipment” within the EDI monitor can be processed successfully and stock difference has been clarified

This are just examples, it is not possible for us to create a final list.

Thank you!

Kind regards,

Jonas

[Marco_Valencia]

Jonas,

This is the case also for Cloud WM. The Outbound delivery document is block while is being distributed to the Warehouse to keep accuracy and consistency between IM and EWM/WM.

What changes do you want to make? Quantities? or others. Normally the only field that remains changable is the Bill of lading.

[Jack_Johnson]

Dear Marco,

thank you for your question!

Our goal is to get something like an Emergency Button to make all field editible again as it was before the outbound delivery was distributed to the external Warehouse System.

The accuracy and concistency would not be a problem in our case.

Due to the fact that our cusomer performd thousends of transaction per day this is a time critical situation and changes needs to be perfomed very quick.

Kind regadrs,

Jonas