Forum Discussion
Former_Member
7 years agoAccelerator III
Jared -
Okay, if it was a one-time thing, we were thinking that an SQL Script could solve the issue.
Since it is an ongoing thing, there will need to be a configuration change to how the property Effective Date behaves for your implementation. There are default rules in the Product Engineering (PE) Application related to CMII behavior that is not going to allow you to use an Effective Date earlier than the Manual Change that you are doing. I tried many ways and could not get around it.
Your are correct that the Manual Change is allowing you to make a minor change and not up the Revision. It is still considered a "change" to the Item, however, so it is not allowing you to keep the original Effective Date. It wants the Effective Date to change to the new version of the Item, even if the Revision didn't change.
Effective Date and its behavior is part of the core PE capability. I've spoken with a colleague and he recommends that the best approach would be to create your own custom property for Effective Date, hide and stop using the OOTB Effective Date, and create the custom behavior and logic that you need for your Effective Date custom property. The OOTB Effective Date drives and is driven by many of the PE OOTB processes and behaviors, it would not be a simple matter to change its logic as part of PE, there are too many dependencies.
Hope this explanation helps.
Thanks,
Lisa