Debug tips about VL014 “Error delivery split because the partners are different”

When using TCODE VL10B to create a delivery order based on one specific STO order, the user got the Error message of VL014 which is “Item &: delivery split because the partners are different”. All items share the same customer and related split configuration been checked without issue, those items should be group into one delivery order instead of split by items which increase lots of unnecessary further operations.

In this article, I try to figure them out from the technical point of view and list the key points during the debugging process.

First of all, setting the break-point at this message type VL with message number 014 at debug screen is the best starting point for sure. But unfortunately, it will not be triggered as this message not been processed like a popup but been collected for error list display only.  And VL10B will not create a background job under your name at SM37, so forget about JDBG as well.

By tracing the changes of error log table FVBFS at Function module: RV_DELIVERY_CC_ERRORLOG_ADD, will find out the trigger point of this error message at routine named ‘message_handling_variabel(sapmv50a)‘ of includes program LV50SF08. (Insert point is routine ‘message_vbfs_aufbauen’ at FV50XF0M.)

Btw, use RV_DELIVERY_CC_ERRORLOG_ADD as a process termination point to prevent delivery been created physically as such cases could be rare and hard to find one new one, otherwise need to revert back the invoice accordingly and deleted generated deliveries.

At the same routine, the key field to check whether need split delivery by partners is field ‘lf_partners_identical’.

This identical flag will be updated by FM:‘SHP_COMPARE_DELIVERY_PARTNERS’ inside FM: ‘SHP_CHECK_PARTNER_COMBINATION’.

Two tables here: one is LT_VBPA_CHECK contains the partner information of the header already existing, LT_VBPA the partners of the new delivery header ZLIKP. Flag ef_partners_identical is flagged as X at the begging, which means all delivery should not be split by default unless this flag been cleared. 

Create watchpoint for field ‘ef_partners_identical’ and we find the root~! Here you can search ‘clear ef_partners_identical’ to get all the different reasons which could lead to a delivery split caused by partners! In my case, which is caused by different ADRNR! 

OMG, how could be such a simple reason~~~ I’m going to faint. Check PO item table, different ADRNR for various PO items, and numbers are sequential! Don’t forget ADRDA = ‘E’ means what.

Check the ADRC table with those ADRNR, all those lines are exactly the same except the number.

Check PO changelogs, what user has done for items? Nothing changed but left change logs!!!

Those meaningless actions make the system think details been updated for delivery address, that’s why ADRDA is ‘E’ instead of defaulted ‘D’!

By user ID and changelog time, we can see this more clearly at the changelog item table CDPOS! Blank value_new and value_old, what a useless update with ‘I’ and its logs 😀

Why there’re some other tables like ADRU besides ADRC been inserted? Check item change log you will find out : P  Some key function or routine during the delivery creation process:

◉ ‘GN_DELIVERY_CREATE’ at  ‘SHP_VL10_DELIVERY_CREATE’

◉ ‘SHP_VL10_DELIVERY_CREATE’ at LV50R_CREAF07

◉ ‘DELIVERY_CREATE’ at LV50R_VIEWF43

◉ ‘PACKAGES_DELIVER’ at LV50R_VIEWF44

◉ FCODE_SAMD / FCODE_EXECUTE at PAI of VL10B

Debugging is like a chasing game for me, full of upset with trap and stimulation of couse ~ The biggest drawback is I will drop hair ~ 

Source: sap.com