Mudanças entre as edições de "Criação de Cards de pedido hoje, Mês, Efetivado Mês por tipo de pedido para serem opção para uso no Dashboard"
(Sem diferença)
| |
Edição atual tal como às 15h10min de 4 de março de 2026
Histórico de Alterações
| Data | Quem | Comentários |
|---|---|---|
| 04/03/2026 | Renato Lima | Criação do documento |
Necessidade
O Contratante identificou a necessidade de customizar a visualização e a separação dos pedidos Hoje, Pedido Mês e Pedidos Efetivado Mês nos cards exibidos no sistema, atualmente apresentados de forma unificada, agrupando em um único indicador os pedidos de Venda e Bonificação, o que dificulta o processo de análise, conferência, no fluxo operacional dos usuários. Essa apresentação consolidada gera retrabalho, aumenta o tempo de validação e pode ocasionar falhas no acompanhamento correto por tipo de pedido.
Dessa forma, torna-se necessário que o sistema permita a separação dos cards por tipo de pedido, garantindo clareza e eficiência no processo de aprovação.
Solução
Para atender a essa necessidade, será realizada uma customização no sistema para que os Cards de pedidos Hoje, Pedido Mês e Pedidos Efetivado Mês, permitindo que o usuário visualize separadamente os pedidos de Venda e os pedidos de Bonificação.
Serão criados novos cards específicos, contemplando tanto o fluxo padrão quanto o fluxo de pendências do gestor, conforme abaixo:
• Card – Pedidos Hoje Venda
• Card – Pedidos Hoje Bonificação
• Card – Pedidos Mês Venda
• Card – Pedidos Mês Bonificação
• Card – Pedidos Efetivados Mês Venda
• Card – Pedidos Efetivados Mês Bonificação
Com isso, os cards deixarão de consolidar os pedidos em um único indicador, passando a apresentar informações de forma segmentada, proporcionando maior controle, agilidade e assertividade na análise.
Atores
Usuário (Vendedor / Operacional): Responsável por consultar pedidos pendentes e acompanhar o status de seus pedidos.
Gestor / Aprovador: Responsável por consultar e aprovar pedidos pendentes sob sua responsabilidade.
Pré-condições
• O usuário deve estar autenticado no sistema.
• O usuário deve possuir permissão de acesso ao dashboard.
• Devem existir regras atuais de status para pedidos pendentes já configuradas no sistema.
• Para exibição dos cards de gestor, o usuário deve possuir perfil de Gestor/Aprovador.
• O usuário deve estar nas alçadas correspondentes para realização da aprovação.
Escopo
Incluso
• Criação de novos cards separados por tipo de pedido: Venda e Bonificação.
• Ajuste do clique/detalhamento para respeitar o filtro do tipo selecionado.
• Manutenção das regras atuais de status e permissão.
Não Incluso
• Alteração de regras de aprovação ou workflow dos pedidos.
• Criação de novos status para pedidos.
• Alterações em cadastros de tipo de pedido no ERP.
• Mudanças na hierarquia ou regras de permissão já existentes.
Regras de Negócio
[RN1] - Separação obrigatória por tipo de pedido
O sistema deve apresentar cards distintos para pedido hoje, Mês e Efetivado Mês do tipo Venda e do tipo Bonificação, não sendo permitido consolidar ambos no mesmo card.
[RN2] - Cards obrigatórios a serem disponibilizados
Devem existir, no mínimo, os seguintes cards:
• Card – Pedidos Hoje Venda
• Card – Pedidos Hoje Bonificação
• Card – Pedidos Mês Venda
• Card – Pedidos Mês Bonificação
• Card – Pedidos Efetivados Mês Venda
• Card – Pedidos Efetivados Mês Bonificação
[RN3] - Disponibilidade dos cards (usuário)
Os novos cards deverão ser criados e disponibilizados nas opções de configuração do dashboard. A exibição dos cards para o usuário deverá ocorrer conforme as configurações aplicadas e de acordo com o papel do usuário.
[RN4] - Contagem e consistência dos quantitativos
A soma das quantidades dos cards por tipo (Venda + Bonificação) deve ser igual ao total que hoje é exibido no card consolidado equivalente (quando aplicável), garantindo consistência da informação.
[RN5] - Acesso ao detalhamento
Ao clicar em um card, o sistema deve abrir a lista/detalhamento exibindo somente pedidos do tipo do card selecionado, mantendo os filtros obrigatórios e comportamentos atuais (ordenação, paginação, etc.).
[RN6] - Atualização em tempo de consulta
Os valores exibidos nos cards devem refletir o estado mais atual dos pedidos no momento do acesso/atualização da tela, respeitando o mecanismo já existente (consulta/refresh).
[RN7] - Tratamento quando não houver pedidos
Quando não existirem pedidos para um determinado tipo, o card deve exibir 0 (zero) e permanecer visível (caso o padrão do dashboard seja manter cards visíveis).
[RN8] - Reaproveitamento das regras atuais
As regras atuais de quais pedidos o usuário pode ver devem ser mantidas (ex.: regras comerciais, empresa/filial, carteira, hierarquia, permissões). A mudança é apenas na segmentação por tipo.
[RN9] - Fonte de dados do tipo de pedido
O tipo de pedido deve ser determinado pelo campo já utilizado no sistema/SFA(ex.: “Tipo de Pedido” ou equivalente), garantindo que pedidos classificados como Bonificação não sejam exibidos em card de Venda, e vice-versa.
Aprovação
Considero aprovada a documentação da funcionalidade especificada acima, e autorizo a implementação da mesma no Sistema GeoSales, em nome da Organização a qual estou vinculado.
GeoSales
| Setor | Aprovado Por | Data |
|---|---|---|
| Integração - GeoSales | dd/mm/aaaa |
Empresa solicitante
| Setor | Aprovado Por | Data | Assinatura |
|---|---|---|---|
| Gerente TI - Cliente | Pessoa que aprovou | 00/00/0000 | |
| Gerente de Projeto - Cliente | Pessoa que aprovou | 00/00/0000 | |
| Gerente Comercial - Cliente | Pessoa que aprovou | 00/00/0000 |