Início / Blog / Dinheiro

Como dividir uma conta detalhada de restaurante

29 de agosto de 2026 · 10 min de leitura · Dimesum Engineering

Uma única despesa com duas regras resolve a conta em que um prato não foi de todos: nomeie quem comeu a linha não compartilhada e deixe o imposto seguir o consumo.

Divida um jantar de R$ 525 igualmente e uma pessoa paga R$ 70 a mais. Duas das três comeram a travessa de frutos do mar de R$ 200 e a terceira não, mas uma divisão igual cobra R$ 175 de cada uma. A Dimesum trata essa conta como uma única despesa: igual no topo, com a linha de R$ 200 sustentada apenas pelas duas que a pediram.

Contas quase iguais com uma linha não compartilhada são a tarefa mais comum que se pede a um aplicativo de divisão, e o primeiro modelo de dados da Dimesum não conseguia expressar isso. O design anterior fazia de ITEMIZED um tipo de divisão, mutuamente exclusivo com EQUAL, PERCENT e SHARES. Uma conta de restaurante real é as duas coisas ao mesmo tempo.

Detalhar é um pormenor de uma despesa, não um tipo diferente de divisão

Uma despesa detalhada na Dimesum é uma despesa comum que por acaso carrega suas linhas. A despesa mantém tudo o que as despesas já têm: um total, participantes, um tipo de divisão, um ou vários pagadores. A isso ela acrescenta itens, as linhas da conta, e ajustes, os impostos, a gorjeta, as taxas e os descontos impressos abaixo delas.

Dois níveis então decidem cada centavo. O tipo de divisão da despesa reparte qualquer linha sem ninguém nomeado nela. Uma linha com responsáveis é sustentada exatamente por essas pessoas, e por mais ninguém.

Um jantar de R$ 525 em que quem comeu menos paga R$ 105

Asha, Bhavna e Chetan jantam, com divisão igual no topo. Os pratos compartilhados somam R$ 300. Um prato de frutos do mar sai por R$ 200, e apenas Asha e Bhavna o comeram. O serviço é de 5%, e Chetan pagou os R$ 525 inteiros.

Chetan pagou R$ 525 e deve R$ 105, então tem R$ 420 a receber: R$ 210 de Asha e R$ 210 de Bhavna. Quem pagou é ortogonal a quem deve. O fato de o pagador ser a pessoa que quase não comeu não muda nenhuma das partes, e é por isso que a Dimesum mantém os pagadores no nível da despesa e os responsáveis no nível da linha.

O imposto segue o que você comeu, não quantos vocês são

A parte de Chetan na taxa de serviço de R$ 25 é R$ 5, não R$ 8,33. Todo ajuste é alocado em proporção ao subtotal de itens de cada pessoa, então a divisão 200:200:100 da comida decide também a divisão da taxa de serviço. Alocar por número de pessoas cobraria silenciosamente de Chetan o imposto sobre um prato que ele nunca tocou.

Alguém que não pediu nada, portanto, não paga imposto e não recebe desconto. Os pesos são os subtotais anteriores aos ajustes, e não o total corrente, o que também impede que o arredondamento de cada ajuste se acumule nos pesos do seguinte.

Os ajustes se aplicam em ordem, então um desconto move a base do GST

Uma conta que diz "R$ 1.000, menos 10%, mais 5% de GST" cobra o GST sobre R$ 900, e a linha do GST é R$ 45. Inverta as duas e o GST é cobrado sobre R$ 1.000, dando R$ 50. Os ajustes são uma lista ordenada, e um percentual se aplica ao total corrente na sua própria posição. As duas ordens são contas reais, então a lista é ordenada e não um conjunto.

Três validações ficam entre um erro de digitação e a aritmética. Um conjunto declara ou um valor fixo ou uma taxa em pontos-base, nunca os dois, porque armazenar os dois armazena um número e a sua própria derivação. Um valor negativo é recusado, com um erro que aponta DISCOUNT como a forma de escrever uma redução. Uma taxa acima de 100.000 pontos-base também é recusada, um limite fixado bem acima dos 10.000 pontos-base que significam 100%, porque cem por cento de desconto é um desconto real.

O total vem das linhas, e um total digitado é apenas uma soma de verificação

Um total detalhado é derivado: a soma dos itens mais a soma dos ajustes. As linhas já dizem quanto a conta custa, então um total declarado à parte seria uma segunda fonte de verdade que pode divergir da primeira. Quem digita uma conta errada corrige uma linha, que é onde o erro de fato está, e o total acompanha. Corrigir uma conta que já foi lançada passa por uma edição que reafirma a sua divisão, então a correção entra como uma nova versão e não como uma sobrescrita.

Um cliente ainda pode enviar amount_minor, e a Dimesum então o trata como uma soma de verificação e não como a resposta. Concordância significa que o cliente leu a mesma conta. Divergência interrompe a despesa antes que qualquer dinheiro se mova.

Uma versão anterior acrescentava automaticamente uma linha "Outros" para o que um total declarado não explicasse, e removia a linha quando a diferença fechava. Essa linha funcionava, e já não existe. Derivar o total dissolveu o problema que a linha "Outros" existia para administrar, que só surgia porque o total era declarado duas vezes.

Por que EXACT e itens são recusados juntos

EXACT nomeia o valor final de cada membro. Os itens derivam o valor de cada membro. Os dois ao mesmo tempo é sobredeterminado: ou eles concordam, caso em que um é redundante, ou divergem, caso em que a despesa tem duas respostas e nenhuma regra diz qual vence. A Dimesum recusa a combinação logo na porta em vez de resolvê-la com uma regra de precedência de que ninguém se lembraria.

EQUAL, PERCENT e SHARES todos se combinam com itens, porque cada um é uma regra para repartir um custo compartilhado e não um conjunto de valores finais.

Onde um desconto costumava perder um centavo

Toda alocação usa o método do maior resto, e cada uma conserva o seu próprio total exatamente. Os empates nesse método antes iam para o menor id de membro, o que entregava o centavo extra ao membro mais antigo do grupo em toda despesa dividida igualmente; o empate agora gira sobre um hash do id da despesa. As linhas compartilhadas são agrupadas e repartidas de uma vez, e não linha por linha, então o centavo sobressalente não cai no mesmo membro em cada linha da conta.

Nossa função apportion tinha um defeito real aqui. A divisão inteira de Go trunca em direção a zero, então um total negativo era arredondado para o lado errado e a sobra nunca era distribuída: −R$ 10,00 sobre pesos de 100, 200 e 300 voltava como −R$ 9,99. Um centavo sumido teria feito uma conta com desconto correta falhar na sua própria verificação de soma, e o usuário teria sido informado de que a sua aritmética estava errada. Os totais negativos agora são repartidos por magnitude e negados de volta.