Re: Estructura contable para BD

Sería muy bueno tambén que ademas de tus entidades de años y ejercicios
mencionaras otras entidades que intervienen en el proceso contable que tu
pretendes administrar, de esa forma podremos darte mas opiniones al
respecto, por lo pronto si te recomendaría leer referencias sobre bases de
datos y normalizaciones... a mi me sirvio mucho... jejejeje... aqui uno
aprende o aprende...

saludos...

On 5/17/07, Juan Martínez <jeugenio(at)umcervantes(dot)cl> wrote:
>
> 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
>
>
> ---------------------------(fin del mensaje)---------------------------
> TIP 4: No hagas 'kill -9' a postmaster
>

--
ISC. Mario Jimenez Carrasco
Ingeniero de Software.