Currency CostingPrecision is multiplied by hard-coded value
Description
Environment
Attachments
Activity
Carlos Ruiz January 26, 2019 at 11:45 AM
Hi, the patch looks like an overkill, wouldn't be simpler to change the getPrecision()*2 with getPrecision() in the class MCost?
Regards,
Carlos Ruiz
Norbert Bede November 6, 2015 at 2:55 PM
Thanks Tomas. The main idea came from too "long" cost prices. We discovered, cost price at average costing methods is multiplied by 2 with constant multiplier number 2. We understand this is "problably" because better precision calculation.
I don't like this approach because when we generate Price list from Product Cost, and store to each pricelist limit price - to calculate transaction margins, then in reports we had too long figures.
Instead we design - add Cost Precision and Standard Precision to Accounting schema. This way implementor able to setup per tenant own standard and cost precision.
In our case cost precision was on currency EUR 4 system calculates with 4x2 with 8. From now it is possible to setup per costing methods specific e.g. 8 to accurate costing calculation.
I will use 5 decimal places in currency, and based on requirement will setup specific precision on schema's per client or per orgs.
Tomáš Švikruha November 6, 2015 at 1:38 PM
attached patch remove hard coded variable and intead of this, uses precision from Account schema. Please write some details about this solution, thanks.
steps to reproduce
1. Setup Average PO for your schema
2. Set on your currency 4 CostingPrecision
3. enter transaction, make some receive and shipment (cant provide here, we have locally examples)
4. BUG_ m_cost and m_costhistory has up to 15 decimal places
customers working with huge qty and low price still able to increase decimal places in currency and UOM. for regular implementation is very not confortabe to work with .15 places figures.