SRM impact of changing the product category hierarchy

[MariusStoica]

Hi,

As an ABAP-er, I'm trying to understand how changing the product category hierarchy, from a 2 lev category, to a 3 lev category (tcode COMM_HIERARCHY) has an impact on the current "opened" documents (SC's awaiting approval, etc).

I understand that every category has a specific GUID that is saved on each document item and if I change the hierarchy, then the GUID is changed. Does this mean that every "open" document has to be manually reprocessed in order to attach the new category for each item?

I tried searching for a SNOTE or document about this but didn't find any.

Kind regards,

Marius

PS: SRM is in Extended scenario.

[MariusStoica]

Hi Laurent,Sorry, I don't understand your answer.There are 3 things that I can say regarding to your answer. For one, I know how to change the hierarchy using COMM_HIERARCHY tcode. I've only done it during an implementation, before go-live, so there were no open documents. Secondly, the hierarchy is only managed in SAP, no other program, middleware is used to change it. Thirdly, I understand that the hierarchy is synchronized to/from ECC, and it works.My only issue is regarding the impact on the current documents.Regards,Marius

[laurent_burtaire]

Hello Marius,

if you replicate ECC material groups, you cannot change your purchasing hierarchy in SRM as SRM is not the original system: you have a pop-up preventing you to do so.

Regards.

Laurent.

[laurent_burtaire]

Hello Marius,

do you replicate ECC material groups through middleware to create your product categories?

If yes, you could use BAdI BBP_PRODCAT_HIER.

Nevertheless, this BAdI is useless for already existing Product Category: it is called only for new Product Categories (see OSS note 2686033 - Product Hierarchy (R3PRODHIER) replication fails from ECC to SRM) in include LCOM_PRODUCT_CUST_INBOUNDF19.

So, i think you will have to enhance this include or make a standard modification to execute the process also for change/update on Product Categories.

This will have no impact on existing Purchasing Documents as you do not change the Product Category GUID, but its parent GUID (check table COMM_CATEGORY).

For Hierarchy ID assigned to application Purchasing (check transaction COMM_PRAPPLCAT), its CATEGORY_GUID is the parent GUID of node below. Then all Product Categories have as parent GUID this GUID.

So for standard hierarchy R3MATCLASS, it gives:

R3MATCLASS -> R3MATCLASS<ECC_Backend> -> all product categories; this is a flat structure.

In your case, it seems you woul like to have:

SRMPRODCAT -> ???? -> Sub-node1 -> Product Categories 4XXXXX

SRMPRODCAT -> ???? -> Sub-node2 -> Product Categories 5XXXXX.

Regards.

Laurent.

[MariusStoica]

My current example is:

<custom class> -> <custom class><ECC_Backend> -> Sub-node1 -> Product Categories 3XXXXX

Since you cannot "move" Product Categories 3XXXXX, to another node, you have to delete it and recreate it somewhere else, it's GUID changes. The new model should look like this:

<custom class> -> <custom class><ECC_Backend> -> NewSub-node1 -> NewSub-node2-> Product Categories 3XXXXX
<custom class> -> <custom class><ECC_Backend> -> NewSub-node1 -> NewSub-node2-> Product Categories 4XXXXX

Does your statement "this will have no impact on existing Purchasing Documents as you do not change the Product Category GUID" still stands? From my understanding, each category will have a new GUID upon creation.

Kind regards,
Marius

PS: Still learning here 😄

[laurent_burtaire]

Hello Marius,

one question: how did you do to get this?

<custom class>-><custom class><ECC_Backend>-> Sub-node1 -> Product Categories 3XXXXX

This is not standard, except if you made enhancement or you used BAdI during middleware replication.

But, even if hierarchy is changed, CATEGORY_GUID does not have to be changed, otherwise, purchasing documents (SC, PO, etc) will have a reference to non-existing Product Categories as their old GUID are no longer relevant.

Regards.

Laurent.

[MariusStoica]

Hi Laurent,You said, "does not have to be changed". How can I make sure it doesn't get changed? Is there a way to achieve this if we change the hierarchy to :

<custom class>-><custom class><ECC_Backend>-> Sub-node1 -> Product Categories 3XXXXX

Like I said, we do not have this yet, it's where we want to arrive, to have another level (a third one) between the "Subnode 1" and the "Custom class".

[laurent_burtaire]

Hello Marius,

did you check OSS note i gave you?

Regards.

Laurent.

[laurent_burtaire]

Hello Marius,

i do not understand your request. Currently which hierarchy do you use for your Product Categories? R3MATCLASS?

Could you please add a screen-shot of your hierarchy in COMM_HIERARCHY transaction?

Regards.

Laurent.

[MariusStoica]

Hi Laurent,I don't know how much info I'm allowed to share, but the current hierarchy has 2 levels, and it should have 3 levels. Here is an example of a 2 lev hierarchy. 2019-12-13-10-56-36-clipboard.pngThe system doesn't use the R3MATCLASS hierarchy, but a custom one created for the client. My question is regarding the best practice of a hierarchy change (if there is one) or the impact that a hierarchy change has on the current "open" documents.Regards,Marius