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
