Problems with FIPP Release - School Boy Error

[Mark Pyc]

G'day all,
 
Must not have had my head screwed on right when I was looking at this.
Thanks to Nat for replying anyway.
 
The problem was the use of a decision step rather than using FIPP.RELEASE.
It worked as longs as the document is never set as complete or if it isn't
changed after it's marked as complete. If however a document is completed
and then changed FLAGRELEASESET does not work.
 
Two options:
1) Use FIPP.RELEASE rather than a user decision.
2) Include a call to FIPP.RELEASETIMESET after the decision to release and
before FLAGRELEASESET.
 
Wonderful.
 
Have fun,
Mark
 
 
>>>>>>>>>>>>>
 
G'day Wugers,
 
Current Release: 46C support pack 47.
 
I have implemented a custom Parked Journal release Workflow.
 
The process works fine if the document is never marked as Complete or if it
is not changed once it is marked as Complete. However if the document is
marked as Complete and is then changed (hitting save without any data
changes is still considered a change) the method FIPP.FlagReleaseSet fails.
It fails to set the document as released but it doesn't raise an error. The
knock on effect is that the background post fails.
 
Drilling into the method a few levels shows that there is a check ensuring
the update time stamp (VBKPF-UPDDT/UPDTM) is not greater than the release
time stamp (VBKPF-RELDT/RELTM). It seems that the update time stamp is set
when a document is changed after completion, but the release time stamp is
initial since it hasn't yet been released.
 
The method does not return this as an error. In fact the code comments
state
that this situation must not be returned as an error. Instead it passes
back
an error message number (134) as the return parameter (definately not the
normal use of a return parameter) and completes normally.
 
Although I haven't tested the standard solution (WS10000051) I can't see
anything in it's design that would make it behave any differently. I can't
find anything in OSS or archive that seems applicable.
 
Extra details:
My solution relies on BTE2213 to control which documents are WF relevant.
There is no "wait for Changed" handling within the process as the agent
determination is based on Document Type alone and therefore no changes will
actually affect the responsible agents.
 
Any help greatly appreciated.
 
Have fun,
Mark