[espinete]

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.

4102 = El XML no cumple el esquema. Falta informar campo obligatorio.
4103 = Se ha producido un error inesperado al parsear el XML.
4104 = Error en la cabecera: el valor del campo NIF del bloque ObligadoEmision no está identificado.
4105 = Error en la cabecera: el valor del campo NIF del bloque Representante no está identificado.
4106 = El formato de fecha es incorrecto.
4107 = El NIF no está identificado en el censo de la AEAT.
4108 = Error técnico al obtener el certificado.
4109 = El formato del NIF es incorrecto.
4110 = Error técnico al comprobar los apoderamientos.
4111 = Error técnico al crear el trámite.
4112 = El titular del certificado debe ser Obligado Emisión, Colaborador Social, Apoderado o Sucesor.
4113 = El XML no cumple con el esquema: se ha superado el límite permitido de registros para el bloque.
4114 = El XML no cumple con el esquema: se ha superado el límite máximo permitido de facturas a registrar.
4115 = El valor del campo NIF del bloque ObligadoEmision es incorrecto.
4116 = Error en la cabecera: el campo NIF del bloque ObligadoEmision tiene un formato incorrecto.
4117 = Error en la cabecera: el campo NIF del bloque Representante tiene un formato incorrecto.
4118 = Error técnico: la dirección no se corresponde con el fichero de entrada.
4119 = Error al informar caracteres cuya codificación no es UTF-8.
4120 = Error en la cabecera: el valor del campo FechaFinVeriFactu es incorrecto, debe ser 31-12-20XX, donde XX corresponde con el año actual o el anterior.
4121 = Error en la cabecera: el valor del campo Incidencia es incorrecto.
4122 = Error en la cabecera: el valor del campo RefRequerimiento es incorrecto.
4123 = Error en la cabecera: el valor del campo NIF del bloque Representante no está identificado en el censo de la AEAT.
4124 = Error en la cabecera: el valor del campo Nombre del bloque Representante no está identificado en el censo de la AEAT.
4125 = Error en la cabecera: Si el envío es por requerimiento el campo RefRequerimiento es obligatorio.
4126 = Error en la cabecera: el campo RefRequerimiento solo debe informarse en sistemas en remisiones al endpoint del servicio a usar para la contestación a requerimientos de registros de facturación.
4127 = Error en la cabecera: la remisión voluntaria solo debe informarse en sistemas VERIFACTU.
4128 = Error técnico en la recuperación del valor del Gestor de Tablas.
4129 = Error en la cabecera: el campo FinRequerimiento es obligatorio.
4130 = Error en la cabecera: el campo FinRequerimiento solo debe informarse en sistemas No VERIFACTU.
4131 = Error en la cabecera: el valor del campo FinRequerimiento es incorrecto.
4132 = El titular del certificado debe ser el destinatario que realiza la consulta, un Apoderado o Sucesor
4133 = Error en la cabecera: el valor del campo RefRequerimiento no es alfanumérico.
3500 = Error técnico de base de datos: error en la integridad de la información.
3501 = Error técnico de base de datos.
3502 = La factura consultada para el suministro de pagos/cobros/inmuebles no existe.
3503 = La factura especificada no pertenece al titular registrado en el sistema.
4134 = Servicio no activo.
4135 = Esta URL no puede ser utilizada mediante GET.
4136 = No se ha enviado el nodo RegistroAlta o el anterior al nodo RegistroAlta no es correcto
4137 = No se ha enviado el nodo RegistroAnulacion o el anterior al nodo RegistroAnulacion no es correcto
4138 = Petición vacía en el XML
4139 = Servicio no habilitado en producción

Errores que provocan la aceptación del RF pero con algún aviso que debe ser corregido
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.

2000 = El cálculo de la huella suministrada es incorrecta.
2001 = El NIF del bloque Destinatarios no está identificado en el censo de la AEAT.
2002 = La longitud de huella del registro anterior no cumple con las especificaciones.
2003 = El contenido de la huella del registro anterior no cumple con las especificaciones.
2004 = El valor del campo FechaHoraHusoGenRegistro debe ser la fecha actual del sistema de la AEAT, admitiéndose un margen de error de:
2005 = El campo ImporteTotal tiene un valor incorrecto para el valor de los campos BaseImponibleOimporteNoSujeto, CuotaRepercutida y CuotaRecargoEquivalencia suministrados.
2006 = El campo CuotaTotal tiene un valor incorrecto para el valor de los campos CuotaRepercutida y CuotaRecargoEquivalencia suministrados.
2007 = No debe informarse como primer registro, existen facturas emitidas con el obligado emisión y el sistema informático actual.
2008 = El valor de la huella del registro anterior debe ser diferente a la huella del registro actual.

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...