Issue of Delivery creation caused by Incomplete check

 

Recently get one error of VU(013) ‘Document is incomplete: You cannot save the delivery’ while using VL10B to generate delivery orders for STO. It’s not a good idea to check from a technical point of view at the beginning for sure as there could be dozens of reasons why documents are incomplete like incorrect master data, various configuration settings, etc.

Unfortunately, no finding from a business point of view so has to start debugging hoping that some potential User exit/custom BADI could impact the incomplete processing.

1, Where to start and how to debug?

As already know the message type VU along with its message number 013, it’ll be the easiest way to set a breakpoint at this unique message VU013 directly. But it’ll not trigger any breakpoint when clicking the ‘Background’ button at VL10B.

Please check this article which clearly demonstrates how to debug VL10B in background processing mode. Unless you are familar with this procedure at system very well or know recent related changes/specific user exit name to set routine as break-point accordingly, otherwise still it looks like a needle in a haystack.

After the parameter ‘LEDSP_DEBUG_MODE’ has been created for ‘VL10B’, two breakpoints will be set automatically.

• 1st break-point against the parameter at function ‘GN_DELIVERY_CREATE’

• 2nd break-point against the parameter at routine BELEG_SICHERN_01.

The key routine for document incompleteness check is: ‘UC_FROM_FINAL_CHECK’:

Here can find the key point where to trigger this error message:

 

2, How have those fields been populated and impacted the incomplete process?

Call sequence till now:

For my case, it’s clear that only two conditions could trigger this error:

1. XVBUK-UVVLS(Total incompletion status of all items: Delivery) equal to ‘A’ or ‘B’
2. XVBUK-UVVLK(Header incompletion status concerning delivery) equal to ‘A’

As suspected, the head’s status (xVBUK) has been impacted by item status(xVBUP) through function module ‘WS_UNCOMPL_STATUS’:

Keep tracing how Xvbup has been populated and updated inside the routine ‘XVBUV_FILL’.

At this point, the variable ‘ls_tvuvs’ is the key field to control how xvbup-uvvls changed from default ‘C’ to ‘A’.

The determination logic is:

• If the table XVBUV does not exist, the value of xvbup-uvvls will set as ‘C’ which means ‘Completely processed’.
• Elseif table xvbuv[] existed, get this status flag from tvuvs-uvvlk according to the status group through routine ‘read_tvuvs’.

translate tvuvs_wa using 'XA C'.
"if tvuvs_wa is intial, the converted result will be 'CCCCCCCC'
"if tvuvs_wa is not initial like 'D1XX', the converted  result will be 'D1AACCCCC'

Then the first configuration table TVUVS shows up:

The SPRO path is: Logistics Execution->Shipping->Basic shipping functions->Incomplete control for Deliveries->define status group:

Now the question is how xvbuv has been inserted at routine ‘xvbuv_fill’ of include program ‘FV50UF0X’. It depends on internal Table ucadm will be filled by ‘ucadm_fill ‘ which determined by table tvuvf and ucobj objects.

Keep searching the filling logic for table UCADM will find out the second configuration table TVUVF (Incompletion Control: Fields).

The SPRO path is: Logistics Execution->Shipping->Basic shipping functions->Incomplete control for Deliveries->define incompleteness procedures (TCODE: OVA2). Here the group for the delivery item is ‘H’:

Check relevant incomplete procedure (Error proc.)  and its incompleted fields setting.

Now the whole picture reveals with consolidating the above settings along with incomplete check logic:

1, Get internal table XVBAK and XVBAP which contains all the detail of header&item for the delivery at routine like ‘delivery_final_check’;

2, For delivery header level incomplete fields:

• Get ‘Error procedure’ assigned for the delivery type(XVBAK-LFART) through SPRO path:Logistics Execution->Shipping->Basic shipping functions->Incomplete control for Deliveries->assign incompleteness procedures->Assign incompletion forms to the delivery types.
• Find fields names that have to be maintained at header level through group ‘G’ (Delivery header) combined with the above ‘Error procedure’.

3, For delivery item level incomplete fields:

• Get ‘Error procedure’ assigned for the delivery item category(XVBAP-PSTYV) through SPRO path: Logistics Execution->Shipping->Basic shipping functions->Incomplete control for Deliveries->assign incompleteness procedures->Assign Incompletion Forms to the Delivery Item Types.
• Find fields names that have to be maintained at the item level through group ‘H’ (Delivery item) combine with the above ‘Error procedure’.
• Here for the Screen name for creating missing data like ‘CHSP_T’, we can use the where-used list at table V50UC(Dynamic Fields: Incompletion Log – Delivery) to find out the routine how it’s been validated during creation.

Finally, it turns out that the issue caused by batch no. is missing at the item level. So simple…such a journey! Haha

3, Potential Custom user exit or BADI implementation

For the delivery creation process, the user exits could exist at mv50afz* at include program SAPMV50A. Those routines like ‘USEREXIT_SAVE_DOCUMENT_PREPARE’ ‘USEREXIT_SAVE_DOCUMENT’ still matters at least for ECC till now.

At end of DELIVERY_FINAL_CHECK inside SAPMV50A, the customized BADI implementation will be check&call here.

Double click the BADI object will find all related implemented classes (SE24) like below:

Check details of those implementations for BADI named ‘LE_SHP_DELIVERY_PROC’ through SE18.

In the End

It’s not a good way to learn incomplete procedures like this. Read SAP helps and articles like this will help to understand the whole process. Such debugging journey just needs once, in case another one in future, I spend another few hours to write this down… 温故而知新

Source: https://blogs.sap.com/2022/02/22/issue-of-delivery-creation-caused-by-incomplete-check/