![]() |
![]() |
![]() |
![]() |
![]() |
FTP | ![]() |
![]() |
CCD | ![]() |
![]() |
Buscar | ![]() |
![]() |
Trucos | ![]() |
![]() |
Trabajo | ![]() |
![]() |
Foros | ![]() |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
![]() |
|
Herramientas | Buscar en Tema | Desplegado |
#1
|
|||
|
|||
(Intento de) resumen de códigos de error y qué hacer en cada caso
Buenas.
Me gustaría hacer un breve resumen que nos ayude a todos a entender mejor qué hacer con cada caso, porque veo que pasan las semanas y no se llega a un acuerdo. Al final acabaremos interpretando cada uno una cosa distinta. Intentaré resumir lo que yo he entendido hasta ahora. Molaría que todos pudiéramos aportar un granito de arena cada uno. Al crear/emitir una factura, se debe crear un RF (XML) y enviarlo a la AEAT Al enviarlo pueden ocurrir varias cosas: - Falla el envío (no hay conexión, problema con el certificado digital, etc.) - se debe esperar a tener conexión, o corregir el problema del certificado, etc. y reintentar el envío hasta que salga - Envío correcto o con avisos: el resultado de cada RF enviado puede ser: - Correcto: Hacienda acepta el XML. No hay que hacer nada (al menos no obligatoriamente) - Incorrecto: Hacienda rechaza el XML. - ParcialmenteCorrecto: Hacienda acepta el XML pero hay algo que se debe revisar Dependiendo del error que nos haya dado un registro Incorrecto o ParcialmenteCorrecto, tenemos varias opciones: - Rectificativa - Subsanación - Anulación - No hacer nada (por ejemplo, algunos errores como el 2004 no requieren hacer nada) Y aquí empieza lo bueno. El dichoso listado oficial de errores. Hay tres bloques (aunque bajo mi punto de vista, debería haber más, pero bueno): Errores que provocan el RECHAZO del Envío completo Se debería marcar la Factura como "A Revisar", o algo similar, para que el usuario corrija el error y, una vez corregido, volver a marcarla como "Pendiente de enviar" para que se intente reenviar de nuevo cuando toque. Estos errores no deberían producirse "casi nunca" si el software está bien diseñado y si se revisan estos requisitos antes de emitir/guardar la factura: comprobar el certificado, comprobar nifs emisor y receptor, etc. Otros errores son ajenos a nuestro software y no se podrán evitar (algunos son "errores técnicos" propios del servidor) Asumo que algunos de estos errores ni siquiera nos aparecerán nunca. Cita:
Hacienda acepta la factura, pero hay algo mal que no consideran del todo importante como para rechazarla por completo. Aquí no hay opción de reenviarla corregida porque Hacienda ya la aceptó (ya le consta), así que te devolverá "registro duplicado" si la reenvías. (La mayoría de estos errores no deberían producirse si el software está bien diseñado) Se debería marcar la factura como "A Revisar" y, una vez corregido el error, reenviarla como subsanación. NOTA: el error 2004 no requiere subsanación ni nada. No sé si habrá otros códigos que tampoco requieran hacer nada. Cita:
Y ahora el bloque chungo, el que cuesta tanto interpretar... Errores que provocan el Rechazo de la factura (o del envío completo si el error está en la cabecera) Hacienda se limita a decir que hay que distinguir si el error afecta al RF o al ROF. Y se quedan tan contentos, en plan "yo ya copié y pegué la lista, ahora léete tu la normativa entera". Como ellos dicen, aquí hay que diferenciar si el error afecta al RF (XML del registro de facturación), al ROF (reglamento de facturación), a la Cabecera... ¿Por qué no separaron los bloques en "errores cabecera y errores RF"? Porque ellos son así de guays... NOTA: Algunos errores son rarísimos y asumo que no los veremos nunca (1128, 1129...) En cualquier caso, vamos a lo importante... los errores de este bloque provocan que la factura (o el envío) haya sido rechazado, así que hay que actuar rectificando, subsanando o anulando (o no haciendo nada), marcando la factura para avisar al usuario y que haga lo que tenga que hacer. ¿Y qué es lo que debe hacer el usuario? ¿Subsanar, Rectificar o Anular? Llorar. Bueno, esa es la pregunta del millón. Algunos exigen siempre hacer rectificativa, otros dicen que lo correcto es hacer lo que toque según cada caso: "subsanación con rechazo previo", anulación, etc. Se podría resumir en esto: - Si el error lo ha cometido el propio Usuario al elaborar la factura (cliente incorrecto, cuotas, totales, forma de pago, etc.), se debe hacer una Rectificativa, porque afecta a los datos "importantes" y "visibles" de la factura - Si el error no afecta al RF, sino a los otros datos que no tienen nada que ver con el contenido de la factura (huella, datos que rellena el propio software y no el usuario, datos como el tipo de factura, motivo de exención, etc.) entonces Subsanación ![]() Otra información relevante: ¿Se puede rectificar una factura que ha sido Aceptada? Si. De hecho, que Hacienda acepte una factura no significa que el usuario no haya cometido un error (a lo mejor se equivocó de cliente, u olvidó añadir un artículo, o se equivocó con el tipo de IVA...). En este caso la factura está aceptada, enviada, etc. pero es el usuario quien deberá actuar, haciendo una nueva factura rectificativa. ¿Se puede subsanar una factura si ha sido aceptada? Si. Si la corrección que hay que hacer no exige hacer una rectificativa, entonces se hace una subsanación ¿Se puede hacer una rectificativa aunque se recomiende hacer una subsanación? Creo que nadie te lo prohíbe, pero yo personalmente no lo he probado. De hecho, como si quieres hacer rectificativas para cualquier cosa. El usuario puede hacer lo que quiera. ¿Se pueden hacer facturas "en negativo"? Para la elaboración de rectificativas en 2 pasos, no solo se puede sino que Hacienda te dice que hay que hacerlo así: primero una factura normal/ordinaria en negativo y luego otra rectificativa que rectifica a la original que estaba mal. Yo considero que para nosotros como programadores, lo complicado es poner en bandeja al usuario final del software loq ue tiene que hacer en cada caso. Si el usuario conociera la legislación, él decidiría cómo actuar y qué hacer en cada caso, pero no es así, y somos nosotros los que debemos "encaminarle" para que haga lo que creamos que deba hacer. El problema es que, para conseguirlo, debemos saber qué error exacto nos devuelve Hacienda, saber en qué bloque está, saber si afecta a una cosa o a otra (RF o ROF) y decirle "mira, esta factura concreta tienes que hacer esto, y para esta otra tienes que hacer esto otro". Lo dicho. Siento el tostón y espero que entre todos podamos colaborar añadiendo o quitando información. Hoy me lo tomé en plan relax y aproveché para escribir el post porque estoy bastante quemado ya con el temita VeriFactu... |
#2
|
|||
|
|||
Le he pedido a ChatGPT que cree un array (en PHP) con los códigos de error, descripción de cada uno, tipo de error y acción recomendada para el usuario, según el error afecte a la estructura, etc.
Aún tengo que revisarlo porque ChatGPT se lía un poco cuando tiene que tratar con archivos grandes, cadenas de texto, etc. pero creo que en algo ayudará. No están ordenados por ningún criterio. Cuando me ponga a verlo con calma ya veo si está bien hecho o si ChatGPT está peor que yo ya... Código PHP:
|
#3
|
|||
|
|||
Continuación, que el mensaje era muy largo:
Código PHP:
|
#4
|
|||
|
|||
Cita:
esto no es correcto, si envías una subsanación cubriendo los campos "Subsanacion" y "RechazoPrevio" como indican sí que entra y te devuelve correcto. Nosotros la forma de pago permitimos modificarla sin reenviar nada a Verifactu. Aunque va o puede ir en la factura impresa, no afecta a nada de lo que se envía a la AEAT. Si por ejemplo la factura tiene un vencimiento y decido que tienen que ser 2 permitimos modificar ese dato para que los vencimientos se vuelvan a generar correctamente. No tengo la seguridad que sea correcto pero lo permitimos Última edición por Jarogo08 fecha: Hace 1 Semana a las 15:42:56. |
#5
|
|||
|
|||
Nosotros es el unico campo de momento que dejamos modificar de la factura, la forma de pago, como bien dices no va en el RF.
|
#6
|
|||
|
|||
Cita:
Lo de la forma de pago es cierto, no debería hacer falta emitir rectificativa, salvo que se pongan tiquismiquis. |
#7
|
|||
|
|||
Cosas que cada vez veo más claras después de tantos días dándole vueltas...
- Los errores del 4102 al 4139 (primer bloque) difícilmente se darán en producción si tenemos el software bien preparado y antes de hacer el envío hacemos algunas comprobaciones. La mayoría de hecho son errores técnicos del propio servidor de Hacienda, cosas para "no-verifactu" y alguno más. Si acaso, los errores relacionados con los NIFs (emisor y destinatario), certificado, etc. que fácilmente podemos evitar haciendo la consulta y comprobaciones adecuadas. - Del 3000 al 3003 no requieren hacer nada (registro duplicado, ya dado de baja, no existe el registro...). No hay nada que corregir, o al menos no nada que debamos hacer nosotros. - Del 2000 al 2008 son "subsanables". Al ser campos internos relacionados con verifactu (huella, huso horario...) y no con el reglamento de facturación, no hay que hacer rectificativa. No obstante, hay dos errores en ese bloque que me mosquean: El 2006 y el 1216 son exactamente el mismo, pero uno de ellos provoca rechazo y el otro la acepta: - 1216 = El campo CuotaTotal tiene un valor incorrecto para el valor de los campos CuotaRepercutida y CuotaRecargoEquivalencia suministrados. - 2006 = El campo CuotaTotal tiene un valor incorrecto para el valor de los campos CuotaRepercutida y CuotaRecargoEquivalencia suministrados. Lo mismo ocurre con el 2005 y el 1210. Digo yo que si hay un error en alguna cuota, importe, etc. se tendría que emitir una rectificativa, no una subsanación. Este error no debería ocurrir porque el software impide que ocurra algo así, pero me extraña que Hacienda acepte el registro si los totales no cuadran. Me da que se han liado ellos mismos poniendo el error en dos bloques. No sé si habrá algún otro error "duplicado" como este caso. |
#8
|
|||
|
|||
Yo creo que esos errores justo cambian si se da el descuadre pero se pasa de x cantidad, por ejemplo te pasas solo un céntimo pues 2005, si te pasas por mucho pues el 1210.
__________________
La religión es personal e intransferible. |
#9
|
||||
|
||||
Cita:
__________________
Uno se alegra de ser útil. (Isaac Asimov) |
![]() |
|
|
![]() |
||||
Tema | Autor | Foro | Respuestas | Último mensaje |
Error 4102 - Error en el primer intento | _Io | Errores (relacionados con al AEAT) | 9 | 04-12-2024 18:21:19 |
Error cuando intento agregar una imagen en un TImageList | darkamerico | OOP | 1 | 25-04-2016 05:27:40 |
No se porque tengo un error cuando intento insertar en la tabla | Anyu | Conexión con bases de datos | 11 | 15-07-2008 23:45:40 |
hacer funcionar un lector de codigos de barras | Ubuntero | Providers | 3 | 15-12-2006 05:40:16 |
Intento hacer consulta SQL parametrica | jefraub | SQL | 6 | 23-02-2005 12:21:02 |
![]() |
|