No vas a encontrar en el reglamento exactamente lo que buscas. El reglamento te dice muy claro lo que debes hacer en ciertas circunstancias y en otras lo deja a tu interpretación siempre y cuando no vulneres el reglamento. ¿ Dice el reglamento que la fecha de expedición de una factura tiene que ser la misma que el día en que la expides ?. No los vas a encontrar por que no lo dice. Pero sí dice lo siguiente:

Reglamento de facturación
Artículo 11. Plazo para la expedición de las facturas.
1. Las facturas deberán ser expedidas en el momento de realizarse la operación.
No obstante, cuando el destinatario de la operación sea un empresario o profesional que actúe como tal, las facturas deberán expedirse antes del día 16 del mes siguiente a aquél en que se haya producido el devengo del Impuesto correspondiente a la citada operación.

O sea, yo puede ir realizando notas de entrega a un cliente empresario durante el mes de marzo y después emitirle una factura resumen de esas operaciones antes del 16 de abril. Como debo respetar la numeración correlativa y las fechas de expedición de forma ascendente, estando a día 16 de abril emito una factura resumen de operaciones con fecha 17 de abril (no tengo facturas emitidas después del 16 de abril ). Le envío la factura al cliente y me responde al día siguiente reclamándome que la fecha de factura es errónea. Ahora ¿Cómo lo soluciono? ¿ Emito una rectificativa con fecha 17 de abril, día en el que estoy ? no debería por que sigo sin resolver el problema.
Lo que debo hacer es emitir una rectificativa por sustitución con fecha de emisión 16 de abril, para corregir la factura errónea.

En resumen, hay que respetar la cronología NumeroFactura-FechaExpedición pero como pueden haber errores, se debe poder rectificarlos, es lo que subyace en el reglamento cuando crea la factura rectificativa, eso si, sin intentar torcerlo. Si yo sé que no tengo facturas emitidas hoy ni las voy a emitir. ¿ qué problema hay en emitirlas hoy con fecha del día siguiente?

Te adjunto link de consulta vinculante realizada a la administración donde se recoge el caso de la emisión de una factura rectificativa por error en fecha de expedición.
https://www.iberley.es/resoluciones/...4-2022-1538919

Cuidado con la fecha y hora de emisión de las facturas, una cosa es el reglamento y otra el conbtrol verifactu que va a estar por encima del reglamento. Si emito una factura hoy con fecha de mañana, a parte de que no puedas hacer ninguna ya con fecha/hora anterior a la emitida tampoco la podras transmitir a hacienda hasta llegada la hora y fecha, se corre el rieso de que te la rechacen por fecha/hora incorrecta. Ya habeis visto en el proyecto de la OM que los programas deben estar como máximo 1 minuto de margen de diferencia con la hora real. Con lo cual, me temo que van a controlar que no haya horas/fechas futuras.

Bajo mi punto de vista, Verifactu no puede impedir que se haga algo que sí permite el reglamento de facturación como queda constatado en la consulta vinculante, que es emitir facturas rectificativas con la
fecha de emisión correcta cuando la fecha de emisión fue incorrecta en primera instancia. El apunte que haces respecto de no poder emitir facturas con fecha anterior a una factura ya emitida es cierta ya que debemos mantener una cronología entre número de factura y fecha de emisión. Pero debes tener en cuenta que cuando se trata de una factura rectificativa, herramienta creada para poder solventar errores en las facturas emitidas, no debería extrañarte que existiera la posibilidad de rotura de esta cronología. Además, ten en cuenta que la OM en ningún momento habla del control de las fechas de expedición de facturas, sólo habla de momento en el que se realiza el fechado del registro de facturación

f) En cualquier caso, el obligado tributario usuario del sistema informático deberá
asegurarse de que la fecha y hora empleadas por dicho sistema informático para fechar
los registros de facturación son exactas, con un margen máximo de error admitido de un
minuto.

2.º La fecha y hora de generación del último registro de facturación generado no es
superior en más de un minuto a la fecha y hora actuales que se utilizarán para fechar
el registro de facturación a generar

por lo que da a entender que se está refiriendo a los campos
FechaGenRegistro, HoraGenRegistro y HusoHorarioGenRegistro del objeto RegistroFacturacion y no del campo FechaExpedicionFacturaEmisor del objeto IDFactura del objeto RegistroFacturacion

De todas maneras, todo esto que hablamos lo podremos probar cuando habiliten el endpoint de recepción de facturas. ¿ Que no te permite que la fecha de expedición sea distinta que la fecha actual ?, pues ya sabes a qué atenerte, no puedes dejar libre el campo fecha emisión en tus facturas por que no vas a poder rectificarlas si se equivocan.

En cuanto al fichero individual de la factura, no el que se subirá luego a Hacienda



Rellenamos el campo HoraGenRegistro con la hora real de creación pero pasará algo si la subida a la AEAT se hace dentro de 10 minutos así lo han requerido?

Sí, pero esto incumbe claramente al usuario operario del sistema (nuestro cliente), art. 7 f), y únicamente en modo «bajo requerimiento» (el art. 3 exime del 7 f), 7 h) y 7 i))

comando curl fecha/hora
 

Aquí os dejo un comando curl para los que querais asegurar la fecha y hora de sistema esten correctas antes de cada factura, ya que si lo dejais en mano de windows algún listillo puede desactivar la sincronización.
Ya lo habia subido anteriormente pero el anterior ejemplo tenia en cuenta la zona horaria de la ip y me a hecho alguna putada, ésta es la correcta:

Añadido al mensaje #2 del hilo, donde está la recopilación de códigos útiles.

Calculo de la Huella
 

Estoy intentando generar la huella , ¿ Debo quitar espacios en blanco entre nodos y saltos de línea antes de enviar la huella o no ?
¿ Donde puedo hacer la prueba para ver si la huella que genero es correcta ?

Buenas,
cómo se calcula la huella del registro de facturación actual antes de enviarlo por GetsfSOAP ?

Muchas gracias

Negativo, debes calcular la huella desde el inicio del nodo <sum:RegistroFacturacion> hasta el fin del nodo </sum:RegistroFacturacion>, donde las etiquetas de inicio y fin deben estar incluidas. Ojo no se calcula la huella del fichero completo, entre otras cosas por que la huella debe estar incluida en el fichero y no podrias calcularla incluyendola antes.
-No puedes quitar ningún caracter, ni espacios, ni tabuladores, ni saltos de linea ni retornos de carro, ni ningún otro caracter especial que esté incluido entre esas 2 etiquetas.
-Para hacer pruebas en alguna web hay que tener en cuenta que los caracteres especiales a veces no se pegan correctamente, con lo cual puedes copiar el nodo en otro fichero para hacer la prueba desde fichero en vez de copiar y pegar, pero recuerda que un salto de línea, por ejemplo después del último caracter, te va a cambiar totalmente el cálculo de la huella (sha256).
-La duda quedaría sí después de la etiqueta de cierre del nodo </sum:RegistroFacturacion>, hay un salto de línea o retorno de carro, ¿habría que cogerlos o no para el cálculo?, en este caso lo que algunos hemos hecho es pegar el inicio del siguiente nodo al final de este y quitar todos los caracteres que poudieran haber entre ambos y nos ahorramos esa duda.

Aquí te dejo una web para que puedas probar, tanto desde fichero como con copiar y pegar
https://hash.online-convert.com/es/generador-sha256

Me refiero a cómo accedo al XML antes de enviar y poder calcular el hash del nodo RegistroFacturacion.

Perdón por la pregunta, es probable que sea absurda pero solo consigo el XML cuando envío y capturo el evento HTTPRIO1BeforeExecute

Código Delphi [-]
var res:RespuestaAltaFactuSistemaFacturacion := RespuestaAltaFactuSistemaFacturacion.Create;
    res := GetsfSOAP(False, '', HTTPRIO1).AltaFactuSistemaFacturacion(alta);

Muchas gracias ermendalenda

De absurda nada. Estoy en el mismo caso no se como acceder al XML antes del GetsfSOAP para seleccionar el nodo y calcular el hash del nodo RegistroFacturacion. Si genero el XML manual no tengo problema en acceder y calcular el hash

Por favor, ¿Cómo y de donde me puedo descargar la Orden Ministerial (OM)?

La OM no está publicada aún. Solo existe un borrador en fase de audiencia publica: https://www.hacienda.gob.es/es-ES/No...aAbiertas.aspx

Hola a todos.

Vamos a empezar a trabajar en esto de verifactu. Ya hemos desarrollado para TicketBAI, así que el cambio no es tan grande. Lo primero que veo es que hacienda ha lanzado todo esto pero lo tiene un poco verde, al menos la información que tenemos, seguramente hay algunas empresas (las de siempre, ya ha pasado en otros desarollos) que tienen más información.

He estado leyendo el foro, y veo que hay un poco de dudas sobre la fecha de factura, según TicketBAI (Hacienda te dice que también según el reglamento de facturación), la fecha de factura tiene que ser igual a la fecha del día que se genera, ni antes ni después. Hemos tenido varias discusiones con clientes y hacienda y eso es lo que te contestan. De hecho los programas que han hecho en hacienda para los que hacen pocas facturas no se puede modificar la fecha de factura, otra cosa es la fecha de operación.

Una consulta muy recurrente que hacían los clientes es, Es que yo hago las facturas el viernes con fecha del lunes para así tenerlas preparadas, pues no se puede. Nosotros lo que hacemos es generar una prefacturación y luego el día que quiere hace las facturas, pero siempre con la fecha del día que se genera las facturas.

Una diferencia que he encontrado respecto a TicketBAI y el SII es que no hay que indicar si el desglose es a nivel de factura o a nivel de operación. Me imagino que por eso las empresas que hacen el SII no tiene por que hacer todo esto. En las Haciendas forales es al revés, el que entra en TicketBAI ya no tiene que enviar las facturas emitidas al SII.

Otra diferencia que veo es que las anulaciones hay que tenerlas en cuenta en el encadenamiento de las facturas, en TicketBAI.

Me llama la atención toda la información que hay que enviar del sistema informático. También veo que respecto a TicketBAI el mayor cambio y del cual no hay mucha información es el tema de los eventos. Entiendo que todo esto es por no obligar a todo el mundo a entrar en VErifactu, como han hecho en las forales que todo el mundo (salvo pocos casos) tienen que entrar en TicketBAI.

Último día de consulta del proyecto de la OM
 

Hola, me han recomendado enviar una consulta para "quejarse" de las restricciones sobre los certificados de envios. Que va a ser un gran problema.
Por si quereis y os interesa quejaros, hoy es el último día para quejarse:
observaciones.proyectos@aeat.es

Nosotros tenemos algo hecho, pero más que nada en pruebas.
Hay muy poca información, la que hay es muy poco concreta, nada donde se pueda probar,...
Yo creo que para hacer algo "es serio" no sirve. Sí para ir probando cosas sueltas.



Lo que ya he oído y leído en varios sitios (y tiene bastante sentido), es que en la práctica quieren que hagas VERI*FACTU (servicios web destinados al envío voluntario de registros de facturación), porque los requisitos de no hacerlo complican tanto el sistema que creo que casi todos los programas van a optar por esta opción. Estaba bien explicado en un video (charla) a la que hicieron referencia hace unos días (de una empresa privada) en el foro, pero no encuentro el link para ponerlo.

El problema es tener que obligar a todos tus clientes que se metan en VeriFactu, aunque es una opción a considerar y así se te olvidas de los eventos, inspecciones, etc....

Hola,

Gracias por avisarnos, Ermendalenda.

Acabamos de enviar email con el texto:
A ver si tienen en cuenta el tema.

Saludos

Perfecto.
Gracias a tí