Startseite / Blog / Geld

Rechnung aufteilen, wenn ein Gericht nicht geteilt wurde

29. August 2026 · 9 Min. Lesezeit · Dimesum Engineering

Ein Abendessen über 525 € gleichmäßig zu teilen belastet eine Person mit 70 € für ein Gericht, das sie nie anrührte, und die Lösung ist eine Ausgabe mit zwei Regeln.

Teilen Sie ein Abendessen über 525 € gleichmäßig, und eine Person zahlt 70 € zu viel. Zwei der drei aßen die Meeresfrüchteplatte für 200 €, die dritte nicht, dennoch belastet eine gleichmäßige Teilung alle drei mit 175 €. Dimesum behandelt diese Rechnung als eine Ausgabe: gleichmäßig auf oberster Ebene, wobei die Position über 200 € nur von den beiden getragen wird, die sie bestellt haben.

Weitgehend gleichmäßige Rechnungen mit einer einzigen nicht geteilten Position sind das Häufigste, worum eine App zum Aufteilen gebeten wird, und das erste Datenmodell von Dimesum konnte so etwas nicht abbilden. Der frühere Entwurf machte ITEMIZED zu einem Teilungstyp, der sich mit EQUAL, PERCENT und SHARES gegenseitig ausschließt. Eine echte Restaurantrechnung ist beides zugleich.

Positionen sind ein Detail einer Ausgabe, kein anderer Teilungstyp

Eine Ausgabe mit Positionen ist in Dimesum eine gewöhnliche Ausgabe, die zufällig ihre Positionen mitführt. Die Ausgabe behält alles, was Ausgaben ohnehin haben: eine Summe, Teilnehmer, einen Teilungstyp, einen oder mehrere Zahler. Hinzu kommen Positionen, die Zeilen der Rechnung, sowie Zuschläge, also Steuer, Trinkgeld, Gebühren und Rabatte, die darunter aufgedruckt sind.

Zwei Ebenen entscheiden dann über jeden Cent. Der Teilungstyp der Ausgabe teilt jede Zeile, auf der niemand genannt ist. Eine Zeile mit zugewiesenen Personen wird von genau diesen Personen getragen und von niemandem sonst.

Ein Abendessen über 525 €, bei dem die Person, die am wenigsten aß, 105 € zahlt

Asha, Bhavna und Chetan essen zu Abend, auf oberster Ebene gleichmäßig geteilt. Geteilte Teller kommen auf 300 €. Ein Meeresfrüchtegericht kommt auf 200 €, und nur Asha und Bhavna aßen es. Der Service beträgt 5 %, und Chetan zahlte die gesamten 525 €.

Chetan zahlte 525 € und schuldet 105 €, also stehen ihm 420 € zu: 210 € von Asha und 210 € von Bhavna. Wer gezahlt hat, ist unabhängig davon, wer schuldet. Dass der Zahler die Person ist, die kaum aß, ändert keinen der Anteile, weshalb Dimesum Zahler auf Ausgabenebene und zugewiesene Personen auf Zeilenebene führt.

Die Steuer folgt dem, was Sie aßen, nicht Ihrer Anzahl

Chetans Anteil am Service von 25 € beträgt 5 €, nicht 8,33 €. Jeder Zuschlag verteilt sich im Verhältnis zur Positionszwischensumme jeder Person, sodass die Aufteilung des Essens von 200:200:100 auch die Aufteilung des Service bestimmt. Eine Verteilung nach Kopfzahl würde Chetan stillschweigend Steuer für ein Gericht berechnen, das er nie anrührte.

Wer nichts bestellte, zahlt daher keine Steuer und erhält keinen Rabatt. Die Gewichte sind die Zwischensummen vor den Zuschlägen und nicht die laufende Summe, was auch verhindert, dass sich die Rundung eines Zuschlags in die Gewichte des nächsten fortpflanzt.

Zuschläge gelten in ihrer Reihenfolge, also verschiebt ein Rabatt die Bemessungsgrundlage der GST

Eine Rechnung mit „1.000 €, minus 10 %, plus 5 % GST“ berechnet die GST auf 900 €, und die GST-Zeile beträgt 45 €. Dreht man die beiden um, wird die GST auf 1.000 € berechnet, was 50 € ergibt. Zuschläge sind eine geordnete Liste, und ein Prozentsatz gilt für die laufende Summe an seiner eigenen Position. Beide Reihenfolgen sind echte Rechnungen, daher ist die Liste geordnet und keine Menge.

Drei Prüfungen stehen zwischen einem Tippfehler und der Arithmetik. Ein Pool nennt entweder einen Pauschalbetrag oder einen Satz in Basispunkten, nie beides, denn beides zu speichern speichert eine Zahl und ihre eigene Herleitung. Ein negativer Betrag wird abgelehnt, mit einem Fehler, der DISCOUNT als den Weg nennt, eine Minderung zu schreiben. Ein Satz über 100.000 Basispunkten wird ebenfalls abgelehnt, eine Grenze weit über den 10.000 Basispunkten, die 100 % bedeuten, denn hundert Prozent Rabatt ist ein echter Rabatt.

Die Summe ergibt sich aus den Zeilen, und eine eingegebene Summe ist nur eine Prüfsumme

Eine Summe mit Positionen wird abgeleitet: die Summe der Positionen plus die Summe der Zuschläge. Die Zeilen sagen bereits, was die Rechnung kostet, daher wäre eine getrennt angegebene Summe eine zweite Quelle der Wahrheit, die der ersten widersprechen kann. Wer eine Rechnung falsch eingibt, korrigiert eine Zeile, wo der Fehler tatsächlich liegt, und die Summe folgt. Eine bereits gebuchte Rechnung wird über eine Änderung korrigiert, die ihre Teilung neu festlegt, sodass die Korrektur als neue Version landet und nicht als Überschreibung.

Ein Client kann dennoch amount_minor senden, und Dimesum behandelt es dann als Prüfsumme und nicht als die Antwort. Übereinstimmung bedeutet, dass der Client dieselbe Rechnung gelesen hat. Abweichung stoppt die Ausgabe, bevor Geld fließt.

Eine frühere Version fügte automatisch eine Zeile „Sonstiges“ für alles hinzu, was eine angegebene Summe nicht abdeckte, und entfernte die Zeile, wenn sich die Lücke schloss. Diese Zeile funktionierte, und sie ist weg. Das Ableiten der Summe löste das Problem auf, das die Zeile „Sonstiges“ verwalten sollte und das nur entstand, weil die Summe zweimal angegeben wurde.

Warum EXACT und Positionen zusammen abgelehnt werden

EXACT nennt den Endbetrag jedes Mitglieds. Positionen leiten den Betrag jedes Mitglieds ab. Beides zugleich ist überbestimmt: entweder sie stimmen überein, dann ist eines überflüssig, oder sie widersprechen sich, dann hat die Ausgabe zwei Antworten und keine Regel sagt, welche gewinnt. Dimesum lehnt die Kombination von vornherein ab, statt sie mit einer Vorrangregel zu klären, die sich niemand merken würde.

EQUAL, PERCENT und SHARES lassen sich alle mit Positionen kombinieren, denn jede ist eine Regel zum Teilen geteilter Kosten und keine Menge von Endbeträgen.

Wo ein Rabatt früher einen Cent verlor

Jede Verteilung nutzt die Methode des größten Rests, und jede erhält ihre eigene Summe genau. Gleichstände bei dieser Methode gingen früher an die niedrigste Mitglieds-ID, was dem ältesten Mitglied der Gruppe bei jeder gleichmäßig geteilten Ausgabe den zusätzlichen Cent gab; der Gleichstand rotiert nun über einen Hash der Ausgaben-ID. Geteilte Zeilen werden zusammengefasst und einmal geteilt statt Zeile für Zeile, sodass der überzählige Cent nicht bei jeder Zeile der Rechnung auf dasselbe Mitglied fällt.

Unsere Funktion apportion hatte hier einen echten Fehler. Die Ganzzahldivision in Go schneidet gegen null ab, sodass eine negative Summe in die falsche Richtung gerundet wurde und der Rest nie verteilt wurde: −10,00 € über Gewichte von 100, 200 und 300 kamen als −9,99 € zurück. Ein verschwundener Cent hätte eine korrekte rabattierte Rechnung ihre eigene Summenprüfung nicht bestehen lassen, und dem Nutzer wäre gesagt worden, seine Arithmetik sei falsch. Negative Summen werden nun nach Betrag verteilt und zurück negiert.