For those that are also interested in this problem here is a summary of what we have learned in the past year.

Our problem was caused by a custom PX and manual procedures where the Declaration was incorrectly archived.  We are trying to fix errors outside of standard behavior in an administrative mode.

First, some background.  PG&C was purchase and “shoehorned” into Agile.  It does not have the same standards or behaviors you might expect to find in “native” modules.

Most significantly there is not an administrative role for PG&C where you can make changes outside of the business rules.  The result is that a released declaration is permanently locked within Agile.  You cannot edit: the state or workflow.  We also could not edit the Composition within the compliance tab of the part.  Even if we could do this it is unlikely to fix the problem because it would need to trigger the PG&C process to populate the declaration information (substances, etc.) on the compliance tab.

This leaves directly changing the Oracle DB underlying Agile.  This would require reverse engineering the Tables either the WORKFLOW_PROCESS as Kevin suggests or finding the Part compliance table and changing that.  Kevin’s approach of adding a Manual Next Step is probably the safest.

That being said, directly modifying the Oracle DB is a very risky proposition and not recommend.  You might say it voids the warranty.  We are not going down that road.

The alternatives are:

1. Current Declarations need to be recreated to fix the problem.
2. We are replacing the custom PX and training users on correct procedures.
3. Future: when creating new declarations you can use a modified worklfow that has a Manual Next Step from Release back to Review or Submitted.  This would allow for modification of the Declaration and re-release triggering the PG&C process for attaching it to the part.  [Note – have not tested this yet]

Did you figure this out?  How?

As I understand it, that is how they should work. A declaration is a statement that, “at this point in time”, the specified parts/mfr parts/part families comply with the indicated specification and for the specified substances. You can also define an expiration date on it, but if not the declaration is open-ended, until something supersedes it. From what I was able to find, declarations are usually considered static once released, but given that this is the real world, I would expect the occasional need to go back and correct things.

Note that the workflow data (steps, next steps, current status, who/when promoted, etc.) for a given declaration (or change) is in the WORKFLOW_PROCESS table. If the manual next step is not present in there (and it will NOT be for any existing declarations), then you experience exactly what you are seeing. Adding a new Manual Next Step will *not* go back and alter existing workflow records. I suspect that with some time and study, I could figure out what is needed, but it would require access to the database you are using instead of a generic one. I need to see what the records for the workflow looked like before and after the change in the Manual Next Step.

9 months and no answer.  We have tried to add the Declaration number to the Part:Compliance:Composition:Composition attribute but have not had any success doing this.  Even if we do will Agile populate the rest of the information & Specifications from the Declaration.  Can anyone provide the logic or documentation on how the Declaration was originally added during the Supplier submission process.  Is there a way to re-release the declaration?