Impact on changing Merchandise Hierarchy

[Former Member]

Dear All,

Currently in my company we have 4 level of merchandise hierarchy to which the management has decided to reduce it to 2 level.

The reason is , company wants to adopt the AC Nielsen hierarchy and properly classify our articles, which helps us compare our department with US standards.

i would like to understand if anyone has done this, what would be implications of this change and what is the best approach to do this.

Your inputs will be really awesome for me

Regards

Ilyas

[former_member232581]

Hi IIyas

Just curious, how you have decided to achieve the result. Is it by deleting the middle hierarchy level and reassigning MC to higher hierachy level. Or by Creating new hierarchy levels (2) all together and then reclassifying all your MC's to them?

Thanks

Vibhor

[Former Member]

Thanks for the reply Vibhor.

Our approach would be creating new hierarchy and create MC and  Re-classfiy all MC's. This way only we will be able to adopt Nielsen hierarchy.

Thanks

Ilyas

[paul_gendreau · Accepted solution]

Hello Ilyas:

There are three separate concerns.

1 - Arrangement and assignment of the Merchandise Category Hierarchy nodes to each other.

2 - Possible creation of new Merchandise Categories.

3 - Reclassification of Articles from one Merchandise Category to another.

If your effort is limited to 1 and 2 then this is relatively easy and straightforward.  In most cases, the Merchandise Category Hierarchy nodes and assignments are pure master data and may be deleted and then created again in a new arrangement.  LSMM can be used to delete existing and create new Merchandise Category Hierarchy nodes and assignments.

The difficulty, if there is difficulty, will be in reclassification of Articles from one Merchandise Category to another.  In this scenario the system performs checks before allowing the activity.   There are standard transactions to support this process.

Merchandise Reclassification

Articles are not typically reclassified on a regular basis.  The preference should be to schedule quarterly or annually. The results of reclassification should be fully tested in another client before changes are applied to production.

Considerations and Limitations

The following article categories can be reclassified:

• Single articles
• Generic articles with variants
• Structured articles
• Prepacks, displays, sets

Constraints

• Historical data is never changed automatically

• Neighboring systems and their documents (for example, FI) are not changed and therefore remain unaffected by the reclassification process.

• Conditions that have been defined for source and/or target objects remain entirely unchanged. A condition that has been defined for a merchandise category, for example, will continue to apply for all the articles in this merchandise category. So if an article is moved to a different merchandise category, it will be subject to the condition already defined for this target merchandise category.

• Completed purchase orders and/or purchase order items (including the document archive) are not changed.

• The level of an object in the hierarchy must be the same in the target as in the source. So a merchandise category, for example, cannot become a hierarchy node or a characteristics profile when it is moved.

• Reference articles (created by calling MM41 from WG22) cannot be reclassified.  A reference article will have MARA-ATTYP (Article Category) of 30 (Merchandise Category Reference Article).   An attempt to reclassify such an article, by using T-CODE WRCR, will result in an error message: ”This article category cannot be reclassified.”

System Checks and Conversions during Reclassification

• An article can be moved directly from a characteristics profile in the source to a merchandise category in the target because the significance of the article in the hierarchy does not change. The reassignment is, of course, still subject to other checks. The source characteristics profile is treated as a merchandise category for the purposes of this reassignment.

• The characteristics defined in the source must already have been defined in the target too. The characteristic profiles must be the same in the source and target merchandise categories.   So a merchandise category with the characteristic "color", for example, cannot be moved to a position beneath a target hierarchy level which only contains or inherits the characteristic "size".

• The characteristic values in the source must be defined in the target in full. So a merchandise category with the characteristic "color" and the values "red", "green" and "yellow", for example, cannot be moved to a position beneath a target hierarchy level which only allows the values "black" and "white", even though the characteristic is also "color".

• If a value-only article is defined in a source merchandise category, then there must be one in the target too. The value-only article, at the level of which stocks are managed, should not be different in source and target. So reclassifications which do not affect inventory management do not pose a problem in this respect. The stocks should be transfer-posted (with physical inventory) before reclassification takes place.

Reclassification Execution

• The system checks the characteristics of source and target objects: reassignment is only possible if the characteristics and characteristic values of the source also exist in the target.

• The system checks the level at which stock is managed in the affected sites: if in at least one site the stock is managed at a higher level than the article level, reclassification is only possible if the value-only article remains the same or if no stock exists anyway.

• Process the error log and change the reclassification version, as necessary.

• Save the reclassification version. This is a simulation version, meaning that it does not take effect until it is actually activated. You can change this version right up until its activation date.

• By activating ("updating") the reclassification version, you confirm that the relevant objects are to be moved on a specified date and - if articles are being moved - that the merchandise categories are to be changed in open purchase orders and allocation table items (optional). New listing conditions can be created and old ones deleted, as required.

• If necessary, you update the Information System (advise BW team to import new merchandise category structure).

Historical Data (Conversion Considerations)

• Historical data is never changed automatically,
• Color characteristic may be an issue for some objects.
• BW / OTB reports may require redesign to use current rather than actual merchandise category.
• Are there GL accounts / FI reports based on Merchandise Category that require review?
• Manual update to assortment planning.

Preparation - Identify objects to be reclassified

This defines the scope of the reclassification effort

• Merchandise category hierarchy changes (changes to the shape of the ‘tree’)
• Merchandise category additions and deletions
• Articles that will be reclassified (article number, old merchandise category, new merchandise category)

Preparation - Validate that articles will reclassify within constraints

• Are characteristic profiles the same in the source and target merchandise categories?
• Are characteristic values full?  The characteristic values in the source must be defined in the target in full. So a merchandise category with a characteristic "color" and the values "red", "green" and "yellow", for example, cannot be moved to a position beneath a target hierarchy level which only allows the values "black" and "white", even though the characteristic is also "color".

Preparation - Identify interfaces that may be impacted

These should be included in the overall reclassification process.
• e.g. POS outbound includes Merchandise category description
• BW

Merchandise Category Hierarchy – Relevant Transaction Codes

CLWM Merchandise Category Hierarchy Level - Create
CLWN Merchandise Category Hierarchy Level - Change
CLWO Merchandise Category Hierarchy Level - Display
CLWP Merchandise Category Hierarchy Level - Delete
CLW1 Merchandise Category Hierarchy Assignment

Merchandise Category – Relevant Transaction Codes

WG21 Merchandise Category Create
WG22 Merchandise Category Change
WG24 Merchandise Category Display
WG23 Merchandise Category Delete

Article Reclassification – Relevant Transaction Codes

WRC4 Create Reclassification Version
WCR3 Change Reclassification Version
WCR2 Display Reclassification Version
WCR1 Delete Reclassification Version
WRCV Activate Reclassification Version
WRCR Single Article Reclassification

- Paul

--------------------------------------------------

Paul R. Gendreau, Jr.

SAP Strategic Industries, Retail and Fashion

[Former Member]

Hey Paul,

Thanks for the long detailed explanation on this. let me check the points you mentioned and take it from there..

Once again ... thanks

ILyas