Prefacturacion, Proformas y Borradores de facturas (Faq Verifactu)
 

Aquí os dejo, sacado de las FAQS de Veri*Factu
No sé si este tema es mejor en temas legales.

Resumen general
 

Aquí os dejo un resumen general que al menos a mí me sirve como guia.

Espero que si hay algún asunto que no "cuaje" me lo hagais saber.
Con respecto a la PREFACTURA creo que ya lo he expuesto varios artículos mas abajo.


***********************************
Veri*factu vs dual veri*factu
Breve resumen (S.E.u.O.)
***********************************

1. Consideraciones iniciales.

a) Se excluyen al menos de momento de la obligación de usar veri*factu las empresas acogidas al SII.
b) Si el sistema informático "puede usarse" en alguna instalación como NO VERIFACTU entonces ha de
cumplir las normas NO VERIFACTU inclusive en las instalaciones que se acojan a VERI*FACTU. Es estos
programas se les denomina modelos duales.
c) Si el sistema informático está limitado a VERI*FACTU y en ningún caso podría ser usado con las normas
de NO VERIFACTU entonces se le conoce como SOLO VERI*FACTU.
d) Si el sistema informático alberga varias empresas (formen grupo empresarial o no) y al menos una
de ellas es NO VERIFACTU entonces el sistema ha de considerarse como capaz de cumplir NO VERIFACTU y
debe cumplir las normas de NO VERIFACTU. Es decir, deberá garantizar el productor la NO alterabilidad
de la información de todas las empresas y usar un certificado para cada factura expedida.
Aunque alguna de las empresas se acoja a veri*factu.
e) Cuando se expide una factura por error y no se ha cobrado, ésta se puede corregir enviando un registro de
anulación. O bien si es una factura de un trabajo que se pensaba hacer y no se termina de realizar.
No se trta de una rectificativa sino una factura que nunca debió existir. P.e. error al expedirla a un
cliente incorrecto. ¿ Cómo procesar ? Después de haberla declarado en el SIF se expedirá un
registro de factura anulada también en el SIF. Los dos se comunicarán a la AEAT.
Se creará otra factura con los mismos contenidos y cantidades negativas en una serie específica para
facturas anuladas. Las facturas de esta serie no se registran en el SIF. En cambio las dos se
llevarán al registro de iva contable con lo que no habrá descuadres ni en el modelo 300/330 ni en el 347
en cambio se verá en el registro de facturas emitidas y en los extractos del cliente. Tampoco habrá descuadres
de existencias en almacén.
f) El sistema informático o DISPOSITIVO debe tener instalado un CERTIFICADO DIGITAL. O bien se usará en
los modelos VERI*FACTU para comunicar a la AEAT los envíos o bien si se trata de un modelo NO VERI*FACTU
se usará para certificar cada documento expedido y posteriormente poder suministrar a la AEAT los requerimientos.
g) Obligación y entrada en vigor. El 29 de Julio de 2025 cualquier sistema informático que se venda debe
cumplir las obligaciones veri*factu y no veri*factu. El 1 de enero de 2026 todos los clientes deberán
tener adaptado su sistema para cumplir dichas normas.
h) El diseño del código QR que se imprimirá en cada documento expedido está definido en un PDF con nombre
DetalleEspecificacTecnCodigoQRfactura_BORRADOR.pdf con fecha 02/10/2024
i) Hay unas FAQ de la propia AEAT que se pueden aglutinar en un único PDF. Eta es la dirección
https://sede.agenciatributaria.gob.e...00dc381e0aRCRD

2. Sistema VERI*FACTU.

Normas generales.

Esquema de funcionamiento
2.1. Se expide una factura (recapitulativa, rectificativa por modificación o sustitución, contado,
simplificada, canje) o bien se anula una factura. Se añade un registro en una tabla (o varias es elección del diseñador)
contenedora de datos tales como ...
HASH del registro actual
HASH del registro anterior (siempre que no sea registro inicial)
FECHA del documento
FECHA del documento anterior
FACTURA compuesto por serie mas nº de factura
FACTURA anterior
FECHAHORA del registro con formato U.T.C. (El sistema no podrá enviar un documento posterior
con fecha/hora posterior)
... y otras especificaciones del documento que se envía, están en la documentación
de la AEAT.
La tabla debe poder ser consultada en hacia adelante y hacia atrás y poder ser verificable
posteriormente en cualquier momento.
2.2. En el caso de la AUTOFACTURA o facturas de compra emitidas por el destinatario o cliente
la AEAT indica que es obligación de registrar en el SIF la factura del proveedor si éste le ha
indicado por escrito que así debe ser. Quiero imaginar que el certificado usado para comunicarlo a la AEAT es el
del cliente y no el del proveedor, sino sería un desastre. La cabecera del envío en este caso
imagino que es la del proveedor y que deben diferenciarse de las facturas expedidas por nuestra entidad,
comunicándolas por separado, en otro tramo. Al tener que emitir desde distintos titulares habrá
que utilizar los datos fiscales del proveedor como cabecera del declarante.
2.3. Si hay pendientes de envío a la AEAT 1000 registros habrá que enviárselos a la AEAT.
O bien si ha pasado un plazo de 2 horas habrá que enviarle los registros que haya acumulados,
si los hay.
Se genera un evento que identifica el envío a la AEAT.
Los tiempos de espera entre envíos deberán ser superiores al menos a 60 segundos.
Si el envío ha fracasado por causas diversas (falta de conexión a internet, el sistema está parado,
hay un determinado fallo) hay que registrarlo como evento y al enviar de nuevo la información a la
AEAT hay que indicar que hubo intentos previos de envío.
2.4. La AEAT puede responder de tres formas distintas :
2.3.1 Envío aceptado.
2.3.2 Envio aceptado con errores.
2.3.3 Envío rechazado.
En los tres casos se refiere a cada factura enviada no al conjunto del envío.
En cualquier caso los documentos rechazados deben volver a enviarse como alta pero como subsanación.
Se genera un evento en la tabla de eventos para indicar lo sucedido. Registro incidencia.
2.5. En la tabla de facturas o registro SIF hay que crear un nuevo registro con los datos de la factura
que se vuelve a enviar. Esto es para no perder el encadenamiento anterior.
2.6. Eventos
Consultar tabla de eventos definida por la AEAT. (L1E, L2E, L3E, L4E) enla hoja de cálculo
DR-Facturacion-VeriFactu-OM_RD-1007-2023-BORRADOR.xlsx última revisión 02/10/2024

3. Sistema NO VERI*FACTU.

Normas generales.

3.1. Es obligatorio que el productor del software garantice la integridad de los datos y la no alterabilidad
de los mismos así como su conservación durante al menos un plazo de 5 años.
3.2. No hay obligación de transmitir los registros a la AEAT.
3.3. Al igual que en VERI*FACTU el funcionamiento es similar en lo que toca a los registros de la tabla
de SIF. Con la salvedad de que hay que firmar cada registro con un certificado digital.
3.4. Debe existir una tabla de requerimientos de tal forma que cuando la AEAT solicite información
de los registros SIF se le pueda transmitir. Debe quedar registrado en dicha tabla los requerimientos.
4.4. La tabla de eventos también ha de ser firmado cada registro con el certificado digital.
4.5. Es también necesario expedir el código QR en las facturas al igual que en VERI*FACTU aunque esto
no sirva para verificar si la AEAT tiene la factura registrada. Sirve para comunicar que el
emisor ha hecho una factura y cual es su código. Lo veo algo innecesario pero así se expone en
las FAQ de la AEAT.
4.6. Período mínimo de conservación de los registros 5 años. Se pueden exportar los registros a medios
externos pero nunca dejando huecos en el registro sino exportar desde el comienzo hasta la fecha
que se defina. Los registros exportados deben ser legibles y no alterados y guardados por 5 años.

4. Trazabilidad y eventos.

4.1. Todos los registros tendrán la posibilidad de ser exportados para consulta posterior.
4.2. Habrá procedimientos automáticos que se encargan de verificar en el sistema que no se ha roto
la cadena de los registros SIF. Se hará por tramos y fechas. En todo caso se creará un evento
de comienzo de verificación y de final de verificación. Si se encontrase alguna anomalía hay que
indicarla también en el registro de eventos.
4.3. Aunque no se indica nada al respecto sería conveniente tener una herramienta gráfica para poder
verificar el registro sif. Es importante que la salida esté ordenada tal y como se ha enviado a
la AEAT y también en orden inverso.

5. Si la empresa dispone de sistemas separados que produzcan facturas se considerará cada uno como un centro
productor de sif y deberá llevar sus registros por separado.

6. Si no he comprendio mal se reduce a verificar el registro anterior antes de que se inserte el nuevo
registro en la tabla verifactu. Anteriormente eran los 5 anteriores.

Hola, muchas gracias por el resumen detallado, la unica parte que me genera dudas es este punto, se puede realmente efectuar asi la correccion, esque revisando en los diferentes post en los que se mencionaba esta operativa, ha habido varias formas de proceder, por ejemplo genrar una rectficativa R4 al cliente incorrecto y luego una F1 al destinatario correcto.

Gracias por el resumen, viene bien hacer un copia pega para tener el Doc a mano para el que necesite explicaciones.
Si me permites te dejo unas cuestiones que me parecen erroneas o dudosas
La anulación está permitida si no se ha entregado al cliente copia, o sea, se ha detectado em el momento, como es un poco a la suerte, normalmente no va a pasar nada, pero existe el riesgo de que la factura anulada (en papel o pdf o facturae, aparezca declarada por el cliente), con lo cual se detecta un incumplimiento del reglamento. Es culpa del desarrollador, No si tiene la opcion de rectificativa, pero si no lo tenemos claro, las instrucciones de que debe hacer no deben ser nuestras pero sí ofrecer las herramientas necesarias para la situación, hay que hacer una rectificativa por sustitución, pero... las facturas por sustitución a veces es incompatible con otras situaciones, por ejemplo, en Facturae hay organismos que no la aceptan, en este caso te aconsejo hacer abono y reemisión .
El emisor de la factura debe dejar como última posibilidad las anulaciones y lo tiene que tener muy claro.
Ayer salió que para las personas fisicas a mediados de 2026

Esto solo es obligatorio para NO Veri*Factu , entre otras cosas por que no es obligatorio para VERI*FACTU guardar los registros, mira el detalle de la orden ministerial las exclusuiones de algunos apartados para VERI*FACTU

El proveedor te tiene que dar por escrito que actuas en su nombre, entonces puedes enviar en su nombre, en el esquema(Si no recueerdo mal) hay un bloque que hay que indicar los datos del tercero (El comunicante)

Este tiempo de 60 segundos es por defecto, pero no sé si te pueden enviar un [t]<60

El el caso de Envio aceptado con errores, existe una excepción en el reenvio y subsanaciones, es el de tiempo, si ha pasado m hayas de los 120segundos(tiempo que varia segun [t]), no es necesario reenviar, pero es aconsejable tenerlo en cuenta para si ha pasado el tiempo indicar que se ha enviado como incidencia(Pero no reenviandolo)
Por otro lado, puede darse la situación de que te hayan aceptado un envio que no se pueda subsanar, ya que le has puesto una fecha anterior y es erroneo, como los indices de subsanación contemplan la fecha(mirar configuracion QR), existen 2 opciones:
- Si te lo han aceptado tienes que hacer anulacion y emitir el correcto
- Si no te lo han aceptado tienes que emitir anulacion sin registro previo



Ok, pero no le des consideración de factura, es un apunte.



Saludos

Buenos matices
 

Estos matices están muy bien. No coincido con uno, los demás están a mi juicio bien.


En el caso de las anuladas yo llevaría las dos al registro de iva, una se anula con la otra. En este caso el registro de iva no tendrá huecos y en los modelos 300 no tendrán variaciones. Tengo dudas si en el modelo 347 deberán de ir en el futuro. Creo que no se ha aclarado aún.

Lo único es que en el mayor del cliente aparecerán las dos facturas y habrá que justificárselas.
De todos modos el 300/330/347 se prescindirá de ellos en breve, ya no servirán para nada.

Sí están condenados a desapareecer.
Para 347, la corrección que haces emitiendo una "factura" que no se comunica a VERI*FACTU tienes que usarlo para recalcular los 347 y hacer una complementaria del 347 en caso de que los 2 clientes en cuestión rectificados (El erroneo y el correcto) cambien el estado, por ejemplo que a raiz del cambio pasen a que en su momento estuvieran obligado a declararlo, que siguiendo estando obligado a declararlos hayan cambiado el importe o el caso 3 que dejen de estar obligados a declararlos. Dado el lio, creo que en los cambios de ejercicio las anulaciones no son muy recomendables, mejor abono y reemision (si el emisor y el cliente lo acueerdan claro)
Recordad que algunas veces las complementarias conllevan a otros requerimientos para ampliar la información de la AEAT.

Punto e.
 

Entonces , para esos casos , se podria:
1-> Realmente no se entrego al cliente, realizar una anulacion de la factura cara a verifactu e imprimir esa factura con los totales a cero , reflejando bien visible que esa factura esta anulada.
2-> No sabemos si el cliente la recibio ,emitir una factura de abono,de por ejemplo devolucion de materiales y asi poder enviarsela al cliente si la recibio.
3-> Destinatario erroneo:
a) Teoricamente cara verifactu se podra subsanar para cambiar el destinatario, entonces generariamos un alta de subsanacion y reimprimiriamos la factura con los datos correctos.
b) Generariamos una factura de abono F1 con las cantidades en negativo al destinatario anterior y otra F1 con los datos del que si es correcto.
c) Anulacion de la incorrecta Y F1 de la correcta.


Sigo con dudas, soy muy duro de mollera, lo siento.

Subsanar NOOO, Recuerdo: han reconocido que fué un error de ellos (HUMANO) contestarme eso.
El destinatario es parte del registro de facturacion con lo cual no es subsanable,

Ok,Gracias por contestar, punto 3-a eliminado, ahora tengo que eliminar el resto...:D:D:D

Si lo de f1 negativa y positiva no es lo que dice el reglamento.
Realmente lo que tienes es que emitir una rectificación por sustitucion en 1 o en 2 pasos.
Pero hablando con la asesoría y dao el lio que tienen para adaptarlo con facturae, no creo que te pongan pegas hacerlo como dices. Y más que el iva está correctamente declarado.

Una gran cantidad de mis clientes seguro que pasan a entregar la mercancía con un albarán y una vez que no haya ningún cambio en el servicio proceder a imprimir la factura, subir a Verifactu y enviarlas por mail a sus clientes

duros de pelar
 

Como diría un viejo rockero, "duros de pelar", jejejeje


Yo no cambiaría la factura original, tiene datos y hash y encima se han enviado parte de esos datos.
No recuerdo ahora pero por algún lado leí que había que hacer una serie paralela solo para esto, para complementar las facturas anuladas.
No tiene mayor importancia esa serie puesto que está justificada.

Correcciones
 

Acabo de tener una charla con un asesor fiscal y corrigo lo siguiente :


Tanto la factura anulada así como la factura complementaria a la anulada en una serie específica no se van a subir a los registros contables ni al registro de iva aunque en el registro de iva haya huecos.
Por las siguientes razones :
a- La AEAT ya es conocedora de la factura anulada y del número de factura con lo que los huecos del registro
son verificables.
b- La serie especial complementaria de las facturas anuladas se justifica con las propias facturas anuladas y no es necesario registrarla contablemente.
c- En los extractos contables no deben ver movimientos que nada tiene que ver con ellos.


Un saludo.

Ok
Es que era raro.
Si ya admites la anulada, los movimientos internos que hagas para regular stock podrán ser válidos, pero en contabilidad es verdad que esta la cosa chunga, y menos poner que es una factura.
Lo que veo que este tema es un pelin más wctenso de lo que explican en la charla por los escenarios distintos que se pueden dar .
Es posible anular registros de facturas ya declaradas? Yo creo que sí, entonces irremediablemente para la próxima declaración hay que hacer un movimiento contable en negativo, llámese x.

duda
 

To tengo una pregunta.


Si hago una factura a la 10:00 de la mañana ... que es lo que me impide enviarla a hacienda a las 17:30h.


Lo digo xq yo no guardo en nigún sitio la hora en la que emito la factura, y pienso, como van a saber los de la AEAT que se la dí al cliente, ( *** o no, xq se la puedo enviar x correo 2 días después ***), la hora en la emiti la factua.

duda
 

Alguien se cree, que un chino, te va a dar, un ticket con un QR como que ha pasado por la AEAT., estos de hacienda flipan.

Hora de envío
 

La norma indica lo siguiente :


Al llegar a 1000 documentos debes enviarlos. Si no has llegado a 1000 en un plazo máximo de 2 horas debes enviar lo que tengas.
La excepción es que no tengas comunicación con la AEAT o cualquier otro motivo de fuerza mayor, como que se corte la corriente antes de enviarlos, o un fallo en el router, switch, etc.

En este último caso debes generar uno o varios eventos y cuando envíes datos al registro has de indicarle el porqué no has podido enviarlos antes si es que no has cumplido la norma.
Las sanciones a priori son sustanciosas. Supongo que al principio harán la vista gorda. Pero que la AEAT sea benévola con el incumplimiento es otra cosa.

Saludos.

Que remedio
 

Que remedio les queda. No hay otra.
A los chinos también se les sanciona y en determinadas ocasiones se les cierra el negocio.
Saludos.

En el qr que entregas al cliente esta la fecha de emisión que coincide con la que tiene que tener en el xml, otra cosa es la fecha de generación del xml. La norma dice inmediatamente, eso te lo impide.

Creo que te has liado.
Hay que cumplir enviar cuando te diga el parámetro [t] que te retornan, por defecto 60 segundos. Pero si tienes los 1000r3gistros antes de ese tiempoos tienes que enviar también.
Lo de las 2 horas no se de donde lo sacas, supongo que será el tiempo máximo que te pueden devolver en [t] Creo recordar, pero no nos liemos

La norma
 

La norma dice que debe generar un registro (llamémosle tabla paralela de verifactu) inmediatamente a la expedición del documento. De ahí la necesidad de hacer prefacturas en el caso de una factura de venta y generarás la factura cuando la prefactura esté lista. La prefactura no es un documento válido ni el número de documento ha de corresponder con el de la factura. Otra cuestión son las facturas simplificadas o tickets, estos deben ser generados en el momento.

Cuando generas un documento debes añadir el susodicho registro en verifactu o como quieras llamar a la tabla.
Y ese si que es inmediato, guardando en el registro de la tabla una fecha-hora en formato UNC.
Pero desde que tengas ese registro hasta que lo envías a la AEAT puede ocurrir lo que ya le he comentado en el post anterior.
Espero haber sido claro. :)

Saludos.

2 horas
 

Yo creo haber leído que debes enviar lo pendiente si en 2 horas no llegas a los 1000. Es mas fue una discusión pasada en este mismo foro.
Y de los 60 segundos no he hablado, eso es otra historia.
Pero puedo estar equivocado. Esto estuvo cambiando día a día así que ya no aseguro nada.
¿ Tienes algún link para afirmar que lo de 2 horas no es así ?
Me gustaría saberlo porque estoy en plena faena con lo de veri*factu y NO veri*factu y quiero acabar cuanto antes con esta programación infinita.
Gracias.

Bueno realmente demostrar lo que no es con un Link más bien será al contrario, dime donde has visto lo de las 2 horas

Buff, creo que tienes liado conceptos o no te entiendo muy bien
Como que el número de factura no tiene que coincidir.
Por otro lado cada uno trabaja según tenga el desarrollo, si tu trabajas con números temporales pues ole, pero eso cada uno...

siguen las 2 horas
 

Como te he dicho, en este mismo foro.
Supongo que lo de linkedin fue problema del corrector.

http://www.clubdelphi.com/foros/showthread.php?p=556357
Ahi puedes buscarlo.


De todos modos lo que realmente me interesa es la Ley actual no un comentario de un foro, eso es solo una aportación personal.
Si tienes un link me gustaría verlo, para cambiar mi programación.
Saludos.

en la reunión virtual del otro día comentaron lo de los 60 segundos o 1000 registros , lo que se cumpla antes

sacado del BOE que sacaron con la orden ministerial:
2. Los sistemas informáticos «VERI*FACTU» deberán implementar un mecanismo de control de flujo basado en el tiempo de espera entre envíos, el cual tomará inicialmente el valor de 60 segundos, y en el número máximo de registros admitidos en cada envío.

Paso de discutir
 

Deberías leer los comentarios antes de tomar conclusiones precipitadas, con todos mis respectos ehhh.
LA PREFACTURA ES UN DOCUMENTO AL QUE A LA AEAT LE IMPORTA UN PIMIENTO. PUEDES HACER LO QUE QUIERAS CON EL. NO ES NECESARIO QUE SU CÓDIGO COINCIDA CON EL DE LA FACTURA QUE VAS A GENERAR. Eso es lo que he dicho. Tengo muy claros mis conceptos. Tan claros que paso de discusiones estériles. Te lo digo sin ningún tipo de acritud.

Entiendo que los que participamos en el foro lo hacemos desinteresadamente, al menos ese es mi caso.


Un saludo a todos.

Bueno, atendiendo a la pregunta a ver si soy capaz poniendo ejemplos:

Caso 1
Emites una factura, evidentemente tienes que meterle el QR. En el QR solo está la fecha de emisión, con lo cual puede dar a pensar, lo mando cuando quiera que no se vana a enterar... Pues hay muchas posibilidades de que se enteren que estas operando así. Por que algún cliente va a leer ese QR y Veri*Factu pondrá en marcha el cronometro de cuando la envias e irá viendo que siempre mandas tarde sin marcar como incidencia, o da igual, si lo marcas todo como incidencia también malo. Salta la alarma
Caso 2
Emites una factura a las 10 y no se la entregas al cliente hasta las 18:00 y no la transmites. Entre las 10:00:01 y las 17:59:59 emite 1 o varias facturas más (Que estan encadenadas con la que no has entregado), e imagina que esa si la mandas, pues detectan que tienes un hueco de encadenamiento de X facturas. Salta la alarma.


En resumen: Factura emitida, factura enviada,

Añado un par de cosas:
Si generas el xml con la fechahorauso correcta y la mandas mas tarde tambien PIIII (Alarma) .
Si emites pdf/papel/Facturae, lo lógico es que vaya con la hora de emision y que envies verifactu no te libra de un posible requerimiento de todas las facturas/tiquets/anulaciones/Rectificativas Completas (Con todas las lineas en un formato legible etc). Con lo cual pueden comprobar tambien que la hora de entrega al cliente no coincida con la de generación, si decides generarlo unas horas después.

Como ves no es muy aconsejable hacer lo que dices por que van a disponer de herramientas para detectar precisamente esas cosas. Y ten por seguro que ahora los inspectores iran con su tablet o movil, te pediran la factura o tiquet, tendran su programita donde leen el qr y detectaran cuanto tardas en enviarla. O simplemente con el mismo qr lo leen varias veces hasta que esté subida.

Otra cosa es que estes trabajando sobre temporales, como en algunos casos hacemos muchos. y cuando terminas es cuando lo generas todo, el documento para el cliente, el qr los encadenamientos etc. eso si está permitido siempre que cumplas el reglamento de facturacion y lo emitas dentro de los margenes de tiempo desde la fecha que entregas la mercancia o servicio etc..

Error 2004
El valor del campo FechaHoraHusoGenRegistro debe ser la fecha actual del sistema de la AEAT, admitiéndose un margen de error de: 120 segundos.

Hola,

Tengo unos 150 bazares chinos como clientes en TicketBAI.
Y todos ellos emiten todos sus tickets con el correspondiente QR de TicketBAI.

Mis clientes chinos son mucho más cumplidores que la media del resto de clientes.

Saludos

justo iba a comentar que los compañeros que ya han instalado ticketbai podrían dar fe que al final todos los comercios han implantado su tpv con su QR y su subida casi inmediata a la hacienda vasca, y han seguido trabajando con normalidad

Por Aclarar
 

Hasta donde entiendo, y me he comido toda la documentacion :eek::eek:, hasta el momento.
En el momento que asignas el numero de factura y permites su impresion o envio al cliente(Crey que hasta su impresion en pantalla por lo de enviar capturas...), has de comunicar a hacienda por medio de verifactu los datos de esa factura, para cumplir con la ley tanto anti fraude, como la de crea y crece(+Cuando toque), puesto que segun su entendimiento del sif, has de generar el registro para enviar a hacienda y el de tu factura interna a la vez, ello quiere decir que dede el momento de "Crear" la factura has de enviar en menos de 120".

Por cierto lo de los [120 segundos] es un parametro que tiene pinta que según el numero de incidencias que tengan lo ampliarán o no.
Ya que en el documento de errores el "Error 2004" es así: El valor del campo FechaHoraHusoGenRegistro debe ser la fecha actual del sistema de la AEAT, admitiéndose un margen de error de:

Y Cuando se envia fuera de estois 120 sí te devuelve lo de los 120Segundos.
El valor del campo FechaHoraHusoGenRegistro debe ser la fecha actual del sistema de la AEAT, admitiéndose un margen de error de: 120 segundos.

Yo creo que no van a tener que ampliarlo pero no nos esperemos gran cosa.
Creo que habrá que estar pendiente si lo van cambiando.

Llevas razón no había leído bien lo del número de factura
Disculpa

Estoy contigo para lo de imprimir o enviar al cliente.
Ahora bien, la asignación del número de factura, ¿dónde has visto que debe ser en el mismo momento?

Sí, el registro debe contener este número (y debe cumplir las normas, ser monotónico etc.)
Sí, hay sistemas que van a hacer las dos operaciones al mismo momento por razones de sincronización (multi-tareas, serialización, transacciones, llamadlo como quieren). Aunque solo es una opción operativa.

Pero entiendo que puedes perfectamente asignar los números con anterioridad, presentar las pre-facturas con los números ya puestos (el registro sin generar), y cumplir; emitiendo luego los registros en orden en el momento de imprimir o enviar.

Estoy de acuerdo, siempre que , en el ultimo momento el usuario no decida cancelar una de las no impresas, y se genere un hueco...:D, a partir de ahi no se, usemos la imaginacion de que puede llegar a pasar.

Un programa conforme no puede permitirlo. así de sencillo. :D
Un usuario podría cancelar todas las pre-facturas; o las últimas; pero no podrá cancelar una (si no es la última).
Y evidentemente, el programa deberá ajustar el contador de la próxima factura para que estas pre-facturas que no llegasen a imprimirse, no se tienen en cuenta.

Buen foro
 

Disculpas no aceptadas porque no hubo ofensa.
Simplemente que después de hablar con un cliente cojonero leí tu comentario, nada mas.
Eres un gran colaborador y participante. Personalmente me has solucionado mas de una dificultad.

Todos dedicamos tiempo por imperativo técnico a leer sendos foros y a colaborar cada cual según sus circunstancias. Y a veces perdemos las "cifras".
Una de las pocas cosas útiles que todavía perduran en internet son foros como este en los cuales se puede obtener información muy valiosa. Y que dure !


Saludos !

Hola, si ,si completamente de acuerdo, prefacturas con una numeracion independiente, la cuestion es que al gnerar la factura para imprimir, ya "Es" Una factura que hay que comunicar en menos de 120" o indicando incidencia.

Vuelta a prefactura
 

El concepto de prefactura/borrador de factura/etc.etc no es mas que un espacio donde puedas aglutinar albaranes hasta ver el resultado. ES AL VALIDAR la prefactura cuando se crea una factura (documento distinto) con movimientos contables, cartera y un nuevo registro en la tabla verifactu o como quieras llamarla. La factura generada es un nuevo documento con su fecha-hora del momento de creación y que se lleva dicha fecha-hora al nuevo registro de verifactu. La factura y el registro en verifactu coinciden. El documento prefactura en este momento ya no existe. No importa la fecha-hora de la prefactura porque a nadie de la AEAT le molesta un documento que no tienen ni por qué conocer.

No va a funcionar si quieres usar el mismo documento de factura con un contador también de prefactura porque distorsionarías la fecha de creación del registro, entre otras cosas.

El concepto de fecha-hora es muy importante. No sirve solo con leer la fecha del sistema central y usarla. Se debería tener mecanismos de actualización automática con algún servidor de tiempo externo. Esa fecha-hora será luego analizado por la AEAT para ver si se cumplen normas.

No se si me explico.
Este tema ya lo traté hace unos meses, podeis repasar el foro.



Saludos.