Cómo solventar el error de una factura rechazada y subsanación por rechazo

[trumbolt]

Empezado por xevi

Yo he tomado la opción de facturar factura a factura. SOLAMENTE VERIFACTU.
Solamente mientras se procesa una factura, nadie más puede generar una nueva.
Generar y enviar el xml a hacienda ANTES de "registrar" la factura, NO imprimir, NO guardar en la base de datos y así evitar posibles encadenamientos posteriores hasta...
Recibida la respuesta de hacienda, salvo error que provoque un rechazo

********* Listado de códigos de error que producen la aceptación del registro de facturación en el sistema (posteriormente deben ser subsanados) *********
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.

Salvo UNICAMENTE esos, (que quiere decir que hacienda cuenta con el registro)... SALVOGUARDO el registro e imprimo una factura generada VERIFACTU.
Libero la base de datos para que se pueda proceder al siguiente registro de facturación.

Creo entender que no he generado ninguna factura mientras no guarde el registro ni la haya impreso.

Yo no lo haría así. Como otros compañeros han apuntado, si hay algún problema con el server de la AEAT o la instalación tiene mala conexión, te quedas sin poder facturar. Precisamente ese era el planteamiento inicial de TBAI que tuvieron que cambiar de manera que el proceso de facturación de los programas fuese independiente de la notificación de los registros de facturación.

Además, si notificas el registro y luego hay algún problema para guardar ese registro en el software, generas un problema bastante más complicado de solucionar.

Yo veo más bien el tema Veri*Factu, si el software actúa sólo como VERI*FACTU, claro, como una especie de enlace en segundo plano con un programa de contabilidad, exportando los registros de facturación cada x segundos. Obviamente lleva más complicación (hay que asegurar la inalterabilidad de los registros, solucionar los rechazos, ...) pero es una base de planteamiento inicial.