Error en calculo de iva

[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

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.

Recuerda que estamos hablando de la administración, las partidas de gastos se cierran al céntimo y si una partida a la que ha sido aprobado su pago por 1234,56€ su sistema de gestión no te va a admitir una factura por valor diferente a ese.

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

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