Criação de Cards de pedido hoje, Mês, Efetivado Mês por tipo de pedido para serem opção para uso no Dashboard

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 pedidos pendentes 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:

• Pedidos de Venda Pendentes

• Pedidos de Bonificação Pendentes

• Pedidos de Venda Pendentes (Gestor)

• Pedidos de Bonificação Pendentes (Gestor)

[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] - Definição de “pendente

Um pedido deve ser considerado pendente quando estiver em status de aprovação pendente (conforme regra atual do sistema). A customização não deve alterar a regra existente de status/etapa; apenas aplicar a separação por tipo.

[RN5] - Regras de visibilidade por perfil

Usuários sem permissão de aprovação/gestão devem visualizar apenas os cards de usuário.

Usuários com permissão de gestor/aprovador devem visualizar os cards de usuário e os cards de gestor, conforme suas permissões.

[RN6] - 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.

[RN7] - 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.).

[RN8] - 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).

[RN9] - Tratamento quando não houver pedidos

Quando não existirem pedidos pendentes 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).

[RN10] - Reaproveitamento das regras atuais

As regras atuais de quais pedidos o usuário pode ver/aprovar devem ser mantidas (ex.: regras comerciais, empresa/filial, carteira, hierarquia, permissões). A mudança é apenas na segmentação por tipo.

[RN11] - 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
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