openerp-community team mailing list archive

["Cloves J. G. de Almeida" <cjalmeida@xxxxxxxxx>]

Fellows,

I've brought an alternative proposal for dealing with a complex tax system
in the l10n-br mailing list a couple months ago and I believe it would be
nice to share it here. Raphael and Renato know I'm very respectful of their
work despite my concerns.

IMO, in trying to fit the Belgian designed fiscal position solution into a
general solution we risk creating another Magento. So flexible that we feel
like we're "programming in the UI" instead of configuring. Take a look at
this catalog and product (only) ER diagram to see what I'm talking about:
http://goo.gl/LRBYmg.

The alternative: "to stop worrying and loving the bomb". Accept our
countries tax systems are not sane and drop fiscal position entirely. And
instead of replacing for another UI-programming system focus on developing
a good "tax engine framework" and accept we need to develop a small custom
module for each implementation - don't implementors already do this? With
the added benefit of easy version control - auditors will love that.
Instead of Magento, let's do Spree Commerce.

The Brazilian tax laws are probably the most complex in the world.
Calculating which taxes are applicable and how much one must pay on a
single sale could potentially depends on dozens of variables. Things like
your previous year revenue, if the buyer will resell or not the product,
which country and state the product was made, who's paying freight, company
specific tax incentives, etc. Really. No, I'm not kidding.

However, most companies are subject to only a handful of tax rules. If one
were to code the tax rules for a specific soap manufacturer or auto dealer,
they'd be different but doable in the budget of an implementation. If one
were to try to code the rules fitting _every_ possible soap manufacturer
and auto dealer we're talking about much-larger-than-SAP budgets.

We could also treat the tax process as a "black box" like other ERPs do to
really simplify the process. The large majority of time, we need tax
calculations only on quotation and on invoicing. No "on_change" stuff
spread around, just press "Calculate Taxes" when needed.

So, how would this engine work? I propose following the general "Rules
Engine" approach:

a) Define a domain-specific data model so the rules are not changed when
ERP's data model change
b) Express the rules, preferably as flat conditions instead of hierarchical
if-then-else conditions.
c) To calculate: pass the facts, map the ERP model to the domain model. act
on them on rule match, return the facts.

"But flat conditions would create A x B x C x D = too many conditions". Not
if you're developing for a single company where much fewer conditions
apply. Also, there are ways to improve expressiveness using decision
tables. Flat conditions are much easier to understand and maintain than
hierarchical ones.

"Talk is cheap. Show some code". Check the following gist:

https://gist.github.com/anonymous/d0627beeb58b5c741fde

This is my production tax engine (v6.1 - comments changed to english) where
there's a lot of tax decisions and solves about 90% of my company's
invoicing needs. No fiscal position or on_change. Of course we're doing
simplified accounting and I have no need for Odoo tax objects. But I'd bet
most company's "custom tax engine" could be made with under 500 lines of
readable Python code.

Regards,

Cloves Almeida

On Tue, Jun 3, 2014 at 6:16 PM, David Arnold - El Alemán <david@xxxxxxxxxxx>
wrote:

> *Hello Raphael,*
>
> I agree 100% with your plea/pleas - was interesting to hear your opinion.
>
> I like the terms "rings of common abstraction" and "incremental steps" and
> "pefect is the enemy of the good" you should include that in the OCA bylaws
> ;) (if it's not there already.. ;)
>
> I want to add, this worldwide community is an immensly incredible large
> resource of knowledge.
>
> There is one point about the DIY aspekt. It is the entry point, and it
> should be as it enables small companies to think big and grow faster.
> That's agood thing, also strategically, because sooner or later those will
> turn into customers.
>
> So now, I want to get my hands dirty and drop another ring of common
> abstraction into the OCeAn ;) Where resides the code? Where shoudl we fork
> from? If it is not yet portet to github, could you exceptionally pre-port
> those moduels so we don't have to clutter arround with launchpad, which we
> will simply refuse to do.
>
> I want to get done something usable/discussable by the end of the week. I
> think tha analyzing is done to a sufficient extend. We don't want to get
> inefficient either.
>
> Basic cleaning: I wonder why openerp hasn't yet adapted this set of tools
> to help with the task: https://github.com/akretion/ooor (those nice
> buttons, on top of the readme)
>
> So expect us here to deliver on these flexibilizations in an upstreamable
> way, and if we don't beat as to! ;) I think the multycompany then is a
> topic on top of that, but right now, i don't want to dig into, as we don't
> have that itching so far (might come reasonably fast)... :)
>
> We got already most of the basic information/data part ready for colombia,
> so now its coding time, and I don't have time to spent moth on that, so
> let's start ;)
> I don't know if it might be worth to host a voluntary sprint on that.
> Anyhow I don't know how to organize that... Saw, that they are doing such
> things in italy, but I dont feel capable of leading such an initative.
>
> Final remarks, I feel that the moving parts (localization communites)
> still lack convergence in some aspekts, probably the OCA isn't pastoring
> the right way. Would be interesting to see, which regions are actively
> present in this community list... That's why I like so much the new spanish
> community page. It's about identity! (http://www.odoospain.com/)
>
> *Best* David
>
>
> ----------------------
> *David Arnold B.A. HSG*
> *Gerente*
>
> +57 315 304 1368
> david@xxxxxxxxxxx
> www.elaleman.co
>
> ​El Alemán S.A.S, Carrera 13 # 93 - 40 P4, Bogotá D.C, Colombia
>
>
> 2014-06-03 10:24 GMT-05:00 Raphael Valyi <rvalyi@xxxxxxxxx>:
>
> Dear survivors of countries with complex tax jurisdictions,
>>
>> I just wanted to make a few comments
>>
>> 1)
>> Sorry for being soooo busy, I didn't even answered your private emails
>> David, sorry for that, glad you investigated the modules we built by
>> yourself meanwhile.
>>
>>
>> 2)
>> I hope that people who discovered OpenERP/Odoo recently understand a few
>> things like "perfect is the enemy of the good".
>> OpenERP is not a multinational company hiring 4 fiscal consultants 2
>> years in 40 countries to build the new tax engine generation able to make
>> everybody happy.
>>
>> And in fact this is so much better this way, because traditionally big
>> initial investment in software industry means proprietary software or non
>> sustainable open source bootstrap as many stories are here to teach us
>> (initially open, then closed). Having a GPL'ed Linux or an AGPL'ed
>> OpenERP/Odoo is so much better than blinding ourselves with non sustainable
>> upfront perfection attempts.
>>
>> So instead OpenERP/Odoo is open source, aggressively open source, with an
>> AGPL license that makes companies working on OpenERP only get return from
>> implementation services, so investments are small little incremental steps.
>>
>> Of course having a golden rule them all tax engine would be cool, but
>> meanwhile, our reality is to take care of things that are so much more low
>> level.
>> At this time we didn't manage yet to adopt just a common model for cities
>> around the world in OpenERP, so having a tax engine that work both in Italy
>> or Brazil or Colombia is really an utopia today.
>>
>> Instead, just like many open source projects, we are building rings of
>> common abstractions year after year and ultimately we have code that work
>> for our requirements.
>>
>> In that landscape, the core publisher is OpenERP SA. People with
>> experience with OpenERP, know how hard it is to get them adopt any idea
>> from outside of their office. Well they are very busy doing mostly great
>> work on the core product and making a living at doing it and this is all
>> right.
>>
>> Then implementation partners try to fill the gap between that core and
>> their customers (and ERP is so complex that one cannot really plan to
>> implement something called an 'ERP' without being a specialized
>> professional himself, just like an accountant for instance).
>>
>> And in between the implementation partner and OpenERP SA, well there are
>> moving parts like this forum, localizations forums etc...
>>
>> Well, it's really important to understand, the dynamics in place in this
>> space. Today we do have a structured plural and open non profit foundation
>> called "OCA" http://odoo-community-association.org/ that is filling that
>> gap.
>>
>> So for a concrete example, the fiscal classification and fiscal rules
>> modules mentioned earlier in the thread were done by Renato Lima and me for
>> the Brazilian localization a few years ago but extracted away from it into
>> reusable smaller pieces that could be used in other countries as this is
>> the case now.
>>
>> Today, these modules are placed under the OCA umbrella. That is many
>> people are maintaining them, proposing improvements and there is a strict
>> review process and decision process (for the sake of quality) to try to
>> accommodate as best as possible with the suggestion of the people willing
>> to make efforts to get a better common product.
>>
>> So please, I suggest people should have a really good reason if they want
>> to build structured initiatives between OpenERP SA and the final users
>> without trying to support an OCA workflow.
>>
>> Now yes, neither OpenERP SA, neither the OCA swill save everybody' use
>> case immediately. In fact we focus on having a half full glass, because
>> it's already so much better than nothing.
>>
>> Then yes, implementation partners or country specific organizations do
>> fill the final gaps to the legal requirements to make the whole thing work.
>>
>> So, I mean it's totally normal to have country specific or even partner
>> specific extensions that may not be perfect at the 1st shoot but will
>> evolve, like any open successful source project and will restructure around
>> common modules as they are abstracted away into reusable concepts.
>>
>> It's really important to understand this dynamic vs the static vision of
>> traditional proprietary legacy ERP's (which can afford upfront investment
>> because customers are trapped to pay back later, but which hardly bring
>> enough flexibility as we all know it).
>>
>> So OCA is doing a lot of things, some people here like Lorenzo already
>> know it very well, being great OCA contributors themselves. But I encourage
>> the others to get learnt about this initiative and how this can be useful
>> in this kind of context.
>>
>>
>> 3)
>> More concretely about the modules that have been talked about:
>> of course, if the OpenERP fiscal position concept was more advanced/more
>> dynamic, then we would probably have a simpler localization for instance in
>> Brazil or we could have a lighter decision table in the tax rule module.
>> The day we have it, we will refactor against it of course and we do have
>> several more things we can extract from our localization into the core or
>> reusable bits meanwhile.
>>
>> But you know, again, we should be pragmatic, get customers having a
>> working ERP so that they can pay us doing further work meanwhile.
>> Today, just simple improvement in the core such as
>>
>> https://code.launchpad.net/~camptocamp/openobject-addons/trunk-refactor-po-merge-lep/+merge/216841
>>  already takes month and month to happen with days and days from their
>> authors to get it merged.
>> Unfortunately, basic cleaning of existing features like that are so much
>> more priority than trying to bring new features in the core. And remember
>> OpenERP/Odoo is reallu modular (provided the code is clean), so many things
>> are doable by extension.
>>
>> So really, more flexible fiscal position is a leap forward that is out
>> question for the immediate future. Specially as the current tax engine
>> works well enough in Europe where OpenERP SA is making the vast majority of
>> its revenues with working implementations (yes there have been some virgin
>> territories fever on the Americas over the last years, but naive
>> enthusiasm, even with revenue is different from working implementations as
>> an ERP system). In a country Brazil around 80% of partners died/stopped so
>> I don't count that kind of things in.
>>
>> So then there is always the possibility to fork the account module of
>> OpenERP and make a better engine.
>> But this is the kind of things that was just discussed in a previous
>> thread with people staying even on 6.1 version with that kind of reasoning.
>> My own opinion is that all in all, even if that is sometimes a 3 steps
>> forward + 2 steps backward evolution, we should avoid as little as possible
>> to fork OpenERP or just modules of it because it makes benefiting from a
>> huge stream of improvement harder.
>> So I would say, as long as the tax engine is this way, well we prefer
>> having these huge tables of taxes, even as Marcelo explained this isn't
>> exactly a must in term of ergonomics.
>>
>> I mate a few hours with Fabien Pinckaers personally during summer 2012 to
>> talk about our tax system in Brazil, so I mean he knows a bit what are the
>> challenges already. During that occasion he could explain me better how the
>> hierarchical tax engine of OpenERP can help them for instance in Belgium.
>> But later we analyzed the engine with Renato and came to the conclusion
>> that the hierarchy part of it is useless in a country like Brazil because
>> the tax computation is so all fucked up as explained Marcelo in greater
>> details (the base of computation can change in so many convoluted and
>> changing ways). So yes we do have some specific code for these computations
>> and this is just like other ERP's use to do in Brazil (whenever they are
>> ERP's that are not Brazil specific which tend to be very rare in term of
>> marketshare).
>>
>>
>> Finally, about the fiscal classification OCA module we made, there is an
>> improvement we did in our override for Brazil that we didn't propose for
>> upstream yet.
>> Indeed, in a multi-companies context, may be you want or don't want to
>> share a fiscal classification.
>> So for instance if the two companies are from different countries, you
>> probably don't want to share the fiscal classification of a product.
>> And account_product_fiscal_classification has been modeled this way, that
>> is the fiscal classification of a product is an ir.properly.
>>
>> Now, instead for several companies in the same country, you probably want
>> that all the companies have their product share the same fiscal
>> classification instead of having to set them again for every single product
>> of your share catalog (if you share it; beware of costing issues BTW).
>> We did that in the Brazilian localization and that can probably cleaned
>> and upstreamed to the account_product_fiscal_classification OCA module.
>> Feel free to help.
>> So instead f using the property, with use that new 'ncm_id' many2one to
>> the fiscal classification:
>>
>> https://github.com/openerpbrasil/l10n_br_core/blob/develop/l10n_br_account_product/product.py#L45
>>  We can probably make it optional in
>> account_product_fiscal_classification is the properties is to be used or if
>> it is shadowed by a generic many2one field like ncm_id.
>>
>>
>> As I said there are other possible improvements, but again unfortunately
>> often we do have much more pragmatic requirements.
>> That kind of impacting change of how banking conciliation works (or not)
>> in OpenERP/Odoo is certainly one of them:
>>
>>
>>
>>
>>
>>
>>
>> On Tue, Jun 3, 2014 at 4:45 AM, Lorenzo Battistini <
>> lorenzo.battistini@xxxxxxxxxxx> wrote:
>>
>>>  On 06/03/2014 03:09 AM, David Arnold - El Alemán wrote:
>>>
>>>  *Lorenzo Battistini*
>>>
>>>  could you drop some comments on this from an italian perspective? I
>>> hope to fetch best practices from around the world!
>>> I've seen you've done quite a bit of coding in your localization, but on
>>> the other hand there are some modules rediliy available...
>>>
>>>  - Fiscal Classification
>>> - Fiscal Position
>>> - Fiscal Position Rule
>>>
>>>  Whith some amendemnds this could serve your case quite generically...
>>> But maybe we're missing something.
>>>
>>>
>>> Dear David,
>>>
>>> we already switched to account_fiscal_position_rule* modules while
>>> migrating to version 7 (thanks to OCA code review on this
>>> <https://code.launchpad.net/%7Eagilebg/account-invoicing/adding_account_fiscal_position_country_7/+merge/182636>
>>> ).
>>> No other localization code is needed about this.
>>>
>>> We developed the account_fiscal_position_country* modules
>>> <https://www.odoo.com/apps?category=&version=&search=account_fiscal_position_country>
>>> before to be aware of the account_fiscal_position_rule* ones. We abandoned
>>> ours now.
>>>
>>> Regards
>>>
>>>
>>> --
>>> Lorenzo Battistini
>>> Tel (CH): +41 91 210 23 40
>>> Tel (IT): +39 011 198 25481http://www.agilebg.com
>>>
>>>
>>> _______________________________________________
>>> Mailing list: https://launchpad.net/~openerp-community
>>> Post to     : openerp-community@xxxxxxxxxxxxxxxxxxx
>>> Unsubscribe : https://launchpad.net/~openerp-community
>>> More help   : https://help.launchpad.net/ListHelp
>>>
>>>
>>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openerp-community
> Post to     : openerp-community@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openerp-community
> More help   : https://help.launchpad.net/ListHelp
>
>