Community mailing list archives
Re: Tax Retencion / Tax Withholding :: Common approachby
David Arnold BA HSG / Analista
315 304 13 68/ firstname.lastname@example.org
devCO - empresa de consultoría de sistemas (en fundación)
This e-mail message may contain confidential or legally privileged information and is intended only for the use of the intended recipient(s). Any unauthorized disclosure, dissemination, distribution, copying or the taking of any action in reliance on the information herein is prohibited. E-mails are not secure and cannot be guaranteed to be error free as they can be intercepted, amended, or contain viruses. Anyone who communicates with us by e-mail is deemed to have accepted these risks. devCO is not responsible for errors or omissions in this message and denies any responsibility for any damage arising from the use of e-mail. Any opinion and other statement contained in this message and any attachment are solely those of the author and do not necessarily represent those of the company.
Hello Community Guys,I do not speak where for the standpoint of a technical guy but a functional guy.We, at Vauxoo, has being involved directly in implementing and deploying ofWithholding (WH) process, localization (L10N) for Venezuela (maintained), Mexico (maintained) and Colombia (unmantained).Throughout my experience in dealing with Withholding and Fiscal Requirements has left my the bittersweet taste of"Universal Withholding System" (UWHS) can not be accomplished, at least with the current approach.Why do I have that vision of half empty cup, and not half full cup?Because,Level 1: for a single country WH are different than othersLevel 2: Taxes: Within a single country There are many different type of taxes.Level 3: Partner: Among Partners WH can be different.Level 4: Products, for each type of products and each product, please read carefully, WH approach can be have different,Level 5: Accounting Timing: Should the WH be performed at invoicing or at payment Time, just to seek two approaches, on suppliers or customers.Level 6: Comparative Units, a la Currency, Statutory Entities set levels that Invoicing or payment should meet to be able to perform a WH. Tax Units as mentioned by @Nhomar.Level 7: Geographical Zones: if a transaction is performed in different geographical entities inside a country, different approaches to perform WH has to be enforced.Level 8: Migratory Status: If a foreign entity stands longer or less than set by law different approaches to perform WH has to be enforced.Level 9: Statutory Entity Entitlement: Government Agencies can entitle a partner to perform WH on behalves of you. Overriding your ability to do so.Other levels I could be missing, these are the ones that just have come to my mind. each level can have many variants.I just have talked about Three different countries, that I do know and I have suffered how their fiscal requirement works.Venezuela, Colombia & Mexico, I can not speak on behalves rest of the world.Finding a solution that try-to-fit-all-but-the-sinkI think that at the end will a daunting task and setting it could be overwhelming.What I think we need is to create a platform that could allow cohabitation ofmore than one L10N in a single instance in a multicompany (MC) environmentI think that was once mentioned by @rvalyi.We have managed to make that cohabitation, in Vauxoo's deploysbut I have to admit it that was far from a easy repeatable receipt.We have to push from a framework where a company can be set for a L10N,I mean If I have three companies: Venezuela, Colombia & Mexico, in a MC environmentI should be able to select which L10N each company in each country will be using,this way, each L10N, will not overlap among them, any user switching among companies will justbe ruled by the L10N that company is configured to. Be that I am logged in asVenezuelan User, only views, fields, and business logic for WH in Venezuela shall be applicable.That feature is the basement for this UWHS,in the meantime we can just work on scaffolding modules,modules that are hollow, only fields and views that overlaps and business logicsthat can end up in spaghetti code.I am a black hat analyst, i.e., I can see where we can fail, and I am tellingwhere we could fail, I am not wishing we to fail, the other way around.I want we to succeed.Best Regards.Quien suscribe,HbtoOn Sat, Oct 18, 2014 at 8:42 PM, Nhomar Hernández <email@example.com> wrote:2014-10-18 18:09 GMT-04:30 Juan José Scarafía (ADHOC) <firstname.lastname@example.org>:* Retentions / withholdings: we refer to amounts been retained on PAYMENTS. It depends in receiver, issuer and sum of amount that has been paid on month or similar.* Perceptions: amounts being "retained" on INVOICE (depends on receiver, issuer and invoice amounts)Just to compliment:In México withholding is "On the tax".In Venezuela withholding is "On the tax" but on "Invoice time"In Colombia is like Venzuela AFAICK.In Brazil other apply.IMHO, withholding must to be:- Configured on "Tax Level".- Have into account the variable David mentioned (Partners (You and customer - You and supplier, Products and Document(s) [Payment, receipt and Invoices])- Computed as a tax on Account Move Line.- It need to be recorded ad a "Document" not as a "Tax".- frquently as Argentina (in Venezuela it happen too!) your Withholding is different even in different cities on th country and the amounts are taken from a no-monetary currency called "Fiscal Unit" (Unidad Tributaria).In our experience even the computing the withholding itself it really complex (for some of them) and so trivials in other documents, we tried without success build an unique model for Colombia and Venezuela and the "IF's" where too much than we decided do 2 development.