A while back a few of us reported a similar problem with SO-A (Enter Sales Order)
 
I'm not aware of us getting such an error in SO-A for quite some time. But it also usually faulted with a 20202020 but it was reading instead of writing.
 
The cause is almost certainly an uninitialized pointer. But... why? The world may never know... Since this seems to have disappeared in SO-A (anyone correct me if I'm wrong) it would appear that either ISTech found the problem in SO-A or that somehow some other change that they did made that particular bug disappear.
 
If you are getting the error consistently then it would be best if you could find the exact spot it dies at (if its the same spot every time.) Also, you could try to do the operation the test company and see if it still blows up.
 
Also, what version of DBA Classic or Evo are you using?

My suspicion is that there is a record in WOMAT with a corrupted date which is causing the report to blow up.  Try opening WOMAT for your company in Maintain Database.   If there is a corrupted date entry, the DBA Classic version of MDB will crash if you go to beginning and end of file  using the date index.  If that is the case, opening the same file using the Evo-ERP Maintain Database will allow you to find and fix the record - it will be either the first or last record in the file when sorted by date.

You should be using JC-M to reconcile WIP balance to GL, not JC-P.  However, JC-M uses the same WOMAT transaction file as JC-E so if there is a problem with that file, JC-M may blow up as well.
 
JC-P WIP value will not reliably match GL and may not even come close unless you never do any partial receipts from work orders and always close work orders at the same time as Enter Finished Production and do not track Labor on Routings.