search

OCA / l10n-spain

Odoo Spain Localization
https://www.aeodoo.org/estado-localizacion
GNU Affero General Public License v3.0
290 stars 521 forks source link

error facturae decimals #1013

Closed afilomeno closed 5 years ago

afilomeno commented 5 years ago

Hello,

I have a problem when I upload the file create for facturae. The message error is:

HF09-Error Orden Ministerial;RCF06001: En las facturas emitidas en euros, alguno de los importes de las líneas tiene más de dos decimales o no es numérico. Se incumple la regla 6a del anexo II de la Orden HAP/1650/2015;RCF06005: En las facturas emitidas en euros, el total importe bruto de la factura debe ser la suma de los importes brutos de las líneas. Se incumple la regla 6b del anexo II de la Orden HAP/1650/2015

We need to work with 4 decimals, can anybody help me?, thanks

pedrobaeza commented 5 years ago

Hola, aquí se puede hablar en español. A ver, si tienes configurados 4 decimales en la contabilidad, ése es el problema, y ahí no se puede hacer nada, ya que eso es ilegal por mucho que digas que lo necesitas.

Otra cosa puede ser que utilices 4 decimales en el precio unitario y luego la contabilidad esté a 2 decimales. Ahí entonces no debería darte problemas, pero si es el caso, entonces concreta más.

afilomeno commented 5 years ago

Gracias por la rapidez en tu respuesta, el problema que tengo es que trabajamos con precios de céntimos en las ventas y necesitamos que el cálculo sea con 4 decimales, en las facturas el precio del producto está en 4 decimales y el total en 2. Si lo cambio en /técnico/estructura de BD/precisión decimal me cambia el precio del producto a dos decimales (por el tipo de producto que vendemos no nos interesa). Te copio el XML que genera el facturae. Gracias de atemano

```xml 3.2 I EM FV/2019/1061ESB61824520 1 284.73 284.73 284.73 284.73 284.73 284.73 EUR J R ESB12345678 My Company S.L. My Company S.L.
Calle
01234 Poblacion Barcelona ESP 9312345678 http://www.wee.com comercial@mail.com My Company S.L. J R ESP1234567D L01081563 01
Calle
01234 Poblacion Barcelona ESP 931234567 http://www.web.com gi@mail.com Empresa cliente cliente L01081563 02
Calle
01234 Poblacion Barcelona ESP 931234567 http://www.web.com gi@web.com empresa cliente empresa cliente L01081563 03
Calle
01234 Poblacion Barcelona ESP 931234567 http://www.web.com gi@mail.com Empresa Cliente Empresa Cliente Empresa Cliente Empresa Cliente
Calle
01234 Poblacion Barcelona ESP 931234567 http://www.web.com gi@mail.com Empresa Cliente FV/2019/1061 FC OO 2019-02-05 EUR EUR ca 01 21.00 235.31 235.31 49.42 49.42 235.31 235.31 49.42 0.00 284.73 284.73 284.73 [BL/IN/0115] TABLERO PLANNING BL/IN/0115 BASIC CORCHO VISTO 100 X 200 CM 3.0 63.438000 190.314000 190.310000 01 21.00 190.31 190.31 39.97 39.97 BL/IN/0115 MUNTATGE A PARET 1.0 45.000000 45.000000 45.000000 01 21.00 45.00 45.00 9.45 9.45 Aquest albarà substitueix al albarà WH/OUT/390 (17.01.19) 1.0 0.000000 0.000000 0.000000 01 21.00 0.00 0.00 0.00 0.00 VARPA 2019-03-07 284.73 04 ESXXXXXXXXXXXXXXXXXXX BBVAESMMXXX BBVAESMMXXX ```
pedrobaeza commented 5 years ago

El problema que tienes es que las cantidades no salen igual precisamente por esos decimales:

seleccion_014

Lo único que se me ocurre es que pongas redondeo global en los impuestos a ver si así lo consigues (y tendrás que rehacer la factura para que te recalcule). Si no, no te quedará otra que bajar el nº de decimales o adaptar el código para lidiar con este problema.

Cierro la incidencia al no estar directamente relacionado con el módulo, si no con la casuística del usuario.

afilomeno commented 5 years ago

Hola Jesús, he redondeado manualmente y cancelado y vuelto a validar la factura, pero me sigue apareciendo igual.

Podrías vosotros hacer la adaptación? Gracias

pedrobaeza commented 5 years ago

¿Quién es Jesús?

afilomeno commented 5 years ago

Perdona, 😊 estaba pensando en un cliente y enviado el mail

MiguelMachadoM commented 5 years ago

@afilomeno Las Facturas Electrónicas deben de ir con 4 Decimales, pero los últimos 2 siempre 0. Es decir, no puedes facturar 1,4321, si no 1,4300. Eso en la linea de producto. De ahí el error.

Lo que tengo yo hecho es una tarifa asignadas a todos los que le hago factura electrónica redondeada a 2 decimales.

Y por lo que veo o cambia la unidad de medida o tienes que redondear, no te queda otra me parece.

afilomeno commented 5 years ago

Buenas tardes y muchas gracias, pero hay alguna manera de hacer que cuando genere la factura electrónica sea tal y como tu me comentas? Teniendo en cuenta que en las ventas necesitamos utilizar los 4 decimales.

Gracias

etobella commented 5 years ago

La solución que veo es crear un campo con el importe de la línea sin descuento con los decimales esperados y sustituir la línea con el campo que comentamos. https://github.com/OCA/l10n-spain/blob/11.0/l10n_es_facturae/views/report_facturae.xml#L274

MiguelMachadoM commented 5 years ago

@afilomeno Creo que te lo comente anteriormente, para los entes o organismos que usas factura electrónica, crea una tarifa derivada de la tarifa que utilizas y la redondeas a 2 decimales, aun que sigues viendo tus 4 decimales los que tengan esa tarifa redondeara a 2.

image

afilomeno commented 5 years ago

Buenos días, la verdad, es que para nuestra forma de trabajar, esta solución me supone mucho trabajo, ya que tengo duplicar nuevamente todas las tarifas de venta con los correspondientes artículos y familias de artículos que tengo introducidas. Gracias igualmente por la solución.

MiguelMachadoM commented 5 years ago

Buenos días, la verdad, es que para nuestra forma de trabajar, esta solución me supone mucho trabajo, ya que tengo duplicar nuevamente todas las tarifas de venta con los correspondientes artículos y familias de artículos que tengo introducidas. Gracias igualmente por la solución. @afilomeno Buenos creo que esto no es tema que deba ir aquí. No tienes que duplicar nada. Si lo tienes ya echo en la tarifa X, lo unico que tienes que es crear una nueva tarifa X1 y dentro de esa tarifa creas un único elemento, en ese elemento como en la imagen anterior seleccionas Fórmula, pones el redondeo y seleccionas la tarifa X. No tienes que volver a agregar todas categorias y margenes, simplemente este coje el precio del la tarifa X y lo redondea.

Y en caso de no querer hacerlo así siempre puedes duplicar la tarifa, exportando e importando. O dentro de la misma duplicando. image

afilomeno commented 5 years ago

Gracias por tu respuesta, hemos creado esta nueva tarifa tal y como nos indicas, pero sucede lo mismo,

afilomeno commented 5 years ago

Buenas tardes, hemos probado redondeando globalmente, redondeando por línea, creando una tarifa para redondear sobre otra tarifa, pero cada vez que generamos el fichero nos sigue pasando lo mismo y no nos lo aceptan. Alguien nos podria adaptar el modulo, aunque tenga algún coste? Gracias

MiguelMachadoM commented 5 years ago

@afilomeno No creo que necesites ninguna adaptación, algo estas haciendo mal. Yo trabajo con 4 decimales y para los que envío factura electrónica por FACE lo redondeo a 2 con un tarifa adicional como te explique anteriormente.

image Si todas las líneas de producto están redondeadas a 2 decimales y el redondeo es global no veo por que te da problemas.

Yo no se si existen otras web para el envío de las facturas, no se is para organismos comunitarios es diferente, yo siempre lo he hecho por face https://face.gob.es/es en todo caso aquí tienes otro enlace con utilidades para comprobar: http://www.facturae.gob.es/formato/Paginas/utilidades-online.aspx

afilomeno commented 5 years ago

OK Miguel, voy a volver a probarlo

gracias

afilomeno commented 5 years ago

Miguel, ya he visto el que, el problema está en que si activamos el redondeo de tarifas, estamos incrementando el valor de la factura, y esto nos es imposible cambiarlo porqué se trabaja con grandes cantidades y provoca diferencias importantes de precio.

rbetancor commented 5 years ago

Es un problema común con los redondeos.

Si haces redondeo linea a línea, cada línea solo te puede variar un 0.01 arriba o abajo, lo que pasa es que ese error es acumulativo por la cantidad de lineas ... por lo que si tienes 2000 lineas en la factura, puedes acabar con un -20 o +20 del total y evidentemente, la gente no lo acepta, pero es que LEGALMENTE, se ha de redondear linea a linea, no el total final de la factura.

Saludos

pedrobaeza commented 5 years ago

@rbetancor ¿tienes algún enlace sobre la normativa donde indique eso del redondeo línea a línea?, porque es más bien al revés y la mayoría de software aplican redondeo global.

rbetancor commented 5 years ago

@pedrobaeza , la cosa trae tela desde hace mucho tiempo. Si nos fijamos aquí https://www.agenciatributaria.es/AEAT.internet/Inicio/_Segmentos_/Empresas_y_profesionales/Empresas/IVA/Obligaciones_de_facturacion/Obligaciones_de_facturacion.shtml

En la sección de "Contenido de las facturas", el punto f de "Factura completa" no aclara la cantidad de decimales que se ha especificar. Pero si buscamos información sobre la parte de e-Factura, vemos que a pesar de que el formato admite más de 2 decimales para el precio unitario, todos los sistemas de recepción de facturas electronicas de la administración española (no se nos ha dado el caso de remitir facturas electrónicas a empresas/administraciones fuera de España), rechazan de pleno que el precio unitario no esté redondeado a 2 cifras.

En su momento planteamos la duda en la delegación local de la AEAT y la respuesta fue que ellos no entran a valorar las líneas de las facturas (en caso de una inspección), sino las bases imponibles y la liquidación de impuestos.

Si sumas esa respuesta de la AEAT a que las administraciones NO ACEPTAN facturas con precios unitarios que no estén redondeados a 2 decimales, solo hay 2 opciones: 1- Redondear linea a linea. Es el método que más error acumula 2- Sumar los subtotales a la cantidad de dígitos que quieras y redondear la base imponible.

El método 2 no se puede usar para mandar facturas electrónicas a la administración, así que solo queda el 1.

afilomeno commented 5 years ago

Buenos días a todos!! Finalmente para poder enviar las efactura, hemos modificado el fichero y luego firmado, pero ahora hay un ayuntamiento que me pide la referencia del pedido que no se ve que no aparece en el fichero de la efactura, he mirado la normativa y no he visto en ningún sitio que sea obligatoria esta información....alguna idea? Gracias

pedrobaeza commented 5 years ago

@rbetancor gracias por la información extendida, pero en lo que me pones en ningún sitio se puede deducir eso que dices de que el método 2 no sirva. Es más, puesto que el SII controla totales de factura, no lo de línea a línea, el redondeo por línea acumularía más error de precisión que el otro método.

rbetancor commented 5 years ago

@pedrobaeza Lo de que el método 2 no sirve, te lo digo por pura empírica, al enviar facturas en formato electrónico a través de FACE, en las que en los importes de las líneas vayan a 4 dígitos, pero los dos últimos no sea 00 (osea, que no estén redondeados a 2 cifras), las facturas son rechazadas por el RCF Esta circunstancia, invalida cualquier intento de NO hacer redondeo linea a línea y te ves forzado a usar redondeo linea a linea, que como comentas, aumenta el error de precisión.

Ejemplo extremo (va de cabeza los campos y simplificando, no lo estoy mirando): Linea|Descripción|Precio unitario|Unidades|TotalLinea 1|Producto1|0.0001|1|0.0001 2|Producto2|0.0001|10|0.0010 .... Enviar esas precios unitarios y totales de linea a FACE así, es rechazado de plano por la RCF, habría que mandarlos así: 1|Producto1|0.0100|1|0.0100 2|Producto2|0.0100|10|0.1000

Y ya ves la burrada de error que se va acumulando en 2 líneas, pues imagínate con 100 lineas

Y en ambos casos, el .xsig sería perfectamente válido. Desconozco si es un problema que dependa del software que use la RCF o es algo que se les pasó por alto en la especificación de facturae

El caso concreto, se le dio a una empresa de suministros de material de ferretería y construcción, trabajando con un ayuntamiento. Ellos trabajan internamente con 6 decimales para productos, cuando el ayuntamiento les admitía la presentación de facturas en papel, ellos sumaban todos los subtotales y redondeaban el resultado final (que es lo que menos error genera), pero al obligarlos ahora el ayuntamiento a presentar todas las facturas por FACE, tienen un problema gordo, porque no pueden seguir haciéndolo como antes y redondear linea a linea, produce un error acumulado brutal.

Y una cosa es el SII, que no comunicas las líneas, sino los importes de las bases y los impuestos y otra diferente facturae, que SI tienes que comunicar las líneas de la factura.

rbetancor commented 5 years ago

Buenos días a todos!! Finalmente para poder enviar las efactura, hemos modificado el fichero y luego firmado, pero ahora hay un ayuntamiento que me pide la referencia del pedido que no se ve que no aparece en el fichero de la efactura, he mirado la normativa y no he visto en ningún sitio que sea obligatoria esta información....alguna idea? Gracias

No es obligatorio, es un campo opcional de la cabecera de factura. Pero el ayuntamiento te lo puede pedir por temas de su trazabilidad interna.

pedrobaeza commented 5 years ago

@rbetancor muchas gracias por la información extra con tanto detalle. Como bien nos has demostrado, cuando se combina FacturaE con precios de 4 decimales, lo mejor es poner redondeo por línea para evitar errores en los totales. Esto demuestra la mala especificación del formato FacturaE. Ojalá y se sustituya por un formato más robusto como es UBL o sus variantes, como han hecho otros países como Francia.

Afortunadamente, no tengo ningún cliente con la combinación de ambas casuísticas, y desde luego siempre desaconsejo a toda costa utilizar más de la precisión contable en cualquier operación, aunque ésta, como otras cosas como el triple descuento, estén muy extendidas en nuestro país...

Gracias una vez más por esta didáctica charla.