Hi there.
We have a series of Documents that we need to make a minor change to - edit the "Assigned Creator" or "Designated User". We wanted to use the Manual Change lifecycle state to achieve this, but after promoting an item into Manual Change, editing, and attempting to promote back to Released, we get a InvalidEffectiveDateValueException "The value of the effective_date property specified for the Document is invalid. A value is required and it must be greater than or equal to the today date.". But we would like to keep the original prior effective date.
When saving the edit while in Manual Change, we can see that the Release Date gets cleared. So perhaps attempting to promote back to Released when there is no release date set is causing the effective date to get checked?
So: 1) Is using Manual Change the correct approach to making a minor edit, such as changing Designated User? 2) How can we get Manual Change to work without causing the released and effective dates to get updated to today?
Using v11 SP 12. Thanks!
Jared -
If I understand correctly, you want to go into an Item and modify it (minor modification - just property changes, Designated User & Assigned Creator), without modifying the Release and/or Effective Date on the Item.
With the OOTB configuration and behavior of Product Engineering (PE), this is not possible, as you have discovered.
I am going to investigate more to see if there is anyway around it, but off the top of my head, this appears to be a behavior that you would need to modify the interaction of the Lifecycle and the Release/Effective dates or come up with some method code to accomplish. Any user interaction with the Configuration Items (Parts, Documents, etc.) is going to trigger a new Release/Effective Date because of the actual "change" to the item.
I am working on a solution that is outside the "OOTB" - stand by!
Lisa
Jared -
I have reproduced what you are seeing. I have another question for you as I look into this further, is this a one-time thing that you need to do or is it a regularly occurring need? The answer could change based on your response, obviously.
Lisa
Hi Lisa, thanks for looking at this.
I can certainly see it being an ongoing need... Changing minor details such as the creator seems to be an ongoing need as we continue to refine our implementation and add users the system. It really seemed like Manual Change was built to do this type of thing, so the error message seems strange.
Please let us k ow what you find out. Thanks!
<p style="text-align: left;">-- Jared</p>
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
Thanks for continuing to look at it, Lisa!
What you say makes sense, however the out of the box MCO workflow seems to do exactly what we want, just for the Approved Manufacturers List - that's how we came up with the idea that this should be possible. If you start an MCO, the part moves into Manual Change, then you can edit the AML, then when you release the MCO, you end up with a released part that has the new AML but retains the original Revision number along with the original Effective and Released dates. The Modified By/Date fields as well as the History reflect the change, which is great. Is there a way that we can replicate whatever magic that makes that work?
Thanks!
Jared -
Yes, the MCO. The MCO is meant to allow you to change the related ALM list without changing the related part's revision or effective date. In that case, you aren't actually changing the related part or internal part at all, you are only changing the relationship(s) of that part to Manufacturing Parts, that's why it works the way it does. And, unfortunately, as you have discovered, that does not translate to making changes to the Part Item itself.
Sorry!
Lisa
