Cual es la mejor forma de llevar registros contables en un sistema

[[AzidRain]]

Whaaatt???

[afxe]

Acabo de terminar un programa de contabilidad, está en fase de implantación en 30 empresas. La más grande lanza 200.000 apuntes por año, lo que es unos 16.000 apuntes mensuales. He usado Firebird con un sistema continuo, es decir, un solo fichero de movimientos contables sin cierres físicos (sí se graban los asientos de regularización, cierre y apertura, pero no se crean tablas nuevas). No obstante, sí uso un fichero de saldos, el registro se compone de : cuenta, ejercicio, mes, debe y haber (a grosso modo). El mes va desde cero (saldo de apertura) hasta 14 (1=enero, 2= febrero... 13= Regularización, 14=Cierre). Este fichero se automantiene mediante triggers sobre el fichero de movimientos, en transacciones únicas, con lo cual es difícil que se corrompa, no obstante, siempre hay que tener previsto el famóso "Recálculo de Saldos".

El archivo de saldos "ES NECESARIO". No debes abusar de las consultas, sobretodo cuando además tienes que hacer agrupaciones, porque quieras sacar un balance de suma y saldos a nivel 3, por ejemplo, o en un comparativo interanual. Ese tipo de consultas dejarían frito al servidor. Para ello, me sirvo de 2 tipos de consultas: Una por rango de fechas, de la cual tiro de consultas directamente sobre el fichero de movimiento (procuro no dar muchas opciones al usuario para este tipo de consultas) y otra por rango de "periodos", es decir, doy a elejir ejercicio y mes, pero no día, y lanzo las consultas sobre el fichero de saldos, mucho más rápido y menos pesado que el de movimientos. Además, las consultas comparativas o mensuales salen casi directamente, no hay que llevar tablas temporales de acumulados.

No me ha ido mal, pero tienes que currarte más el tema de la contabilidad presupuestaria y la fiscal.

De todas maneras, al final siempre hay que hacer un proceso para descargar datos ¿Para qué quieres tener la contabilidad de hace 5 o 6 años? Sólo sirve para que las copias de seguridad tarden más y las consultas sean más lentas.

Saludos.

[Casimiro Noteví]

Empezado por afxe

[..]El archivo de saldos "ES NECESARIO". No debes abusar de las consultas, sobretodo cuando además tienes que hacer agrupaciones, porque quieras sacar un balance de suma y saldos a nivel 3, por ejemplo, o en un comparativo interanual. Ese tipo de consultas dejarían frito al servidor.[..]

Aunque no me gustan los saldos guardados en tablas, prefiero calcularlos, he de decir que en este caso parece lo más razonable. En estos días ando en pruebas para algo similar y parece que es lo más aconsejable.

Empezado por afxe

[..]¿Para qué quieres tener la contabilidad de hace 5 o 6 años?[..]

Porque es obligatorio, hay que mantenerlas por ley (aunque sea en papel).

[afxe]

Porque es obligatorio, hay que mantenerlas por ley (aunque sea en papel).

Cierto, no me he explicado bien. Lo que quería decir es: ¿Por qué mantener en la misma base de datos movimientos de 5 o 6 años?. En la práctica, no hay estadistas que manejen comparaciones de más de 3 años... incluso los más quisquillosos sólo suelen hacer comparaciones de un año con el anterior. Aunque preparo mis aplicativos para mantener tantos años en la misma B.D. cómo quiera el usuario, siempre aconsejo tener las bases de datos con 3 años. Pero eso no quiere decir que eliminen datos antigüos, sino que la tengan en bases de datos diferentes: BD2002_2004.GDB , BD2003_2005.GDB... a principios de este año creamos la base de datos BD2004_2006.GDB y sacamos de la BD de trabajo el año 2004.

El guardar tres años consecutivos es para poder realizar consultas comparativas entre esos periodos, activando la BD que crean conveniente. Hay que quieren tener cinco años consecutivos y otros que quieren tener sólo 2 años... pero eso deja de ser nuestro problema.

Saludos

[Casimiro Noteví]

Estoy de acuerdo en lo que comentas, no sirve para nada tener que "cargar" con los datos de hace 5 años

[marcoszorrilla]

La mayoría de los programas comerciales lo que hacen es crear un sistema de tablas por año.

Es decir creamos la empresa Pepe_Perez_07 el sistema crea todas las tablas necesarias.

Al final del año.
1.- Creamos Pepe_Perez_08
2.- Cerramos el ejercicio Pepe_perez_07 nos pregunta dónde vamos a continuar, es decir en donde se va a efectuar el asiento de apertura, le decimos que en Pepe_Perez_08, nos cierra el ejercicio 07 y nos traspasa las cuentas y saldos a Pepe_Perez_08.
3.- En Pepe_perez_07 no nos debe dejar nada más que consultar, puesto que el ejercicio ya se cerró.
Por lo tanto se contabilizaron las existencias a final de ejercicio, se efectuaron las amortizaciones correspondientes y se cumplimentó el IVA con las operaciones correspondientes a las cuentas 472, 477, 475 etc.

En conclusión a mi me parece correcto que cada año este "el Diario" en una tabla distinta y que esta quede en solo lectura una vez cerrado el ejercicio, teniendo acceso total solamente al ejercicio actual.

Un Saludo.

[Casimiro Noteví]

Pues sí, me parece correcto, así.

Por cierto, yo no entiendo la manía de reinventar la rueda que tienen los jefes, el año pasado estuve en un proyecto de programa de contabilidad y ahora parece que se va a iniciar otro para hacer otro programa de contabilidad (para otro cliente).
Conversación jefe<>yo
jefe: vamos a tener que hacer otro programa de contabilidad para yyyyyy
yo: ¿otro?, ¿no le vale el que hicimos el año pasado para xxxxx y para zzzzzz?
jefe: no, es que yyyyyy quiere uno personalizado
yo: ya, bien, le ponemos el logo de su empresa, pero es que es 'una contabilidad' estandar y normal.
jefe: el cliente paga
yo (con cara de resignación): no lo entiendo, si tenemos el otro programa y hay además varios proyectos opensource que puede usar también, que es una simple contabilidad.
jefe: ya.
yo: vale.