openerp-community team mailing list archive

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

*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
>>
>>
>