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"

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
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

@@ Linha 11: / Linha 11: @@
 == 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 ==
@@ Linha 82: / Linha 82: @@
 Devem existir, no mínimo, os seguintes cards:
-•	Pedidos de Venda Pendentes
+•	Card – Pedidos Hoje Venda
+•	Card – Pedidos Hoje Bonificação
+•	Card – Pedidos Mês Venda
-•	Pedidos de Bonificação Pendentes
+•	Card – Pedidos Mês Bonificação
-•	Pedidos de Venda Pendentes (Gestor)
+•	Card – Pedidos Efetivados Mês Venda
-•	Pedidos de Bonificação Pendentes (Gestor)
+•	Card – Pedidos Efetivados Mês Bonificação
 '''[RN3] - Disponibilidade dos cards (usuário)'''
@@ Linha 94: / Linha 98: @@
 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'''
+'''[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.
-'''[RN7] - Acesso ao detalhamento'''
+'''[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.).
-'''[RN8] - Atualização em tempo de consulta'''
+'''[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).
-'''[RN9] - Tratamento quando não houver pedidos'''
+'''[RN7] - 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).
+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).
-'''[RN10] - Reaproveitamento das regras atuais'''
+'''[RN8] - 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.
+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.
-'''[RN11] - Fonte de dados do tipo de pedido'''
+'''[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.