POD How to identify the outbound deliveries which have been partially accepted by the Customer

[former_member182378]

Process:

1. Truck reaches the customer site with Delivery# 8010 with 30 pallets

2. Customer accepts 27 pallets. 3 pallets are rejected because these are damaged

3. POD process is setup. Customer sends an IDoc to the company with info about accepted quantity in Delivery# 8010

4. How can the user find the list of deliveries which have rejected items by the customer? Or list of deliveries which are partially accepted?

In VLPODL or VLPODQ, we can see all the deliveries, not specifically deliveries which are partially accepted.

[former_member365886 · Accepted solution]

Hi,

I am not sure exactly what selection criterai is not present in VLPODL t-code,that you mention.We have customization on POD side and using this feature for some time.

I could see all possible status and filter criteria based on customer and tested the output as well.

Regards,

Avik

[former_member182378 · Accepted solution]

Thanks Avik, good to know that your company is using VLPODL for sometime now.

Referring to "Deliveries worklist" section in your screenshot -

If we choose the radio button - Not yet edited , then all the deliveries with POD status = A will populate in the next screen. In other words, all the deliveries.

----x----

A different question:

point 3: Customer sends IDocs to company for every delivery; as a confirmation of the number of goods accepted.

In case the accepted quantity is less than the delivered quantity in the IDoc, then does the POD status in the SAP outbound delivery change to B?

If this is the case, then in VLPODL, selecting radio button "Verified with difference" will give a list of all deliveries in which some quantity was rejected by the customer. And that is the list I am looking for.

[former_member365886 · Accepted solution]

Hi,

The behavior is exactly same as you mentioned and yes we use IDOC as a process flow.

click on selected line and go inside

Regards,

Avik

[former_member182378 · Accepted solution]

Thanks Avik!

[former_member182378 · Accepted solution]

Avik,

From your post, I understand that the Reason for Deviation, QtyDiff in the outbound delivery are updated from the information of the IDoc coming for the Customer (to the company, as a POD confirmation).

Few questions:

1. What Basic type, message type and Function Module does your company use for the inbound IDoc?

2. Does the Customer send different Reason for Deviation depending upon the situation?

Side note: FM is important, as it will have the logic for updating information (RoD and QtyDiff) in the outbound delivery.

Thanks!

[former_member365886 · Accepted solution]

Hi,

Please find the details,hope it is helpful.

1)Message Type-->STPPOD,Basic Type ->DELVRY03,and process code standard->attched FM i think IDOC_input_stppod

However,currently unable to connect SAP so exact details is not available to me,will update tomorrow.

2. Yes we have highly customized solution for POD deviation reason and based on that we generate Call list

This call list idoc goes from ECC --> CRM for customer interaction.This is done by SAP SCEM(Event management)

and posting idoc is msg typ EVMSTA.

Regards,

Avik

[former_member365886 · Accepted solution]

Sorry,I could not give actual picture and after posting,I thought it is clumsy to understand.

Hence,I decided to review the solutions again and here are few details.

I shall describe TWO scenario which will be enough to understand the architecture around POD and SCEM alert.

We have many other scenarios ,not delving much into those here.

Scenario 1: Sales orders/OBDs for which Fulfillment center delivers the product to customer,and there is a shortage or damage at POD stage.

1) Sales order created via interface/VA01 for particular order typ and item category.

2) OBD created via interface/VL01N

3) We do the PGI: By posting inbound idoc: SHP_OBDLV_CONFIRM_DECENTRAL

4) Now we have to post STPPOD idcoc which will be triggered by middleware with qty. lesser than the delivered qty.

5) Go to VL03N:check the delivery the call alert generated in the header view: SAP Event Mgmt Tab.

we have a custom call list OUTBOUND idoc generated via SCEM alert configuration.

Scenario 2: Typically Return scenario:

Quantity will be short picked from the customer for that fulfillment centre.

1) Create return sales order via VA01.

2) Delivery document is created as follow on document for the return sales order with say 1 line item = 10 qty.

3) SHPCON idoc is posted with actual picked qty. for e.g 1 line item = 8 qty.

so after posting delivery qty changed to 8 and

4) Call list IDOC generated with necessary details.

EVMSTA IDOC is a separate scenario.

Regards,

Avik

[former_member182378 · Accepted solution]

Thanks Avik,

The important point that I want you to confirm is that

The reason for deviation and qtydiff are populated automatically in the OB deliveries with the information from the inbound POD confirmation IDoc

Because of this automatic update, the POD status changes from A to B in the OBDs which have some quantity rejected by the customer.

In turn, Business can filter out these deliveries by selecting radio button "Verified with differences" in VLPODL (or any such transaction)

[former_member365886 · Accepted solution]

Yes it happens automatically. We have certain customized requirement for SHIPCON and STPPOD related to HU logic inside suitable exit.

Regards,

Avik

[former_member182378 · Accepted solution]

Thanks Avik for this strong support!

TW

[Lakshmipathi]

I dont remember whether we can check such partially accepted POD deliveries can be fetched but manually, it is possible to check what is the delivery quantity and what is confirmed quantity. Nevertheless, irrespective of your quantity in delivery, invoice can be generated only to the extent of POD confirmation.

[former_member182378]

How does business user know that SAP Delivery#8010 has been accepted partially and user must complete POD confirmation manually?

Taking in to consideration that 5000 outbound deliveries are created daily by the business.

Thanks!