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

Buenas compañeros,

Tengo bastante bola con un problema que ya llegó a insinuar @ermendalenda en algún post pero que no me ha quedado muy claro. Tiene que ver con la solución a los problemas de facturas / registros de facturación rechazados tras su envío a la AEAT y la figura de "subsanación por rechazo".

Para el ejemplo, pongamos que envío tres facturas, la 1A, 2A y 3A, en una conexión. La primera se acepta, la segunda se rechaza con un error de nif incorrecto y la tercera se acepta.

En este escenario y teniendo mentalidad TBAI, para empezar tendría un error de encadenamiento porque me faltaría la factura "a que es con la que "encadenaría" la 3A (cuando se rechaza una factura, no se guarda nada en la AEAT) pero parece que con Veri*Factu esto no es un excesivo problema.

En esta momento y cuando el cliente pudiera, habría que solventar el problema del nif de la factura número 2A. Y aquí llega la historia y la "bola".

Teóricamente, el software NO puede permitir la modificación de ningún registro ya emitido. Entiendo que ésto también es extensible a los rechazados por la AEAT. En tal caso, no veo la manera de poder usar la figura de envío de alta de subsanación por rechazo. Si no se permite la modificación de un registro ya guardado, ¿cómo puedo volver a enviarlo utilizando esta posibilidad?. No lo acabo de entender.

Bien, si sigo con el hilo de pensamiento, como no se puede modificar de ninguna manera la factura 2A, la única opción es hacer otra factura que la modifique, es decir, emitir una factura rectificativa. Pongamos entonces que el cliente emite la factura 1R (en mi soft y supongo que en el de todos, las rectificativas llevan su propia serie y numeración), que modifica la factura 2A. Esta nueva factura, encadena con la última factura emitida, la 3A, llevará su propia huella e incluirá la info identificativa de la factura 2A en el nodo <FacturasRectificadas>. En este momento entonces, se está enviando una factura que informa en <FacturasRectificadas> de una factura que no existe en la AEAT. ¿Eso es correcto?

¿Algún otro concepto que se me esté escapando?

Gracias a todos.

Es tan fácil como generar un nuevo registro de facturación para la factura 2A con el nif correcto, nadie te dice que no puedas modificar los datos asociados a la factura, te dicen que no puedes modificar el registro de factura ya generado. El nuevo registro de facturación estará encadenado con el 3A.

Cuando tú guardas una factura se genera el RegistroDeFacturación, posteriormente esos registrosDeFacturación se envían o no dependiendo de si tienes Verifactu o no-verifactu, pero el encadenamiento se hace en el momento de generar los XML.

Al crear las factuuras 1A, 2A, y 3A se generan los 3 RegistrosDeFacturación (XML) y se van encadenando. 1A -> 2A -> 3A
Que luego la factura 2A sea rechazada, no afecta a los 3 RegistrosDeFActuración ya generados y encadenados.


Eso es correcto. No se puede modificar un RegistroDeFacturación ya generado (eso es innegociable).
En este caso, para corregir ese error, deberá generarse un nuevo RegistroDeFacturación 2B y encadenarlo con el último 3A (el cómo se genere, sea con sustitutiva, sea con una nueva versión del programa,...). Y luego enviarlo o no dependiendo de si tienes verifactu o no-verifactu.
El encadenamiento quedará como: 1A -> 2A -> 3A ->2B

Eso está claro. El tema, o como lo he entendido, es que ese registro de facturación de sustitución por rechazo, tiene que tener el mismo numero que la factura original pero lógicamente cambiará su encadenamiento ya que ira asociada a la última factura emitida. Algo así 1A-2A (rechazada)-3A-2A(sustitutiva por rechazo). Yo no sé si esto es así o es todo una paja mental mía, sobretodo porque en mi software, un registro de facturación es el equivalente, digamos, a una "factura en papel" y no pueden existir dos "facturas en papel" con el mismo número ...

Hola Neftali, a que te refieres con "una nueva versión del programa" ?

Nosotros en ese caso teníamos pensado permitir al usuario introducir manualmente el valor correcto a subsanar y con eso generar un nuevo registro de facturación, de la misma factura.
Esa factura pasaría a tener dos registros de facturación, el de alta y el de subsanación.

Me parece haber leído algo parecido en otra parte del foro

Puede haber mas de un registro de facturación para cada factura, uno de alta, uno de anulación, ...

Digamos que puede haber varias situaciones por las que una factura puede tener 2 registros de facturación (o más) como tú dices y se pueden generar de formas distintas.
Por ejemplo, varias situaciones:

1) La que tú comentas, el usuario cambia un valor de la factura (por ejemplo una causa exenta E4 por una E6) y se genera un nuevo RegistroDeFacturación para esa factura (tendrá uno de alta y otro de subsanación).

2) El programa tiene un error y genera mal el RegistroDeFacturación. La factura F1 es correcta pero el programa ha generado mal el RegistroDeFacturación. Nosotros en ese caso tenemos previsto (una vez corregido el error en el programa), que sin cambiar/modificar la factura (porque en este caso la factura es correcta), el usuario pueda "forzar" a que se genere un nuevo registro de facturación de esa factura. Si se ha corregido el error correctamente, esa factura tendrá, al igual que antes, 2 RegistrosDeFacturación. Pero se han generado con métodos distintos.

Con el comentario de antes me refería a la segunda.

Me parece muy interesante para esos casos.

Faltaría ver como controlar esa "opción del programa", para evitar que cualquier usuario pueda ir creando nuevos registros de facturación de las facturas.
Imagino que seria una opción disponible solamente para las facturas que han sido rechazadas en el envío del último registro de facturación por ejemplo... lo estudiaremos.

Muchas gracias

Muy buenas ideas que me dan que pensar sobre cómo se podría implementar todo ésto en mi software. Entiendo, no obstante, que siempre nos estamos refiriendo a subsanaciones (bien por un primer rechazo en el alta o por algún cambio "menor", verdad? porque si hay alteraciones ya en la parte económica o fechas, creo que ya estaríamos hablando de realizar rectificativas ...

Buenas.


Aclarar un par de temas. Según creo una subsanación es la corrección de una factura rechazada por motivos que no afecten a la ley de facturación, o sea, casi ningunos. En el caso de tener que corregir algo que afecte a la ley de facturación (Nif, fecha...) hay que emitir una factura rectificativa que tendría un número de factura nuevo (porque va en otra serie) y estaría encadenada a la última factura que se haya hecho.


En la práctica creo que pocas facturas se podrán subsanar (manteniento el número) y que habrá que hacer facturas rectificativas.


Saludos.

Yo hace tiempo que como Ian Martens en su famosa anécdota de cuantos dientes tiene un camello, en lugar de perderme en "literaturas" lo que hago es probar las cosas directamente.

Por ejemplo, aunque en teoría no se puede enviar una factura con fecha anterior a la fecha actual, de momento Verifactu las acepta sin problemas (excepto anteriores a 2024).
Esto en mis programas tiene sentido porque muchas veces los clientes, cuando el fin de mes coincide en fin de semana, facturan los albaranes pendientes el lunes, pero con fecha anterior al día.

Otro tema que también he comprobado es que me permite enviar la misma factura, una vez corregida, en caso de rechazo. Es decir, en principio no hace falta generar una nueva factura, sino corregir directamente el error y volver a enviarla.

Esto que puede parecer que no tiene mayor recorrido, es clave, porque si a final de trimestre se envía una factura, pero nos damos cuenta después del envío que ha sido rechazada, por la razón que sea, si me permite enviar la misma factura entraría en dicho trimestre. En cambio, si hacemos lo que en teoría manda la documentación, habría que hacer una nueva factura de corrección pero ya no entraría en dicho trimestre.

Tienes que tener en cuenta de que el que se la "trague" si la envías como subsanación no quiere decir que sea correcto. La ley de facturación dice claramente que no se puede hacer y yo no me la jugaría teniendo en cuenta (entre otras cosas) que estás informando al fisco de la "ñapa" con pelos y señales. Por otro lado seguramente con el tiempo irán apretando las validaciones y no te extrañe que en cualquier momento deje de "tragar" estas cosas.



Saludos.

Vamos a ser serios.

Una cosa es las "ñapas" que comentas, que todo el mundo conoce y otra cosa es el funcionamiento del día de a día de una empresa.

Por ejemplo, las facturas recibidas se suelen introducir en días posteriores, cuando se reciben por email, etc, aunque esto se supone que cambiará cuando entre en vigor la factura electrónica con la cual también nos vamos a divertir.

Por ello el SII te proporciona un margen de días para transmitir dicha información a Hacienda.

Lo que no tiene sentido, "desde mi punto de vista", es que Verifactu imponga mayores restricciones que el SII.

La ley debería estar diseñada para facilitar el funcionamiento de las empresas, no para obstaculizar su desarrollo.

De hecho siempre tienes la opción de acogerte voluntariamente al SII y en ese caso no estas obligado a instalar Verifactu. Es una opción que no descarto en aquellos clientes que la entrada de Verifactu vaya a suponer un problema.

En cuanto a lo primero es una opción bastante restringida, como comentas.
En cuanto a lo segundo está en estudio, porque puede ser una factura que se ha generado mal, pero a ojos de hacienda es correcta y se ha aceptado (por ejemplo hemos enviado un E6 en lugar de un E4, por error del programa). Está aceptada, pero igualmente hay que enviar un nuevo registro una vez corregido el programa.

Si, correcto.
Hay muy pocos cambios en la factura que generen subsanación (cambios menores como dices). La mayoría de los cambios en factura generan una rectificativa.

Totalmente de acuerdo.
Lo has explicado de forma clara.

Está bien probar, pero tened en cuenta que lo que manda es la documentación.
En TicketBAI ya pasó, que para las primeras versiones "tragaban" con determinadas cosas, que con el tiempo han ido corrigiendo, y a medida que han ido saliendo versiones han ido incrementando las validaciones y las restricciones.

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 creo que no es la forma correcta. En el momento en el que "intentas" enviar una factura a VeriFactu esa factura ya existe y va a misa, no puedes decir..."uis... me he equivocado y me olvido de la factura". Seguro que VeriFactu "sabe" que has intentado enviar una factura con unas características determinadas aunque te la rechace e igual no pasa nada que igual si. Yo en particular no optaría por ese método.


Saludos.

Yo pienso igual, no es la forma correcta. "Es empezar la casa por el tejado".

Hay que pensar que puede haber problemas de internet o del mismo servidor de Hacienda, como pasó hace días, que nos impida enviar las facturas en tiempo real.

En ese caso no debes de parar de facturar, imagínate una tienda abierta al púbico.

El problema que le veo a esto es que si los servidores de la AEAT caen durante 2 horas (por decir algo) se te va a quedar el sistema parado.
Imagino que tampoco tienes procesos al estilo de facturación automática (que generen X facturas de forma seguida en poco tiempo), porque con este sistema tampoco sería viable.

Revisando las FAQ que están en el sitio de desarrolladores, he encontrado algo interesante:

No sé si estará vigente / actualizado ésto pero puedo inferir que cualquier registro rechazado (bien sea por nif incorecto o cualquier otra causa) es susceptible de ser enviado por subsanación indicando que es subsanación por rechazo. Entiendo que hacen diferencia entre, por ejemplo, haber emitido un registro de facturación con un nif correcto pero "equivocado" y tener que modificarlo (lo que acarrea una rectificativa según se especifica en el reglamento de facturación) a que el registro de facturación ha sido rechazado porque tiene un nif inválido y que se puede solucionar con una sustitutiva y no haría falta una rectificativa.

¿Alguien ha preguntado ésto a la AEAT? ¿Cómo lo veis?