SAP

I just discovered something interesting that I never noticed before.  During some testing for an upcoming go-live, one of the people in our team noticed that in an plant that uses the material variant, but doesn’t produce it, you can see the configuration within the sales order.  The configuration is completely grayed out, so no changes can occur, but still behavior I didn’t realize.

This little tidbit has some interesting side effects and possible benefits.  The first and most obvious is that your order entry person can easily see the configuration of a material variant if they want to see what options are select.  Now, one of the key things to keep in mind, if you want this behavior, you now need to maintain the characteristics and values in all plants.  This is always a mixed bag in my opinion.  Typically, I encourage clients to only maintain the material variants in plants that produce the material.  The reason is that for any changes to VC logic that impacts the characteristics and values needs to be updated in every material variant/plant combination.  This can quickly become a big data nightmare if you have many plants and variants.  If the number is manageable, it’s not such a big deal, but it is an extra piece of data to maintain.  It also means that you need to be careful if you need to have any plant specific logic incorporated within your materials (again, you hope to avoid this whenever possible in the model).

The short story, it could be a mixed blessing to have Material Variant information available within the sales order.  Potentially valuable, with master data maintenance repercussions 🙂

Thanks, for reading,

Best approach for implementing ECM on a VC model for the initial push to production.

1. Create ECM in production client
2. ALE from Production Client to Dev client
3. ALE all components from Dev to Production Client using ECM.
4. Do not maintain any components with ECM in the Dev client.
5. Maintain all models in production using the change number, or create new change numbers for each change.

Let me go into more details.  For step 1, the ECN must exist in the target system before any ALE is processed.  This allows every object to be instantly placed under engineering change management.  The only exception will be table structures and function structures (they don’t have the option of ECM).  In addition, routings, reference operation sets, etc do not need to be placed under engineering change management, but it is highly encouraged.  This will be based on your business rules and what is commonly done in your organization.

In order to perform certain ALE steps, the change number must exist in the source system.  It does not need to be assigned to any objects, but for the ALE transaction (like BD91 or BD92) you will need to have the change number exist in both the target and the source.

Now, to demonstrate, I used a test system to create a characteristic without ECM.  Then I’m going to make a change to the cstic and place it under ECM.  I created TEST_CSTIC and gave it values 001, 002, 003

Then I created the change number: 500000000000

Went back to TEST_CSTIC and added 004.

I then created 2 dependencies to reference this characteristic.  The first one under ECM at creation, and the second created without ECM, and then placed under ECM.  I was still able delete a value from the characteristic despite the dependency existing at 00/00/0000.  Keep in mind, the system is far more likely to give you grief when you don’t have everything under ECM control at initial creation.  There are OSS notes to be found that talk about cleaning up items without ECM, but if you can avoid the hassles, I strongly encourage it J  Happily, as of EHP4, it seems that SAP has cleaned up the integration with change numbers if they are applied after the fact, but this could quickly change once it’s connected to multiple items with mix and match ECM.

Here is something to be aware of when doing a drop down search.  You will see this behavior in searching in some transactions, like object dependencies.

Look closely at ECM_TEST_2.  It’s the same dependency, but it shows once without the change number that has the 00/00/0000 date, and again after the change number was applied.  Based on the date you enter in CU03, you can see both versions.  In previous version of SAP, this could cause issues trying to remove or delete items that existed in the 00/00/0000 date from, but from my testing in the EHP4 system, these issues appear to be resolved.

Regardless, it is still advisable to initially create all objects with ECM.  If you don’t do this with the ALE, you will need to manually make a change to every object with a change number in order to lock it down and prevent changes from occurring without ECM.

I have had to do this before and I typically use Gui Scripting to make a minor description change or add a comment.  It’s not pretty, but it can be done.