Attribute transformation in IBP. Not an easy thing!

Attribute transformation in IBP. Not an easy thing!

I selected this picture to illustrate the "dark side" win because it is about the feeling I ever had when facing a customer requirement that needs to be modeled by means of “Attribute Transformation”.?

1-??Background

With this weird technical logic in IBP, I feel just distraught, as I am miserably failing at visualizing the necessary steps to complete the task, quickly and effortlessly. It finally works, but always with a taste of defeat and a way too long time for such a basic matter.

And you know what? As these attribute transformations are rare in IBP design, I forget about it, until next time ??

For sure I read a few articles and posts about it, every time, however, it does not go smoothly.

It seems that there are consultants who are wired for it, who integrate this as a natural feature. They get the brain connections with the SAP developer that invented this odd thing, and the others like me who struggle.

2-??Objectives of attribute transformations

The target of the attribute transformation concept is really simple to explain.

It allows sourcing any keyfigure values, from any other keyfigure however, changing on the fly, the key data that the system uses to read from the database.

These keys can be the time periods, the values of the attribute for product, location, customer, etc…

3-??Typical example of attribute transformations

3.1-???Time transformation

Specifically for time periods, SAP is now proposing a so-called simplified function, IBP_TIMESHIFT, which allows you not to use any more attribute transformation, to get values from different periods. This is great as this function is really simple to use.

See the below example of past sales key figure being populated from actual sales, 12 months in the past, here defined in a technical week therefore 62 periods.

No alt text provided for this image
Key figure formula avoiding time attribute transformation

Therefore, I will not show anything for time transformation. This said be aware that in your current planning areas, you are likely still using time transformations because you created them before the new function IBP_TIMESHIFT was created by SAP.

My advice, in case you need to do anything about these key figures using the time transformation, is just to replace the logic with the new function. Delete the additional planning levels and enjoy simplicity.

3.2-???Product transformation

In this new case, we wish to transform some of the non-time attributes, like product ID, location ID, or customer ID while reading data from the database.

Say you need to read the inventory position of a component when displaying production component requirements in an Excel Template.

In fact, in the planning level WKPRODLOCCOMPSRC, where the component is defined in IBP, the PRDID links to the output product and the component to PRDFR. If you attempt reading inventory from planning level WKPRODLOC, which keys are LOCID for the location and PRDID the product, using the available information of your current planning level WKPRODLOCCOMPSRC you will retrieve the inventory of the output product, not the component ?.

COMPONENTINVENTORY@ WKPRODLOCCOMPSRC = PROJECTEDSTOCK@WKPRODLOC

*additional input to resolve SRC and COMP indeed

This formula does not work as PRDID(output product) on the left (of =) is used to read data on the right (of =)

You definitely need an attribute transformation here.

3.3-???Alternative way to avoid transformations

If we step back, you can also consider the alternative of using a different planning level that complies with what we want to do in keyfigure formulas. For instance, you can use the reverse planning level to create your custom key figures and better use planning level WKPRODTOLOCCOMP, which has the output product defined as PRDTO, and component as PRDID. In this case, no need for any transformation as PRDID is the component! Cool, isn’t it? ??

4-??How to proceed to create attribute transformation

Unfortunately, sometimes you have to go with attribute transformations. Bad luck!

In SAP documentation, you will find a useless detailed example about time transformation, which does not help as IBP_TIMESHIFT exist on one hand, and the period transformation is the easiest case.

In Google, you will find other articles, however not easy to read nor the case you wish to model.

I will not be better than the other writers, however in brief:

1-????You need to create a new planning level dedicated to the transformation. Be aware that attributes of this special planning level must be carefully managed, by only selecting attributes involved in the transformation. This is at least our last experiment. Really bizarre!! If you select all normal attributes, the transformation fails or does not return the expected results. Say we create WKPRODLOCCOMPSRC2

2-????You maintain your target key figure as per normal, and source it, by formula, from the new planning level above.

3-????You create a key figure of type attribute transformation (bizarre, it should be an attribute isn’t it??) where you mention what transformation must happen. In our previous case PRDFR@ WKPRODLOCCOMPSRC2 = PRDID@ WKPRODLOCCOMPSRC

4-????You assign as additional inputs of the formula for this transformation, only the key figures that will trigger the attribute transformation.

5-????Be aware that IBP thinks the reverse. In standard, like Excel, a formula pulls data from other cells. In IBP the attribute transformation behave in push, like in Multiplan in 1990. See in the above example, in the logic you would state that my product ID = my component ID, however, the formula has to be set the other way around PRDFR@ WKPRODLOCCOMPSRC2 = PRDID@ WKPRODLOCCOMPSRC.

5-??A possible simpler future

Because I am convinced we are too many struggling, I have placed a SAP Influence #306535, to request SAP a new function IBP_GETDATA() to do similar job compared to IBP_TIMESHIFT however on the other attributes. I did the same in the past which hopefuly contributed to the IBP_ TIMESHIFT creation by SAP.

If it works, that would save days of cumbersome setting and testing for sure, and likely better performances. Remember to vote on this influence item, even if it is a techy one.

Syntax:

IBP_GETDATA(SourceKeyf@SourcePlevel, period attribute, PeriodID, key1 attribute, Key1 Value, key2.., key3.., ...)

With :

  • ?SourceKey is the key figure to get data from
  • ?SourcePlevel is the planning level source
  • Period Attribute is the target time granularity according to the available time level
  • PeriodID is the time index to the source period
  • Key1 Attribute name, being the name of the attribute to use to read source data
  • Key1 value, being value of key1 to address the targeted data
  • Key 2..., Key3... up to 10

?

Enjoy IBP!

?If you like this article, “Like” it, “Repost” it, “Comment” it. We grow by exchanging opinions!

#SAP #IBP #S4 #SUPPLYCHAIN #RESPONSE #ATP #SOP #MRP #BOP #OPTIMIZATION

Daniel Lellouche

Principal Consultant and Architect at Camelot Consulting - Senior Manager

1 年

Don't be shy about commenting or asking! This is my pleasure.

回复
Walter Reynders

Independent SAP IBP expert

1 年

The annoying thing about attribute transformations is that the planning view filtering does not work properly. I used it when product substitution was not yet supported in the analyse supply usage key figures. And in order for it to work, the planner had to include both the predecessor as the successor material in his filter.

回复

要查看或添加评论,请登录

Daniel Lellouche的更多文章

  • To Fiori or not Fiori

    To Fiori or not Fiori

    SAP will not let you choose however it is not a bad idea to analyze this statement. Since the S4 release, whenever I am…

    4 条评论
  • SAP PP-Predictive MRP, something to know!

    SAP PP-Predictive MRP, something to know!

    Since the SAP S4 release, many evolutions have been incorporated into Finance, Sales, etc..

    14 条评论
  • Balancing and Optimizing Inventory Positions in a month, even less!

    Balancing and Optimizing Inventory Positions in a month, even less!

    If you like this article, “Like” it, “Repost” it, “Comment” it, we grow by exchanging opinions! With such a title, you…

    6 条评论
  • The survey "Need your help" results and the simplicity paradox!

    The survey "Need your help" results and the simplicity paradox!

    Interesting! Although no LinkedIn profiling allows me to better understand the audience, the rough results are very…

  • IBP time series, by the campaign side!

    IBP time series, by the campaign side!

    IBP time series being capable of closing requirements in the field of campaign planning may surprise some of you! Me…

  • Do you know SAM?

    Do you know SAM?

    SAM is a nice guy who invests time to simplify the boring parts of other colleague's jobs. SAM has recently had an…

    2 条评论
  • Customer, to be or not to be, in Tactical planning??

    Customer, to be or not to be, in Tactical planning??

    For many years, I have been involved in supply chain planning solution design, being in PP, APO, or IBP, a recurrent…

    2 条评论
  • Go Virtual Master Data Type in IBP!

    Go Virtual Master Data Type in IBP!

    Supply chain is not a virtual thing, Daniel! It is concrete, made of processes, master data, and transactional data…

  • Querying IBP data from Excel via OData API Webservices

    Querying IBP data from Excel via OData API Webservices

    My recent post about connecting IBP and Excel by means of API raise about 40 comments, and 5500 of you read the…

  • PLAY CONCERTINA WITH SPORADIC DEMAND!

    PLAY CONCERTINA WITH SPORADIC DEMAND!

    Depending on your business sector, you may roughly catch what this title means. For the others, let’s use a French…

    2 条评论

社区洞察

其他会员也浏览了