Optimizacion de Consultas Creando Tablas de Saldos
125 views
Skip to first unread message
Visual FoxPro Nuevo
Oct 15, 2010, 4:34:23 PM10/15/10
to Comunidad de Visual Foxpro en Español
Saludos a todos,
Escribo en esta oportunidad para pedir sugerencia en cuanto a la
creacion de tablas que controlen saldos a fin de poder optimizar
consultas.
Estoy hablando de Tablas VFP en Bases de datos. Recuerden que hace un
mes aproximado presente un problema con el rendimiento de un Servidor
Windows 2003 Server y el manejo de consultas multiples cuando una
tabla estaba en uso por otro cliente de la red.
A pesar de que el problema fue resuelto y la consulta de aquel
entonces fue optimizada, siguen persistiendo algunos problemas en
cuanto a la lentitud de operaciones en el momento en que dos o mas
usuarios acceden a la informacion de las tablas.
Se que la solucion es migrar a SQL, pero este cambio no es tan
facil, al menos no para la cantidad de programas y cuando se
desarrolla desde un principio pensando DBF (Este es mi caso).
Por tal razon, se me ocurre ( Sin haber pensado esto muy
profundamente ), realizar alguna especie de "Archivos de Saldos" los
cuales se generen cada cierto tiempo de forma que la tabla original
quede un poco libre de tantos registros.
No se que opinen ustedes en cuanto a aplicar este tipo de
metodologia???.
A decir verdad yo nunca he estado muy de acuerdo en el uso de archivos
de Saldos, me parece que eso puede traer como consecuencia que la
informacion no sea fiel. Sin embargo conozco sistemas que agrupan
informacion y arman archivos de saldos para tales efectos. Algunos de
estos lo representan Sistemas de Saldos Contables, Saldos de
Proveedores, Saldos de Inventario, etc...
Tienen ustedes experiencia en esto? A rasgos generales cuales son las
pautas que toman en cuenta para generar, actualizar y leer este tipo
de archivos?
Gracias a todos y Saludos,
Angel Ferreira.
Escribo en esta oportunidad para pedir sugerencia en cuanto a la
creacion de tablas que controlen saldos a fin de poder optimizar
consultas.
Estoy hablando de Tablas VFP en Bases de datos. Recuerden que hace un
mes aproximado presente un problema con el rendimiento de un Servidor
Windows 2003 Server y el manejo de consultas multiples cuando una
tabla estaba en uso por otro cliente de la red.
A pesar de que el problema fue resuelto y la consulta de aquel
entonces fue optimizada, siguen persistiendo algunos problemas en
cuanto a la lentitud de operaciones en el momento en que dos o mas
usuarios acceden a la informacion de las tablas.
Se que la solucion es migrar a SQL, pero este cambio no es tan
facil, al menos no para la cantidad de programas y cuando se
desarrolla desde un principio pensando DBF (Este es mi caso).
Por tal razon, se me ocurre ( Sin haber pensado esto muy
profundamente ), realizar alguna especie de "Archivos de Saldos" los
cuales se generen cada cierto tiempo de forma que la tabla original
quede un poco libre de tantos registros.
No se que opinen ustedes en cuanto a aplicar este tipo de
metodologia???.
A decir verdad yo nunca he estado muy de acuerdo en el uso de archivos
de Saldos, me parece que eso puede traer como consecuencia que la
informacion no sea fiel. Sin embargo conozco sistemas que agrupan
informacion y arman archivos de saldos para tales efectos. Algunos de
estos lo representan Sistemas de Saldos Contables, Saldos de
Proveedores, Saldos de Inventario, etc...
Tienen ustedes experiencia en esto? A rasgos generales cuales son las
pautas que toman en cuenta para generar, actualizar y leer este tipo
de archivos?
Gracias a todos y Saludos,
Angel Ferreira.
IVAN MARTINEZ
Oct 16, 2010, 3:20:57 AM10/16/10
to publice...@googlegroups.com
Aunque parezca no inn, la aplicación computacional mas antigua la
CONTABILIDAD,se puede decir que siempre tiene un archivo de Saldos.
Alguien tiene una aplicación de CONTABILIDAD que no tenga un archivo de
saldos por cada cuenta y subcuenta en que esten minimo los:
Saldos de Inicio del Año, (1 saldo por cuenta)
los Saldos por cada uno de los meses (12 x cuenta)
Saldos del debe (12 x cuenta)
Saldos del Haber (12 x cuenta)
total de la cuenta (12 x cuenta)
el saldo de precierre anual (1 x cuenta),
el saldo de cierre definitivo (1x cuenta.
CONTABILIDAD,se puede decir que siempre tiene un archivo de Saldos.
Alguien tiene una aplicación de CONTABILIDAD que no tenga un archivo de
saldos por cada cuenta y subcuenta en que esten minimo los:
Saldos de Inicio del Año, (1 saldo por cuenta)
los Saldos por cada uno de los meses (12 x cuenta)
Saldos del debe (12 x cuenta)
Saldos del Haber (12 x cuenta)
total de la cuenta (12 x cuenta)
el saldo de precierre anual (1 x cuenta),
el saldo de cierre definitivo (1x cuenta.
Si esto es bueno para la mas antigua aplicaccion de sistemas y la que mas
exactitud requiere porque no va ha ser bueno para cualquier otra.
La cuestion es que llevar saldos en un sistema de inventario seria un poco
mas complicado pero la filofia que hay que seguir seria la misma que la
contable.
Por ejemplo para un producto tendriamos que tener:
Saldo Inicio
Saldo de Ventas
Saldo de Compras
Saldo de Ajustes
Saldo de Notas de Creditos
Saldo de Anulaciones
Y asi por cada tipo de movimiento.
Pero los saldos a llevar van a depender mucho de la aplicación y de las
necesidades.
Ivan Marinez von Halle
>>>-----Mensaje original-----
>>>De: publice...@googlegroups.com
>>>[mailto:publice...@googlegroups.com] En nombre de
>>>Visual FoxPro Nuevo
>>>Enviado el: Viernes, 15 de Octubre de 2010 04:04 p.m.
>>>Para: Comunidad de Visual Foxpro en Español
>>>Asunto: [vfp] Optimizacion de Consultas Creando Tablas de Saldos
Walter R. Ojeda Valiente
Oct 16, 2010, 3:53:00 AM10/16/10
to publice...@googlegroups.com
Hola Iván
Mi sistema de Contabilidad, NO TIENE un archivo de saldos. Sí lo tenía la versión anterior pero la versión actual (desde el año 2004) ya no tiene porque no necesita. Es innecesario. Tampoco lo tiene el sistema de Inventarios, aunque sí guarda el saldo inicial de cada producto y el saldo actual de cada producto.
Saludos.
Walter.
Mi sistema de Contabilidad, NO TIENE un archivo de saldos. Sí lo tenía la versión anterior pero la versión actual (desde el año 2004) ya no tiene porque no necesita. Es innecesario. Tampoco lo tiene el sistema de Inventarios, aunque sí guarda el saldo inicial de cada producto y el saldo actual de cada producto.
Saludos.
Walter.
IVAN MARTINEZ
Oct 16, 2010, 4:14:07 AM10/16/10
to publice...@googlegroups.com
Walter, todos los años estan en la misma baseo esta
separado por años o meses?
Ivan
De: publice...@googlegroups.com [mailto:publice...@googlegroups.com] En nombre de Walter R. Ojeda Valiente
Enviado el: Sábado, 16 de Octubre de 2010 03:23 a.m.
Para: publice...@googlegroups.com
Asunto: RE: [vfp] Optimizacion de Consultas Creando Tablas de Saldos
Walter R. Ojeda Valiente
Oct 16, 2010, 4:21:57 AM10/16/10
to publice...@googlegroups.com
Basicamente hay tres tablas:
- CUENTAS (con sus números, nombres, cuentas superiores, etc.)
- ASIENTOSCAB (con sus números de referencia, ejercicio contable, sucursal, fecha, número de asiento, etc.)
- ASIENTOSDET (con sus números de referencia, número de la cuenta, tipo de movimiento, monto, etc.)
Y todos los asientos, sean del ejercicio contable que sean, se encuentran en las tablas ASIENTOSCAB y ASIENTOSDET. Eso hace que las tablas sean grandes, pero están completas y todo lo que se desee obtener se obtiene fácil y rápidamente.
Saludos.
Walter.
- CUENTAS (con sus números, nombres, cuentas superiores, etc.)
- ASIENTOSCAB (con sus números de referencia, ejercicio contable, sucursal, fecha, número de asiento, etc.)
- ASIENTOSDET (con sus números de referencia, número de la cuenta, tipo de movimiento, monto, etc.)
Y todos los asientos, sean del ejercicio contable que sean, se encuentran en las tablas ASIENTOSCAB y ASIENTOSDET. Eso hace que las tablas sean grandes, pero están completas y todo lo que se desee obtener se obtiene fácil y rápidamente.
Saludos.
Walter.
Carlos Miguel FARIAS
Oct 16, 2010, 9:39:42 AM10/16/10
to publice...@googlegroups.com
Walter, coincido con tu diseño, (mi profesión Universitaria es CPN, aunque siempre trabaje en el area de programación, aún antes de recibirme), pero es un diseño ultra-simple-efectivo, revertir un asiento, simplemente lo marcas y está. Es un modelo totalmente normalizado.
En modelo con multiples campos para saldos de distintos meses, una actualización fallida, puede hacerte un desastre, pueden quedarte valores mal y producir un arrastre catastrofico, ademas, eso se justificaba en sistemas donde ubicar registros, era supercomplicado (no indices, no apareo automatico NO SQL!!!), pero en la actualidad, via SQL, dicha estructura, mas que ventaja, es una complejidad.
Es más, en mi caso, solo uso una columna para el importe (debitos positivos, creditos negativos, o a la inversa, como gustes), una simple suma sobre el campo importe filtrando por cuenta y fecha me da el saldo de una cuenta, asumo, que como buen sistema de registración contable, a fin de año haces un asiento de cierre de ejercicio y otro asiento de apertura de ejercicio. Entonces el rango de consulta va desde inicio de ejercicio hasta la fecha.
Si son muchos movimientos, se puede hacer un cierre mensual (y la respectiva apertura al inicio), y consultas desde comienzo de mes.
En todo caso, si hay consultas reiteradas a saldos historicos (tipo mineria de datos), y solo necesitan totales, sin nivel de detalle, puede crearse una tabla con totales mensuales por cuenta (en una corrida con un select into table), porque ademas, dicha tabla puede ser importada a una planilla de calculo para que el contador "juegue" con tablas dinamicas que ya estan resueltas en dichos programas de oficina.
Hay que tener en cuenta que en las versiones hasta 2003 de excel no podias levantar mas de 65000 filas y en las versiones levanta mas pero es lento porque excel levanta todo a memoria (importa la tabla en una hoja).
Para manejo de inventario, perfectamente se puede utilizar el modelo contable, donde cada asiento serian movimientos de stock (compras/devoluciones: suman, ventas/roturas/perdidas/choreos: restan), si queres manejar inventario valorizado, agregas a la columna de cantidad la de importe.
Pero basicamente es lo mismo.
Esto ultimo ademas te permite manejar cualquier tipo de costeo de productos.
Saludos: Miguel
En modelo con multiples campos para saldos de distintos meses, una actualización fallida, puede hacerte un desastre, pueden quedarte valores mal y producir un arrastre catastrofico, ademas, eso se justificaba en sistemas donde ubicar registros, era supercomplicado (no indices, no apareo automatico NO SQL!!!), pero en la actualidad, via SQL, dicha estructura, mas que ventaja, es una complejidad.
Es más, en mi caso, solo uso una columna para el importe (debitos positivos, creditos negativos, o a la inversa, como gustes), una simple suma sobre el campo importe filtrando por cuenta y fecha me da el saldo de una cuenta, asumo, que como buen sistema de registración contable, a fin de año haces un asiento de cierre de ejercicio y otro asiento de apertura de ejercicio. Entonces el rango de consulta va desde inicio de ejercicio hasta la fecha.
Si son muchos movimientos, se puede hacer un cierre mensual (y la respectiva apertura al inicio), y consultas desde comienzo de mes.
En todo caso, si hay consultas reiteradas a saldos historicos (tipo mineria de datos), y solo necesitan totales, sin nivel de detalle, puede crearse una tabla con totales mensuales por cuenta (en una corrida con un select into table), porque ademas, dicha tabla puede ser importada a una planilla de calculo para que el contador "juegue" con tablas dinamicas que ya estan resueltas en dichos programas de oficina.
Hay que tener en cuenta que en las versiones hasta 2003 de excel no podias levantar mas de 65000 filas y en las versiones levanta mas pero es lento porque excel levanta todo a memoria (importa la tabla en una hoja).
Para manejo de inventario, perfectamente se puede utilizar el modelo contable, donde cada asiento serian movimientos de stock (compras/devoluciones: suman, ventas/roturas/perdidas/choreos: restan), si queres manejar inventario valorizado, agregas a la columna de cantidad la de importe.
Pero basicamente es lo mismo.
Esto ultimo ademas te permite manejar cualquier tipo de costeo de productos.
Saludos: Miguel
Walter R. Ojeda Valiente
Oct 16, 2010, 4:37:46 PM10/16/10
to publice...@googlegroups.com
Hola Miguel
Exacto, tener una tabla de saldos no se justifica en estos tiempos. Era lógico e inclusive hasta obligatorio utilizarla hace muchos años, cuando las computadoras eran lentísimas y las capacidades de almacenamiento de los discos duros muy limitadas (comparadas con las de ahora). Pero en esta época es inncesaria dicha tabla.
Yo también utilizo una sola columna para todos los importes. Hay un campo en la tabla ASIENTOSDET llamado "Tipo de Movimiento" el cual puede tener una "D" (si es un debe) o una "H" (si es un haber), de esa manera puedo saber muy fácilmente de qué se trata.
El sistema tiene un proceso llamado "Cierre anual del Ejercicio contable" que genera dos asientos: uno para cerrar las cuentas activas y pasivas y el otro para liquidar las cuentas de ingresos y de egresos.
Tiene otro proceso llamado "Reapertura de cuentas" que genera el asiento de reapertura del año especificado, con los mismos datos del Balance General correspondiente al ejercicio anterior.
No tiene la opción de hacer cierres mensuales, pero sí un proceso llamado "Cierres de movimientos" que básicamente impide que se agreguen, borren o modifiquen asientos con fecha igual o anterior a la especificada. Por ejemplo, si un usuario cierra los movimientos al 18/02/2010, ya no se podrán agregar/borrar/modificar asientos con fechas anteriores. Cualquier usuario puede volver a ejecutar ese proceso y colocar una nueva fecha posterior (por ejemplo: 25/03/2010) pero solamente el usuario Supervisor puede colocar una fecha anterior (por ejemplo: 21/01/2010).
Para el caso de mi sistema administrativo, tengo una tabla llamada TIPOSMOVIMIENTOS, la cual tiene algunos registros predefinidos y no borrables por los usuarios (SVT=salida por ventas, ECM=entrada por compras, TRA=traslado entre sucursales, EDV=entrada por devolución del cliente, SDV=salida por devolución al proveedor, etc.). El usuario puede agregar más registros a dicha tabla (por ejemplo: SRA=salida por regalos de aniversario) con la convención de que si el código empieza con una "E" se trata de una entrada al stock y si empieza con una "S" se trata de una salida del stock.
Cada producto tiene una fecha de stock inicial, una cantidad inicial (la que tenía en la fecha anterior) y una cantidad actual (la cual no coloca el usuario, sino que es siempre calculada por el sistema). Cada vez que un producto tiene movimientos y se agrega/borra/modifica alguna cantidad con fecha igual o posterior a la fecha inicial, el sistema simplemente hace la operación correspondiente para actualizar la cantidad actual en stock de ese producto (y en caso de tratarse de una compra, también calcula el nuevo precio de costo).
Si un producto tiene movimientos con fechas anteriores a su fecha de stock inicial, el sistema no procesa dichos movimientos y le muestra al usuario el mensaje correspondiente, en la pantalla o en el informe, según corresponda.
Saludos.
Walter.
Exacto, tener una tabla de saldos no se justifica en estos tiempos. Era lógico e inclusive hasta obligatorio utilizarla hace muchos años, cuando las computadoras eran lentísimas y las capacidades de almacenamiento de los discos duros muy limitadas (comparadas con las de ahora). Pero en esta época es inncesaria dicha tabla.
Yo también utilizo una sola columna para todos los importes. Hay un campo en la tabla ASIENTOSDET llamado "Tipo de Movimiento" el cual puede tener una "D" (si es un debe) o una "H" (si es un haber), de esa manera puedo saber muy fácilmente de qué se trata.
El sistema tiene un proceso llamado "Cierre anual del Ejercicio contable" que genera dos asientos: uno para cerrar las cuentas activas y pasivas y el otro para liquidar las cuentas de ingresos y de egresos.
Tiene otro proceso llamado "Reapertura de cuentas" que genera el asiento de reapertura del año especificado, con los mismos datos del Balance General correspondiente al ejercicio anterior.
No tiene la opción de hacer cierres mensuales, pero sí un proceso llamado "Cierres de movimientos" que básicamente impide que se agreguen, borren o modifiquen asientos con fecha igual o anterior a la especificada. Por ejemplo, si un usuario cierra los movimientos al 18/02/2010, ya no se podrán agregar/borrar/modificar asientos con fechas anteriores. Cualquier usuario puede volver a ejecutar ese proceso y colocar una nueva fecha posterior (por ejemplo: 25/03/2010) pero solamente el usuario Supervisor puede colocar una fecha anterior (por ejemplo: 21/01/2010).
Para el caso de mi sistema administrativo, tengo una tabla llamada TIPOSMOVIMIENTOS, la cual tiene algunos registros predefinidos y no borrables por los usuarios (SVT=salida por ventas, ECM=entrada por compras, TRA=traslado entre sucursales, EDV=entrada por devolución del cliente, SDV=salida por devolución al proveedor, etc.). El usuario puede agregar más registros a dicha tabla (por ejemplo: SRA=salida por regalos de aniversario) con la convención de que si el código empieza con una "E" se trata de una entrada al stock y si empieza con una "S" se trata de una salida del stock.
Cada producto tiene una fecha de stock inicial, una cantidad inicial (la que tenía en la fecha anterior) y una cantidad actual (la cual no coloca el usuario, sino que es siempre calculada por el sistema). Cada vez que un producto tiene movimientos y se agrega/borra/modifica alguna cantidad con fecha igual o posterior a la fecha inicial, el sistema simplemente hace la operación correspondiente para actualizar la cantidad actual en stock de ese producto (y en caso de tratarse de una compra, también calcula el nuevo precio de costo).
Si un producto tiene movimientos con fechas anteriores a su fecha de stock inicial, el sistema no procesa dichos movimientos y le muestra al usuario el mensaje correspondiente, en la pantalla o en el informe, según corresponda.
Saludos.
Walter.
IVAN MARTINEZ
Oct 16, 2010, 9:06:18 PM10/16/10
to publice...@googlegroups.com
Carlos dice: Si son muchos movimientos, se puede
hacer un cierre mensual (y la respectiva apertura al inicio), y consultas desde
comienzo de mes.
Y esto no es lo mismo que decir que hay saldos de Inicio de
cada mes. ?????
Ivan Martinez
De: publice...@googlegroups.com [mailto:publice...@googlegroups.com] En nombre de Carlos Miguel FARIAS
Enviado el: Sábado, 16 de Octubre de 2010 09:10 a.m.
Para: publice...@googlegroups.com
Asunto: Re: [vfp] Optimizacion de Consultas Creando Tablas de Saldos
Walter R. Ojeda Valiente
Oct 16, 2010, 9:22:33 PM10/16/10
to publice...@googlegroups.com
Por lo menos es similar, pero es innecesario hacer ese proceso en esta época, con las herramientas de hardware y de software que disponemos.
Saludos.
Walter.
Saludos.
Walter.
IVAN MARTINEZ
Oct 16, 2010, 9:26:27 PM10/16/10
to publice...@googlegroups.com
Walter dice: Cada producto
tiene una fecha de stock inicial, una cantidad inicial (la que tenía en la fecha
anterior) y una cantidad actual (la cual no coloca el usuario, sino que es
siempre calculada por el sistema). Cada vez que un producto tiene movimientos y
se agrega/borra/modifica alguna cantidad con fecha igual o posterior a la fecha
inicial, el sistema simplemente hace la operación correspondiente para
actualizar la cantidad actual en stock de ese producto (y en caso de tratarse de
una compra, también calcula el nuevo precio de
costo).
Pregunto: Y
esto no es llevar un saldo ?????
Ivan
Martinez
De: publice...@googlegroups.com [mailto:publice...@googlegroups.com] En nombre de Walter R. Ojeda Valiente
Enviado el: Sábado, 16 de Octubre de 2010 04:08 p.m.
Para: publice...@googlegroups.com
Asunto: RE: [vfp] Optimizacion de Consultas Creando Tablas de Saldos
Walter R. Ojeda Valiente
Oct 16, 2010, 9:38:05 PM10/16/10
to publice...@googlegroups.com
Es llevar un saldo inicial y un saldo final. Nada más.
Pero no es llevar un saldo para cada mes o para cada semana o para cada año, o lo que sea. Y no se ocupa una tabla de saldos para conocer esas cantidades.
El saldo inicial es obligatorio, para saber cual es la primera cantidad que deberá utilizarse en los procesos. El saldo final es opcional, porque puede recalcularse cuantas veces se requiera. El tenerlo en la tabla es solamente para agilizar la obtención de algunos informes porque al empresario el saldo que generalmente más le interesa es el saldo actual (o final). A veces también quiere saber cuanto tenía hace 10 días o hace un mes, pero eso es más esporádico. Lo normal es que quiera saber cuanto tiene hoy.
Saludos.
Walter.
Pero no es llevar un saldo para cada mes o para cada semana o para cada año, o lo que sea. Y no se ocupa una tabla de saldos para conocer esas cantidades.
El saldo inicial es obligatorio, para saber cual es la primera cantidad que deberá utilizarse en los procesos. El saldo final es opcional, porque puede recalcularse cuantas veces se requiera. El tenerlo en la tabla es solamente para agilizar la obtención de algunos informes porque al empresario el saldo que generalmente más le interesa es el saldo actual (o final). A veces también quiere saber cuanto tenía hace 10 días o hace un mes, pero eso es más esporádico. Lo normal es que quiera saber cuanto tiene hoy.
Saludos.
Walter.
Angel Ferreira
Oct 17, 2010, 1:20:54 PM10/17/10
to publice...@googlegroups.com
Saludos a todos muchachos,
Gracias por sus comentarios y por toda la informacion de la que se puede nutrir uno en este foro.
En realidad si alguna duda tenia en cuanto a generar archivos de Saldos, con esta discucion la misma queda eliminada.
Gracias una vez mas y seguimos en contacto.
Saludos,
AF
Gracias por sus comentarios y por toda la informacion de la que se puede nutrir uno en este foro.
En realidad si alguna duda tenia en cuanto a generar archivos de Saldos, con esta discucion la misma queda eliminada.
Gracias una vez mas y seguimos en contacto.
Saludos,
AF
Walter R. Ojeda Valiente
Oct 17, 2010, 2:08:13 PM10/17/10
to publice...@googlegroups.com
Hola Angel
De nada, esa es la idea del grupo, ayudarnos entre todos en lo que podamos.
Saludos.
Walter.
De nada, esa es la idea del grupo, ayudarnos entre todos en lo que podamos.
Saludos.
Walter.
Carlos Miguel FARIAS
Oct 17, 2010, 5:42:39 PM10/17/10
to publice...@googlegroups.com
Lo que indico de asientos de cierre de periodo (anual/mensual) y apertura de periodo, corresponde a practicas contables, que ademas sirve como "control de cierre", el usuario no puede acceder a los importes de dicho asiento de cierre, solo puede visualizarlo, con lo que una vez hecho el cierre, impide que se puedan tocar los asientos anteriores al cierre (y te aumenta el puntaje a nivel de auditoria contable).
Funciona como un "bit" de paridad de saldos, o cierre de paquete en tcp/ip, asegura que los importes intermedios, parte desde y llegan hasta.
Un registro de cierre puede no ser necesario como se indico previamente, ya que es facil de calcular a partir del inicial.
Ademas, por ejemplo a nivel de inventario, hay un momento crucial donde se reajusta la existencia cuando se hace el recuento fisico (cerrado por balance, es basicamente para hacer eso). Las diferencias entre la existencia real y la contable, debe ajustarse y se tiene la certeza de partir de saldo cierto.
Saludos: Miguel
Desde Argentina, festejando el Dia de la Madre
Funciona como un "bit" de paridad de saldos, o cierre de paquete en tcp/ip, asegura que los importes intermedios, parte desde y llegan hasta.
Un registro de cierre puede no ser necesario como se indico previamente, ya que es facil de calcular a partir del inicial.
Ademas, por ejemplo a nivel de inventario, hay un momento crucial donde se reajusta la existencia cuando se hace el recuento fisico (cerrado por balance, es basicamente para hacer eso). Las diferencias entre la existencia real y la contable, debe ajustarse y se tiene la certeza de partir de saldo cierto.
Saludos: Miguel
Desde Argentina, festejando el Dia de la Madre
Henry Martinez
Oct 18, 2010, 7:56:51 PM10/18/10
to publice...@googlegroups.com
La utilización de tablas de saldos, depende del diseño de la Base de datos.
Los usuarios piden consultas y reportes; que se generan utilizando indices cdx.
El proceso es el siguiente:
- Solicitud de reporte/consulta.
- Abre las tablas con los indices apropiados para el reporte.
- Seek hasta el inicio de los datos solicitados del reporte.
- Barriendo los datos los envía a un archivo plano/impresora.
- Termina el filtro de datos.
- Cierra las tablas.
- Muestra el archivo plano en el caso que el reporte sea a pantalla.
No pierde tiempo en proceso de:
- Generar tablas intermedias.
- Ordenar datos para el reporte.
Saludos.
Henry Martínez Flores
Sistema Administrativo Moises 2.0
Movíl: 593-89865854 (Porta)
Oficina: 593-4-2826901
Guayaquil-Ecuador
Henry Martinez
Oct 18, 2010, 8:07:57 PM10/18/10
to publice...@googlegroups.com
Perdón me olvide yo si utilizo archivos de saldos.
Y genero reportes a tasas de 40 hasta 200 paginas x segundo dependiendo del procesador, disco y la RAM.
La cantidad de usuarios que esta utilizando la base de datos, no es muy relevante.
Saludos.
Henry Martínez Flores
Sistema Administrativo Moises 2.0
Movíl: 593-89865854 (Porta)
Oficina: 593-4-2826901
Guayaquil-Ecuador
Walter R. Ojeda Valiente
Oct 18, 2010, 8:59:50 PM10/18/10
to publice...@googlegroups.com
Hola Henry
Por supuesto que sí puedes utilizarlas si lo deseas. Una de las cosas buenas de VFP es que cada problema puede encararse de muchísimas maneras y tiene muchísimas soluciones.
Pero usar tablas de saldos en esta época es innecesario, porque las computadoras son rapidísimas y los discos duros gigantescos (comparados con los de 20 años atrás, por ejemplo). En esa época sí era conveniente, corriente y hasta quizás obligatorio utilizar tablas de saldos. Ahora ya no.
Pero es cuestión de gustos.
Yo no las utilizo porque complican los trabajos de Análisis y de Programación y mi idea es hacer todas las tareas siempre en la forma más simple, sencilla y rápida posible. Usando tablas de saldos, tendría esto:
PROCESO ---> GENERA LAS TABLAS DE SALDOS ---> SE IMPRIMEN LOS SALDOS
No usándolas tengo esto:
PROCESO ---> SE IMPRIMEN LOS SALDOS
O sea, ni me preocupo de generar las tablas, ni de saber si están actualizadas o no. Ni de actualizarlas cuando no lo están.
Si te parece que ahorras tiempo de impresión usando tablas de saldos, deberías probar imprimiendo esos mismos saldos pero sin usar las tablas de saldos. ¿Cuánto tiempo has ahorrado? ¿Un minuto, dos? ¿Se justifica tener la complicación de usar y processar tablas de saldos por un ahorro esporádico de uno o dos minutos?
Teniendo un SELECT optimizado en tu base de datos obtener los datos que necesitas es muy rápido.
Pero claro, es cuestión de gustos.
Saludos.
Walter.
Por supuesto que sí puedes utilizarlas si lo deseas. Una de las cosas buenas de VFP es que cada problema puede encararse de muchísimas maneras y tiene muchísimas soluciones.
Pero usar tablas de saldos en esta época es innecesario, porque las computadoras son rapidísimas y los discos duros gigantescos (comparados con los de 20 años atrás, por ejemplo). En esa época sí era conveniente, corriente y hasta quizás obligatorio utilizar tablas de saldos. Ahora ya no.
Pero es cuestión de gustos.
Yo no las utilizo porque complican los trabajos de Análisis y de Programación y mi idea es hacer todas las tareas siempre en la forma más simple, sencilla y rápida posible. Usando tablas de saldos, tendría esto:
PROCESO ---> GENERA LAS TABLAS DE SALDOS ---> SE IMPRIMEN LOS SALDOS
No usándolas tengo esto:
PROCESO ---> SE IMPRIMEN LOS SALDOS
O sea, ni me preocupo de generar las tablas, ni de saber si están actualizadas o no. Ni de actualizarlas cuando no lo están.
Si te parece que ahorras tiempo de impresión usando tablas de saldos, deberías probar imprimiendo esos mismos saldos pero sin usar las tablas de saldos. ¿Cuánto tiempo has ahorrado? ¿Un minuto, dos? ¿Se justifica tener la complicación de usar y processar tablas de saldos por un ahorro esporádico de uno o dos minutos?
Teniendo un SELECT optimizado en tu base de datos obtener los datos que necesitas es muy rápido.
Pero claro, es cuestión de gustos.
Saludos.
Walter.
IVAN MARTINEZ
Oct 19, 2010, 12:12:18 PM10/19/10
to publice...@googlegroups.com
Sin archivo de saldos:
proceso mov -> graba registro
mov
proceso estado de cuenta -> obtiene saldo inicio
sistema -> ajusta saldo inicio-> lo demas
igual
Con archivo de saldos si se tienen por
mes.
proceso mov -> graba reg mov -> actualiza
saldo
proceso estado de cuenta -> obtiene saldo
inicio de mes -> ajusta saldo al dia si es necesario -> todo lo demas
igual
Ivan Martinez
De: publice...@googlegroups.com [mailto:publice...@googlegroups.com] En nombre de Walter R. Ojeda Valiente
Enviado el: Lunes, 18 de Octubre de 2010 08:30 p.m.
Para: publice...@googlegroups.com
Asunto: RE: [vfp] Optimizacion de Consultas Creando Tablas de Saldos
Reply all
Reply to author
Forward
0 new messages