Error en calculo de iva

[sglorka]

Empezado por jlmoli_67

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

Creo que cometes un error al calcular el Iva. No puedes redondear más que una sola vez al calcular el Iva y las bases imponibles.
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

[jlmoli_67]

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.

[siyei]

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.

[jlmoli_67]

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

[siyei]

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.

[sglorka]

Empezado por siyei

Supongo que no habrás 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.

Bueno el caso de los resumen de tiques contabilizados no es lo mismo la suma individual de los tiques que una única suma con todos los tiques, eso está claro, pero no te vas a encontrar con ese problema ya que Verifactu no admite la clave F4. En todo caso, si la admitiera alguna vez, el cálculo que debes realizar para este asiento resumen no sería el de los tiques individuales, tendría que recalcular todas las bases imponibles y cuotas repercutidas y te daría distinto de las sumas individuales pero eso no es problema, ya lo explican ellos, hacen referencia a base imponibles GLOBALES en "https://sede.agenciatributaria.gob.es/Sede/impuestos-tasas/iva/iva-libros-registro-iva-traves-aeat/preguntas-frecuentes/2-registro-cuestiones-comunes.html?faqId=34326c3d02bc9510VgnVCM100000dc381e0aRCRD"

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€

[siyei]

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.

[sglorka]

Empezado por siyei

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.

Entiendo lo que quieres decir, pero lo que no sería de recibo es que teniendo un importe de 2.80€, la suma de tu base y cuota diera 2.81€. Te en cuenta que las reglas de validación de Verifactu ya recogen este extremo, puedes verlo en el documento de errores y validaciones. Te permiten desviarte en el cálculo de la cuota tributaria hasta en un +/- 1% del valor de la base imponible

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%)