*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 [email protected] 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 <[email protected]>: > 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 < > [email protected]> 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 >> [email protected] >> 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 <[email protected]>: >> >> 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 < >>> [email protected]> 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 : [email protected] >>>> Unsubscribe : https://launchpad.net/~openerp-community >>>> More help : https://help.launchpad.net/ListHelp >>>> >>>> >>> >> >> _______________________________________________ >> Mailing list: https://launchpad.net/~openerp-community >> Post to : [email protected] >> Unsubscribe : https://launchpad.net/~openerp-community >> More help : https://help.launchpad.net/ListHelp >> >> > > _______________________________________________ > Mailing list: https://launchpad.net/~openerp-community > Post to : [email protected] > Unsubscribe : https://launchpad.net/~openerp-community > More help : https://help.launchpad.net/ListHelp > >
_______________________________________________ Mailing list: https://launchpad.net/~openerp-community Post to : [email protected] Unsubscribe : https://launchpad.net/~openerp-community More help : https://help.launchpad.net/ListHelp
