FiveTech Support Forums

Compañeros,

En un aplicativo de facturación bajo entorno de RED LOCAL con DBF/CDX, básicamente la factura contiene 2 DBF:
1º. Un registro por cada factura con: Código cliente, nombre, fecha factura, nº factura, bases imponible, impuestos y total factura.
2º. Varios registros por cada factura con: Todos los artículos que contiene

Por tanto, existe una relación UNO - VARIOS, entre las 2 DBF.

La pregunta es doble:
1. ¿ Como relacionais las 2 DBF? ¿ A través de un campo ID comun a ambas DBF ?
2. Cuando se modifica una factura, estando en RED LOCAL, y esto puede suponer eliminar/añadir uno o varios artículos, cambiar precios... etc..., ¿como lo haceis? Yo suelo migrar todos los datos de las 2 dbf a 2 dbf temporales en PC Cliente, hago DELETE en las DBF originales y una vez modificada la factura vuelvo a volcar de DBFs Temporal a DBFs Definitiva del PC-Servidor asignándole otro ID. ¿ .... y vosotros?

Gracias. Un saludo
LORENZO

¿ puedo yo añadir una pregunta ?

3º Estamos en un mantemiento de uno-varios, en un dialogo con un boton ok y otro cancelar ¿ Como tratar el mantenimiento uno-varios si tenemos un boton ok y otro cancelar y por tanto el usuario puede modificar/ borrar lineas/ añadir lineas ? ¿ que haremos si el usuario borra o modifica y luego desiste con cancelar ?

hola ,,, buenos días

yo relaciono los dos archivos con un campo en este caso con el folio de la factura ( ya dependiendo del modulo,,, ejercicio, periodo, folio, etc)

si en el primer archivo no existe el folio lo doy de alta sino reemplazo , y hago uno búsqueda en el segundo archivo si existen (folio) los borro lógicamente todos que están con el mismo folio y en un campo x les coloco que están borrados.... una vez borrando le agrego todos los movimientos

con esto me da las altas y cambios si usar temporales ,,,, controles a llevar un campo donde indica que se hizo todo correctamente,,,

saludos

Hola compañeros:
Una forma de asegurarse que solo uno a la vez esté modificando una factura en particular es hacer un bloqueo del registro de la tabla cabecera (facturas) previo a mostrar el detalle (items).
La relacion puede ser por el nro de comprobante tipo+letra+numero.
Cuando se quiere modificar una factura, se leen los items, se los carga en una tabla temporaria abierta de forma exclusiva, se hacen todos los cambios y al grabar se borrar los registros que estaban y se añaden todos los que tiene la tabla temporal.
Espero les pueda servir

Amigos:

Permítanme meter una cuña más, que hacer cuando haya necesidad de controlar existencia
al momento de la venta?, me refiero a que si en un producto hay 10 pzs, una terminal vende
8 piezas y en otra terminal el cliente pide 5 la existencia es insuficiente !. y eso lo debemos
controlar.

Por esta razón me inclino hacia una gran tabla temporal donde concurran todas las terminales.

Saludos

para controlar las existencias

se puede controlar en la misma tabla del catalogo de productos o una tabla a parte .

de perdis

  tabla exisprod

  codprod , existencia,  saltemp

  al momento de realizar una factura  y agregar un producto nos debe dar la existencia del producto que tiene en la tabla exisprod

  y grabar en la tabla exisprod  la salida que tiene temporalmente asi podemos controlar las existencias que se están haciendo al mismo momento,,, si no lo graba o no lo desea quitarlas de saltemp..

ay se le puede poner varios controles para saber que sucursal es el que lo tiene capturando al mismo tiempo

saludos

Loren, lo hago muy parecido a tu procedimiento y al que explica cmsof, con la diferencia que solo uso una dbf para las facturas. (no uso relaciones)
Para modificar hago lo siguiente:
1- Copio a una dbf temporal en c:\ de la pc cliente, los datos de la factura, desde el fichero original de facturas.
2- Abro en modo exclusivo la temporal.
3- En esta modifico, borro o agrego items.
4- Presiono el boton aceptar, y en el action de este ejecuto una function de validacion que chequea por todas las condiciones pertinentes, y a la vez trato de bloquear todo el fichero original de facturas. Si la function de validacion retorna .t., continuo con los siguientes pasos.
5- 'Deleteo' del fichero original, la factura en mención.
6- Agrego los nuevos datos desde la temporal
7- Desbloqueo la dbf original
8- Borro la temporal.

Si se presiona Cancelar, solo borro la temporal.

Sobre el punto que expone Armando, lo que tengo es una function que se llama al clickear el boton Aceptar, la cual, antes de emitir la factura, chequea nuevamente si hay existencia de cada uno de los productos, en ese mismo momento. Si hay, emite factura, de lo contrario no.

Saludos

Una forma de asegurarse que solo uno a la vez esté modificando una factura en particular es hacer un bloqueo del registro de la tabla cabecera (facturas) previo a mostrar el detalle (items).

Cuando se quiere modificar una factura, se leen los items, se los carga en una tabla temporaria abierta de forma exclusiva, se hacen todos los cambios y al grabar se borrar los registros que estaban y se añaden todos los que tiene la tabla temporal.

hola

los registros borrados, los puedes usar para  nuevos movimientos , asi no se van acomulando muchos

saludos

haciendo un bloqueo de registro, nunca me gusto... el mismo usuario que tiene bloqueado el registro puede, en un subproceso segundo, alterar algo de la factura, y si no lleva cuidado puede desbloquear el registro de la factura y por tanto liberarla. A mi modo de ver es mejor llevar los bloqueos "aparte" de otra forma mas controlada que no sea con rlock() porque sino a la larga habra problemas.

Nuestro comprañero hmpaquito hace una matización, que me gustaría aclarase, en relación a:

haciendo un bloqueo de registro, nunca me gusto... el mismo usuario que tiene bloqueado el registro puede, en un subproceso segundo, alterar algo de la factura, y si no lleva cuidado puede desbloquear el registro de la factura y por tanto liberarla. A mi modo de ver es mejor llevar los bloqueos "aparte" de otra forma mas controlada que no sea con rlock() porque sino a la larga habra problemas.

Aprovecho y os cuento una experiencia desagradable con un cliente de muchos años que tiene un volumen de facturación grande y que NO puede dejar de facturar por su alto nivel de venta... y es que tras migrarle el aplicativo de DBF/NTX a DBF/CDX en Red Local y tras somerter EXITÓSAMENTE el nuevo aplicativo durante varios días a prueba en red local en mi establecimiento, lo instalo en su centro de trabajo y desde el primer día genera errores, liga artículos de una factura a otra, emite facturas en blanco (sin artículos) y emite errores del tipo:

Unrecorevable error 9201: hb_cdxPageSeekKey: Wrong parent Key. .... incluso ni reindexando indices (el cual el aplicativo dispone de una opción para ello) se soluciona.

Pero lo curioso es que hago un COPIAR-PEGAR en mi red-local, reindexo y funciona PERFECTAMENTE. ¿Alguna explicación? Yo no la encuentro. Cosas de la informática  :?  :?  :cry:  :cry: