Re: Estructura contable para BD

Hola Juan.
Antes que nada, gracias por contestar.

>> ¿Alguien me puede indicar cual es la mejor forma de manejar una base de
>> datos para un sistema contable?
> Mmm...en el mercado hay suficientes software que ya hacen esto. Puedes
> mirar el proyecto pygestor, quizá te sirva.

Estuve mirando el pyGestor, pero creo que se me olvidó comentar algo
primordial. Tengo entendido que pyGestor es para Linux... Yo de Linux
entiendo muy poco, casi nada (conocerlo, para mí, es una de estas cosas que
uno quiere hacer pero va dejando para después, mientras no la necesita). De
hecho, la aplicación la debo desarrollar en Visual FoxPro 9 y el ambiente a
utilizar es el Windows (quiera o no).
Todo eso es debido a que este módulo se va a ensamblar, a su momento, con el
resto del sistema de control de stock y facturación que ya utiliza esta
estructura (aplicación VFP9 + BD PostgreSQL + SO Windows2000/XP).
En este momento se está usando la versión 8.2.3 del Postgres. Planificamos
instalar la 8.2.4 este fin de semana.

De todos modos, trataré de encontrar alguien que tenga Linux y el pyGestor,
para ver si consigo una copia de la estructura de su base de datos a fin de
poder analizarla y sacar mis conclusiones.

>> Estuve pensando en usar una base de datos principal y separar las
>> subempresas en diferentes esquemas. ¿Sería ese el camino?
>
> Esto se reponde preguntandote: Las empresas entraran a la base de datos
> directamente?

Aun no tengo bien definido si las subempresas entrarán directamente o si se
utilizará el sistema de replicación de datos (actualización off line). Si
esto es importante, crearé otro hilo cuando tenga esta definición.

> Ahora, si la contabilidad se lleva ordenadamente, los movimientos se
> ingresaran todos en su justo momento... Entonces no habran "descuadres"
> por que falto ingresar una factura, o un ingreso...etc.

Este siempre fué el gran problema aquí... muchas veces, luego hacer un
cierre y sacar los informes, se dan cuenta de que hay cosas que no fueran
ingresadas o algo fue ingresado indebidamente, etc. Incluso cosas referentes
al año pasado, pueden necesitar ser ingresadas en Enero, Febrero o hasta
Marzo de este año... Esto quiere decir que debo tener la posibilidad de
hacer cambios en el año anterior, sí o sí... Infelizmente no estoy viviendo
en un "ambiente ideal" y debo lidiar con muchas fallas humanas...

Saludos cordiales

Ricardo De Castro Aquino
Asunción - Paraguay

----- Original Message -----
From: "Juan Martínez" <jeugenio(at)umcervantes(dot)cl>
To: "decastro" <decastro(at)netvision(dot)com(dot)py>
Cc: <pgsql-es-ayuda(at)postgresql(dot)org>
Sent: Thursday, May 17, 2007 8:57 AM
Subject: Re: [pgsql-es-ayuda] Estructura contable para BD

> El Jue, 17 de Mayo de 2007, 4:17 pm, decastro escribió:
>> Hola grupo.
>>
>> Antes que nada, espero me disculpen lo largo de este mensaje. Pero es
>> necesario para explicar todo el tema.
>> Como notarán, estoy aun en los primeros pasos con PostgreSQL y el resumen
>> del tema es:
>> ¿Alguien me puede indicar cual es la mejor forma de manejar una base de
>> datos para un sistema contable?
>
> El modelo relacional sirve bastante para ese requerimiento.
>
>> Les explico, hace algún tiempo atrás he hecho algo semejante usando
>> Visual
>> Foxpro con base de datos y tablas nativas.
>> Allí teníamos las diferentes subempresas en subcarpetas del sistema
>> general y los distintos períodos contables (años) en diferentes
>> subcarpetas de cada empresa. Todo esto físicamente, en el disco.
>> Había un árbol de carpetas más o menos así:
>>
>> SISTEMA_CONTABLE
>> tablas generales
>> --> subempresa1
>> - tablas comunes
>> -> ejercicio2000
>> -> ejercicio2001
>> -> ejercicio2002
>> --> subempresa2
>> - tablas comunes
>> -> ejercicio2000
>> -> ejercicio2001
>> -> ejercicio2002
>> -->...
>>
>> Ahora que me piden pasar todo eso a una base de datos cliente-servidor (y
>> estoy pensando usar PostgreSQL) me doy cuenta que la cosa es bastante
>> distinta, desde el punto de vista estructural.
>
> Mmm...en el mercado hay suficientes software que ya hacen esto. Puedes
> mirar el proyecto pygestor, quizá te sirva.
>
>> La pregunta es: ¿cual es el mejor enfoque a utilizar para encarar ese
>> tipo
>> de estructura?
>
> Yo diria que casi cualquier estructura es optimamente implementable en el
> modelo relacional.
>
>> ¿Alguien tiene una estructura de ejemplo que me pueda
>> facilitar?
>
> Mira pygestor, es software libre, y hasta donde se, usa postgres para
> almacenar sus datos.
>
>> (puede ser un diccionario de datos o una simple descripción de
>> las tablas, campos y relaciones)
>>
>> Estuve pensando en usar una base de datos principal y separar las
>> subempresas en diferentes esquemas. ¿Sería ese el camino?
>
> Esto se reponde preguntandote: Las empresas entraran a la base de datos
> directamente?
>
>> Pero... ¿cómo hago con los años?
>
> Se almacenan sin problemas en un campo int2 :-)
>
>> ¿Los pongo todos en la misma bolsa?.
>
> Considerando que postgres 8.2 (si eres nuevo en postgres, esa version
> debes usar) tiene cantidad ilimitada de filas por tabla, no veo problemas
> a guardar todos los movimientos en una tabla. Normalizala y ve que se
> repite para dejarlo en otra tabla, eso si.
>
>> Me acuerdo que la ventaja de separar los años era en relación a la
>> apertura y cierre de cada ejercicio, lo que también facilitaba bastante
>> la
>> impresión de los libros y el tema de los balances, cuadros de resultados
>> y
>> todo lo demás...
>
> Eso puede ser una barrera mental de las personas y no del software.
>
> El tema del cierre de año tiene que ver con que si la fecha de los
> movimientos la ingresa el usuario o se genera automaticamente con la
> funcion ad-hoc al momento de insertar la fila.
>
> Cerrar un año, no es mas, que no ingresar mas movimientos para ese año...
> Ahora, si la contabilidad se lleva ordenadamente, los movimientos se
> ingresaran todos en su justo momento... Entonces no habran "descuadres"
> por que falto ingresar una factura, o un ingreso...etc.
>
> Probablemente, ese tema se soluciona con una pequeña tabla donde se
> establece el año en funcionamiento. Luego el software lee la tabla (o mas
> bien el registro del año activo) y le permite al usuario ingresar
> movimientos para ese año (esto con el modelo de que el usuario ingresa la
> fecha del movimiento, OJO fecha distinta a la fecha de registro del
> movimiento en el sistema o en la BD mas bien).
>
>> Confieso que hace bastante tiempo que no manejo ese tema, así que estoy:
>> un tanto herrumbrado por un lado (contabilidad)
>
> La contabilidad no es muy compleja. Lo complicado es lo metódico y
> sistemático que exige llevarla. Pero no esta demas que te hagas acompañar
> de un Contador (Auditor).
>
>> y muy verde por el otro (bds en postgres).
>
> Na...para eso estamos ;-)
>
> --
> Juan Martinez Linux user # 335778
> Departamento de Informática 499 7934 - 499 7992
> Universidad Miguel de Cervantes Mac Iver # 370 - Stgo. Centro - RM