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.