Faturamento e ticket
Por dia, por loja, por finalizadora, com o comparativo do período.
Camada analítica para supermercados
Perda do mês em zero, salário que ninguém lançou, produto vendido sem custo cadastrado, crediário de cinco anos atrás ainda contando como a receber. O seu sistema registra tudo isso e não avisa nada. O Plenus lê a mesma base e começa por aí.
O diagnóstico não custa nada e não depende de contrato.
Seis verificações rodam antes de qualquer gráfico — e é isto que você recebe antes de decidir qualquer coisa.
0 lançamentos no mês
Em hortifrúti e açougue, perda zero não acontece. Sem a baixa de quebra, a margem exibida é a de cadastro — não a que sobra no caixa.
Registrar quebra e avaria no módulo de perdas.
FGTS e férias lançados · salário ausente
O encargo do salário está no sistema e o salário não. Nenhum relatório acusa isso sozinho: a despesa que sobrou parece legítima — e é.
Lançar folha e encargos no contas a pagar.
6,2% · R$ 71.100 (fora tributos)
Supermercado gasta de 8% a 25% da receita para funcionar. Abaixo disso é despesa que ficou só com a contabilidade, e a DRE fica otimista na mesma proporção.
Conferir com a contabilidade o que fica de fora.
38 produtos
Produto sem custo médio entra na conta como lucro inteiro — e sobe indevidamente na curva ABC, que é a lista usada para decidir a compra.
Revisar o cadastro de custo desses itens.
23 produtos
Alguns são promoção deliberada e estão certos. Muitos são erro de preço ou de cadastro. Separar os dois é rápido — desde que a lista exista.
Conferir preço e custo item a item.
11,4% · 2.847 de 24.980
Com onze em cada cem cupons identificados não há como medir recompra, frequência nem cesta.
Reforçar o cadastro de cliente no caixa.
Nenhum dos seis é defeito do ERP. São processos que ninguém combinou de fazer — e que só aparecem quando alguém confere.
Um mês que parecia fechar em 19,6% fechou em 7,7%. A diferença é uma linha que ninguém digitou.
| Linha | Como o ERP mostra | Com as despesas de fora |
|---|---|---|
| Faturamento | 1.146.382,40 | 1.146.382,40 |
| Custo da mercadoria | 802.467,68 | 802.467,68 |
| Margem bruta | 343.914,72 | 343.914,72 |
| Despesas lançadas no ERP | 118.940,00 | 118.940,00 |
| Folha de pagamento fora do ERP | — | 136.500,00 |
| Resultado do mês | 224.974,72 | 88.474,72 |
| Margem líquida | 19,6% | 7,7% |
A coluna da direita não é projeção. É a mesma consulta somando uma despesa digitada uma vez, que fica lá mês a mês.
Roda sobre os seus dados e não custa nada. Se estiver tudo certo, a gente diz isso também.
Por dia, por loja, por finalizadora, com o comparativo do período.
Sobre o custo de reposição, não o de cadastro.
Onde está o giro e onde está o capital parado.
O que faltou na gôndola e quanto dinheiro dorme sem giro.
Onde o pedido e a nota discordam, antes de virar custo.
Aging da carteira, com os nomes só para quem é da casa.
O que vence, o que venceu e o que ficou sem baixa.
Folha, aluguel, energia. Digitados uma vez, presentes todo mês.
Quanto falta vender por dia para bater o mês, por loja.
Um e-mail por dia, e só quando há o que dizer.
O que mais gira parou de vender porque acabou.
O fornecedor subiu e o preço de venda não acompanhou.
A projeção do mês fecha abaixo, com dias para reagir.
Item abaixo do custo sem ninguém ter decidido isso.
Uma seção inteira perdendo contra o período anterior.
O mesmo problema não é anunciado duas vezes: o aviso chega quando começa e quando termina, não todo dia enquanto dura.
Um executável no servidor da loja abre a sessão com
default_transaction_read_only. Não é disciplina nossa: é o
Postgres que recusa a escrita, e o agente prova isso antes de
parear.
Só as colunas que a análise usa — a base do ERP vira um espelho cerca de quinze vezes menor, com as mesmas contagens.
Nenhuma consulta analítica toca o banco do PDV. A loja não fica lenta porque alguém abriu um relatório de doze meses.
UPDATE
nosso falharia mesmo que existisse.
Se os números não baterem com o que a sua contabilidade fechou, o problema é nosso — e queremos ver.