Motivos para permitir "subsanar"

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