Acciones a realizar en respuesta a un ERROR de cara al usuario

[frrr@grupo3rs.c]

Creo que seria una buena praxis el crear una serie de respuesta a los posibles errores recibidos en el envio del XML de una factura.

En el foro anterior este tema lo empezó sglorka y espinete y dejo a continuación sus impresiones. Pienso que deberíamos entre todos continuar con los errores mas comunes y las posibles soluciones de cara el usuario, que la mayoría de las veces es un administrativo general que no tiene mucha idea del tema fiscal y menos de veri*factu

Empezado por espinete  
Volviendo a este tema, que me sigue generando alguna duda...  

¿Cómo sabemos si una factura "Parcialmente Correcta", que se ha aceptado con errores/avisos, se debe subsanar/anular o rectificar? ¿No sería MÁGICO que la propia AEAT devolviera un campo indicando "se requiere subsanación" o "se requiere rectificativa"? Vamos, yo lo veo.

Pero como no lo van a hacer... ¿Cómo sabemos cómo actuar? ¿Teniendo una lista de las decenas de errores posibles y según cada caso, actuar en consecuencia, viendo qué error es en cada caso, etc.?

Porque queda claro que las facturas NO pueden modificarse (para eso estaba la ley antifraude, no?) Hay que rectificarlas.
Entonces... ¿en qué casos concretos se debe hacer una "subsanación" y no una rectificativa?

¿Podría ser algo así:

- Rectificativas: si cambia el importe de la factura, datos fiscales, algún dato erróneo, etc. (en definitiva, contenido de la factura incorrecto)
- Subsanación: error al generar el XML o el envío, no relacionado con el contenido de la factura (error en la huella, encadenamiento, algún dato mal informado...)

¿Es correcto?

¿Aparte de rectificativa y subsanación, hay algo más?
Por aportar algo más.

Factura "Correcta" (sin errores/avisos):
- Consta como enviada
- No se podrá volver a subir porque Hacienda dirá que está duplicada
- No hay que hacer nada. Guardamos el registro, lo marcamos como "aceptado/enviado", ya tendremos el QR, etc.

Se puede seguir emitiendo subsanaciones a posteriori, por ejemplo, te das cuenta de que el Régimen tributario lo habías enviado mal.

Factura "Parcialmente Correcta":
- Consta como enviada
- No se podrá volver a subir de forma "normal". Hay que subirla como "subsanación".
- Habría que marcarla como "subida pero con errores" para evitar que se vuelva a subir como factura normal y exigir que sea una subsanación
Correcto

Factura "Incorrecta":
- NO consta como enviada
- Habría que marcarla como "Error" para saber que podemos volver a intentarlo
- Podemos arreglar lo que sea que haya dado error y volver a subirla, hasta que devuelva "Correcta" o "Parcialmente correcta"

No puedes volver a subirla, debes emitir una "Subsanación x Rechazo Previo" siempre y cuando te venga un código de error dentro del objeto respuesta (la Aeat la recibió y la rechazó.). Si este objeto viene vacío, indica que la Aeat no la ha recibido y por ende, no la ha rechazado, entonces sí debes de reenviar pero en orden cronológico de generación de registros, o sea, antes un fallo de comunicaciones debes parar los envíos, no puedes permitir mandar un primer registro, te fallan las comunicaciones en el segundo y sigues intentándolo y sí, te entra el tercero.

Para saber si se debe emitir una Rectificativa o una Subsanación, yo estoy agrupando los códigos de error en tres bloques, un bloque donde seguro que es una rectificativa (errores desde el 1162 al 1170 y otros errores donde se referencia el Nif del destinatario), otro en que seguro que es una subsanación (la mayoría) y un tercero donde ambas opciones podrían ser válidas, por ejemplo, Nif no censado se puede arreglar con una rectificativa poniendo bien su Nif o con una subsanación, añadiendo la clave IdOtro con indicación de No Censado.

Empezado por sglorka  
Factura "Incorrecta":
- NO consta como enviada
- Habría que marcarla como "Error" para saber que podemos volver a intentarlo
- Podemos arreglar lo que sea que haya dado error y volver a subirla, hasta que devuelva "Correcta" o "Parcialmente correcta"

No puedes volver a subirla, debes emitir una "Subsanación x Rechazo Previo" siempre y cuando te venga un código de error dentro del objeto respuesta (la Aeat la recibió y la rechazó.). Si este objeto viene vacío, indica que la Aeat no la ha recibido y por ende, no la ha rechazado, entonces sí debes de reenviar pero en orden cronológico de generación de registros, o sea, antes un fallo de comunicaciones debes parar los envíos, no puedes permitir mandar un primer registro, te fallan las comunicaciones en el segundo y sigues intentándolo y sí, te entra el tercero.
En este último caso, en efecto habría que saber si fue un error "en el envío" o si efectivamente fue rechazada por Hacienda (la recibió pero la rechazó).
Si el error es en el envío, obviamente habría que reintentar el envío. Si fue rechazada por Hacienda (está enviada pero la rechazó por algún error), habría que enviar subsanación.

Correcto?

Hay que hacer muchas pruebas de todo tipo para entender el funcionamiento al 100%, y aún así seguro que algún caso concreto se me escapa...
Cita:
Empezado por sglorka  
Para saber si se debe emitir una Rectificativa o una Subsanación, yo estoy agrupando los códigos de error en tres bloques, un bloque donde seguro que es una rectificativa (errores desde el 1162 al 1170 y otros errores donde se referencia el Nif del destinatario), otro en que seguro que es una subsanación (la mayoría) y un tercero donde ambas opciones podrían ser válidas, por ejemplo, Nif no censado se puede arreglar con una rectificativa poniendo bien su Nif o con una subsanación, añadiendo la clave IdOtro con indicación de No Censado.
Creo que es la mejor (o única) forma de hacerlo, y mostrar un mensaje en pantalla al usuario para que sepa lo que tiene que hacer y por qué. Con TicketBAI olvidamos esta parte y no hacían más que llamarnos para preguntar "qué hacemos ahora". Y luego nosotros a rebanarnos el coco, primero intentando averiguar qué hicieron y después para decirles cómo corregir cada caso.

Sin duda lo mejor es dejarlo todo masticadito a los usuarios para evitarnos dolores de cabeza más tarde.

Esto seria el arranque para conseguir una guia de buenas practicas de cara al usuario.

[Neftali [Germán.Estévez]]

El problema es que un mismo error en unos casos se puede arreglar con subsanación y en otros casos SE DEBE arreglar con rectificativa.
Esa última decisión es del usuario que debería saber qué está haciendo.

Creo recordar que si la factura no ha sido enviada al cliente puedes subsanarla y enviarla. Si la factura ha sido enviada al cliente el OBLIGATORIO crear una rectificativa y enviarla al cliente (esta situación sólo la conoce el cliente final y él es quien debe decidir si hace una o la otra).

[Franche]

Que error tienes que tener al enviar para que no conste como enviada y así de esa forma podamos modificarla y volver a intentarlo ?

[sglorka]

Empezado por Franche

Que error tienes que tener al enviar para que no conste como enviada y así de esa forma podamos modificarla y volver a intentarlo ?

No se puede modificar una factura después de haberla emitido y generado su registro de facturación. Siempre hay que caminar hacia delante aunque la factura haya sido rechazada o aceptada con errores.
Errores en la identificación del destinatario (nif inexistente o datos fiscales erróneos), en los tipos de iva utilizados (Ivas no válidos para el periodo de facturación), errores en la construcción de las bases imponibles, en resumen, cualquier defecto que no cumpla con los artículos 6 y 7 del reglamento de facturación, requieren de una Rectificación.
El resto de errores, nif de destinatario no censado, sumas de bases imponibles y sumas de cuotas mal calculadas, importe total no concordante o huella mal construida (independientemente de si está encadenada con la huella anterior o no), fallo en los criterios de validación de la Aeat, requerirán de una subsanación.

[Franche]

Empezado por sglorka

No se puede modificar una factura después de haberla emitido y generado su registro de facturación. Siempre hay que caminar hacia delante aunque la factura haya sido rechazada o aceptada con errores.
Errores en la identificación del destinatario (nif inexistente o datos fiscales erróneos), en los tipos de iva utilizados (Ivas no válidos para el periodo de facturación), errores en la construcción de las bases imponibles, en resumen, cualquier defecto que no cumpla con los artículos 6 y 7 del reglamento de facturación, requieren de una Rectificación.
El resto de errores, nif de destinatario no censado, sumas de bases imponibles y sumas de cuotas mal calculadas, importe total no concordante o huella mal construida (independientemente de si está encadenada con la huella anterior o no), fallo en los criterios de validación de la Aeat, requerirán de una subsanación.

Pero si hay un error en cualquiera de los casos que pones que requieren subsanación tendrás que modificar y volver a enviar ?

[sglorka]

Empezado por Franche

Pero si hay un error en cualquiera de los casos que pones que requieren subsanación tendrás que modificar y volver a enviar ?

Se supone que si requiere Subsanación, no rectificación, la factura en el SIF, no necesita una modificación posterior, probablemente necesites ajustar tu código fuente porque algo has hecho mal al generar el registro de facturación. Si no es el caso, como por ejemplo una fecha de operación incorrecta, sí tendrías que modificar ese campo de la factura en el SIF y posteriormente, generar una subsanación. Ese cambio hecho en la factura vendría respaldado por ese registro de subsanación que vas a emitir y que no ha necesitado la emisión de una rectificativa. Pero vamos, que eso de dejar la factura abierta para que el usuario haga lo que quiera con ella después de emitida, totalmente prohibido. La idea es habilitar una serie de entradas en un menú asociado a esa factura, de campos que podrías subsanar para corregirla, esos campos, deberían hacer referencia a aquellos que no han cumplido alguna regla de validación de la Aeat y que bajo ningún concepto, alteren bases imponibles, cuotas repercutidas, identificación del destinatario, etc