Strona główna / Blog / Pieniądze

Jak sprawiedliwie podzielić rachunek w restauracji

29 sierpnia 2026 · 8 min czytania · Dimesum Engineering

Podziel kolację za 2100 zł po równo, a jedna osoba po cichu płaci 280 zł za danie, którego nawet nie tknęła; rozwiązaniem jest jeden wydatek z dwiema regułami: wskaż, kto zjadł niewspółdzieloną pozycję, i pozwól, by podatek szedł za konsumpcją.

Podziel rachunek za kolację na 2100 zł po równo, a jedna osoba nadpłaci 280 zł. Dwie z trzech osób zjadły półmisek z owocami morza za 800 zł, a trzecia nie, jednak równy podział obciąża każdą z nich kwotą 700 zł. Dimesum traktuje ten rachunek jako jeden wydatek: równo na górnym poziomie, a pozycję za 800 zł ponoszą tylko te dwie osoby, które ją zamówiły.

Rachunki w większości dzielone po równo, z jedną niewspółdzieloną pozycją, to najczęstsze zadanie stawiane aplikacji do dzielenia kosztów, a pierwszy model danych Dimesum nie potrafił takiego opisać. Wcześniejszy projekt czynił z ITEMIZED osobny typ podziału, wykluczający się wzajemnie z EQUAL, PERCENT i SHARES. Prawdziwy rachunek z restauracji jest jednym i drugim naraz.

Rozpisanie na pozycje to szczegół wydatku, a nie inny rodzaj podziału

Wydatek rozpisany na pozycje w Dimesum to zwykły wydatek, który po prostu niesie ze sobą swoje pozycje. Wydatek zachowuje wszystko, co wydatki mają już wcześniej: sumę, uczestników, typ podziału, jednego lub kilku płatników. Do tego dodaje pozycje, czyli wiersze rachunku, oraz korekty, czyli podatek, napiwek, opłaty i rabaty wydrukowane pod nimi.

O każdym groszu decydują następnie dwa poziomy. Typ podziału wydatku dzieli każdą pozycję, przy której nikogo nie wskazano. Pozycję z przypisanymi osobami ponoszą dokładnie te osoby i nikt inny.

Kolacja za 2100 zł, na której osoba, która zjadła najmniej, płaci 420 zł

Asha, Bhavna i Chetan jedzą kolację, dzieloną po równo na górnym poziomie. Wspólne dania wychodzą na 1200 zł. Danie z owocami morza wychodzi na 800 zł i zjedli je tylko Asha i Bhavna. Obsługa wynosi 5%, a Chetan zapłacił całe 2100 zł.

Chetan zapłacił 2100 zł, a jest winien 420 zł, więc należy mu się 1680 zł: 840 zł od Ashy i 840 zł od Bhavny. To, kto zapłacił, jest niezależne od tego, kto jest winien. Fakt, że płatnikiem jest osoba, która ledwie jadła, nie zmienia żadnego z udziałów, dlatego Dimesum trzyma płatników na poziomie wydatku, a osoby przypisane na poziomie pozycji.

Podatek idzie za tym, co zjadłeś, a nie za tym, ile was jest

Udział Chetana w opłacie za obsługę wynoszącej 100 zł to 20 zł, a nie 33,33 zł. Każda korekta rozkłada się proporcjonalnie do sumy częściowej pozycji danej osoby, więc podział jedzenia w proporcji 800:800:400 decyduje też o podziale opłaty za obsługę. Rozłożenie według liczby osób po cichu obciążyłoby Chetana podatkiem od dania, którego nawet nie tknął.

Ktoś, kto nic nie zamówił, nie płaci więc żadnego podatku i nie dostaje żadnego rabatu. Wagami są sumy częściowe sprzed korekt, a nie suma bieżąca, co powstrzymuje też zaokrąglenie każdej korekty przed kumulowaniem się w wagach następnej.

Korekty stosuje się po kolei, więc rabat przesuwa podstawę GST

Rachunek o treści "4000 zł, minus 10%, plus 5% GST" nalicza GST od 3600 zł, a pozycja GST wynosi 180 zł. Odwróć kolejność tych dwóch, a GST naliczany jest od 4000 zł, co daje 200 zł. Korekty to lista uporządkowana, a procent stosuje się do sumy bieżącej na swojej własnej pozycji. Obie kolejności to prawdziwe rachunki, więc ta lista jest uporządkowana, a nie zbiorem.

Między literówką a arytmetyką stają trzy walidacje. Pula podaje albo kwotę stałą, albo stawkę w punktach bazowych, nigdy obie, bo przechowywanie obu przechowuje liczbę i jej własne wyprowadzenie. Kwota ujemna jest odrzucana, a błąd wskazuje DISCOUNT jako sposób na zapisanie obniżki. Stawka powyżej 100 000 punktów bazowych też jest odrzucana, przy limicie ustawionym daleko powyżej 10 000 punktów bazowych oznaczających 100%, bo sto procent rabatu to prawdziwy rabat.

Suma pochodzi z pozycji, a wpisana suma jest tylko sumą kontrolną

Suma pozycji jest wyprowadzana: suma pozycji plus suma korekt. Wiersze już mówią, ile kosztuje rachunek, więc osobno podana suma byłaby drugim źródłem prawdy, które może się nie zgadzać z pierwszym. Ktoś, kto błędnie wprowadzi rachunek, poprawia wiersz, czyli miejsce, w którym naprawdę jest błąd, a suma podąża za tym. Poprawianie rachunku, który jest już zaksięgowany, przechodzi przez edycję, która na nowo określa jego podział, więc poprawka ląduje jako nowa wersja, a nie nadpisanie.

Klient nadal może przesłać amount_minor, a Dimesum traktuje to wtedy jako sumę kontrolną, a nie jako odpowiedź. Zgodność oznacza, że klient odczytał ten sam rachunek. Niezgodność zatrzymuje wydatek, zanim jakiekolwiek pieniądze się przesuną.

Wcześniejsza wersja automatycznie dodawała pozycję "Inne" dla wszystkiego, czego podana suma nie uwzględniała, i usuwała tę pozycję, gdy różnica się domykała. Ta pozycja działała, i już jej nie ma. Wyprowadzanie sumy rozpuściło problem, do którego zarządzania istniała pozycja "Inne", a który brał się tylko stąd, że suma była podawana dwukrotnie.

Dlaczego EXACT i pozycje są odrzucane razem

EXACT podaje końcową kwotę każdego uczestnika. Pozycje wyprowadzają kwotę każdego uczestnika. Oba naraz są nadokreślone: albo się zgadzają, i wtedy jedno jest zbędne, albo się nie zgadzają, i wtedy wydatek ma dwie odpowiedzi, a żadna reguła nie mówi, która wygrywa. Dimesum odrzuca to połączenie już na wejściu, zamiast rozstrzygać je regułą pierwszeństwa, której nikt by nie zapamiętał.

EQUAL, PERCENT i SHARES łączą się z pozycjami, bo każde z nich jest regułą dzielenia wspólnego kosztu, a nie zestawem końcowych kwot.

Gdzie rabat kiedyś gubił grosz

Każde rozłożenie korzysta z metody największej reszty, i każde zachowuje swoją własną sumę dokładnie. Remisy w tej metodzie trafiały kiedyś do najniższego identyfikatora uczestnika, co wręczało najstarszemu członkowi grupy dodatkowy grosz przy każdym wydatku dzielonym po równo; teraz remis rotuje na haszu identyfikatora wydatku. Wspólne pozycje są łączone w pulę i dzielone raz, a nie wiersz po wierszu, więc nieparzysty grosz nie ląduje u tego samego uczestnika przy każdym wierszu rachunku.

Nasza funkcja apportion miała tu prawdziwą wadę. Dzielenie całkowite w Go obcina w stronę zera, więc suma ujemna była zaokrąglana w złą stronę i reszta nigdy nie była rozdawana: −40,00 zł przy wagach 100, 200 i 300 wracało jako −39,99 zł. Zniknięty grosz sprawiłby, że poprawnie zrabatowany rachunek nie przeszedłby własnego sprawdzenia sumy, a użytkownikowi powiedziano by, że jego arytmetyka jest błędna. Sumy ujemne są teraz rozkładane według wartości bezwzględnej i z powrotem negowane.