cancel
Showing results for 
Search instead for 
Did you mean: 

Controlling extended classic

Former Member
0 Kudos

We are using the Extended classic scenario in SRM 5.

A requirement has now surfaced where all catalogue items should be processed within SRM PO wise so when the cart is approved it reacts just like extended classic where a copy of the PO goes to R/3.

Free text items once approved should invoke the classic scenarion via Badi BBP_EXTLOCALPO_BADI.

Our problem is that it cannot destinguish between catalogue and free text items and as we are not using R/3 products and types we can only use the product category section of the method, but as catalogue items could have the same category this causes a problem as we do not want to add categories specific for catalogue shopping and the decoupled scenario does not suit the model

Can anyone help with a suggestion we have also looked at using the the badi BBP_DETERMINE_LOGSYS

Tom

Accepted Solutions (1)

Accepted Solutions (1)

Former Member
0 Kudos

Hi,

Just implement the BADI "BBP_EXTLOCALPO_BADI " for controlling the scenarios based on your conditions.

See this related thread:

BR,

Disha.

Do reward points for useful answers.

Answers (5)

Answers (5)

Former Member
0 Kudos

We resolved this ourselves in the end but thanks for all your comments as we had fall back positions if we failed

Former Member
0 Kudos

Hi. I take it the idea of duplicate categories did not go down too well? Another option, how about getting really creative with the BADIs?

1 - Create a custom table to store 3 fields - cart number, line number, real product category

2 - Create 2 product categories, 1 called "Catalog" 1 called "Free Text"

3 - Use the BBP_DOC_CHANGE_BADI method BBP_SC_CHANGE to check if the current t-code = BBPSC07/8/9 (whatever you use as the approval inbox) and SY-UCOMM = "approve" (or complete approval step, whatever SRM version you are on) and this is the last step of the workflow then change product category to either "free text" or "catalog" and also write the original values to the custom table

4 - Get the BBP_EXTLOCALPO_BADI working off the 2 product categories

5 - Use the BBP_CREATE_PO_BACK BADI to change the product category from the dummy one to the real one by reading the custom table for backend POs

6 - Use the BBP_DOC_CHANGE_BADI method BBP_PO_CHANGE to change the product category from the dummy to the real for the local POs

The only down side to this is that the cart will end up with the dummy product category. You could try the BBP_DOC_CHANGE_BADI again to see if it is called after the backend docs are transferred, then you can swicth from the dummy to the real again.

Regards,

Dave.

Former Member
0 Kudos

Isn't there a field called CATALOGID in the item_data table?

if it is empty you have a free text item, if it's not empty you have a catalogue item.

Regards,

Robin

Former Member
0 Kudos

We can see the item data but we canu2019t detect which item is being processedu2026.we found some coding that pointed us at Global data at runtime but only data which is defined at the top level of the program object is loaded. Unfortunately there is not any global data that points to the present item being processed, just data that only exists at runtime, hence the issueu2026.:-(

IF you can give us a clue as to how we find and hold the data we would be grateful

Tom

Former Member
0 Kudos

Hi Thomas,

why is it important to know which item is processed? It is either a free text item or a catalogue item. If I understand your topic start correctly that is the requirement you should base the classic/ext. classic decision on.

imthiaz_ahmed
Active Contributor
0 Kudos

I agree with David. Another or if that is not feasible, then check these tables

/CCM/D_CTLG Table for Catalog Header Data

/CCM/D_ITM_TXT Short Descriptive Texts for Catalog Items

to identify whether it's a catalog item or not.

Regards, IA

Former Member
0 Kudos

Hi. It's not a great solution, but you could set up alternate product categories for catalog / free text.

Create a custom table to store the link from 1 set to the other.

Only assign 1 set to the users in the org plan, and use the same set in the catalog, but use BBP_DOC_CHANGE_BADI to switch from product category A to product category B if the item is catalog.

Then the product category will be available in the BBP_EXTLOCALPO_BADI and you can look up from the same Z table to work out if it is catalog or free text and set EC on or off accordingly.

Regards,

Dave.