cancel
Showing results for 
Search instead for 
Did you mean: 

IBP - Database design & Master Data Types - Creation of planning objects based on Master Data upload

vincentverheyen
Active Participant
0 Kudos

Let's say we have the following Master Data Types:

Single MDT1 with key Attr1
Single MDT2 with key Attr2
Single MDT3 with key Attr3
Compound MDT1.2.3 with keys Attr1, Attr2, Attr3

I understand we can add all of these key Attributes of the Single MDTs in a Planning Level as root, and also include at least 1 extra non-key Attribute of the Compound MDT1.2.3 in the Planning Level. And IBP will be able to automatically create planning objects from the Attribute As Key Figure of Compound MDT1.2.3. The number of these automatically generated planning objects will equal the amount of rows in Compound MDT1.2.3.

My question is the following:

Let's say, on top of the above, we also have the following:

Single MDT4 with key Attr4
Compound MDT1.4 with keys Attr1, Attr4.

My question is: can we create a Planning Level which can join all of the attributes in MDT1, MDT2, MDT3, MDT1.2.3, MDT4 and MDT1.4?

Such that the Planning Objects are created automatically from the valid combinations which include Attr1. Or do we need to use a copy operator to be able to create the rows which we desire.

Accepted Solutions (0)

Answers (3)

Answers (3)

riyazahmed_ca2
Contributor
0 Kudos

Hi Vincent,

Lets say we have 2 Planning Levels namely PL1(Attr1-Att2-Attr3) and PL2(Attr1-Attr2-Attr3-Attr4). In order to create the planning objects, we need a trigger point such as Copy operator with or without Attribute Transformation, data loads or Attribute as Keyfigure and so on..

To initialize PL1, you are using AAK feature. But for PL2, you aren't having any fore-said trigger points. Hence planning objects cannot be created automatically.

And I sense a risk, if you want to create PL2 Planning Objects automatically referring the valid combination of PL1, as it will lead to the creation of unwanted planning objects. For example, Lets say there are 3 SKUs P1, P2 and P3. And we have 3 Customers namely C1, C2 C3. C1 buys all 3, C2 buys only P1 and P3, C3 buys only P3. Considering this basic understanding of Business, we should create only the required combinations. Creation of Planning Objects such as P1-C3, P2-C3 and P2-C2 are certainly wrong and this is the expectation by Automations which I don't recommend at all.

An other example, Lets consider PL1 as Liquor-Middle East. At this level, it seems good coz Middle East countries does allows sales of liquor. To create PL2, Liquor-Middle East-Saudi Arabia. This combination is not at all possible, Coz Saudi has active ban on the Sales of Liquor.

Automations leads to such issues from higher to lower level. Take a deep breathe and specify it clearly which valid combinations of PL1 is going to merge with which Attr4 to create PL2 to make IBP sophisticated in front of Users.

Best Regards,

'Riyaz'

pradeepmolugu
Explorer
0 Kudos

Hello Vincent,

Once the Master data is availble for the Product, location , UOM, UOM conversion factor , Exchange rates, Production location etc etc.

Identify the planning level of KF and check wheather the reavant master data is created, once the master data is available ready to use. Pick any one of the KF relavent planning level to activate the Transaction data planning objects combinations for the available master data . This process will activate all Keyfigure for the planning level in which activation processed.

Regards,

Pradeep Kumar

0 Kudos

Hi Vincent,

I'm not so sure about your requirement. But the AAKF planning level needs to be as per your keys in master data.

If you want to input all MDT1, MDT2, MDT3, and MDT4 then your planning level must contain all of these 4 master data + relevant compound master data. Your attribute as a key figure will be in the compound MDT where the keys consist of key Attr1,2,3 &4. And these 4 keys should be the root attributes in the base planning level as well.


Please let me know if you have any further clarifications.

Regards,

Sittinut R.