Community mailing list archives

community@mail.odoo.com

Re: Tax Retencion / Tax Withholding :: Common approach

by
dar
- 10/20/2014 00:48:41
Hi Enthusiasts, Hi Devil's Advocates ;)

thanks for the excellent feedback. And I'll take up only the last line written: "I want we to succeed".

I hope everyone is fine with having this conversation in spanish as I think it would be easier for all of us to communicate more effectively with having the proper special terms and definitions at hand. Thanks for your kind understanding, a sumary in english would be in blue color.

Entonces mirando otra vez mi mockup (https://gomockingbird.com/mockingbird/#zq0em7d - please click on the jumpto in order to see the various pages) creo que necesito saber mas sobre el concepto mencionado de retenciones y percepciones.

Segun lo visto en algunos blogposts:

Percepciones son impuestos normals como son conocido en todo el mundo que el vendedor aplica sobre el valor neto de la facrtura
Retenciones son gravamenes (locos) que el comprador appliqua sobre una facura generalmente ya generada. De esa forma esta obligado a alterar la realidad dispuesto en el documento de la factura de forma unilateral y posterior. Es eso que se refiere "al momento de pago". Eso implique que el comprador agente retenedor tiene que certificar al vendedor la practica de dichas retenciones ya que no estan (necesariamente) establecidas en la factura orignal. En Colombia esta certificacion puede ser un documento annexo a la facutra, pero de igual forma el vendedor ya puede anticipar dicha applicacion investigando las circunstancias y responsabilidads tributarias del comprador y de esa manera incluirla en la factura, basicamente ahorando asi papel (y tiempo y costos de transaccion). De igual forma el comprador puede emtir un documento que se asimila a la facutra conteniendo dichas retenciones y hacerle llegar al vendedor como comprobante de la applicacion. (En Odoo seria imprimir y hacer llegar la "Factura de proveedor") 

La ley en colombia, frente a las retenciones, exige su aplicacion "en el momento de pago o abono en cuenta" donde el abono encuenta se refiere al asiento contable que lo registra en una cuenta del plan contable. Hay mucha confusion sobre ese concepto pero al pied de la letra y en la practica contable es al momento de "generar la factura" ya que si ocurre primero el pago, seria no un pago de factura, sino un anticipado "libre" donde los conceptos mismos que son objeto de retencion no estan establecidas, debido a es la factura misma que lo establece. 

Por ende, las retenciones se pueden establecer al momento de que el VENDEDOR emite la factura al COMPRADOR ya teniendo en cuenta de manera anticipada las responsabilidades del COMPRADOR y la situacion especifica. De esa manera ya forman parte de la factura original sin dar necesidad material a generar otro comprobante de applicaccion ahorrando asi costos de transaccion.

Por otra parte, si el VENDEDOR falla a establecerle de manera anticipada, el COMPRADOR puede de su parte emitir una facutra de proveedor que compruebe la incorporacion de las retenciones y se adjuntaria a la factura original como soporte y se deberia hacerla llegar al VENDEDOR por ese fin. (-> Mas costos de transaccion)

La applicacion en la contabilidad entonces seria al momento de la causacion. Aun que se realizara su applicacion real frente al VENDEDOR en el momento del pago (ya que el monton registrado en la cuenta accreditora esta disminuido por las retenciones). Asi puede succeder la situacion que se hara el pago a la entidad tributaria antes de que se haya recaudado la retencion del VENDEDOR. Segun mi entendido, eso es lo correcto. Pero en ningun caso puede violar la ley ya que un pago anticipado a las autoridadas tributarias mal puede ser prejudical.

Por lo anterior es importante concluir que la retencion es un concepto que de manera oportuna se etablezca junto con la factura original o mediante una factura "secundaria y comrobatoria" emitida del COMPRADOR. Viendolo de esa manera Odoo nos dispone de todos los conceptos basicos necesarias para establecer el concepto de retenciones sobre el modelo tecnico de la factura (sea venta o compra).

Es asi que se justificaria de igual manera dividir el concepto actual de impuestos en:
- Impuestos / Percepciones
- Retenciones
Asi siendo asientable al plan contable por medio de la registracion de una factura

These are the reasons that would justify the division of the tax concpet into two types:
- Taxes and 
- Withholdings
And therefore would be posted at the momento of the Invoice to the Chart of Accounts.

La UVT - Unidad de Valor Tributario - al parecer tambien existe en muchos paises sudamericanos y su fin es establecer una referencia flexible que facilmente puede ser adaptada a la inflacion sin necesidad de actualizar todas las referencias en las leyes. Es importante entender esta characteristica para entender su applicacion commun. La UVT es utilizada como una funcion de la moneda legal, con una tasa de conversion cada vez actualizada. Su applicacion es unicamente de modo referencial y muchas vezes utilizada para definir limites o bases de aplicacion. - Es un concepto aislado totalmente abstraible y de esa forma no aumenta la complejidad por el momento.

Ya se ha commentado sobre la la logica de applicacion de las retenciones y los impuestos normales que depende de muchos factores. Pero aca no quiero hablar de eso. Al pied de la letra eso son reglas de applicacion que pueden ser automatizadas o no y siempre serian bajo la vigilancia de un contador (o no).

Aca es importante las diferencias y las parallelidades de retenciones y percepciones (AR) / impuestos (CO) y derivar de eso la necesidad de dividir el concpeto Odoo de impuestos(AR) / gravamenes(CO) / Taxes(EN) en dos variedades. 

Un Colombiano diria: Gravamenes = Impuestos + Retenciones
Un Argentino diria: Impuestos = Percepciones + Retenciones
Un Europeo diria: Taxes = Taxes

I would therefore propose to have those differences properly handled throughout the handling of an invoice as proposed in the mockup, which is in english by the way, so have a look... https://gomockingbird.com/mockingbird/#zq0em7d

Por fin quiero preguntar a Juan José como exatamente es posible que una retencion se basara sobre un valor aggregado mensual. Respuesta detalada, por favor ;)

Por ultimo quiero proponer si nos podemos acordar en el anterior proceder a la parte compleja (logica de aplicacion) a una segunda fase de levante de requerimientos en una tabla googlesheet.
Para eso necesitamos una categorizacion intelligente de attributos tributarias principalente sobre dos modelos:
- Partner (tales como: Grande Contribuyente, Autorretenedor, Regimen Simplificado, Regimen Commun, Entidad estadal, Sociedad commercio exterior; etcetera - nota: la informacion territorial ya reside en las direcciones de los dos terceros que interactuen en una factura)
- Product (tales como: clase arrancelaria andina, codigo CIIU, typificacion national, grado alcohol, etcetera)

Saludos Cordiales
David Arnold

David Arnold BA HSG / Analista
315 304 13 68/ dar@devco.co

devCO - empresa de consultoría de sistemas (en fundación)
http://www.devco.co

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.


2014-10-19 0:17 GMT-05:00 Humberto Arocha <hbto@vauxoo.com>:
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 of
Withholding (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 others
Level 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-sink 
I 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 of
more than one L10N in a single instance in a multicompany (MC) environment
I think that was once mentioned by @rvalyi.

We have managed to make that cohabitation, in Vauxoo's deploys 
but 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 environment
I 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 just
be ruled by the L10N  that company is configured to. Be that I am logged in as
Venezuelan 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 logics
that can end up in spaghetti code.

I am a black hat analyst, i.e., I can see where we can fail, and I am telling
where we could fail, I am not wishing we to fail, the other way around.
I want we to succeed.

Best Regards.

Quien suscribe,

Hbto


On Sat, Oct 18, 2014 at 8:42 PM, Nhomar Hernández <nhomar@gmail.com> wrote:

2014-10-18 18:09 GMT-04:30 Juan José Scarafía (ADHOC) <scarafia.juanjose@gmail.com>:
* 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.


--
--------------------
Saludos Cordiales
 
--
Nhomar Hernandez
 

_______________________________________________
Mailing-List: https://www.odoo.com/groups/community-59
Post to: mailto:community@mail.odoo.com
Unsubscribe: https://www.odoo.com/groups?unsubscribe


_______________________________________________
Mailing-List: https://www.odoo.com/groups/community-59
Post to: mailto:community@mail.odoo.com
Unsubscribe: https://www.odoo.com/groups?unsubscribe