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

[[AzidRain]]

A propósito de saldos contables...tengo una inquietud sobre el manejo de los archivos de las distintas cuentas...

Casi todos los paquete contables usan una tabla o archivo por cada cuenta individual, algunos usan una tabla maestra y otra con el detalle. En la maestra guardan el saldo y demás info. El problema es que cuando no cierran bien el sistema, se cae, se bloquea o algo similar, algunos saldos quedan volando y no se actualizan. Hay incluso un sistema que mantiene copias de estas tablas por cada periodo. Al cerrar y abrir un nuevo periodo, se crea una nueva copia de las tablas y se le pone el saldo del mes anterior, comenzando con tablas en limpio y asi sucesivamente. El problema es cuando queremos mover un movimiento de un periodo ya cerrado...un merequetengue.

Yo me h preguntado si no es mejor tener una sola tabla que contenga todos los movimientos y para saber el saldo simplemente un query como el del ejemplo y listo. De esta forma aun haciendo movimientos a periodos pasados el saldo se actualiza casi inmediatamente. Al igual que al generar los reportes clásicos (balanzas, auxiliares, estados de resultados,etc.) simplemente se corre un Query y ya, es más ni siquiera veo necesario "cerrar" fisicamente los periodos, aunque claro se supone que no hay razón para estar haciendo movimientos atrasados.

Ustedes que opinan.

(Por cierto hace falta una aplicacion Open Source de este tipo, ya sea para Linux o Win, ya que las pocas que hay no están muy completas o estan muy regionalizadas (BulmaGes y Cia.)

[JXJ]

Pues. que a mi me gustaria saber, que software
comercial o free o opensource, y en delphi mejor.

Existen
Dijamos por aca en México, y los demas paises

Yo no se como se hace eso de llevar un libro de registros contables
o como se puede llevar en software, o cualquier documento
decentemente escrito, tipo nota de venta, es aceptable
por los sistemas recaudadores de impuestos,, en México y/o en America.
Europa, y demas continentes

[[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 Notevi]

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 Notevi]

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 Notevi]

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.

[[AzidRain]]

Me parece razonable la idea de marcoszorilla, de hech pensaba dejar disponible todo un ejercicio y poder manipularlo como se quiera y como estamos hablando de SQL (usare MySQL) no tiene porque volverse loco el servidor. Además pocas consultas, si no es que ninguna, requeririan traerse todos los registros, a lo sumo estaran pidiendo periodos de un mes como máximo o bien si piden periodos mas largos serán correspondients a algunos criterios muy precisos por lo que las consultas traeran solo una pequeña fracción de los registros.

Otra cosa distinta son los balances, estados de resultados y demás que ahi si harían agrupaciones y cosas así pero insisto, en teoría al menos, un motor de BD que se precie de llamarse así no debe tener problemas para manejarlo y suponiendo que en efecto sean procesos un poco lentos, tambien es cierto que no se requeririan salvo cada mes o de vez en cuando.

[[Caral]]

Hola
Pues que coincidencia, acabo de tener una conversacion con mi contador con respecto al control de los bancos.
Tengo una tabla por banco, en esta esta toda la informacion, el problema que se me presenta en que esta detallada, describo:

fecha, deposito #1 factura2, cliente1, monto 100, saldo 1000
fecha, deposito #1 factura3, cliente1, monto 200, saldo 1200
fecha, cheque #4 pago1, proveedor2, monto 100, saldo 1100
fecha, cheque #4 pago2, proveedor2, monto 100, saldo 1000

Bueno esa es la idea, osea que esta muy detallada, y bueno mi contador la quiere facil:

fecha, deposito #1 cliente1, monto 300, saldo 1200
fecha, cheque #4 proveedor2, monto 200, saldo 1000

Ademas la quiere en exel, osea
Suena facil de arreglar con una sentencia sql, pero no me aclaro para nada, en otras palabras si sigue asi, cambio de contador y ya esta.
Es la mejor solucion.
Saludos

[[AzidRain]]

Yo pongo o en negativo los retiros para hacerlo más facil.
de forma que debe quedar algo asi en los datos:

fecha, deposito #1 factura2, cliente1, monto 100, saldo 1000  
fecha, deposito #1 factura3, cliente1, monto 200, saldo 1200 
fecha, cheque #4 pago1, proveedor2, monto -100, saldo 1100 
fecha, cheque #4 pago2, proveedor2, monto -100, saldo 1000

Código SQL [-]
SELECT FECHA, DEPOSITO, CLIENTE, SUM(MONTO), SUM(SALDO)+sum(monto) FROM BANCO GROUPY BY CLIENTE

Aclaro que no soy muy experto en SQL y con frecuencia recurro a algún recetario para hacer las consultas pero mas o menos es asi la cosa

Afortunadamente uso QuantumGrid de DeveExpress y en estos casos solo diseño bien la consulta, cuando ya me da lo que quiero, se la pongo a la grilla, la pongo guapa (totales y demás) y listo. La puedo pasar a Excel, Word o PDF usando las funciones que traen las Quantum y sin hacer nada...