13 respuestas en este tema

[lnufish]

hola amigos!

tengo una consulta para ustedes! - estoy teniendo problemas con firebird y el redondeo la cuestion es que necesito precision en los datos devueltos por la base de datos  y firebird no me redondea bien!
tengo varios trigger los cuales realizan bien los calculos pero a la hora de redondear no lo hace con la precision que necesito! tengo campos decimal 12,2  y varios campos que hacen operaciones entre si cuando se inserta, actualiza y borra un registro - pregunta = la utilizacion de campos calculados me ayudaran a resolver este problema ? para este caso usaria lazarus y zeos y firebird 2.5 - la opcion de la utilizacion de round en firebird no me sirve!

muchas gracias!

[Marc]

hola amigos!

tengo una consulta para ustedes! - estoy teniendo problemas con firebird y el redondeo la cuestion es que necesito precision en los datos devueltos por la base de datos  y firebird no me redondea bien!
tengo varios trigger los cuales realizan bien los calculos pero a la hora de redondear no lo hace con la precision que necesito! tengo campos decimal 12,2  y varios campos que hacen operaciones entre si cuando se inserta, actualiza y borra un registro - pregunta = la utilizacion de campos calculados me ayudaran a resolver este problema ? para este caso usaria lazarus y zeos y firebird 2.5 - la opcion de la utilizacion de round en firebird no me sirve!

muchas gracias!

Hola.

¿ Puedes dar algún ejemplo ?.

Si nos puedes indicar alguna de las operaciones que realizas, junto a los valores implicados y el resultado final en comparación con el resultado esperado, entonces seguro que te podemos orientar para conseguir ese resultado.

Saludos.

[lnufish]

paso ejemplo de triggers:

after insert:

[firebird] update a set precioneto = cantidad * precio where articulo = new.ARTICULO;
  update a set iva = precioneto * 21 / 100 where articulo = new.ARTICULO;
  update a set preciototal = precioneto + iva where articulo = new.ARTICULO;
  update a set totaliva = (select sum (iva) from a where articulo >= 1) where articulo >= 1;
  update a set totalsin = (select sum (precioneto) from a where articulo >= 1) where articulo >= 1;
  update a set total = (select sum (preciototal) from a where articulo >= 1) where articulo >= 1;
[/firebird]
after update:

[firebird]  if (new.CANTIDAD > 0) then
  begin
  if (new.CANTIDAD <> old.CANTIDAD) then
  begin
  update a set precioneto = cantidad * precio where articulo = old.ARTICULO;
  update a set iva = precioneto * 21 / 100 where articulo = old.ARTICULO;
  update a set preciototal = precioneto + iva where articulo = old.ARTICULO;
  update a set totaliva = (select sum (iva) from a where articulo >= 1) where articulo >= 1;
  update a set totalsin = (select sum (precioneto) from a where articulo >= 1) where articulo >= 1;
  update a set total = (select sum (preciot) from a where articulo >= 1) where articulo >= 1;
  end
  end
  else
  begin
  update a set cantidad = 1 where articulo = old.ARTICULO;
  end
[/firebird]
el resultado esperado es que al obtener el iva y el total neto y el total con iva los valores tienen pequeñas diferencias ya que firebird redondea en determinados casos de forma que no da "exacto" ejemplo en un caso que deberia dar 2.23 firebird me lo pasa a 2.25 por dar un ejemplo, no lo tengo en mano un caso ocurrido pero mas o menos es asi , como podria solucionar este margen ya que el resultado debe ser exacto!

muchas gracias!

[Sergio]

¡Estas intentando la cuadratura del circulo!

Quieres calcular el IVA linea a linea, luego sumarlo, y que te de el 18% de la suma de las bases: no podras conseguirlo nunca.

Cada linea solo puede tener un total en euros, que sera precio * uinidades redondeado al numero de decimales que quieras mostrar (ojo, si precio y unidades tiene 2 unidades, y el total de la linea lo redondeas a 2 decimales tambien, estás perdiendo algo de "base" en cada linea, pero esto es correcto, aunque puedes decidir que tus lineas de factura usaen 4 decimales. Al final la base TIENE que ir con 2 decimales, asi que solo puedes redondear linea a linea o solo en el total de las base).

El sumatorio de los totales de linea te da la base de la factura, y SOLO sobre la base tiene algún sentido calcular el IVA.

Te pongo un ejemplo extremo, pero posible:

Tienes 100 lineas de factura, en cada una vendes 1 unidad a un precio 1 centimo, con lo que el total de la linea es 0.01€, y si le calculas el IVA a esa linea te da o bien 0.00€ de IVA o bien 0.01€, segun decidas si vas a redondear de una u otra forma, lo mismo da.

Ahora sumas el iva de las 100 lineas: 100 veces 1 centimo = 1€ (o 0€ si redondeaste a la baja el iva de cada linea).

Ya lo tienes: Una base de 1€ (100 x 0.01€) pero con un sumatorio de ivas que es, o bien 1€ o bien 0€... con esta estrategia nunca jamas a ese sumatorio te va a dar el 18% de 1€, y no es un problema de redondeos, es de concepto: las lineas de factura no pueden ni pueden tener iva, solo el total de factura.

[Marc]

Hola.

Personalmente guardo los importes de IVA de las líneas de factura con 4 decimales (como también sugiere Sergio), de forma que en el ejemplo de Sergio, el IVA de esas líneas sería 0.0018

Así no se pierde precisión, y la suma de IVA's de linea corresponde al 18% de la suma de bases de línea.

Naturalmente el total de IVA de la factura, lo acabo redondeando a solo dos decimales.

Como dice Sergio, esto no es un problema de mal redondeo de Firebird, te ocurriría igual con cualquier otro motor de bases de datos.

Saludos.

[Wilson]

Pienso que el problema es más de diseño y de concepto. Por ejemplo, en el diseño de la DB de Inufish, que pasa si mañana el gobierno decide excluir el iva de algunos artículos y cambiar el de otros? Te enloqueces tratando de reprogramar la entrada de compras y de ventas ... eso ocurre en Colombia, los artículos tienen diferentes Ivas, aún si nó fuera así, en mi concepto es mejor añadir un campo IVA a la  tabla artículos y nó dejarlo exclusivamente en la tabla de detalles, aunque esta debe también debe tener el campo IVA, de esta forma el campo iva de la línea de detalles lo cálculas a la hora de escoger el artículo.

Del mismo modo pienso que si la tabla "a" de tu trigger es la tabla de detalles, entonces  te sobran varios campos de dicha tabla  en tu diseño, (PrecioNeto, PrecioTotal, TotalIva,TotalSin, Total) estos campos deberían ser campos calculados por la aplicación, no habría necesidad de almacenarlos. Con base en estos ya puedes realizar los cálculos para la tabla maestra haciendo la sumatoria de las columnas correspondientes.


Te aclaro que es tan solo una forma de ver las cosas.

Saludos

[Sergio]

Personalmente guardo los importes de IVA de las líneas de factura con 4 decimales (como también sugiere Sergio), de forma que en el ejemplo de Sergio, el IVA de esas líneas sería 0.0018

Hola Marc, yo no digo de usar 4 decimales para el IVA de cada linea, si acaso para el total de esa linea (yo uso 2 decimales en precio y dos en unidades, y redondeo a 2 tambien el total de cada linea, pero segun el tipo de empresa pueden necesitar 4 o mas). Yo digo no calcular el IVA de la linea, porque no tiene ni sentido (se paga IVA del total final de la factura) pero puedes guardar el tipo de IVA (en %) de cada linea si hace falta, pero en euros es un problema.

Por ejemplo: Tu usas 4 decimales en el IVA de una linea, pero en alimentacion hay tipos de IVA reducidos de, por ejemplo 6.5 y cosas asi... ahora necesitarias 5 decimales!

Pero además, las unidades pueden tener 4 decimales, en cuyo caso precio * unidades tiene 6, y el IVA 8 o 9 si es del 6.5%... o precios y unidades con 4 decimales.... un verdadero lio, porque sobre las lineas de factura no hay normas, solo importa el total de la factura a un cierto tipo de IVA, y ese total va con 2 deimales por ley (en España).

Y ademas, al final tu necesitas saber la base a cada tipo de IVA, por eso lo suyo es guardar en cada linea el % (si has de admitir 2 o mas IVAS por factura) y luego totalizar a nivel de factura: sumas los totales de las lineas al 18%, REDONDEAS a 2 decimales, y sobre esa base calculas el importe del IVA.

...y todo esto se complica aun mas si tienes recargos de equivalencia, descuentos sobre los precios adicionales, etc.

Te pongo un ejemplo casi "real": el movil lo pagas a 0.12€ el minuto, hablas solo 3 segundos, esa linea de tu factura suma 0.12*3/60 = 0.006€, que al 18% de IVA = 0.006*0.18=0.00108€, pero tu sistema redondearia ese IVA a 0.0011€. No tiene mucho sentido, el IVA siempre se calcula sobre un total con 2 decimales y se redondea a 2 decimales, eso segun la ley, asi que todo esto es gastar espacio de la BD y exponerte a un problema.

Marc, te lanzo una pregunta dificil sobre IVA que se me planteo un cliente hace unos meses (se la respuesta, es solo un trivial): Si el total de factura * el tipo de IVA te da 12.235€ y según la ley se ha de redondear a 2 decimales, podrias redondearlo a 12.23 o 12.24 ¿cual esl el valor legalmente correcto del IVA?

Me costo mucho localizar una respuesta repaldada por la ley del IVA, no te creas que es sencilla la preguntita de marras (tampoco te lies a buscar leyes, te paso luego un link resumen)!

[Marc]

Hola Sergio.

Sí, tienes razón. Mis clientes no trabajan con IVA's decimales, ni importes con cuatro decimales, y aún así me encuentro con diferencias debido a los descuentos generales. Pero con todos los cálculos intermedios a cuatro decimales y un resultado final redondeado a dos decimales, esas diferencias no suelen afectar a dicho resultado final.

En todo caso, llevas razón en que lo suyo es guardar el IVA aparte (en una tabla de desglose de IVA, para cuando puedes tener diferentes tipos de IVA's en la misma venta). Yo lo guardo también en las líneas de venta, simplemente porqué guardo un montón de datos intermedios totalmente innecesarios, pero que después me pueden facilitar algunos cálculos.

Marc, te lanzo una pregunta dificil sobre IVA que se me planteo un cliente hace unos meses (se la respuesta, es solo un trivial): Si el total de factura * el tipo de IVA te da 12.235€ y según la ley se ha de redondear a 2 decimales, podrias redondearlo a 12.23 o 12.24 ¿cual esl el valor legalmente correcto del IVA?

12.24€ ¿ verdad ?. El IVA utiliza el redondeo monetario, es decir, el redondeo por arriba, en lugar del redondeo matemático, que por defecto es por abajo y daría 12.23.

Saludos.

[Sergio]

Hola Sergio.

Sí, tienes razón. Mis clientes no trabajan con IVA's decimales, ni importes con cuatro decimales, y aún así me encuentro con diferencias debido a los descuentos generales. Pero con todos los cálculos intermedios a cuatro decimales y un resultado final redondeado a dos decimales, esas diferencias no suelen afectar a dicho resultado final.

En todo caso, llevas razón en que lo suyo es guardar el IVA aparte (en una tabla de desglose de IVA, para cuando puedes tener diferentes tipos de IVA's en la misma venta). Yo lo guardo también en las líneas de venta, simplemente porqué guardo un montón de datos intermedios totalmente innecesarios, pero que después me pueden facilitar algunos cálculos.

Marc, te lanzo una pregunta dificil sobre IVA que se me planteo un cliente hace unos meses (se la respuesta, es solo un trivial): Si el total de factura * el tipo de IVA te da 12.235€ y según la ley se ha de redondear a 2 decimales, podrias redondearlo a 12.23 o 12.24 ¿cual esl el valor legalmente correcto del IVA?

12.24€ ¿ verdad ?. El IVA utiliza el redondeo monetario, es decir, el redondeo por arriba, en lugar del redondeo matemático, que por defecto es por abajo y daría 12.23.

Saludos.

Marc, cuando hace poco se subio el IVA al 18€, perfectamente podrían haber elegido el 17.5% y te hubieses encontrado en serios problemas, hay muchas cosas que pueden ir mal si se usa el IVA linea a linea. Mi programa permite elegir el % de IVA, supongo que el tuyo tambien, y cualquier dia aparecera un valor con decimales (bueno, igual lo definiste como integer, en ese caso el cliente te llamará y te pedira decimales) y ya tienes descuadres.

Piensa que si tu sistema de calculo del IVA, sea el que sea, al final te da un total base y un total IVA que no cumplan que el IVA es el % que toca de la base, redondeado al centimo mas cercano, tu factura no es válida, así que esos descuadres que te aparecen algunas veces pueden hacer que los totales que das sean "alegales", por decir algo.

En el tema del redondeo, diste la respuesta "standard" pero que no es la correcta, bueno, si lo haces al alza tu calculo es correcto, pero no es obligatorio hacerlo así.

El "redondeo monetario" no es al alza, en ningún sitio pone eso, absolutamente en ninguno. Esa creencia viene de cuando el paso de pesetas a euros, en ese cambio si que se exigia un redondeo al alza en caso de porciones de centimo, pero una vez convertido todo a euros, no existe ninguna regla establecida de como se ha de redondear, la ley solo dice "al más cercano", asi que 0.003€ es 0.00€, y 0.006€ es 0.01€, pero 0.005€ puedes elegir a tu gusto como tratarlo, siempre que una vez fijes el IVA como 0.01€ o 0.00€, lo uses ya en todos tus calculos, resumenes de IVA, etc.

Lo encontre tras mucho buscar en una respuesta vinculante de hacienda a una pregunta de una empresa de programación, te pone un monton de leyes al respecto y esas cosas, pero deja claro el tema.

Por cierto, nuestra aplicación usa el redondeo que trae delphi por defecto: si la ultima cifra es par o impar, redondea al alza o a la baja el medio centimo. Este sistema es el mejor a nivel matematico porque no tiene "sesgo": Si eliges redondear el medio centimo al alza siempre, como es tu caso, y coges la facturacion de un año, sumas las bases, y calculas el IVA global del año como un porcentaje sobre ese total, y ahora lo comparas con la suma de los IVAs de cada factura, mas o menos tiene que coincidir, pero en tu caso es de esperar un total teorico algo mas bajo que el real obtenido debido a que estos "casos grises" los redondeastes al alza, pero si alternas alza/baja obtienes un sistema de redondeo "justo".

[Marc]

Hola Sergio.

En realidad ya pase el IVA a decimales el año pasado cuando hicimos una venta en Argentina y allí utilizan valores decimales de forma común (aunque no lo he nombrado porqué solo es un cliente que utiliza decimales).

Me has sorprendido con el redondeo del IVA, estaba seguro de haber leído que hay que usar siempre el redondeo superior. Además también pensaba que el redondeo propio de Delphi era siempre "a la baja" (igual que el redondeo de Firebird, etc. ...), no sabía que alternaba el superior con el inferior.

Siempre se aprende algo nuevo .

Saludos.

[Sergio]

El IVA con decimales es normal en España en el sector de la alimentacion, tubimos un cliente hace tiempo que vendia arroz, habichuelas y lentejas y cosas asi, y ocurre que segun el producto tenia un IVA u otro (primera necesidad como arroz es mas bajo el IVA que por ejemplo las lentejas y cosas del estilo) asi que esa leccion ya la "traiamos aprendida" de entonces.

Lo del redondeo del IVA a nosotros nos pillo igual, un cliente se quejo de que le habian devuelto una factura por tener el IVA mal calculado por 1 centimo, por temas de redondeo, y juraban que lo correcto es al alza en caso de medio centimo, incluso nos hizo llegar la legislacion... solo que al leerla, era la ley del cambio de moneda.

Como era el govierno vasco el que se quejaba, dimos por bueno su punto de vista, pero antes de cambiar nada lo comprobe con un "deep google", vamos, buscar como un desesperado una regla que confirmase la forma correcta... y nos encontramos con lo que te comento, que todo vale al redondear al mas cercano!

Lo de delphi, si, ese es el redondeo por defecto que trae: sacado de help del round "If X is exactly halfway between two whole numbers, the result is always the even number. This method of rounding is often called "Banker’s Rounding". Vamos, quen 1.5 centimos es 2 y 2.5 es 2 centimos, siempre impar par, que es la regla que te comento pero explicada de otra forma (si es par, a al baja para que te de par, y si es impar, al alza para que te de par de nuevo).

Pero se puede modificar con un $NOSEQUE si lo necesitas, pero ahora no lo encuentro en las ayudas... seguramente has estado aplicando este redondeo par/impar sin saberlo, asi que te puede hacer falta el link.. te lo busco... guardate este link para defensas legales!

http://petete.minhac...nsulta=V2162-09

Empieza con mucha palabreria, mirate el final mejor.

[cerezo]

No veo claro el problema que planteas, pero las instrucciones que das no veo redondeo por ninguna parte, solo operaciones, ademas sin ver de que tipo de campo estamos hablando.
Para temas de importes y unidades creo que lo mas interesante es usar campos de tipo numeric(x,y), si quieres hacer redondeos, lo mas rapido es hacer un cast, por ejemplo:

update a set iva = cast(precioneto * 21 / 100 as numeric(15,2) where articulo = old.ARTICULO;

por otra parte, para calculos sencillos lo mas interesante son campos calculados, asi no "gastas" disco

ALTER TABLE FACTURALinea ADD iva COMPUTED BY (cast(precioneto*21.0/100 as numeric(15,2)));

Y por supuesto, antes que almacenar valores que puedes calcular con la información que ya tienes, mejor un procedimiento almacenado que haga los calculos sobre la marcha.

Un saludo,

[lnufish]

cerezo el campo es decimal 12,2 , tengo una consulta:

en caso de optar por dar a cada producto un iva distinto el calculo que pasare a detallar es correcto?

2  x 44.80 (21%)

3  x 7.90  (21%) 55.90  = 11.74

4  x 3.20 (21%)

1  x 5.60 (10.50%)  5.60 = 0.60


neto 61.50

total iva 12.34

total 73.80

sumar el iva es incorrecto por cada linea segun sergio pero el resultado da correcto! claro que no tiene mucho sentido calcular por cada linea el iva ya que el mismo no fue concebido para calcular sobre cada articulo pero en el caso de presentarse la necesidad de calcular por articulo quiero saber si esta operacion es correcta aunque yo no lo necesite por ahora!

saludos!

[Sergio]

cerezo el campo es decimal 12,2 , tengo una consulta:

en caso de optar por dar a cada producto un iva distinto el calculo que pasare a detallar es correcto?

2  x 44.80 (21%)

3  x 7.90  (21%) 55.90  = 11.74

4  x 3.20 (21%)

1  x 5.60 (10.50%)  5.60 = 0.60


neto 61.50

total iva 12.34

total 73.80

sumar el iva es incorrecto por cada linea segun sergio pero el resultado da correcto! claro que no tiene mucho sentido calcular por cada linea el iva ya que el mismo no fue concebido para calcular sobre cada articulo pero en el caso de presentarse la necesidad de calcular por articulo quiero saber si esta operacion es correcta aunque yo no lo necesite por ahora!

saludos!

Algo pusiste mal: 2 x 44.80 ya es mas que el total de factura que das!

De todas formas, la idea es esa, sumar los totales de las lineas al 21%, y eso te da una base de factura al 21%, con su IVA, y luego sumas los totales de las lineas al 10.5%, que te da una segunda base al 10.5%, con su IVA correspondiente. Las dos bases y los dos IVAS deben ir en factura (en Españas, fuera no se, pero en europa es igual en general, las leyes del iva son iguales porque son de origen europeo).

La idea es que tendras tantas bases como tipos de iva, y a cada una le tocara su total de IVA, luego, la base total de la factura es la suma de las dos bases, y el total del iva la suma de los dos totales de iva, como si fuesen dos facturas, una al 21 y otra al 10.5%, sumadas.