openerp-expert-accounting team mailing list archive

[Raphaël Valyi <rvalyi@xxxxxxxxx>]

Hello guys,


We should have a discussions about taxes included in price for 5.2. I'm not
alone to think that if there is a check-box on the taxes to be included in
price, then they should be included by default not in dubious modules that
will be incompatibles with a ton of modules because they don't rely on a
fined grained API.

Just an illustration of how those modules are brittle and not seriously
maintained:
Tiny just accepted that patch for account_tax_include (I didn't analyse it
yet):
https://bugs.launchpad.net/openobject-addons/+bug/51324<https://bugs.launchpad.net/openobject-addons/+bug/513240>

However, it's easy to see that sale_tax_include and purchase_tax_include
from extra addons have exactly the same code (yes that's a ugly copy/paste)
but received absolutely no attention from Tiny here!
So, that's yet an other example how the code tends to get more entropy and
becomes inconsistent over the time. This is one more example of lack of
rigor that makes it difficult to admit our clean peer reviewed patches such
as
https://code.launchpad.net/~openerp-commiter/openobject-addons/account-method-extraction/+merge/15727don't
make their way in on the contrary (not even yet in trunk).

We also found a bug with accuracy and account_tax_include last week
https://bugs.launchpad.net/openobject-addons/+bug/510726 . Both of us could
reproduce the issue. However, I'll test one more time, after Alexis's patch
too. Meanwhile, if you want to comment on, be my guest.


Now fundamentally about taxes included in price:

1) isn't that possible to have them working always be default in 5.2 ? (we
will then have to live with it until mid 2011, remember?) For us in Brazil,
any company doing legal accounting will need it and relying an brittle
incompatibles *_tax_include modules is really scary.
2) I don't get the point about the *_tax_include modules. When installed
they alter the computation in that way:
   - if the tax is set up with "included in price" at the tax object level,
then it will indeed make it include in price (with eventually the rounding
issue) no matter the "tax included/not included" option you have at the
order.invoice level. But notice that if you don't install those modules this
tax object checkbox will not be used at all...
   - if you choose 'tax include' at the order/invoice level, all taxes will
be included in the price no matter their tax settings. I mean, it's
childdish because:
        - you could already have it by setting the property at the tax level
(so what is the point of getting that option, should the salesman, deal with
fiscality?)
        - you will probably have taxes included and other not included in
the price (here in Brazil that's the case). this option will just make all
taxes included in the price, so the option is not usable in those case.
   - it's very strange that the "included in price" at the tax level option
is only used if you install those modules BUT even if you choose tax not
included in price at the order/invoice level.


I will tempt here to extrapolate an explanation: those modules are old
inheritance of a time where no fiscal positions could map the taxes properly
if you have for instance to skip a tax. They first were enabling to binary
allow/disallow all invoice taxes to be included in price. Then Tiny
implemented the finer grained "include tax" checkbox at the tax level which
is taken into account only in those module; god only knows why.
But as soon as they made that option at the tax level, then the option at
the order/invoice level became useless. However they didn't pay attention to
remove it. They didn't even try to make OpenERP use that tax level option bu
default at his core. I am correct or what did I miss?



Finally, just a remark about rounding (feel free to extend it in an other
thread if you would like to comment on that one):
OpenERP makes the sum of the rounded lines in orders/invoices rather than
the rounding of the non rounded lines.
Some suggest rounding is done at the very end (not sure how much refactoring
is required, we have to be realistic).
But because OpenERP let you have an accounting move line per invoice line,
if you roundeded the sum of the lines for the order/invoice total, then that
total may not matched the sum of the rounded account move lines! So you
would have trouble for reconciliation. I mean, account move lines have
rounding anyway (at least when they are printed/exported).
So did you think about that? (I'm sorry I thought about it only recently),
does it gives you new perspective to fix the rounding issues?


Thank you for your attention,

Raphaël Valyi
http://www.akretion.com