openerp-expert-accounting team mailing list archive

[Raphaël Valyi <rvalyi@xxxxxxxxx>]

All right, I just confirmed the rounding issue with *_tax_include modules
here: https://bugs.launchpad.net/openobject-addons/+bug/510726
And Also, Tiny propagated the other fix of account_tax_include to
sale_tax_include (just sad we have to be the watchdogs...).

Without even speaking about refactoring it into the core, nobody shocked be
the mere awkward functionality of *_tax_modules I described?

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


2010/1/27 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
>
>