Sistema Contable
215 views
Skip to first unread message
Bibiana Cacciaguerra
Feb 2, 2026, 3:33:40 PMFeb 2
to Comunidad de Visual Foxpro en Español
Buenas tardes comunidad,
En esta oportunidad, escribo pidiendo opiniones por si alguno lo ha hecho y ver cómo lo resolvió.
Estoy rehaciendo un viejo sistema contable (que además saca IVA y Ctas Ctes) y pasando la base nativa a mysql
Lo cierto es que cada cierre de ejercicio, varias tablas se vacían y otras son permanentes, tal el caso de alícuotasIVA, tipos de Cpte, Clientes, proveedores y pases de cuenta corriente.
Lo ideal, creo, sería manejar una base con un archivo de pases que tuviera los asientos de todos los ejercicios, sin embargo esto se hace "pesado" por la acumulación de registros.
¿Alguien tiene alguna idea superadora?
Desde ya, muchas gracias por sus opiniones.
Saludos!
elkin dario uribe torres
Feb 2, 2026, 4:09:19 PMFeb 2
to publice...@googlegroups.com
Si no guardas los históricos como sacarías informes comparativos de ejercicios contables tan necesarios?
--
Blog de la Comunidad Visual FoxPro en Español http://comunidadvfp.blogspot.com
---
Has recibido este mensaje porque estás suscrito al grupo "Comunidad de Visual Foxpro en Español" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a publicesvfoxp...@googlegroups.com.
Para ver este debate, visita https://groups.google.com/d/msgid/publicesvfoxpro/990afcd8-759e-4427-af72-bab06dd55e39n%40googlegroups.com.
Esteban Herrero
Feb 2, 2026, 4:15:41 PMFeb 2
to publice...@googlegroups.com
Hola...
Respondiendo esta parte:
Lo ideal, creo, sería manejar una base con un archivo de pases que tuviera los asientos de todos los ejercicios, sin embargo esto se hace "pesado" por la acumulación de registros.
Vas a trabajar con SQL, no es un DBF, xq se pondría pesado???
Si tenes un buen diseño de tablas con sus correspondientes indices, podes administrar millones de registros y a la misma velocidad de cuando iniciaste.
En el caso de asientos te aconsejo manejarlo con 2 tablas una cabecera y otra detalle.
Saludos
Carlos Miguel FARIAS
Feb 2, 2026, 7:48:51 PMFeb 2
to publice...@googlegroups.com
Esto sale de un trabajo de investigación que hice en 2003 para un sistema de normalización de bases de datos aplicando reglas prácticas (no Formas Normales pero con igual resultado).
Como los asientos tienen fecha, puedes guardar innumerables pases. En VFP posiblemente hasta un millón (Que serían cosquillas en MySQL)
Los nombres indican con su primer letra el tipo de datos. c: caracteres, m: memo, n: numéricos enteros, y: monetarios. Puede haber algún error.
Las tablas con más cantidad de registros, son asientos y detalle-asientos, que son registros con muy pocos bytes por registro.
Saludos: Miguel.
Para ver este debate, visita https://groups.google.com/d/msgid/publicesvfoxpro/8b34bb64-1caf-4663-aeb8-4133902d7a86%40yahoo.com.ar.
Pablo Foa Torres
Feb 2, 2026, 7:52:48 PMFeb 2
to publice...@googlegroups.com
Miguel Antúnez
Feb 3, 2026, 3:49:01 PMFeb 3
to publice...@googlegroups.com
Migrar de tablas libres a una base de datos relacional implica un cambio mucho más profundo: cambian por completo las limitaciones, el rendimiento y la forma de manejar la información, especialmente en seguridad e integridad, donde MySQL es muy superior a DBF.
Para un dimensionamiento normal, no veo problema en tener una sola tabla de detalle de asientos acumulando todos los ejercicios, siempre que exista:
-
✔️ Buena normalización (cabecera + detalle).
-
✔️ Índices bien definidos por fecha, ejercicio, cuenta, comprobante, etc.
-
✔️ PK numérica autoincremental (Identity/Auto Increment).
Con ese enfoque, millones de registros no deberían ser un inconveniente real. El problema rara vez es la cantidad de filas, sino un mal diseño del modelo o consultas sin índices adecuados.
Saludos.
Para ver este debate, visita https://groups.google.com/d/msgid/publicesvfoxpro/CABdMRLsa%3DKruuF7_ruCrWLN%3DBuffqhf89Yu7Tr1ckRmf6r4-fg%40mail.gmail.com.
Jorge L. Florez C.
Feb 3, 2026, 6:35:05 PMFeb 3
to publice...@googlegroups.com
Hola
¿Por qué no particionas las tablas en MySQL?
Saludos
Jorge Florez
Lima - Perú
Jomel Mcdonald
Feb 3, 2026, 7:15:25 PMFeb 3
to publice...@googlegroups.com
Manéjalo con un historial al cierre del ejercicio, crea una tablas idéntica a la de los asientos y le colocas _historial. Asi cuando ejecutes el cierre solo dejas en el historial el asiento de apertura que es el de activo/pasivo y capital del cierre y todo lo demás al historial.
Para ver este debate, visita https://groups.google.com/d/msgid/publicesvfoxpro/CAMBYqNL51soBbfyd9GkPjvrKHu9a7NaYvZuqR8RBJd%2B9aBN3CA%40mail.gmail.com.
Dorian Ordonez
Feb 3, 2026, 8:32:36 PMFeb 3
to publice...@googlegroups.com
Buena moacheS jóvenes, hay muy importante este no es un problema técnico, esto es un problema de lógica de negocio, puedes ser el mejor programador del mundo pero si no tienes la lógica del negocio Jamas obtendrás el resultado. Todo empieza por saber que una póliza, una partida,....cierre mensual, cierre anual,....me explico?
Para ver este debate, visita https://groups.google.com/d/msgid/publicesvfoxpro/CAMBYqNL51soBbfyd9GkPjvrKHu9a7NaYvZuqR8RBJd%2B9aBN3CA%40mail.gmail.com.
mapner
Feb 5, 2026, 7:05:10 AMFeb 5
to Comunidad de Visual Foxpro en Español
Hola,
hice una respuesta un tanto larga, pero creo que es de ayuda para esta pregunta que hace al buen diseño de un sistema.
Un sistema de tipo administrativo tiene "Entidades" que en la base de datos devienen en Tablas (y sub-tablas) y se clasifican según su propósito:
de Configuración: son datos auxiliares al contexto general del negocio o en particular sobre otras entidades.
de Recursos: indican objetos físicos o no tangibles que se transaccionan en forma interna o externa en la organización.
de Personas: Físicas o Jurídicas, son actores intervinientes en las transacciones con un rol determinado.
de Transacciones: implican el registro de acciones que son parte de un proceso donde se responde: cuándo (datos temporales), dónde (sectorización), quiénes (personas y roles), contexto (configuración), y qué (recursos físicos o intangibles) que intervienen.
Cada tipo de transacción puede ser:
Directa: se genera luego de la carga del usuario.
Secundaria: generada por otra transacción previa (ejemplo: Factura -> Movimiento de Stock o Factura -> Registro Contable).
¿Qué información es activa o histórica?
Activa: cuando esa información es parte de un proceso no cerrado (ejemplo: un ejercicio contable o un pedido en curso).
Histórica: cuando es registro de un proceso ya cerrado.
Y acá llegamos al nudo de la cuestión
La información histórica debe estar permanentemente en línea para consulta permanente?
Si la respuesta es afirmativa deriva en tablas gigantes en cantidad de registros.
Esto es muy cómodo para el desarrollador (porque simplifica las consultas), pero es poco práctico para el mantenimiento y la performance de la base de datos.
Si la respuesta es negativa:
Si la empresa es chica y con poca necesidad de consulta de históricos:
Lo ideal es un backup pasivo completo a final de ejercicio y limpieza de los datos de la base operativa. Esto mantiene el sistema ligero y rápido.
Si la empresa tiene grandes volúmenes de transacciones y necesidad de consultar varios años en línea:
Se requiere backup activo (datos consultables en línea junto a los datos actuales). Esto requiere más infraestructura y estrategia lo que deviene en más trabajo para el desarrollador pero ese trabajo se presupuesta y se cobra de acuerdo a la complejidad.
Saludos
hice una respuesta un tanto larga, pero creo que es de ayuda para esta pregunta que hace al buen diseño de un sistema.
Un sistema de tipo administrativo tiene "Entidades" que en la base de datos devienen en Tablas (y sub-tablas) y se clasifican según su propósito:
de Configuración: son datos auxiliares al contexto general del negocio o en particular sobre otras entidades.
de Recursos: indican objetos físicos o no tangibles que se transaccionan en forma interna o externa en la organización.
de Personas: Físicas o Jurídicas, son actores intervinientes en las transacciones con un rol determinado.
de Transacciones: implican el registro de acciones que son parte de un proceso donde se responde: cuándo (datos temporales), dónde (sectorización), quiénes (personas y roles), contexto (configuración), y qué (recursos físicos o intangibles) que intervienen.
Cada tipo de transacción puede ser:
Directa: se genera luego de la carga del usuario.
Secundaria: generada por otra transacción previa (ejemplo: Factura -> Movimiento de Stock o Factura -> Registro Contable).
¿Qué información es activa o histórica?
Activa: cuando esa información es parte de un proceso no cerrado (ejemplo: un ejercicio contable o un pedido en curso).
Histórica: cuando es registro de un proceso ya cerrado.
Y acá llegamos al nudo de la cuestión
La información histórica debe estar permanentemente en línea para consulta permanente?
Si la respuesta es afirmativa deriva en tablas gigantes en cantidad de registros.
Esto es muy cómodo para el desarrollador (porque simplifica las consultas), pero es poco práctico para el mantenimiento y la performance de la base de datos.
Si la respuesta es negativa:
Si la empresa es chica y con poca necesidad de consulta de históricos:
Lo ideal es un backup pasivo completo a final de ejercicio y limpieza de los datos de la base operativa. Esto mantiene el sistema ligero y rápido.
Si la empresa tiene grandes volúmenes de transacciones y necesidad de consultar varios años en línea:
Se requiere backup activo (datos consultables en línea junto a los datos actuales). Esto requiere más infraestructura y estrategia lo que deviene en más trabajo para el desarrollador pero ese trabajo se presupuesta y se cobra de acuerdo a la complejidad.
Saludos
Antonio Lima
Feb 5, 2026, 9:10:34 AMFeb 5
to publice...@googlegroups.com
Hola ,
Puedes tener perfectamente todos los movimientos en una sola tabla sin vaciar datos, para que no sea pesado como dices depende de los índices que tengas en las tablas , si en tus consultas solo te traes los movimientos de un rango de fechas , perfectamente puedes trabajar con ese conjunto de datos.
--
Blog de la Comunidad Visual FoxPro en Español http://comunidadvfp.blogspot.com
---
Has recibido este mensaje porque estás suscrito al grupo "Comunidad de Visual Foxpro en Español" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a publicesvfoxp...@googlegroups.com.
Para ver este debate, visita https://groups.google.com/d/msgid/publicesvfoxpro/1e67e636-2028-4873-831b-9fe3092599dcn%40googlegroups.com.
Bibiana Cacciaguerra
Feb 9, 2026, 10:02:06 AMFeb 9
to Comunidad de Visual Foxpro en Español
Agradezco a cada uno que se tomó un momento para responder. Valoro todos los aportes que recibí. Muchas gracias!
La verdad es que las cosas son un poquito más complejas, en tanto hay una ventana de tiempo e la que se trabaja con dos ejercicios simultáneamente. Pero todos los aportes son válidos.
Saludos, Bibiana
Reply all
Reply to author
Forward
0 new messages