cancel
Showing results for 
Search instead for 
Did you mean: 

Issue with End routine to update Masterdata 0cust_sales

0 Kudos
360

Urgent: Hello Gurus, We have a requirement to update 0cust_sales master data with latest buying group. Buying group is determined based on submission numbers and some other conditions. We have implemented an end routine and enabled semantic keys in DTP. The issue is End routine is not updating buying group correctly for few customers, but when I debug I can see the correct results in result_package but its not updating the P table. when I run the full dtp with a single customer in filter it works well, I am not sure why its not getting updated to P-table.
Can anyone help me. Please find the attached code.

Accepted Solutions (1)

Accepted Solutions (1)

john_lang
Active Participant
0 Kudos

Hi Koushik,

The below recommendations are assuming the business rules themselves are all ok, as you have stated.

The business rules might not always be updating the P table, due to the way the code flows, specifically the way it is doing it's block processing of the datasets. These recommendations focus on the way the data in the internal tables is being processed (Loops, Ladders, Sorts, Reads, etc).

Action Recommended 1: Update the sort it_42_22 statement to be the exact four fields used in the BINARY SEARCH.

sort it_42_22 by kunnr spart vkorg vtweg.

Tip: Where a READ TABLE ... BINARY SEARCH is done, the preceding SORT statement must be an exact match (all fields listed & in order) of the WITH KEY parameters listed. If this is not honoured, then the BINARCH SEARCH results will occasionally return an incorrect answer in sy-subrc. It is not because the data wasn't there but because the data was not sorted by following the READ TABLE ... WITH KEY ... BINARY SEARCH expectations.

Action Recommended 2: Remove the sort it_42_22 by msnum DESCENDING statement.

Tip: This statement appears to be completely redundant. Any benefit obtained by the sorted order is immediately overridden/wiped out/never used by the sort it_42_22 by statement 3 lines below it.

Action Recommended 3: Change the continue statement to be a break statement.

Tip: The nested loop (loop at it_42_22) seems to be written to process only a single master data value of 0CUST_SALES (its full key of 0CUST_SALES, 0DIVISION, 0SALES_ORG, 0DISTR_CHAN) as a time through each iteration of the outer loop (loop at result_package). This implies that when the business rules have finished doing their processing for a single master data value of 0CUST_SALES (because it was sorted properly) then the nested loop is only wasting CPU by iterating to the end of the nested loop (loop at it_42_22) internal table. I recommend using a break statement, instead of continue statement, as we want the loop processing to continue iterating through the outer loop.

Action Recommended 4: Have an open discussion with you're fellow ABAPers in the team, specifically discussing the processing logic issue of dataset granularity, fundamentally embedded in the use of a BINARY SEARCH versus the actual records in the it_42_22 internal table.

Consideration 4.1: The internal table has many records in it that have the same primary key of the read table ... with key kunnr spart vkorg vtweg. Which is why it_sort_2242 is being used to capture the smaller datasets of that same key.

Consideration 4.2: A binary search is not guaranteed to return the very first record in the sorted order of the it_42_22 table. A binary search only guarantees that it found at least one matching record, not the 'first one of the sorted internal table'.

Consideration 4.3: Add a small loop to traverse/iterate backwards to meet the condition ... "lv_index = the first matching record in the sorted it_42_22 table".

Tip: While it might be tempting to ignore this subtle distinction of 'a matching record' versus 'the first record'; it is exactly what drives your original question of why sometimes it doesn't work, but most of the time it does. Given that most organisations have a decent sized master data list in 0CUST_SALES (+1 million records), I strongly recommend you keep the current BINARY SEARCH technique with the nested ladder (loop at it_42_22) and just add a new small piece of code to traverse/iterate backwards to identify the true 'first record in the small subset'.

This is general advice only; please ensure you debug all changes applied in the target system to ensure there are no unintended consequences.

Hope this helps.

Kind regards,

john.lang.

Answers (1)

Answers (1)

former_member267922
Participant

Hi Koushik,

in Full DTP please set the semantic key as Cust Sales # and in End routine code sort Custsales as ascending and buying group as descending order and then pick it.

if you are not writing code than any core ABAPer will understand this easily. your side just set Cust Sales # as semantic key.

Thanks,

KD Jain

0 Kudos

Hi, but our requirement is to pick up latest buying group.

john_lang
Active Participant
0 Kudos

Hi Koushik,

Could you let us know that the DTP Semantic key is set as 0CUST_SALES, as per KD Jain recommendation?

Given the way the code is doing its block processing, it is also just as crucial for the DTP Semantic key to not include the other compound objects (0DIVISION, 0SALES_ORG, 0DISTR_CHAN). It does need to be just 0CUST_SALES to ensure all records belonging to a single master data value of 0CUST_SALES (a single customer number with all of its divisions, sales organisations & distribution channels) get put into the same result_package for processing by the End Routine.

Looking forward to your confirmation of the DTP Semantic configuration.

Kind regards, John Lang.