openerp-community team mailing list archive

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

Feel free to imagine a function that calls home on a github community
localization repository, every time a user has spotted a new Tax
Constellation to be officially approved by community accountants. Licenses
could be adapted accordingly.


----------------------
*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-18 21:27 GMT-05:00 David Arnold - El Alemán <david@xxxxxxxxxxx>:

> *To whom it might concern...*
>
>
>
> As announced previously in this list, we have worked on an advanced tax
> engine, to tackle tax specialties which are common in South American (and
> maybe more) jurisdictions in a transparent, clear and logical manner.
>
>
>
> *​The logical foundations of this Advanced Tax Engine are:*
>
>
>
> - ​To cluster different Tax Concepts, we want to break the topic down into
> smaller, isolated pieces: *Fiscal Domains *(Examples Domains would be:
> TVA, Withholdings, Income Tax Prepayments on Invoices, etc.)
>
>
>
> - To keep things transparent, we want to cluster taxes, which for
> technical reasons are different "tax entries" but belong to the same
> concept, into one *Tax Allocation Packages *(ex.: Purchase and Sale Tax
> with their respective Tax and Counterparty Tax)
>
>
>
> - As our jurisdiction might be complex, we do not only want predefined
> taxes on products, because this makes everything only more complex. (We
> until now tried to write our own code or to work with Fiscal Positions to
> teach Odoo to alter taxes based on some very basic conditions, but this
> always required a in the worst case "dummy tax" that can be altered). It
> was like teaching an elephant to fly. Therefore, we now want that Tax
> Allocation Packages are allocated based on a (occasionally large) set of
> rules, which describe a particular constellation of factors in a specific
> sales or purchase situation. We introduced *Tax Allocation Rules.*
>
>
>
> - Because, our jurisdiction is complex, there are various influencing
> factors, most commonly, a tax depends on some constellation of specific
> partner, vendor and product attributes. We therefore want to collocate such *Fiscal
> Attributes* on a Fiscal Domain Case basis (to keep things manageable). As
> in even more complex jurisdictions we might not only need the herein
> predefined attributes of partners, vendors and products. In this case
> additional attributes (example of the invoice line [Brazil]) can be easily
> created and implemented via little extra coding.
>
>
>
> *See what I mean:*
>
>
>
> Install the modules (account_fiscal_allocation & account_fiscal_attribute)
> of this branch on a virgin SaaS-5 with demo data (V8 alpha doesn't work
> properly)
>
> *http://goo.gl/2KPiqL <http://goo.gl/2KPiqL>*
>
>
>
> ​This is a preview, most things are still not working, but it gives a
> better Idea of what we are trying to implement. Among the things that are
> not working yet:
>
>
>
> - Application of Tax Packages
>
> - Collocation of Attributes on Partners/Products​
>
> - Situation of Templates/Wizards is very inhomogeneous
>
>
>
> If you like the work show your support with a +1.
>
> If you feel like helping a little more, an offer to review a future beta
> version of the code would be *very highly *appreciated.
>
>
>
> If you've got some time left, you might even help us with debugging and
> some coaching/best practices (we are all not the most experienced
> programmers). Please write me a personal mail in case.
>
>
>
> Thank you for your time, I hope you like this initiative.
>
>
>
> *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
>