Hello all you guys I am quite glad to see that tax issue has been addressed, though not un the regarding trend, sorry for preaching, 'cause I'll contribute to it,
We Vauxoo, formerly known as a branch of netquatro, developed a localization for Colombia on 2011 http://bazaar.launchpad.net/~openerp-colombia/openerp-colombia-localization/5.0/files At that time we addressed those concerns in the way David is pointing Actually, Vat withholding, income withholding and municipality withholding are addressed there, That is: retencion Iva, retención en la fuente, y Retención ICA In the same way we have being addressing the issues in Venezuelan Location Best regards On Jun 23, 2014 8:17 PM, "David Arnold - El Alemán" <[email protected]> wrote: > Last but not least, this concept is at least configurable by an > accountant. So far we oftentimes see hard coded concepts that are only > configurable by developers. I acknowledge that with the pace of changing > tax jurisdiction in south america this might be a sustainable resource of > income. > > But it definitly not is what the coustomers want. > > Here in Colombia, many people have stated privately to me, that service of > some local partners is very bad and unresponsive (= general colombian > cultural issue). They would love to only depend on inhouse accountants, > which oftentimes are the most knowledgable people of the organization... ;) > > > ---------------------- > *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-23 19:35 GMT-05:00 David Arnold - El Alemán <[email protected]>: > >> *comments in plain red* >> >> >> 2014-06-23 18:34 GMT-05:00 Gustavo Adrian Marino <[email protected]>: >> >> Raphäel, David: >>> >>> I really believe we should not fall in love with Odoo, so hard than we >>> try to explain everything in a Odoo compatible way. >>> >>> Taxes are part of legislation. And in all countries I know, they are >>> organized in three levels: Federal or nationals, Federal States and local >>> (Municipal). Each level has his own taxes and rules to be applied to >>> products, companies and types of transactions. >>> >>> Why not try to define objects in OpenERP following the same logic? It >>> will be easier to explain to customers and accountants, to implement and to >>> spot errors in configuration. >>> >> *Somehow, we're trying to achieve exactly this in the present colombian >> localizacion effort by defining tax domains (which can split up further >> each level into its corresponding concepts (eg. VAT, Coustoms, Retentions, >> etc.). This should be a rather short list not superating 20 different >> concepts in most countries. (hint for europeans, who might not understand >> at all, what we are talking about: European countries mostly have only 1 of >> those domains on the invoice level: VAT) The hirachy information is >> implicit to the domain, as users usually know, which tax is from which >> level (eg. VAT = national).* >> >> >>> Let's tie tax definitions to national, federal states and >>> locations/cities (defined once for every company and transaction they >>> apply). >>> >> *This is exactly the proposed concept of tax application steered by >> decision tables. After it's release you should be able to define a state >> tax based on the combination of state and additional attributes of partner >> and product (attributes ideally clusterd under the "state tax" domain) - >> transacction attribute, or how a brazilian collegue called it "attributes >> of the invoice.line level" should be not too difficult to implement. It was >> kept in mind while coding.* >> >> Lets make easy to apply the mandatory taxes and cases. Let's tie the >>> specific taxes to companies, products and types of transactions where they >>> belong and conditionally if they dont belong to some of them: to companies, >>> products and documents (invoices, refunds and payments). >>> >> *What we're working on is fully conditional like so: If set of >> conditions met, then apply set of tax/taxcodes and go to next condition set >> and apply it additionally in a way so that the same tax is only applied >> onces.* >> *You could probably define standard state taxes in a set of rules under >> the "state tax" domain, and then apply some additional special cases under >> some additional circumstances under the same state tax domain.* >> *I acknowledge that sometimes deviation from standard case, in other >> words alteration of a tax (as it is done by the fiscal position rule >> concept) would reduce complexity. Also, having kind of logical operators on >> rule conditions would greatly reduce complexity. See task formulation >> further down...* >> >> *Is there a tax concept which is applied on the generating fact >> (causación), but not reversed on the reversal (refund) of its generation >> fact??? This would be once more typical of south american creative >> jurisdictions...* >> >>> >>> The idea of making a flexible but complex set of rules, not natural to >>> anyone out of the OpenERP world seems to me at least difficult to >>> understand. >>> >> *To reduce complexity, we propose the use of fiscal domains. It's left >> to be seen in action to determin how complex it really is, but i belive >> "separate and conquer" is always a good strategy to cutting through >> complexity. Think of defining a fiscal domain "State Tax", so then you're >> only looking at state tax rules, and you can only apply taxes that are >> within this domain (or have no domain), and you can only take >> product/partner attributes of this domain (or which have no domain), etc. >> So then, once finished with "State Taxes", you might parametrize "national >> taxes" or let's say "IVA" the next day, you can fully filter on that, and i >> hope it's rather easy to grasp, once understanding "additionality" (which >> might be not sufficient for complexity reduction)* >> >> *What is missing at this stage of development, is community/city taxes >> and transaction attributes (invoice.line level attributes), as this is not >> the most urgent focus for colombia. but should be easy to implement, as >> said before.* >> >>> >>> My 2 cents. >>> >> *Thank you, i've the same complexity concerns in fact in mind. And I >> see that a first release of the module would probably not be optimzied >> completely. I therefore want to state two pending tasks already here for >> public consideration:* >> *- Apply configurable logical operators to rules' conditions. (Common use >> case made simple: If I'm in state X and partner is NOT in my state - >> Reduces number of rules by factor of number of states)* >> *- Unify the concepts of fiscal positions (where the module is partly >> derived from) and fiscal allocations. A posible approach could be to define >> child rules on application rules which define exeption handling and have an >> inherent ALTERATION logic, constrained to parent rules for even more >> usability. (would greatly reduce complexity in the case, that a standard >> case applies taxes, which in a very special case should not apply)* >> >>> >>> And I really appreciate your commitment to pursue your ideas and your >>> good attitude of sharing your thoughts with us >>> >> *Thanks, I very much apreciate your feedback!* >> >>> Best regards >>> >>> Gustavo Adrian Marino >>> >>> Mobile: +54 911 5498 2515 >>> >>> Email: [email protected] >>> >>> Skype: gustavo.adrian.marino >>> >>> >>> >>> >>> >>> >>> 2014-06-23 19:12 GMT-03:00 David Arnold - El Alemán <[email protected]>: >>> >>>> Another Idea: >>>> >>>> Couldn't there be a company_id field as a many2many field or is this >>>> incopatible with the core rutoines on company_id fields? Like this every >>>> object could be individually assigned to various companies in a flexible >>>> way. >>>> >>>> I'm sure though I missed something.. ;) >>>> >>>> >>>> ---------------------- >>>> *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-23 17:04 GMT-05:00 David Arnold - El Alemán <[email protected]> >>>> : >>>> >>>> Thank you Raphael! I'm on the edge of understanding ;) After further >>>>> research, I would even consider my previous question obsolete, as all >>>>> (relevant stuff) that fields.property() does is implement a company_id >>>>> statment on a domain search.. This company_id-domain search however is in >>>>> my case already implemented at the moment of application. so using >>>>> properties as many2many (if there were such) would result in doing the >>>>> same >>>>> thing twice. >>>>> >>>>> *Further comments in orange.* >>>>> >>>>> 2014-06-23 16:22 GMT-05:00 Raphael Valyi <[email protected]>: >>>>> >>>>> Hello David, >>>>>> >>>>>> I'm not sure about the performance trade-off you may need to do. >>>>>> Usually I would say assigning taxes isn't really a bottleneck fortunately >>>>>> (as long as you wouldn't be crazy enough to use them in the fields of >>>>>> decision tables). >>>>>> >>>>> *I might have reason to be concerned, as I might have been crazy >>>>> enough ;)* The situation so far is [] of properties of the actual >>>>> tax case on a inoice.line basis (collectet from m2m fields of product and >>>>> partner) matching against a [] of properties of the tax rule set by a >>>>> regular many2many field. >>>>> >>>>>> That being said there is an other important functional consideration >>>>>> in our experience: sometimes the several companies belong to the same tax >>>>>> jurisdiction and sometimes not... >>>>>> That is if you force to share tax settings between companies it may >>>>>> not work in some situations. >>>>>> While on the other hand, if you force to re-configure possibly >>>>>> complex tax settings when companies belong to the same tax jurisdiction, >>>>>> well you might force your customer to depend on expert fiscal consulting >>>>>> when he isn't psychologically ready for that... >>>>>> >>>>> *Thanks for the hint!* *I think this also refers to a comment made >>>>> by Gustavo Marino earlier on multicompany setups.* >>>>> >>>>>> >>>>>> So as I explained in a other post, in Brazil we started with >>>>>> properties and changed some fields to regular many2one to cut the >>>>>> bureaucracy in case of companies sharing similar settings. We did that >>>>>> for >>>>>> the fiscal classification (the "Nomenclatura Comum do MERCOSUL" in >>>>>> Brazil) >>>>>> attached to the product.template. >>>>>> A possible evolution that may fulfill all requirements in this case >>>>>> would be 2 fields: 1 m2o property and and regular m2o. If the m2o is set >>>>>> it >>>>>> would shadow the property setting. That may fit most of the use case (the >>>>>> case with some companies of the DB sharing tax settings and some other >>>>>> not >>>>>> is very rare and can still be addressed by using properties all the way >>>>>> at >>>>>> the cost of the extra bureaucracy of setting all these properties). >>>>>> >>>>> *Probably a more elegant and generic solution could be via templates >>>>> and then run template updates sporadically on different companies. >>>>> Although >>>>> this is not a true share on the object level, it might cover the needs and >>>>> include optional extra flexbility on the company level. I ignore however, >>>>> if a template is able to update content or just can create content, and if >>>>> the latter, how difficult it would be to add sort of a diff-funcionality >>>>> (update, create, unlink).* >>>>> >>>>> *I say this because similar issues arise on account charts, e.g. if >>>>> the mother house has a given, but extensible set and wants to populate it >>>>> within the holding companies with regular updates. So abstracting, this is >>>>> a generic multicompany maintainance topic...* >>>>> >>>>>> >>>>>> I'm not sure what would be these many2many relations in your case >>>>>> though. >>>>>> >>>>> *As explained above, the idea is to have a highly flexible set of >>>>> properties on products and partners, clustered by tax domains* >>>>> *e.g.:* >>>>> *Product: Airbus A380* >>>>> *Property 1: Fiscal Domain = VAT; Attribute Use = Product; Name = "has >>>>> a left wing (attribute for left wing tax exempt rule XY as of law 12345 of >>>>> 1995)"* >>>>> *Property 2: Fiscal Domain = IPI; Attribute Use = Product; Name = "I'm >>>>> a passenger aircraft"* >>>>> *Property 3: Fiscal Domain = Withholding; Attribute Use = Product; >>>>> Name = Not subject to tax withholding as of national development plan 1369 >>>>> of 1634"* >>>>> *Property n: Fiscal Domain = Aduana; Attribute Use = Product ; Name = >>>>> "Aircraft over 200 metric tons"* >>>>> >>>>> >>>>> *Partner: Client in Zona Franca Property 1: Fiscal Domain: Aduana; >>>>> Attribute Use = Partner_Shipping; Name = "Professional Aircraft buyer >>>>> under >>>>> National Aircraft prolifertion regime"* >>>>> *Property n: ....* >>>>> >>>>>> >>>>>> Regards, and sorry for not having looked deeply at your work yet. >>>>>> >>>>> *It's still debugging ;)* >>>>> >>>>>> >>>>>> -- >>>>>> Raphaël Valyi >>>>>> Founder and consultant >>>>>> http://twitter.com/rvalyi <http://twitter.com/#!/rvalyi> >>>>>> +55 21 3942-2434 >>>>>> www.akretion.com >>>>>> >>>>>> >>>>>> >>>>>> On Mon, Jun 23, 2014 at 5:32 PM, David Arnold - El Alemán < >>>>>> [email protected]> wrote: >>>>>> >>>>>>> *Hi* >>>>>>> >>>>>>> I already read some remarks on pros and cons about property fields. >>>>>>> >>>>>>> As far as my knowledge reaches, property fields are not best for >>>>>>> performance. On the other side, you can assign to the same object (let's >>>>>>> say a product) various properties based on the current users company. >>>>>>> >>>>>>> The case is an advanced tax engine (posted about before), where I >>>>>>> have to make a choice about, wether to implement fiscal properties of >>>>>>> products and partners as ir.properties or as regular many2many fields. >>>>>>> >>>>>>> If the decision would be principally in favor of fiscal properties, >>>>>>> if the benefits of properties would justify to hack the core method in >>>>>>> fields.py to accomodate many2many properties. >>>>>>> >>>>>>> *Thank you beforehand for your opinion.* >>>>>>> >>>>>>> *Best* >>>>>>> >>>>>>> David >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Mailing list: https://launchpad.net/~openerp-community >>>>>>> Post to : [email protected] >>>>>>> Unsubscribe : https://launchpad.net/~openerp-community >>>>>>> More help : https://help.launchpad.net/ListHelp >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>>> _______________________________________________ >>>> Mailing list: https://launchpad.net/~openerp-community >>>> Post to : [email protected] >>>> Unsubscribe : https://launchpad.net/~openerp-community >>>> More help : https://help.launchpad.net/ListHelp >>>> >>>> >>> >>> _______________________________________________ >>> Mailing list: https://launchpad.net/~openerp-community >>> Post to : [email protected] >>> Unsubscribe : https://launchpad.net/~openerp-community >>> More help : https://help.launchpad.net/ListHelp >>> >>> >> > > _______________________________________________ > Mailing list: https://launchpad.net/~openerp-community > Post to : [email protected] > Unsubscribe : https://launchpad.net/~openerp-community > More help : https://help.launchpad.net/ListHelp > >
_______________________________________________ Mailing list: https://launchpad.net/~openerp-community Post to : [email protected] Unsubscribe : https://launchpad.net/~openerp-community More help : https://help.launchpad.net/ListHelp
