|
Error en calculo de iva
Buenas,
En verifactu el total de las bases, cuotas, etc van con dos decimales. Las facturas simplificadas de un supermercado suelen hacer referencia al pvp de cada articulo con el iva incluido por cada linea. Si se desglosa cada linea para determinar la base imponible eso trae problemas que la verdad no se ahora mismo como resolverlo. Antes sacaba el total a pvp, calculaba la base y por diferencia determinaba el importe de iva para que el cliente viera en el ticket la suma del pvp pero ahora si hago eso , logicamente, me da un error por hacer el calculo erroneo de las coutas de iva. Como resolveis este caso? und articulo tipo iva pvp subtotal 1 articulo 1 10% 1€ 1€ 1 articulo 2 10% 1.8€ 1.80€ total a pvp=2.80€ desglose de iva **************************** con la base redondeada a 4 decimales por linea..... base imponible couta iva 10% total 0.9091+1.6364=2.55 0.26 2.81 Que haceis vosotros porque lo que esta claro es que hay que enviar calculando el iva sobre la base a dos decimales y el total entra ademas en el qr.? gracias |
Algo no has explicado bien, esos datos no cuadran.
|
Cita:
Buenas, gracias por contestar Lo que digo es que si hago un ticket de supermercado en el que se muestra la venta de dos articulos a pvp con iva ya incluido del 10% ( el primero a un euro y el segundo a 1.8) la suma a pvp es 2.80 Bien, al realizar el desglose de iva me sale: 2.8/1.10=2.5454 que redondeado a dos decimales da 2.55 si ahora calculo el iva me sale: iva 10%=0.255 que redondeado da 0.26 La suma de base + iva es= 2.81 como ves la suma a pvp es 2.80 y una vez desglosado el iva me sale 2.81 Queria saber como solucionais esto porque claro el cliente va a ver 1 lata de tomate = 1 euro 1 lo que sea =1.8 euro a pagar=1.81 y no 1.80 Al hacer el desglose ya no puedo hacer lo que antes hacia por diferencia de forma cutre (solo con las simplificadas) para que el cliente viera el total y le cuadrara aunque a nivel interno yo si lo cuadrara bien para los resumenes trimestrales y demas. El motivo-->huella del registro y qr de comprobacion. Gracias por tu atencion |
Para evitar el dichoso decimal, calcula el IVA restando la base imponible del total.
|
Cita:
La base imponible del 10% de 2.80 es 2.80/1.10 = 2.5454545454545454, esto quiere decir que el Iva repercutido será Iva= 10 * 2.5454545454545454 /100 = 0.25454545454545452 Como debes presentar tus datos formateados a dos decimales, primero debes redondear el Iva que es lo que le interesa a hacienda Iva(10%) = 0.25 (el tercer decimal es un 4) y ahora debes sacar la base imponible por diferencia con el importe del tipo del 10%, o sea, Base imponible (10%) = 2.80 - 0.25 = 2.55 En resumen, para un valor de 2.80 tenemos una base del 10% de 2.55 y una cuota del 10% de 0.25 ¿ Y por qué no da exactamente 0.25 cuando calculo el 10% de 2.55 ? . El valor que arroja esta pregunta es 0.26 pero tenemos que tener en cuenta que los datos se presentan redondeados a dos decimales y una vez hecho este redondeo, ya no tiene sentido calcular el 10% de 2.55 porque el valor era el 10% de 2.5454545454545454 que sí que es 0.25 |
Muchisimas gracias por tu estupenda explicacion de porque me ocurria ese problema y la forma de subsanarlo asi como a carlosarjonomia y a casimiro por el interes prestado.
|
Con la iglesia hemos topado.
Este problema nos lo vamos a encontrar todos los que tengamos tiendas en el sector del retail. El problema viene a que por ley, los precios de dichos establecimientos tienen que estar etiquetados con el PVP, es decir, con el IVA incluido. Es decir, si un usuario coge un producto cuya etiqueta pone 2,80 P cuando llega la caja ese el precio que espera pagar. Para que no hubiese problema, nuestros programas calculan tanto la Base como el IVA a partir del total hacia atrás. Sin embargo, por ley, una factura se debe calcular de la siguiente forma -> Base Imponible (redondeada a 2 decimales) + importe IVA (redondeado a 2 decimales) = Total Factura. En nuestro caso sería : 2,55 + 0,26 = 2,81. El importe de IVA de 2,55 redondeado a 2 decimales es 0,26, si o si. Lo demás es hacer trampas al solitario. Si cogiéramos como Base Imponible 2,54 el calculo sería: 2,54 + 0,25 = 2,79. Esto es la cuadratura del circulo, matemáticamente no hay ninguna Base Imponible redondeada a 2 decimales a la que sumándole el IVA redondeado igualmente nos de un valor de 2,80. El problema es que en la administración de matemáticas no van muy sobrados y por un lado obligan a que los establecimientos etiqueten los precios con IVA, pero por otro lado cuando envías una factura electrónica (de momento ya es obligado en los organismos oficiales) tiene que estar valorada correctamente conforme a las reglas que ellos establecen, no vale calcular el IVA o la Base por sustracción porque en ese caso te la rechazan porque no está bien valorada. Yo lo estoy sufriendo cada vez que un cliente intenta enviar una factura a un ayuntamiento a través de FACE. Si alguien tiene una varita mágica que resuelva este problema, haría bien en difundirlo, pero creo que nos vamos a divertir en cuanto el Verifactu y la Factura electrónica entren a pleno funcionamiento. |
Buenas, te voy a decir como resuelvo por ahora ese problema segun las recomendaciones que he recibido (ya veremos cuando entre la factura electronica para todo dios)
La base imponible mientras se estan añadiendo articulos al documento la reflejo con 4 decimales o mas decimales que es con lo que mi programa trabaja. Al cerrar el documento es cuando : 1) si se trata de un cliente normal calculo el iva sobre la base con mas de dos decimales y despues formateo a dos decimales la base (sii y verifactu se lo come) 2) si detecto que se trata de una administracion entonces formateo la base a dos decimales y calculo el iva sobre dicha base y que salga lo que salga AL cerrar el documento siempre formateo a dos decimales la base pero la guardo con mas decimales "por si" El mayor problema que tenemos con el rollo este, como tu bien dices, son las explicaciones que hay que dar a los clientes por el no cuadre de la factura. Es mas facil decirle al interventor del ayuntamiento "esto es lo que hay, chaval" que a una clienta que va mirando el centimo en cada compra. Con el metodo que empleo esto mas o menos lo tengo controlado ( al ayuntamiento le importa un carajo un centimo mas que menos mientras que el sistema se lo trague ). Lo malo va a ser cuando la factura electronica se empiece a usar de forma generalizada pero.... eso es otro cantar que ya veremos como solucionar (espero) un saludo |
Cita:
cito "Si [BaseImponibleOimporteNoSujeto] ≤1.000,00:[CuotaRepercutida]=([BaseImponibleOimporteNoSujeto] * TipoImpositivo) +/- 1% de[BaseImponibleOimporteNoSujeto] (y en todo caso se admite una diferencia de +/- 10,00euros). " Esto te permite calcular el iva con todos los decimales obtenidos de la base imponible y luego formatear a dos decimales. La expresión "Lo demás es hacer trampas al solitario" creo que no es acertada ya que si el Valor = base + cuota y conoces la cuota y el valor entonces está claro que puedes obtener la base por diferencia. LO dice la ecuación matematica. En resumen, para mí estaría bien que la suma del valor de base y cuota que no excedieran del 1% de la base imponible y su suma coincidiera con el valor total. El tema de Face seguro que tienen también una validación para estos casos, yo tengo clientes que exportan a administraciones pública a través de Face y no he tenido todavía este problema (puede se que las operaciones siempre sean al 21% y no genere el problema que si hace el 10%) |
Respecto a esto,
" La expresión "Lo demás es hacer trampas al solitario" creo que no es acertada ya que si el Valor = base + cuota y conoces la cuota y el valor entonces está claro que puedes obtener la base por diferencia. LO dice la ecuación matematica" En Verifactu que no se transmite el detalle de la factura podría servir y calcular la base en función de total Factura y la cuota de IVA. Pero en FACE que la Base es igual al precio unitario (con hasta 6 decimales) x la cantidad - descuentos ... Ya no te puedes inventar la base pues se calcula sumando las bases de las líneas de dicho documento. Por otro lado, supongo que no habréis trabajado con muchos ayuntamientos, porque yo como en BladeRunner, he visto ayuntamientos rechazar facturas de miles de euros porque no cuadraban al céntimo con lo que ellos tenían grabado. Es una putada, pero es así (en dichos sitios no suelen estar los más listos de la clase). El ultimo caso, por ejemplo, el cliente tenía un presupuesto de tanto para remitir al ayuntamiento. En lugar de una factura, genera dos. La suma de las dos facturas tenía que cuadrar al céntimo con lo que el ayuntamiento decía sin tener en cuenta que no es lo mismo sumar dos documentos con IVA incluido, que sumar las bases y calcular el IVA. El cliente lleva meses para poder cobrar y la cifra ya te digo que no es baladí. De locos. Al hilo de esto, otro problema que nos vamos a encontrar es la gente que en lugar de contabilizar todos los tickets genera una única factura de agrupación con los tickets de un periodo determinado. En ese caso pasa lo mismo, la suma de los importes de los tickets con IVA incluido no es la misma que sumar las bases y calcular el IVA. Como esos tickets ya se han subido a Verifactu supongo el importe de dicha factura debe cuadrar al céntimo con la suma de los tickets, si no ya tenemos el lío montado. |
Cita:
cito "Sí. Se informará en un solo registro desglosándose la base imponible global correspondiente a cada tipo impositivo y los distintos tipos impositivos." El tema de los dos presupuesto también es lógico que no lo admitan ya que la suma total de ambos importes difiere del valor inicial, aunque sea en 1 céntimo, podrías aplicarle algún ajuste a la segunda factura (descuento x valor) para cuadrarla. Te propongo que hagas la siguiente prueba. Si para tí el Iva que arroja un importe de 2.80€ es de 0.26€ prueba a mandarlo con una base de 2.80-0.26 = 2.54€ verás como te lo acepta y luego prueba a enviar 0.25€ de Iva y 2.80-0.25 = 2.55€ de base, verás como te lo acepta también. Quizás lo que no te acepte sea 2,55€ de base y 0,26€ de Iva para un total de 2.80€ |
Pero como va ser lógico que te rechacen una factura de miles de euros porque te diga el iluminado del ayuntamiento que dicha factura tiene que valer tal importe, cuando si se aplican las reglas oficiales de valoración de una factura: Base Imponibles (2 decimales) + Importe IVAS (2 decimales) me da un valor diferente a lo que me piden.
Lógicamente os estáis centrando en Verifactu que como ya he dicho es el más sencillo pues no tiene el desglose de la Factura. El problema vendrá cuando se tenga que implantar la Factura electrónica en todas las empresas. Hay que tener en cuenta que el problema que mis clientes se encuentran, no siempre proviene de FACE, sino del programa en cuestión, que tiene dicha administración que trabaja con los decimales como le da la gana y al intentar integrar la factura del cliente final le da error. Os digo que me he encontrado casos de todo tipo, como un ayuntamiento que para calcular el total documento sumaba los importes de cada linea con el IVA incluido. La fiesta acaba de empezar. |
Cita:
Respecto de tener muchos o pocos clientes en Face en relación a los problemas de rechazo, miré mi código para ver si me podría pasar el caso que me dices y tengo un link al fichero de validaciones de Face https://www.boe.es/boe/dias/2015/08/...-2015-8844.pdf que te recomiendo te leas, cito a)En las facturas emitidas en euros, se validará que los importes totales de las líneas relativos al coste total sean numéricos y estén redondeados, de acuerdo con el método común de redondeo, a dos decimales, como resultado del producto del número de unidades por el precio unitario, y que los importes brutos de las líneas sean el resultado de restar del coste total los descuentos, y de sumar los cargos, todos ellos numéricos y con dos decimales. Asimismo se validará que el resto de importes a nivel de línea, con excepción del importe unitario, vengan expresados en euros con dos decimales. No se consideran importes los tipos impositivos o los porcentajes a aplicar que, al igual que el importe unitario, podrán tener los decimales que permita el formato Facturae. b) En las facturas emitidas en euros, se validará que el total importe bruto de la factura sea numérico y a dos decimales, por suma de los importes brutos de las líneas. Asimismo se validará que el resto de importes vengan expresados en euros con dos decimales. No se consideran importes los tipos impositivos o los porcentajes a aplicar que podrán tener los decimales que permita el formato Facturae. c) Se validará la existencia del código de moneda de acuerdo con lo establecido en el propio esquema “Facturaeˮ. d) Si el “total importe bruto antes de impuestosˮ es positivo, se validará que el “total impuestos retenidosˮ, si tiene contenido, sea mayor o igual que cero. e) Se validará que el “total importe bruto antes de impuestosˮ sea igual al “total importe brutoˮ menos el “total general descuentosˮ más el “total general cargosˮ. f) Se validará que el “total Facturaˮ sea igual al “total importe bruto antes de impuestosˮ más el “total impuestos repercutidosˮ menos el “total impuestos retenidosˮ.para Si te fijas, la base imponible debe coincidir con las suma de los importes brutos de cada línea ( para cada tipo de impuesto). Si tu calculas la base imponible de la manera que comento en mi post anterior luego aseguras que esa base imponible coincide con la suma de los valores brutos de cada línea. Si no coincidiera, como es el caso del 2.80 debes ajustar la línea del bruto aplicando un descuento por valor o recargo por valor a dicha la línea para que, dejando quieta la base imponible, sean las líneas las que se ajusten internamente para solventar el problema |
Cita:
|
Os cuento mi experiencia con FacturaE, porque con Verifactu ese problema no se va a dar porque no hay que incluir las líneas de las facturas.
Para FacturaE, el importe verdaderamente importante es el Total de la factura. Por tema de varios descuentos que se pueden aplicar a los precios unitarios, es fácil que si vas llevando línea a línea los importes, calculando descuentos y calculando impuestos y/o retenciones, por el tema de redondeo, y más cuando vendes tornillos cuyo precio puede ser con más de dos decimales, al final el total que has ido acumulando para FacturaE te descuadre céntimo arriba o céntimo abajo con el total de la factura que le presentaste al cliente. En esos casos, como sé de cuanto va a ser el descuadre, le añado una línea con ese importe de descuadre para llegar al cuadre total de la factura. No hay funcionario que se me resista. En Verifactu no existe ese problema, no hay que detallar las líneas. Jugar con los totales, no con los parciales. |
Gracias por la información aunque todo lo que indicas ya lo había visto.
Por no alargar el tema, el problema es muy simple, con la limitación de los 2 decimales (como bien indicas el único punto donde se permite más decimales es en los precios unitarios), una factura que lleve un 10% de IVA, NUNCA debería valer 2,80 con IVA incluido. Siguiendo las indicaciones que dices puedes llegar a hacer que FACE lo admita (aceptamos pulpo), pero nada te impide que el sistema informático de turno que tenga dicha administración al intentar integrar dicha factura te la rechace porque le diga que está mal valorada. Es decir, te exigen en una factura un importe que su ERP te va a rechazar. Por cierto, mis ERPs también la rechazarían, porque de toda la vida una Factura se valora : Base + Impuestos = Total (redondeado a 2 decimales). |
Cita:
Espero no incurrir en ningún error. Pero básicamente, asegura que la suma de todos los valores brutos de las líneas para un tipo de Iva coincidan con la base imponible de ese Iva y que la suma de los valores de iva para el tipo de Iva "Tipo" coincida con el Iva del tipo "Tipo". He obviado los recargos de equivalencia para mayor claridad 1.- Construcción de las Bases Imponibles For each LineaVenta in Ventas (Para cada línea de venta) LineasVenta(Base) = LineasVenta(Uds) * LineasVenta(Precio) - (DescuentosLineas) + (RecargosLineas) 'En los Descuentos y recargos se incluyen prorrateados los descuentos y recargos globales Next 2.-Cálculo de Brutos e Impuestos por línea For each Tipo in TiposDeImpuestos (Para cada Tipo de Impuesto) For each Linea in LineasVenta(Tipo) 'Obtiene todas las líneas de venta del Tipo "Tipo" LineaBruto = Linea(Base) * 100 / (100 + Tipo) LineaIva = Redondea2Decimales(LineaBruto * Tipo / 100) LineaBruto = Redondea2Decimales(Linea(Base) - LineaIva) Next Next 3.-Ajustes de las Bases imponibles For each Tipo in TiposDeImpuestos For Each ValorBruto in LineasBruto(Tipo) 'Obtiene todos los valores brutos de las líneas con el Tipo "Tipo" Parcial += ValorBruto Next Ajuste = LineaBruto(Tipo) - Parcial si Ajuste <> 0 quiere decir que las sumas de las bases de cada línea para el tipo "Tipo" difiere de la Base imponible del tipo "Tipo" Le aplico el ajuste a la primera línea del Tipo "Tipo" if Ajuste <> 0 then For Each Linea in LineaBruto(Tipo) Linea(Bruto) += Ajuste exit for End if End if Next 4.- Hacemos lo mismo con los Impuestos For each Tipo in TiposDeImpuestos For Each ValorIva in LineasIva(Tipo) Parcial += ValorIva Next Ajuste = LineaIva(Tipo) - Parcial si Ajuste <> 0 quiere decir que las sumas de los Ivas de cada línea para el tipo "Tipo" difiere de el Valor de Iva para el tipo "Tipo" Le aplico el ajuste a la primera línea del Tipo "Tipo" if Ajuste <> 0 then For Each Linea in LineasIva(Tipo) Linea(Iva) += Ajuste exit for End if End if Next |
Cita:
|
Cita:
|
Cita:
Disculpad que lo pida por aquí |
| La franja horaria es GMT +2. Ahora son las 07:56:28. |
Powered by vBulletin® Version 3.6.8
Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
Traducción al castellano por el equipo de moderadores del Club Delphi