Motivos para permitir "subsanar"

[ermendalenda]

Empezado por RUBEN_SP

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

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.

[RUBEN_SP]

Empezado por ermendalenda

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

[FacilIng]

Empezado por ermendalenda

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.

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.
¡Muchas gracias!

[ermendalenda]

Empezado por FacilIng

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

[ermendalenda]

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

[rci]

Empezado por FacilIng

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.
¡Muchas gracias!

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?

[ermendalenda]

Empezado por rci

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?

[rci]

Empezado por ermendalenda

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

Empezado por FacilIng

tenemos que "arreglarle" los RdF's al cliente para que los pueda enviar a la AEAT.
...
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).

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

[ermendalenda]

Empezado por rci

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.