Transfer of data from one system to another using ALE

[Former Member]

Hi,

I had created some classes in development system than transfered them to productive system through ale, and in productive system there is lots of trasaction data is created , many sales orders etc .

now after some time my user requested that they want to delet some of the characterstic from the classes , so in development system its not a problem as there is no transaction data , i can straight way delet the characterstic from classes, ignoring the request to check wheater its used in configuration or not.

but when i transfer this classes to productive system through ale, i got a error that as all this characterstic s are used in past i cant delet them , and after that system ll put all the characterstic in the top of classes , ie, neglecting the earlier sequence of characterstic in class.

we have ecm activated but its limited for changing material and boms only, for changing classes and characterstic its not in scope.

so can you think of some solution for this problem .

thanks in advance.

regards

[Ritz · Accepted solution]

Hi Dear,

its possible only with the help of ECM , you need to do some work around too.

ECM should be extended to include the classification. In fact, the EXACT SAME change number should be used. In PLM, it's important that all of the changes related to a material become active in a cohesive unit. We can talk about those details if you need some background.

Unfortunately, in the split-client scenario, you're toast on any hope of using the same ECM number, due to the internally defined number range. The best you can do is create a new, externally assigned number range in the production client, and generate the number internally in the staging client. You can then make the change in the staging client and ALE it over to the productive client.

The next nasty part is going to be retroactive changes. You can't simply back-date a change. You have to change every occurrence of a dependency, class, characteristic, etc, that has existed in production as of that back date. So, the smartest practice is to never allow any back-dated changes. Require orders to be cancelled and re-created with the new effective date.

Check and revert back.

Regards

Ritesh