Diseño de base de datos de contabilidad de doble entrada

Estoy creando software de contabilidad. Necesito hacer cumplir la contabilidad de doble entrada. Tengo el problema clásico de una fila por transacción versus dos filas.

Tomemos un ejemplo y veamos cómo se implementaría en ambos escenarios.

Considere cuenta Cashy cuenta Rent. Cuando pago mi renta mensual, transfiero $ 100 de mi Cashcuenta a mi Rentcuenta.

Una fila por transacción

En un sistema de una fila, dicha transacción se almacenaría como:

actas

 tx_id | posting_date
 1     | 23/05/2015

transacción_records

 id | tx_id | credit_account | debit_account | amount
 1  | 1     | Cash           | Rent          | 100.00

Dos filas por transacción

En un sistema de dos filas, tendría que reflejar el mismo registro de transacción para crear un registro opuesto que una vez que sume ambos, obtendría un saldo cero.

actas

 tx_id | posting_date
 1     | 23/05/2015

transacción_records

id  | tx_id | type   | account | amount
1   | 1     | credit | Cash    | 100.00
2   | 1     | debit  | Rent    | 100.00

El problema

En primer lugar, me gustaría señalar: la razón por la que tengo ambas transactionsy transaction_recordstablas (en lugar de una tabla) es para poder manejar transacciones divididas (un caso en el que transfiero $ 100 de la Cashcuenta a dos o más cuentas diferentes).

Al principio traté de implementar esto con una fila por transacción, pero es difícil calcular el saldo de la cuenta y recuperar los datos.

Me estoy inclinando hacia el segundo escenario; Sin embargo, también tiene algunos problemas:

• ¿Cómo actualizo un solo registro? Asumiendo que he cometido un error y en lugar de registrar $ 100 por mi renta, he registrado $ 10. Ahora tengo 2 transaction_records: uno para crédito y otro para débito, ambos con un monto de $ 10.
• Ahora hago mi reconciliación y quiero arreglar este error tipográfico. ¿Cómo solucionaría esto en la base de datos? No sé la conexión entre los registros, y en caso de división, una transacción puede tener más de 2 registros. La única solución que se me ocurrió es agregar algunos ref_idpara cada par de registros que identifiquen de forma única esos registros como los "lados opuestos entre sí" dentro de un contexto específico tx_id.

¿Qué enfoque es mejor / más simple?

Para simplificar mi pregunta: quiero representar un movimiento de fondos de la cuenta A a la cuenta B. Los dos escenarios que di son ambos diseños válidos para almacenar dicha transacción. Como también señalé, ambos tienen inconvenientes y ventajas (el primero: más fácil de guardar, más difícil de recuperar; el segundo es lo contrario).

Es posible que tengan otros pros / contras que no veo en este momento, por lo tanto, pido una opinión de personas más experimentadas.

De hecho, el esquema contable de una sola fila propuesto permite realizar una contabilidad de doble entrada adecuada (para especificar siempre la cuenta debitada y acreditada) sin introducir la redundancia de los datos de "importe".

El esquema de una fila le brinda una implementación de una entrada doble que se equilibra por construcción, por lo que es imposible "perder el equilibrio". La máquina puede recalcular los libros de contabilidad sobre la marcha.

Tienes que hacer 2 selecciones en lugar de una para recuperar un libro mayor.

Tenga en cuenta que, además de la división de transacciones, hay otras transacciones, como el cambio de divisas que podría terminar con 2 registros en lugar de 4. Todo depende de si se desnormalizaría un poco, simplemente ingrese 4 transacciones con una descripción similar.

Puede evitar la entrada o modificación de cualquier transacción para mantener un seguimiento de auditoría, esto es necesario si desea poder auditar el registro de transacciones.

Parece que en el hilo anterior, para el CPA, "completamente normalizado" parece significar reglas reconocidas por todos los contadores, mientras que para el programador tiene un significado diferente, que no hay datos derivados o redundantes almacenados.

Lo único que hay para los datos contables es un conjunto de transacciones que dan el monto y las cuentas de las cuales y hacia las cuales fluyen, junto con su fecha, alguna descripción (y otros archivos adjuntos). Los libros mayores y los saldos son vistas simples derivadas de estos datos transaccionales al hacer sumas.

Un diario es una lista cronológica de todas las transacciones de un tipo específico para un sistema de contabilidad. Aquí hay una presentación clásica en papel contable de un simple diario de ventas (en cuenta):

Tenga en cuenta que cada línea es una transacción única, con débitos totales = créditos totales; y que cada transacción llega a las mismas tres cuentas. Un diario de ventas en efectivo se vería similar pero reemplazaría la columna Débito de cuentas por cobrar con una etiqueta Débito en efectivo . Un Diario de desembolsos en efectivo tendría una primera columna denominada Crédito en efectivo y columnas adicionales como Débito de cuentas por pagar y Débito de gastos de empleados .

Esta presentación fue estándar durante cientos de años hasta que las computadoras personales se volvieron asequibles hace un par de décadas. Tiene una ventaja significativa de verificar fácilmente que cada transacción se equilibra simplemente verificando cada fila. Del mismo modo, antes de publicar una página de dicha transacción en los Ledgers, los totales de la página podrían verificarse de manera similar. Ese es un modelo de procesamiento por lotes utilizado en muchos sistemas de contabilidad.

Es fácil ver que este modelo de papel tiene desventajas significativas cuando se transcribe literalmente a un sistema automatizado:

1. La estructura de datos es dinámica, mientras que la experiencia ha demostrado que es mucho más simple (también más robusto y más fácil de verificar) programar contra una estructura de datos plegada; y
2. Debido a que cada diario especializado llega a un conjunto diferente de cuentas, cada uno de esos diarios debería diseñarse y programarse por separado, una actividad inútil y propensa a errores.

Por estas razones, generalmente se recomienda utilizar el diseño de Revistas especializadas como interfaz para el sistema de contabilidad, pero diseñar una estructura de datos que pueda ser el depósito numérico para múltiples publicaciones. En un RDBMS moderno, esto tiene la ventaja potencial que el Libro mayor , e incluso el especialista libros auxiliares , pueden convertirse en Vistas indexadas en el Diario, eliminando por completo el requisito de codificar un Proceso de contabilización (el paso donde una transacción del Diario está bloqueada y tiene su cuenta totales transcritos a los diferentes libros de contabilidad).

Independientemente del diseño de datos que termine, la clave es tener un solo entrada de contabilización para cada tipo de transacción (es decir, cada diario especializado en el sistema de papel equivalente) donde se realizan las comprobaciones de saldo.

Mi punto es que ambos enfoques que propone son mecanismos poco sólidos para la contabilidad de doble entrada. Primer punto: las revistas son tablas de escritura única por muy buenas razones. En ocasiones, las dos tablas virtuales Entradas pendientes y Entradas publicadas se colocan en una sola estructura de datos, pero el bit IsPosted siempre es de solo escritura y el sistema debe garantizar que se mantenga la naturaleza de solo lectura de los registros de Entradas publicadas.

La forma en que los contadores han publicado entradas en el diario durante los últimos 800 años está completamente normalizada . La única diferencia entre una presentación en papel y una presentación electrónica de sonido es que una estructura de tabla doblada es más conveniente en el último caso, mientras que una estructura de tabla pivotada en el primero, que históricamente fue más significativa cuando se deseaba un procesamiento altamente paralelo, es decir, muchos empleados cada uno mantener un número único o pequeño de revistas especializadas. Solo el Controlador históricamente tenía permisos para el Diario General.

Tenga en cuenta cuidadosamente que en lo anterior especifiqué que las entradas de diario están completamente normalizadas; Las entradas de diario son un registro cronológico de todas las transacciones, agrupadas en diarios específicos para cada tipo de transacción. La publicación de asientos de diario en el Libro mayor es una tarea separada y, aunque está completamente normalizada por sí sola, es una copia redundante de los asientos de diario donde todas las transacciones se resumen (Libro mayor general) o se detallan (Libro mayor secundario) por cuenta. Tanto las revistas como los libros de contabilidad emplean la contabilidad de doble entrada de forma independiente.

@Codism Cualquier sistema de contabilidad, DEB o SEB, le brinda informes generalizados para todas las cuentas registradas . Tenga en cuenta que, internamente, un sub-libro mayor es, por definición, un registro de contabilidad de una sola entrada; el otro lado son las cuentas de control correspondientes en el Balance general. DEB asegura que por cada dólar de activos exista un registro preciso del reclamo comercial sobre el activo , es decir, el patrimonio del activo, ya sea un patrimonio de deuda (también conocido como pasivo) o un patrimonio propio , y de la prioridad de esos reclamos si el la organización se vuelve insolvente.

¿Puedo sugerirle que eche un vistazo al tesoro del software de código abierto que existe en esta área?

Un Google de " software de contabilidad de doble entrada de código abierto " ofrece varias vías prometedoras de investigación.

Puede consultar el paquete de contabilidad de GNU aquí , un par de sitios de revisión ( 1 y 2 ) y finalmente la wiki del software de contabilidad con una sección sobre Software libre.

Estoy seguro de que al examinar algunos de los esquemas y el código fuente de F / LOSS, puede obtener algunos buenos consejos e indicaciones sobre cómo escribir esquemas y / o software que se adapten a sus necesidades particulares.

Tengo un sistema que hace líneas dobles y tiene muchos desafíos que tener cuentas de líneas simples. Primero, he encontrado instancias de solo una línea presionada como el lado de débito, lo que resulta en una cuenta desequilibrada. Incluso si no estoy haciendo los controles adecuados de compromiso y retrocesos, esto no sucedería en cuentas de una sola línea. Por último, su base de datos crece en una tasa de crecimiento doble, su segunda línea de envío tendrá mucha información duplicada, la única diferencia es la segunda cuenta. Aconsejaría retener, cuenta de línea única, voy a esa ruta ..