Best approach for implementing ECM on a VC model for the initial push to production.
- Create ECM in production client
- ALE from Production Client to Dev client
- ALE all components from Dev to Production Client using ECM.
- Do not maintain any components with ECM in the Dev client.
- 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.