PRD - App Calculadora Charrua de preços BB (AppSheet)

Author

Leonardo Fernandes Wink - Inteligência de Mercado

Published

January 23, 2026

1 Visão Geral do Produto

Nome do Produto: [CHARRUA] Calculadora de Pedidos Bandeira Branca
Plataforma: AppSheet (Mobile & Desktop)
Objetivo: Padronizar a criação de pedidos de venda, automatizar o cálculo de margem (em R$) e gerenciar o fluxo de aprovação de preços com base em alçadas (Pricing/Gerente Comercial), garantindo a integridade com as regras comerciais da empresa.

2 Personas e Permissões

Perfil Descrição Permissões
Assessor (Vendedor) Responsável pela conta/cliente. Criar cotações, visualizar apenas seus clientes, editar pedidos em rascunho.
Analista Pricing (Débora) Guardiã da margem e dados mestres. Atualizar tabelas de Preço/Custo (Input), Aprovar cotações de nível 1 (Amarelo), Visualizar tudo.
Gerente Comercial Aprovador Final. Aprovar cotações críticas de nível 3 (Vermelho), Visualizar relatórios globais.
Admin (Você) Desenvolvedor/Manutenção. Acesso total à estrutura e dados.

3 Arquitetura de Dados (Backend)

O aplicativo consumirá dados de duas fontes principais integradas via Google Sheets:

  1. Automático (Via BI -> Power Automate -> Google Planilhas):
    • Tabela Clientes: CNPJ, Razão Social, Cidade, Prazo cadastrado no SAP, Tipo Frete Padrão.
  2. Manual (Gestão Pricing - Template SAP):
    • Tabela INPUT_PRECOS: Cod_Produto, Base, Preço Tabela.
    • Tabela INPUT_CUSTOS: Cod_Produto, Base, Custo ZPMZ.
    • Tabela INPUT_TX_FIN: Prazo (dias), Taxa financeira, Encargo ao dia (0,0045).
      • Como referência, a SIM DISTRI usa 0,0035 * dia
    • Tabela INPUT_FRETES: Origem (Município base) x Destino (Município cliente) = Custo Frete (R$/L).

4 Requisitos Funcionais

4.1 Módulo de Configuração (Input)

  • Seleção de Cliente: O assessor seleciona o cliente. O App carrega automaticamente: Município de destino, Prazo de pagamento e Frete padrão.
  • Validação de Prazo: O assessor insere o prazo da negociação.
    • Regra: Se Prazo inserido > Prazo de pagamento cadastrado no SAP, o sistema alerta “Sujeito à análise de crédito”.
    • [A DEFINIR]: Como que irá funcionar essa análise de crédito? Quem avalia se está OK ou não? Quais parâmetros que são avaliados para aprovar uma análise?
  • Adição de Itens: Seleção de Produto + Base de Carregamento.
    • O App busca automaticamente: Preço de tabela (ZPR0) e Custo margem zero (ZPMZ).
    • O Assessor insere: Preço negociado (R$/L) e Quantidade (L).

4.2 Motor de Cálculo (Lógica)

O sistema deve calcular em tempo real (usando colunas virtuais):

  1. Margem unitária (R$/L) = Preço negociado - Custo ZPMZ - Frete (se CIF) - Taxa financeira.
  2. Margem total do pedido (R$) = Soma de (Margem Unitária * Quantidade) de todos os itens.
  3. [A DEFINIR] Alçadas de aprovação/reprovação:
    • 🟢 Verde: Margem unit >= 0 (Aprovação Automática).
    • 🟡 Amarelo: Margem unit >= -0,03 (Alçada Pricing).
    • 🟠 Laranja: Margem unit >= -0,05 (Proposição: Alçada Gerente de Área).
    • 🔴 Vermelho: Margem unit < -0,03 (Alçada Gerência Comercial).

Para cada pedido realizado, o App deve registrar:

4.3 Workflow de Aprovação

  • Pedidos com status “Verde” vão direto para “Aprovado”.
  • Pedidos “Amarelo/Vermelho” ficam travados como “Pendente Aprovação”.
  • Botões de Ação (Aprovar/Reprovar) visíveis apenas para os usuários com a alçada correta (Slices do AppSheet).
  • Quando reprovado, selecionar o motivo.

4.4 Saída (Output)

  • Botão WhatsApp: Gerar texto pré-formatado com o resumo do pedido para o assessor enviar para o aprovador (agilizando a cobrança da aprovação).
  • E-mails Automáticos:
    • Assessor recebe aviso quando o pedido for “Finalizado” ou “Reprovado”.
    • Central de Pedidos recebe cópia dos pedidos “Aprovados” para lançar no CRM -> SAP.

5 Diagrama de Fluxo

Os diagramas abaixo detalham a jornada do usuário e o comportamento do sistema com as 4 faixas de alçada.

5.1 Diagrama 1: Fluxo do Assessor (Input e Cálculo)

Clique aqui para expandir/recolher o fluxo do Assessor Comercial 

graph TD
    %% --- ESTILOS ---
    classDef input fill:#e1f5fe,stroke:#01579b,stroke-width:2px;
    classDef process fill:#fff9c4,stroke:#fbc02d,stroke-width:2px;
    classDef decision fill:#ffccbc,stroke:#d84315,stroke-width:2px,rx:5,ry:5;
    classDef output fill:#c8e6c9,stroke:#2e7d32,stroke-width:2px;
    classDef database fill:#eee,stroke:#333,stroke-width:1px,stroke-dasharray: 5 5;
    classDef waiting fill:#e0e0e0,stroke:#616161,stroke-width:2px,stroke-dasharray: 5 5;

    %% --- DADOS ---
    subgraph BACKEND [Backend Google Sheets]
        DB_Clientes[(Tabela Clientes)]:::database
        DB_Pricing[(Tabela Preço/Custo)]:::database
    end

    %% --- FLUXO ---
    Start((Início)) --> SelectCli[Selecionar Cliente]:::input
    DB_Clientes -.->|Carrega Dados| SelectCli

    SelectCli --> CheckPrazo{Prazo Input <br>=<br> Prazo CRM?}:::decision
    CheckPrazo -- Sim --> InputItens[Adicionar Produtos]:::input
    CheckPrazo -- Não --> FlagCredito[Flag: Análise Crédito]:::process
    FlagCredito --> InputItens

    %% --- CÁLCULO ---
    InputItens --> FetchData[Busca ZPR0 e ZPMZ]:::process
    DB_Pricing -.-> FetchData
    
    FetchData --> Calcs[Cálculo Margem R$]:::process
    Calcs --> CheckAlcada{Verificar <br> Margem Unitária}:::decision

    %% --- RESULTADOS DO ASSESSOR ---
    CheckAlcada -- "Margem >= 0" --> StatusAprov[Status: APROVADO]:::output
    
    %% Saídas para aprovação (Fim do fluxo do assessor)
    CheckAlcada -- "Margem >= -0,03" --> Wait1(Enviado para<br>Pricing):::waiting
    CheckAlcada -- "Margem >= -0,05" --> Wait2(Enviado para<br>Gerente de Área):::waiting
    CheckAlcada -- "Margem < -0,05"  --> Wait3(Enviado para<br>Gerente Comercial):::waiting

    %% --- OUTPUTS AUTOMÁTICOS ---
    StatusAprov --> OutEmail[Email para<br>Central de Pedidos]:::output

5.2 Diagrama 2: Fluxo do Pricing

Clique aqui para expandir/recolher a rotina de atualização das bases

Foco no “Backoffice”: O trabalho diário de garantir que o App tenha os números certos.

graph TB
    %% --- ESTILOS ---
    classDef input fill:#e1f5fe,stroke:#01579b,stroke-width:2px;
    classDef process fill:#fff9c4,stroke:#fbc02d,stroke-width:2px;
    classDef database fill:#eee,stroke:#333,stroke-width:1px,stroke-dasharray: 5 5;
    classDef google fill:#e8f5e9,stroke:#2e7d32,stroke-width:2px;

    %% --- PREPARAÇÃO (O QUE) ---
    subgraph SAP [Origem: SAP / Excel Local]
        Step1[Gerar Template SAP]:::input
        Step1 --> Data1[Dados de Preço Venda<br>Tab: ZPR0]
        Step1 --> Data2[Dados de Custos<br>Tab: ZPMZ]
        Step1 --> Data3[Dados de Frete]
    end

    %% --- AÇÃO (COMO) ---
    subgraph SHEETS [Destino: Google Sheets Backend]
        Data1 --> Action1[Copiar e Colar na aba:<br>INPUT_PRECOS]:::process
        Data2 --> Action2[Copiar e Colar na aba:<br>INPUT_CUSTOS]:::process
        Data3 --> Action3[Copiar e Colar na aba:<br>INPUT_FRETES]:::process
    end

    %% --- RESULTADO (ONDE) ---
    subgraph APP [AppSheet]
        Action1 & Action2 & Action3 --> Sync[Sincronização Automática]:::google
        Sync --> AppReady[(Base Atualizada<br>Disponível p/ Cálculo)]:::database
    end

Clique aqui para expandir/recolher o fluxo de aprovação do Pricing

Foca apenas nas cotações que caíram na regra de margem entre 0 e -0,03.

Foco na “Tomada de Decisão”: O que acontece quando um pedido cai na caixa de entrada.

graph TB
    %% --- ESTILOS ---
    classDef startnode fill:#fff9c4,stroke:#fbc02d,stroke-width:2px;
    classDef input fill:#e1f5fe,stroke:#01579b,stroke-width:2px;
    classDef decision fill:#ffccbc,stroke:#d84315,stroke-width:2px,rx:5,ry:5;
    classDef output fill:#c8e6c9,stroke:#2e7d32,stroke-width:2px;
    classDef correction fill:#e0e0e0,stroke:#616161,stroke-width:2px,stroke-dasharray: 5 5;

    %% --- GATILHO ---
    Trigger(Status: Pendente Pricing<br>Margem entre 0 e -0,03):::startnode --> View[Pricing abre o App<br>Visualiza Detalhes]:::input

    %% --- ANÁLISE ---
    View --> CheckDados{O Custo/Preço<br>está correto?}:::decision

    %% --- CENÁRIO 1: DADO ERRADO ---
    CheckDados -- Não --> FixBase[Corrigir Base de Dados<br>Voltar p/ Rotina 1]:::correction
    FixBase -.->|Solicitar ao Assessor| Recalc[Assessor Refaz Pedido]:::correction

    %% --- CENÁRIO 2: DADO CORRETO (DECISÃO) ---
    CheckDados -- Sim --> Decisao{Aprovar Margem?}:::decision

    Decisao -- Sim --> Aprov[Status: APROVADO]:::output
    Decisao -- Não --> Reprov[Status: REPROVADO]:::output

    %% --- SAÍDAS ---
    Aprov --> Email[Email Automático<br>p/ Central SAP]:::output
    Reprov --> Notif[Notificação Push<br>p/ Assessor]:::output

5.3 Diagrama 3: Fluxo de Aprovação - Gerente de Área

Foca nas cotações com margem intermediária (entre -0,03 e -0,05).

Clique aqui para expandir/recolher o fluxo do Gerente de Área 

graph TB
    %% --- ESTILOS ---
    classDef input fill:#e1f5fe,stroke:#01579b,stroke-width:2px;
    classDef decision fill:#ffccbc,stroke:#d84315,stroke-width:2px,rx:5,ry:5;
    classDef output fill:#c8e6c9,stroke:#2e7d32,stroke-width:2px;
    classDef startnode fill:#fff9c4,stroke:#fbc02d,stroke-width:2px;

    %% --- FLUXO ---
    InputArea(Status: Pendente Gerente de Área):::startnode --> ViewArea[Gerente de Área<br> analisa o pedido]:::input
    ViewArea --> DecArea{Aprovar?}:::decision

    %% --- DECISÃO ---
    DecArea -- Sim --> StatusAprov[Status: APROVADO]:::output
    DecArea -- Não --> StatusReprov[Status: REPROVADO]:::output

    %% --- OUTPUTS ---
    StatusAprov --> OutEmail[Email para<br>Central de Pedidos]:::output
    StatusAprov --> OutWhats[Botão Whats para<br>avisar o Assessor]:::output
    StatusReprov --> OutNotif[Notificar Assessor]:::output

5.4 Diagrama 4: Fluxo de Aprovação - Gerência Comercial

Foca nas cotações críticas (abaixo de -0,05).

Clique aqui para expandir/recolher o fluxo do Gerente comercial 

graph TB
    %% --- ESTILOS ---
    classDef input fill:#e1f5fe,stroke:#01579b,stroke-width:2px;
    classDef decision fill:#ffccbc,stroke:#d84315,stroke-width:2px,rx:5,ry:5;
    classDef output fill:#c8e6c9,stroke:#2e7d32,stroke-width:2px;
    classDef startnode fill:#fff9c4,stroke:#fbc02d,stroke-width:2px;

    %% --- FLUXO ---
    InputComm(Status: Pendente Gerente Comercial):::startnode --> ViewComm[Ger. Comercial analisa o pedido]:::input
    ViewComm --> DecComm{Aprovar?}:::decision

    %% --- DECISÃO ---
    DecComm -- Sim --> StatusAprov[Status: APROVADO]:::output
    DecComm -- Não --> StatusReprov[Status: REPROVADO]:::output

    %% --- OUTPUTS ---
    StatusAprov --> OutEmail[Email para<br>Central de Pedidos]:::output
    StatusAprov --> OutWhats[Botão Whats para<br>avisar o Assessor]:::output
    StatusReprov --> OutNotif[Notificar Assessor]:::output

6 Etapas e Cronograma (Estimativa)

O cronograma foi desenvolvido para permitir entregas incrementais. O tempo total estimado para desenvolvimento é de aproximadamente 150h. Considerando um dedicação de 70% do tempo diário, temos uma estimativa de 4-5 semanas.

Estimativa de 5 semanas * 5 dias * 6 horas por dia = 5 * 5 * 6 = 150 horas Custo da hora = R$30/h

Custo estimado para desenvolvimento = R$4.500

6.1 Fase 1: Fundação de Dados (Backend)

Objetivo: Garantir que o Google Sheets receba os dados corretamente do Power Automate e da Débora.

Tempo Estimado: 12 a 16 horas (Semana 1)

6.2 Fase 2: Construção da Calculadora (AppSheet - Core)

Objetivo: Assessor consegue fazer um pedido e ver a margem calculada.

Tempo Estimado: 30 a 40 horas (Semana 2 e 3)

6.3 Fase 3: Workflow e Aprovações (Lógica de Negócio)

Objetivo: Implementar as travas de segurança e caixas de entrada dos gerentes.

Tempo Estimado: 20 a 30 horas (Semana 3 e 4)

6.4 Fase 4: Testes e Go-Live

Objetivo: Garantir que não existem bugs de cálculo e treinar os usuários.

Tempo Estimado: 24 a 48 horas (Semana 5)

6.5 Fase 5: Melhorias de Experiência do usuário (UX) e Gestão

Objetivo: Entregar funcionalidades que geram valor gerencial e agilidade. Tempo Estimado: 15 a 20 horas (Distribuídas ao longo das primeiras semanas com o App rodando)

    • Volume de Pedidos por Status (Quantos estão travados no Pricing?).
    • Top 5 Motivos de Reprovação (Se houver campo de motivo).

7 Avaliação de Impacto Estratégico

A implementação desta calculadora gera valor distinto para cada persona envolvida, justificando o investimento:

  • Para o Assessor (Vendedor):
    • Benefício: Autonomia e Agilidade. O feedback instantâneo (cores da margem) elimina a necessidade de consultar a gestão para vendas rotineiras. A funcionalidade de gerar texto para WhatsApp reduz o trabalho manual.
    • Fator Crítico: A adesão depende estritamente da confiança nos dados. Se o preço carregado estiver desatualizado, o assessor abandonará a ferramenta.
  • Para o Pricing (Débora):
    • Benefício: Governança e Foco. Transforma o papel de “calculadora humana” para “analista de exceções”. Garante que apenas cotações fora da política consumam seu tempo.
    • Fator Crítico: A disciplina na rotina diária de atualização das bases (Preço/Custo) no Google Sheets é o motor que mantém o app vivo.
  • Para a Gerência Comercial:
    • Benefício: Mobilidade e Controle. Permite aprovar negociações críticas via celular, reduzindo gargalos. Garante visibilidade imediata de concessões de margem agressivas.

8 Inteligência de Mercado: Novas Análises Possíveis

Com a centralização dos dados no AppSheet, o time de Inteligência de Mercado poderá gerar análises inéditas (hoje impossíveis via WhatsApp/E-mail):

  1. Mapa de Calor da Margem: Identificar quais filiais ou regiões operam sistematicamente nas faixas “Laranja/Vermelha”, permitindo ajustes regionais de política de preços.
  2. Comportamento do Vendedor (Desvio Padrão): Identificar assessores que sistematicamente vendem no limite inferior da alçada (ex: sempre a -0,029), diferenciando quem vende “valor” de quem vende “preço”.
  3. Lead Time de Aprovação: Mensurar o tempo médio que um pedido fica parado nas filas de Pricing ou Gerência, identificando gargalos no processo de venda.
  4. Taxa de Conversão Real: Cruzar o volume de Cotações Criadas versus Pedidos Finalizados, entendendo a agressividade do mercado (cotações aprovadas que não viraram venda).
  5. Impacto Financeiro do Prazo: Correlacionar o Prazo Médio concedido com a Margem Realizada, identificando onde estamos perdendo dinheiro com custos financeiros desnecessários.

9 Pontos de Atenção e Melhoria (Backlog Técnico)

Para garantir a robustez do cálculo e do processo, os seguintes pontos foram mapeados como críticos e devem ser abordados prioritariamente no desenvolvimento ou logo após o MVP:

  • 9.1 Fluxo de Análise de Crédito:
    • Risco: A flag “Sujeito à análise” é apenas um alerta visual.
    • Solução: Definir se pedidos com essa flag devem ir para um status intermediário “Pendente Financeiro” antes de seguir para o Pricing.
  • 9.3 Fechamento do Ciclo (Feedback do SAP):
    • Risco: O App registra a “intenção de venda”, mas não sabe se o pedido foi faturado ou caiu por falta de estoque no ERP.
    • Solução Futura: Implementar rotina de retorno (SAP -> AppSheet) para atualizar o status final para “Faturado/Cancelado”.

10 10. Matriz de Riscos e Plano de Gerenciamento

Para garantir o sucesso do projeto, mapeamos os principais riscos e suas respectivas estratégias de mitigação:

Risco Impacto Probabilidade Estratégia de Mitigação
1. Erro de Cálculo (Matemático) 🔴 Crítico 🟡 Média Mitigação: Fase 4.1 (Teste de Mesa) rigorosa. Comparar centenas de cenários entre o App e o Excel da Débora antes do Go-Live. Travar fórmulas no AppSheet.
2. Desatualização de Preços (Humano) 🔴 Crítico 🟡 Média Mitigação: O App deve exibir em destaque no topo: “Tabela atualizada em: [DATA/HORA]”. Criar cultura/alarme para o Pricing atualizar as abas manuais toda manhã.
3. Resistência do Time Comercial 🟠 Alto 🟡 Média Mitigação: Focar na UX (Experiência do Usuário). O App deve ser mais rápido e fácil do que mandar um WhatsApp. Envolver assessores “chave” no Piloto (Fase 4.2) para serem evangelizadores.
4. Falha na Integração (Power Automate) 🟠 Alto 🟢 Baixa Mitigação: Configurar o Power Automate para enviar um e-mail de alerta para o Admin (Você) caso o fluxo de extração falhe. Manter o Excel da Débora como plano de contingência (backup).
5. Aprovação “às cegas” 🟡 Médio 🟡 Média Mitigação: O App deve obrigar o preenchimento de Motivo ao reprovar e destacar em vermelho/negrito as margens negativas na tela de aprovação do Gerente.

11 Análise de ROI (Retorno sobre Investimento)

O investimento estimado para o desenvolvimento é de R$ 4.500,00 (150 horas de dedicação interna). Abaixo, detalhamos como esse valor retorna para a Charrua.

11.0.1 ROI Financeiro (Proteção de Margem)

No mercado de combustíveis, a margem é sensível. Um erro manual de cálculo ou uma venda aprovada indevidamente pode gerar prejuízo imediato.

  • Cenário Hipotético: Se a ferramenta evitar que 1 carga (ex: 15.000 litros) seja vendida com um erro de cálculo de -R$ 0,05/L (que passaria despercebido no WhatsApp), a economia é de R$ 750,00.
  • Payback: Com apenas 6 ocorrências desse tipo evitadas em toda a empresa, o projeto já se paga integralmente.
  • Projeção: Considerando o volume total da distribuidora, a padronização do cálculo tende a recuperar milhares de reais em “vazamento de margem” (centavos perdidos por arredondamento ou falta de visão de custo real) já no primeiro mês.

11.0.2 ROI de Produtividade (Hora-Homem)

  • Pricing (Débora): Eliminação do tempo gasto respondendo e-mails/whats para vendas dentro da alçada (Verde). Se ela economizar 1 hora por dia, são ~20h/mês recuperadas para análise estratégica.
  • Assessores: Redução do tempo de espera. A aprovação automática (Verde) permite fechar o negócio na hora, aumentando a taxa de conversão e evitando que o cliente cote com a concorrência enquanto espera resposta.

Conclusão do ROI: O projeto possui custo de implementação irrelevante frente ao potencial de proteção de receita. O Payback estimado é imediato (< 1 mês de operação).