# Ecommerce: precos, pedidos e painel batendo

Exemplo publico e sanitizado de como eu organizo uma primeira investigacao quando uma loja, marketplace, comparador de precos ou painel interno mostra numeros que nao batem. Nao e case de cliente, nao usa dados reais e nao afirma que um sistema identico ja foi construido.

O objetivo e simples: o dono do negocio precisa olhar para o painel e confiar que produto, preco, pedido, pagamento e total estao certos.

## Quando isso ajuda

- O preco aparece correto em uma fonte, mas errado no painel.
- Um produto, mercado, restaurante ou cliente aparece duplicado.
- Pedidos pagos somem do dashboard.
- O total de vendas da loja nao bate com o total da planilha.
- Um status fica antigo: pago, enviado, cancelado, entregue ou pendente.
- A equipe nao sabe se o erro esta na loja, na planilha, na API, no banco ou no dashboard.

## Mapa visual

```text
Fonte do dado
loja, fornecedor, planilha, app, pagamento
        |
        v
Organizacao
produto certo, preco certo, cliente certo, pedido certo
        |
        v
Painel interno
lista, busca, comparador, relatorio, alerta
        |
        v
Decisao do negocio
comprar melhor, vender melhor, corrigir erro, atender cliente
```

Se uma etapa falha, o cliente final ve preco errado, o dono ve numero errado ou a equipe perde tempo conferindo tudo no olho.

## Como eu faria a primeira passada

1. Escolho poucos exemplos reais.
   - 1 produto/preco que esta correto.
   - 1 produto/preco que esta errado.
   - 1 pedido que aparece no painel.
   - 1 pedido que sumiu ou duplicou.

2. Marco onde cada informacao deveria aparecer.
   - fonte original
   - sistema que recebe
   - painel ou relatorio final
   - pessoa que usa aquilo no dia a dia

3. Comparo o que o dono espera com o que o sistema mostra.
   - mesmo produto?
   - mesmo preco?
   - mesmo status?
   - mesmo total?
   - mesma data?

4. Separo o problema em cores.
   - Verde: esta batendo.
   - Amarelo: precisa conferir regra ou fonte.
   - Vermelho: esta errado, duplicado, sumido ou antigo.

## Exemplo simples

| Item conferido | Fonte original | Painel final | Sinal | Proxima acao segura |
| --- | --- | --- | --- | --- |
| Arroz 5kg | R$ 24,90 | R$ 24,90 | Verde | Manter como exemplo correto |
| Cafe 500g | R$ 18,50 | R$ 15,90 | Vermelho | Ver de onde veio o preco antigo |
| Pedido 1038 | Pago | Nao aparece | Vermelho | Achar onde o pedido parou |
| Mercado A | 1 cadastro | 2 cadastros | Amarelo | Definir regra para juntar duplicados |
| Total do dia | R$ 3.420 | R$ 3.180 | Vermelho | Comparar pedidos um por um |

## O que o cliente recebe

- Um mapa curto mostrando de onde o dado sai e onde ele deveria chegar.
- Uma lista dos pontos mais provaveis de quebra, em linguagem simples.
- Uma tabela visual com exemplos verdes, amarelos e vermelhos.
- Uma primeira correcao ou diagnostico seguro, sem mexer no que for sensivel no escuro.
- Um criterio de aceite: quais itens precisam bater para considerar resolvido.

## O que eu preciso do cliente

- 3 a 5 exemplos reais que ele consegue conferir.
- Print do painel onde o numero esta errado.
- Export, planilha ou print da fonte original.
- Regra esperada em uma frase: "o preco certo deve ser o do fornecedor X" ou "pedido pago sempre precisa aparecer no dashboard".
- Acesso so quando for necessario e seguro. Se der para comecar com prints/export, melhor.

## Resultado esperado da primeira fase

```text
Antes:
"O painel esta errado, mas ninguem sabe onde."

Depois:
"Esses 5 itens foram conferidos.
 2 estao certos.
 1 esta com preco antigo.
 1 sumiu antes de entrar no painel.
 1 esta duplicado por regra de cadastro.
 O proximo conserto seguro e este."
```

## Limite honesto

A primeira passada organiza o problema e aponta o conserto mais seguro. A correcao final pode depender de acesso ao sistema, banco, app, API, planilha, configuracao da loja ou regra comercial do dono.