openerp-community team mailing list archive

[Gustavo Adrian Marino <gamarino@xxxxxxxxx>]

For anyone wanting to explore, I've just created a Github project:
https://github.com/gamarino/numa_shared_taxes

It is work in progress. Any comment will be appreciated
Best regards

Gustavo Adrian Marino

Mobile: +54 911 5498 2515

Email: gamarino@xxxxxxxxx

Skype: gustavo.adrian.marino






2014-06-02 12:54 GMT-03:00 David Arnold - El Alemán <david@xxxxxxxxxxx>:

> To sum it up in a kind of to do list for Colombia tax project (containing
> additional items):
>
> - widen concept of fiscal position to be allocation (and not only
> replacement tables)
> - allow for n allocation tables, n product attributes and n partner
> attributes (ideally grouped around tax domains), which steer behaviour of
> fiscal position roules (tax controller)
> - reframe fiscal classification to match the requirements of being a n
> product attribute
> - prepare for generic granularity (now via individual XML reports) - >
> maybe pentaho integration
> - allow tax precision be independent of account precision (blame OpenERP
> SA R&D for not being able to solve this since 2011 despite several bug
> reports and fierce discussion)
> - allow tax chart queries for an individualized set of periods (not just
> one) - in case reporting periods differ on different concepts
>
> Anything to add? Further comments?
>
> *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-02 10:32 GMT-05:00 David Arnold - El Alemán <david@xxxxxxxxxxx>:
>
> *Hello Marcelo, Hello Gustavo*
>>
>> I hope that at least during World Championship, Brazilian accountants
>> might find some spare time to watch some games... ;)
>>
>> I think the kind of flexibilzation proposed, could get you generically
>> covered on everything which are attributes of partners and products. It is
>> true that the invoice line itself, in other words: the specific
>> characteristics of a particular sale  (which are not attributed to partner
>> or product) are somewhat difficult.
>>
>> The Tax Include /Base Amount Include topic I also noticed. The *Core
>> here seems utterly buggy *afaik, Akretion completely overwrote it to
>> make it somewhat intelligent. See a pull request, i made recently: https://
>> github.com/odoo/odoo/pull/219
>> (I think I'm not the first one to notice, that bugs/pull requests are
>> handled very inefficiently at the moment? A perceived lack of respect.
>> Other projects do that way better. Hint!)
>>
>> I got the AHA moments. ;) I think probably the tax break logic can be
>> kind of a generic use case. In some countries of the world, there are a lot
>> of Free Trade Zones and probably special tax brakes. But I'm not sure, if
>> this should be calculated on the invoice or even line-item granularity.
>> My best guess is rather that it is more appropriate to account for such
>> situation at an accounting level.
>>
>> As to *Argentina* it seems, the that tax system is very parallel to the
>> Colombian one. I'm not sure about the "activity", because in fact this is
>> kind of an aggregate product classification. In case of Colombia we are
>> talking about CIIU (ISIC: http://unstats.un.org/unsd/cr/registry/isic-4.asp),
>> which can be mapped for example to product classification CPC (http://
>> unstats.un.org/unsd/cr/registry/regcst.asp?Cl=25&Lg=1). So in fact
>> "activity" refers to kind of a simplified product classification, which
>> is trying to cover the standard case, where one company is dedicated to
>> one or few activities. But caution! A company can pursue multiple
>> activities depending on the specific product it is producing. So this
>> way, the CIIU is a *product * attribute.
>>
>> I think as to the base done, we have great modules like Fiscal
>> Classification and Fiscal Position Rule available, however these must be
>> altered, to reflect an adaptable high level logic. (The ones mentioned by
>> Pedro and Raphael) Fiscal Position Rule already allows for a logic
>> depending on State, Country (all three: Issuer Address, Delivery or
>> Invoice Address) But what it does lack is to account for other fiscal
>> attributes of the partner and the product.
>>
>> On the partner side, there can be applied for example in the case of the
>> domain of a specific national tax a *retention *depending on issuer *and
>> * buyer characteristics. This actually is not an available attribute in
>> Fiscal Position Rule. On the other Hand, *fiscal classification * is a
>> module to provide tax-sets on products. If we dismantle this concept, it
>> comprises a classification + an actual allocation (two in one).
>> Additionally, it is single-dimension. So there is only one possible
>> classification available at the moment.
>>
>> The Brazilian localization from Akretion (credits!) tackle this issues
>> in a very country specific and "hard coded" way. But it's readily available
>> for *"genericalization" *If you think then the Fiscal Position module as
>> an extensible controller logic, you probably could cover all Argentinian/
>> Venezuelan/etc. tax cases.
>>
>> Such a common framework would then also be easier to adapt at those
>> Brazilian specialties (such that line order attributes are important).
>>
>> I value your ideas, of abstracting taxes further. Actually when having
>> dinner yesterday with the localization team we ran about the idea of an
>> completely independent tax enginge with an API to provide for south
>> America's ERP, to outsource the headache of tax calculation to a central
>> company. (Hint for smart entrepreneurs!) There are some US companies for a
>> possible exit strategy on such a project. I think, such ideas are probably
>> outside the focus of OpenERP (I know, the culture is somewhat let's
>> copy/reinvent the wheel in some cases, but you probably already know my
>> opinion on that).
>>
>> However some aspects, I see, can be covered by the localization
>> *templates* (not the updating aspect). You can define tax accounts on
>> the general ledger an allocate taxes to, etc. To abstract this, I'm not
>> sure, if that wouldn't be too specific, as you would have map your accounts
>> to a set of tax-concepts (kind of tax api), but this set of concepts can be
>> very dynamic as per jurisdiction. So this mapping effort would have to be
>> done also in case of an update in the mapping structure.
>>
>> A side note on aggregating granularity to obtain tax statements: I think
>> that the Odoo way of displaying taxes (Chart of Taxes will in the near
>> future become deprecated as concepts such as XBRL (http://es.wikipedia
>> .org/wiki/XBRL) win ground. Basicially you take a xml-tag of the
>> official or national "taxonomy", then you define which data has to be
>> aggregated around that specific tag, then you file via XML to your
>> authorities) This granularity approach will certainly be necessary for a
>> lot of countries (also for statistical reporting, which can be tied to
>> taxes or not). So I think at least we wouldn't have to bother to much about
>> in which tax account to strategically allocate a tax perspectively.
>> (Maybe the whole concept of tax accounts will get deprecated, as
>> granularity advances, as it's basically replicated information and a
>> violation of the DRY principle)
>>
>> I think, it would be very helpful if you could publish your code on
>> github, in order to be able to analyze it and look for parallel
>> concepts. Maybe the multicompany-management approach can be refactored
>> as a compatible delta module in the future?
>>
>> The Colombian one lives at: https://github.com/odoo-colombia/odoo-
>> colombia
>>
>> @ Ana: Europe gratefully in't the sad standard of tax complexity. The
>> only tax retention to be known in Germany is in construction (as a sector
>> which has a lot of tax evasion).
>>
>> *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-02 9:11 GMT-05:00 Gustavo Adrian Marino <gamarino@xxxxxxxxx>:
>>
>> Let me add some considerations for Argentina: In our country is very
>>> clear that the taxes to be applied are dependant on:
>>>
>>>    - The issuer company, and the possibility to act as a retention
>>>    agent for some taxes
>>>    - The issuer activity
>>>    - The fiscal address: one set of taxes could be potentially applied
>>>    based on city, federal state and country
>>>    - The product
>>>    - The buyers activity
>>>    - The buyers fiscal address
>>>
>>> If you are trying to define a new way to treat taxes, for sure the idea
>>> of redefining the tax structure per company (as today in Odoo) and "fixing"
>>> via a simple table is simply not reflecting reality nor the common use
>>> pattern of any real customer
>>>
>>> I have started developing a module to redefine taxes accounts as
>>> properties per company and assigning a set of taxes to federal states and
>>> countries. This set of taxes should be applied depending on issuing
>>> companies fiscal federal_state and country.
>>>
>>> This arrangement allows us to deliver an incremental set of taxes
>>> covering first the country level and then federal state taxes as needed.
>>> This taxes could be configured AFTER the company account plan is set for
>>> the company set needed, and thus allowing to adapt the DB to changes in
>>> taxes without having to do manual editing on every company in the database.
>>>
>>> Of course a set of company specific taxes is also provided
>>>
>>> Additionally, due to the fact now taxes are global (not company
>>> specific), you can define taxes on products without be worried to point to
>>> the exact account on each company, and avoiding to rely on obscure access
>>> rules to manage taxes.
>>>
>>> Under the new scenario, accounts could be only visible to the company
>>> they are defined on, reflecting the fact they are strongly tied to
>>> company's account plan.
>>>
>>> Under this schema, the need of fiscal positions for customers is
>>> strongly reduced to some simple cases, reflecting just special cases for
>>> some customers, and thus using the simple standard approach is enough in
>>> most cases.
>>>
>>> The module is still not in production. If you think this approach could
>>> be used as a common strategy, I have no problem publishing it
>>>
>>> Best regards
>>>
>>>
>>>
>>> Gustavo Adrian Marino
>>>
>>> Mobile: +54 911 5498 2515
>>>
>>> Email: gamarino@xxxxxxxxx
>>>
>>> Skype: gustavo.adrian.marino
>>>
>>>
>>>
>>>
>>>
>>>
>>> 2014-06-02 10:14 GMT-03:00 Marcelo Bello <marcelo.bello@xxxxxxxxx>:
>>>
>>> David, my 2cents as an user of the Brazilian localization (I am not
>>>> aware of all the technical challenges, I am just speaking from an end user
>>>> PoV).
>>>>
>>>>    The idea of an application instead of replacement table sounds good
>>>> to me. Usability-wise I always found strange that by default a product
>>>> would have dozens of taxes pre-applied to it only for most to be filtered
>>>> out later in the process. Again, I am sure there are design decisions to
>>>> justify that, but usability-wise it is not ideal.
>>>>
>>>>    Regarding what you say about the flexibility of the current
>>>> implementation, I agree with you that some pieces might be missing, but at
>>>> least in the context of the Brazilian tax legislation what you propose will
>>>> still not cover the full range of possibilities that need to be taken into
>>>> account.
>>>>
>>>>     At least in the case of Brazil, the taxation of a sale needs to
>>>> take into account information from:
>>>>
>>>> - The buyer/partner;
>>>>
>>>> - The product itself;
>>>>
>>>> - The seller (the company selling, in the case of a company with
>>>> multiple branches - like my company - this is extremely relevant because
>>>> some of my branches are on special trade zones which change the tax
>>>> calculation significantly);
>>>>
>>>> *- The order.line: *for example, a product in Brazil is taxed
>>>> differently depending on whether the buyer plans to resell the item or if
>>>> it is going to consume it (or add it to its assets).
>>>>
>>>> *- The product unit being sold* - yes, some pieces of legislation
>>>> requires us in Brazil to keep track of individual units so that they are
>>>> sold the same way they were bought. Sometimes this do not impact the tax
>>>> rate, but do impact the tax codes we need to use to fill eInvoicing,
>>>> sometimes it affects both. For instance, in Brazil if I buy an imported
>>>> product from a distributor, the goods I purchased from that distributor
>>>> will use a specific CST code, but if I import it myself I will have to sell
>>>> them with another CST code. In a few cases even the tax rate changes. For a
>>>> company like mine, we sometimes buy locally, sometimes import and this kind
>>>> of "lot-number-like" control is very difficult to handle without an ERP
>>>> system. Our localization still can't handle this.
>>>>
>>>>       Think about it and check if in your country you do not have cases
>>>> where you need info from order.line (or even just the order itself), and/or
>>>> if you need to do the lot-number-like tracking I mentioned in some cases.
>>>> Of course, these two last items account for a smaller % of total
>>>> transactions in my country, but they are relevant for a large number of
>>>> organizations (they happen often enough that one wishes it were handled by
>>>> their ERP system).
>>>>
>>>> *A few more things to consider before you get your hands dirt:*
>>>>
>>>> - As far as I know, today the tax calculation does not work well as an
>>>> independent tax-engine. Therefore, it is hard to make Odoo provide the
>>>> sales agent a table like the one below (showing taxes as a function of sale
>>>> location). This is useful for companies that are trying to optimize their
>>>> taxation, avoiding taxes when possible. Companies usually achieve this by
>>>> setting up factories or branches in special tax locations so it is
>>>> interesting if the system can be made easy to offer tax simulations like I
>>>> show in the table below, so that a sales agent can place the order in the
>>>> best possible way.
>>>>
>>>>              Product Cost     Tax A     Tax B     Tax C        Total
>>>>
>>>> Location A       X              X         X         X            X
>>>>
>>>> Location B       X              X         X         X            X
>>>>
>>>> - At least in Brazil, taxes have an hierarchy. Taxes must be calculated
>>>> on top of a base value. Such base value sometimes is the value of the goods
>>>> being sold but sometimes, for some taxes, it is the value of the goods PLUS
>>>> the value of another tax (so tax applies over other tax, in cascading
>>>> style). Maybe this is an exclusivity of the crazy Brazilian tax
>>>> legislation, maybe not, but one needs to consider it for the tax engine to
>>>> work well.
>>>>
>>>> - Taxes may or may not be part of the product price. In Brazil usually
>>>> the price list is inclusive of some taxes so the total price to be paid by
>>>> the client will not change if some taxes (that are included in the price)
>>>> change;
>>>>
>>>> - It would be wise if the system had three fields for each tax rate:
>>>> (a) tax_rate_for_display: the tax rate % used for display purposes;
>>>> (b) tax_rate_for_invoice_calculation: the tax rate % used for
>>>> calculating the tax used for invoicing;
>>>> (c) tax_rate_for_effective_payment: the tax rate % that will actually
>>>> be paid to the government
>>>>
>>>>         Usually a=b=c, but not ALWAYS!
>>>>
>>>> (b) is for when you have a tax that is not applied in the usual
>>>> TAX_AMOUNT=BASE_VALUE*TAX_RATE way. Hence you need to convert the way the
>>>> tax must actually be calculated so that it will work when calculated in the
>>>> standard TAX_AMOUNT=BASE_VALUE*TAX_RATE. We have one such case in Brazil,
>>>> where the tax called ICMS must be calculated in a way that the tax_rate is
>>>> applied over the value of the goods PLUS the value of the ICMS tax itself!
>>>> Yes, the tax applies over itself (this is usually the AHA moment, when
>>>> foreigners realize how fucked up our tax system is in Brazil). So ICMS has
>>>> a tax rate of 25%,18%,17%,12%,7%,4% or 0% depending on a number of
>>>> variables. When you need to print the tax rate applied you must write 18%,
>>>> but the tax rate you actually use to calculate the tax is given by the
>>>> formula TAX_AMOUNT = BASE_VALUE * [1/(1-TAX_RATE)-1]. Hence the need for
>>>> the field (b) tax_rate_for_invoice_calculation, one would write (a) = 0.18,
>>>> (b) = 0.21951219512 in this example.
>>>>
>>>> (c) is for when a company has a tax incentive that is not reflected on
>>>> the invoices (which is very often in Brazil). So for instance, I may have a
>>>> tax break and instead of paying 10% tax I effectively pay only 5%. But the
>>>> government still requires me to issue my eInvoices with the 10% rate like
>>>> everyone else and I am given a rebate at the end of the month. So for
>>>> accounting purposes, in this example we would have (b) = 0.10, (c) =0.05.
>>>>
>>>>         So one can actually have a situation where all three fields are
>>>> different. Not sure you have a similar case in Colombia.
>>>>
>>>>         I wanted to point out all these use cases so that if there is a
>>>> coordinated effort to standardize across the "tax calculation engine" some
>>>> of these items could be taken into account (not all of them I am sure).
>>>>
>>>> Best regards,
>>>>
>>>> Marcelo
>>>> On 2 Jun 2014 02:54, "David Arnold - El Alemán" <david@xxxxxxxxxxx>
>>>> wrote:
>>>>
>>>>> *Hello Raphael*
>>>>>
>>>>> we are going forth with Colombia following your example.
>>>>>
>>>>> At this stage I already can make my comments on the logic of the
>>>>> mentioned set of modules, as they do not (yet) solve our problem, as
>>>>> initially stated.
>>>>>
>>>>> Lets rename some of the concepts as mapped hereafter for better
>>>>> understanding (speaking names at the right abstraction level):
>>>>> fiscal position = replecement set (this is historically, but wrongly,
>>>>> directly attached to the partner, because it can be equally dependent on
>>>>> product caracteristics)
>>>>> fiscal classification = fiscal attribute of product
>>>>> fiscal position rule = replacement table controller
>>>>>
>>>>> So what we are missing, and what you missed in barzilian localization
>>>>> is a custom "fiscal attribute of partner", which then is taken by the
>>>>> "replacement table controller" and funneled into the application of a
>>>>> "replecement set" in the very moment that all relvant factors (fiscal
>>>>> attributes of product, and fiscal attributes of partner) are available.
>>>>>
>>>>> So we would have:
>>>>> "replacement sets", which are controlled by the "replacement table
>>>>> controller", which draws on "fiscal attributes of products" and "fiscal
>>>>> attributes of partners" to determin the application of such sets.
>>>>>
>>>>> Now given, that in south american countries there are various fiscal
>>>>> concepts which - in the case of colombia - amount to 8 different taxation
>>>>> concepts on a product (retentions included). This being said, in the world
>>>>> of a one dimensional application of attributes (product and partner) and
>>>>> sets, this actually amounts to the statistical combination of cases in each
>>>>> concept (tax) domain. Lets say illustratively 5x2x4x5x12x5x8=96000
>>>>> combinations. This is not the way to go! What we need therefore is a
>>>>> flexibilisation by using the already built in tax domain concept to gather
>>>>> taxes arround a specific domain - say VAT.
>>>>>
>>>>> So the idea is, that partner and product each get an attribute per
>>>>> every domain. (So if there are 8 domains, a partner or a product can have 8
>>>>> respective attributes) And that each set of attributes is processed by the
>>>>> replacement table controller to allocate a flexible set of replacement
>>>>> tables, which are executed according to a specified sequence.
>>>>>
>>>>> Even the creation of Tax domains, and the definition of domain items
>>>>> in the respective tables should be dynamic, allowing for further
>>>>> flexibilisation.
>>>>>
>>>>> I think even some concepts of brazilian tax structure have some more
>>>>> generic cousins that you might have thought at the time of programming.
>>>>> (but honestly, that's just an educated guess)
>>>>>
>>>>> As leagel requirements in many jurisdiction, I think this should go
>>>>> into core as "advanced taxes" some day...
>>>>>
>>>>> *How is the situation in Thailand about those topics? Seems that
>>>>> Thailand is quite similar to Colombia.*
>>>>>
>>>>> *Nhomar,* have you checked the brazilian concepts? Might there be
>>>>> room for convergence with venezuela and mexico? (maybe appling the above
>>>>> said)
>>>>>
>>>>> When we start to override, where should we merge the generic portions
>>>>> of code? I'd like to see that built in into the relevant Akretion modules...
>>>>>
>>>>> *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-05-29 9:10 GMT-05:00 Raphael Valyi <rvalyi@xxxxxxxxx>:
>>>>>
>>>>>> Hello David,
>>>>>>
>>>>>> double check but this OCA project may help you:
>>>>>> https://launchpad.net/openerp-fiscal-rules
>>>>>> And this is how we override it for Brazil for instance:
>>>>>>
>>>>>> https://github.com/openerpbrasil/l10n_br_core/blob/develop/l10n_br_account/account_fiscal_position_rule.py
>>>>>>
>>>>>> as far as I know this is also used in international commerce in
>>>>>> Europe, in Canada and may be Italy or Spain.
>>>>>>
>>>>>> The idea is that the partner don't carry the fiscal position anymore
>>>>>> exactly but instead we have that extensible intermediary flat decision
>>>>>> table that will determine, depending on many extensible parameters
>>>>>> (countries, states, fiscal types etc..) which fiscal position will apply
>>>>>> exactly. That table can be large eventually.
>>>>>>
>>>>>> I think there is room to improve thee compatibility of these module
>>>>>> for v8 using the new OCA web_context_tunnel module to avoid creating
>>>>>> signature incompatibilities with existing on_changes until the new API will
>>>>>> be used everywhere in the addons (probably v9 only).
>>>>>>
>>>>>> Please let us know if these modules can help you.
>>>>>>
>>>>>>
>>>>>> Regards.
>>>>>>
>>>>>> --
>>>>>> Raphaël Valyi
>>>>>> Founder and consultant
>>>>>> http://twitter.com/rvalyi <http://twitter.com/#!/rvalyi>
>>>>>> +55 21 3942-2434
>>>>>> www.akretion.com
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Thu, May 29, 2014 at 9:50 AM, David Arnold - El Alemán <
>>>>>> david@xxxxxxxxxxx> wrote:
>>>>>>
>>>>>>> *Hello Fellows*
>>>>>>>
>>>>>>>  in Colombia we (some) are trying to adapt to local legislations by
>>>>>>> following a concept of introducing multiple fiscal positions per parnter.
>>>>>>> This sould only involve quite minimal code change, maybe same 30-50 lines
>>>>>>> of code in total...
>>>>>>>
>>>>>>> The idea is to cluster fiscal positions under certain domains (such
>>>>>>> as one tax1, tax2, tax3, tax4, tax5, etc.) and to be able to assing to a
>>>>>>> partner an infinite number of fiscal postiones ordered by domains.
>>>>>>>
>>>>>>> If we don't introduce this multidimensionality of fiscal postitons,
>>>>>>> we would have to multiply out (is this the corect term?) the matrix and get
>>>>>>> some 5x5x5x5 (=4 domains with 5 cases each) fiscal positions... Not cool.
>>>>>>>
>>>>>>> Would this be a feature eligible for core aknowledging it's very
>>>>>>> small code impact (using existing concepts) and its usefullness in more
>>>>>>> complicated jurisdictions worldwide?
>>>>>>>
>>>>>>> Point two, is there some kind of classification flield on product
>>>>>>> known, which can serve to prepare for granularity when it comes to concepts
>>>>>>> such as BI and XBRL. We would like to link taxes and reporting requirements
>>>>>>> to such product classification fields here in colombia. (there are about
>>>>>>> 5000-6000 thousend different concepts of municipality tax, differing from
>>>>>>> municipality to municipality - which are based on such a product - or
>>>>>>> "activity " - classification)
>>>>>>>
>>>>>>>
>>>>>>> *Freundliche Grüsse*
>>>>>>>
>>>>>>>
>>>>>>>  ----------------------
>>>>>>> *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
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> 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
>>>>
>>>>
>>>
>>
>