Has anyone had Epicor ever change # of decimals on a field before?
We are looking at container landed cost entry and creating a tariff type, and the tariff is .125% but the field is only 2 decimals. We are thinking of putting a ticket into Epicor but wondering if anyone had success in the past for similar things?
Yeah, I figured that would be a good place. However, not sure if we will be updating to a newer version to receive a general update prior to needing it. I’m surprised in this specific case that no one has needed more than 2 decimal points of precision on tariffs before.
Is it possible to use extended properties maintenance to add decimal spots? Or is that only for unmasking digits to the left of the decimal?
Does Epicor reduce the default SQL precision and scale to what’s shown in Data Dictionary Viewer (and Extended Properties Maint)?
E.g. 5, for Part.UnitPrice
https://www.sqlshack.com/understanding-sql-decimal-data-type/
Good news is that if Epicor needs to do it, it’s super easy for them to add in the next release. They did it for us on the HTS field, which was also an Aha Idea.
It’s set in the DB for scale of 2. So in this case Ext Props can’t save us it’s not a format in this case.
Nice find.
Thinking one way to bandage this at current version would be storing the proper values at each business object level in custom fields, as the tariff gets added through the various business objects to totals, then using a data directive to change the poorly rounded data at each level to a more precise, first-time-rounded value at each business object level.
Guessing I’ll run into a problem where values are being calculated and not stored for multiple layers in a row.
I’m guessing it would cause some noticeable issues if someone got nefarious, if other fields are limited or rounded based on knowledge of this field being 2 decimals.
Navicat FTW
