Sage 100

Customer is on Sage 100 Advanced v4.05. Against my advice their IT consultant/ CFO's brother has gone through and begun a test conversion. During the pre-migration apparently they committed a myriad of IA adjustments created by the pre-migration utilities. Naturally they now want to know how to undo these hundreds of thousands of dollars (and quantities) that the pre-migration posted. I'm thinking the only viable way (short of restore from backup which means several days of re-keying data) is to reverse the IA through transaction entry. Has anyone had to deal with this type of issue before and if so how did you correct?

I would look at a crystal to export all the IA Transactions along with the unit cost and reverse that by importing it back in as a negative receipt (since I don't think you ca import adjustments )

To clarify I would import that int the inventory transaction table as a negative amount transaction type of RECEIPT

1st thing that comes to mind is to create a Tranaction entry using crystal and import using Vi to import to back it out via Inv trans entry

You should be able to pull and parse the data for a VI import from the text log that is created. I believe the logs are written in the source IMxxx folder.

Good thinking David!!

Thanks - now on to the fun part of explaining why there's a charge for fixing the self-upgrade botched job. You try to be a ""nice guy"" and not nickel and dime a customer for every call but little by little you're drawn into a point where you are practically doing the upgrade -- or at least portions...

Tell them you would fix it for free if it was you who had done the upgrade....

Theresa is right. And it is not hard to justify. Just tell them that they can spend X man hours manually entering that and hopefully they don't make any typos. Or they can pay you to come to the rescue

I personally would do it as an Excel query after getting paid in advance to do it. Too bad their IT department didn't do it in the test company first, but then he wasn't getting paid the big bucks to do it right the first time. Let him dangle a while.....

Perhaps just say outright this type of service doesn't fall under any support they prepaid for on the annual Schulz Plan given they went against your original advice. Then maybe this: Pass along this high level info already mentioned here on how to fix. This way you're positioning yourself as a nice guy who's looking after their interest. Also in the same email mention your premium price for fixing if they can't make it work themselves. This way I think you've given them 2 options implicitly and even with Option 2 you're still thought of as the guy who tried to be helpful and then CFO (the smarter brother) realizes it was an expensive lesson for them. I dunno just thinking out loud.

I logged in to have a look and it seems odd but the IA adjustments don't seem to have impacted their qty on hands or their GL. I can see that there is a detail transaction for about -1,400 items but their on hand quantity seems to have stayed stable and I can't see where there was a GL entry made to support the adjustment. The only thing that looks odd (so far) is the detail transaction report showing the qty adjustment but that does not for some reason seem to have impacted qty on hand. We also ran stock status and valuation and both those don't seem to have been impacted by the pre-migration utility which kicked out an IA adjustment. Seems weird.

The balancing utility is similar to IMZBL1 in dealing with out of balance items. It lets you choose which balance you want to change and so it makes sense that the quantity on hand didn't change and the utility does not write to the GL. It just attempts to fix the out of balance situation by changing the balance you choose for it to change which in this case be might the warehouse balances file. I don't think it will change the costing tier file.

The question I would have it how did this company get 1400 items that were out of balance?

In this case the Pre-Migration utility effectively made ""one-sided"" IA entries only to IM5. It does this by design if you tell it that the IM2 whse qtys or IM3 tier qtys are correct AND on that pre-migration utility screen the IM5 trans qty is different. It doesn't write to the G/L and leaves no audit trail in MAS at all. It's just the text file(s) in the IMxxx folder of the source system. Save the text file(s). On a support call 2 years ago where the client was a public company their auditor was auditing their 10Q filing or something and caught the discrepancy and couldn't find the supporting source journal in MAS. Thank god we hadn't deleted the old 4.05 installation and hadn't deleted the text files.

I am guessing that I'm confused because the customer looked at a subset of their detail which included a large ""plug"" number to make the detail agree to the total qty on hand. The confusion -- I think -- is the customer did not run the detail report for all history and I suspect that if they did they'd find that the matching utility made the plug so all the detail agreed to the total. Going to check this AM. Thanks for the info - greatly appreciated.

I went in this morning and looked at the detail report. Customer has about 1/2 dozen records with no date which were not showing on the Inventory - Detail Transaction report until I used a blank start date. Once I did that I could see that the detail transactions were in agreement with the summary.