openerp-expert-accounting team mailing list archive

[Stefan Rijnhart <stefan@xxxxxxxx>]

On 03/19/2012 10:05 PM, Raphael Valyi wrote:
> Hello Stefan,
>
> I can tell you that for the case of Brazil, products have many 
> different taxes and they depend on some category called "NCM" 
> for "Nomenclatura Comum do Mercosul" so this is much more complex than 
> just default sale taxes...
> In our case, that NCM is an official categorization that differ from 
> the custom categorization one would do with the native product categories.
> So what we did is we built the account_product_fiscal_classification 
> extra-addons: where a product will be able to instantiate its default 
> sale and purchase taxes given a specific NCM category (where default 
> sales and purchases taxes are set up).
> This system is totally generic and not specific to our localization, 
> so one can always see if it fits its needs. In our cause we use a 
> subtle combo of such default taxes and fiscal mapping (also according 
> to rules sensitives to states, partner fiscal types, countries...) to 
> automatically compute the exact taxes of every product sold or purchased.
Hi,

Thanks to all of you for your reactions. Here is a round up of the topic.

It is clear that our issue does not exactly resonate loudly among the 
accounting experts. Your reactions showed that tax configurations vary 
wildly between regions. Especially David's story of delegating the task 
of tax selection to a web service ([1]) was an eyeopener. Other 
practices have been revealed: Akretion's module ([2]) allows the product 
manager to assign sets of taxes to a product in one step, while the 
GnuThink module ([3]) aims at providing a default set of taxes on the 
product template.

The fact that only Samer from another OpenERP supporting party in the 
Netherlands seemed to fully agree with our use case confirms that it is 
probably only valid for certain localizations.

It is the GnuThink solution that comes closest to our use case, and I 
would choose to develop it further for our purposes but for two reasons:
- a comprehensive glue module solution for this problem is ugly for 
either having to depend on both sale, purchase and point_of_sale, or 
consisting of separate glue modules for each of these.
- the desired behaviour is currently already implemented in OpenERP for 
invoices (since a messageless commit in 2009,  [4]), so I still fail to 
see the fundamental issue here that blocks the adoption of a solution in 
the OpenERP core

It is this inconsistency that frustrates me the most, and I will 
therefore try to provide a full patch for lp:796570 ([5]) to extend this 
existing behaviour to sale and purchase orders and POS which I can 
hopefully get Fabien to agree on this time. It should be quite harmless 
to other setups, and I hope that the accounting experts will be able to 
confirm this in a code review that I will invite them for.

Otherwise I would plead for the account model's default tax field to be 
removed but the field is actually used to provide a default value for a 
receipt voucher's tax, based on the default accounts of the journal. 
Apart from that a reference to the field is featured in 
account_move_line._default_get() in a code path that seems unreachable 
since one specific line ([6]) has been removed from the code base.

Thanks again,
Stefan.

[1] http://www.avalara.com/avaintegrations/openerp 
<http://www.avalara.com/avaintegrations/openerp>
[2] http://apps.openerp.com/addon/1934
[3] http://apps.openerp.com/addon/1916
[4] 
http://bazaar.launchpad.net/~openerp/openobject-addons/trunk/revision/2150#account/invoice.py
[5] https://bugs.launchpad.net/openobject-addons/+bug/796570 
<https://bugs.launchpad.net/openobject-addons/+bug/796570>
[6] 
http://bazaar.launchpad.net/~openerp/openobject-addons/trunk/view/1/account/account.py#L776

--
Therp - Maatwerk in open ontwikkeling

Stefan Rijnhart - Ontwerp en implementatie

mail: stefan@xxxxxxxx
tel: +31 (0) 614478606
http://therp.nl
https://twitter.com/therp_stefan