Mudanças entre as edições de "Disponibilizar as Informações de Atualização de Versão"

De GeoSales
Ir para navegação Ir para pesquisar
(Criou página com '== Histórico de Alterações == {| class="wikitable" ! Data ! Quem ! Comentários |- | 11/09/2026 || Renato Lima || Criação do documento |- |} == Necessidade == ==...')
 
 
(27 revisões intermediárias pelo mesmo usuário não estão sendo mostradas)
Linha 5: Linha 5:
 
! Comentários  
 
! Comentários  
 
|-
 
|-
−
|  11/09/2026  || Renato Lima || Criação do documento  
+
|  19/10/2026  || Renato Lima || Criação do documento  
 
|-
 
|-
 
|}
 
|}
  
 
== Necessidade ==
 
== Necessidade ==
 +
O cliente necessita de um local no sistema onde possa consultar as atualizações disponibilizadas nas versões do GeoSales, permitindo identificar, de forma simples e organizada, as melhorias, funcionalidades e alterações liberadas ao longo do tempo.
  
 +
As informações deverão apresentar uma descrição funcional das atualizações relevantes para o usuário, possibilitando o acompanhamento das mudanças disponibilizadas em cada versão e a consulta de um histórico das atualizações por período.
  
 +
Para atender a essa necessidade, é necessário disponibilizar um mecanismo de seleção das informações que serão exibidas, considerando que o changelog técnico existente também contempla alterações internas, ajustes operacionais e outras informações que não devem necessariamente ser apresentadas aos clientes.
 
== Solução ==
 
== Solução ==
−
Será implementada uma evolução no relatório de clientes sem compra do módulo Inteligência, permitindo que o resultado da análise seja utilizado como origem para uma rotina de agendamento automático de atividades de retomada.
 
  
−
O fluxo será dividido em etapas:
+
Implementar uma funcionalidade para consulta do histórico de atualizações das versões do GeoSales, utilizando como referência o changelog existente e permitindo o cadastro manual das informações que deverão ser disponibilizadas aos clientes.
  
−
'''1.''' O usuário acessa o relatório de clientes sem compra;
+
Durante o processo de preparação de uma nova versão, as atualizações relevantes deverão ser selecionadas e descritas em linguagem simples, com foco nos benefícios e comportamentos percebidos pelo usuário. Somente as informações definidas para divulgação serão apresentadas na consulta.
  
−
'''2.''' Aplica os filtros necessários;
+
A solução deverá contemplar:
  
−
'''3.''' '''1.''' Analisa os clientes apresentados;
+
* Cadastro ou preenchimento de uma descrição específica para divulgação de cada atualização, associada à respectiva versão.
  
−
'''4.''' Utiliza as informações comerciais e financeiras para definir as oportunidades;
+
* Possibilidade de definir quais atualizações serão apresentadas aos clientes.
  
−
'''5.''' Seleciona os clientes que deseja trabalhar;
+
* Identificação da versão e da data de disponibilização das atualizações.
  
−
'''6.''' Aciona a opção para criação da agenda;
+
* Consulta do histórico de versões e respectivas alterações divulgadas.
  
−
'''7.''' O sistema apresenta uma segunda etapa para configuração da geração;
+
* Organização das informações por versão, com possibilidade de filtrar o histórico por período.
  
−
'''8.''' O gestor define os vendedores que participarão;
+
* Exibição das informações em uma interface integrada à identificação da versão no sistema, preferencialmente aproveitando o popup existente, mediante expansão de sua estrutura.
  
−
'''9.''' Define a quantidade de atividades que deverão ser realizadas por dia;
+
As informações destinadas à divulgação deverão ser mantidas de forma independente do changelog técnico original, evitando que alterações internas sejam publicadas automaticamente.
−
 
 
−
'''10.''' Define o período para distribuição das atividades;
 
−
 
 
−
'''11.''' O sistema realiza a distribuição automática dos clientes;
 
−
 
 
−
'''12.''' Apresenta um resumo da agenda que será criada;
 
−
 
 
−
'''13.''' O gestor poderá revisar a geração;
 
−
 
 
−
'''14.''' Após a confirmação, o sistema cria os eventos na agenda;
 
−
 
 
−
'''15.''' Os eventos serão identificados como atividades do tipo Retomada;
 
−
 
 
−
'''16.''' A observação do evento conterá informações relevantes sobre o cliente para auxiliar o vendedor durante o atendimento.
 
−
 
 
−
====Relatório de Clientes Inativos====
 
−
 
 
−
O relatório existente no Inteligência será utilizado como ponto inicial do processo.
 
−
 
 
−
Além das informações já disponíveis, deverão ser disponibilizados dados que permitam ao gestor avaliar a relevância e o momento de retomada de cada cliente.
 
−
 
 
−
'''Informações comerciais'''
 
−
* Cliente;
 
−
* Vendedor responsável;
 
−
* Supervisor;
 
−
* Organização de venda;
 
−
* Canal;
 
−
* Curva ABC;
 
−
* Valor vendido no período;
 
−
* Quantidade de pedidos;
 
−
* Data da última compra;
 
−
* Quantidade de dias de inatividade;
 
−
* Frequência média de compra.
 
−
* Valor Ticket Médio
 
−
 
 
−
'''Informações financeiras'''
 
−
* Status do cliente;
 
−
* Indicador de cliente bloqueado/não bloqueado;
 
−
* Valor total em aberto;
 
−
* Valor total vencido/em atraso;
 
−
* Limite de crédito.
 
−
 
 
−
Essas informações deverão permitir que o gestor faça uma análise conjunta do comportamento comercial e financeiro do cliente.
 
−
 
 
−
====Critérios para análise e seleção====
 
−
 
 
−
O gestor poderá utilizar as informações do relatório para estabelecer seus próprios critérios de priorização.
 
−
 
 
−
Exemplos:
 
−
 
 
−
* Clientes classificados como A;
 
−
* Clientes classificados como A e B;
 
−
* Clientes com determinado valor médio de compras;
 
−
* Clientes sem compra há mais de 90 dias;
 
−
* Clientes cuja frequência habitual de compra seja inferior ao período atual de inatividade;
 
−
* Clientes sem bloqueio financeiro;
 
−
* Clientes com limite de crédito disponível.
 
−
 
 
−
Os critérios acima são exemplos de utilização das informações e não deverão ser aplicados automaticamente pelo sistema, salvo aqueles que forem definidos como filtros da própria consulta.
 
−
 
 
−
====Criação da Agenda====
 
−
 
 
−
A partir do resultado do relatório, o gestor poderá iniciar o processo de criação da agenda.
 
−
 
 
−
A opção de criação deverá considerar o conjunto de dados resultante dos filtros aplicados no relatório.
 
−
 
 
−
Dessa forma, o usuário não precisará repetir na tela de criação todos os filtros já utilizados no relatório.
 
−
 
 
−
Exemplo
 
−
 
 
−
O gestor poderá filtrar previamente:
 
−
 
 
−
Canal = Varejo
 
−
Supervisor = João
 
−
Período = últimos 12 meses
 
−
Clientes sem compra há mais de 90 dias
 
−
 
 
−
Após aplicar esses filtros, somente os clientes resultantes da consulta serão considerados na etapa de criação da agenda.
 
−
 
 
−
====Parâmetros para geração da agenda====
 
−
 
 
−
Na etapa de configuração da agenda, o gestor deverá informar os parâmetros necessários para a geração automática.
 
−
 
 
−
'''Tipo de atividade'''
 
−
 
 
−
O sistema deverá utilizar um tipo específico para identificar os eventos criados pela rotina.
 
−
 
 
−
'''Tipo sugerido: Retomada'''
 
−
 
 
−
O tipo deverá ser atribuído automaticamente, evitando que o gestor tenha que selecionar manualmente o tipo da atividade em cada geração.
 
−
 
 
−
====Vendedores====
 
−
 
 
−
O gestor deverá poder selecionar os vendedores para os quais deseja gerar as atividades.
 
−
 
 
−
A seleção deverá permitir trabalhar com múltiplos vendedores simultaneamente.
 
−
 
 
−
Isso é necessário para permitir a geração em massa em empresas que possuem grande quantidade de vendedores.
 
−
 
 
−
====Quantidade de atividades por dia====
 
−
 
 
−
O gestor deverá informar a quantidade de atividades que deseja gerar diariamente.
 
−
 
 
−
Exemplo:
 
−
 
 
−
2 atividades por dia.
 
−
 
 
−
Caso existam 10 clientes para determinado vendedor, o sistema poderá distribuí-los em cinco dias.
 
−
 
 
−
Caso existam 20 clientes, serão distribuídos em dez dias, considerando a mesma capacidade diária.
 
−
 
 
−
====Período de execução====
 
−
 
 
−
O gestor deverá informar o período no qual as atividades deverão ser distribuídas.
 
−
 
 
−
Exemplo:
 
−
 
 
−
Início: 14/09/2026
 
−
Fim: 25/09/2026
 
−
 
 
−
O sistema deverá respeitar o período definido durante a distribuição das atividades.
 
−
 
 
−
====Geração em massa====
 
−
 
 
−
A geração deverá ser realizada de forma automática e em massa.
 
−
 
 
−
O sistema deverá considerar:
 
−
 
 
−
* Clientes selecionados;
 
−
* Vendedor responsável;
 
−
* Quantidade de atividades por dia;
 
−
* Período informado;
 
−
*Critérios definidos no relatório.
 
−
Exemplo
 
−
 
 
−
O resultado possui:
 
−
 
 
−
{| class="wikitable"
 
−
! Vendedor
 
−
! Cliente Selecionados
 
−
|-
 
−
|  Renato  || 10
 
−
|-
 
−
|  Andre || 20
 
−
|-
 
−
|  Carlos  || 15
 
−
|-
 
−
|}
 
−
 
 
−
 
 
−
O gestor define:
 
−
 
 
−
2 atividades por dia
 
−
 
 
−
O sistema deverá realizar automaticamente a distribuição:
 
−
 
 
−
{| class="wikitable"
 
−
! Vendedor
 
−
! Clientes
 
−
! Atividades/dia
 
−
! Dias necessários
 
−
|-
 
−
|  Renato  || 10 || 2 || 5
 
−
|-
 
−
|  André  || 20 || 2 || 5
 
−
|-
 
−
|  Carlos  || 15 || 2 || 8*
 
−
|-
 
−
|}
 
−
 
 
−
 
 
−
*Considerando arredondamento para o último dia.
 
−
 
 
−
====Resumo da geração====
 
−
 
 
−
Antes da criação definitiva dos eventos, o sistema deverá apresentar uma tela de resumo.
 
−
 
 
−
O objetivo é permitir que o gestor valide o resultado da geração antes da confirmação.
 
−
 
 
−
'''Sugestão de informações'''
 
−
* Vendedor;
 
−
* Quantidade de clientes elegíveis;
 
−
* Quantidade de clientes selecionados;
 
−
* Quantidade de atividades a gerar;
 
−
* Quantidade de atividades por dia;
 
−
* Data inicial;
 
−
* Data final;
 
−
* Quantidade de dias necessários.
 
−
 
 
−
O resumo deverá permitir identificar como os clientes serão distribuídos entre os vendedores.
 
−
 
 
−
====Revisão antes da confirmação====
 
−
 
 
−
O gestor deverá poder revisar o resultado da geração.
 
−
 
 
−
Será possível, por exemplo:
 
−
 
 
−
* Confirmar todos os vendedores;
 
−
* Retirar determinado vendedor;
 
−
* Manter determinado vendedor para geração posterior;
 
−
* Revisar a quantidade de atividades;
 
−
* Cancelar a geração.
 
−
 
 
−
Somente após a confirmação os eventos deverão ser efetivamente criados.
 
−
 
 
−
====Criação dos eventos====
 
−
 
 
−
Após a confirmação, o sistema deverá criar automaticamente as atividades na agenda dos respectivos vendedores.
 
−
 
 
−
Cada evento deverá estar associado, no mínimo, a:
 
−
 
 
−
* Cliente;
 
−
* Vendedor/responsável;
 
−
* Data;
 
−
* Tipo de atividade;
 
−
* Observação.
 
−
 
 
−
O evento deverá ser identificado como uma atividade de Retomada.
 
−
 
 
−
====Observação automática da atividade====
 
−
 
 
−
Para evitar que o vendedor precise retornar ao relatório para entender o motivo da atividade, o sistema deverá gerar uma observação contendo um resumo das principais informações utilizadas na análise.
 
−
 
 
−
Exemplo
 
−
 
 
−
'''Retomada de cliente inativo'''
 
−
* Última compra: 15/05/2026
 
−
* Inatividade: 118 dias
 
−
* Frequência média de compra: 45 dias
 
−
* Valor vendido no período: R$ 35.500,00
 
−
* Quantidade de pedidos: 12
 
−
* Curva ABC: A
 
−
* Status: Ativo
 
−
* Valor em aberto: R$ 3.200,00
 
−
* Valor vencido: R$ 0,00
 
−
* Limite de crédito: R$ 10.000,00
 
−
 
 
−
A composição definitiva das informações da observação deverá ser definida durante a implementação.
 
  
 
== Implementação ==
 
== Implementação ==
−
A implementação deverá contemplar as seguintes etapas:
+
'''1. Adequação da estrutura de dados:''' criar ou adaptar os campos necessários para armazenar a descrição destinada à divulgação e a indicação de quais atualizações poderão ser apresentadas aos clientes, associando os registros à versão correspondente.
−
 
 
−
'''Etapa 1 — Evolução do relatório'''
 
−
* Revisar o relatório de clientes sem compra;
 
−
* Disponibilizar as informações comerciais necessárias;
 
−
* Disponibilizar informações de crédito;
 
−
* Disponibilizar a curva ABC;
 
−
* Disponibilizar indicadores de inatividade e frequência;
 
−
* Criar a ação para iniciar a geração da agenda.
 
−
 
 
−
'''Etapa 2 — Tela de configuração'''
 
−
 
 
−
Desenvolver a etapa responsável pela configuração da geração, contemplando:
 
−
 
 
−
* Tipo de atividade;
 
−
* Vendedores;
 
−
* Quantidade de atividades por dia;
 
−
* Data inicial;
 
−
* Data final;
 
−
* Demais parâmetros definidos no detalhamento funcional.
 
−
 
 
−
'''Etapa 3 — Motor de distribuição'''
 
  
−
Implementar a lógica responsável por:
+
'''2. Preparação da versão:''' durante o processo de preparação e aprovação de uma versão, identificar as alterações relevantes para os clientes e registrar suas respectivas descrições em linguagem funcional.
  
−
* Receber os clientes resultantes do relatório;
+
'''3. Seleção das atualizações:''' permitir que o responsável pela preparação da versão determine quais informações serão disponibilizadas para consulta, mantendo as alterações não selecionadas restritas ao histórico técnico.
−
* Agrupar os clientes por vendedor;
 
−
* Aplicar a capacidade diária;
 
−
* Distribuir as atividades;
 
−
* Respeitar o período definido;
 
−
* Preparar os eventos.
 
  
−
'''Etapa 4 — Resumo'''
+
'''4. Disponibilização das informações:''' após a aprovação e publicação da versão, apresentar as atualizações selecionadas na área de consulta do sistema.
  
−
Desenvolver a tela de conferência da geração, permitindo ao gestor visualizar e revisar o resultado antes da efetivação.
+
'''5. Interface de consulta:''' adaptar o popup existente, se tecnicamente viável, para permitir a visualização das atualizações por versão, com identificação da data, descrição das alterações e acesso ao histórico.
  
−
'''Etapa 5 — Criação dos eventos'''
+
'''6. Filtro do histórico:''' disponibilizar um filtro por período para facilitar a consulta das atualizações publicadas em determinado intervalo de tempo.
  
−
Após a confirmação:
+
'''7. Validação:''' realizar os testes em ambiente de homologação, verificando o cadastro, a seleção, a publicação e a consulta das informações antes da disponibilização em produção.
−
 
 
−
* Criar os eventos;
 
−
* Associar cliente e vendedor;
 
−
* Definir data;
 
−
* Definir tipo “Retomada”;
 
−
* Gerar a observação automática.
 
−
 
 
−
'''Etapa 6 — Validação'''
 
−
 
 
−
Realizar testes contemplando:
 
−
 
 
−
* Um vendedor;
 
−
* Múltiplos vendedores;
 
−
* Grande quantidade de clientes;
 
−
* Diferentes capacidades diárias;
 
−
* Períodos diferentes;
 
−
* Clientes com e sem informações financeiras;
 
−
* Clientes com diferentes classificações ABC;
 
−
* Validação da distribuição;
 
−
* Validação da criação dos eventos.
 
  
 
== Escopo ==
 
== Escopo ==
  
 
=== Escopo Incluso ===
 
=== Escopo Incluso ===
−
* Evolução do relatório de clientes sem compra;
+
* Criação ou adequação da estrutura de armazenamento das informações de atualização destinadas aos clientes.
−
* Exibição das informações comerciais necessárias;
 
−
* Exibição das informações de crédito;
 
−
* Exibição da curva ABC;
 
−
* Indicadores de frequência e inatividade;
 
−
* Ação para iniciar a criação da agenda;
 
−
* Seleção de vendedores;
 
−
* Definição de quantidade de atividades por dia;
 
−
* Definição de período;
 
−
* Geração em massa;
 
−
* Distribuição automática dos clientes;
 
−
* Tela de resumo;
 
−
* Revisão antes da confirmação;
 
−
* Criação automática dos eventos;
 
−
* Identificação do evento como “Retomada”;
 
−
* Geração automática da observação;
 
−
* Respeito à estrutura atual de cliente/vendedor.
 
  
−
=== Escopo Não Incluso ===
+
* Associação das informações à respectiva versão do sistema.
−
* Transferência automática de carteira;
 
−
* Criação de nova estrutura de carteira;
 
−
* Alteração do relacionamento cliente/vendedor;
 
−
* Alteração da visualização de pedidos históricos;
 
−
* Criação automática de rotas;
 
−
* Otimização geográfica de visitas;
 
−
* Sugestão automática de pedido;
 
−
* Sugestão de produtos;
 
−
* Inteligência preditiva para escolha automática dos clientes;
 
−
* Automação de cobrança;
 
−
* Regras de comissão;
 
−
* Alterações na integração de pedidos;
 
−
* Outras funcionalidades não relacionadas diretamente à geração da agenda de retomada.
 
  
−
== Atores ==
+
* Cadastro manual das descrições funcionais das atualizações.
−
'''Gestor'''
 
  
−
Responsável por:
+
* Identificação das atualizações que deverão ser exibidas aos clientes.
  
−
* Consultar o relatório;
+
* Restrição da consulta às informações selecionadas para divulgação.
−
* Aplicar filtros;
 
−
* Analisar os clientes;
 
−
* Definir os critérios de priorização;
 
−
* Selecionar os vendedores;
 
−
* Definir capacidade diária;
 
−
* Definir período;
 
−
* Validar o resumo;
 
−
* Confirmar a geração.
 
  
−
'''Vendedor/Responsável pela atividade'''
+
* Exibição da identificação da versão, da data e das respectivas descrições.
  
−
Responsável por:
+
* Consulta do histórico de atualizações disponibilizadas.
  
−
* Receber as atividades de retomada;
+
* Implementação de filtro por período.
−
* Consultar as informações apresentadas na atividade;
 
−
* Realizar o contato/visita ao cliente;
 
−
* Registrar o resultado da atividade conforme os recursos existentes no sistema.
 
  
−
'''Sistema'''
+
* Adequação do popup existente para apresentação das informações, conforme viabilidade técnica.
  
−
Responsável por:
+
* Testes funcionais em homologação.
  
−
* Consultar e apresentar os dados;
+
=== Escopo Não Incluso ===
−
* Processar os clientes selecionados;
 
−
* Distribuir as atividades;
 
−
* Criar os eventos;
 
−
* Registrar o tipo da atividade;
 
−
* Gerar a observação automaticamente.
 
  
−
== Pré-condições ==
+
* Publicação automática e integral do changelog técnico existente.
−
* Usuário possuir acesso ao módulo Inteligência;
 
−
* Relatório de clientes sem compra estar disponível;
 
−
* Clientes possuírem vínculo com vendedor;
 
−
* Informações de vendas estarem disponíveis;
 
−
* Informações necessárias para os indicadores estarem integradas;
 
−
* Funcionalidade de agenda/eventos estar disponível;
 
−
* Usuário possuir permissão para gerar atividades;
 
−
* Vendedores selecionados estarem ativos/disponíveis para receber atividades.
 
  
−
== Pós-condições ==
+
* Exibição automática de todas as alterações registradas durante o desenvolvimento.
−
Após a confirmação da geração:
 
  
−
* As atividades de retomada serão criadas;
+
* Divulgação de ajustes internos, correções técnicas ou alterações operacionais não selecionadas para publicação.
−
* Cada atividade estará associada ao respectivo cliente;
 
−
* Cada atividade estará atribuída ao responsável/vendedor;
 
−
* As datas serão distribuídas conforme os parâmetros informados;
 
−
* O evento possuirá identificação de atividade de retomada;
 
−
* O evento possuirá observação com o resumo das informações do cliente.
 
  
−
== Regras de Negócio ==
+
* Geração automática de textos explicativos a partir das descrições técnicas do changelog.
  
−
'''[RN1] - Origem da geração'''
+
* Envio de notificações, e-mails ou mensagens aos clientes informando sobre novas versões.
  
−
A agenda deverá ser gerada a partir dos clientes resultantes do relatório de clientes sem compra do Inteligência.
+
* Implementação de um portal externo ou de uma página pública para consulta das versões.
  
−
'''[RN2] - Filtros '''
+
* Alteração do processo de versionamento, compilação ou publicação do sistema.
  
−
Os filtros aplicados no relatório deverão determinar o conjunto de clientes considerado para a geração da agenda.
+
* Migração automática de todo o histórico de versões anteriores, salvo se definida posteriormente como necessidade complementar.
  
−
'''[RN3] - Decisão do gestor '''
+
== Atores ==
 +
'''Responsável pela preparação da versão:''' identifica as alterações relevantes, registra as descrições funcionais e seleciona as informações destinadas à divulgação.
  
−
O sistema não deverá determinar automaticamente quais clientes devem ser priorizados. A seleção deverá permanecer sob responsabilidade do gestor.
+
'''Equipe de desenvolvimento:''' implementa a estrutura de armazenamento, os mecanismos de seleção e a interface de consulta das atualizações.
  
−
'''[RN4] - Curva ABC '''
+
'''Equipe de testes/homologação:''' valida o comportamento da funcionalidade e verifica se somente as informações selecionadas são apresentadas.
  
−
A classificação ABC deverá ser apresentada como informação para apoio à decisão e poderá ser utilizada como critério de seleção.
+
'''Cliente/usuário do GeoSales:''' consulta o histórico de versões e as atualizações disponibilizadas no sistema.
  
−
'''[RN5] - Histórico comercial '''
+
== Pré-condições ==
 +
* Deve existir uma versão do GeoSales identificada no processo de disponibilização.
  
−
O relatório deverá disponibilizar informações relacionadas ao histórico de compras do cliente, incluindo última compra, frequência, quantidade de pedidos e valor vendido.
+
* O changelog técnico ou as informações referentes às alterações realizadas devem estar disponíveis para consulta pela equipe responsável.
  
−
'''[RN6] - Inatividade '''
+
* O responsável pela preparação da versão deve ter acesso ao mecanismo de cadastro e seleção das informações destinadas à divulgação.
  
−
O sistema deverá apresentar o período de inatividade do cliente, preferencialmente em quantidade de dias, além da data da última compra.
+
* As descrições das atualizações devem estar registradas e associadas à respectiva versão antes de sua disponibilização aos clientes.
  
−
'''[RN7] - Crédito '''
+
* A funcionalidade de consulta deve estar habilitada no ambiente em que será utilizada.
  
−
O sistema deverá apresentar informações de crédito do cliente, incluindo status, valores em aberto, valores vencidos e limite de crédito, quando disponíveis.
+
== Pós-condições ==
  
−
'''[RN8] - Tipo de atividade '''
 
  
−
Os eventos gerados automaticamente pela rotina deverão utilizar o tipo Retomada ou outro tipo previamente definido para essa finalidade.
+
* As atualizações selecionadas para divulgação ficam armazenadas e associadas à versão correspondente.
  
−
'''[RN9] - Seleção de vendedores '''
+
* O usuário consegue consultar as informações disponibilizadas para cada versão.
  
−
A geração deverá permitir a seleção de múltiplos vendedores em uma única operação.
+
* O histórico de atualizações publicadas permanece disponível para consultas posteriores, a partir da disponibilidade desta funcionalidade.
  
−
'''[RN10] - Capacidade diária '''
+
* As alterações não selecionadas para divulgação não são apresentadas na consulta destinada aos clientes.
  
−
O gestor deverá informar a quantidade de atividades que deverão ser distribuídas por dia.
+
* As informações permanecem organizadas por versão e podem ser consultadas conforme o período informado no filtro.
  
−
'''[RN11] - Período '''
+
== Regras de Negócio ==
  
−
A distribuição deverá respeitar o período informado pelo gestor.
+
'''RN01 — Associação à versão:''' toda atualização destinada à divulgação deverá estar vinculada à respectiva versão do GeoSales.
  
−
'''[RN12] - Distribuição '''
+
'''RN02 — Seleção para divulgação:''' somente as atualizações explicitamente selecionadas para divulgação poderão ser apresentadas na consulta destinada aos clientes.
  
−
Os clientes deverão ser distribuídos automaticamente considerando o vendedor responsável e a quantidade de atividades definida.
+
'''RN03 — Descrição funcional:''' as atualizações selecionadas deverão possuir uma descrição em linguagem simples, permitindo ao usuário compreender o que foi alterado ou disponibilizado.
  
−
''' RN13 — Geração em massa '''
+
'''RN04 — Separação do changelog técnico:''' o changelog técnico original não deverá ser publicado integralmente de forma automática. As informações deverão passar por uma seleção e descrição específica antes de serem disponibilizadas.
  
−
A rotina deverá permitir gerar atividades para diversos vendedores em uma única execução.
+
'''RN05 — Identificação da versão:''' as informações apresentadas deverão permitir identificar claramente a versão à qual pertencem.
  
−
'''RN14 — Validação'''
+
'''RN06 — Data de disponibilização:''' cada conjunto de atualizações deverá apresentar a data correspondente à disponibilização da versão, permitindo ao usuário identificar quando as alterações foram liberadas.
−
Os eventos não deverão ser criados definitivamente antes da confirmação do resumo apresentado ao gestor.
 
  
−
'''RN15 — Revisão'''
+
'''RN07 — Organização do histórico:''' as atualizações deverão ser agrupadas por versão, mantendo a identificação e as descrições das alterações relacionadas.
  
−
O gestor deverá poder retirar vendedores da geração antes da confirmação.
+
'''RN08 — Filtro por período:''' o usuário deverá conseguir consultar as atualizações considerando um intervalo de datas, facilitando a visualização das alterações disponibilizadas no período informado.
  
−
'''RN16 — Observação'''
+
'''RN09 — Atualizações sem divulgação:''' alterações internas, técnicas ou operacionais que não tenham sido selecionadas não deverão ser exibidas na consulta dos clientes.
  
−
Os eventos gerados deverão possuir uma observação automática com informações relevantes do cliente.
+
'''RN10 — Consulta de versões anteriores:''' as atualizações anteriormente disponibilizadas deverão permanecer acessíveis no histórico, conforme os critérios de consulta definidos para a funcionalidade.
  
−
'''RN17 — Estrutura de vendedores'''
+
'''RN11 — Disponibilização condicionada à publicação:''' as informações de uma versão somente deverão ficar disponíveis para consulta dos clientes após a efetiva disponibilização da respectiva versão.
  
−
A rotina deverá respeitar a estrutura atual de relacionamento entre cliente e vendedor existente no sistema.
+
'''RN12 — Manutenção das informações:''' deverá ser possível registrar as descrições destinadas à divulgação durante a preparação da versão, sem exigir a alteração do conteúdo técnico original do changelog.
  
−
'''RN18 — Carteira'''
+
== Fluxograma ==
  
−
A funcionalidade não deverá criar uma nova estrutura de carteira ou realizar transferência automática de clientes entre vendedores.
+
[[Arquivo:Disponibilizar_versao.png|1150px]]
  
−
'''RN19 — Pedidos anteriores'''
+
====Fluxo resumido da solução====
−
 
 
−
A rotina não deverá alterar regras existentes de visualização ou propriedade dos pedidos históricos dos clientes.
 
−
 
 
−
'''RN20 — Rotas'''
 
  
−
A primeira versão não deverá realizar criação ou otimização automática de rotas.
+
1. A equipe responsável prepara uma nova versão do GeoSales e consulta o changelog técnico.
  
−
'''RN21 — Sugestão de pedido'''
+
2. As alterações são avaliadas individualmente, identificando aquelas que são relevantes para os clientes.
  
−
A primeira versão não deverá gerar sugestão automática de produtos ou pedidos.
+
3. As atualizações selecionadas recebem descrições em linguagem simples e são marcadas para divulgação.
  
−
'''RN22 — Evolução futura'''
+
4. As alterações não selecionadas permanecem fora da consulta destinada aos clientes.
  
−
A estrutura deverá permitir futuras evoluções para utilização em outros processos, como cobrança, rotas e sugestões comerciais.
+
5. Após a aprovação e a publicação da versão, as atualizações selecionadas ficam disponíveis no sistema.
  
−
== Fluxograma ==
+
6. O cliente acessa a área de consulta, aplica o filtro por período, se desejar, e visualiza as versões e respectivas atualizações publicadas.
−
 
 
−
[[Arquivo:Inteligence_geração_agenda.png|1100px]]
 
−
 
 
−
====Fluxo resumido da solução====
 
  
−
Inteligência → Relatório de clientes inativos → Análise → Seleção → Configuração da agenda → Distribuição automática → Resumo → Validação → Criação dos eventos → Atividade de Retomada para o vendedor
+
'''Regra principal:''' nenhuma atualização deverá ser apresentada automaticamente ao cliente apenas por constar no changelog técnico. A divulgação depende da seleção prévia e da publicação da versão correspondente.
  
 
== Aprovação ==
 
== Aprovação ==

Edição atual tal como às 17h47min de 21 de outubro de 2026

Histórico de Alterações

Data Quem Comentários
19/10/2026 Renato Lima Criação do documento

Necessidade

O cliente necessita de um local no sistema onde possa consultar as atualizações disponibilizadas nas versões do GeoSales, permitindo identificar, de forma simples e organizada, as melhorias, funcionalidades e alterações liberadas ao longo do tempo.

As informações deverão apresentar uma descrição funcional das atualizações relevantes para o usuário, possibilitando o acompanhamento das mudanças disponibilizadas em cada versão e a consulta de um histórico das atualizações por período.

Para atender a essa necessidade, é necessário disponibilizar um mecanismo de seleção das informações que serão exibidas, considerando que o changelog técnico existente também contempla alterações internas, ajustes operacionais e outras informações que não devem necessariamente ser apresentadas aos clientes.

Solução

Implementar uma funcionalidade para consulta do histórico de atualizações das versões do GeoSales, utilizando como referência o changelog existente e permitindo o cadastro manual das informações que deverão ser disponibilizadas aos clientes.

Durante o processo de preparação de uma nova versão, as atualizações relevantes deverão ser selecionadas e descritas em linguagem simples, com foco nos benefícios e comportamentos percebidos pelo usuário. Somente as informações definidas para divulgação serão apresentadas na consulta.

A solução deverá contemplar:

  • Cadastro ou preenchimento de uma descrição específica para divulgação de cada atualização, associada à respectiva versão.
  • Possibilidade de definir quais atualizações serão apresentadas aos clientes.
  • Identificação da versão e da data de disponibilização das atualizações.
  • Consulta do histórico de versões e respectivas alterações divulgadas.
  • Organização das informações por versão, com possibilidade de filtrar o histórico por período.
  • Exibição das informações em uma interface integrada à identificação da versão no sistema, preferencialmente aproveitando o popup existente, mediante expansão de sua estrutura.

As informações destinadas à divulgação deverão ser mantidas de forma independente do changelog técnico original, evitando que alterações internas sejam publicadas automaticamente.

Implementação

1. Adequação da estrutura de dados: criar ou adaptar os campos necessários para armazenar a descrição destinada à divulgação e a indicação de quais atualizações poderão ser apresentadas aos clientes, associando os registros à versão correspondente.

2. Preparação da versão: durante o processo de preparação e aprovação de uma versão, identificar as alterações relevantes para os clientes e registrar suas respectivas descrições em linguagem funcional.

3. Seleção das atualizações: permitir que o responsável pela preparação da versão determine quais informações serão disponibilizadas para consulta, mantendo as alterações não selecionadas restritas ao histórico técnico.

4. Disponibilização das informações: após a aprovação e publicação da versão, apresentar as atualizações selecionadas na área de consulta do sistema.

5. Interface de consulta: adaptar o popup existente, se tecnicamente viável, para permitir a visualização das atualizações por versão, com identificação da data, descrição das alterações e acesso ao histórico.

6. Filtro do histórico: disponibilizar um filtro por período para facilitar a consulta das atualizações publicadas em determinado intervalo de tempo.

7. Validação: realizar os testes em ambiente de homologação, verificando o cadastro, a seleção, a publicação e a consulta das informações antes da disponibilização em produção.

Escopo

Escopo Incluso

  • Criação ou adequação da estrutura de armazenamento das informações de atualização destinadas aos clientes.
  • Associação das informações à respectiva versão do sistema.
  • Cadastro manual das descrições funcionais das atualizações.
  • Identificação das atualizações que deverão ser exibidas aos clientes.
  • Restrição da consulta às informações selecionadas para divulgação.
  • Exibição da identificação da versão, da data e das respectivas descrições.
  • Consulta do histórico de atualizações disponibilizadas.
  • Implementação de filtro por período.
  • Adequação do popup existente para apresentação das informações, conforme viabilidade técnica.
  • Testes funcionais em homologação.

Escopo Não Incluso

  • Publicação automática e integral do changelog técnico existente.
  • Exibição automática de todas as alterações registradas durante o desenvolvimento.
  • Divulgação de ajustes internos, correções técnicas ou alterações operacionais não selecionadas para publicação.
  • Geração automática de textos explicativos a partir das descrições técnicas do changelog.
  • Envio de notificações, e-mails ou mensagens aos clientes informando sobre novas versões.
  • Implementação de um portal externo ou de uma página pública para consulta das versões.
  • Alteração do processo de versionamento, compilação ou publicação do sistema.
  • Migração automática de todo o histórico de versões anteriores, salvo se definida posteriormente como necessidade complementar.

Atores

Responsável pela preparação da versão: identifica as alterações relevantes, registra as descrições funcionais e seleciona as informações destinadas à divulgação.

Equipe de desenvolvimento: implementa a estrutura de armazenamento, os mecanismos de seleção e a interface de consulta das atualizações.

Equipe de testes/homologação: valida o comportamento da funcionalidade e verifica se somente as informações selecionadas são apresentadas.

Cliente/usuário do GeoSales: consulta o histórico de versões e as atualizações disponibilizadas no sistema.

Pré-condições

  • Deve existir uma versão do GeoSales identificada no processo de disponibilização.
  • O changelog técnico ou as informações referentes às alterações realizadas devem estar disponíveis para consulta pela equipe responsável.
  • O responsável pela preparação da versão deve ter acesso ao mecanismo de cadastro e seleção das informações destinadas à divulgação.
  • As descrições das atualizações devem estar registradas e associadas à respectiva versão antes de sua disponibilização aos clientes.
  • A funcionalidade de consulta deve estar habilitada no ambiente em que será utilizada.

Pós-condições

  • As atualizações selecionadas para divulgação ficam armazenadas e associadas à versão correspondente.
  • O usuário consegue consultar as informações disponibilizadas para cada versão.
  • O histórico de atualizações publicadas permanece disponível para consultas posteriores, a partir da disponibilidade desta funcionalidade.
  • As alterações não selecionadas para divulgação não são apresentadas na consulta destinada aos clientes.
  • As informações permanecem organizadas por versão e podem ser consultadas conforme o período informado no filtro.

Regras de Negócio

RN01 — Associação à versão: toda atualização destinada à divulgação deverá estar vinculada à respectiva versão do GeoSales.

RN02 — Seleção para divulgação: somente as atualizações explicitamente selecionadas para divulgação poderão ser apresentadas na consulta destinada aos clientes.

RN03 — Descrição funcional: as atualizações selecionadas deverão possuir uma descrição em linguagem simples, permitindo ao usuário compreender o que foi alterado ou disponibilizado.

RN04 — Separação do changelog técnico: o changelog técnico original não deverá ser publicado integralmente de forma automática. As informações deverão passar por uma seleção e descrição específica antes de serem disponibilizadas.

RN05 — Identificação da versão: as informações apresentadas deverão permitir identificar claramente a versão à qual pertencem.

RN06 — Data de disponibilização: cada conjunto de atualizações deverá apresentar a data correspondente à disponibilização da versão, permitindo ao usuário identificar quando as alterações foram liberadas.

RN07 — Organização do histórico: as atualizações deverão ser agrupadas por versão, mantendo a identificação e as descrições das alterações relacionadas.

RN08 — Filtro por período: o usuário deverá conseguir consultar as atualizações considerando um intervalo de datas, facilitando a visualização das alterações disponibilizadas no período informado.

RN09 — Atualizações sem divulgação: alterações internas, técnicas ou operacionais que não tenham sido selecionadas não deverão ser exibidas na consulta dos clientes.

RN10 — Consulta de versões anteriores: as atualizações anteriormente disponibilizadas deverão permanecer acessíveis no histórico, conforme os critérios de consulta definidos para a funcionalidade.

RN11 — Disponibilização condicionada à publicação: as informações de uma versão somente deverão ficar disponíveis para consulta dos clientes após a efetiva disponibilização da respectiva versão.

RN12 — Manutenção das informações: deverá ser possível registrar as descrições destinadas à divulgação durante a preparação da versão, sem exigir a alteração do conteúdo técnico original do changelog.

Fluxograma

Disponibilizar versao.png

Fluxo resumido da solução

1. A equipe responsável prepara uma nova versão do GeoSales e consulta o changelog técnico.

2. As alterações são avaliadas individualmente, identificando aquelas que são relevantes para os clientes.

3. As atualizações selecionadas recebem descrições em linguagem simples e são marcadas para divulgação.

4. As alterações não selecionadas permanecem fora da consulta destinada aos clientes.

5. Após a aprovação e a publicação da versão, as atualizações selecionadas ficam disponíveis no sistema.

6. O cliente acessa a área de consulta, aplica o filtro por período, se desejar, e visualiza as versões e respectivas atualizações publicadas.

Regra principal: nenhuma atualização deverá ser apresentada automaticamente ao cliente apenas por constar no changelog técnico. A divulgação depende da seleção prévia e da publicação da versão correspondente.

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