When researching these problem JVs the selection screen for the workflow table, SWIWIOBJCT, should be:
(company code, document number, fiscal year)
Fields of interest are:
Work item text, Task text, Status, Creation date, Creation time, Agent & Task.
In 4.6C ZJVSTAT can be run to find these problem JVs.
Limbo JVs - not in an approver's "in box" and not posted - found by comparing the report from ZWFJV with the report from FBV3 and researching the ones that appear in FBV3 but do not appear in ZWFJV. If the JV that appears in FBV3 is not rejected and still does not appear in ZWFJV then it is by definition in limbo. The parameters for FBV3 are X for "Enter release" and "Complete" and blank for "Released". After the 4.6c upgrade FSS will create a report to find these "limbo" JVs. I would also like to find out why they are happening. Below is an example. This is a parked document with no workflow (No service available):Notice that the posting date is long after the document date. This was modified by the approver via FBV4 (Change Parked Document Header) to change the posting date so it could be "completed" and "released" and posted. Kyriakos thinks that when the approver modifies a parked document it confuses workflow and can cause these "limbo" JVs. This eventually showed up in workflow after a long time delay! Here is a production "stuck" parked JV (it has 3 'X's, "release nec", "complete", "released") because it was last changed on 10/17/00 by the approver who tried to post it. Since the fix for this "stuck" problem was put into production the morning of 10/19/2000, they got no warning that it would not post (9/28/00 was a closed period).
But if you look at workflow it looks like the posting did not take place until 10/20/2000:
It looks like it was lost in workflow for three days!