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.
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 have been updated for delivery address, that's why ADRDA is 'E' instead of defaulted 'D'!
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~
---Updated at Sep-16-2021
Just less than three months, I almost forget the whole process~ Thanks for this blog&myself to bring me back to that old battleground ：D That's why I need to keep blogging...
Ex. if BAPIMERQADDRDELIVERY-TEL1_NUMBR had been maintained then ADR2 will show in changelogs with 3 entries for 'ADRU'. It's the reason why those 3 changes log at item level with empty old/new values.
So it's correct changelogs for PR creation.
Will try the approach from this linkage.
-------------updated at 2021/10/20 -----------------
The final solution for my case:
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.
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 have been updated for delivery address, that's why ADRDA is 'E' instead of defaulted 'D'!
- '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~
---Updated at Sep-16-2021
Just less than three months, I almost forget the whole process~ Thanks for this blog&myself to bring me back to that old battleground ：D That's why I need to keep blogging...
Ex. if BAPIMERQADDRDELIVERY-TEL1_NUMBR had been maintained then ADR2 will show in changelogs with 3 entries for 'ADRU'. It's the reason why those 3 changes log at item level with empty old/new values.
So it's correct changelogs for PR creation.
Will try the approach from this linkage.
Notes 546668(FAQ: Delivery split when creating deliveries)
Question: Why does a split occur due to deviating partners?
Answer: All partners which stand in the partner schema of the delivery and that are copied from the preceding document or that are determined from the customer master record of the goods recipient are a splitting criterion. The only mandatory partner of the outbound delivery is the goods recipient. If, for example, no statistical data is affected, you can delete the sold-to party from the partner schema for deliveries with order reference and it is then no splitting criterion anymore. The following may lead to a split in the delivery:
- Different partner numbers for the same partner function.
- Deviating addresses of the partners even if the partner number is the same. Here, only the address number is crucial for the split; the address list parts are not checked.
- The forwarding agent as an additional partner in one of the sales orders involved. In contrast, additional partners with other roles do not lead to the split in the standard. For this, you can find more information in SAP Note 448919.
-------------updated at 2021/10/20 -----------------
The final solution for my case:
- Implicit enhance at begin of routine gn_lieferkopf_finden at LV50SF08. Set the flag to trigger this logic with filter get from LIKP
- Implicit enhance at end of FM:SHP_CHECK_PARTNER_COMBINATION. Get the flag to active compare new logic:
- fetch 2 ADRNR for partner WE from lt_vbpa_check and lt_vbpa accordingly;
- remove the value of addrnumber, adrc_UUID;
- if those two ADRC entries are equal then set EF_PARTNERS_IDENTICAL back as 'X'
- SAP Managed Tags:
