Sage 100

A client contacted me today with an AR problem. They were posting cash receipts and apparently did not realize that there was a problem. The posting hung up and the batches did not fully post. Basically, the amounts posted to G/L but did not fully post to the A/R subsidiary ledger nor the A/R cash account. Now their A/R Trial Balance and A/R Agings agree with one another but are off about 108K with the G/L. The batches are still sitting in Cash Receipts unposted so we have a couple of choices: 1. Post these batches and the result is to post to the G/L again. We then reverse the G/L entry so the aging balances with the G/L control account. 2. Post these batches in a backup company and then copy the A/R module over into the production company. Has anyone ever seen something like this happen before? What would cause the system to partially post then bring the batches ""back to life?"" And I would appreciate opinions on one of the two proposed solutions.

I know that in some of the register updates, the GL file gets created before some of the rest of the updating is done. So while the update may have crapped out before finishing in AR, the GL portion was created just fine. If you can restart the update from where it was at (assuming it says it was interrupted), there is a good chance it won't even create the GL files again. But even if it did, that's the option I'd go for - I'd far rather just make the small adjusting entry.

Also, sometimes when an error happens near the end of day - a GL posting will be out of balance one way, then when you manage to get the update to finish the next day (and forget to change the date back), you'll have another GL posting the second day out of balance the other way. Taken together, they balance.

Chuck - to correct... (first make a copy of the live company and test this in the copy) ..... after updating the batch, don't update the daily transaction register. Then using data file display and maintenance, navigate to MAS_XXX, GLXXX, GL_DailyPosting. Manually delete the entries related to the cash receipt. If there are no other entries in this table other than the cash receipt it may be easier to reinitialize it.

We're also a bit puzzled at how this could happen. The customer uses MAS 200 v4.5 workstation on this machine, (Not Terminal Services). With a thin client, what sort of event could trigger this sort of update splatter?