Table-driven combination categorization

[Former Member]

I have a working report that has a gt_vbap internal table with only two columns; VBELN and MVGR3. A given order (VBELN) can have multiple rows in gt_vbap for a combination of kits (a MVGR3 code is used to represent each kit) that might be bought on each order.

(ex:)

VBELN MVGR3

187037934 BKS

187037934

187037936 JBU

187037936

187037937 JBU

187037937

187037937 SLC

187037937 DGC

187037937 TOC

187037938 JBU

187037938

187037938 SLC

187037938 SPC

187037938 DGC

187037938 DTC

187037938 ORC

187037938 TOC

The report currently turns "on" a global variable flag for each MVGR3 that it finds per order and initializes the flags before the next VBELN set.

It then goes into a complex hard-coded IF THEN ELSE perform that has an IF clause for each possible combination of kits, using the flags to see which combination was ordered. That perform also assigns a NUMBER to that "group" or combination. That number is then used in another perform with hard-coded IF logic to give a unique NAME to the combination. To write the report, the number/name rows (or different combinations) then become aggregated for sales of different types.

The psuedo-code for all this is:

Clear each MVGR3 flag.

Loop at gt_vbap using field symbols to assign 'X' to flag for each found MVGR3.

At end of vbeln:

perform get_group

perform assign_description (takes the number from the group and gives a description)

clear each MVGR3 flag.

ENDAT.

ENDLOOP.

FORM GET_GROUP

(contains a separate IF clause for each possible combination of MVGR3 values

ENDFORM.

Edited by: Rob Burbank on Jun 16, 2010 3:45 PM

[Former Member]

am trying to design a way to replace all that hard-coded IF logic in the performs with a new custom table containing the numbers (there are just over a hundred combinations, but this will grow), the names of the kit combinations, and the MVGR3 (material group 3) codes that make up each valid combination.

Something like this is what I was thinking of. Using a custom table will require less programming when valid kits are added or changed from our sales lineup.

z_kit_group_desc

Group Desc Col1 Col2 Col3 Col4 Col5 Col6 Col7

17 Only BKE BKE

18 BKE plus BKE SLC

u2026

79 Large Group BKE SLC ORC DGC DTC SPC

80 Big Group BKE SLC ORC DGC DTC SPC TOC

Sorry for all that background, but here is the problem: How can I match up the internal table gt_vbap values for each VBLEN with the new custom table "z_kit_group_desc" (not yet defined) to give a number/description group to each ordered combination? I'm not sure how to find the proper row from my new custom table using the combination of rows from the internal table that make up the combinations on each order. Table gt_vbap MVGR3 values do not occur in any particular order, but are part of a finite combination.

Thank you!

Jeremy

[Former Member]

Jeremy - please note that there is a 2,500 character limit to posts in this forum. In the future, try to trim you message and post only the relevant parts.

Rob

[brad_bohn]

Well, given that design, add a 'search string' field to your custom table which is populated by your entry transaction logic or built into your table maintenance logic. Presumably, the 'group' description is not dependent on the order of your MG3 values, so you need to generate the search string field value based on a simple alpha sort or by reading another table that identifies the proper sort value for each MG3. Then, you simply determine the search string value for the entries in your order (using LOOP...CONCATENATE...SPLIT INTO TABLE...SORT...LOOP...CONCATENATE or some other approach) and select from your Z-table using the resulting search string value.

[Former Member]

I wanted to post a conclusion to this question. I was able to successfully implement this design to solve the requirement. Thank you for the suggestion to solve my question regarding concatenating the codes into a look-up key.

[Former Member]

Thank you for the suggestions. I'll investigate and apply that method. I'm not a very senior abaper, so I am probably suggesting a rather elementary design, but it was the first approach I thought of to make the report easier to maintain. Thank you and I'll check back to this thread with my progress.

(Moderators, sorry about the lack of formatting in my question, and the > 2500 character limit. I couldn't figure out how to keep the original formatting in my question).