base de datos de Contabilidad - almacenar una transacción

Question

Haces una página web de juego donde el usuario puede comprar créditos de juego y los fondos se depositan/acreditado en cuenta virtual del usuario para jugar algún juego etc ... etc ..

Si usted tiene un contador para registrar la transacción, que se registrarían como esto (tal vez un poco más complejo, pero usted consigue el punto)

TRANSACTION 
PK_ID1 Cash  - $10 (System) 
PK_ID2 Deposit  $10 (System) 

TRANSACTION 
PK_ID3 Bank Account  - $10 (John) 
PK_ID4 Deposit  $10 (John) 

Como desarrollador, ¿realmente necesita perder 2 registros adicionales? ¿por qué no grabar así ... (entonces es posible almacenar información en los fondos provenían de, situación en el resto de las columnas bajo el mismo registro de depósito)

TRANSACTION 
PK_ID1 Cash  - $10 (system) 
PK_ID2 Deposit  $10 (John) 

¿Hay alguna ventaja real de la opción # 1 sobre la opción # 2 y vice visa?

EDITAR: modificó la pregunta, eliminó CR, DR y la reemplazó con un signo.

Answer 1

(en respuesta a su pregunta, sino también responder algunas cuestiones planteadas en la respuesta de paxdiablo.)

No tiene nada que ver con el contador mirar dentro de su base de datos. Con la entrada doble, los errores son fáciles de rastrear; es un requisito de Contabilidad y IRS, por lo que realmente no tiene otra opción, necesita una doble entrada para cualquier sistema que maneje fondos públicos.

• (Por favor, no trato de decirme lo que "por partida doble" es;. He escrito sistemas de doble entrada para los bancos, para auditar los requisitos) por partida doble es un método de contabilidad, basado en un conjunto de cuentas. Cada transacción financiera es Journal Entry; si todas las transacciones se volvieran a aplicar desde el principio, todas las cuentas tendrían exactamente el mismo saldo que tienen hoy.

• Entrada doble significa que cada transacción tiene una cuenta "A" y una cuenta "De"; el dinero nunca abandona el sistema o ingresa al sistema. Cada crédito tiene un débito adjunto.

• Por lo tanto, (1) no es la versión de "doble entrada" de (2), no se pueden comparar fácilmente. La versión de doble entrada de transacción de Juan es (una transacción financiera), en términos de contabilidad lógicas:

  • Desde: JohnAccount Para: SystemAccount Cantidad: 10.00 (dólares)

  • que bien puede haber dos filas de una tabla, una a crédito y la otra a un débito, las dos inserciones envueltas en una Transacción SQL.

• Eso es para el sistema de contabilidad, que es interno, y se ocupa de dinero. Hemos terminado.

• Pero también está casando el sistema de contabilidad con un sistema de compra/venta (sin haberlo declarado explícitamente). Por supuesto, por los diez dólares que le sacaste a John, debes darle lo que haya comprado para él y registrarlo. John compró diez dólares de valor de créditos de juego, si realiza el seguimiento que, entonces sí, también es necesario:

  • Desde: SystemGamingAccount Para: JohnGamingAccount Cantidad: 100 (créditos)
    o, expresado en dólares:

  • Desde: SystemGamingAccount Para: JohnGamingAccount Cantidad: 10.00 (dólares)

  • Eso, también, bien puede haber dos filas de una tabla, una de ellas de crédito y la otra una tarjeta de débito, los cuatro insertos envueltos en una transacción de SQL.

• Para que quede claro, si vende reproductores en lugar de créditos de juego, el segundo (seguimiento Widget) transacción sería:

  • Desde: Warehouse Para: PublicSale Cantidad: 1 (widgets)

  • y dado que está siguiendo las unidades en el almacén, pero no cuántos widgets tiene John Q Public en su bolsillo, es decir, dos insertos más una actualización (UPDATE Part SET QtInStock = QtyInStock - 1 WHERE PartCode = "Widget"), todos envuelto en una transacción SQL.

Y hay una cuenta para cada usuario, a la derecha. Virtual, esotérico o físico, es una entidad jurídica contra la cual se realizan las transacciones. Así que no pretendamos que no existe porque es virtual. Para juegos, cuenta de un dólar más una cuenta de juego (crédito).

de Crédito/Débito

Yo pondría la CR/DB de vuelta en; no CHAR (2), sino booleano.Esto ayudará a que más tarde, cuando la tabla es grande,

WHERE IsCredit = 1 

es mucho más rápido que

WHERE Amount >= 0. 

Tenga en cuenta que con "> =" usted tiene que asegurarse de que cada segmento de código se codifica de la misma manera, no ">" a veces. Boolean o char no tiene ese problema.

Answer 2

En términos de los datos (que es lo que estás preguntando), no. Debe almacenarlo como un valor firmado. La contabilidad de doble entrada no es algo que la mafia hace para ocultar los beneficios reales del IRS :-)

Significa que la transacción debe equilibrarse (el valor nunca se crea o destruye, simplemente se transforma). Y será mucho más fácil equilibrar las transacciones (y los libros) si solo los almacena en una columna con un letrero.

En términos de presentación visual, a algunos contadores les pueden gustar en columnas separadas, pero la gran mayoría generará informes con los "negativos" simplemente indicados de manera diferente (como rodearlos con paréntesis).

Puede ser que (como muchas otras cosas de contabilidad), las columnas duales se lleven desde hace muchas lunas. Sería más fácil agregar dos columnas y luego restar el total negativo del total positivo para obtener la posición actual (en lugar de sumar y restar de forma entremezclada). Pero eso es suposición de mi parte.

Véase también here.