- Aunque los términos contables resulten poco familiares, si se la ve como una estructura para seguir cuentas y saldos a lo largo del tiempo, la contabilidad de partida doble puede entenderse como un modelo de flujo de dinero
- Una tabla que solo sobrescribe el saldo actual pierde el proceso de cambio, pero un libro mayor agrega una partida cada vez que ocurre una transacción, dejando historial y rastros de correcciones
- La contabilidad de partida simple puede ser suficiente para registrar cambios por cuenta, pero cuando varias cuentas se mueven juntas, hay que agrupar las partidas relacionadas como una transacción para mostrar el origen y el destino
- En la contabilidad de partida doble, en cada transacción el monto que sale y el monto que entra deben ser iguales, y esta condición de equilibrio ayuda a detectar errores como una suma de verificación en la contabilidad manual
- Si vemos las cuentas y las transacciones como nodos, y las partidas de débito y crédito como aristas dirigidas, los libros contables se convierten en un grafo dirigido que crece con el tiempo, y los estados financieros también pueden verse como visualizaciones de ese grafo
La información que se pierde al registrar solo saldos
- La contabilidad consiste en seguir a lo largo del tiempo objetos que se pueden contar; aquí nos enfocamos en el flujo de dinero
- En el ejemplo, se parte del 1 de enero de 2024, cuando Alice tiene $100 y Bob tiene $50
- Si Alice le paga a Bob $20 por un libro, el saldo de Alice pasa a $80 y el de Bob a $70
- Aquí, una cuenta (account) es el lugar donde se guarda el dinero, y un saldo (balance) es la cantidad de dinero que hay en una cuenta en un momento determinado
- Si solo se sobrescribe el saldo actual, es difícil saber por qué Alice llegó a tener $80
- No se puede distinguir si empezó con $0 y recibió $80
- o si tenía $10,000 y gastó $9,920
- Un método que solo conserva instantáneas de saldos borra el proceso por el que ocurrieron los cambios
Libro mayor de partida simple y registros inmutables
- Para conservar el historial de cambios, cada vez que ocurre una transacción hay que agregar una fila nueva sin modificar los valores existentes
- Una partida del libro mayor suele incluir la siguiente información
- Description: una descripción legible para humanos, como el detalle de la transacción, el destinatario del pago o un número de referencia
- Date: la fecha en que ocurrió la transacción; también puede usarse para agrupar por períodos, por ejemplo en reportes mensuales
- Balance: el saldo de la cuenta después de la transacción; es información redundante, pero útil para revisar los datos
- Cada fila es una partida (entry), y el conjunto de partidas de una cuenta es un libro mayor (ledger)
- En el libro mayor de Alice se registra un opening balance de $100 el 1 de enero de 2024, y bought book por -$20 el 1 de febrero de 2024
- En el libro mayor de Bob quedan registrados opening balance por $50 y sold book por $20
- Este método es un sistema de contabilidad de partida simple (single-entry bookkeeping)
- Cada cuenta tiene su propio libro mayor
- Se registran partidas que afectan a una cuenta a la vez
- Puede funcionar bien para negocios pequeños o finanzas personales
El libro mayor funciona como event sourcing
- Una característica importante del libro mayor es que los datos son inmutables (immutable)
- Una vez escrita una partida, no se modifica, para preservar todo el historial
- Si el precio real era $30 pero el libro se registró por error como $20, cambiar la fila existente haría que se perdiera tanto el monto original como el hecho de que hubo una corrección
- Una mejor forma es agregar una nueva partida que compense la existente y luego ingresar la partida correcta
- Se cancela la partida de -$20 con +$20
- Luego se registra una nueva partida de -$30
- El saldo final es el mismo, $70, pero quedan registrados el error y el motivo de la corrección
- Este enfoque se parece al event sourcing de la informática
- Se almacenan los eventos ocurridos en el sistema
- Se calcula el estado actual reproduciendo los eventos
- Se puede reconstruir el estado en un momento específico
El momento en que se necesita la partida doble
- En transacciones donde varias cuentas se mueven juntas, solo con partida simple es difícil ver claramente la relación
- Los -$20 de Alice y los +$20 de Bob son el mismo dinero, pero con libros mayores simples no se puede distinguir de la posibilidad de que Bob haya recibido dinero de Charlie
- Al agrupar las partidas relacionadas como una transacción (transaction), se puede indicar explícitamente que pertenecen al mismo evento
- Transaction 1: opening balance de Alice
- Transaction 2: opening balance de Bob
- Transaction 3: Alice le compra un libro a Bob
- Una transacción es un grupo de partidas relacionadas que afectan a distintas cuentas
- La contabilidad de partida doble conecta las partidas relacionadas a nivel de transacción para poder ver el flujo de dinero entre cuentas
Débito, crédito y condición de equilibrio
- La contabilidad tradicional expresa el flujo de dinero en dos columnas: debit y credit
- Credit: una partida en la que el dinero sale de la cuenta
- Debit: una partida en la que el dinero entra a la cuenta
- Si Alice le paga $20 a Bob, la cuenta de Alice se registra con un credit de $20 y la cuenta de Bob con un debit de $20
- Los términos credit/debit de las tarjetas bancarias y los términos debit/credit de la contabilidad se usan de forma diferente
- En los libros en papel se usaba el formato de T-account, que divide el lado izquierdo como debit y el derecho como credit
- En sistemas informáticos no es necesario mantener dos columnas
- Se puede poner Debit o Credit en una columna
Typey tenerAmountpor separado - O se puede usar una sola columna de monto, definiendo los credit como negativos y los debit como positivos
- Se puede poner Debit o Credit en una columna
- En lugar de los términos tradicionales, dinero entrante y dinero saliente pueden ser expresiones menos confusas
Las transacciones no se limitan a dos partidas
- El principio central de la contabilidad de partida doble es que, después de cada transacción, la suma total de dinero del sistema no cambia
- El saldo de una cuenta específica puede subir o bajar, pero la suma de los saldos de todas las cuentas debe permanecer constante
- Para que un opening balance también esté equilibrado, el dinero tiene que salir de algún lado
- En el ejemplo se agrega una cuenta Bank para registrar que los $100 de Alice y los $50 de Bob salieron de Bank
- Esta cuenta Bank es una especie de cuenta temporal para respetar la regla y, en términos contables, corresponde a una contra account
- En toda transacción, el dinero que sale y el dinero que entra deben ser iguales, y esto funciona como una suma de verificación (checksum) para detectar errores en la contabilidad manual
- Las transacciones complejas también pueden modelarse con el mismo principio
- Alice le paga $20 a Bob y $2 de comisión por cambio de divisas a la empresa de tarjeta de crédito
- Bob recibe $20 de Alice y paga $2 de impuesto a las ventas a la autoridad fiscal, y $1 de comisión a la empresa de tarjeta de crédito
- La empresa de tarjeta de crédito recibe $2 de Alice y $1 de Bob
- La autoridad fiscal recibe $2 de Bob
- En este caso, una sola Transaction 3 incluye exactamente 8 partidas
- “Double-entry” no significa que una transacción tenga solo dos partidas, sino que tiene dos lados: el lado por donde sale el dinero y el lado por donde entra
Ver los libros contables como un grafo dirigido
- La contabilidad de partida doble puede verse como un modelo del flujo de dinero mediante un grafo dirigido
- La correspondencia con el grafo es la siguiente
- Las cuentas son nodos del grafo
- Las transacciones también son nodos separados
- Una partida Credit es una arista saliente que va desde la cuenta hacia la transacción
- Una partida Debit es una arista entrante que va desde la transacción hacia la cuenta
- El monto de la partida es el valor de la arista
- El saldo de una cuenta es la suma de las aristas entrantes menos la suma de las aristas salientes
- Transaction 1 mueve $100 de Bank a Alice
- Transaction 2 mueve $50 de Bank a Bob
- Transaction 3 mueve $20 de Alice a Bob
- En esta representación, el saldo de Alice es $80 y el de Bob es $70
Elegir cómo modelar dividiendo transacciones complejas
- Si se incluyen todas las comisiones e impuestos en una sola transacción, Transaction 3 queda con muchas aristas y se vuelve compleja
- El mismo flujo de dinero también puede dividirse en transacciones más pequeñas
- De la cuenta de Alice salen $22
- Bob recibe $19
- Los $3 restantes van a la empresa de tarjeta de crédito
- El impuesto a las ventas de Bob de $2 se procesa como una Transaction 4 separada
- Según cómo se agrupen las transacciones y las partidas, los saldos finales de las cuentas pueden ser los mismos
- Alice: $78
- Bob: $67
- Tax authority: $2
- Credit card company: $3
- Los sistemas contables son lo bastante flexibles para cubrir distintas necesidades, y la forma de agrupar transacciones y partidas debe decidirse según el negocio
Los estados financieros son visualizaciones del grafo
- El grafo crece con el tiempo a medida que se agregan nuevas transacciones
- Sus propiedades básicas se mantienen
- Las cuentas siguen siendo nodos
- Las transacciones siguen siendo nodos que imponen el flujo de dinero
- En cada transacción, la suma de los montos salientes y la suma de los montos entrantes deben ser iguales
- El balance sheet, el income statement y el cash flow statement pueden verse como visualizaciones de este grafo
- Clasificaciones como assets, liabilities, equity, income y expenses pueden verse como grupos de nodos dentro del grafo
- Desde la perspectiva del grafo, resulta más intuitivo entender cómo credit y debit aumentan o reducen el saldo de cada clasificación
1 comentarios
Opiniones de Hacker News
Explicar la contabilidad de partida doble como “un asiento para Alice, un asiento para Bob” parece una elección rara.
Si hay dos partes en una transacción, es obvio que puede registrarse en dos lugares, pero el punto central es que se necesitan dos asientos para cada parte de la transacción. Si Alice le compra un libro a Bob, se generan cuatro asientos.
Entiendo que es una simplificación didáctica, pero me parece una simplificación excesiva que elimina lo esencial.
Por ejemplo, al pagar cuentas por pagar con efectivo, sería como enviar un mensaje simultáneamente al actor Accounts Payable y al actor Cash, y cada actor traduce ese evento a débito/crédito según su propia naturaleza para mantener su saldo. Desde esta perspectiva, la partida doble se parece más a que cada evento debe ser absorbido exactamente una vez por un número par de actores.
Si estás construyendo rieles de pago, ese evento en sí también podría ser uno de un par de eventos derivados de un metaevento que rastrea la intención de la transacción. En contabilidad, es más útil ver las aristas del grafo no como dinero, sino como datos dentro de una jerarquía de eventos derivados.
Dicho eso, el texto original no deja claro para qué sirve esta analogía, y me preocupa que aumente la confusión en vez de reducirla.
No me importan los libros contables de Bob; solo quiero seguir mis propios libros. Si compré un libro, lo que quiero saber es cómo debería registrar esta transacción con partida doble en mi contabilidad.
Además, Bob no está llevando libros contables, está vendiendo un libro ;-)
¿Cómo habría que corregir este texto para explicar bien la parte de “double”? ¿Se puede hacer solo desde la perspectiva de Bob o de Alice?
Por ejemplo, un banco puede decidir que probablemente no voy a pagar un préstamo y reducirlo a 0 en sus libros. Yo puedo seguir teniendo la intención de pagarlo y dejar la deuda en mis libros. El banco crea los asientos correspondientes en su sistema y los débitos/créditos cuadran; aunque yo no haga nada, mis libros se mantienen balanceados.
La contabilidad de partida doble no depende de otros sujetos; trata únicamente de los propios libros.
Creo que la belleza y la influencia de la contabilidad están subestimadas.
Con un número muy pequeño de fórmulas, es decir, la ecuación contable, y estados financieros como el estado de resultados y el estado de situación financiera, se puede expresar lo que ocurre en una organización de una manera aproximadamente comparable. Me recuerda al teorema fundamental del cálculo o al dogma central de la biología.
La contabilidad también es el origen de las matemáticas y del lenguaje escrito. Las antiguas civilizaciones mesopotámicas usaban al principio “fichas contables” con la forma de los objetos para rastrear mercancías, y puede verse cómo eso evolucionó hacia el lenguaje escrito, por ejemplo, los jeroglíficos.
Más tarde, Al-Khwarizmi creó Al-Jabr, es decir, el álgebra, para resolver la ley islámica de herencias, y al convertirse las reglas de distribución de herencias en ecuaciones surgió la necesidad de resolverlas rápida y correctamente. El método de Al-Khwarizmi para resolver ecuaciones cuadráticas dio origen al nombre “algorithm”.
https://en.wikipedia.org/wiki/Accounting_identity
https://en.wikipedia.org/wiki/History_of_accounting
https://en.wikipedia.org/wiki/History_of_ancient_numeral_sys...
https://en.wikipedia.org/wiki/Al-Jabr
https://en.wikipedia.org/wiki/Al-Khwarizmi
Los números negativos se usaron por primera vez en China alrededor del siglo III, y en Europa no se usaron ampliamente hasta el siglo XVI. La partida doble moderna se creó en la Europa del siglo XIV.
Por eso, el método tradicional de tener columnas separadas de débito y crédito, con definiciones que parecen un poco extrañas, era la mejor forma de hacerlo funcionar usando solo números positivos.
Hay muchos aspectos importantes del diseño organizacional que solo están débilmente correlacionados con los estados financieros.
Solo después de que la teneduría de libros se arraigó en todos los niveles de la sociedad, los números negativos empezaron a aceptarse como algo tan real como los positivos.
La contabilidad por partida doble es muy fácil de entender si se abandonan los ridículos términos “credit” y “debit”
Lo esencial es mantener siempre verdadera la ecuación contable. La fórmula básica es Equity = Assets - Liabilities y, como las ganancias terminan entrando al capital, queda Equity + Income - Expenses = Assets - Liabilities. Si se reordena para eliminar los negativos, queda Equity + Income + Liabilities = Assets + Expenses
Esta ecuación siempre debe ser verdadera; si no, significaría que el dinero apareció o desapareció de la nada. Por eso, si se suma dinero a una cuenta del lado izquierdo de la ecuación, hay que sumar el mismo monto a una cuenta del lado opuesto, o restar el mismo monto del mismo lado
Por ejemplo, si vendes limonada por 5 dólares, sumas 5 dólares a Sales (Income) y también 5 dólares a Current Account (Assets)
La razón por la que “credit” y “debit” son ridículos es que sus definiciones se invierten según el tipo de cuenta, y ese uso absurdo del lenguaje es la principal razón por la que la gente se confunde
Un instructor de un curso de contabilidad de nivel 100 lo dijo de forma bastante concisa. Debit es un elemento de la columna izquierda y Credit es un elemento de la columna derecha. Lo que esa transacción significa para el negocio depende de la cuenta
Para alguien que no ha estudiado contabilidad, el uso de estos términos es enormemente confuso, y muchas respuestas a quienes se confunden, aunque sean técnicamente correctas, tampoco ayudan mucho. Porque parten del supuesto de que uno ya conoce la terminología
La pregunta “si el saldo aumentó, ¿por qué se debita la cuenta bancaria? ¿Debit no es negativo? ¿El saldo de efectivo se muestra como negativo?” es una muy buena pregunta. Intuitivamente, un direct debit hace que salga dinero, con una debit card gastas dinero, y debit suena como debt, así que uno termina pensando que debit siempre es negativo
Es divertido y a la vez frustrante ver cómo parecen hablar idiomas distintos usando la misma palabra. A veces la conversación deriva en señalar detalles pequeños para demostrar que uno tiene razón
Porque desde el punto de vista de la persona que gasta 5 dólares en limonada, no está poniendo en absoluto 5 dólares en su partida Sales. Todavía no entiendo del todo cuál es exactamente la confusión de la que hablan este artículo y los comentarios
credit significa origen, debit significa destino
Si le facturas 10.000 euros a un cliente, se crea una promesa de 11.000 dólares al tipo de cambio actual. Entonces acreditas 11.000 dólares en la cuenta de origen, “Income: Customer A”, y debitas 11.000 dólares en “Assets: Accounts Receivable”
Más tarde, si el cliente paga pero el tipo de cambio se movió y solo recibiste 10.500 dólares, la promesa registrada originalmente por 11.000 dólares es el origen, así que acreditas 11.000 dólares en Accounts Receivable. Como recibiste 10.500 dólares en efectivo, debitas 10.500 dólares en cash y, para cuadrar el debe y el haber, debitas 500 dólares en “Expenses: Loss on Foreign Exchange”
Normalmente no se liquida una empresa todos los días hábiles, así que ¿por qué intentar encajar a la fuerza esos 500 dólares en un escenario ficticio de liquidación inmediata? Basta con registrarlo mediante el balance entre credit y debit
Había demasiadas gráficas con la variable independiente en el eje Y
“Credit es una partida en la que sale dinero de una cuenta, Debit es una partida en la que entra dinero a una cuenta” no es exacto
El significado de debit y credit cambia según el tipo de cuenta: https://en.wikipedia.org/wiki/Debits_and_credits
Tal vez haya una razón por la que para ser CPA se necesite más de una materia: https://www.accounting.com/careers/cpa/how-to-become/
A mí me parece una forma de duplicar el trabajo para detectar ciertos errores de la época en que las personas ingresaban partidas y hacían los cálculos. En sí mismo tiene sentido
Pero quizá porque crecí en un mundo donde las computadoras hacen todos los cálculos, me parece que viola el principio de no repetir lo mismo. Si anotas lo mismo en dos lugares, tarde o temprano uno de los dos estará mal
Siento que, si la contabilidad se hubiera diseñado en la era moderna, no se haría así. Que yo no sea contador y no lo entienda no significa que el sistema esté mal, pero la confusión que siento cuando veo que “credit disminuye una cuenta de activos” me parece una señal de que hay algo fundamentalmente desalineado
Una partida CR es un aumento de lo que la empresa debe, es decir, de sus obligaciones frente a acreedores o accionistas, y una partida DR es un aumento de lo que la empresa posee
Para la relación con la ecuación contable, consulta esto: https://news.ycombinator.com/item?id=32501707
Se ve mucha confusión con los términos credit/debit
Para pensarlo de forma más simple desde una perspectiva moderna, basta recordar que la contabilidad es mucho más antigua que el uso popular de los números negativos. Si hoy se inventara la contabilidad, probablemente se usarían cuentas positivas/negativas en lugar de cuentas debit/credit
El álgebra sobre la suma nos resulta natural ahora, pero para un comerciante común de 1604 no era algo obvio, y los números negativos tampoco eran muy bien aceptados entonces
Lo importante es que una transacción siempre tiene dos lados y que son operaciones inversas entre sí. Credit y debit son, en última instancia, operaciones inversas sobre números
Por eso se puede crear la regla de que, si credit = debit, la transacción está balanceada. En términos modernos también podría verse como debit + credit = 0, pero cuando se creó este sistema no gustaban los números negativos, así que esto es más una feliz coincidencia que siempre se cumple que un objetivo
Es razonable pensarlo al revés, viendo el efectivo que tienes en mano como la cuenta más positiva, es decir, una cuenta con naturaleza debit. Para registrar un gasto, hay que tratar la cuenta de efectivo en sentido contrario, así que se le hace credit, y al lugar adonde fue el dinero se le hace debit como contraparte. Por eso las cuentas de gastos suelen tener saldo debit
¿De dónde vino el efectivo? Vino de ingresos, y si quieres que el efectivo se comporte como debit, el origen debe comportarse como credit para que la transacción no se desbalancee. Por eso las cuentas de ingresos suelen ser cuentas credit, es decir, generalmente tienen saldo negativo o “credit normal”
Lo bueno de este sistema es que todas las transacciones cotidianas se reducen a transacciones balanceadas, y las cuentas posibles terminan teniendo, cada una, una naturaleza de saldo consistente: normalmente credit o debit. Es realmente elegante
Si memorizas eso y la ecuación contable, puedes derivar el saldo normal de todos los demás tipos de cuentas
Hace más o menos un mes inicié una discusión en el subreddit de PTA sobre cómo hacer más intuitiva la sintaxis de PTA, y alguien propuso marcar con flechas “from”, es decir, la cuenta credit/negativa, y “to”, es decir, la cuenta debit/positiva. Los números no tienen signo y tampoco se usan los términos “credit” y “debit”, así que se siente mucho más intuitivo
https://www.reddit.com/r/plaintextaccounting/comments/1bh3x7...
El contexto sobre los números negativos es interesante
Sigue siendo demasiado complicado. Se desvía desde “agreguemos una columna Transaction a la tabla”
No hay que almacenar datos de cuentas, sino transacciones. Las cuentas se calculan a partir de eso. La tabla “Transactions” debería tener los campos Date, Amount, SourceAccount, TargetAccount y Description
En mi opinión, ahí es cuando se vuelve bello. Hay que abandonar la costumbre de pensar en torno a las cuentas solo porque eso resulta familiar por los estados de cuenta bancarios, y pensar en términos de flujo de efectivo
Claro que para fines fiscales es demasiado simple. A veces una transacción tiene varias fuentes o varios destinos, así que el esquema anterior necesita ajustes. Aun así, el punto es que la forma de pensar debería ser distinta
Es una señal de que algún programador intentó hacerse el listo y mantener totales acumulados en lugar de calcularlos a partir de las transacciones originales. Ahí hay dragones
Un mejor diseño es tener una tabla de encabezado y otra de detalle
Header: TransactionID, Date, Description y los campos necesarios, como posting status o reconciliation status
Detail: TransactionID, LineNumber, Account, Amount, Description y los campos necesarios, como el número de referencia del subledger
Así, una sola transacción puede afectar a cualquier cantidad de cuentas. Al final, una transacción refleja una operación de negocio que puede afectar a varias cuentas
En los detalles es un poco más complicado, por ejemplo, la salida de cada transferencia debe incluir la dirección de origen, pero la idea es la misma. Como también se dijo en otras partes de este hilo, cada transacción necesita múltiples entradas y múltiples salidas
Todas las transacciones están en un archivo de texto plano, y cuando se necesita evaluarlas, genera al vuelo todo el libro mayor a partir de ellas
No soy contador, pero hace un tiempo decidí estudiar partida doble y contabilidad básica, y aprendí mucho de varios lugares, incluido un buen hilo de HN.
En este artículo explico cómo funciona la partida doble y el proceso por el que me di cuenta de que es un grafo dirigido. En HN hay muchos fanáticos de la contabilidad, así que si hay algo incorrecto, agradecería críticas o sugerencias de corrección.
https://martin.kleppmann.com/2011/03/07/accounting-for-compu...
Me encantaría que mis controllers convirtieran el desempeño comercial en estos flujos gráficos. A cierta escala, la contabilidad se vuelve bastante difícil, al punto de que en el equipo de políticas contables se necesita gente de nivel profesor.
Algo que aprendí en estadística es que los gráficos importan. Con la abstracción adecuada, cualquier cifra puede representarse como un grafo de sus componentes. De golpe se me abrió la comprensión.
De un lado está el dinero que entra o sale; del otro, el producto o servicio. Eso es el registro por partida doble en contabilidad. Puede parecer obvio y simple, pero no mucha gente en mi campo lo entiende.
Es un texto bien escrito, pero hay que tener cuidado al redefinir términos que tienen un significado generalmente aceptado.
Cambiar Debit/Credit por Incoming/Outgoing parece otra forma de jerga y puede generar confusión. Cualquier bookkeeper entiende qué significa credit cash y debit expense.
Cambiarlo por incoming/outgoing no ayuda a quienes hacen el trabajo real ni a quienes tienen que explicarlo. Vale más aprender una nomenclatura que ha sido útil durante cientos de años que apoyarse en una analogía.
Cada vez que aparece una discusión así en HN, siempre hay alguien que dice: “es muy simple, credit simplemente…”, y enseguida llega una respuesta de “lo tienes al revés; es simple, credit…”.
A mí no me importaría en absoluto abandonar esos términos para siempre.
Cuando se dice que el dinero fue credited, o cuando usas una credit card, se siente como si el dinero apareciera de algún lado, algo bueno; debit suena como debt y se siente como si tu dinero disminuyera, algo malo.
Entiendo que en realidad los nombres tienen su razón de ser, pero si un campo insiste en usar jerga poco intuitiva que choca con todos los usos que ve una persona externa, parece razonable usar expresiones menos sobrecargadas y diferentes.
Poder conversar usando correctamente la jerga adecuada aumenta mucho la credibilidad.
No entiendo bien por qué explicar debit/credit, que son términos contables, con palabras de uso común parecería jerga. Tal vez sea porque yo soy una persona común.
Para alguien sin formación contable, explicar credit/debt como “entra dinero, sale dinero” me parece suficientemente razonable en el contexto de este artículo. ¿La definición “real” de credit/debit funciona de una manera significativamente distinta aquí?
David P. Ellerman presenta un enfoque matemático de la contabilidad basado en lo que llama el Pacioli group.
Un elemento provisional del Pacioli group tiene la forma x//y, donde x e y son enteros no negativos. x//y y u//v se consideran equivalentes si las sumas cruzadas x+v e y+u son iguales.
La operación de grupo es x//y + u//v = (x+u)//(y+v), el inverso de x//y es y//x, y el elemento identidad es 0//0. Para más detalles, se puede ver, por ejemplo, este documento: https://ellerman.org/wp-content/uploads/2012/12/DEB-Math-Mag...
Siento que me estoy perdiendo algo aquí. ¿En qué ayuda ver el historial de transacciones como un grafo dirigido?
¿Qué mejora hay frente a la práctica centenaria de la partida doble?
En un ejemplo de juguete con unas pocas transacciones apenas parece funcionar, pero basta imaginar cómo se vería el grafo cuando haya decenas o cientos de aristas entre pares de nodos. Tampoco veo para qué servirían los algoritmos de grafos comunes.
Se siente como usar unas pinzas como martillo. Claro que se puede, pero ¿por qué hacerlo?
Primero, es otra forma de entender el concepto. En la mayoría de los casos puede no ser relevante, pero ¿quién sabe si un problema contable difícil podría resolverse aplicando teoría de grafos, o al revés, si un problema de teoría de grafos podría resolverse desde la contabilidad?
Segundo, es otra forma de visualizar flujos. No todo el mundo tiene gran alfabetización financiera o sentido numérico, así que en vez de dar una tabla con columnas de números y pedir que infieran los flujos numéricamente, se puede representarlos espacialmente. No todas las herramientas son solo para expertos.
Ver todo el historial acumulado como un solo grafo puede ser excesivo, pero con solo agregar un filtro por fecha de transacción ya podría dar perspectivas que otras visualizaciones se pierden. También podría volverse más útil al cruzarlo con otra información, como la ubicación.
No logra justificarlo, y la afirmación del autor de que esta visualización le ayudó a entender con más claridad queda debilitada por el error de categoría que aparece al explicar la partida doble desde cero al estilo geek.
Además, solo representó una transacción muy simple. No veo cómo se obtendrían con una visualización basada en grafos cosas más abstractas, como diferencias entre depreciación fiscal y depreciación contable, ajustes por ganancias y pérdidas cambiarias, distribución de franked dividends, PAYG, importes retenidos por cuenta de terceros o reconocimiento parcial de ingresos diferidos.
Ingenieros que descubren tardíamente principios fundamentales que ya existían en otros campos, a medida que el software empieza a replicar esos campos.