Sage 100

Another Decimal issue, Same client (Advanced v5.20.3). Who knows what data entry shenanigans happened here, but they have average costs that are wildly out of control, and even though they don't use average costs, it is causing several reports to fail because their total inventory value is in the Trillions+, or their decimal places are 9+ characters in the DFDM (E+21??). Where do I start? I have run all the IM Balancing utilities and recalculated inventory in some blind hope that miracles would happen, but none will go back to change the actual transactions. I feel like I saw a post on ridiculous inventory values a while back, but can't find it. Do I have any other choice but to purge the bad data or export, modify and import? This goes all the way back to 2014 with several products, and I can pinpoint the transactions that started it all and with average costs not being watched (because they are standard) it just snowballed from there. So as you can imagine, there are tens of thousands or records that would need to be looked at and potentially modified.

We had a v2017 client that uses Standard Costs exclusively, and they experienced the same issue. Their Explorer Views would ""bomb"" because of the crazy Average Cost Values. Our support team opened a ticket with Sage and they provided a ""utility"" to fix the issue. Not really sure what the utility was, or if we had to sign a release document or what. My suggestion is to call Sage; although in re-reading your message it may be something completely different.

Pretty sure it stems back from the old v4.4 or earlier days, and was likely a bug. Looks like we will change the read only costs fields and export/Import data that doesn't bomb out. What a PIA!!

I wonder if they improperly changed their Standard Unit of Measure.

@SteveIwanowski back in the day they had all sorts of crazy unit of measure conversions, so I would guess that was part of the problem, but since most have changed, it's hard to tell what was what.

E+21 sounds like something was imported from Excel, where Excel had truncated a number field. I'm pretty sure the system will ignore anything past the set number of decimal places entered in CI. Units of Measure, specifically selecting the wrong UOM during PO Entry, often is the reason for huge swings in Average Cost. The user enters the correct extended cost, but the wrong UOM causes the units to be way off in one direction, with the unit cost way off in the other direction.

Interesting @ChrisStAmand! Not sure how that would get into the history file unless the field wasn't set to read back in pre4.5? Or maybe they had an ROR before us that ""helped"" At this point, no one is fessing up to anything - no surprise there! We are fixing it slowly but surely and trying to make sure it doesn't happen again.