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

[trumbolt]

Empezado por rci

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

[[newtron]]

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.

[siyei]

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.

[[newtron]]

Empezado por siyei

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.

[siyei]

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.

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

Empezado por siyei

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

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.

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

[[newtron]]

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

[siyei]

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.

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

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

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.

[trumbolt]

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

P: Buenas tardes, si hay un problema con una factura enviada en un lote de varias facturas, porque se
rechaza, que pasa con la trazabilidad. ¿Las anteriores se enviaron y son correctas y las posteriores
también? Esa factura tiene una referencia a la anterior que no será la físicamente anterior.

R: En primer lugar, si el resto de registros de facturación enviados están bien, no se rechaza el lote completo, solamente el
marcado como rechazado. Dicho registro de facturación se debe subsanar con una nueva remisión de otro registro de
facturación (ya que no se puede alterar el erróneo). De acuerdo con el nuevo diseño de registro que se publicará en la
orden ministerial (y en la Sede electrónica de la AEAT), deberá llevar 'Tipo de registro'="Sustititivo" e indicador
SubsanaError a "S". La trazabilidad no se ve afectada porque esta va ligada a los registros de facturación según el orden
temporal de su generación, no a las facturas a las que estos referencian.

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?

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

[Franche]

No es la forma correcta.

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.

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

Empezado por newtron

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.

Totalmente de acuerdo.
Lo has explicado de forma clara.

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

Empezado por rci

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.

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.

Empezado por trumbolt

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

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.