Motivos para permitir "subsanar"
 

Sé que ya se ha hablado de esto mucho. De hecho algunos han optado por no permitir hacer subsanaciones, sino rectificativas, porque motivos para subsanar debería haber pocos (y los que pudieran haber, se podrían corregir también con una Rectificativa, aunque sea más tedioso...).

Pero me gustaría tener esto cubierto para algunas causas concretas, por si acaso.

Entiendo que solo se puede subsanar una factura si el problema a corregir no afecta a los importes de la factura, los datos fiscales, etc.
Pero imaginemos que un usuario se equivoca de Motivo de Exención (pone E2 en vez de E3), o elige una ClaveRegimen que no es la adecuada (04 en vez de 01, o yo qué sé).
Hacienda no da error (o quizás sí), pero esos datos están mal (otra cosa es que sea TAN importante como para corregirlo, pero bueno, eso es otra historia...)

Total. Estoy pensando en detectar en mi aplicación si el usuario cambia alguno de estos datos de una factura/RF ya enviada, y si es así, intuir que se trata de una subsanación y generar un nuevo RF de Subsanación:
- ClaveRegimen cambiada
- MotivoExencion cambiado
- no sé si también tener en cuenta un cambio en el motivo y código de rectificación (R2,R3...) para las rectificativas

¿Pondríais un botón "subsanar" para determinadas facturas que cumplan una serie de condiciones? ¿O detectaríais con código si se ha cambiado algo susceptible de subsanación (como los ejemplos que puse) para evitar que ese botó esté siempre visible (y al usuario le dé por pulsarlo 30 veces)?

O si pasar un kilo de esto y no permitir subsanar nada. Rectificativas y punto :rolleyes:

Yo por mi parte, de momento no permito la subsanación, mis clientes son "muy cucos" así que les corto las alas todo lo que puedo, cuando la cosa se calme ya veremos :rolleyes:

Nosotros hemos puesto un botón de subsanar en la pantalla que muestra los registros erróneos, pero lo único que hace es generar un nuevo registro de la misma factura. No sirve para modificar importes ni ningún otro valor (para eso se hace rectificativa), pero sí lo usamos para corregir errores del software.

Por ejemplo, el otro día les fallaron los envíos a algunos clientes porque tenían un formato de fecha extraño en su ordenador y Verifactu rechazaba la factura. Pues arreglamos el SIF para que ya no pasara y pulsamos el botón de "subsanar", enviándose así un nuevo registro exactamente igual que el anterior, pero con la fecha con el formato correcto.

Otro caso de uso sería también si recibiéramos errores de "registro duplicado", "esta no es la primera factura" o "han pasado los 240 segundos" (por si en algún caso no se enviaran con la marca de incidencia), en estos casos pulsaríamos "subsanar" y, como ese nuevo registro sería igual que el anterior pero devolvería un estado correcto, ya mostramos al usuario que la factura es correcta. :)

Los registroa que te devuelva error por pasar el tiempo de 240 y aunque no hayas marcado incidencia, no hay que reenviarlos ni crear subsanaciones, no hay que hacer nada, solo corregir el software si fuera por culpa de error de software.

Pero si mandas una subsanación de un registro duplicado te va a volver a dar el mismo error

Tienes razón, @ermendalenda.

Sobre lo que comentas @RUBEN_SP, solo si se envían con RechazoPrevio=X. En caso contrario, la AEAT devuelve aceptado.

Sea como sea, esperamos no tener que usarlo en estos dos casos (y como menciona @ermendalenda, con los 240 segundos no hace falta). Pero es cierto que sí que nos ha sido útil para solucionar esos errores de software que se habían escapado. :)

¡Espero que sirva!

Una subsanación normamlmente no te va a devolver registro duplicado, puesto que el cometido es claro, subsanar un envio anterior, a no ser que sea lo que comenta el compañero en el post anterior, subsanacion sin registro previo que si existe si te va a devolver error y entras en bucle, que tendrias que enviar una subsanación de una subsanación mal realizada para seguir el orden de encadenamiento, hay que andarse con ojo y no enviar subsanaciones sin comprobar la existencia del registro, igualmente para las anulaciones.

Ok. Tienes toda la razón

Con respecto a esto, nos surge una duda a causa de un error que le ha pasado a un cliente.

Este cliente tiene mal la configuración regional por lo que usa el "." como separador de horas. P.e.: "2025-10-24T11.38.06+02:00".
El cliente ha generado una docena de RdF que el programa no llega a enviar a la AEAT pq nuestro código "peta" antes, al no reconocer el formato de hora.
Por lo tanto la AEAT no tiene constancia de estos RdF ni tampoco los ha rechazado pq no se han llegado a enviar.

Nosotros ahora ya hemos corregido el error para que siempre se usen los ":" como separador de horas en el XML de los RdF.

Pero claro, tenemos que "arreglarle" los RdF's al cliente para que los pueda enviar a la AEAT.
La cuestión es que como no se llegaron a enviar en ningún momento, no podemos usar "Subsanar un envío previo aceptado" (punto 9.1.2 del documento de servicios web) ni tampoco "Subsanación por rechazo (sin registro previo)" (punto 9.1.3 del mismo documento).

Entonces, ¿cómo lo hacemos? ¿Cuál sería la forma correcta de hacerlo?
Creemos que los RdF del cliente los tenemos que "borrar/ocultar" y volver a generarlos de nuevo para poder enviarlos como alta inicial de RdF (punto 9.1.1).

A ver si nos podéis ayudar. :D
¡Muchas gracias!

La marca =S se refiere a si te han rechazao anteriomente una subsanación, pero el registro original permanece en sis servidores.
Subsanacion sin rechazo previo
=N (existe el registro en el servidor de verifactu)
=S (te han rechazado una subsanacion pero el registro original existe en el servidor de verifactu)
=X (Te han rechazado el original)

Por otro lado, cuando arranqueis un SIF, os recominedo, si podeis tener prioblemas con los separadores, siempre reaigneis los mismos con las variables de sistema, por ejemplo separador decimal, de miles, de hora, fecha...
Y eso lo admite cualquier deaarrollo independientemente del lenguaje, os ahorrara posobles errores de la instalacion o manipulaciones.
Si lo necesitais por que no lo tenga directamente, podeis usar la api de windows SetLocaleInfo

Yo creo que tienes que volver a enviar esos registros de facturación ya creados.
NUNCA puedes modificarlos.
Si el programa corregido ya no "peta", los envía con la marca de incidencia, para que no se queje que envías tarde y punto.
y si al enviar se rechazan, luego ya si que podrás CREAR un nuevo registro de facturación de subsanación

Que pensáis los demás?

Eso no estaría alineado con el reglamento. Comerselos como comentas se los come, pero hay diversos riesgos:
Que tengan trazado y grabado lo que has intentado enviar erroneamente y vean que has vuelto a generar los mismos, cosa incompatible con el reglamento. 2 que te lies y los envies despues de haber enviado alguno posteriormente emitido cuando el software está bien(dificil por que lo normal es que este intentando mandar un bloque con algunos mal y uno bien e igualmente te lo rechaza), lo legal:
-subsanación rechazoprevio=X.
Además entra dentro de la lógica de que todos estamos empezando y hay fallos.
A mi ya me ha pasado algo parecido en una instalacion hace 1 semana y opte por la subsanación, qie necesidad de arriesgarse?

si no se han enviado nunca, como dice el compañero porque el programa petaba, no veo el problema.
lo que yo si considero fuera de la ley es lo que propone de Un registro de facturación no se puede modificar nunca.
Estamos de acuerdo en eso no? ;)


Yo dije volver a enviar, en el caso que los registros de facturación creados estén bien y lo que estaba mal era el programa que los gestionaba y petaba.
Si los registros están mal y se rechazan, pues tal como dije, crear nuevo registro de facturación de subsanación. Vaya lo mismo que comentas tu ermendalenda :)

Saludos

Llevas razón, maal entendido por mi parte.
Si ya estan generados y es el que genera el bloque de envios el que peta, palante.
Disculpa.