Inventory API

Inventory API will support a precision= parameter, which can be used in getInventory, in that case, the query would be:

SELECT SUM(ROUND(stock.quantity, precision)) as inventory ....

getMovementHistoryList also support the precision= parameter, the query is:

SELECT ROUND(stock.quantity, precision) as total_quantity ....

The value we pass to precision= must be the result of resource.getQuantityPrecision(), delivery.getQuantityPrecisionFromResource(delivery.getResource()) or movement.getQuantityPrecisionFromResource(movement.getResource()).

Note: getQuantityPrecisionFromResource is here for performance, because the result is cached, and it does not need to access the resource object in the ZODB.

In single currency mode, Forms such as Account_viewAccountingTransactionList or Entity_viewAccountingTransactionList will use the precision defined on the default currency of the preferred section. This allows for producing a view which is compatible with fiscal rules.

In multiple currency mode, Forms such as Account_viewAccountingTransactionList or Entity_viewAccountingTransactionList will use the max of all precisions defined on all currencies. This allows for displaying debits and credits in a uniform way yet provide a view which is compatible with all currencies.

Reports like Trial Balance, General Ledger etc have to use the same quantity precision.

User Interface

Fields showing currency values should set the precision property according to the currency precision, for example, we can use:

  python: here.getQuantityPrecisionFromResource(here.getResource())

FIXME: open problem, floatfields uses python representations, and sometimes displays scientific notation, like 10e9

Simulation

Q. Do we have to round in simulation movements ?

A. Probably not, because if you have 10 lines with qty 1 and price 0.001, with precision 2, your total price would be 0.

Q. Do we have to round after build accounting lines ?

A. Yes, and you may also want to change some quantities to make sure total debit == total credit. If you consider the following invoice lines, with a currency precision of 2:

invoice_line1

qty=1

price=0.023

resource=r1

invoice_line2

qty=1

price=0.033

resource=r2

if you have an invoice transaction rule like this one:

resource r1

source=account1

qty=1

source=account2

qty=-1

resource r2

source=account1

qty=1

source=account3

qty=-1

This will build:

node

quantity formula

quantity

account1

round(0.023 + 0.033, 2)

0.06

account2

round(0.023, 2)

-0.02

account3

round(0.033, 2)

-0.03

Here debit != credit. One solution is, in addition to rounding, adjust quantities to make debit == credit, taking care not to blindly round if debit really != credit due to misconfiguration.

Q. If we round some accounting lines quantities, delivery will be divergent, how to solve this ?

A. A good configuration of divergence tester can accept a quantity change with a delta under a certain value without making the movement divergent.

TechnicalNoteOnRoundingInAccounting (last edited 2008-01-03 13:48:04 by localhost)