PDA

Ver la Versión Completa : Decimales en facturas electrónicas

newtron
29-05-2018, 17:40:21
Hola a tod@s.


Actualmente estoy generando el fichero XML con formato "facturae" para posteriormente firmarlo y enviarlo por la plataforma face. El problema que me estoy encontrando es que cuando se graban artículos con más de 3 decimales me viene la factura devuelta con el mensaje siguiente:



Rechazada Sist.Contable:AUT. RCF6a. Regla 6a del anexo II Orden HAP/1650/2015: El importe bruto de cada línea (136,58 Eur) debe ser la suma del coste total (136,575 Eur) más la suma de recargos (0 Eur) menos la suma de descuentos (0 Eur).||RCF6a. Reg


En este caso 136.575 es el precio unitario del artículo, que yo lo redondeo a 136.58 en el total de la linea. Después de revisar la documentación entiendo que es como debe de ser pero no encuentro el problema.


¿Alguien ha tenido este problema con más de dos decimales en facturas electrónicas?


Gracias y un saludo
duilioisola
29-05-2018, 18:41:32
Antes que nada verifica que Hacienda diga que es correcta o no: http://sedeaplicaciones2.minetur.gob.es/FacturaE/

Luego de esto ten en cuenta que hay dos versiones actuales: 3.1 y 3.2
Una de ellas tiene más decimales que la otra (además de algunas otras diferencias).
newtron
29-05-2018, 18:47:48
Antes que nada verifica que Hacienda diga que es correcta o no: http://sedeaplicaciones2.minetur.gob.es/FacturaE/

Luego de esto ten en cuenta que hay dos versiones actuales: 3.1 y 3.2
Una de ellas tiene más decimales que la otra (además de algunas otras diferencias).


La factura se valida correctamente en la web y la plataforma face se la "traga" sin problemas. El problema viene un día o dos después que viene rechazada por el motivo que comento.


Gracias y un saludo
manelb
29-05-2018, 19:05:52
Yo creo que el problema está en que, aunque trabajes con varios decimales en el precio, en el momento de guardar importes y sumatorios, se debe redondear siempre a dos decimales.

Por lo que parece, guardas 136,58 en el importe de la línea pero guardas los tres decimales en el coste total.
Entiendo que en el coste total también debes redondear a 2 decimales.

Nosotros también generamos el formato xml y no me he encontrado nunca con este problema.
De todas formas te hablo de memoria, si te interesa que verifique exactamente algún apartado lo dices y lo miro.

Saludos
newtron
29-05-2018, 19:08:53
Hola.


¿Cuando te refieres al "Coste total" te refieres al campo "TotalCost"?


Saludos
manelb
29-05-2018, 19:14:16
Supongo que si..., pero te hablo de memoria.

Si quieres, genero un factura con una sola linea y un artículo cuyo precio tenga 3 o 4 decimales y verificamos el resultado.
newtron
29-05-2018, 19:37:47
Supongo que si..., pero te hablo de memoria.

Si quieres, genero un factura con una sola linea y un artículo cuyo precio tenga 3 o 4 decimales y verificamos el resultado.


Estupendo, te lo agradecería.
manelb
29-05-2018, 20:13:47
Te mando una factura (https://www.dropbox.com/s/k8ykiieaa5tbucu/VE23487.xml?dl=0) donde aparece la venta de una unidad de un articulo cuyo precio es de 10,1234 y tiene un IVA del 10%
mamcx
29-05-2018, 22:09:36
Especulando, creo que el problema es que no puedes alterar los calculos... SOLO SU VISUALIZACION.

Osea, haz calculos EXACTOS Y da los resultados de acuerdo. Solo a la hora de como se VEN redondea.

Eso es lo que siempre he hecho. (Y SIEMPRE uso tipos decimales para todo lo que es dinero, y solo al final convierto a lo que sea)
newtron
30-05-2018, 09:24:29
Gracias manelb, siguiendo lo que habíamos comentado ayer envié un fichero con el campo "TotalCost" redondeado a dos decimales (tal y como me envías en tu fichero de ejemplo) y me acaban de enviar un correo rechazando el fichero ahora por otro motivo: "Rechazada Sist.Contable:AUT. 000001- El tercero no existe en SICALWIN : U19757097"


¿Te suena eso de SICALWIN? He mirado por internet y parece que es el programa que usan en el ayuntamiento para manejar las facturas electrónicas, ¿es posible que desde el ayuntamiento tengan que dar a la empresa de alta o algo así?





Osea, haz calculos EXACTOS Y da los resultados de acuerdo. Solo a la hora de como se VEN redondea.



Gracias mamcx, estamos en ello.


Saludos
engranaje
30-05-2018, 11:58:00
Ese último error apunta a que desde el ayuntamiento destinatario de la factura la han rechazado por no encontrar un tercero con el identificador de la factura en su bd. Lo normal sería que añadieran al nuevo tercero o modificaran el identificador si es que ya tienen al tercero pero con un identificador distinto. Todo esto, sando por hecho que el identificador del tercero que envías en la factura es el correcto.
newtron
30-05-2018, 12:04:32
Ese último error apunta a que desde el ayuntamiento destinatario de la factura la han rechazado por no encontrar un tercero con el identificador de la factura en su bd. Lo normal sería que añadieran al nuevo tercero o modificaran el identificador si es que ya tienen al tercero pero con un identificador distinto. Todo esto, sando por hecho que el identificador del tercero que envías en la factura es el correcto.


Esta empresa le vende por primera vez al ayuntamiento. Cuando se habla del "tercero" imagino que es el emisor de la factura. Mi pregunta es ¿tiene el ayuntamiento que darlo de alta en su sistema?


Gracias y un saludo
manelb
30-05-2018, 12:47:58
Nunca he tenido este error, aunque tiene toda la pinta de lo que dice engranaje.
No estoy seguro de si el organismo en cuestión que recibe la factura debe dar de alta al proveedor en algún sistema.
En todo caso el ayuntamiento nos podría sacar de dudas.

Por otra parte cabría verificar que el problema no venga por un error en los códigos DIR3, aunque tiene más pinta de lo anterior.
engranaje
30-05-2018, 13:13:32
Normalmente para poder importar las facturas en su sistema de contabilidad necesitan tener registrado el tercero. Otra cosa es que desde su programa permitan darlo de alta o rechazar la factura y el usuario haya decidido rechazar en lugar de dar de alta.


En esta url parece que explican algo acerca del proceso.

http://www.dip-badajoz.es/agenda/tablon/jornada_efactura/documentos/FACe_manual_de_Infomuni.pdf
duilioisola
31-05-2018, 16:42:37
También puede ser que estén pidiendo que asignes un Centro administrativo.
En nuestra aplicación los tenemos definidos por dirección o para todas las direcciones.

Direccion Descripcion Rol Centro_Adm.
-------------------------------------
0 Todas las direcciones 01 W123456
1 Direccion BCN 02 W456789
2 Direccion MAD 02 M987654


// RoleTypeCode
// Tipo rol. Indica la función de un Punto Operacional (P.O.) definido como Centro/Departamento.
// Estas funciones son:
// "Receptor" - Centro del NIF receptor destinatario de la factura.
// "Pagador" - Centro del NIF receptor responsable de pagar la factura.
// "Comprador" - Centro del NIF receptor que emitió el pedido.
// "Cobrador" - Centro del NIF emisor responsable de gestionar el cobro.
// "Fiscal" - Centro del NIF receptor de las facturas, cuando un P.O. buzón es compartido por varias empresas clientes con diferentes NIF.s y es necesario diferenciar el receptor del mensaje (buzón común) del lugar donde debe depositarse (empresa destinataria).
// 01 Fiscal - Oficina Contable, es España
// 02 Receptor - Organo Gestor, es España
// 03 Pagador - Unidad Tramitador, es España
// 04 Comprador - Organo Ponente, es España
// 05 Cobrador
// 06 Vendedor
// 07 Receptor del pago
// 08 Receptor del cobro
// 09 Emisor


<AdministrativeCentres>
<AdministrativeCentre>
<CentreCode>U19757097</CentreCode>
<RoleTypeCode>01</RoleTypeCode>
</AdministrativeCentre>
</AdministrativeCentres>
newtron
31-05-2018, 17:04:19
Pues no sé la verdad. Estoy esperando a poder hablar con alguien del ayuntamiento de Granada pero ahora resulta que son las fiestas del Corpus y estarán media semana sin trabajar.


Gracias y un saludo