We had this NPI concern shared by some of our customers, so we wrapped our head around a solution. Feel free to comment and suggest improvement, your input is always appreciated!

This article is also available on our blog. For more stuff on IBP and SAP supply chain solutions, click here


A common challenge in an integrated IBP/ERP environment is the new product introduction (NPI) process. The problem lies in the fact that the planning activities for a new product may occur long before it is even created in the core ERP system. Of course, if products are created simultaneously in ERP and IBP thanks to a proper Master Data Management process, what follows is not a concern.

In fact, creating and planning the new product in IBP only is not an issue. The question is: how can we ensure a smooth data reconciliation between IBP and ERP? Manual interventions are often chosen as a workaround solution, but it can quickly turn into a mess.

As far as we know, there is currently no standard functionality in IBP that covers NPI special requirements. This paper is intended to demonstrate how we can easily overcome, with IBP flexibility and Hana Cloud Integration (HCI) capabilities, two common issues related to NPI: the creation of a new product, and then the integration with ERP.

Preliminary notes:

1. We are not addressing the problematic of product substitution, neither Like Modeling, Interchangeability or Supersession.

2. The logic described below could be applied to any other master data type, i.e. for new customers planning.

3. For purpose of explanation, we will make reference to SAP ECC all through this paper, but it could have been replaced by any other ERP system or SAP application.

Standard IBP Model

In a typical IBP planning model, the master data object product relies on a unique key indicator, the product identifier. As proposed by SAP in their out-of-the-box models, this ID is generally sourced from ECC and is mapped against the material number.

This basic data structure becomes troublesome when we have to create the product in IBP prior to ECC. One basic solution would be to temporarily create a product with a dummy ID, but it would then be impossible to update this identifier since the product ID is a key entry in the database. Obviously, we could manage this manually by deleting the dummy product and recreating a valid entry once the material is created in ECC, but unless related key figures data get extracted and reimported with the new ID, planning data would be lost. And this is not to mention the data manipulation risks and the time needed for such an operation.

Solution Proposal

Trying to keep things as simple as possible, we designed a solution based on two configuration points: a minor master data modification in IBP and a conversion dataflow setup in HCI.

Data Modeling

Basically, what we suggest is to use the existing PRDID attribute as a native IBP product number and to add a new attribute for the ECC material number that we will call MATNR for example.

As in standard models, PRDID is defined as the key attribute, while the new MATNR is just a simple characteristic. MATNR is mandatory, but since it is not a key field, value can (and should) be updated as soon as the ECC material number is known.

Here is a simple view of what value should be maintained for each attribute, depending on the scenario that applies at the time the product gets created in IBP.


Scenario 1 is mostly relevant for initial mass upload in IBP during a project cutover, while scenarios 2 and 3 are part of a day-to-day product introduction process in IBP. 

More concretely, for IBP end users, the new product introduction involves the following:

1. The planner first creates the product in the IBP database with a dummy ID. This dummy ID is registered in both PRDID field and MATNR field.

2. Once the product is created in ECC, the planner updates the MATNR with the correct value.  (This activity must become part of the standard product creation process).

3. All Excel planning views and Web UI Analytics must be displayed at MATNR level since this is the more up to date data available.

ID Conversion via HCI

Now, considering that:

  • Master Data and Key Figures are extracted from SAP applications with the material number as key indicator;
  • Data must be imported in IBP tables based on PRDID key attribute;
  • PRDID does not always match the ECC material number;
  • IBP planning outputs are exported back to ECC.

We need to configure an ETL process in Hana Cloud Integration (HCI) that will support a two ways integration flow between ECC and IBP.

To import data in IBP, a transformation task is inserted in the HCI process flow in order to link the ECC material number to the corresponding PRDID key attribute.

Doing so, we have to generate an intermediate product IDs conversion table, built directly from IBP product master data and extracted via HCI. The conversion table is made out of two fields, PRDID and its corresponding MATNR.

To allow data transformation, the conversion table must be stored in the same HCI datastore than the data to be converted. It could be stored for example in a custom table developed in ECC, or either as a flat file on a server directory.

Once all data is repatriated in a common datastore, a simple HCI query can convert ECC material number to IBP product ID.

  • Both SAP source data and the Conversion table are used as Input to the query.
  • A joint between the tables reconciles the IBP PRDID with the data extracted from ECC.

From a more technical perspective, here is a view of the dataflow described above. Keep in mind that this is not an exhaustive table mapping, but rather a rough example with INITIALINVENTORY key figure, just to illustrate in a simple manner how data are extracted from ECC, converted in HCI and loaded in IBP. In this example, the conversion table and ECC data are stored in a common repository. Note that HCI cannot extract data from ECC to a target files datastore. Thus, extraction must to be executed via a scheduled batch job in ECC or with another ETL tool.


Below is the result of such a dataflow, illustrated with a basic dataset.

Image 1.png

Finally, to pull data from IBP back to ECC, the same conversion logic applies on reverse mode, i.e. IBP product number is converted to ECC material number. We shall just mention that it is judicious to exclude entries with dummy MATNR (flagged with a special range or prefix) from the query in order to avoid transfer inconsistencies (i.e. when a product ID exists in IBP but not in ECC).


The main benefit of this solution is to be low maintenance. The only manual action involved in all the process is to update the ECC material number in the IBP database once the information is available. Everything else is processed in the background and is totally transparent for end users. And last but not least, estimated efforts and time for implementing this solution are minimal, reflecting the simple configuration approach proposed by IBP.

To report this post you need to login first.


You must be Logged on to comment or reply to a post.

  1. Jonathan Karczewski

    The concept sounds good. I did something similar to register changes in material master in IBP that would not match the filter criteria of the initial load. However, did you also think about the case that a product still might be created in ECC first? Instead of joining the tables, a lookup could be the better choice.

    1. Philippe Hetu Post author

      Hi Jonathan,

      Few good points here.

      Indeed, we thought about products that could be created in ECC first. This case would be managed very similarly to scenario 1 (where material already exist in ECC). We did not really talk about master data maintenance in this post, but obviously, some background jobs will have to be scheduled to update the product database in IBP. That being said, if a product gets created in ECC prior to IBP, it means that a new record will be created in IBP through one of these job. In this case, ECC MATNR would be assigned as both the PRDID and the MATNR.

      Regarding JOIN vs LOOKUP, I agree that a lookup function could also be an alternative. However, as far as I know on the difference between both functions, I think that JOIN can be faster processing (depending on the number of records) and that JOIN is more suitable when there is more than 1 possible correct match between tables. Can you tell me more on why you consider LOOKUP as a better choice?

      Thanks for your reply!

      1. Jonathan Karczewski

        Hi Philippe,

        in your example, I assume you have a join on MATNR. For those materials that already exist in ECC but not yet in IBP, you need to ensure that this join returns a result as well. You can achieve this by an outer join, but from my experience it is simpler to use lookup and define an explicit default value for PRDID in case you don’t find MATNR in the file table.

        Plus, I had the experience that – at least within the ABAP code block – lookups had a much better performance compared to joins.



  2. E. Meiners

    Dear Philippe, this seems to be a very nice workaround however, as PRDID is used in many planning levels it requires a lot of additional work to re-build the model.


Leave a Reply