openerp-community team mailing list archive

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