Forsiden / Blogg / Penger

Slik deler du en regning når én rett ikke ble delt

29. august 2026 · 9 min lesing · Dimesum Engineering

Del en middag på 525 kr likt, og én person betaler stille 70 kr for en rett vedkommende aldri rørte, løsningen er én utgift med to regler.

Del en middag på 525 kr likt og én person betaler 70 kr for mye. To av de tre spiste sjømatfatet til 200 kr og den tredje gjorde det ikke, likevel belaster en lik deling alle tre med 175 kr. Dimesum håndterer den regningen som én utgift: likt på toppen, med linjen på 200 kr båret bare av de to som bestilte den.

Regninger som stort sett er like, med én linje som ikke ble delt, er det vanligste en delingsapp blir bedt om å gjøre, og Dimesums første datamodell kunne ikke uttrykke en slik. Den tidligere utformingen gjorde ITEMIZED til en delingstype, gjensidig utelukkende med EQUAL, PERCENT og SHARES. En ekte restaurantregning er begge deler samtidig.

Spesifisering er en detalj ved en utgift, ikke en annen type deling

En spesifisert utgift i Dimesum er en vanlig utgift som tilfeldigvis bærer sine linjer. Utgiften beholder alt utgifter allerede har: en total, deltakere, en delingstype, en eller flere betalere. Til det legger den varer, linjene på regningen, og justeringer, avgiftene, driksen, gebyrene og rabattene som er trykt under dem.

To nivåer avgjør så hver eneste øre. Utgiftens delingstype deler enhver linje uten noen navngitt på den. En linje med tilordnede bæres av nøyaktig de personene, og av ingen andre.

En middag på 525 kr der den som spiste minst betaler 105 kr

Asha, Bhavna og Chetan spiser middag, delt likt på toppen. Delte retter kommer på 300 kr. En sjømatrett kommer på 200 kr, og bare Asha og Bhavna spiste den. Servering er 5 %, og Chetan betalte hele 525 kr.

Chetan betalte 525 kr og skylder 105 kr, så han har 420 kr til gode: 210 kr fra Asha og 210 kr fra Bhavna. Hvem som betalte er uavhengig av hvem som skylder. At betaleren er personen som knapt spiste endrer ingen av andelene, og derfor holder Dimesum betalere på utgiftsnivå og tilordnede på linjenivå.

Avgift følger hva du spiste, ikke hvor mange dere er

Chetans andel av serveringsgebyret på 25 kr er 5 kr, ikke 8,33 kr. Hver justering fordeles i forhold til hver persons delsum for varer, så 200:200:100-delingen av maten avgjør delingen av serveringsgebyret også. Å fordele etter antall personer ville stille belaste Chetan avgift for en rett han aldri rørte.

Noen som ikke bestilte noe betaler derfor ingen avgift og får ingen rabatt. Vektene er delsummene før justering i stedet for den løpende summen, noe som også hindrer at avrundingen for hver justering forplanter seg inn i vektene for den neste.

Justeringer gjelder i rekkefølge, så en rabatt flytter GST-grunnlaget

En regning som lyder «1 000 kr, minus 10 %, pluss 5 % GST» belaster GST på 900 kr, og GST-linjen er 45 kr. Snu de to og GST belastes på 1 000 kr, som gir 50 kr. Justeringer er en ordnet liste, og en prosentsats gjelder den løpende summen i sin egen posisjon. Begge rekkefølgene er ekte regninger, så listen er ordnet i stedet for et sett.

Tre valideringer står mellom en skrivefeil og aritmetikken. En pool angir enten et fast beløp eller en sats i basispunkter, aldri begge, fordi å lagre begge lagrer et tall og dets egen utledning. Et negativt beløp avvises, med en feil som navngir DISCOUNT som måten å skrive en reduksjon på. En sats over 100 000 basispunkter avvises også, en grense satt langt over de 10 000 basispunktene som betyr 100 %, fordi hundre prosent avslag er en ekte rabatt.

Totalen kommer fra linjene, og en inntastet total er bare en kontrollsum

En spesifisert total er utledet: summen av varene pluss summen av justeringene. Linjene sier allerede hva regningen koster, så en separat oppgitt total ville være en andre sannhetskilde som kan være uenig med den første. Noen som taster inn en regning feil retter en linje, som er der feilen faktisk er, og totalen følger med. Å rette en regning som allerede er postert går gjennom en redigering som omformulerer delingen sin, så rettingen lander som en ny versjon i stedet for som en overskriving.

En klient kan fortsatt sende amount_minor, og Dimesum behandler det da som en kontrollsum i stedet for som svaret. Enighet betyr at klienten leste den samme regningen. Uenighet stopper utgiften før noen penger flyttes.

En tidligere versjon la automatisk til en «Annet»-linje for det en oppgitt total ikke gjorde rede for, og fjernet linjen når gapet lukket seg. Den linjen fungerte, og den er borte. Å utlede totalen løste opp problemet «Annet»-linjen fantes for å håndtere, som bare oppsto fordi totalen ble oppgitt to ganger.

Hvorfor EXACT og varelinjer avvises sammen

EXACT navngir hvert medlems endelige beløp. Varelinjer utleder hvert medlems beløp. Begge samtidig er overbestemt: enten er de enige, og da er den ene overflødig, eller de er uenige, og da har utgiften to svar og ingen regel sier hvilket som vinner. Dimesum avviser kombinasjonen ved døren i stedet for å avgjøre den med en presedensregel ingen ville huske.

EQUAL, PERCENT og SHARES kombineres alle med varelinjer, fordi hver av dem er en regel for å dele en delt kostnad i stedet for et sett med endelige beløp.

Der en rabatt pleide å miste en øre

Hver fordeling bruker metoden med største rest, og hver av dem bevarer sin egen total nøyaktig. Uavgjort i den metoden pleide å gå til laveste medlems-id, noe som ga gruppens eldste medlem den ekstra øren på hver likt delte utgift; uavgjort roterer nå på en hash av utgiftens id. Delte linjer samles og deles én gang i stedet for linje for linje, så den odde øren lander ikke på det samme medlemmet for hver linje på regningen.

Vår apportion-funksjon hadde en reell feil her. Gos heltallsdivisjon avkorter mot null, så en negativ total ble rundet feil vei og resten ble aldri delt ut: −10,00 kr over vekter på 100, 200 og 300 kom tilbake som −9,99 kr. En forsvunnet øre ville ha gjort at en korrekt rabattert regning strøk på sin egen sumkontroll, og brukeren ville ha fått beskjed om at aritmetikken var feil. Negative totaler fordeles nå etter størrelse og negeres tilbake.