Supply Chain Management Blogs by SAP
Expand your SAP SCM knowledge and stay informed about supply chain management technology and solutions with blog posts by SAP. Follow and stay connected.
cancel
Showing results for 
Search instead for 
Did you mean: 
JuergenPitz
Product and Topic Expert
Product and Topic Expert

Due to the regular questions and discussion in SCN I decided to write down some of the aspects to be considered when transferring material master data from an SAP ERP system to SAP EWM.

The title says "Part 1", as there are some aspects I do not include in this document, but I might write another document when I find the time.

Meanwhile this document is a little bit outdated, as there where changes in EWM which affects this, so I have amended or updated the text below.

First things first: the ERP system is the leading system and you have to transfer the material master from ERP to EWM. It is not intended to create a material new in EWM and there is no standard way to transfer a material created in EWM back to ERP. Also changes done in the product in EWM are not reflected back in ERP.

For the transfer ERP re-uses a tool developed for the integration of ERP and SCM (formerly named APO), called Core Interface – CIF. As EWM was developed on a SCM base, it was simply decided to re-use CIF for the master data. EWM needs movement data as well, but for this a separate integration model was build. CIF can also transfer movement data, but only for APO purposes, not for EWM.

Master Data for EWM transferred through CIF means

- material,

- plants (if required),

- batches (if you have material with batches),

- customers,

- vendors,

- shipping points and

- classifications (for material with batches).

See Picture 1 (Note: this picture shows a reduced selection screen for CIF. This is because the target system is marked as a “SCM Basis System”, not as an “APO System” – which is enough for EWM).

Pic 1:

I will not explain how to work with CIF in general, there is enough documentation about that and there are also some aspects from an administrative side to consider, so this is a different topic.

What you have to do when transferring the material you have to flag the field for material and you have to enter selection criteria to select the material (see Pic. 2). Whatever selection criteria you use is fine, but rarely you will transfer all materials (which would mean to enter no selection criteria), that means you have to give it some thoughts how to select the materials in the most effective way.

Pic 2:

Next to the flag for material is a flag for plant. When you set this flag, you also should enter a plant in the selection area. This way you do not only define a selection for the material, but also for the plant you transfer. If you would not enter any plant, all plants in your ERP system will be transferred to the EWM system and exist there as location (Pic 3).

Pic 3:

Now the first question is: why is the plant next to the material? And not in the same section as the shipping point or the vendor? And the next question is: do we really need this?

For this we have to look at the material master. The material consists of several fields, these fields are organized in views. Views describe for which aspects the fields on the view are being used (for example sales or accounting) and are therefore assigned to the corresponding organizational units (like the sales area or the company code).

For CIF two groups of fields are relevant:

  • Fields on client level, like the material name, weight, etc. (basically everything in the table MARA)
  • Fields on plant level organized in the MRP views

When the material gets transferred to a SCM system, you can check the products (as it is named then) in a transaction /SAPAPO/MAT1. In this transaction you can distinguish between a global data view and a location view (Pic 4).

Pic 4:

The global view (which is then simply the product) corresponds to the data on client level in ERP, while the location view, also called a location product, which requires that you enter a location as well, shows the information which is maintained on the MRP views, that means it always refers to a plant.

The important thing when you use EWM is: we do not need this information, we do not need a location product. It is very important for a SCM system when you use APO functionalities, to have a location product, but EMW only needs the product. So you can reduce the data which is being transferred to the EWM system significantly if you choose to transfer the client level data only. The question is how to do that.

First of course you do not mark the plant to be transferred. Still you can enter a plant as selection criteria for the material, this way only materials for which views referring to this plant are defined, are transferred. The next thing is to enter a warehouse number in the selection field “Warehouse Number” (Pic 5).

Pic 5:

This field is a marker for CIF that the target system is an EWM system and that no plant data of the material master is to be transferred. If you have still marked the plant to be transferred and entered a plant as selection criteria, this plant will be transferred and a location will be created – but no location product.

You can not simply enter a warehouse number in this field “warehouse number”. In order to select anything here, you have to maintain the mapping of the ERP warehouse number to an EWM warehouse number. This is a separate table in customizing. Actually it does not matter what you enter in this table, it is not checked if this really is a warehouse number in EWM or not (but for consistency I would recommend to maintain this properly). It also does not matter if you have more than one EWM warehouse in which the material is stored, you only transfer the material master once, the product is then working in all warehouses in that EWM system. So you can select any warehouse number which is maintained in this table.

Conclusion: you make no mistake when you transfer plant related data for your products to EWM, but it is always worth to think about how to reduce the quantity of master data sent from one system to the other.

Update: From EWM9.2 unfortunately the importance of the plant related data has changed a little bit.With the deeper integration into QM processes, in the warehouse product (which is explained below) there is a new field, "GR Block". This field can be set directly in EWM, but it can be set from ERP. The field used in ERP for this is called "QM Procurement active" and the "QM Control Key" - and these fields are on the tab "Quality Management", and this tab is plant related.

That means that if you want to use this feature of transferring the GR block from ERP, you must NOT enter the warehouse number in the selection screen.

Funny enough: if you never transfer the plant as location, still EWM does not create a location product.

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

WM views vs. Warehouse Product

OK, now you have transferred the product from ERP to EWM and you can start working. But wait, there is something else.

A material in ERP consists of several views, two important ones in regards to warehouse management are the views “Warehouse management 1” and “Warehouse management 2” (just called WM views in the rest of the text). If you use WM and want to store the material in a warehouse, you have to have the views maintained, otherwise you will get an error message. For example when trying to post a GR for a plant and storage location combination which is connected to a warehouse number, the system will come back with an error message, saying that the material does not exist in the warehouse number, if these views are not maintained.

“Maintained” means that the views are created with reference to the respective warehouse number, it is actually not necessary to fill any of the fields on the views.

The CIF does not transfer the WM views. There are also no “WM views” in EWM, but there is a “Warehouse product”. Now, technically, a “Warehouse product” is actually the same as “WM views”. You extend the product by additional information, and this information refers to a warehouse number and a party entitled to dispose. So when you “create” the warehouse product, also in EWM you just create additional information to the product.

Other than in ERP (where you “extend” a material by simply creating new views, but always with the same transaction), in EWM a separate transaction exists. Why is that? Because for SCM / APO you need a product (and the location product described before), but there is no use for a warehouse product. So for SCM / APO customers nothing changes, also the standard product transaction does not change. The new transaction is only important for EWM customers.

But the real important difference between the WM views and the warehouse product is: you do not need a warehouse product in EWM. EWM can work with the product only. You only need a warehouse product if there is something in the warehouse you want to control through the product. There are a lot of things you can control through the product (like the storage type sequence for putaway or picking, or the storage section sequence, or the determination of the warehouse process type) – but putaway and picking and most processes are possible without a warehouse product. So it should always be considered if you really need a warehouse product. If only 20 or 30 percent of the products are in any way using a field of the warehouse product – it means that 70 or 80 percent of the products do not need a warehouse product, and that is a lot of master data which does not need to be maintained.

What possibilities are there if you want to have a warehouse product or if you need one as you want to control processes in the warehouse through the product?

- For customers which are migrating from an existing WM to EWM the transaction /SCWM/MIG_PRODUCT is interesting (you can find this in the EWM Easy Access Menu under “Interfaces --> Migration from LE-WM”). With this transaction you can (next to some other things) create a Warehouse product in EWM from the WM views. But this means that all the control flags (like the putaway control indicator or the section indicator) have to be the same in your EWM warehouse number as you used them in WM. Well, in case you do a simple WM-->EWM migration it probably is.

- Someone in the forum once described a method how to extend the CIF and how he created the Warehouse product through that (http://scn.sap.com/thread/3420123).

Personally I find both methods… questionable. OK, it is nice for a quick move over from WM to EWM – but why do you change if you do the same things as before anyway? And my absolutely nightmare is that customers continue to maintain WM views…

- A nice way to create the warehouse product is the use of slotting (http://help.sap.com/saphelp_ewm92/helpdata/en/4b/c46aed5a304b41e10000000a42189e/frameset.htm). You do not have to make use of all the possibilities available in slotting, but what slotting will do is that it will create a warehouse product in case none does exist. And so you can use very simple condition records in order to get your warehouse products created and certain information filled. Slotting can not fill all fields available in the warehouse products, but once the warehouse product exists, you also can do a mass change after that.

- And of course there is the manual creation of the warehouse product through the transaction /SCWM/MAT1. If up to now you have a procedure build to create the WM views (meaning you use a workflow or any other method to have users maintaining master data), you can consider adapting this procedure for the maintenance of the warehouse product, but it should be extended by the question if a warehouse product is really required.

Update: Since EWM9.2 there is a flag in the warehouse number settings, "Control CIF Behavior". If this flag is activated (means the entry is "1"), then the warehouse products for the materials you transfer via CIF are automatically created. The reason for this flag is the QM goods receipt control which is available since that release.

26 Comments