Prefacturacion, Proformas y Borradores de facturas (Faq Verifactu)

[bmfranky]

Empezado por emailesc

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?

[emailesc]

Empezado por bmfranky

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.

[Jarogo08]

Empezado por emailesc

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)

[emailesc]

Empezado por Jarogo08

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)

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.

[bmfranky]

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.

[emailesc]

Empezado por bmfranky

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.

[bmfranky]

Empezado por emailesc

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.

[Neftali [Germán.Estévez]]

Empezado por bmfranky

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?

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