Discúlpame si te he entendido mal, pero voy a dar mi propia interpretación, basada en esta publicación de la Agencia Tributaria:

https://sede.agenciatributaria.gob.e...amentario.html

Allí dice claramente, que las letras a), b), c) y d) son de directa aplicación desde el 11 de Octubre de 2021, y que las letras e) y f) están pendientes del desarrollo reglamentario.
Por otro lado, yo también he hecho consultas a la AEAT, y en una de ellas, me contestan que, "aunque haya parcelas de mi Sistema Informático que estén pendientes de desarrollo reglamentario, para salvaguardar mi responsabilidad de desarrollador, debo abstenerme de realizar cualquier trabajo, modificación y/o corrección sobre programas que no cumplan esas 4 letras, de a) a d)". De hecho la frase exacta de la contestación es: Por tanto, a partir de dicha fecha solo pueden venderse sin incurrir en infracción, los productos que cumplan estas características.
Por último, utilizas la palabra intencionalmente en tu explicación como uno de los elementos necesarios para ser sancionado, que yo no he encontrado en ninguna de las publicaciones ni en el BOE, ni en Reglamento, ni en el RD, más bien al contrario pues la Ley dice "explicitamente" que la mera tenencia de sistemas que no cumplan con la Ley es motivo de sanción. Esto, a mi entender, significa que la AEAT se desliga de su obligación de demostrar que se está cometiendo una ilegalidad, y nos traslada a los desarrolladores esa responsabilidad, de modo que si un "obligado tributario" tiene instalados en sus ordenadores varios programas, y alguno de ellos no cumple la Ley, podría ser sancionado.

Un saludo.

Ya han publicado documento de PREGUNTAS y RESPUESTAS del seminario (webminar) sobre VERI*FACTU.
Descargable desde la web de hacienda y desde el FTP del club.

Actualizo el mensaje #1 recopilatorio de información.

Intencionalmente lo han usado como respuesta a una pregunta, supongo que para aclarar el concepto, ya que hay muchas normativas que se establecen y hasta que no haya desarrollo reglamentario no tienen apenas efecto, a veces no se hace el desarrollo reglamentario y por tanto la normativa queda olvidada.
De todas formas en las preguntas y respuestas del seminario podrás ver una pregunta al hilo del mismo escenario en el que estanos intentando aclarar y verás que lo que te he comentado en el post está reforzado por la respuesta que dan. Es cierto que el tema roza la ambigüedad en lss respuestas de la AEAT, pero mi interpretación es clara, que si cumples con el envío de la facturación, hasta que no haya otro desarrollo reglamentario, el resto de lo que tengas respecto a la contabilidad, no solo no les importa, además es que a efectos fiscales no vale para nada si no cuadra con lo enviado.
Pregunta
En la ley habla en algunos apartados de los procesos contables. Quiere decir que habría que llevar una auditoria contable en el caso de se modifique dicha información en contabilidad o que no sea posible alterarla?
RESPUESTA
El artículo 29.2.j) de la Ley General Tributaria aplica a los sistemas informáticos utilizados para dar soporte a los procesos contables, de facturación y de gestión, por lo que todos ellos están obligados a garantizar los 6 requisitos exigidos sobre los registros empleados (es decir, sobre la información y datos que maneja cada uno) y, por tanto, no permitir interpolaciones, omisiones o alteraciones de las que no quede la debida anotación en los sistemas mismos. Sin embargo, solo se concreta cómo cumplir con este mandato para el caso de la facturación, lo que se hace mediante el reglamento aprobado por el RD 1007/2023, que desarrolla los requisitos que se deben implementar en los sistemas informáticos de facturación para cumplir con el 29.2.j).

Hola como y cuando se supone que sería conveniente o la mejor opción para realizar la comprobación de la fecha del sistema, ¿En el momento que se va a confeccionar una nueva factura o serie de facturas? y ¿que se debería hacer, comprobar y comparar la fecha de la última factura y si la actual es anterior a la última marcar un error?

El sistema comprueba y se auto-asigna la fecha de Windows al entrar al mismo. Cierto que lleva una opción en la que se puede alterar la fecha de trabajo. Esta se hizo necesaria ya que si cambiamos de ejercicio y hay que hacer alguna operación en el ejercicio anterior con esta opción se cambiaba por ejemplo al 31/12/2023 y se podían entrar facturas de compra y realizar últimas ventas en el ejercicio anterior. El sistema no permite hacer estas operaciones en el ejercicio 2023 con fecha 02/01/2024.
¿Vosotros anularíais la opción de cambio de fecha de trabajo?
Venga gracias, a ver si me podeis orientar y echar un cable al respecto.

Tao y como comentaros los compañeros en post anterior4s y tal y como han r4spondido hacienda en el seminario, la fecha de operwxion de la factura puede ser anterior a hoy, no s8endo así con la fecha de wxpedicion, para ello disponemos de 2 nodos en verifactu con lo cual, yo veo conveniente controlar que no senpueda modificar la fecha del sistema de windows o del S.O que sea, comprobando contra un servidor de hora externo como el que puse. Como lo he hecho yo... si no coincide en más menos unos 4 min. No dejo hacer factura. Por otro lado si puedes dejar el campo fecha de operación abierto a fechas anteriores a la de hoy. Y la fecha de expedición la del sistema sin opciones a cambiarla.

A alguien le funciona los enlaces de los videos?

Por mi experiencia con los clientes en TicketBAI, recomiendo mirar la fecha en internet, ya que nos hemos encontrado con clientes listillos que para saltarse lo de la fecha de expedición cambiaban la fecha del sistema.

¿Qué enlaces?

Hola,

Nosotros también utilizamos para la fecha-hora de expedición de facturas, en TicketBAI, la fecha-hora de un servidor en Internet.
Fiarse de la honestidad de todos los clientes es jugársela.
Seguro que los hay que en cuanto se dan cuenta de que pueden cambiar la fecha-hora del sistema, hacen de las suyas para poder emitir las facturas con la fecha que quieran.
Hay que cerrar puertas a los "listillos", que siempre los hay.

Saludos

Estos https://www.agenciatributaria.es/AEA...actu_EEDD.html

Vale entiendo que se puede realizar una ultima factura a fecha de 31/12/2023 con fecha 02/01/2024, cuya fecha de factura constará como 31/12/2023 y fecha de expedidición 02/01/2024, siendo fecha de factura y fecha de expedición cosas distintas en verifactu. Por tanto como bien indicas dejo un margen de 4 minutos de diferencia entre la fecha del sistema y la obtenida de Internet para permitir o no realizar la factura. Por lo que creo que lo más lógico es ejecutar la comprobación en el momento de expedir la factura con el comando curl.exe (que indicaste en post anteriores y que tengo integrado) y comprobando desde el json generado.
Tenemos diferenciada en la aplicación la fecha de trabajo que es la que asigna la fecha y hora de factura y la fecha y hora del sistema que sería la que se asignaría a la de expedición de factura.

Gracias Ermendalenda

No.
A mi tampoco.
No deben haber puesto bien los links o no tenemos permisos.

Al principal deja acceder pero a parte.1, parte.2, etc no

Te recomiendo que dejes un parámetro a nivel de superusuario en la que puedas desactivar esa co probación, imagínate que falla el se4vidor de Internet y devuelve un dato erróneo y no dejas facturar. Así lo tengo hecho

Si, si por supuesto, seguire tu recomendación. Perfectamente podría pasar un fallo en el servidor horario.

Incidencia no recogida en reglamento
 

Buenas, voy a plantear otra duda a Veri*Factu que he visto que en las consultas la han planteado pero veo que hay que apretar un poco más.
La duda es sobre los registros que se pueden perder después de imprimirlo.
La respuesta de Veri*Factu es que el reglamento es claro de que no podemos imprimirlos hasta que se hayan grabado correctamente y el envio debe ser "inmediato", en el mismo seminario aclaran que lo de de inmediato es siguiendo el flujo, pero claro, el flujo depende de circunstancias que pueden ver alterada la inmediatez por Conexión lenta o por otras circunstancias.
Ejemplo Real que me ha pasado en 1 de más de 4.000.000 de tiquets en las que llevo hecha las pruebas, pero me ha pasado:
Genero ticket en papel.
Se corta la luz y se pierde el contenido de la caché que aún no se ha grabado en el disco y aún no se habia enviado a Veri*Factu por que el corte de luz hua sido inmediatamente al imprimirse. Y la impresión es más rápida que el envio, por tanto, hay un periodo de decimas de segundos en la que existe la posibilidad de que no se envie.
El desarrollador se compromete a que todo ha sido con el control de flujo establecido pero no puede controlar esa incidencia puntual en la que en ocasiones solo se puede detectar un cierre de programa fuera de control, pero al encender podemos haber perdido información irrecuperable, el siguiente registro podemos marcarlo como incidencia y encadenado con el anterior grabado correctamente, por que es lo que el programa puede saber.

Imagina que el receptor de la factura envia el QR pero yo nunca lo envio por que no lo tengo. Suelen ser importes pequeños pero he roto el flujo de encadenamiento correcto.
Culpa: Hardware
Solución: Tendrían que obligar a usar equipos con posibilidad de usar baterias de caché, por lo tanto encarecimiento del hardware, pero eso es otro cantar que no tiene nada que ver con los desarrolladores.

Nosotros en TicketBAI no marcamos una factura como enviada hasta que hacienda no devuelve que ellos lo han recibido. Cuando abra la aplicación otra vez tendrá que enviar esas facturas que no se han enviado.

El problema es que se pierde la caché de disco y se pierde el registro

Creo que estáis confundiendo los términos Fecha de operación y Fecha de expedición.

La Fecha de operación es la fecha en que realmente se ha generado el hecho imponible (entrega de bienes / prestación de servicios).
Para el caso de operaciones con empresario o profesionales ambas fechas pueden ser distintas. Por ejemplo, el día 10/02/2024 se entregaron 5 cajas del producto "X" y no se emitió factura se emitió albarán (fecha de operación = 10/02/2024). Posteriormente, el día 15/02/2024 se entregaron 15 cajas del producto "Y" y no se emitió factura, se emitió albarán (fecha de operación= 15/02/2024).
Llegado el día 01/03/2024, voy a generar la factura por los suministros del mes de febrero al empresario pero lo voy a hacer con fecha 29/02/2024 ya que no he emitido todavía ninguna factura el día 01/03/2024 y no se va a producir desfase (número factura / fecha)
Fecha de Expedición = 29/02/2024, Fecha de Operación = 15/02/2024 (la más reciente de entre todas las operaciones del mes)

Para el caso de NO empresarios o profesionales, no le podemos emitir albaranes. Estamos obligados a emitir factura el mismo día en que prestamos el servicio o entregamos bienes, por lo tanto la fecha de operación y la fecha de expedición es la misma.
Si para este caso, queremos emitir una recapitulativa de las operaciones a cliente particular a final de mes, por que el cliente no quiere contabilizar las 35 facturas emitidas en dicho mes, podemos anular / abonar las 35 facturas emitidas y luego incluir dichas facturas en una factura recapitulativa cuya fecha de emisión tiene que ser sí o sí la fecha de final de mes.
Por lo tanto, en este caso, la fecha de operación = la fecha más cercana a final de mes donde se hubiera emitido una factura al cliente, la fecha de expedición = 29/02/2024

Con esto quiero decir que la fecha de operación de la que estás hablando no establece una fecha para la factura. La única fecha que importa en una factura y que el reglamento de facturación obliga a identificar es la fecha de expedición.

Al hilo de esto


Cuando encontráis una factura que no ha subido bien, fue rechazada por algún motivo etc... supongo que esa factura queda "retenida" dentro del ERP hasta que se arregle...


Cuando digo retenida me refiero a que no continua el circuito habitual de las facturas (grabarla en contabildad, vaya)

Lo primero que hacemos es grabar la factura antes de imprimir, enviar, etc... Esta claro que si rebuscamos encontramos algún caso en el que puede fallar. En todo el tiempo que llevamos con TBAI no hemos tenido ni un problema de estos.

Debe ser como dices. En los negocios que yo atiendo coinciden la fecha de expedición y servicio el mismo día, com lo cual no se me ha planteado el problema. Es cierto que fecha expedición fuera del mes de la del servicio puede ser problemático.

Claro. Rebuscando es que si envío 2 millones de registros sl mesdesfe varios SIF algún SIF va a cumplir xon la ley de Murphi y lo que pueda.pasar pasa. Y yo no me la quiero jugar, deberían contemplar ese remoto problema.

Vale sglorka, entonces quieres decir que en ejemplo que he puesto anterior, que nos encontramos a caballo de dos ejercicios la fecha de operación sería 31/12/2023 y la fecha de expedición 31/12/2023 verdad?

/

Según entiendo en las preguntas que han colgado la fecha de expedición siempre tiene que ser igual a la fecha del día, y hay que jugar con la fecha de operación. Al igual que en TBAI. De todas formas esperaré a que publiquen el reglamento y luego volveré a hacer la pregunta a hacienda.

Más leo sobre VeriFactu, Ley Antifraude, etc. más me preocupa la puesta en marcha, sea cuando sea.

Estos años con TicketBAI nos han servido para darnos cuenta de los cientos de problemas no previstos que puedan ocurrir, y que la gente no está preparada para algo así, aunque les demos 6 meses o 3 años.
Todavía hay empresarios que no saben lo que es un certificado digital, o que tiene que pagar por él.
Todavía nos preguntan cómo "esconder facturas", modificarlas, borrarlas, etc. pese a que la Ley Antifraude ya tiene bastante tiempo, y pese a que la Ley de Facturación prohíbe hacer desde 2003.

Ojalá salga todo bien, pero poner en funcionamiento algo así, casi de un día para otro, sabemos cómo puede acabar.

Hace unos meses a Gipuzcoa se le caducó el certificado del servidor, no se pudieron hacer envíos.
Al principio hubo días en los que simplemente no funcionaba el envío, o tardaba una eternidad.
Problemas con la caducidad de los certificados, usar el certificado que no es, gente que ni siquiera sabe si ellos son persona física o jurídica, gente que emite facturas sin recoger todos los datos del cliente, etc.

Y eso que TicketBAI solo son 3 provincias y tenemos pocos clientes. Cuando se aplique VeriFactu en toda España, va a estar divertido...

Debes volver a plantear la pregunta porque no entiendo la mezcla que haces ente hora del sistema, fecha de Internet, etc. Si tienes tiempo y la vuelves a plantear te podría dar más información.
Especifica también si el cliente es particular o empresa

Yo creo que se han liado en la respuesta de las FAQs. La respuesta de verifactu a la consulta que les planteé sobre este tema la publiqué en este foro y claramente dijeron que no habían reglas de validación que impidieran emitir una factura con fecha de expedición menor que la fecha de emisión del registro de facturación. En general, el 90% de los SIF son terminales de punto de venta y la norma general y que yo acato es que la fecha de expedición siempre debe ser igual a la fecha del día en que se emite porque no tiene sentido emitir a un cliente final una factura con fecha de ayer.
Pero los SIF de sistemas de gestión que recolectan operaciones de todo tipo, clientes finales, empresarios, etc utilizan series distintas para los clientes empresas y para los clientes particulares, de tal forma que, yo puedo seguir emitiendo facturas en la serie 1 (clientes particulares) y reservar la serie 2 para aquellos clientes de final de mes que hay que emitirles la factura resumen.
Piensa en una estación de servicio que suministra combustible el día 29/02/2024 a las 23:59:59 mediante un albarán de entrega a una flota de furgones de una empresa. Hasta el día siguiente. 01/03/2024 no va a poder emitir la factura para poder incluir todas la operaciones. Dicha factura tendrá que emitirla con fecha de expedición 29/02/2024. Aunque podría emitirla antes del 16 de marzo pero la empresa destinataria se quejaría porque diría que quiere la factura a final de mes para que le entre en la declaración de impuestos de febrero. (OJO no quiero liarla más, pero si se emite dicha factura entre el 1 y 16 de marzo dicha factura hay que declararla en el mes de febrero, no de marzo, ya que es la fecha de operación y no la de emisión, la que dicta el periodo de devengo del impuesto)

Ya estaba al tanto de lo que pusiste la otra vez. En el webinar hice la pregunta y parece que contestaron que es igual que en ticketbai. Es decir la fecha de expedición tiene que ser la actual y jugar con la fecha de operación. Todo eso que comentas en las haciendas forales te dicen que cambies la fecha de operación, pero la fecha de factura es la fecha del día. Por eso digo que esperaré a que salga la norma para volver a hacer la pregunta.

En cuanto a los clientes que reciben la factura hay que ponerle en el impreso las dos fechas, la de expedición y la de operación, que es cuando ellos se la deducen.

Eso es lo que no entiendo de la respuesta, "que podemos utilizar la fecha de operación para cambiarla". En general, el 99% de las facturas resumen de final de mes tienen la fecha de operación menor que la fecha de expedición. Eso ya es una práctica habitual.
¿ Por qué ante la pregunta clara en las FAQs "Se pueden generar facturas con fecha anterior de la fecha actual? O todas las facturas tienen que
tener la fecha del día que se generan y jugar con la fecha de operación, como hace TicketBai"? la respuesta de ellos es "Sí, es posible generar facturas con fecha anterior a la actual, a través del campo "Fecha de operación" que podrá ser distinta que la "Fecha de expedición". "

No sé qué tiene que ver la respuesta con la pregunta
¿ Tú lo tienes claro ?, si es así me gustaría que dieras tu opinión.

Si a ver, tengo tres fechas, la del propio sistema Windows, y que adquiere el ERP como fecha y hora de trabajo, la fecha de control que obtengo en Internet mediante el comando Curl y que me sirve de base para poder controlar que la fecha y hora del ERP no exceda en una diferencia de 4 minutos, en caso contrario no dejaría emitir la factura (salvo excepción de a un administrador -por si hay fallos en la captura de la hora de internet-). Espero que con esto se entienda el manejo y control de las fechas, por si al usuario se le ocurre alterar, atrasar la del sistema Windows para hacer alguna pajarraka.

Ahora bien, estando a caballo entre dos ejercicios y dada la fecha 02/01/2024 en la cual nos encontraríamos, supongamos que necesito emitir una factura que en su día 31/12/2023 no pude hacer (por motivo X -se fué la luz durante horas-) la fecha de expedición sería 02/01/2024 y la fecha de factura/fecha de operacion sería 31/12/2023, me da igual que sea empresa o particular, ya que los dos casos se pueden dar perfectamente. No se si estoy en lo cierto en cuanto a las fechas. No hay una entrega de bienes o prestación de servicio anterior al 31/12/2023 y que esta se realiza el 31/12/2023.

Espero haberlo explicado bien. ¿La verdad?.... es un maldito lio

Te voy a dar mi opinión que deberías contrastar con un asesor fiscal. A los que yo les he consultado me han trasmitido lo que te reflejo aquí.

1- Si estamos hablando de un terminal punto de venta, donde estás expuesto al público, en ningún momento deberías generar facturas con fecha de expedición distinta de la fecha en curso y haces bien en controlar la fecha del sistema y contrastarla con un servidor fiable de Internet para evitar problemas.

2.- Si estamos hablando de un ERP - BackOffice, estando en el día 02/01/2024, o estando en cualquier día entre 1 de enero y el 31 de enero de 2024, emitiría la(s) factura(s) que quedaron atrás con fecha de expedición 31/12/2023 y fecha de operación, la que se hubiese establecido en la entrega de bienes (siempre menor o igual que la fecha de expedición). Fíjate que, en ningún momento, vas a romper la cronología Fecha-Número de Factura ya que no se pueden emitir facturas con fecha superior a 31/12/2023 dentro del ejercicio fiscal 2023, entre otros motivos por que no hay más días.

Este planteamiento es muy común en los cierres de año, ya que es imposible que a 31/12/2023 puedas tener todas tus facturas emitidas (siempre pensando en clientes de operaciones recurrentes en el mismo mes natural).

Esta procedimiento se puede aplicar a cualquier final de mes a lo largo del año fiscal, siempre y cuando, te hayas preocupado de generar una serie particular para la facturación de resumen final de mes. Si aún así, has emitido una factura el día 01/02/2023 con la misma serie que otra que deberías emitir a fecha 31/01/2023, no te queda otra que emitir la factura con fecha 01/02/2023 y luego emitir una rectificativa por sustitución con fecha de emisión 31/01/2023 y fecha de operación la que tenga asignada la factura sustituida.

En ningún caso, emitiría una factura con fecha de expedición anterior al día en curso si el destinatario es cliente particular. Sólo si es recapitulativa y el cliente es particular (durante todo el mes le he emitido factura por cada operación) podría emitirle la factura recapitulativa con fecha anterior al día en curso (tiene que ser como máximo el último día del mes) por que puede ocurrir que el último día del mes sea domingo y en ese día también haya realizado una operación el cliente, entonces hasta el lunes no podré emitir la recapitulativa

Espero haber sido claro en la explicación

También puedes plantear la pregunta al correo de verifactu, siendo lo más claro posible en la pregunta y poniendo un par de ejemplos. Si la pregunta es clara te van a sacar de dudas, lo de preguntar a un asesor puede responderte según su experiencia pero puede no ser adaptable a las nuevas circunstancias. En este momento me fio más de otros cauces para el tema de facturación, creo que michos asesores están en este momento un pelin desbordados con la nueva normativa.

Según TicketBai, y lo que interpreto de las preguntas que han colgado. La fecha de operación sería el 31/12/2023 y la fecha de factura/expedición sería el 02/01/2024.

Pero bueno creo que lo mejor es hacer la pregunta a hacienda. Yo se la hice hace unos días y me dijeron que hasta que no salga la normativa no me iban a contestar. Y en la impresión de la factura tienes que indicar las dos fechas, para que así el cliente sepa como la tiene que contabilizar.

Por eso el SII de compras tiene un campo Fecha Operación, otro Fecha de Expedición y uno tercero de Fecha de Registro contable.

Un Saludo

Me han contestado desde ala AEAT:

"Buenos días:
Efectivamente se ha detectado un problema en la publicación de los links. Se ha avisado a los responsables para su subsanación. Disculpe las molestias."

La fecha de registro contable solo existe en el libro de Facturas Recibidas, es otro lío completamente, por qué en compras tienes que hacer la diferencia entre la fecha que el proveedor ha puesto a la factura (fecha de expedición) y la fecha en la cual el cliente ha recibido la factura, puede ser hasta 47 o 48 meses más tarde...

Ya he puesto que en compras. Para indicar que eso es lo que tiene que poner el cliente al contabilizar la factura y saber cuando deducirselo. Y indicar que en las emitidas cuando al imprimir la factura la fecha de factura no coincide con la de operación hay que indicarlo.

Presentación y Planteamiento
 

Antes de nada , saludar al foro y dar las gracias a todos los que han escrito, me han ayudado mucho a decidir como empezar , con la pereza que me daba.:mad::mad::)

Como soy novato en el foro , es mi primer post y os cuento como lo voy a plantear Inicialmente, modo básico y esquemático , por si le sirve a alguien o por si alguien más experto me recomienda que abandone las cervecitas urgentemente :)

Es verdad que cuando me ponga seguro pueden cambiar cosas , es solo un planteamiento incial para empezar a trabajar, no entro en los requisitos de huella,firma etc....

En principio la idea es no tocar las tablas actuales de facturas ,etc. que ya existen en mi sistema.

1.- Voy a crear una tabla nueva para guardar los registros verifactu de cada factura

básicamente tendrá:

campo que identifica la factura en el fichero de facturas
campo para guardar el xml "RegistroFacturacion"
campo para guardar el número de envío , si 0 = Pendiente de enviar.

seguro que al final tenga que añadir alguno más....


2.- Voy a crear una tabla nueva para guardar los registros de los envíos verifactu

campo con un código interno de envío
campo para guardar el xml AltaFactuSistemaFacturacion enviado.
campo para guardar la respuesta de la aeat.

seguro que al final tenga que añadir alguno más....


Cada factura que se genere usare Fact.RegistroFacturacion.ObjectToSOAP para obtener el xml y guardarlo en la tabla de los registros verifactu.

Partiendo del código de Neftali , aqui va un ejemplo de como obtener el xml con ObjectToSOAP , solo hay que meter en el Form un XMLDocument1, TOPToSoapDomConvert

Código Delphi [-]
procedure TForm4.Button7Click(Sender: TObject);
var
  ARootNode, ElemNode, NewNode: IXMLNode;
  RefId,Swdsl : String;
begin
  XMLDocument1.Active := True;

  XMLDocument1.Version:='1.0';
  XMLDocument1.Encoding:='utf-8';

  with XMLDOcument1 do
  begin
    ARootNode := CreateNode('RegistroFacturacion');
  end;


  // Factura ejemplo
  var fact:FacturasEmitidasType;
  fact := FacturasEmitidasType.Create;
  fact.RegistroFacturacion := RegistroFacturacionType.Create;
  fact.RegistroFacturacion.IDFactura := IDFacturaExpedidaType.Create;
  fact.RegistroFacturacion.IDFactura.NumSerieFacturaEmisor := '23/123456';
  fact.RegistroFacturacion.IDFactura.FechaExpedicionFacturaEmisor := '31/12/23';
  fact.RegistroFacturacion.IDFactura.IDEmisorFactura := IDEmisorFactura.Create;
  fact.RegistroFacturacion.IDFactura.IDEmisorFactura.NIF := '3333333';
  fact.RegistroFacturacion.DescripcionOperacion := 'venta de mercaderías';

    // Resto de datos de la factura....

  Swdsl := "no puedo poner enlaces   xxxxxenciatributaria.gob.es/static_files/common/internet/dep/aplicaciones/es/aeat/tike/cont/ws/SistemaFacturacion.wsdl";


  newNode := Fact.RegistroFacturacion.ObjectToSOAP( ARootNode, ARootNode, OPToSoapDomConvert1, 'RegistroFacturacionType', Swdsl, 'T',[], RefId  ); 

  XMLDocument1.DocumentElement := ARootNode;
  Memo1.Lines.Clear;
  Memo1.Lines.Add(XMLDocument1.XML.Text);
  XMLDocument1.Active := False;


  fact.DisposeOf;
  fact.RegistroFacturacion.DisposeOf;

end;

Luego al generar los envíos , aprovechar el ejemplo de Neftali para ir recogiendo los RegistroFacturacion guardados con SOAPToObject

Código Delphi [-]
procedure TForm4.Button5Click(Sender: TObject);
var
  arrayDetalles : array of DetalleType;
  RegistroAltaFacturas: Array_Of_FacturasEmitidasType;
  x : Integer;
begin
  var alta:AltaFactuSistemaFacturacion := AltaFactuSistemaFacturacion.Create;

  // Cabecera
  var cab := Cabecera.Create;
  cab.IDVersion := VersionType._1_0;

  cab.ObligadoEmision := PersonaFisicaJuridicaESType.Create;
  cab.ObligadoEmision.NombreRazon := 'Empresa pruebas';
  cab.ObligadoEmision.NIF := '11111111H';
  cab.TipoRegistroAEAT := TipoRegistroAEATType.T0;
  cab.FechaFinVeriFactu := '01/01/2026';
  alta.Cabecera := cab;


  for x := 0 to 1 do
  Begin


    // Factura
    var fact:FacturasEmitidasType;
    fact := FacturasEmitidasType.Create;


    fact.RegistroFacturacion := RegistroFacturacionType.Create;
    fact.RegistroFacturacion.SOAPToObject()  // Codigo pendiente de poner y probar , solo es para mostrar el planteamiento , pero es el contrario de ObjectToSOAP

 
   // Lista de facturas del envío
   SetLength(RegistroAltaFacturas, x+1);

    RegistroAltaFacturas[x] := fact;

  end;


  // Factura 1
  alta.RegistroAltaFacturas := RegistroAltaFacturas;




  // envío
  try
    var res:RespuestaAltaFactuSistemaFacturacion := RespuestaAltaFactuSistemaFacturacion.Create;
    res := GetsfSOAP(False, '', HTTPRIO1).AltaFactuSistemaFacturacion(alta);

    ShowMessage('Se ha realizado el envío; ' + sLineBreak +
                '   CSV: ' + res.CSV  + sLineBreak +
                '   TimeStamp: ' + res.DatosPresentacion.TimestampPresentacion
                );
  except
    on E:Exception do begin
      ShowMessage(Format('Error al realizar el envío; (%s)-%s',[E.ClassName, E.Message]));
    end;
  end;
end;

Un Saludo a todos y no me metáis mucha caña :)

Ya que tienes toda la razón....

Pues bueno formulada está la pregunta a la AEAT. Yo habiendo recapacitado y analizado entiendo lo que indicas, la fecha de operación debe ser 31/12/2024 tambien a efectos de liquidación de iva, momento de la entrega de bienes o prestación de servicios y otros asuntos y que la fecha de expedición y generación del registro sería 02/01/2024.

Si os fijais en la ultima hoja excel - Anexo_OM_RD-1007-2023(v0.5.0_2023-12-20).xlsx - Disponemos de tres campos FechaExpedicionFacturaEmisor, FechaOperacion y FechaGenRegistro.

Entiendo que en el documento factura se debiera especificar la fecha de expedición y la fecha de operación para que el cliente tenga claro como debe actuar con esa factura y que la fecha de operación debiera prevalecer sobre la fecha de expedición a efectos fiscales ya que es la que se especifica el momento de entrega de bienes y/o prestación de servicios.

Perdonad aue me he perdido un poco No sé si alguien lo ha planteado/contestado.
La diferencia entre la fecha de operación y expedición supongo que también está algo reglamentado, no creo que pueda ser más de x días des0ues dd ka de operacion o maximo al dia 15 del mes siguiente para empresarios y autonomos y dentro del mismo mes para emision a particulares, enfín supongo qir algo así como lo que se aplica para las recapitulativas con los albaranes.
Por otro lado me quedan más dudas
Que es la fecha de operación, la fecha del servicio o la fecha en que me lo pagan?
Por otro lado veo que también hay una fecha de pagos acta que tendrá otro tratamiento fiscal, no?
Vaya lio tengo. Creo que voy a hacer coincidir todas las fechas con la de expedición menos en la de las sustitutiva que hay que poner la fecha de cada tiquet, que, además esto es otro cantar, si un cliente me pide la factura sustitutiva he leído en varios foros de asesorías que hay que poner que el iva no es deducible por que ya se dedujo el tiquet, y esto lo veo una tremenda tontería, por que si me piden una sustitutiva es por que normalmente no se lo dedujeron en su momento, a no ser que necesiten el comprobante de autoria de que r3almente fue el receptor.
Aunque creo que la fecha de deducción debe ser la de operación o al menos el mes de la fecha de operación, corregidme si me equivoco.
Cuantos líos fiscales Dios, que yo soy programador y ni los asesores aclaran bien, pero yo tengo que saberlo todo. Es increible.