IVA en version 3.4

[santseya]

Hola buenos dias y gracias por el software de antemano.

Calculando los Ivas me sale descuadrado por el tema de los decimales, he probado a cambiar los parametros de limites y precision cn las solucines que he encontrado por el foro per me sigue saliendo erronero el Iva.

Alguien podria ayudarme a solucionar esto

Muchas gracias

[leonardo.martinez]

Hola, si das con la solucion podrias indicarmela, ya que hice la misma pregunta hace más de un año y el foro no contesta.
Muy agradecido de antemano

Visita www.itstudio.cl

[bercovicho]

Estimados, el problema no es el calculo del iva en "Precisión y limites". es la forma que utiliza el sistema para procesar que no se usa en algunos países.

el calculo de iva en dolibarr es por linea de producto, que se calcula sobre el precio neto de linea y el descuento si tiene. la suma de todos los netos es el total sin impuesto de las facturas, pero el IVA y el TOTAL es la suma del iva de cada linea (parciales) y según la regla de precisión puede truncar decimales esto es util cuando los productos tienen distinto tipo de tasa de impuesto.

lo que muchos paises hacen con sus sistemas de facturación es calcular el iva del total para evitar la desviacion y el truncamiento de los montos . pero en la practica tu puedes calcular el iva de las 2 formas y obtener un margen de error por linea y está permitido. lo que no esta permitido es que el monto neto total + iva sea distinto al valor de la factura final tiene que ser completamente consistente y no independientes como lo plantea dolibarr.


ojo solo para desarrolladores

para corregir definitivamente este problema hay que modificar la clase del modulo de calculo y registro de documentos (hay un archivo comun para todos los modulos que maneja eso) y decirle al sistema que calcule el iva desde el total y con el formato deseado utilizando como base la suma de los valores netos de las lineas. y ese monto se vaya directamente a la base de datos.

el código alguna vez lo publiqué para la versión 3.1 pero imagino que para la 3.4 debe ser parecido.

si les sirve de ayuda busquen un archivo de clase que contenga la sentencia UPDATE del monto del iva en la db.

[marcosgdf]

Hola santseya:

Pon un ejemplo de factura con IVA mal calculado para que podamos encontrar la configuración adecuada.

Un saludo.

[Unimbo]

Quería saber si de alguna forma se puede hacer que el cálculo del IVA sea sobre el importe neto del total de la factura. Ahora se calcula por línea, pero esto no es como lo debo aplicar.
Si hay que tocar código no hay problema, pero una orientación estaría bien.

Gracias y un saludo.

P.D.: Esperemos poder solucionar este problema en la menor brevedad posible. Es la única pega que le he encontrado a Dolibarr.

[marcosgdf]

Hola Unimbo:

Hasta donde yo sé no es posible, sin embargo con una configuración adecuada de redondeo no debería notarse.

Un saludo.

[Unimbo]

Hola Marcosgdf,

Te pongo un ejemplo del problema que tengo al introducir una factura de un proveedor. La factura consta de tres líneas y tengo un descuadre de 0,01€. Es poco pero si ya en tres líneas tengo este descuadre no se como se comportará con una cantidad mayor.

Nº Línea _________________IMPORTE NETO____IVA(21%)___________TOTAL LÍNEA
1_____________________________55,50________11,655______________67,16€
2_____________________________33,85________7,1085______________40,96€
3_____________________________18,22________3,8262______________22,05€

TOTAL LÍNEAS_________________107,57________22,60______________130,17€

Al hacer el redondeo del IVA en las líneas y no al final los importes totales de la factura no cuadran. Deberían ser:

TOTAL LÍNEAS_________________107,57________22,59______________130,16€
Este resultado lo consigo calculando el IVA del importe total de 107,57. Así es como hemos de calcular las facturas en territorio español.

Por eso no me sirve la configuración del redondeo.

Aprovecho para agradecer el inmenso trabajo que hacéis en esta aplicación y me ofrezco como programador a ayudar a resolver este "problema" para la facturación en España.

[bercovicho]

Les voy a contar como solucioné el tema para una localizacion en chile, ojo que en nuestro pais no ocupamos decimales en los totales, pero me imagino que ajustar el tema para españa es muy similar.

Actualmente los totales no son redondeados, solo es la sumatoria de los totales sin impuestos (total_ht), total impuestos (total_tva) y total general (total_ttc)

la idea era aplicar la regla de redondeo al comprobar los totales de cada documento (presupuestos, pedidos y facturas a clientes, pedidos a proveedor y facturas de proveedor)

Luego de analizar el codigo y las funciones de cada formulario, descubri que Dolibarr por defecto hace esta operacion en un solo archivo ubicado en el core via SQL
la ruta es:
..htdocscoreclasscommonobject.class.php

Si se fijan en la version 3.4.1 (linea aprox 1567 ) hay una linea comentada que dice

// Now update global field total_ht, total_ttc and tva

y luego sigue la sentencia para actualizar los datos en la db

if (empty($nodatabaseupdate))
{
$sql = 'UPDATE '.MAIN_DB_PREFIX.$this->table_element.' SET';
$sql .= " ".$fieldht."='".price2num($this->total_ht)."',";
$sql .= " ".$fieldtva."='".price2num($this->total_tva)."',";
$sql .= " ".$fieldlocaltax1."='".price2num($this->total_localtax1)."',";
$sql .= " ".$fieldlocaltax2."='".price2num($this->total_localtax2)."',";
$sql .= " ".$fieldttc."='".price2num($this->total_ttc)."'";
$sql .= ' WHERE rowid = '.$this->id;


El punto es incorporar una regla de redondeo en la variable que necesitamos dejar ajustada segun nuestra localizacion.

Eso se puede hacer mediante la funcion round() en php
http://www.php.net/manual/es/function.round.php
en mi caso redondear sin decimales es solo colocar la funcion sin argumento.
para el caso de mas decimales queda round($var, ndecimales)
para hacerlo mas facil la agregamos directamente en el sql

$sql = 'UPDATE '.MAIN_DB_PREFIX.$this->table_element.' SET';
$sql .= " ".$fieldht."='".round(price2num($this->total_ht))."',";
$sql .= " ".$fieldtva."='".round(price2num($this->total_tva))."',";
$sql .= " ".$fieldlocaltax1."='".price2num($this->total_localtax1)."',";
$sql .= " ".$fieldlocaltax2."='".price2num($this->total_localtax2))."',";
$sql .= " ".$fieldttc."='".round(price2num($this->total_ttc))."'";
$sql .= ' WHERE rowid = '.$this->id;

y entonces forzamos los totales a un redondeo global cada vez que creamos o modificamos un documento, dejando los valores ajustados en la base de datos.

Eso es todo, no hagan eso en una instalacion de produccion directamente ya que en mi caso funciono luego de muchas pruebas. tampoco me hago responsable por errores, ya que como es el core pueden dejar tremendo problema en la plataforma modificando sentencias sql.

Saludos.

[marcosgdf]

Hola:

He probado a aumentar la precisión de los cálculos y sí que es cierto que hay un pequeño descuadre... Para tu tranquilidad he visto que en la 3.6 se plantea el utilizar 2 métodos para calcular el IVA: 1 sobre el total y otro línea a línea.

Por culpa de mi trabajo no puedo dedicarle mucho tiempo a Dolibarr y estoy un poco fuera del ecosistema de éste por lo que no te puedo dar mucha ayuda... Te recomiendo echarle un vistazo a la lista dolibarr-dev@nongnu.org, github.com/dolibarr/dolibarr y el tracker de incidencias/requests en doliforge.org.

En dolibarr.org hay mucho más movimiento por lo que allí podrías entrar en contacto con alguno de los desarrolladores principales.

Siento no poder ayudarte mucho más...

Un saludo.

[Unimbo]

Hola,

Gracias por las respuestas, este fin de semana es puente y no he tenido tiempo de mirarlo.

El consejo "bercovicho" es sobre el redondeo y no es eso lo que necesito, pero gracias.

Lo que comenta Marcosgdf es exactamente lo que necesito, me miraré lo que me indicas, muchas gracias.

Está muy bien que en la próxima versión permitan hacer el cálculo del IVA del total, es señal de que la aplicación avanza.

Buen trabajo y felicidades al equipo de Dolibarr.