Home / Blog / Denaro

Come dividere un conto con un piatto non condiviso

29 agosto 2026 · 9 min di lettura · Dimesum Engineering

Una spesa con due regole risolve il conto: indicate chi ha mangiato la riga non condivisa e lasciate che le tasse seguano il consumo.

Dividete in parti uguali una cena da €525 e una persona paga €70 di troppo. Due dei tre commensali hanno mangiato il piatto di pesce da €200 e il terzo no, eppure una divisione uguale addebita €175 a testa a tutti e tre. Dimesum tratta quel conto come una sola spesa: uguale al vertice, con la riga da €200 sostenuta solo dai due che l'hanno ordinata.

I conti quasi uguali con una sola riga non condivisa sono la richiesta più comune per un'app di divisione, e il primo modello di dati di Dimesum non riusciva a esprimerli. Il progetto precedente faceva di ITEMIZED un tipo di divisione, mutuamente esclusivo con EQUAL, PERCENT e SHARES. Un vero conto di ristorante è entrambe le cose insieme.

La suddivisione in voci è un dettaglio della spesa, non un tipo di divisione diverso

Una spesa con voci in Dimesum è una spesa ordinaria che si trova a portare le proprie righe. La spesa mantiene tutto ciò che le spese hanno già: un totale, i partecipanti, un tipo di divisione, uno o più pagatori. A questo aggiunge le voci, le righe del conto, e le rettifiche, cioè tasse, mancia, commissioni e sconti stampati sotto di esse.

Due livelli decidono poi ogni centesimo. Il tipo di divisione della spesa suddivide qualsiasi riga su cui non è indicato nessuno. Una riga con assegnatari è sostenuta esattamente da quelle persone, e da nessun altro.

Una cena da €525 in cui chi ha mangiato di meno paga €105

Asha, Bhavna e Chetan cenano insieme, con divisione uguale al vertice. I piatti condivisi arrivano a €300. Un piatto di pesce arriva a €200, e solo Asha e Bhavna l'hanno mangiato. Il servizio è del 5%, e Chetan ha pagato l'intero conto da €525.

Chetan ha pagato €525 e deve €105, quindi gli spettano €420: €210 da Asha e €210 da Bhavna. Chi ha pagato è indipendente da chi deve. Il fatto che a pagare sia la persona che ha mangiato appena qualcosa non cambia nessuna delle quote, ed è per questo che Dimesum tiene i pagatori a livello di spesa e gli assegnatari a livello di riga.

Le tasse seguono ciò che avete mangiato, non quanti siete

La quota di Chetan sul servizio da €25 è €5, non €8,33. Ogni rettifica si ripartisce in proporzione al subtotale delle voci di ciascuna persona, quindi la divisione 200:200:100 del cibo decide anche la divisione del servizio. Ripartire in base al numero di persone addebiterebbe a Chetan, senza farlo notare, le tasse su un piatto che non ha mai toccato.

Chi non ha ordinato nulla non paga quindi alcuna tassa e non riceve alcuno sconto. I pesi sono i subtotali prima delle rettifiche anziché il totale progressivo, il che impedisce anche che l'arrotondamento di ogni rettifica si sommi nei pesi di quella successiva.

Le rettifiche si applicano in ordine, quindi uno sconto sposta la base dell'IVA

Un conto che recita "€1.000, meno 10%, più 5% di IVA" applica l'IVA su €900, e la riga dell'IVA è €45. Invertite i due e l'IVA viene applicata su €1.000, dando €50. Le rettifiche sono un elenco ordinato, e una percentuale si applica al totale progressivo nella propria posizione. Entrambi gli ordinamenti sono conti reali, quindi l'elenco è ordinato anziché un insieme.

Tre controlli si frappongono tra un refuso e l'aritmetica. Un insieme indica o un importo fisso o un'aliquota in punti base, mai entrambi, perché memorizzare entrambi memorizza un numero e la sua stessa derivazione. Un importo negativo viene rifiutato, con un errore che indica DISCOUNT come modo per scrivere una riduzione. Anche un'aliquota superiore a 100.000 punti base viene rifiutata, un tetto fissato molto al di sopra dei 10.000 punti base che indicano il 100%, perché uno sconto del cento per cento è uno sconto reale.

Il totale viene dalle righe, e un totale digitato è solo un codice di controllo

Un totale con voci è derivato: la somma delle voci più la somma delle rettifiche. Le righe dicono già quanto costa il conto, quindi un totale indicato a parte sarebbe una seconda fonte di verità che può divergere dalla prima. Chi inserisce male un conto corregge una riga, che è dove sta davvero l'errore, e il totale ne consegue. Correggere un conto già registrato passa per una modifica che riformula la sua divisione, così la correzione arriva come nuova versione anziché come sovrascrittura.

Un client può comunque inviare amount_minor, e Dimesum lo tratta allora come un codice di controllo anziché come la risposta. La concordanza significa che il client ha letto lo stesso conto. La discordanza ferma la spesa prima che si muova del denaro.

Una versione precedente aggiungeva automaticamente una riga "Altro" per tutto ciò che un totale indicato non spiegava, e rimuoveva la riga quando la differenza si chiudeva. Quella riga funzionava, e non c'è più. Derivare il totale ha dissolto il problema che la riga "Altro" esisteva per gestire, e che sorgeva solo perché il totale veniva indicato due volte.

Perché EXACT e le voci vengono rifiutati insieme

EXACT indica l'importo finale di ciascun membro. Le voci derivano l'importo di ciascun membro. Entrambi insieme sono sovradeterminati: o concordano, e allora uno è ridondante, oppure divergono, e allora la spesa ha due risposte e nessuna regola dice quale prevale. Dimesum rifiuta la combinazione fin dall'ingresso anziché risolverla con una regola di precedenza che nessuno ricorderebbe.

EQUAL, PERCENT e SHARES si combinano tutti con le voci, perché ciascuno è una regola per dividere un costo condiviso anziché un insieme di importi finali.

Dove uno sconto perdeva un centesimo

Ogni ripartizione usa il metodo del resto maggiore, e ciascuna conserva esattamente il proprio totale. In quel metodo i pareggi andavano all'id di membro più basso, il che consegnava al membro più anziano del gruppo il centesimo in più su ogni spesa divisa in parti uguali; ora il pareggio ruota su un hash dell'id della spesa. Le righe condivise vengono raggruppate e divise una volta sola anziché riga per riga, così il centesimo dispari non finisce sullo stesso membro per ogni riga del conto.

La nostra funzione apportion aveva qui un vero difetto. La divisione intera di Go tronca verso lo zero, così un totale negativo veniva arrotondato per difetto nel verso sbagliato e il resto non veniva mai distribuito: −€10,00 su pesi di 100, 200 e 300 tornava come −€9,99. Un centesimo svanito avrebbe fatto fallire a un conto scontato corretto il suo stesso controllo di somma, e all'utente sarebbe stato detto che la sua aritmetica era sbagliata. I totali negativi ora vengono ripartiti per grandezza e rinegati.