# O que muda para a equipe após alinhar a produção com a homologação (maio/2026) Este texto descreve, em linguagem simples, o que passa a existir ou a funcionar de outro modo nos sistemas que usamos no dia a dia. Foi pensado para quem atende cliente, comercial, financeiro e operações — não é documentação técnica. --- ## 1) Site (página pública de cotação para o cliente final) Neste pacote **não houve mudança voltada ao site público de cotação** que a equipe precise divulgar ao cliente final. O foco das entregas está no painel interno da CoteFrete e no painel da transportadora (DaCruz). --- ## 2) Administrativo (painel CoteFrete) ### 2.1 Módulo financeiro (novo bloco no menu interno) **Antes:** O time interno não tinha, no mesmo painel administrativo da CoteFrete, um conjunto de telas dedicadas a acompanhar entradas e saídas, contas bancárias da operação, fornecedores vinculados ao financeiro e relatórios consolidados desse tipo. **Depois:** Passa a existir um **módulo financeiro** acessível pelo menu do administrativo, com áreas para ver **resumo em painel**, **contas a pagar**, **contas a receber**, **fluxo de caixa**, **cadastro de fornecedores** usados nesse contexto, **relatórios** (incluindo visões como receita por transportadora e despesas por categoria, quando os dados estiverem lançados) e **contas bancárias** usadas na operação. Também há opções de **exportar** informações para planilha quando a tela oferecer esse botão. **O que fazer na prática:** Quem for validar após o deploy deve entrar com um usuário administrativo autorizado, abrir cada item do menu financeiro e conferir se os números batem com o que já era controlado fora do sistema (planilhas, banco, etc.). ### 2.2 Demais áreas do administrativo **Antes e depois:** CRM, cotações, transportadoras, disparos e demais menus que já existiam **continuam como estavam**, salvo pequenos ajustes visuais ou de texto que acompanham o pacote sem mudar regra de negócio central. --- ## 3) DaCruz (painel da transportadora) ### 3.1 Fechamento da cotação (tela principal depois que o frete foi aprovado) **Antes:** A transportadora via o andamento do frete, podia trabalhar motoristas e rastreamento, mas **não tinha na mesma tela** um histórico claro de **observações internas** em formato de linha do tempo, nem um **histórico do que já foi enviado ao cliente** (mensagem por aplicativo ou e-mail) com data e responsável. O **link público de rastreamento** era montado de forma mais simples e o recarregamento do cartão de status nem sempre trazia o mesmo nível de informação. **Não havia** na própria tela um atalho inteligente para **cadastrar ou abrir o cadastro do cliente como contato** usando o documento da cotação. **Não havia** botão ou ação dedicada para **gerar na hora o PDF da proposta já aprovada** para conferência ou envio. **Depois:** Na mesma tela de fechamento passam a aparecer **observações internas** organizadas (quem comentou e quando, quando houver registro). Passa a existir um **histórico de comunicações** (o que foi enviado, por qual canal e quando). O fluxo de **rastreamento** fica alinhado a uma lógica única: a lista de atualizações considera datas de atualização e **datas previstas de coleta e entrega** quando existirem, e o **link para o cliente acompanhar o frete** é montado da mesma forma em toda a tela (inclusive quando o cartão de status é atualizado sem recarregar a página inteira). Há uma **ação de contato**: se o documento do cliente estiver válido, o sistema oferece ir para o cadastro de contatos já com dados sugeridos ou abrir o contato existente. A transportadora pode **gerar o PDF da proposta comercial já aprovada** direto dessa tela, para baixar ou usar como anexo. **O que fazer na prática:** Abrir uma cotação aprovada real (ou de teste), percorrer cada bloco novo (observações, histórico de envios, link de rastreamento, contato, PDF) e comparar com o fluxo antigo anotado pela equipe. ### 3.2 Lista de cotações aprovadas e indicador de “fase” do fechamento **Antes:** Ajustar o indicador visual da fase do fechamento podia exigir mais passos dispersos ou não refletir imediatamente na lista o que a operação queria comunicar. **Depois:** Passa a existir um **fluxo em modal** para atualizar o **indicador de status do fechamento** de forma guiada, com feedback na lista quando a transportadora usa esse caminho. **O que fazer na prática:** Na lista de aprovadas, usar o novo fluxo de indicador em uma cotação de teste e confirmar se o cartão ou a linha da cotação mostra o estado esperado para o cliente interno/externo. ### 3.3 Tela de recebimentos e configurações **Antes:** Telas já existiam, com o layout e textos anteriores. **Depois:** **Recebimentos** ganha refinamentos de interface (por exemplo, como o **status do recebimento** é mostrado) para leitura mais rápida pela equipe da transportadora. Em **configurações**, há **ajustes visuais** alinhados ao restante do painel. **O que fazer na prática:** Conferir visualmente recebimentos e configurações após o deploy em um navegador limpo (sem cache antigo). --- ## 4) Comunicação (e-mails e mensagens automáticas) **Antes:** A transportadora enviava propostas e avisos pelos canais já configurados, mas **na tela de fechamento** não ficava registrado de forma centralizada **o histórico do que já foi disparado** por canal. **Depois:** O próprio fechamento mostra **o que já foi enviado ao cliente** (tipo de conteúdo, canal e momento), ajudando atendimento e comercial a não duplicar envio sem querer e a responder dúvidas com base no que de fato saiu. **O que fazer na prática:** Depois de um envio de teste (e-mail ou mensagem pelo canal que a transportadora usa), abrir o fechamento e confirmar se o registro aparece no histórico. --- ## 5) Operação (o que roda “nos bastidores” ou depende de infraestrutura) **Antes:** Parte das informações financeiras e de conciliação era mantida fora desse conjunto de telas ou dependia de processos manuais paralelos. **Depois:** O sistema passa a **suportar** o novo módulo financeiro com cadastros e movimentações internas; boletos e vínculos internos podem **associar-se a conta bancária** quando esse cadastro for usado. Rotinas que já existiam (como geração de cobrança ou integrações já conhecidas) **continuam**, ganhando suporte aos novos cadastros onde fizer sentido. **O que fazer na prática:** Garantir que **banco de dados e permissões** estejam atualizados conforme o roteiro do time de tecnologia antes de liberar o módulo financeiro a usuários finais. Registrar em voz alta, no canal da operação, a data em que o ambiente de produção foi atualizado para evitar que alguém oriente o cliente com base na versão antiga. --- *Este manual acompanha o pacote homologação → produção de 2026-05-07. O time técnico dispõe de um relatório separado com conflitos resolvidos e checklist de validação para desenvolvimento.*