Hola buenas tardes

Has recibido una respuesta a esta pregunta?

Muchas gracias

A mi si me respondieron, sobre este tema hice muchas preguntas:
Finalmente Si lo has informatizado y quieres borrarlo tienes que tener la trazabilidad y para borrarlos tienes que emitir otro registro(algo así como una anulacion o recrificativa) tampoco se meten mucho en como.
Excepciones:
Si es un documento temporal que no se ha emitido lo puedes borrar tranquilamente.
Si es un pedido/encargo/.. que has informatizado y despues modifcas directamebte en la factura o albaran, pero con una entrega, no tienew que modificar ni conservar el pedido por que ya se ha convertido en factura..
O albaran..
En definitiva, es todo un lio y no hay concreción van s9bre la marcha según les van llegando las dudas.

Imagina que te hacen un pedido verbal y no emites nada, pues ya sabes que es temporal lo tienes abierto y puedes hacer lo que quieras hasta que emitas algo al cliente o una emision para orddn de trabajo. Con lo cual aqui la continuidad de las numeraciones no afectan tampoco

Resumo rápido lo que les han comentado a nuestra empresa, por si a alguien le sirve.
Básicamente, es que todos estos documentos (los que no son facturas) se pueden generar, modificar, borrar y facturar sin problemas, pero hay que dejar traza de todas estas operaciones.
Esto, en nuestro caso, afecta a pedidos, ofertas, albaranes y facturas borrador.

Si más adelante amplían o documentan más este tema, ampliaremos, pero por ahora con esto se cumple (esto es lo que nos han transmitido a nosotros).
Por ahora no hay documentación clara, todo esto ha sido vía consultas del departamento legal. Así que si lo quieren, imagino que tendrán que especificarlo más detalladamente.

No me preocuparía de esto, hasta que publiquen documentación clara.

Yo no tuve la suerte de Ermendalenda: A mí no me contestaron.:(

Una pregunta, como lo habéis implementado?, creáis un log por cada prefactura, albarán, etc, en el que indicáis, se ha añadido tal producto o , se ha modificado la cantidad de tal linea??
Es por tener una idea de como implementarlo, porque de momento lo único que hacia es bloquear la pro forma una vez convertidas a factura final.

Aquí han decidido que en una primera versión (para cubrir expediente creo) se van a logar operaciones sobre documentos, pero no a nivel de detalle de líneas.
Supongo que si en algún momento sale algo más concreto, se ampliará.

Me explico. Cuando das de alta, modificas, anulas (borras), cambias de estado (**) queda reflejado como operación.
Y luego para cada operación se almacenan campos de la cabecera y del pie (por decirlo así). Los importantes; Se guarda el total, pero no las líneas. Si cambian un importe quedará la modificación, pero no sabrás qué línea ha cambiado.

(**) Los cambios de estado, para nosotros, es que además de las operaciones básicas (A/M/B) hay conversiones (le llamamos cambios de estado). Una Oferta puede convertirse en pedido, un pedido en albarán, un albarán en factura borrador y una factura borrador finalmente se convierte a factura (y los saltos directos, no hace falta pasar por todos los estados).

Los registros llevan un HASH para evitar modificaciones y van encadenados con el HASH anterior (similar a lo que hacemos con los reg. de facturación).

Osea por ejemplo .


Añadís la lineas algo así?:
....
23/10/25 ALTA PROFORMA 2025/0000123 BRUTO: 1.033,00 IMPUESTO 21% 216,93 "Hash calculado anterior + esto"
23/10/25 MODIFICADO PROFORMA 2025/0000123 BRUTO: 1.030,00 IMPUESTO 21% 216,30 "HUELLA"
24/10/25 FACTURADO PROFORMA 2025/0000123 -> F1-25-10000145 "Huella"


Algo así seria +/- lo que me comentabas?

Por si os sirve de algo nosotros tenemos básicamente 6 tablas: pedidos, prefacturas y facturas cada una separada en dos tablas, la de los campos relativos al pedido en sí y otra con los artículos de los pedidos. Creo que todo el mundo esto lo tendrá mas o menos igual. Lo que hemos hecho es crear otra tabla igual de cada una, de pedidos y artículos. Cada vez que hay un cambien de cualquier tipo, y antes de realizarlo, hacemos una copia tanto del pedido antes de cambiarlo como de los artículos que contiene, y luego se cambian los campos que se tengan que cambiar. Cuando los pedidos pasan a prefacturas, hay un campo que enlaza el pedido/pedidos de los que proviene, y también funciona igual, si se cambia algo hay otras dos tablas que guardan los datos antes del cambio. Y cuando pasan a facturas hay otro campo que identifica la prefactura de la que proviene. Al pasara a facturas se "bloquea" todo lo anterior: en realidad hay dos formularios en pedidos y prefacturas: lo que esta bloqueado, que solo se puede ver, y lo pendiente de facturar que si se puede editar. Luego hay un formulario que permite ver todo enlazado si alguien se quiere entretener un rato. Son un montón de tablas con un montón de datos, que se van acumulando y no valen para nada más que para gastar disco duro, porque nadie lo va a mirar jamás (y los de hacienda menos), pero bueno, es fácil de implementar y se cumple con la traza y la no modificación.

Entonces en una proforma , que aveces modificamos un porrón de veces, antes de que el cliente la acepte, que creáis imágenes espejo hasta el infinito??, O simplemente machacáis la copia cada vez?

Depende, en los programas de TPV las adiciones de artículos no se registran ya que están en el ticket, pero cambios en cantidades "para abajo" sí. Luego el sistema solo deja borrar artículos en determinadas circunstancias, solo pueden cancelarlos: quedan marcados pero no se borran. Por otro lado respecto a las proformas cada vez que se emite/imprime hay una tabla que la graba entera, ticket y artículos. Otra tabla para dar de comer a los proveedores de discos duros y que no va a mirar nadie jamás.
En el ERP, que es lo que comentaba antes, sí, cada vez que se modifica un registro se graban todos los campos del mismo en otra tabla, exactamente como estaban antes del cambio. Estas tablas tiene la misma estructura que la primera, salvo un indice adicional para ella, y tres campos más para el usuario que realiza el cambio, la fecha hora y el tipo de modificación: si es borrado o edición.

eso si le metes un trigger a la tabla ya funciona sólo, ¿no? Y ya no hay que programar nada, se encarga la base de datos sola (estoy hablando de SQL Server, no sé si otras tienen lo mismo)

Si.
Como he dicho hay todos los campos de la cabecera importantes (los referentes a Cliente, Fechas, Serie, Número, Tipo Factura,...) y los importes (Totales, IVA total, Total moneda,...).
Pero la idea es más o menos esa.

La finalidad es que si se necesita, se pueda ver "toda la vida" de ese documento, desde que se creó hasta ahora.
Por ejemplo, si se creó como oferta, luego se modificó, luego se convirtió albarán, luego pasó a f.borrador, luego se añadieron líneas (se modificó el importe), y finalmente se facturó.

Nosotros creamos una línea por cada vez que se modifica.

Supongo que sí, el indice yo lo tengo como autonumérico, y la fecha y hora es un Getdate(), el tipo de cambio lo sacas del tipo de trigger, lo único que te faltaría es el usuario que realiza el cambio (siempre que quieras poner estos campos claro). En cualquier caso yo lo tengo como clases y consultas en datasets, ya que básicamente es lo mismo, pero te da mas juego de modificar cosas, poner verificaciones, enlazar con otros objetos etc.

Gracias a todos por las respuestas, en cuanto acabe de afinar lo de verifactu, me meto en la cabeza a ver como lo implemento, supongo que creare unas tablas espejo de las que tengo al estilo.
FacturaProforma2025
FacturaProforma2025Mod <-- igual que el anterior , pero con 3 campos mas FechoraMod(Cuando),UserMod(Quien),NumeroMod(Cuantas Veces)
MaterialProforma2025
MaterialProforma2025Mod <-- igual que el anterior , pero con los campos FechoraMod(Cuando),UserMod(Quien),NumeroMod(Cuantas Veces),TipoMod(Que Se Izo) solo de las lineas modificadas.

Si usas tablas espejo, depende de como lo tengas, vas a necesitar también un indice adicional, para que puedas relacionar los datos originales y las modificaciones sin problemas.

Pues al final voy a introducir un campo Versión, que inicialmente sera 0, si modifico algo al guardar copio íntegramente la versión que tenia guardada y la actualizo en la base tabla de modificaciones, los mats solo los borro/modifico en la tabla original enviando unicamente el material modificado borrado anterior a la tabla backup.


Así si cargo la pro-forma y veo que versión !=0 , cargo desde la de mods, una lista con todas las modificaciones, aunque al visionar muestro solo la ultima, puedo retroceder en el tiempo mostrando que paso y mostrando como se vería.


Por ejemplo edito y borro una de las lineas, al cargar la pro-forma al ser la primera modificación, la versión 1, la muestro y si deseo , cargaría la anterior , mostrando los materiales guardados con ese numero de versión y los que haya en la tabla principal, con ese numero de versión y anterior hasta 0.
Así llevo un control de que le hice , incluyendo en mi caso reparaciones y demás.

en cuanto a huecos en la numeracion y dias de presentacion
 

buenas chicos

yo estoy haciendo pruebas y hay 2 cosas que tengo bastante claras pero que a tenor de los resultados obtenidosigual no están tan claras.

- la primera es que no puede haber saltos en las numeraciones. Eso es algo que he leído siempre por aquí y por allá y que especifican en la documentación de la AEAT
- la segunda es que los clientes tienen hasta 17 dias naturales para enviar una factura desde el momento en el que se emite la factura. Esto nos lo dijo un cliente previa consulta a su equipo legal, se lo he preguntado a la IA y es cierto que me dicen que si todos, pero yo, documentación oficial, no he visto al respecto.

La cosa es que si fuerzo una transmisión al entorno de pruebas que pase de que haya huecos (que es algo que controlo en interfaz pero que dejo pasar a criterio del usuario) y que sea del mes pasado (más de esos 17 dias naturales que comento).... la respuesta me devuelve un <tikR:EstadoEnvio>Correcto</tikR:EstadoEnvio>

y claro, no se si estoy haciendo algo mal, o esta gente son tan sinvergüenzas que te devuelven un estado correcto y aceptan cualquier cosa para poder multar

Enviar a quién? Al cliente? Ahí no entro.
A Veri*factu? Dile que cambie de equipo legal, a menos que te digan en que normativa se apoyan para afirmar eso.


No me hablo con esta gente para cosas serias.

En cuanto a tu primera pregunta, VeriFactu sólo te va a validar que los registros de las facturas que se van generando estén bien encadenados el último con el anterior, pero no te detecta que las numeraciones de facturas vayan correlativas (por ejemplo, puede generarse el RF de la factura 500 de la serie 1 y justo después el RF de la factura 300 de la serie 4 porque así fue como se registraron en el SIF) ni tampoco si has borrado facturas a posteriori de haber enviado sus RF (porque el encadenamiento se hace con el último RF enviado). No obstante, por la propia Ley de Facturación, no deberían existir saltos en la facturación, y además un SIF con saltos significa que permite borrar facturas y esto no cumple la Ley Antifraude.

Mientras tu SIF trabaje en modo VeriFactu se supone que evitas los requerimientos (y siempre podrás consultar los RF de las facturas ya subidas por si tienes que volvértelos a bajar y volver a llenar esos saltos). Pero lo que no evitas son las inspecciones, y es aquí donde puedes tener un problema si ven que en tu SIF hay saltos en la numeración de una misma serie. Si además tu SIF trabaja en modo No VeriFactu, y te hacen un requerimiento, también podrías tener problemas, porque igual les saltará un error de encadenamiento de hashes.

En cuanto a tu segunda pregunta, no sé de dónde se han sacado eso, porque el RF hay que mandarlo en un máximo de 240 segundos desde su creación, de lo contrario recibirás error y tendrás que reintentar el envío con la etiqueta Incidencia = S. A lo que se refieren tal vez es al periodo de devengo de las facturas.

Buff, es que piensa que algorirmo usan para saber la continuidad de las numeraciones cuando están mezladas con la serie y cada uno de su padre y madre, ¿te propongo que cojas un tiquet del carrefour y me desgloses la serie y el número)

Edito: he arrastrado la respuesta, lo siento

vale Carlos, he encontrado la dichosa normativa
y es que nunca habla de 17 dias naturales sino de que puedes facturar cada mes, hasta el dia 16 del mes siguiente como tope

no me deja poner links pero es el BOE-A-2012-14696 (buscad el literal 16 dentro de ese BOE y encontrareis todo esto)

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.

2. En las entregas de bienes comprendidas en el artículo 75.Uno.8.º de la Ley del Impuesto, las facturas deberán expedirse antes del día 16 del mes siguiente a aquél en que se inicie la expedición o el transporte de los bienes con destino al adquirente.

3. En las operaciones acogidas al régimen especial del criterio de caja regulado en el Capítulo X del Título IX de la Ley del Impuesto, la expedición de la factura deberá realizarse en el momento de la realización de tales operaciones, salvo cuando el destinatario de la operación sea un empresario o profesional que actúe como tal, en cuyo caso deberán expedirse antes del día 16 del mes siguiente a aquel en que se haya realizado la operación.

Artículo 13. Facturas recapitulativas.
1. Podrán incluirse en una sola factura distintas operaciones realizadas en distintas fechas para un mismo destinatario, siempre que las mismas se hayan efectuado dentro de un mismo mes natural.

2. Estas facturas deberán ser expedidas como máximo el último día del mes natural en el que se hayan efectuado las operaciones que se documenten en ellas. No obstante, cuando el destinatario de éstas sea un empresario o profesional que actúe como tal, la expedición deberá realizarse antes del día 16 del mes siguiente a aquél en el curso del cual se hayan realizado las operaciones.

3. En las entregas de bienes comprendidas en el artículo 75.Uno.8.º de la Ley del Impuesto, las facturas deberán expedirse antes del día 16 del mes siguiente a aquél en que se inicie la expedición o el transporte de los bienes con destino al adquirente.

Artículo 18. Plazo para la remisión de las facturas.
La obligación de remisión de las facturas que se establece en el artículo 17 deberá cumplirse en el mismo momento de su expedición o bien, cuando el destinatario sea un empresario o profesional que actúe como tal, 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 en el caso de las operaciones acogidas al régimen especial del criterio de caja o de facturas rectificativas antes del día 16 del mes siguiente a aquel en que se hubiera realizado la operación o se hubiera expedido la factura respectivamente.






y en un portal de software de facturacion con un FAQ sobre verifactu he leido esto

757. ¿Existe un “plazo máximo” para enviar la factura en VERI*FACTU desde que sep rodujo la venta?
No hay un plazo fijo (tipo 4 días) como en el SII. El espíritu de VERI*FACTU es la inmediatez. Sin embargo, el ROF (RD 1619/2012) sí marca fechas tope para la expedición (hasta el día 16 del mes siguiente, según operaciones). Superar ese plazo incumple la ley, aunque no haya un “sistema” automático que te bloquee. En una inspección, podrían sancionarte por expedición tardía.


lo cual me cuadra perfectamente con que no me de ningun error enviando facturas de hace mas de 17 dias
o sea... ya te crujirá haciendqa en una inspección llegado el momento porque quejarse no se va a quejar en el momento de la transmisión


yo es que flipé cuando me enteré de esto porque desde el principio tengo un desde/hasta fecha en la transmisión de facturas a verifactu
es decir... nosotros hemos adaptado la tabla de facturas con un campo identificador donde nos guardamos la huella

y sigue siendo la misma tabla de facturas de toda la vida, con al salvedad de que hemos desdoblado todas las interfaces al concepto Pre-Factura o Factura dependiendo de si tenemos ese Identificador relleno en tabla

y cuando ya pasan a ser Facturas no dejamos modificarlas ni eliminarlas

pero para nosotros internamente siguen siendo 'lo mismo'


estoy interpretando algo mal?
como lo veis?

porque esto sale de un BOE al final

o es que hay rectificaciones sobre esa ley que no he encontrado?

Perdona, no me he leido todo lo que has puesto por que eso ya lo habiamos puesto hace meses, pero te digo:
La fecha de emision es la que manda para la inmediatez del envio, según que casos, puedes añadir fecha de operación, no ouedes enviar facturas de hace 17, ni 10 ni de ayer sin que puedas tenrr un problema, salvo excepciones por incidencias que al emirlas no puedas enviarlas.
La fecha de emisión no puede ser ni anterior ni posterior al momento actual en la que la grabas/emites.
Las recapitulativas no añaden contenido ni fechas a verifactu, pero ai sirven para calcular la fecha de operacion de la factura.
Debes diferenciar lo que es fecha de expedición que Unque anteriormente "podia" ser distinta a la de emisión, ahora ddben coincidir, excepro una casuaa excepxionañ que te coincida la grabacion con un cambio de fecha en el mismo segundo.
La fecha de operación, es la del último albaran que incluyas en la recaptiulativa(si no me equovoco)
Y ya si entras en otros temaa de fechas para la consulta de registros ppr que quieras hacer el libro de ivas, más variedad: periodo impositivo, de devengo, donde va en el libro de ivas, que fecha es la buena para el devengo en la factura rectificativa,.... estoy ya como un cencerro, por que además no hay forma que mingún profesional te lo explique, hasta ahora han hecho lo que les venia en gana

Olvidate de chatgpt que en estas cosas es una escopeta de feria

pero no he puesto chatgpt

he encontrado un BOE que explica todo lo que he puesto arriba
que básicamente es que el dia 15 puedes cerrar la facturacion del mes anterior, emitir y transmitir (con ese maximo de 240 segundos de delay)

y por eso pregunto si existe alguna ley que corrija ese BOE que os he puesto

(lo que pasa que no me deja poner el link supongo que por pocos mensajes que llevo)
pero todo eso está sacado del BOE-A-2012-14696
podeis ponerlo en el google y dentro de ese BOE buscar el literal 16
empieza todo en el artículo 11

en su ultima actualizacion publicada el 06-12-2023

Puedes escribir los links con h_t_t_p:/_/... y luego un moderador te lo corrige.
De todas formas, ya deberías poder, porque has alcanzado el mínimo de mensajes (antispam).

ah, muchas gracias neftali

pues el BOE en cuestion es este
https://www.boe.es/buscar/act.php?id...n=1&p=20231206

os explico, nosotros no facturamos bienes propiamente dichos, nuestros clientes no son una tienda que pueda vender un televisor o una cortina o lo que sea
hacemos programas para mensajerias y lo que estamos facturando son los servicios de mensajeria prestados durante un mes

entonces nuestros clientes, a principios del Noviembe por poner un ejemplo, cierran la facturacion de Octubre y emiten la factura con todos los servicios de Octubre

y según entiendo yo en ese BOE, es algo perfectamente legal ya que se trata de empresas, no de particulares

en mi XML monto los nodos
FechaExpedicionFactura y
FechaHoraHusoGenRegistro

en FechaHoraHusoGenRegistro monto la fecha y hora de hoy y no puede diferir en 240 segundos de la fecha y hora de la AEAT

pero mi pregunta es
si yo estoy emitiendo esa factura el dia 05/11/2025, tengo que poner esa fecha en FechaExpedicionFactura?
o tengo que poner 31/10/2025 porque en realidad es una factura de octubre?


VAAAALE
acabo de ver que hay un nodo que no uso por no ser mandatorio que es FechaOperacion

O referís a que debo poner en
FechaExpedicionFactura 31/10/2025
FechaOperacion 05/11/2025

y en FechaHoraHusoGenRegistro 05/11/2025 + la hora del sistema


es eso????


y en relacion a eso....
nunca va a dar error la transmision PERO
si FechaExpedicionFactura = 31/10/2025 y transmito mas allá del dia 15 me expongo a que en una inspección me crujan???

lo estoy entendiendo bien ahora??

Al revés... la fecha de expedición es la del día en que estás generando la factura. El usuario no puede decidir la fecha que va a tener la factura, es siempre la del día
Y la fecha operación si que puede ser de otro día

vaaale

muchas gracias chicos

Ok, asi es
Otra cosa, el dekay no es la diferencia de hora de tu reloj von el de hacienda, ese solo puede ser de maximo un minuto, los 140 segundos es el tiempo maximo de envio desde la hora en lo que lo generas hasta la hora que le llega hacienda, que ademas debes de tener en cuenta que si vas tener desfases de segundos también es mejor dejarlo previsto por si es mejor pecar de mandarlo en ciertas ocasiones como incidencia. O sea si detectas que yaa han pasado 180 swgundos dedde que lo generaste y no enviaste, mejor marcalo como incidencia.

estupendo, gracias :)

y perdon por preguntar algo que ya estaba resuelto, pero es que llevo MESES pensando que lo tenia bien y todo esto viene en relacion al cliente que nos dice que tenemos 17 dias par enviar las facturas
y claro, como veriFACTU se lo traga todo te devuelve un Correcto mientras el encadenamiento sea correcto...
pues yo tan tranquilo con que lo tenia bien

lo dicho
gracias :)

buenos dias

os dejo un enalce a un webinar sobre veriFACTu de la semana pasada que cuenta con la participación de un técnico de hacienda al que le preguntan casos prácticos por si a alguien le pudiera servir
https://www.youtube.com/watch?v=9gXLRSg1pbo

Gracias, me lo miro a ver si hay algo interesante.

en el minuto 39 confirma que, aunque estemos ya enviando facturas a entorno de producción, hasta el dia 1 de enero no serán sancionables ante cualquier posible error
que es algo que leí en este foro que no había quedado demasiado claro ni preguntando a hacienda siquiera

Eso esta muy bien para los clientes miedosos a cambiar ya.

La verdad no entiendo a que juega Hacienda; ¿no les parece un tema importante para aclarar sin dudas Y PARA TODOS LOS DESARROLLADORES Y USUARIOS que los envíos en el periodo transitorio no tienen transcendencia tributaria, que lo tiene que comentar este señor de pasada en una webinar de una empresa privada? Es una verguenza...

Poco dura la alegría en casa del pobre. El vídeo que habíais puesto de enlace ya no es público. He intentado entrar para grabar la parte de "los envíos en el periodo transitorio no tienen transcendencia tributaria" que decía el técnico de hacienda, pero lo han hecho privado, ya no es público, quizá porque lo de la transcendencia tributaria no es cierto. Le pedido confirmación de lo que decía a los de Verifactu, y esto es lo que han respondido (las negritas y subrayados son suyos):
En cualquier caso, parece que confirman lo interesante, que es que en principio no hay sancionabilidad ante errores. Supongo que lo que quieren decir es: errores no hay sanción, pero pufos descarados, tacatá.

Tambien puede ser que solo puedan verlo los que asistieron al webinar y por eso lo pasen a privado. Yo me capture las diapositivas que puso Joaquin (creo que se llamaba el de la AEAT).

Lo he subido a mega, por si alguien quiere verlo.
Tranquilos que no es algo raro, como los del emule.:cool:

Ojo, admin, si incumplo alguna norma borrad el enlace.

Hola, el video me parece interesante pero hay cosas que me confunden más que aclaran. El tema de la pregunta del almacén con dos tiendas en sitios diferentes. Quiero pensar que no entendió o le explicaron bien la pregunta, por que por lo que yo entiendo de lo que dice, es que las dos tiendas, aunque usen diferentes series, si están usando el mismo software, tienen que estar en el mismo encadenamiento. Imagino que el entenderá que las dos tiendas acceden a la misma base de datos.
Por lo que creo es:
-Cada tpv con su propia base de datos hace un encadenamiento propio de su facturas simplificadas/facturas ordinarias.
-El software central, tendrá su propio encadenamiento.

Luego como es el mismo emisor, ya la AEAT gestionará todo esos envíos.

Y lo de las fechas, tampoco me lo ha dejado muy claro, quiere decir que si hacemos una facturación mensual de nuestros clientes y normalmente se pone a esa factura fecha de final del mes, si por ejemplo el día 3 de noviembre (1 y 2 fue fin de semana), si quiero facturar a fecha 31/10/2025 o 01/11/2025, ¿ya no puedo hacerlo o permitirlo?

Hola, la fecha de operación podrás poner esa, pero la fecha de factura, no , tiene que ser la de creación /envío del registro de facturacion, prueba lo y veras que si lo haces de otra forma, da error.