Home / Blog / Geld

Een restaurantrekening eerlijk splitten

29 augustus 2026 · 9 min leestijd · Dimesum Engineering

Verdeel een diner van €525 gelijk en iemand betaalt stil €70 voor een gerecht dat hij nooit aanraakte.

Verdeel een diner van €525 gelijk en één persoon betaalt €70 te veel. Twee van de drie aten de zeevruchtenschotel van €200 en de derde niet, toch rekent een gelijke verdeling alle drie €175 aan. Dimesum behandelt die rekening als één uitgave: gelijk aan de bovenkant, waarbij de regel van €200 alleen wordt gedragen door de twee die hem bestelden.

Grotendeels gelijke rekeningen met één niet-gedeelde regel zijn het meest voorkomende waar een deel-app om wordt gevraagd, en het eerste datamodel van Dimesum kon er geen uitdrukken. Het eerdere ontwerp maakte ITEMIZED een verdeeltype, wederzijds uitsluitend met EQUAL, PERCENT en SHARES. Een echte restaurantrekening is beide tegelijk.

Specificeren is detail op een uitgave, geen ander soort verdeling

Een gespecificeerde uitgave in Dimesum is een gewone uitgave die toevallig haar regels meedraagt. De uitgave houdt alles wat uitgaven al hebben: een totaal, deelnemers, een verdeeltype, één of meerdere betalers. Daaraan voegt ze items toe, de regels van de rekening, en aanpassingen, de belasting, fooi, kosten en kortingen die eronder gedrukt staan.

Twee niveaus bepalen dan elke cent. Het verdeeltype van de uitgave verdeelt elke regel waarop niemand is genoemd. Een regel met toegewezen personen wordt gedragen door precies die personen, en door niemand anders.

Een diner van €525 waar de persoon die het minst at €105 betaalt

Asha, Bhavna en Chetan eten samen, gelijk verdeeld aan de bovenkant. Gedeelde gerechten komen op €300. Een zeevruchtengerecht komt op €200, en alleen Asha en Bhavna aten het. De bediening is 5%, en Chetan betaalde de hele €525.

Chetan betaalde €525 en is €105 verschuldigd, dus hij krijgt €420 terug: €210 van Asha en €210 van Bhavna. Wie betaalde staat los van wie verschuldigd is. Dat de betaler de persoon is die nauwelijks at verandert niets aan de aandelen, en daarom houdt Dimesum betalers op uitgaveniveau en toegewezen personen op regelniveau.

Belasting volgt wat je at, niet met hoeveel jullie zijn

Chetans aandeel in de bedieningstoeslag van €25 is €5, niet €8,33. Elke aanpassing wordt toegewezen in verhouding tot ieders item-subtotaal, dus de verdeling 200:200:100 van het eten bepaalt ook de verdeling van de bedieningstoeslag. Toewijzen naar hoofdtelling zou Chetan stilletjes belasting aanrekenen op een gerecht dat hij nooit aanraakte.

Iemand die niets bestelde betaalt daarom geen belasting en ontvangt geen korting. De gewichten zijn de subtotalen vóór aanpassing en niet het lopende totaal, wat ook voorkomt dat de afronding van elke aanpassing doorwerkt in de gewichten van de volgende.

Aanpassingen worden op volgorde toegepast, dus een korting verschuift de GST-grondslag

Een rekening die luidt "€1.000, min 10%, plus 5% GST" rekent GST op €900, en de GST-regel is €45. Draai de twee om en GST wordt op €1.000 gerekend, wat €50 geeft. Aanpassingen vormen een geordende lijst, en een percentage geldt voor het lopende totaal op zijn eigen positie. Beide volgordes zijn echte rekeningen, dus de lijst is geordend en geen verzameling.

Drie validaties staan tussen een typefout en de rekenkunde. Een pool geeft ofwel een vast bedrag ofwel een tarief in basispunten aan, nooit beide, want beide opslaan slaat een getal en zijn eigen afleiding op. Een negatief bedrag wordt geweigerd, met een fout die DISCOUNT noemt als de manier om een verlaging te schrijven. Een tarief boven 100.000 basispunten wordt eveneens geweigerd, een grens ver boven de 10.000 basispunten die 100% betekenen, want honderd procent korting is een echte korting.

Het totaal komt van de regels, en een ingetypt totaal is slechts een controlegetal

Een gespecificeerd totaal is afgeleid: de som van de items plus de som van de aanpassingen. De regels zeggen al wat de rekening kost, dus een apart vermeld totaal zou een tweede bron van waarheid zijn die kan afwijken van de eerste. Iemand die een rekening verkeerd invoert corrigeert een regel, waar de fout werkelijk zit, en het totaal volgt. Een rekening corrigeren die al is geboekt gaat via een bewerking die de verdeling opnieuw vaststelt, dus de correctie landt als een nieuwe versie in plaats van als een overschrijving.

Een client kan nog steeds amount_minor sturen, en Dimesum behandelt het dan als een controlegetal in plaats van als het antwoord. Overeenstemming betekent dat de client dezelfde rekening las. Onenigheid stopt de uitgave voordat er geld beweegt.

Een eerdere versie voegde automatisch een regel "Overig" toe voor alles wat een vermeld totaal niet verantwoordde, en verwijderde de regel wanneer het verschil sloot. Die regel werkte, en hij is weg. Het afleiden van het totaal loste het probleem op dat de regel "Overig" beheerde, dat alleen ontstond doordat het totaal twee keer werd vermeld.

Waarom EXACT en items samen worden geweigerd

EXACT noemt het eindbedrag van elk lid. Items leiden het bedrag van elk lid af. Beide tegelijk is overbepaald: ofwel komen ze overeen, in welk geval er één overbodig is, ofwel wijken ze af, in welk geval de uitgave twee antwoorden heeft en geen regel zegt welke wint. Dimesum weigert de combinatie aan de deur in plaats van haar te beslechten met een voorrangsregel die niemand zou onthouden.

EQUAL, PERCENT en SHARES combineren allemaal met items, want elk is een regel voor het verdelen van gedeelde kosten en geen set eindbedragen.

Waar een korting vroeger een cent verloor

Elke toewijzing gebruikt de methode van het grootste restant, en elke behoudt haar eigen totaal exact. Gelijke standen in die methode gingen vroeger naar het laagste lid-id, wat het oudste lid van de groep de extra cent gaf bij elke gelijk verdeelde uitgave; de gelijke stand roteert nu op een hash van het uitgave-id. Gedeelde regels worden samengevoegd en één keer verdeeld in plaats van regel voor regel, zodat de losse cent niet bij elke regel van de rekening op hetzelfde lid landt.

Onze functie apportion had hier een echt gebrek. De gehele-getaldeling van Go kapt af richting nul, dus een negatief totaal werd de verkeerde kant op afgerond en het restant werd nooit uitgedeeld: −€10,00 over gewichten van 100, 200 en 300 kwam terug als −€9,99. Een verdwenen cent zou een correcte rekening met korting zijn eigen somcontrole hebben laten falen, en de gebruiker zou zijn verteld dat zijn rekenkunde fout was. Negatieve totalen worden nu naar grootte toegewezen en teruggenegeerd.