Facturación

[Loren]

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

[hmpaquito]

¿ 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 ?

[benjiben143]

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

[cmsoft]

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

[Armando]

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

[lucasdebeltran]

Hola,

Si añades como tipo de campo en la DBF + se crea un campo del tipo autoincrementable presente en entornos SQL:

Code: Select all | Expand

aDBF :=  { { 'ID', '+', 4, 0,;
                  "NOMBRE", "C", 50 } }


dbCreate( "Table.dbf", aDBF )


 

[benjiben143]

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

[FranciscoA]

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

[hmpaquito]

cmsoft,

Con todos mis respetos permíteme que te haga dos matizaciones:

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).

Esta forma, 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.

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.

Segun la aplicacion, esto puede generar una gran cantidad de registros deleted, en pocas semanas el usuario tendra que hacer PACK que requiere exclusividad que requiere que nadie este utilizando las tablas de datos ¿ por qué no reutilizar los registros usados grabando cada registro en su recno() origen ?

Un cordial saludo.

[benjiben143]

hola

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


saludos

[Loren]

Compañeros,

Lo primero: Gracias por contestar.

Mi experiencia, despues de muchos años, es prácticamente la misma que FranciscoA, es decir, vuelco las 2 DBF a 2 DBF en modo excluisivo en PC-Cliente, modifico, hago delete en DBF servidor y vuelco todo de DBF local a servidor. Esto supone que en poco tiempo se crean muchos registros deleted, pero para eso tengo una función que 1 vez al mes se activa y hace un "pack" justo antes de arrancar el programa (aunque para eso necesita exclusividad).

Las DBF "UNA-VARIAS" yo las relacionos con un ID que guardo en una DBF que llamo "Contadores" y que ubico en el Servidor. Así controlo las facturas, notas de entregas, albaranes, compras... etc...

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

En fin...

Mil gracias.
Un saludo.
LORENZO

[hmpaquito]

Loren,

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.

Asi pues, como dije antes, el tratamiento a esto, IMHO, deberia ser de otra forma.

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:

Comprueba el antivirus. Puede estar corrompiendo indices


Saludos