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 [email protected] 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 <[email protected]>: > *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 > [email protected] > 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 : [email protected] Unsubscribe : https://launchpad.net/~openerp-community More help : https://help.launchpad.net/ListHelp
