Jobs 118229-1-1, 118230-1-1, and 118231-1-1 all read the same. We’ve run the recon for 118229-1-1 and 118230-1-1 with the same results. I’m figure 118231-1-1 will do the same, but am saving it for testing.
What the heck? It looks like the recon is fixing something when it runs.
The WIP Recon does do some processing similar to Capture WIP/COS. But I always thought that WIP Recon only did that on a temporary basis. Just to make the report show like it should be after running Capture WIP/COS
Was Capture WIP/COS run in between the runnings of WIP Report? It looks like some timing issues may have existed, and the Captur WIP/COS straightened them out (things that were going to go to variance, now go to COS, Orphaned dollars in WIP, etc…)
No they hadn’t run the cost capture at the time. The change occurred in two separate instances where the WIP Report/Recon/WIP Report sequence “fixed” the odd negative WIP numbers. They ran one before I got there, and then I ran one while on site. They ran the cost capture after I left.
Dunno. Wondering if this might be an Epicor issue fixed in subsequent releases.
Another observation: the costs on JobAsmbl looked good for all three jobs–two had been “fixed” on the WIP report and one had not (still showed the negative WIP).
