R42800 and Duplicate G/L Batches

[creeceRx]

It looks like a user has ran the R42800 program against orders that were at a 999 next status, it has created duplicate Batches and then finance posted this again. So now there are duplicate g/l entries for each invoice as well as it has duplicated the amount taken out of inventory and the lines in the F42119. Does anyone have a suggestion on what the easiest way is to offset this? Can the second batch simply be retracted somehow?

Corey Reece

 

[pfd]

It will be a painful task to correct this. This is what you can do.

1) You have to delete the duplicate batch records from F03B11 and F0911
2) Run a query to figure out the items and quantities that were deducted from Inventory twice and then do an Inventory adjustment to correct Inventory
3) Delete the duplicate records from F42119
4) Run R099102 (Repost Account Ledger) in proof mode first. Once you analyse the pdf generated and you feel comfortable then run R099102 in final mode. Nobody should be posting in the system when you run this in the final mode. You can search on Knowledge Garden for white papers on R099102.

Good Luck,
Matt

 

[dschlieder]

To prevent this in the future you should insure that all versions of R42800 run in a single threaded queue.

I didn't think you could run it twice two separate times and have this happen - but if you run it concurrently this can happen as both jobs are selecting and processing the same data.

Single threaded queues will prevent this.

Of course this doesn't help of the user runs the job locally and not on the server.

Dave Schlieder

 

[Shadow]

You may also have to delete the duplicate batch records from F0018.

Sara / B7333