Inicio / Blog / Dinero

Dividir la cuenta cuando un plato no se compartió

29 de agosto de 2026 · 10 min de lectura · Dimesum Engineering

Divide una cena de 525 € a partes iguales y alguien paga 70 € por un plato que no probó; la solución es un gasto con dos reglas: nombra quién comió la línea no compartida y deja que el impuesto siga al consumo.

Divide una cena de 525 € a partes iguales y una persona paga 70 € de más. Dos de los tres comieron la fuente de marisco de 200 € y el tercero no, y aun así una división a partes iguales cobra a los tres 175 €. Dimesum gestiona esa cuenta como un solo gasto: a partes iguales en lo general, con la línea de 200 € asumida solo por los dos que la pidieron.

Las cuentas casi iguales con una sola línea no compartida son lo más habitual que se le pide a una app de división, y el primer modelo de datos de Dimesum no podía expresarlo. El diseño anterior hacía de ITEMIZED un tipo de división, mutuamente excluyente con EQUAL, PERCENT y SHARES. Una cuenta real de restaurante es ambas cosas a la vez.

Detallar es un dato del gasto, no un tipo distinto de división

Un gasto detallado en Dimesum es un gasto corriente que además lleva sus líneas. El gasto conserva todo lo que los gastos ya tienen: un total, participantes, un tipo de división, uno o varios pagadores. A eso añade los artículos, las líneas de la cuenta, y los ajustes, los impuestos, la propina, las comisiones y los descuentos impresos debajo.

Dos niveles deciden entonces cada céntimo. El tipo de división del gasto reparte cualquier línea en la que no se nombre a nadie. Una línea con asignados la asumen exactamente esas personas, y nadie más.

Una cena de 525 € en la que quien menos comió paga 105 €

Asha, Bhavna y Chetan cenan juntos, con división a partes iguales en lo general. Los platos compartidos suman 300 €. Un plato de marisco suma 200 €, y solo Asha y Bhavna lo comieron. El servicio es del 5 %, y Chetan pagó los 525 € completos.

Chetan pagó 525 € y debe 105 €, así que le deben 420 €: 210 € de Asha y 210 € de Bhavna. Quién pagó es independiente de quién debe. Que el pagador sea la persona que apenas comió no cambia ninguna de las partes, y por eso Dimesum mantiene los pagadores a nivel de gasto y los asignados a nivel de línea.

El impuesto sigue lo que comiste, no cuántos sois

La parte de Chetan del cargo por servicio de 25 € es de 5 €, no de 8,33 €. Cada ajuste se reparte en proporción al subtotal de artículos de cada persona, así que la división 200:200:100 de la comida decide también la división del cargo por servicio. Repartir por número de comensales cobraría en silencio a Chetan un impuesto sobre un plato que nunca probó.

Por tanto, quien no pidió nada no paga impuesto y no recibe descuento. Los pesos son los subtotales previos al ajuste y no el total acumulado, lo que además evita que el redondeo de cada ajuste se acumule en los pesos del siguiente.

Los ajustes se aplican en orden, así que un descuento mueve la base del GST

Una cuenta que dice "1.000 €, menos 10 %, más 5 % de GST" cobra el GST sobre 900 €, y la línea del GST es de 45 €. Invierte los dos y el GST se cobra sobre 1.000 €, dando 50 €. Los ajustes son una lista ordenada, y un porcentaje se aplica al total acumulado en su propia posición. Ambos órdenes son cuentas reales, así que la lista está ordenada y no es un conjunto.

Tres validaciones se interponen entre una errata y la aritmética. Un fondo indica o un importe fijo o una tasa en puntos básicos, nunca ambos, porque guardar ambos guarda un número y su propia derivación. Un importe negativo se rechaza, con un error que nombra DISCOUNT como la forma de escribir una reducción. Una tasa por encima de 100.000 puntos básicos también se rechaza, un tope fijado muy por encima de los 10.000 puntos básicos que significan el 100 %, porque un cien por cien de descuento es un descuento real.

El total sale de las líneas, y un total escrito es solo una suma de comprobación

Un total detallado es derivado: la suma de los artículos más la suma de los ajustes. Las líneas ya dicen lo que cuesta la cuenta, así que un total indicado por separado sería una segunda fuente de verdad que puede discrepar de la primera. Quien introduce mal una cuenta corrige una línea, que es donde está el error de verdad, y el total la sigue. Corregir una cuenta ya publicada pasa por una edición que replantea su división, así que la corrección llega como una versión nueva y no como una sobrescritura.

Un cliente todavía puede enviar amount_minor, y Dimesum lo trata entonces como una suma de comprobación y no como la respuesta. La concordancia significa que el cliente leyó la misma cuenta. La discrepancia detiene el gasto antes de que se mueva dinero alguno.

Una versión anterior añadía de forma automática una línea "Otros" para lo que un total indicado no llegaba a cuadrar, y quitaba la línea cuando el hueco se cerraba. Esa línea funcionaba, y ya no está. Derivar el total disolvió el problema que la línea "Otros" existía para gestionar, que solo surgía porque el total se indicaba dos veces.

Por qué EXACT y los artículos se rechazan juntos

EXACT nombra el importe final de cada miembro. Los artículos derivan el importe de cada miembro. Ambos a la vez está sobredeterminado: o concuerdan, en cuyo caso uno es redundante, o discrepan, en cuyo caso el gasto tiene dos respuestas y ninguna regla dice cuál gana. Dimesum rechaza la combinación en la puerta en lugar de resolverla con una regla de precedencia que nadie recordaría.

EQUAL, PERCENT y SHARES se combinan todos con los artículos, porque cada uno es una regla para repartir un coste compartido y no un conjunto de importes finales.

Dónde un descuento solía perder un céntimo

Cada reparto usa el método del resto mayor, y cada uno conserva su propio total con exactitud. Los empates en ese método solían ir al id de miembro más bajo, lo que entregaba al miembro más antiguo del grupo el céntimo extra en cada gasto dividido a partes iguales; el empate ahora rota según un hash del id del gasto. Las líneas compartidas se agrupan y se reparten una sola vez en lugar de línea por línea, así que el céntimo suelto no cae sobre el mismo miembro en cada línea de la cuenta.

Nuestra función apportion tenía aquí un defecto real. La división entera de Go trunca hacia cero, así que un total negativo se redondeaba hacia el lado equivocado y el resto nunca se repartía: −10,00 € sobre pesos de 100, 200 y 300 daba −9,99 €. Un céntimo desaparecido habría hecho que una cuenta con descuento correcta fallara su propia comprobación de suma, y se le habría dicho al usuario que su aritmética estaba mal. Los totales negativos ahora se reparten por magnitud y se vuelven a negar.