Guia

Como modelar sem errar

O modelo resolve quase tudo na origem. Sobram quatro decisões que dependem de como você monta o relatório — e são as que mais causam número inesperado.

1. Custo mora no apontamento, produção mora no talhão

Um apontamento agrícola tem um custo e vários talhões. São duas coleções por isso: Activities carrega o custo (uma linha por apontamento) e ActivityAreas carrega a produção (uma linha por talhão).

Some cada medida na sua própria coleção. Se você juntar as duas numa tabela só e somar o custo, ele se repete uma vez por talhão. O total inflaria proporcionalmente ao número de talhões de cada operação.

Relacione as duas por activityId → Activities.id e deixe o Power BI cruzar. É para isso que o relacionamento serve.

O mesmo vale para os detalhes de custo

ActivityLabor (mão de obra), ActivityInputs (insumos) e ActivityMachines (máquinas) detalham o custo por pessoa, por insumo e por implemento.

2. Colheita e produção se sobrepõem

Harvest é a colheita: os mesmos talhões de ActivityAreas, filtrados pelos apontamentos que foram de colheita. Toda linha de Harvest também está em ActivityAreas — é um recorte, não um complemento.

Então escolha uma das três:

• Só Harvest, se o painel é de safra. É o mais simples, e traz a quantidade na unidade da fazenda de brinde.
• Só ActivityAreas, se você quer todas as operações e não precisa separar a colheita.
• As duas, se precisa comparar colheita com o resto — mas aí exclua a colheita de ActivityAreas filtrando Activities.application diferente de M. Sem isso, o peso colhido conta duas vezes.

3. Unidade não soma com unidade diferente

O produtor conta em caixa, saca ou tambor — e a unidade muda por fazenda e por cultura. Onde existe quantidade, ela vem sempre acompanhada da unidade:

Só some fatiando pela unidade. Um total geral de "quantidade" mistura caixa com tambor e não significa nada. Quando você precisa de um número único que atravesse tudo, use a medida em quilos (grossWeightKg) ou em reais (grossAmount).

4. Produtividade: área vem da dimensão

A área física de uma subárea vive em Subareas.areaHa — e só ali. Os fatos não trazem área de propósito: um talhão aparece uma vez por operação, então somar a área pelos fatos contaria a mesma terra várias vezes e infla o denominador.

Para produtividade, a conta certa é:

SUM(Harvest[grossWeightKg]) / SUM(Subareas[areaHa])

Com os filtros do relatório aplicados aos dois lados — o relacionamento faz isso sozinho. Note que a área é somada na dimensão, onde cada subárea aparece uma vez só.

Além disso: o que a API não decide por você

Financeiro não tem status de baixa

Payables e Receivables expõem os sinais como informados: paid, paymentDate e settlementDate. Não derivamos um campo "situação" porque a regra de baixa varia de operação para operação, e um campo derivado teria cara de autoridade que não temos. Concilie do seu lado, com a regra que vale na sua operação.

Chuva: leitura não soma

Em WeatherReadings, rainfallReading é a leitura observada, e a grandeza muda conforme o fabricante da estação — somar leituras não tem significado físico. Para acumular chuva, use rainfallDay, que é o total do dia informado pela estação.

Lançamentos contábeis não são balancete

LedgerEntries é o espelho detalhado dos lançamentos, não uma peça contábil fechada. O nome é literal de propósito.

Resumo