openerp-community team mailing list archive

[David Arnold - El Alemán <david@xxxxxxxxxxx>]

*Hello Cloves*

what I like about your Idea, is that it can be completely outsourced to a
tax engine provider (which could be subscription based for maintatining
logic up to date). In the US I've seen such businesses but I don't remember
the name.
I think, in South America at least, there would be a market for that kind
of service.

That's not open source, but probably very efficient...

*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-11 21:34 GMT-05:00 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
>>
>>
>
> _______________________________________________
> 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
>
>