GeoSales - Contribuições do(a) usuário(a) [pt-br]

Caso de Uso – Pagamento Online no B2B EVO para Veterinários

2026-10-30T19:32:31Z

Renatolima: /* Regras de Integração */

== Histórico de Alterações ==
{| class="wikitable"
! Data
! Quem
! Comentários
|-
| 28/10/2026 || Renato Lima || Criação do documento
|-
|}

== Necessidade ==
A VIRBAC necessita disponibilizar uma experiência de compra digital por meio de uma plataforma B2V (Business-to-Vet), permitindo que o médico veterinário, após realizar seu cadastro, validação e login, possa consultar o catálogo autorizado, visualizar os preços conforme sua classificação comercial, realizar pedidos, efetuar pagamentos e acompanhar o status de faturamento e entrega.

Para o processo de pagamento, o B2B EVO deverá integrar-se à API da Lyra, permitindo o processamento das transações financeiras e a utilização dos meios de pagamento disponibilizados pelo parceiro.

Para pagamentos com cartão de crédito, deverá ser implementada a tokenização, permitindo a reutilização do cartão em compras futuras sem que os dados sensíveis sejam armazenados pelo B2B EVO.

O processo também deverá contemplar Antifraude, com análise das transações antes da autorização definitiva do pagamento.

Além do pagamento, deverá existir controle da jornada financeira da transação, incluindo pagamentos pendentes, novas tentativas, histórico, cancelamentos, reembolsos, aprovações e respectivos status.

O fluxo deverá ainda contemplar o acompanhamento da entrega, utilizando as informações disponibilizadas pela API da AGV, considerando a relação CEP × prazo de entrega definida pela contratante.

== Solução ==
Será desenvolvido no B2B EVO o fluxo integrado de compra e pagamento para veterinários, utilizando a API da Lyra para processamento das transações financeiras e Antifraude.

O fluxo será iniciado após a seleção dos produtos e confirmação do endereço de entrega. O sistema deverá utilizar o CEP do endereço para disponibilizar as informações relacionadas ao prazo de entrega.

Após a definição da forma de pagamento, o sistema encaminhará a transação para o fluxo correspondente:

'''- Cartão de crédito:''' verificar existência de token previamente armazenado;

'''- Novo cartão:''' realizar o processo de tokenização através da Lyra e armazenar somente o token;

'''- PIX:''' encaminhar os dados necessários para processamento da transação;

'''- Antifraude:''' submeter a transação à análise antes da autorização definitiva;

'''- Pagamento aprovado:''' registrar a transação, atualizar o pedido e prosseguir com o envio ao ERP;

'''- Pagamento recusado ou pendente:''' registrar a ocorrência e disponibilizar nova tentativa de pagamento.

A solução também contemplará o controle de cancelamentos e reembolsos diretamente no B2B EVO. As solicitações de reembolso deverão registrar o motivo e passar pela aprovação dos responsáveis do Financeiro e/ou Comercial, antes do envio da solicitação de estorno à Lyra.

O acompanhamento da entrega será realizado por meio de tela específica no B2B EVO, utilizando as informações retornadas pela integração com a API da AGV, parceira logística da VIRBAC.

== Implementação ==
A implementação será composta pelos seguintes componentes:

'''Fluxo de compra'''

- Acesso do veterinário ao Portal B2B;

- Seleção dos produtos;

- Confirmação do endereço de entrega;

- Identificação do CEP;

- Consulta das informações de prazo de entrega;

- Confirmação do pedido;

- Seleção da forma de pagamento.

'''Pagamento'''

- Integração B2B EVO × API Lyra;

- Processamento de cartão de crédito;

- Processamento de PIX;

- Tokenização de cartão;

- Armazenamento do token;

- Reutilização do cartão tokenizado;

- Registro das transações;

- Tratamento de pagamentos aprovados, recusados e pendentes.

'''Antifraude'''

- Envio da transação para análise;

- Recebimento do resultado da análise;

- Tratamento de transação aprovada;

- Tratamento de transação recusada;

- Tratamento de transação direcionada para análise adicional;

- Registro do resultado da análise.

O documento define que o resultado do Antifraude poderá determinar a aprovação, recusa ou encaminhamento da transação para análise adicional, conforme as regras do parceiro.

'''Controle financeiro'''

Será criada estrutura específica para gerenciamento das transações, contemplando:

- Pagamentos;

- Análises antifraude;

- Pagamentos pendentes;

- Novas tentativas;

- Cancelamentos;

- Reembolsos;

- Histórico das movimentações;

- Status das transações.

'''Cancelamento e reembolso'''

O B2B EVO será responsável por centralizar o controle do processo de cancelamento.

Para pedidos que necessitem de reembolso:

1. Solicitação de reembolso;

2. Registro do motivo;

3. Análise pelo Financeiro e/ou Comercial;

4. Aprovação ou reprovação;

5. Envio da solicitação de estorno à Lyra;
6. Recebimento da confirmação;

7. Atualização do histórico;

8. Atualização dos sistemas envolvidos.

A definição e validação das políticas de cancelamento de pagamento e das políticas de cancelamento/devolução da entrega são de responsabilidade da contratante.

'''Entrega e logística'''

Será desenvolvida uma tela para acompanhamento do status da entrega.

As informações serão obtidas através da integração com a API da AGV, permitindo que o B2B EVO apresente as fases de andamento da entrega ao veterinário.

== Atores ==
{| class="wikitable"
! Ator
! Responsabilidade
|-
| '''Veterinário''' || Realizar cadastro, acessar o B2B EVO, selecionar produtos, realizar pedidos, efetuar pagamentos e acompanhar a entrega.
|-
| '''B2B EVO''' || Centralizar o fluxo de compra, pagamento, cancelamento, reembolso e acompanhamento da entrega.
|-
| '''Lyra''' || Processar pagamentos, tokenização e Antifraude por meio de suas APIs.
|-
| '''Financeiro''' || Analisar e aprovar/reprovar solicitações de reembolso quando aplicável.
|-
| '''Comercial''' || Analisar e aprovar/reprovar solicitações de reembolso quando aplicável.
|-
| '''ERP VIRBAC''' || Receber e atualizar as informações relacionadas aos pedidos.
|-
| '''AGV''' || Disponibilizar informações relacionadas ao andamento da entrega por meio de API.
|-
|}

== Pré-condições ==
- O veterinário deve estar cadastrado e validado.

- O veterinário deve possuir acesso ao B2B EVO.

- O catálogo autorizado deve estar disponível.

- Os preços aplicáveis à classificação comercial do veterinário devem estar configurados.

- O endereço de entrega deve estar cadastrado.

- O CEP do endereço deve estar disponível para utilização no fluxo logístico.

- A integração com a API da Lyra deve estar disponível.

- A integração com o serviço de Antifraude deve estar disponível.

- A integração com a API da AGV deve estar disponível para acompanhamento da entrega.

- As regras de cancelamento e reembolso devem estar definidas e validadas pela VIRBAC.

== Escopo ==
=== Escopo incluso ===
- Integração com a API da Lyra;

- Integração com Antifraude;

- Tokenização de cartões;

- Reutilização de cartões tokenizados;

- Pagamento via meios disponibilizados pela Lyra;

- Controle de pagamentos pendentes;

- Nova tentativa de pagamento;

- Histórico das transações;

- Controle de cancelamento;

- Solicitação e aprovação de reembolso;

- Solicitação de estorno;

- Atualização dos status;

- Integração com ERP VIRBAC;

- Integração com API da AGV;

- Tela de acompanhamento da entrega;

- Controle da relação CEP × prazo de entrega.

O documento contratado também prevê estrutura de banco e telas administrativas para acompanhamento das transações financeiras e seus respectivos retornos.

=== Escopo Não incluso ===
Com base no documento fornecido, não devem ser considerados neste caso de uso:

- Definição das políticas de cancelamento pela CONTRATADA;

- Definição das políticas de devolução da entrega pela CONTRATADA;

- Desenvolvimento de um novo Gateway de Pagamento;

- Armazenamento dos dados sensíveis dos cartões;

- Criação de serviço próprio de Antifraude;

- Cálculo de valor de frete por CEP.

'''Ponto de atenção:''' o fluxograma enviado contém a etapa “Calcular opções e valor do frete”, porém o documento contratual da VIRBAC estabelece expressamente que, neste escopo, o frete será tratado como CEP × prazo de entrega, sem relação de CEP com valor de frete. Portanto, eu recomendaria alterar essa caixa do fluxograma para “Consultar prazo de entrega conforme CEP” para manter o diagrama coerente com o documento contratado.

== Documentos Relacionados ==

[https://docs.cyclopay.com/reference/authentication Documentação Lyra -Ciclopay Link]

== Regras de Negócios ==

'''[RN1] - Cadastro do veterinário'''

O veterinário deverá estar previamente cadastrado, validado e autenticado para realizar pedidos.

'''[RN2] - Catálogo'''

O veterinário poderá consultar somente o catálogo autorizado para seu perfil.

'''[RN3] - Preço'''

Os preços apresentados deverão considerar a classificação comercial do veterinário.

'''[RN4] - Tokenização'''

Nos pagamentos com cartão, o B2B EVO deverá armazenar somente o token retornado pela Lyra, não persistindo os dados sensíveis do cartão.

'''[RN5] - Reutilização do cartão'''

Quando houver token previamente armazenado, o veterinário poderá reutilizar o cartão sem necessidade de informar novamente seus dados.

'''[RN6] - Antifraude'''

A transação deverá passar pelo processo de análise antifraude antes da autorização definitiva do pagamento.

'''[RN7] - Pagamento recusado'''

Quando o pagamento for recusado, a transação deverá ser registrada e o veterinário poderá realizar uma nova tentativa sem recriar o pedido.

'''[RN8] - Pagamento pendente'''

Pedidos com pagamento pendente deverão permanecer identificados no sistema até que ocorra uma nova tentativa ou atualização do status.

'''[RN9] - Cancelamento'''

O controle do cancelamento deverá ser centralizado no B2B EVO.

'''[RN10] - Reembolso'''

A solicitação de reembolso deverá registrar o motivo e ser submetida à aprovação dos responsáveis definidos pela VIRBAC.

'''[RN11] - Estorno'''

Somente após a aprovação deverá ser enviada a solicitação de estorno à Lyra.

'''[RN12] - Política de cancelamento'''

As regras e políticas de cancelamento do pagamento e de cancelamento/devolução da entrega serão definidas e validadas pela VIRBAC.

'''[RN13] - Frete/Prazo'''

O fluxo logístico deverá considerar a relação CEP × prazo de entrega, não sendo utilizada, neste escopo, uma relação de CEP com valor de frete.

'''[RN14] - Acompanhamento da entrega'''

As informações de andamento da entrega serão obtidas por meio da API da AGV.

'''[RN15] - Atualização de status'''

Os status deverão ser atualizados conforme os retornos do Antifraude, Gateway de Pagamentos e ERP. Virbac 8-10 (1)

== Regras de Integração ==

'''[RI1] - B2B EVO × Lyra'''

A integração deverá contemplar:

- Envio da solicitação de pagamento;

- Dados necessários para processamento;

- Tokenização;

- Consulta/retorno da transação;

- Retorno do Antifraude;

- Status do pagamento;

- Solicitação de estorno;

- Confirmação do estorno.

'''[RI2] - B2B EVO × ERP VIRBAC'''

Deverá contemplar:

- Envio do pedido após confirmação do pagamento;

- Atualização de status;

- Comunicação de cancelamentos;

- Atualizações relacionadas ao ciclo de vida do pedido.

'''[RI3] - B2B EVO × AGV'''

A integração deverá disponibilizar as informações necessárias para acompanhamento do andamento da entrega, conforme os dados fornecidos pela API da AGV.

== Fluxograma ==

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

{| class="wikitable"
! Setor
! Aprovado Por
! Data

|-
| Desenvolvimento - GeoSales || Pessoa que aprovou || 00/00/0000
|-
| Integração - GeoSales || Pessoa que aprovou || 00/00/0000
|-
| Configurações - GeoSales || Pessoa que aprovou || 00/00/0000
|-
|}

=== Empresa solicitante ===

{| class="wikitable"
! 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 ||
|-
|}

Caso de Uso – Pagamento Online no B2B EVO para Veterinários

2026-10-30T19:21:16Z

Renatolima: /* Documentos Relacionados */

== Histórico de Alterações ==
{| class="wikitable"
! Data
! Quem
! Comentários
|-
| 28/10/2026 || Renato Lima || Criação do documento
|-
|}

== Necessidade ==
A VIRBAC necessita disponibilizar uma experiência de compra digital por meio de uma plataforma B2V (Business-to-Vet), permitindo que o médico veterinário, após realizar seu cadastro, validação e login, possa consultar o catálogo autorizado, visualizar os preços conforme sua classificação comercial, realizar pedidos, efetuar pagamentos e acompanhar o status de faturamento e entrega.

Para o processo de pagamento, o B2B EVO deverá integrar-se à API da Lyra, permitindo o processamento das transações financeiras e a utilização dos meios de pagamento disponibilizados pelo parceiro.

Para pagamentos com cartão de crédito, deverá ser implementada a tokenização, permitindo a reutilização do cartão em compras futuras sem que os dados sensíveis sejam armazenados pelo B2B EVO.

O processo também deverá contemplar Antifraude, com análise das transações antes da autorização definitiva do pagamento.

Além do pagamento, deverá existir controle da jornada financeira da transação, incluindo pagamentos pendentes, novas tentativas, histórico, cancelamentos, reembolsos, aprovações e respectivos status.

O fluxo deverá ainda contemplar o acompanhamento da entrega, utilizando as informações disponibilizadas pela API da AGV, considerando a relação CEP × prazo de entrega definida pela contratante.

== Solução ==
Será desenvolvido no B2B EVO o fluxo integrado de compra e pagamento para veterinários, utilizando a API da Lyra para processamento das transações financeiras e Antifraude.

O fluxo será iniciado após a seleção dos produtos e confirmação do endereço de entrega. O sistema deverá utilizar o CEP do endereço para disponibilizar as informações relacionadas ao prazo de entrega.

Após a definição da forma de pagamento, o sistema encaminhará a transação para o fluxo correspondente:

'''- Cartão de crédito:''' verificar existência de token previamente armazenado;

'''- Novo cartão:''' realizar o processo de tokenização através da Lyra e armazenar somente o token;

'''- PIX:''' encaminhar os dados necessários para processamento da transação;

'''- Antifraude:''' submeter a transação à análise antes da autorização definitiva;

'''- Pagamento aprovado:''' registrar a transação, atualizar o pedido e prosseguir com o envio ao ERP;

'''- Pagamento recusado ou pendente:''' registrar a ocorrência e disponibilizar nova tentativa de pagamento.

A solução também contemplará o controle de cancelamentos e reembolsos diretamente no B2B EVO. As solicitações de reembolso deverão registrar o motivo e passar pela aprovação dos responsáveis do Financeiro e/ou Comercial, antes do envio da solicitação de estorno à Lyra.

O acompanhamento da entrega será realizado por meio de tela específica no B2B EVO, utilizando as informações retornadas pela integração com a API da AGV, parceira logística da VIRBAC.

== Implementação ==
A implementação será composta pelos seguintes componentes:

'''Fluxo de compra'''

- Acesso do veterinário ao Portal B2B;

- Seleção dos produtos;

- Confirmação do endereço de entrega;

- Identificação do CEP;

- Consulta das informações de prazo de entrega;

- Confirmação do pedido;

- Seleção da forma de pagamento.

'''Pagamento'''

- Integração B2B EVO × API Lyra;

- Processamento de cartão de crédito;

- Processamento de PIX;

- Tokenização de cartão;

- Armazenamento do token;

- Reutilização do cartão tokenizado;

- Registro das transações;

- Tratamento de pagamentos aprovados, recusados e pendentes.

'''Antifraude'''

- Envio da transação para análise;

- Recebimento do resultado da análise;

- Tratamento de transação aprovada;

- Tratamento de transação recusada;

- Tratamento de transação direcionada para análise adicional;

- Registro do resultado da análise.

O documento define que o resultado do Antifraude poderá determinar a aprovação, recusa ou encaminhamento da transação para análise adicional, conforme as regras do parceiro.

'''Controle financeiro'''

Será criada estrutura específica para gerenciamento das transações, contemplando:

- Pagamentos;

- Análises antifraude;

- Pagamentos pendentes;

- Novas tentativas;

- Cancelamentos;

- Reembolsos;

- Histórico das movimentações;

- Status das transações.

'''Cancelamento e reembolso'''

O B2B EVO será responsável por centralizar o controle do processo de cancelamento.

Para pedidos que necessitem de reembolso:

1. Solicitação de reembolso;

2. Registro do motivo;

3. Análise pelo Financeiro e/ou Comercial;

4. Aprovação ou reprovação;

5. Envio da solicitação de estorno à Lyra;
6. Recebimento da confirmação;

7. Atualização do histórico;

8. Atualização dos sistemas envolvidos.

A definição e validação das políticas de cancelamento de pagamento e das políticas de cancelamento/devolução da entrega são de responsabilidade da contratante.

'''Entrega e logística'''

Será desenvolvida uma tela para acompanhamento do status da entrega.

As informações serão obtidas através da integração com a API da AGV, permitindo que o B2B EVO apresente as fases de andamento da entrega ao veterinário.

== Atores ==
{| class="wikitable"
! Ator
! Responsabilidade
|-
| '''Veterinário''' || Realizar cadastro, acessar o B2B EVO, selecionar produtos, realizar pedidos, efetuar pagamentos e acompanhar a entrega.
|-
| '''B2B EVO''' || Centralizar o fluxo de compra, pagamento, cancelamento, reembolso e acompanhamento da entrega.
|-
| '''Lyra''' || Processar pagamentos, tokenização e Antifraude por meio de suas APIs.
|-
| '''Financeiro''' || Analisar e aprovar/reprovar solicitações de reembolso quando aplicável.
|-
| '''Comercial''' || Analisar e aprovar/reprovar solicitações de reembolso quando aplicável.
|-
| '''ERP VIRBAC''' || Receber e atualizar as informações relacionadas aos pedidos.
|-
| '''AGV''' || Disponibilizar informações relacionadas ao andamento da entrega por meio de API.
|-
|}

== Pré-condições ==
- O veterinário deve estar cadastrado e validado.

- O veterinário deve possuir acesso ao B2B EVO.

- O catálogo autorizado deve estar disponível.

- Os preços aplicáveis à classificação comercial do veterinário devem estar configurados.

- O endereço de entrega deve estar cadastrado.

- O CEP do endereço deve estar disponível para utilização no fluxo logístico.

- A integração com a API da Lyra deve estar disponível.

- A integração com o serviço de Antifraude deve estar disponível.

- A integração com a API da AGV deve estar disponível para acompanhamento da entrega.

- As regras de cancelamento e reembolso devem estar definidas e validadas pela VIRBAC.

== Escopo ==
=== Escopo incluso ===
- Integração com a API da Lyra;

- Integração com Antifraude;

- Tokenização de cartões;

- Reutilização de cartões tokenizados;

- Pagamento via meios disponibilizados pela Lyra;

- Controle de pagamentos pendentes;

- Nova tentativa de pagamento;

- Histórico das transações;

- Controle de cancelamento;

- Solicitação e aprovação de reembolso;

- Solicitação de estorno;

- Atualização dos status;

- Integração com ERP VIRBAC;

- Integração com API da AGV;

- Tela de acompanhamento da entrega;

- Controle da relação CEP × prazo de entrega.

O documento contratado também prevê estrutura de banco e telas administrativas para acompanhamento das transações financeiras e seus respectivos retornos.

=== Escopo Não incluso ===
Com base no documento fornecido, não devem ser considerados neste caso de uso:

- Definição das políticas de cancelamento pela CONTRATADA;

- Definição das políticas de devolução da entrega pela CONTRATADA;

- Desenvolvimento de um novo Gateway de Pagamento;

- Armazenamento dos dados sensíveis dos cartões;

- Criação de serviço próprio de Antifraude;

- Cálculo de valor de frete por CEP.

'''Ponto de atenção:''' o fluxograma enviado contém a etapa “Calcular opções e valor do frete”, porém o documento contratual da VIRBAC estabelece expressamente que, neste escopo, o frete será tratado como CEP × prazo de entrega, sem relação de CEP com valor de frete. Portanto, eu recomendaria alterar essa caixa do fluxograma para “Consultar prazo de entrega conforme CEP” para manter o diagrama coerente com o documento contratado.

== Documentos Relacionados ==

[https://docs.cyclopay.com/reference/authentication Documentação Lyra -Ciclopay Link]

== Regras de Negócios ==

'''[RN1] - Cadastro do veterinário'''

O veterinário deverá estar previamente cadastrado, validado e autenticado para realizar pedidos.

'''[RN2] - Catálogo'''

O veterinário poderá consultar somente o catálogo autorizado para seu perfil.

'''[RN3] - Preço'''

Os preços apresentados deverão considerar a classificação comercial do veterinário.

'''[RN4] - Tokenização'''

Nos pagamentos com cartão, o B2B EVO deverá armazenar somente o token retornado pela Lyra, não persistindo os dados sensíveis do cartão.

'''[RN5] - Reutilização do cartão'''

Quando houver token previamente armazenado, o veterinário poderá reutilizar o cartão sem necessidade de informar novamente seus dados.

'''[RN6] - Antifraude'''

A transação deverá passar pelo processo de análise antifraude antes da autorização definitiva do pagamento.

'''[RN7] - Pagamento recusado'''

Quando o pagamento for recusado, a transação deverá ser registrada e o veterinário poderá realizar uma nova tentativa sem recriar o pedido.

'''[RN8] - Pagamento pendente'''

Pedidos com pagamento pendente deverão permanecer identificados no sistema até que ocorra uma nova tentativa ou atualização do status.

'''[RN9] - Cancelamento'''

O controle do cancelamento deverá ser centralizado no B2B EVO.

'''[RN10] - Reembolso'''

A solicitação de reembolso deverá registrar o motivo e ser submetida à aprovação dos responsáveis definidos pela VIRBAC.

'''[RN11] - Estorno'''

Somente após a aprovação deverá ser enviada a solicitação de estorno à Lyra.

'''[RN12] - Política de cancelamento'''

As regras e políticas de cancelamento do pagamento e de cancelamento/devolução da entrega serão definidas e validadas pela VIRBAC.

'''[RN13] - Frete/Prazo'''

O fluxo logístico deverá considerar a relação CEP × prazo de entrega, não sendo utilizada, neste escopo, uma relação de CEP com valor de frete.

'''[RN14] - Acompanhamento da entrega'''

As informações de andamento da entrega serão obtidas por meio da API da AGV.

'''[RN15] - Atualização de status'''

Os status deverão ser atualizados conforme os retornos do Antifraude, Gateway de Pagamentos e ERP. Virbac 8-10 (1)

== Regras de Integração ==

'''[RI1] - B2B EVO × Lyra'''

A integração deverá contemplar:

- Envio da solicitação de pagamento;

- Dados necessários para processamento;

- Tokenização;

- Consulta/retorno da transação;

- Retorno do Antifraude;

- Status do pagamento;

- Solicitação de estorno;

- Confirmação do estorno.

'''[RI2] - B2B EVO × ERP VIRBAC'''

Deverá contemplar:

- Envio do pedido após confirmação do pagamento;

- Atualização de status;

- Comunicação de cancelamentos;

- Atualizações relacionadas ao ciclo de vida do pedido.

'''[RI3] - B2B EVO × AGV'''

A integração deverá disponibilizar as informações necessárias para acompanhamento do andamento da entrega, conforme os dados fornecidos pela API da AGV.

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

{| class="wikitable"
! Setor
! Aprovado Por
! Data

|-
| Desenvolvimento - GeoSales || Pessoa que aprovou || 00/00/0000
|-
| Integração - GeoSales || Pessoa que aprovou || 00/00/0000
|-
| Configurações - GeoSales || Pessoa que aprovou || 00/00/0000
|-
|}

=== Empresa solicitante ===

{| class="wikitable"
! 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 ||
|-
|}

Caso de Uso – Pagamento Online no B2B EVO para Veterinários

2026-10-30T19:21:03Z

Renatolima: /* Documentos Relacionados */

== Histórico de Alterações ==
{| class="wikitable"
! Data
! Quem
! Comentários
|-
| 28/10/2026 || Renato Lima || Criação do documento
|-
|}

== Necessidade ==
A VIRBAC necessita disponibilizar uma experiência de compra digital por meio de uma plataforma B2V (Business-to-Vet), permitindo que o médico veterinário, após realizar seu cadastro, validação e login, possa consultar o catálogo autorizado, visualizar os preços conforme sua classificação comercial, realizar pedidos, efetuar pagamentos e acompanhar o status de faturamento e entrega.

Para o processo de pagamento, o B2B EVO deverá integrar-se à API da Lyra, permitindo o processamento das transações financeiras e a utilização dos meios de pagamento disponibilizados pelo parceiro.

Para pagamentos com cartão de crédito, deverá ser implementada a tokenização, permitindo a reutilização do cartão em compras futuras sem que os dados sensíveis sejam armazenados pelo B2B EVO.

O processo também deverá contemplar Antifraude, com análise das transações antes da autorização definitiva do pagamento.

Além do pagamento, deverá existir controle da jornada financeira da transação, incluindo pagamentos pendentes, novas tentativas, histórico, cancelamentos, reembolsos, aprovações e respectivos status.

O fluxo deverá ainda contemplar o acompanhamento da entrega, utilizando as informações disponibilizadas pela API da AGV, considerando a relação CEP × prazo de entrega definida pela contratante.

== Solução ==
Será desenvolvido no B2B EVO o fluxo integrado de compra e pagamento para veterinários, utilizando a API da Lyra para processamento das transações financeiras e Antifraude.

O fluxo será iniciado após a seleção dos produtos e confirmação do endereço de entrega. O sistema deverá utilizar o CEP do endereço para disponibilizar as informações relacionadas ao prazo de entrega.

Após a definição da forma de pagamento, o sistema encaminhará a transação para o fluxo correspondente:

'''- Cartão de crédito:''' verificar existência de token previamente armazenado;

'''- Novo cartão:''' realizar o processo de tokenização através da Lyra e armazenar somente o token;

'''- PIX:''' encaminhar os dados necessários para processamento da transação;

'''- Antifraude:''' submeter a transação à análise antes da autorização definitiva;

'''- Pagamento aprovado:''' registrar a transação, atualizar o pedido e prosseguir com o envio ao ERP;

'''- Pagamento recusado ou pendente:''' registrar a ocorrência e disponibilizar nova tentativa de pagamento.

A solução também contemplará o controle de cancelamentos e reembolsos diretamente no B2B EVO. As solicitações de reembolso deverão registrar o motivo e passar pela aprovação dos responsáveis do Financeiro e/ou Comercial, antes do envio da solicitação de estorno à Lyra.

O acompanhamento da entrega será realizado por meio de tela específica no B2B EVO, utilizando as informações retornadas pela integração com a API da AGV, parceira logística da VIRBAC.

== Implementação ==
A implementação será composta pelos seguintes componentes:

'''Fluxo de compra'''

- Acesso do veterinário ao Portal B2B;

- Seleção dos produtos;

- Confirmação do endereço de entrega;

- Identificação do CEP;

- Consulta das informações de prazo de entrega;

- Confirmação do pedido;

- Seleção da forma de pagamento.

'''Pagamento'''

- Integração B2B EVO × API Lyra;

- Processamento de cartão de crédito;

- Processamento de PIX;

- Tokenização de cartão;

- Armazenamento do token;

- Reutilização do cartão tokenizado;

- Registro das transações;

- Tratamento de pagamentos aprovados, recusados e pendentes.

'''Antifraude'''

- Envio da transação para análise;

- Recebimento do resultado da análise;

- Tratamento de transação aprovada;

- Tratamento de transação recusada;

- Tratamento de transação direcionada para análise adicional;

- Registro do resultado da análise.

O documento define que o resultado do Antifraude poderá determinar a aprovação, recusa ou encaminhamento da transação para análise adicional, conforme as regras do parceiro.

'''Controle financeiro'''

Será criada estrutura específica para gerenciamento das transações, contemplando:

- Pagamentos;

- Análises antifraude;

- Pagamentos pendentes;

- Novas tentativas;

- Cancelamentos;

- Reembolsos;

- Histórico das movimentações;

- Status das transações.

'''Cancelamento e reembolso'''

O B2B EVO será responsável por centralizar o controle do processo de cancelamento.

Para pedidos que necessitem de reembolso:

1. Solicitação de reembolso;

2. Registro do motivo;

3. Análise pelo Financeiro e/ou Comercial;

4. Aprovação ou reprovação;

5. Envio da solicitação de estorno à Lyra;
6. Recebimento da confirmação;

7. Atualização do histórico;

8. Atualização dos sistemas envolvidos.

A definição e validação das políticas de cancelamento de pagamento e das políticas de cancelamento/devolução da entrega são de responsabilidade da contratante.

'''Entrega e logística'''

Será desenvolvida uma tela para acompanhamento do status da entrega.

As informações serão obtidas através da integração com a API da AGV, permitindo que o B2B EVO apresente as fases de andamento da entrega ao veterinário.

== Atores ==
{| class="wikitable"
! Ator
! Responsabilidade
|-
| '''Veterinário''' || Realizar cadastro, acessar o B2B EVO, selecionar produtos, realizar pedidos, efetuar pagamentos e acompanhar a entrega.
|-
| '''B2B EVO''' || Centralizar o fluxo de compra, pagamento, cancelamento, reembolso e acompanhamento da entrega.
|-
| '''Lyra''' || Processar pagamentos, tokenização e Antifraude por meio de suas APIs.
|-
| '''Financeiro''' || Analisar e aprovar/reprovar solicitações de reembolso quando aplicável.
|-
| '''Comercial''' || Analisar e aprovar/reprovar solicitações de reembolso quando aplicável.
|-
| '''ERP VIRBAC''' || Receber e atualizar as informações relacionadas aos pedidos.
|-
| '''AGV''' || Disponibilizar informações relacionadas ao andamento da entrega por meio de API.
|-
|}

== Pré-condições ==
- O veterinário deve estar cadastrado e validado.

- O veterinário deve possuir acesso ao B2B EVO.

- O catálogo autorizado deve estar disponível.

- Os preços aplicáveis à classificação comercial do veterinário devem estar configurados.

- O endereço de entrega deve estar cadastrado.

- O CEP do endereço deve estar disponível para utilização no fluxo logístico.

- A integração com a API da Lyra deve estar disponível.

- A integração com o serviço de Antifraude deve estar disponível.

- A integração com a API da AGV deve estar disponível para acompanhamento da entrega.

- As regras de cancelamento e reembolso devem estar definidas e validadas pela VIRBAC.

== Escopo ==
=== Escopo incluso ===
- Integração com a API da Lyra;

- Integração com Antifraude;

- Tokenização de cartões;

- Reutilização de cartões tokenizados;

- Pagamento via meios disponibilizados pela Lyra;

- Controle de pagamentos pendentes;

- Nova tentativa de pagamento;

- Histórico das transações;

- Controle de cancelamento;

- Solicitação e aprovação de reembolso;

- Solicitação de estorno;

- Atualização dos status;

- Integração com ERP VIRBAC;

- Integração com API da AGV;

- Tela de acompanhamento da entrega;

- Controle da relação CEP × prazo de entrega.

O documento contratado também prevê estrutura de banco e telas administrativas para acompanhamento das transações financeiras e seus respectivos retornos.

=== Escopo Não incluso ===
Com base no documento fornecido, não devem ser considerados neste caso de uso:

- Definição das políticas de cancelamento pela CONTRATADA;

- Definição das políticas de devolução da entrega pela CONTRATADA;

- Desenvolvimento de um novo Gateway de Pagamento;

- Armazenamento dos dados sensíveis dos cartões;

- Criação de serviço próprio de Antifraude;

- Cálculo de valor de frete por CEP.

'''Ponto de atenção:''' o fluxograma enviado contém a etapa “Calcular opções e valor do frete”, porém o documento contratual da VIRBAC estabelece expressamente que, neste escopo, o frete será tratado como CEP × prazo de entrega, sem relação de CEP com valor de frete. Portanto, eu recomendaria alterar essa caixa do fluxograma para “Consultar prazo de entrega conforme CEP” para manter o diagrama coerente com o documento contratado.

== Documentos Relacionados ==

[https://docs.cyclopay.com/reference/authentication Documentação Lyra -Ciclopay Link]

https://docs.cyclopay.com/reference/authentication

== Regras de Negócios ==

'''[RN1] - Cadastro do veterinário'''

O veterinário deverá estar previamente cadastrado, validado e autenticado para realizar pedidos.

'''[RN2] - Catálogo'''

O veterinário poderá consultar somente o catálogo autorizado para seu perfil.

'''[RN3] - Preço'''

Os preços apresentados deverão considerar a classificação comercial do veterinário.

'''[RN4] - Tokenização'''

Nos pagamentos com cartão, o B2B EVO deverá armazenar somente o token retornado pela Lyra, não persistindo os dados sensíveis do cartão.

'''[RN5] - Reutilização do cartão'''

Quando houver token previamente armazenado, o veterinário poderá reutilizar o cartão sem necessidade de informar novamente seus dados.

'''[RN6] - Antifraude'''

A transação deverá passar pelo processo de análise antifraude antes da autorização definitiva do pagamento.

'''[RN7] - Pagamento recusado'''

Quando o pagamento for recusado, a transação deverá ser registrada e o veterinário poderá realizar uma nova tentativa sem recriar o pedido.

'''[RN8] - Pagamento pendente'''

Pedidos com pagamento pendente deverão permanecer identificados no sistema até que ocorra uma nova tentativa ou atualização do status.

'''[RN9] - Cancelamento'''

O controle do cancelamento deverá ser centralizado no B2B EVO.

'''[RN10] - Reembolso'''

A solicitação de reembolso deverá registrar o motivo e ser submetida à aprovação dos responsáveis definidos pela VIRBAC.

'''[RN11] - Estorno'''

Somente após a aprovação deverá ser enviada a solicitação de estorno à Lyra.

'''[RN12] - Política de cancelamento'''

As regras e políticas de cancelamento do pagamento e de cancelamento/devolução da entrega serão definidas e validadas pela VIRBAC.

'''[RN13] - Frete/Prazo'''

O fluxo logístico deverá considerar a relação CEP × prazo de entrega, não sendo utilizada, neste escopo, uma relação de CEP com valor de frete.

'''[RN14] - Acompanhamento da entrega'''

As informações de andamento da entrega serão obtidas por meio da API da AGV.

'''[RN15] - Atualização de status'''

Os status deverão ser atualizados conforme os retornos do Antifraude, Gateway de Pagamentos e ERP. Virbac 8-10 (1)

== Regras de Integração ==

'''[RI1] - B2B EVO × Lyra'''

A integração deverá contemplar:

- Envio da solicitação de pagamento;

- Dados necessários para processamento;

- Tokenização;

- Consulta/retorno da transação;

- Retorno do Antifraude;

- Status do pagamento;

- Solicitação de estorno;

- Confirmação do estorno.

'''[RI2] - B2B EVO × ERP VIRBAC'''

Deverá contemplar:

- Envio do pedido após confirmação do pagamento;

- Atualização de status;

- Comunicação de cancelamentos;

- Atualizações relacionadas ao ciclo de vida do pedido.

'''[RI3] - B2B EVO × AGV'''

A integração deverá disponibilizar as informações necessárias para acompanhamento do andamento da entrega, conforme os dados fornecidos pela API da AGV.

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

{| class="wikitable"
! Setor
! Aprovado Por
! Data

|-
| Desenvolvimento - GeoSales || Pessoa que aprovou || 00/00/0000
|-
| Integração - GeoSales || Pessoa que aprovou || 00/00/0000
|-
| Configurações - GeoSales || Pessoa que aprovou || 00/00/0000
|-
|}

=== Empresa solicitante ===

{| class="wikitable"
! 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 ||
|-
|}

Caso de Uso – Pagamento Online no B2B EVO para Veterinários

2026-10-30T19:13:32Z

Renatolima: /* Regras de Integração */

== Histórico de Alterações ==
{| class="wikitable"
! Data
! Quem
! Comentários
|-
| 28/10/2026 || Renato Lima || Criação do documento
|-
|}

== Necessidade ==
A VIRBAC necessita disponibilizar uma experiência de compra digital por meio de uma plataforma B2V (Business-to-Vet), permitindo que o médico veterinário, após realizar seu cadastro, validação e login, possa consultar o catálogo autorizado, visualizar os preços conforme sua classificação comercial, realizar pedidos, efetuar pagamentos e acompanhar o status de faturamento e entrega.

Para o processo de pagamento, o B2B EVO deverá integrar-se à API da Lyra, permitindo o processamento das transações financeiras e a utilização dos meios de pagamento disponibilizados pelo parceiro.

Para pagamentos com cartão de crédito, deverá ser implementada a tokenização, permitindo a reutilização do cartão em compras futuras sem que os dados sensíveis sejam armazenados pelo B2B EVO.

O processo também deverá contemplar Antifraude, com análise das transações antes da autorização definitiva do pagamento.

Além do pagamento, deverá existir controle da jornada financeira da transação, incluindo pagamentos pendentes, novas tentativas, histórico, cancelamentos, reembolsos, aprovações e respectivos status.

O fluxo deverá ainda contemplar o acompanhamento da entrega, utilizando as informações disponibilizadas pela API da AGV, considerando a relação CEP × prazo de entrega definida pela contratante.

== Solução ==
Será desenvolvido no B2B EVO o fluxo integrado de compra e pagamento para veterinários, utilizando a API da Lyra para processamento das transações financeiras e Antifraude.

O fluxo será iniciado após a seleção dos produtos e confirmação do endereço de entrega. O sistema deverá utilizar o CEP do endereço para disponibilizar as informações relacionadas ao prazo de entrega.

Após a definição da forma de pagamento, o sistema encaminhará a transação para o fluxo correspondente:

'''- Cartão de crédito:''' verificar existência de token previamente armazenado;

'''- Novo cartão:''' realizar o processo de tokenização através da Lyra e armazenar somente o token;

'''- PIX:''' encaminhar os dados necessários para processamento da transação;

'''- Antifraude:''' submeter a transação à análise antes da autorização definitiva;

'''- Pagamento aprovado:''' registrar a transação, atualizar o pedido e prosseguir com o envio ao ERP;

'''- Pagamento recusado ou pendente:''' registrar a ocorrência e disponibilizar nova tentativa de pagamento.

A solução também contemplará o controle de cancelamentos e reembolsos diretamente no B2B EVO. As solicitações de reembolso deverão registrar o motivo e passar pela aprovação dos responsáveis do Financeiro e/ou Comercial, antes do envio da solicitação de estorno à Lyra.

O acompanhamento da entrega será realizado por meio de tela específica no B2B EVO, utilizando as informações retornadas pela integração com a API da AGV, parceira logística da VIRBAC.

== Implementação ==
A implementação será composta pelos seguintes componentes:

'''Fluxo de compra'''

- Acesso do veterinário ao Portal B2B;

- Seleção dos produtos;

- Confirmação do endereço de entrega;

- Identificação do CEP;

- Consulta das informações de prazo de entrega;

- Confirmação do pedido;

- Seleção da forma de pagamento.

'''Pagamento'''

- Integração B2B EVO × API Lyra;

- Processamento de cartão de crédito;

- Processamento de PIX;

- Tokenização de cartão;

- Armazenamento do token;

- Reutilização do cartão tokenizado;

- Registro das transações;

- Tratamento de pagamentos aprovados, recusados e pendentes.

'''Antifraude'''

- Envio da transação para análise;

- Recebimento do resultado da análise;

- Tratamento de transação aprovada;

- Tratamento de transação recusada;

- Tratamento de transação direcionada para análise adicional;

- Registro do resultado da análise.

O documento define que o resultado do Antifraude poderá determinar a aprovação, recusa ou encaminhamento da transação para análise adicional, conforme as regras do parceiro.

'''Controle financeiro'''

Será criada estrutura específica para gerenciamento das transações, contemplando:

- Pagamentos;

- Análises antifraude;

- Pagamentos pendentes;

- Novas tentativas;

- Cancelamentos;

- Reembolsos;

- Histórico das movimentações;

- Status das transações.

'''Cancelamento e reembolso'''

O B2B EVO será responsável por centralizar o controle do processo de cancelamento.

Para pedidos que necessitem de reembolso:

1. Solicitação de reembolso;

2. Registro do motivo;

3. Análise pelo Financeiro e/ou Comercial;

4. Aprovação ou reprovação;

5. Envio da solicitação de estorno à Lyra;
6. Recebimento da confirmação;

7. Atualização do histórico;

8. Atualização dos sistemas envolvidos.

A definição e validação das políticas de cancelamento de pagamento e das políticas de cancelamento/devolução da entrega são de responsabilidade da contratante.

'''Entrega e logística'''

Será desenvolvida uma tela para acompanhamento do status da entrega.

As informações serão obtidas através da integração com a API da AGV, permitindo que o B2B EVO apresente as fases de andamento da entrega ao veterinário.

== Atores ==
{| class="wikitable"
! Ator
! Responsabilidade
|-
| '''Veterinário''' || Realizar cadastro, acessar o B2B EVO, selecionar produtos, realizar pedidos, efetuar pagamentos e acompanhar a entrega.
|-
| '''B2B EVO''' || Centralizar o fluxo de compra, pagamento, cancelamento, reembolso e acompanhamento da entrega.
|-
| '''Lyra''' || Processar pagamentos, tokenização e Antifraude por meio de suas APIs.
|-
| '''Financeiro''' || Analisar e aprovar/reprovar solicitações de reembolso quando aplicável.
|-
| '''Comercial''' || Analisar e aprovar/reprovar solicitações de reembolso quando aplicável.
|-
| '''ERP VIRBAC''' || Receber e atualizar as informações relacionadas aos pedidos.
|-
| '''AGV''' || Disponibilizar informações relacionadas ao andamento da entrega por meio de API.
|-
|}

== Pré-condições ==
- O veterinário deve estar cadastrado e validado.

- O veterinário deve possuir acesso ao B2B EVO.

- O catálogo autorizado deve estar disponível.

- Os preços aplicáveis à classificação comercial do veterinário devem estar configurados.

- O endereço de entrega deve estar cadastrado.

- O CEP do endereço deve estar disponível para utilização no fluxo logístico.

- A integração com a API da Lyra deve estar disponível.

- A integração com o serviço de Antifraude deve estar disponível.

- A integração com a API da AGV deve estar disponível para acompanhamento da entrega.

- As regras de cancelamento e reembolso devem estar definidas e validadas pela VIRBAC.

== Escopo ==
=== Escopo incluso ===
- Integração com a API da Lyra;

- Integração com Antifraude;

- Tokenização de cartões;

- Reutilização de cartões tokenizados;

- Pagamento via meios disponibilizados pela Lyra;

- Controle de pagamentos pendentes;

- Nova tentativa de pagamento;

- Histórico das transações;

- Controle de cancelamento;

- Solicitação e aprovação de reembolso;

- Solicitação de estorno;

- Atualização dos status;

- Integração com ERP VIRBAC;

- Integração com API da AGV;

- Tela de acompanhamento da entrega;

- Controle da relação CEP × prazo de entrega.

O documento contratado também prevê estrutura de banco e telas administrativas para acompanhamento das transações financeiras e seus respectivos retornos.

=== Escopo Não incluso ===
Com base no documento fornecido, não devem ser considerados neste caso de uso:

- Definição das políticas de cancelamento pela CONTRATADA;

- Definição das políticas de devolução da entrega pela CONTRATADA;

- Desenvolvimento de um novo Gateway de Pagamento;

- Armazenamento dos dados sensíveis dos cartões;

- Criação de serviço próprio de Antifraude;

- Cálculo de valor de frete por CEP.

'''Ponto de atenção:''' o fluxograma enviado contém a etapa “Calcular opções e valor do frete”, porém o documento contratual da VIRBAC estabelece expressamente que, neste escopo, o frete será tratado como CEP × prazo de entrega, sem relação de CEP com valor de frete. Portanto, eu recomendaria alterar essa caixa do fluxograma para “Consultar prazo de entrega conforme CEP” para manter o diagrama coerente com o documento contratado.

== Documentos Relacionados ==

== Regras de Negócios ==

'''[RN1] - Cadastro do veterinário'''

O veterinário deverá estar previamente cadastrado, validado e autenticado para realizar pedidos.

'''[RN2] - Catálogo'''

O veterinário poderá consultar somente o catálogo autorizado para seu perfil.

'''[RN3] - Preço'''

Os preços apresentados deverão considerar a classificação comercial do veterinário.

'''[RN4] - Tokenização'''

Nos pagamentos com cartão, o B2B EVO deverá armazenar somente o token retornado pela Lyra, não persistindo os dados sensíveis do cartão.

'''[RN5] - Reutilização do cartão'''

Quando houver token previamente armazenado, o veterinário poderá reutilizar o cartão sem necessidade de informar novamente seus dados.

'''[RN6] - Antifraude'''

A transação deverá passar pelo processo de análise antifraude antes da autorização definitiva do pagamento.

'''[RN7] - Pagamento recusado'''

Quando o pagamento for recusado, a transação deverá ser registrada e o veterinário poderá realizar uma nova tentativa sem recriar o pedido.

'''[RN8] - Pagamento pendente'''

Pedidos com pagamento pendente deverão permanecer identificados no sistema até que ocorra uma nova tentativa ou atualização do status.

'''[RN9] - Cancelamento'''

O controle do cancelamento deverá ser centralizado no B2B EVO.

'''[RN10] - Reembolso'''

A solicitação de reembolso deverá registrar o motivo e ser submetida à aprovação dos responsáveis definidos pela VIRBAC.

'''[RN11] - Estorno'''

Somente após a aprovação deverá ser enviada a solicitação de estorno à Lyra.

'''[RN12] - Política de cancelamento'''

As regras e políticas de cancelamento do pagamento e de cancelamento/devolução da entrega serão definidas e validadas pela VIRBAC.

'''[RN13] - Frete/Prazo'''

O fluxo logístico deverá considerar a relação CEP × prazo de entrega, não sendo utilizada, neste escopo, uma relação de CEP com valor de frete.

'''[RN14] - Acompanhamento da entrega'''

As informações de andamento da entrega serão obtidas por meio da API da AGV.

'''[RN15] - Atualização de status'''

Os status deverão ser atualizados conforme os retornos do Antifraude, Gateway de Pagamentos e ERP. Virbac 8-10 (1)

== Regras de Integração ==

'''[RI1] - B2B EVO × Lyra'''

A integração deverá contemplar:

- Envio da solicitação de pagamento;

- Dados necessários para processamento;

- Tokenização;

- Consulta/retorno da transação;

- Retorno do Antifraude;

- Status do pagamento;

- Solicitação de estorno;

- Confirmação do estorno.

'''[RI2] - B2B EVO × ERP VIRBAC'''

Deverá contemplar:

- Envio do pedido após confirmação do pagamento;

- Atualização de status;

- Comunicação de cancelamentos;

- Atualizações relacionadas ao ciclo de vida do pedido.

'''[RI3] - B2B EVO × AGV'''

A integração deverá disponibilizar as informações necessárias para acompanhamento do andamento da entrega, conforme os dados fornecidos pela API da AGV.

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

{| class="wikitable"
! Setor
! Aprovado Por
! Data

|-
| Desenvolvimento - GeoSales || Pessoa que aprovou || 00/00/0000
|-
| Integração - GeoSales || Pessoa que aprovou || 00/00/0000
|-
| Configurações - GeoSales || Pessoa que aprovou || 00/00/0000
|-
|}

=== Empresa solicitante ===

{| class="wikitable"
! 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 ||
|-
|}

Caso de Uso – Pagamento Online no B2B EVO para Veterinários

2026-10-30T19:03:30Z

Renatolima: /* Regras de Integração */

== Histórico de Alterações ==
{| class="wikitable"
! Data
! Quem
! Comentários
|-
| 28/10/2026 || Renato Lima || Criação do documento
|-
|}

== Necessidade ==
A VIRBAC necessita disponibilizar uma experiência de compra digital por meio de uma plataforma B2V (Business-to-Vet), permitindo que o médico veterinário, após realizar seu cadastro, validação e login, possa consultar o catálogo autorizado, visualizar os preços conforme sua classificação comercial, realizar pedidos, efetuar pagamentos e acompanhar o status de faturamento e entrega.

Para o processo de pagamento, o B2B EVO deverá integrar-se à API da Lyra, permitindo o processamento das transações financeiras e a utilização dos meios de pagamento disponibilizados pelo parceiro.

Para pagamentos com cartão de crédito, deverá ser implementada a tokenização, permitindo a reutilização do cartão em compras futuras sem que os dados sensíveis sejam armazenados pelo B2B EVO.

O processo também deverá contemplar Antifraude, com análise das transações antes da autorização definitiva do pagamento.

Além do pagamento, deverá existir controle da jornada financeira da transação, incluindo pagamentos pendentes, novas tentativas, histórico, cancelamentos, reembolsos, aprovações e respectivos status.

O fluxo deverá ainda contemplar o acompanhamento da entrega, utilizando as informações disponibilizadas pela API da AGV, considerando a relação CEP × prazo de entrega definida pela contratante.

== Solução ==
Será desenvolvido no B2B EVO o fluxo integrado de compra e pagamento para veterinários, utilizando a API da Lyra para processamento das transações financeiras e Antifraude.

O fluxo será iniciado após a seleção dos produtos e confirmação do endereço de entrega. O sistema deverá utilizar o CEP do endereço para disponibilizar as informações relacionadas ao prazo de entrega.

Após a definição da forma de pagamento, o sistema encaminhará a transação para o fluxo correspondente:

'''- Cartão de crédito:''' verificar existência de token previamente armazenado;

'''- Novo cartão:''' realizar o processo de tokenização através da Lyra e armazenar somente o token;

'''- PIX:''' encaminhar os dados necessários para processamento da transação;

'''- Antifraude:''' submeter a transação à análise antes da autorização definitiva;

'''- Pagamento aprovado:''' registrar a transação, atualizar o pedido e prosseguir com o envio ao ERP;

'''- Pagamento recusado ou pendente:''' registrar a ocorrência e disponibilizar nova tentativa de pagamento.

A solução também contemplará o controle de cancelamentos e reembolsos diretamente no B2B EVO. As solicitações de reembolso deverão registrar o motivo e passar pela aprovação dos responsáveis do Financeiro e/ou Comercial, antes do envio da solicitação de estorno à Lyra.

O acompanhamento da entrega será realizado por meio de tela específica no B2B EVO, utilizando as informações retornadas pela integração com a API da AGV, parceira logística da VIRBAC.

== Implementação ==
A implementação será composta pelos seguintes componentes:

'''Fluxo de compra'''

- Acesso do veterinário ao Portal B2B;

- Seleção dos produtos;

- Confirmação do endereço de entrega;

- Identificação do CEP;

- Consulta das informações de prazo de entrega;

- Confirmação do pedido;

- Seleção da forma de pagamento.

'''Pagamento'''

- Integração B2B EVO × API Lyra;

- Processamento de cartão de crédito;

- Processamento de PIX;

- Tokenização de cartão;

- Armazenamento do token;

- Reutilização do cartão tokenizado;

- Registro das transações;

- Tratamento de pagamentos aprovados, recusados e pendentes.

'''Antifraude'''

- Envio da transação para análise;

- Recebimento do resultado da análise;

- Tratamento de transação aprovada;

- Tratamento de transação recusada;

- Tratamento de transação direcionada para análise adicional;

- Registro do resultado da análise.

O documento define que o resultado do Antifraude poderá determinar a aprovação, recusa ou encaminhamento da transação para análise adicional, conforme as regras do parceiro.

'''Controle financeiro'''

Será criada estrutura específica para gerenciamento das transações, contemplando:

- Pagamentos;

- Análises antifraude;

- Pagamentos pendentes;

- Novas tentativas;

- Cancelamentos;

- Reembolsos;

- Histórico das movimentações;

- Status das transações.

'''Cancelamento e reembolso'''

O B2B EVO será responsável por centralizar o controle do processo de cancelamento.

Para pedidos que necessitem de reembolso:

1. Solicitação de reembolso;

2. Registro do motivo;

3. Análise pelo Financeiro e/ou Comercial;

4. Aprovação ou reprovação;

5. Envio da solicitação de estorno à Lyra;
6. Recebimento da confirmação;

7. Atualização do histórico;

8. Atualização dos sistemas envolvidos.

A definição e validação das políticas de cancelamento de pagamento e das políticas de cancelamento/devolução da entrega são de responsabilidade da contratante.

'''Entrega e logística'''

Será desenvolvida uma tela para acompanhamento do status da entrega.

As informações serão obtidas através da integração com a API da AGV, permitindo que o B2B EVO apresente as fases de andamento da entrega ao veterinário.

== Atores ==
{| class="wikitable"
! Ator
! Responsabilidade
|-
| '''Veterinário''' || Realizar cadastro, acessar o B2B EVO, selecionar produtos, realizar pedidos, efetuar pagamentos e acompanhar a entrega.
|-
| '''B2B EVO''' || Centralizar o fluxo de compra, pagamento, cancelamento, reembolso e acompanhamento da entrega.
|-
| '''Lyra''' || Processar pagamentos, tokenização e Antifraude por meio de suas APIs.
|-
| '''Financeiro''' || Analisar e aprovar/reprovar solicitações de reembolso quando aplicável.
|-
| '''Comercial''' || Analisar e aprovar/reprovar solicitações de reembolso quando aplicável.
|-
| '''ERP VIRBAC''' || Receber e atualizar as informações relacionadas aos pedidos.
|-
| '''AGV''' || Disponibilizar informações relacionadas ao andamento da entrega por meio de API.
|-
|}

== Pré-condições ==
- O veterinário deve estar cadastrado e validado.

- O veterinário deve possuir acesso ao B2B EVO.

- O catálogo autorizado deve estar disponível.

- Os preços aplicáveis à classificação comercial do veterinário devem estar configurados.

- O endereço de entrega deve estar cadastrado.

- O CEP do endereço deve estar disponível para utilização no fluxo logístico.

- A integração com a API da Lyra deve estar disponível.

- A integração com o serviço de Antifraude deve estar disponível.

- A integração com a API da AGV deve estar disponível para acompanhamento da entrega.

- As regras de cancelamento e reembolso devem estar definidas e validadas pela VIRBAC.

== Escopo ==
=== Escopo incluso ===
- Integração com a API da Lyra;

- Integração com Antifraude;

- Tokenização de cartões;

- Reutilização de cartões tokenizados;

- Pagamento via meios disponibilizados pela Lyra;

- Controle de pagamentos pendentes;

- Nova tentativa de pagamento;

- Histórico das transações;

- Controle de cancelamento;

- Solicitação e aprovação de reembolso;

- Solicitação de estorno;

- Atualização dos status;

- Integração com ERP VIRBAC;

- Integração com API da AGV;

- Tela de acompanhamento da entrega;

- Controle da relação CEP × prazo de entrega.

O documento contratado também prevê estrutura de banco e telas administrativas para acompanhamento das transações financeiras e seus respectivos retornos.

=== Escopo Não incluso ===
Com base no documento fornecido, não devem ser considerados neste caso de uso:

- Definição das políticas de cancelamento pela CONTRATADA;

- Definição das políticas de devolução da entrega pela CONTRATADA;

- Desenvolvimento de um novo Gateway de Pagamento;

- Armazenamento dos dados sensíveis dos cartões;

- Criação de serviço próprio de Antifraude;

- Cálculo de valor de frete por CEP.

'''Ponto de atenção:''' o fluxograma enviado contém a etapa “Calcular opções e valor do frete”, porém o documento contratual da VIRBAC estabelece expressamente que, neste escopo, o frete será tratado como CEP × prazo de entrega, sem relação de CEP com valor de frete. Portanto, eu recomendaria alterar essa caixa do fluxograma para “Consultar prazo de entrega conforme CEP” para manter o diagrama coerente com o documento contratado.

== Documentos Relacionados ==

== Regras de Negócios ==

'''[RN1] - Cadastro do veterinário'''

O veterinário deverá estar previamente cadastrado, validado e autenticado para realizar pedidos.

'''[RN2] - Catálogo'''

O veterinário poderá consultar somente o catálogo autorizado para seu perfil.

'''[RN3] - Preço'''

Os preços apresentados deverão considerar a classificação comercial do veterinário.

'''[RN4] - Tokenização'''

Nos pagamentos com cartão, o B2B EVO deverá armazenar somente o token retornado pela Lyra, não persistindo os dados sensíveis do cartão.

'''[RN5] - Reutilização do cartão'''

Quando houver token previamente armazenado, o veterinário poderá reutilizar o cartão sem necessidade de informar novamente seus dados.

'''[RN6] - Antifraude'''

A transação deverá passar pelo processo de análise antifraude antes da autorização definitiva do pagamento.

'''[RN7] - Pagamento recusado'''

Quando o pagamento for recusado, a transação deverá ser registrada e o veterinário poderá realizar uma nova tentativa sem recriar o pedido.

'''[RN8] - Pagamento pendente'''

Pedidos com pagamento pendente deverão permanecer identificados no sistema até que ocorra uma nova tentativa ou atualização do status.

'''[RN9] - Cancelamento'''

O controle do cancelamento deverá ser centralizado no B2B EVO.

'''[RN10] - Reembolso'''

A solicitação de reembolso deverá registrar o motivo e ser submetida à aprovação dos responsáveis definidos pela VIRBAC.

'''[RN11] - Estorno'''

Somente após a aprovação deverá ser enviada a solicitação de estorno à Lyra.

'''[RN12] - Política de cancelamento'''

As regras e políticas de cancelamento do pagamento e de cancelamento/devolução da entrega serão definidas e validadas pela VIRBAC.

'''[RN13] - Frete/Prazo'''

O fluxo logístico deverá considerar a relação CEP × prazo de entrega, não sendo utilizada, neste escopo, uma relação de CEP com valor de frete.

'''[RN14] - Acompanhamento da entrega'''

As informações de andamento da entrega serão obtidas por meio da API da AGV.

'''[RN15] - Atualização de status'''

Os status deverão ser atualizados conforme os retornos do Antifraude, Gateway de Pagamentos e ERP. Virbac 8-10 (1)

== Regras de Integração ==

'''[RI1] - B2B EVO × Lyra'''

A integração deverá contemplar:

- Envio da solicitação de pagamento;

- Dados necessários para processamento;

- Tokenização;

- Consulta/retorno da transação;

- Retorno do Antifraude;
- Status do pagamento;

- Solicitação de estorno;

- Confirmação do estorno.

'''[RI2] - B2B EVO × ERP VIRBAC'''

Deverá contemplar:

- Envio do pedido após confirmação do pagamento;

- Atualização de status;

- Comunicação de cancelamentos;

- Atualizações relacionadas ao ciclo de vida do pedido.

'''[RI3] - B2B EVO × AGV'''

A integração deverá disponibilizar as informações necessárias para acompanhamento do andamento da entrega, conforme os dados fornecidos pela API da AGV.

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

{| class="wikitable"
! Setor
! Aprovado Por
! Data

|-
| Desenvolvimento - GeoSales || Pessoa que aprovou || 00/00/0000
|-
| Integração - GeoSales || Pessoa que aprovou || 00/00/0000
|-
| Configurações - GeoSales || Pessoa que aprovou || 00/00/0000
|-
|}

=== Empresa solicitante ===

{| class="wikitable"
! 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 ||
|-
|}

Caso de Uso – Pagamento Online no B2B EVO para Veterinários

2026-10-30T19:03:07Z

Renatolima: /* Regras de Integração */

== Histórico de Alterações ==
{| class="wikitable"
! Data
! Quem
! Comentários
|-
| 28/10/2026 || Renato Lima || Criação do documento
|-
|}

== Necessidade ==
A VIRBAC necessita disponibilizar uma experiência de compra digital por meio de uma plataforma B2V (Business-to-Vet), permitindo que o médico veterinário, após realizar seu cadastro, validação e login, possa consultar o catálogo autorizado, visualizar os preços conforme sua classificação comercial, realizar pedidos, efetuar pagamentos e acompanhar o status de faturamento e entrega.

Para o processo de pagamento, o B2B EVO deverá integrar-se à API da Lyra, permitindo o processamento das transações financeiras e a utilização dos meios de pagamento disponibilizados pelo parceiro.

Para pagamentos com cartão de crédito, deverá ser implementada a tokenização, permitindo a reutilização do cartão em compras futuras sem que os dados sensíveis sejam armazenados pelo B2B EVO.

O processo também deverá contemplar Antifraude, com análise das transações antes da autorização definitiva do pagamento.

Além do pagamento, deverá existir controle da jornada financeira da transação, incluindo pagamentos pendentes, novas tentativas, histórico, cancelamentos, reembolsos, aprovações e respectivos status.

O fluxo deverá ainda contemplar o acompanhamento da entrega, utilizando as informações disponibilizadas pela API da AGV, considerando a relação CEP × prazo de entrega definida pela contratante.

== Solução ==
Será desenvolvido no B2B EVO o fluxo integrado de compra e pagamento para veterinários, utilizando a API da Lyra para processamento das transações financeiras e Antifraude.

O fluxo será iniciado após a seleção dos produtos e confirmação do endereço de entrega. O sistema deverá utilizar o CEP do endereço para disponibilizar as informações relacionadas ao prazo de entrega.

Após a definição da forma de pagamento, o sistema encaminhará a transação para o fluxo correspondente:

'''- Cartão de crédito:''' verificar existência de token previamente armazenado;

'''- Novo cartão:''' realizar o processo de tokenização através da Lyra e armazenar somente o token;

'''- PIX:''' encaminhar os dados necessários para processamento da transação;

'''- Antifraude:''' submeter a transação à análise antes da autorização definitiva;

'''- Pagamento aprovado:''' registrar a transação, atualizar o pedido e prosseguir com o envio ao ERP;

'''- Pagamento recusado ou pendente:''' registrar a ocorrência e disponibilizar nova tentativa de pagamento.

A solução também contemplará o controle de cancelamentos e reembolsos diretamente no B2B EVO. As solicitações de reembolso deverão registrar o motivo e passar pela aprovação dos responsáveis do Financeiro e/ou Comercial, antes do envio da solicitação de estorno à Lyra.

O acompanhamento da entrega será realizado por meio de tela específica no B2B EVO, utilizando as informações retornadas pela integração com a API da AGV, parceira logística da VIRBAC.

== Implementação ==
A implementação será composta pelos seguintes componentes:

'''Fluxo de compra'''

- Acesso do veterinário ao Portal B2B;

- Seleção dos produtos;

- Confirmação do endereço de entrega;

- Identificação do CEP;

- Consulta das informações de prazo de entrega;

- Confirmação do pedido;

- Seleção da forma de pagamento.

'''Pagamento'''

- Integração B2B EVO × API Lyra;

- Processamento de cartão de crédito;

- Processamento de PIX;

- Tokenização de cartão;

- Armazenamento do token;

- Reutilização do cartão tokenizado;

- Registro das transações;

- Tratamento de pagamentos aprovados, recusados e pendentes.

'''Antifraude'''

- Envio da transação para análise;

- Recebimento do resultado da análise;

- Tratamento de transação aprovada;

- Tratamento de transação recusada;

- Tratamento de transação direcionada para análise adicional;

- Registro do resultado da análise.

O documento define que o resultado do Antifraude poderá determinar a aprovação, recusa ou encaminhamento da transação para análise adicional, conforme as regras do parceiro.

'''Controle financeiro'''

Será criada estrutura específica para gerenciamento das transações, contemplando:

- Pagamentos;

- Análises antifraude;

- Pagamentos pendentes;

- Novas tentativas;

- Cancelamentos;

- Reembolsos;

- Histórico das movimentações;

- Status das transações.

'''Cancelamento e reembolso'''

O B2B EVO será responsável por centralizar o controle do processo de cancelamento.

Para pedidos que necessitem de reembolso:

1. Solicitação de reembolso;

2. Registro do motivo;

3. Análise pelo Financeiro e/ou Comercial;

4. Aprovação ou reprovação;

5. Envio da solicitação de estorno à Lyra;
6. Recebimento da confirmação;

7. Atualização do histórico;

8. Atualização dos sistemas envolvidos.

A definição e validação das políticas de cancelamento de pagamento e das políticas de cancelamento/devolução da entrega são de responsabilidade da contratante.

'''Entrega e logística'''

Será desenvolvida uma tela para acompanhamento do status da entrega.

As informações serão obtidas através da integração com a API da AGV, permitindo que o B2B EVO apresente as fases de andamento da entrega ao veterinário.

== Atores ==
{| class="wikitable"
! Ator
! Responsabilidade
|-
| '''Veterinário''' || Realizar cadastro, acessar o B2B EVO, selecionar produtos, realizar pedidos, efetuar pagamentos e acompanhar a entrega.
|-
| '''B2B EVO''' || Centralizar o fluxo de compra, pagamento, cancelamento, reembolso e acompanhamento da entrega.
|-
| '''Lyra''' || Processar pagamentos, tokenização e Antifraude por meio de suas APIs.
|-
| '''Financeiro''' || Analisar e aprovar/reprovar solicitações de reembolso quando aplicável.
|-
| '''Comercial''' || Analisar e aprovar/reprovar solicitações de reembolso quando aplicável.
|-
| '''ERP VIRBAC''' || Receber e atualizar as informações relacionadas aos pedidos.
|-
| '''AGV''' || Disponibilizar informações relacionadas ao andamento da entrega por meio de API.
|-
|}

== Pré-condições ==
- O veterinário deve estar cadastrado e validado.

- O veterinário deve possuir acesso ao B2B EVO.

- O catálogo autorizado deve estar disponível.

- Os preços aplicáveis à classificação comercial do veterinário devem estar configurados.

- O endereço de entrega deve estar cadastrado.

- O CEP do endereço deve estar disponível para utilização no fluxo logístico.

- A integração com a API da Lyra deve estar disponível.

- A integração com o serviço de Antifraude deve estar disponível.

- A integração com a API da AGV deve estar disponível para acompanhamento da entrega.

- As regras de cancelamento e reembolso devem estar definidas e validadas pela VIRBAC.

== Escopo ==
=== Escopo incluso ===
- Integração com a API da Lyra;

- Integração com Antifraude;

- Tokenização de cartões;

- Reutilização de cartões tokenizados;

- Pagamento via meios disponibilizados pela Lyra;

- Controle de pagamentos pendentes;

- Nova tentativa de pagamento;

- Histórico das transações;

- Controle de cancelamento;

- Solicitação e aprovação de reembolso;

- Solicitação de estorno;

- Atualização dos status;

- Integração com ERP VIRBAC;

- Integração com API da AGV;

- Tela de acompanhamento da entrega;

- Controle da relação CEP × prazo de entrega.

O documento contratado também prevê estrutura de banco e telas administrativas para acompanhamento das transações financeiras e seus respectivos retornos.

=== Escopo Não incluso ===
Com base no documento fornecido, não devem ser considerados neste caso de uso:

- Definição das políticas de cancelamento pela CONTRATADA;

- Definição das políticas de devolução da entrega pela CONTRATADA;

- Desenvolvimento de um novo Gateway de Pagamento;

- Armazenamento dos dados sensíveis dos cartões;

- Criação de serviço próprio de Antifraude;

- Cálculo de valor de frete por CEP.

'''Ponto de atenção:''' o fluxograma enviado contém a etapa “Calcular opções e valor do frete”, porém o documento contratual da VIRBAC estabelece expressamente que, neste escopo, o frete será tratado como CEP × prazo de entrega, sem relação de CEP com valor de frete. Portanto, eu recomendaria alterar essa caixa do fluxograma para “Consultar prazo de entrega conforme CEP” para manter o diagrama coerente com o documento contratado.

== Documentos Relacionados ==

== Regras de Negócios ==

'''[RN1] - Cadastro do veterinário'''

O veterinário deverá estar previamente cadastrado, validado e autenticado para realizar pedidos.

'''[RN2] - Catálogo'''

O veterinário poderá consultar somente o catálogo autorizado para seu perfil.

'''[RN3] - Preço'''

Os preços apresentados deverão considerar a classificação comercial do veterinário.

'''[RN4] - Tokenização'''

Nos pagamentos com cartão, o B2B EVO deverá armazenar somente o token retornado pela Lyra, não persistindo os dados sensíveis do cartão.

'''[RN5] - Reutilização do cartão'''

Quando houver token previamente armazenado, o veterinário poderá reutilizar o cartão sem necessidade de informar novamente seus dados.

'''[RN6] - Antifraude'''

A transação deverá passar pelo processo de análise antifraude antes da autorização definitiva do pagamento.

'''[RN7] - Pagamento recusado'''

Quando o pagamento for recusado, a transação deverá ser registrada e o veterinário poderá realizar uma nova tentativa sem recriar o pedido.

'''[RN8] - Pagamento pendente'''

Pedidos com pagamento pendente deverão permanecer identificados no sistema até que ocorra uma nova tentativa ou atualização do status.

'''[RN9] - Cancelamento'''

O controle do cancelamento deverá ser centralizado no B2B EVO.

'''[RN10] - Reembolso'''

A solicitação de reembolso deverá registrar o motivo e ser submetida à aprovação dos responsáveis definidos pela VIRBAC.

'''[RN11] - Estorno'''

Somente após a aprovação deverá ser enviada a solicitação de estorno à Lyra.

'''[RN12] - Política de cancelamento'''

As regras e políticas de cancelamento do pagamento e de cancelamento/devolução da entrega serão definidas e validadas pela VIRBAC.

'''[RN13] - Frete/Prazo'''

O fluxo logístico deverá considerar a relação CEP × prazo de entrega, não sendo utilizada, neste escopo, uma relação de CEP com valor de frete.

'''[RN14] - Acompanhamento da entrega'''

As informações de andamento da entrega serão obtidas por meio da API da AGV.

'''[RN15] - Atualização de status'''

Os status deverão ser atualizados conforme os retornos do Antifraude, Gateway de Pagamentos e ERP. Virbac 8-10 (1)

== Regras de Integração ==

'''[RI1] - B2B EVO × Lyra'''

A integração deverá contemplar:

- Envio da solicitação de pagamento;

- Dados necessários para processamento;

- Tokenização;

- Consulta/retorno da transação;

- Retorno do Antifraude;
- Status do pagamento;

- Solicitação de estorno;

- Confirmação do estorno.

'''[RI2] - B2B EVO × ERP VIRBAC'''

Deverá contemplar:

- Envio do pedido após confirmação do pagamento;

- Atualização de status;

- Comunicação de cancelamentos;

- Atualizações relacionadas ao ciclo de vida do pedido.

'''[RI3] - '''

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

{| class="wikitable"
! Setor
! Aprovado Por
! Data

|-
| Desenvolvimento - GeoSales || Pessoa que aprovou || 00/00/0000
|-
| Integração - GeoSales || Pessoa que aprovou || 00/00/0000
|-
| Configurações - GeoSales || Pessoa que aprovou || 00/00/0000
|-
|}

=== Empresa solicitante ===

{| class="wikitable"
! 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 ||
|-
|}

Caso de Uso – Pagamento Online no B2B EVO para Veterinários

2026-10-30T19:02:15Z

Renatolima: /* Regras de Negócios */

== Histórico de Alterações ==
{| class="wikitable"
! Data
! Quem
! Comentários
|-
| 28/10/2026 || Renato Lima || Criação do documento
|-
|}

== Necessidade ==
A VIRBAC necessita disponibilizar uma experiência de compra digital por meio de uma plataforma B2V (Business-to-Vet), permitindo que o médico veterinário, após realizar seu cadastro, validação e login, possa consultar o catálogo autorizado, visualizar os preços conforme sua classificação comercial, realizar pedidos, efetuar pagamentos e acompanhar o status de faturamento e entrega.

Para o processo de pagamento, o B2B EVO deverá integrar-se à API da Lyra, permitindo o processamento das transações financeiras e a utilização dos meios de pagamento disponibilizados pelo parceiro.

Para pagamentos com cartão de crédito, deverá ser implementada a tokenização, permitindo a reutilização do cartão em compras futuras sem que os dados sensíveis sejam armazenados pelo B2B EVO.

O processo também deverá contemplar Antifraude, com análise das transações antes da autorização definitiva do pagamento.

Além do pagamento, deverá existir controle da jornada financeira da transação, incluindo pagamentos pendentes, novas tentativas, histórico, cancelamentos, reembolsos, aprovações e respectivos status.

O fluxo deverá ainda contemplar o acompanhamento da entrega, utilizando as informações disponibilizadas pela API da AGV, considerando a relação CEP × prazo de entrega definida pela contratante.

== Solução ==
Será desenvolvido no B2B EVO o fluxo integrado de compra e pagamento para veterinários, utilizando a API da Lyra para processamento das transações financeiras e Antifraude.

O fluxo será iniciado após a seleção dos produtos e confirmação do endereço de entrega. O sistema deverá utilizar o CEP do endereço para disponibilizar as informações relacionadas ao prazo de entrega.

Após a definição da forma de pagamento, o sistema encaminhará a transação para o fluxo correspondente:

'''- Cartão de crédito:''' verificar existência de token previamente armazenado;

'''- Novo cartão:''' realizar o processo de tokenização através da Lyra e armazenar somente o token;

'''- PIX:''' encaminhar os dados necessários para processamento da transação;

'''- Antifraude:''' submeter a transação à análise antes da autorização definitiva;

'''- Pagamento aprovado:''' registrar a transação, atualizar o pedido e prosseguir com o envio ao ERP;

'''- Pagamento recusado ou pendente:''' registrar a ocorrência e disponibilizar nova tentativa de pagamento.

A solução também contemplará o controle de cancelamentos e reembolsos diretamente no B2B EVO. As solicitações de reembolso deverão registrar o motivo e passar pela aprovação dos responsáveis do Financeiro e/ou Comercial, antes do envio da solicitação de estorno à Lyra.

O acompanhamento da entrega será realizado por meio de tela específica no B2B EVO, utilizando as informações retornadas pela integração com a API da AGV, parceira logística da VIRBAC.

== Implementação ==
A implementação será composta pelos seguintes componentes:

'''Fluxo de compra'''

- Acesso do veterinário ao Portal B2B;

- Seleção dos produtos;

- Confirmação do endereço de entrega;

- Identificação do CEP;

- Consulta das informações de prazo de entrega;

- Confirmação do pedido;

- Seleção da forma de pagamento.

'''Pagamento'''

- Integração B2B EVO × API Lyra;

- Processamento de cartão de crédito;

- Processamento de PIX;

- Tokenização de cartão;

- Armazenamento do token;

- Reutilização do cartão tokenizado;

- Registro das transações;

- Tratamento de pagamentos aprovados, recusados e pendentes.

'''Antifraude'''

- Envio da transação para análise;

- Recebimento do resultado da análise;

- Tratamento de transação aprovada;

- Tratamento de transação recusada;

- Tratamento de transação direcionada para análise adicional;

- Registro do resultado da análise.

O documento define que o resultado do Antifraude poderá determinar a aprovação, recusa ou encaminhamento da transação para análise adicional, conforme as regras do parceiro.

'''Controle financeiro'''

Será criada estrutura específica para gerenciamento das transações, contemplando:

- Pagamentos;

- Análises antifraude;

- Pagamentos pendentes;

- Novas tentativas;

- Cancelamentos;

- Reembolsos;

- Histórico das movimentações;

- Status das transações.

'''Cancelamento e reembolso'''

O B2B EVO será responsável por centralizar o controle do processo de cancelamento.

Para pedidos que necessitem de reembolso:

1. Solicitação de reembolso;

2. Registro do motivo;

3. Análise pelo Financeiro e/ou Comercial;

4. Aprovação ou reprovação;

5. Envio da solicitação de estorno à Lyra;
6. Recebimento da confirmação;

7. Atualização do histórico;

8. Atualização dos sistemas envolvidos.

A definição e validação das políticas de cancelamento de pagamento e das políticas de cancelamento/devolução da entrega são de responsabilidade da contratante.

'''Entrega e logística'''

Será desenvolvida uma tela para acompanhamento do status da entrega.

As informações serão obtidas através da integração com a API da AGV, permitindo que o B2B EVO apresente as fases de andamento da entrega ao veterinário.

== Atores ==
{| class="wikitable"
! Ator
! Responsabilidade
|-
| '''Veterinário''' || Realizar cadastro, acessar o B2B EVO, selecionar produtos, realizar pedidos, efetuar pagamentos e acompanhar a entrega.
|-
| '''B2B EVO''' || Centralizar o fluxo de compra, pagamento, cancelamento, reembolso e acompanhamento da entrega.
|-
| '''Lyra''' || Processar pagamentos, tokenização e Antifraude por meio de suas APIs.
|-
| '''Financeiro''' || Analisar e aprovar/reprovar solicitações de reembolso quando aplicável.
|-
| '''Comercial''' || Analisar e aprovar/reprovar solicitações de reembolso quando aplicável.
|-
| '''ERP VIRBAC''' || Receber e atualizar as informações relacionadas aos pedidos.
|-
| '''AGV''' || Disponibilizar informações relacionadas ao andamento da entrega por meio de API.
|-
|}

== Pré-condições ==
- O veterinário deve estar cadastrado e validado.

- O veterinário deve possuir acesso ao B2B EVO.

- O catálogo autorizado deve estar disponível.

- Os preços aplicáveis à classificação comercial do veterinário devem estar configurados.

- O endereço de entrega deve estar cadastrado.

- O CEP do endereço deve estar disponível para utilização no fluxo logístico.

- A integração com a API da Lyra deve estar disponível.

- A integração com o serviço de Antifraude deve estar disponível.

- A integração com a API da AGV deve estar disponível para acompanhamento da entrega.

- As regras de cancelamento e reembolso devem estar definidas e validadas pela VIRBAC.

== Escopo ==
=== Escopo incluso ===
- Integração com a API da Lyra;

- Integração com Antifraude;

- Tokenização de cartões;

- Reutilização de cartões tokenizados;

- Pagamento via meios disponibilizados pela Lyra;

- Controle de pagamentos pendentes;

- Nova tentativa de pagamento;

- Histórico das transações;

- Controle de cancelamento;

- Solicitação e aprovação de reembolso;

- Solicitação de estorno;

- Atualização dos status;

- Integração com ERP VIRBAC;

- Integração com API da AGV;

- Tela de acompanhamento da entrega;

- Controle da relação CEP × prazo de entrega.

O documento contratado também prevê estrutura de banco e telas administrativas para acompanhamento das transações financeiras e seus respectivos retornos.

=== Escopo Não incluso ===
Com base no documento fornecido, não devem ser considerados neste caso de uso:

- Definição das políticas de cancelamento pela CONTRATADA;

- Definição das políticas de devolução da entrega pela CONTRATADA;

- Desenvolvimento de um novo Gateway de Pagamento;

- Armazenamento dos dados sensíveis dos cartões;

- Criação de serviço próprio de Antifraude;

- Cálculo de valor de frete por CEP.

'''Ponto de atenção:''' o fluxograma enviado contém a etapa “Calcular opções e valor do frete”, porém o documento contratual da VIRBAC estabelece expressamente que, neste escopo, o frete será tratado como CEP × prazo de entrega, sem relação de CEP com valor de frete. Portanto, eu recomendaria alterar essa caixa do fluxograma para “Consultar prazo de entrega conforme CEP” para manter o diagrama coerente com o documento contratado.

== Documentos Relacionados ==

== Regras de Negócios ==

'''[RN1] - Cadastro do veterinário'''

O veterinário deverá estar previamente cadastrado, validado e autenticado para realizar pedidos.

'''[RN2] - Catálogo'''

O veterinário poderá consultar somente o catálogo autorizado para seu perfil.

'''[RN3] - Preço'''

Os preços apresentados deverão considerar a classificação comercial do veterinário.

'''[RN4] - Tokenização'''

Nos pagamentos com cartão, o B2B EVO deverá armazenar somente o token retornado pela Lyra, não persistindo os dados sensíveis do cartão.

'''[RN5] - Reutilização do cartão'''

Quando houver token previamente armazenado, o veterinário poderá reutilizar o cartão sem necessidade de informar novamente seus dados.

'''[RN6] - Antifraude'''

A transação deverá passar pelo processo de análise antifraude antes da autorização definitiva do pagamento.

'''[RN7] - Pagamento recusado'''

Quando o pagamento for recusado, a transação deverá ser registrada e o veterinário poderá realizar uma nova tentativa sem recriar o pedido.

'''[RN8] - Pagamento pendente'''

Pedidos com pagamento pendente deverão permanecer identificados no sistema até que ocorra uma nova tentativa ou atualização do status.

'''[RN9] - Cancelamento'''

O controle do cancelamento deverá ser centralizado no B2B EVO.

'''[RN10] - Reembolso'''

A solicitação de reembolso deverá registrar o motivo e ser submetida à aprovação dos responsáveis definidos pela VIRBAC.

'''[RN11] - Estorno'''

Somente após a aprovação deverá ser enviada a solicitação de estorno à Lyra.

'''[RN12] - Política de cancelamento'''

As regras e políticas de cancelamento do pagamento e de cancelamento/devolução da entrega serão definidas e validadas pela VIRBAC.

'''[RN13] - Frete/Prazo'''

O fluxo logístico deverá considerar a relação CEP × prazo de entrega, não sendo utilizada, neste escopo, uma relação de CEP com valor de frete.

'''[RN14] - Acompanhamento da entrega'''

As informações de andamento da entrega serão obtidas por meio da API da AGV.

'''[RN15] - Atualização de status'''

Os status deverão ser atualizados conforme os retornos do Antifraude, Gateway de Pagamentos e ERP. Virbac 8-10 (1)

== Regras de Integração ==

'''[RI1] - '''

'''[RI2] - '''

'''[RI3] - '''

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

{| class="wikitable"
! Setor
! Aprovado Por
! Data

|-
| Desenvolvimento - GeoSales || Pessoa que aprovou || 00/00/0000
|-
| Integração - GeoSales || Pessoa que aprovou || 00/00/0000
|-
| Configurações - GeoSales || Pessoa que aprovou || 00/00/0000
|-
|}

=== Empresa solicitante ===

{| class="wikitable"
! 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 ||
|-
|}

Caso de Uso – Pagamento Online no B2B EVO para Veterinários

2026-10-30T18:14:34Z

Renatolima: /* Regras de Integração */

== Histórico de Alterações ==
{| class="wikitable"
! Data
! Quem
! Comentários
|-
| 28/10/2026 || Renato Lima || Criação do documento
|-
|}

== Necessidade ==
A VIRBAC necessita disponibilizar uma experiência de compra digital por meio de uma plataforma B2V (Business-to-Vet), permitindo que o médico veterinário, após realizar seu cadastro, validação e login, possa consultar o catálogo autorizado, visualizar os preços conforme sua classificação comercial, realizar pedidos, efetuar pagamentos e acompanhar o status de faturamento e entrega.

Para o processo de pagamento, o B2B EVO deverá integrar-se à API da Lyra, permitindo o processamento das transações financeiras e a utilização dos meios de pagamento disponibilizados pelo parceiro.

Para pagamentos com cartão de crédito, deverá ser implementada a tokenização, permitindo a reutilização do cartão em compras futuras sem que os dados sensíveis sejam armazenados pelo B2B EVO.

O processo também deverá contemplar Antifraude, com análise das transações antes da autorização definitiva do pagamento.

Além do pagamento, deverá existir controle da jornada financeira da transação, incluindo pagamentos pendentes, novas tentativas, histórico, cancelamentos, reembolsos, aprovações e respectivos status.

O fluxo deverá ainda contemplar o acompanhamento da entrega, utilizando as informações disponibilizadas pela API da AGV, considerando a relação CEP × prazo de entrega definida pela contratante.

== Solução ==
Será desenvolvido no B2B EVO o fluxo integrado de compra e pagamento para veterinários, utilizando a API da Lyra para processamento das transações financeiras e Antifraude.

O fluxo será iniciado após a seleção dos produtos e confirmação do endereço de entrega. O sistema deverá utilizar o CEP do endereço para disponibilizar as informações relacionadas ao prazo de entrega.

Após a definição da forma de pagamento, o sistema encaminhará a transação para o fluxo correspondente:

'''- Cartão de crédito:''' verificar existência de token previamente armazenado;

'''- Novo cartão:''' realizar o processo de tokenização através da Lyra e armazenar somente o token;

'''- PIX:''' encaminhar os dados necessários para processamento da transação;

'''- Antifraude:''' submeter a transação à análise antes da autorização definitiva;

'''- Pagamento aprovado:''' registrar a transação, atualizar o pedido e prosseguir com o envio ao ERP;

'''- Pagamento recusado ou pendente:''' registrar a ocorrência e disponibilizar nova tentativa de pagamento.

A solução também contemplará o controle de cancelamentos e reembolsos diretamente no B2B EVO. As solicitações de reembolso deverão registrar o motivo e passar pela aprovação dos responsáveis do Financeiro e/ou Comercial, antes do envio da solicitação de estorno à Lyra.

O acompanhamento da entrega será realizado por meio de tela específica no B2B EVO, utilizando as informações retornadas pela integração com a API da AGV, parceira logística da VIRBAC.

== Implementação ==
A implementação será composta pelos seguintes componentes:

'''Fluxo de compra'''

- Acesso do veterinário ao Portal B2B;

- Seleção dos produtos;

- Confirmação do endereço de entrega;

- Identificação do CEP;

- Consulta das informações de prazo de entrega;

- Confirmação do pedido;

- Seleção da forma de pagamento.

'''Pagamento'''

- Integração B2B EVO × API Lyra;

- Processamento de cartão de crédito;

- Processamento de PIX;

- Tokenização de cartão;

- Armazenamento do token;

- Reutilização do cartão tokenizado;

- Registro das transações;

- Tratamento de pagamentos aprovados, recusados e pendentes.

'''Antifraude'''

- Envio da transação para análise;

- Recebimento do resultado da análise;

- Tratamento de transação aprovada;

- Tratamento de transação recusada;

- Tratamento de transação direcionada para análise adicional;

- Registro do resultado da análise.

O documento define que o resultado do Antifraude poderá determinar a aprovação, recusa ou encaminhamento da transação para análise adicional, conforme as regras do parceiro.

'''Controle financeiro'''

Será criada estrutura específica para gerenciamento das transações, contemplando:

- Pagamentos;

- Análises antifraude;

- Pagamentos pendentes;

- Novas tentativas;

- Cancelamentos;

- Reembolsos;

- Histórico das movimentações;

- Status das transações.

'''Cancelamento e reembolso'''

O B2B EVO será responsável por centralizar o controle do processo de cancelamento.

Para pedidos que necessitem de reembolso:

1. Solicitação de reembolso;

2. Registro do motivo;

3. Análise pelo Financeiro e/ou Comercial;

4. Aprovação ou reprovação;

5. Envio da solicitação de estorno à Lyra;
6. Recebimento da confirmação;

7. Atualização do histórico;

8. Atualização dos sistemas envolvidos.

A definição e validação das políticas de cancelamento de pagamento e das políticas de cancelamento/devolução da entrega são de responsabilidade da contratante.

'''Entrega e logística'''

Será desenvolvida uma tela para acompanhamento do status da entrega.

As informações serão obtidas através da integração com a API da AGV, permitindo que o B2B EVO apresente as fases de andamento da entrega ao veterinário.

== Atores ==
{| class="wikitable"
! Ator
! Responsabilidade
|-
| '''Veterinário''' || Realizar cadastro, acessar o B2B EVO, selecionar produtos, realizar pedidos, efetuar pagamentos e acompanhar a entrega.
|-
| '''B2B EVO''' || Centralizar o fluxo de compra, pagamento, cancelamento, reembolso e acompanhamento da entrega.
|-
| '''Lyra''' || Processar pagamentos, tokenização e Antifraude por meio de suas APIs.
|-
| '''Financeiro''' || Analisar e aprovar/reprovar solicitações de reembolso quando aplicável.
|-
| '''Comercial''' || Analisar e aprovar/reprovar solicitações de reembolso quando aplicável.
|-
| '''ERP VIRBAC''' || Receber e atualizar as informações relacionadas aos pedidos.
|-
| '''AGV''' || Disponibilizar informações relacionadas ao andamento da entrega por meio de API.
|-
|}

== Pré-condições ==
- O veterinário deve estar cadastrado e validado.

- O veterinário deve possuir acesso ao B2B EVO.

- O catálogo autorizado deve estar disponível.

- Os preços aplicáveis à classificação comercial do veterinário devem estar configurados.

- O endereço de entrega deve estar cadastrado.

- O CEP do endereço deve estar disponível para utilização no fluxo logístico.

- A integração com a API da Lyra deve estar disponível.

- A integração com o serviço de Antifraude deve estar disponível.

- A integração com a API da AGV deve estar disponível para acompanhamento da entrega.

- As regras de cancelamento e reembolso devem estar definidas e validadas pela VIRBAC.

== Escopo ==
=== Escopo incluso ===
- Integração com a API da Lyra;

- Integração com Antifraude;

- Tokenização de cartões;

- Reutilização de cartões tokenizados;

- Pagamento via meios disponibilizados pela Lyra;

- Controle de pagamentos pendentes;

- Nova tentativa de pagamento;

- Histórico das transações;

- Controle de cancelamento;

- Solicitação e aprovação de reembolso;

- Solicitação de estorno;

- Atualização dos status;

- Integração com ERP VIRBAC;

- Integração com API da AGV;

- Tela de acompanhamento da entrega;

- Controle da relação CEP × prazo de entrega.

O documento contratado também prevê estrutura de banco e telas administrativas para acompanhamento das transações financeiras e seus respectivos retornos.

=== Escopo Não incluso ===
Com base no documento fornecido, não devem ser considerados neste caso de uso:

- Definição das políticas de cancelamento pela CONTRATADA;

- Definição das políticas de devolução da entrega pela CONTRATADA;

- Desenvolvimento de um novo Gateway de Pagamento;

- Armazenamento dos dados sensíveis dos cartões;

- Criação de serviço próprio de Antifraude;

- Cálculo de valor de frete por CEP.

'''Ponto de atenção:''' o fluxograma enviado contém a etapa “Calcular opções e valor do frete”, porém o documento contratual da VIRBAC estabelece expressamente que, neste escopo, o frete será tratado como CEP × prazo de entrega, sem relação de CEP com valor de frete. Portanto, eu recomendaria alterar essa caixa do fluxograma para “Consultar prazo de entrega conforme CEP” para manter o diagrama coerente com o documento contratado.

== Documentos Relacionados ==

== Regras de Negócios ==

'''[RN1] - '''

'''[RN2] - '''

'''[RN3] - '''

'''[RN4] - '''

'''[RN5] - '''

'''[RN6] - '''

'''[RN7] - '''

'''[RN8] - '''

'''[RN9] - '''

'''[RN10] - '''

'''[RN11] - '''

'''[RN12] - '''

'''[RN13] - '''

'''[RN14] - '''

'''[RN15] - '''

== Regras de Integração ==

'''[RI1] - '''

'''[RI2] - '''

'''[RI3] - '''

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

{| class="wikitable"
! Setor
! Aprovado Por
! Data

|-
| Desenvolvimento - GeoSales || Pessoa que aprovou || 00/00/0000
|-
| Integração - GeoSales || Pessoa que aprovou || 00/00/0000
|-
| Configurações - GeoSales || Pessoa que aprovou || 00/00/0000
|-
|}

=== Empresa solicitante ===

{| class="wikitable"
! 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 ||
|-
|}

Caso de Uso – Pagamento Online no B2B EVO para Veterinários

2026-10-30T18:14:15Z

Renatolima: /* Regras de Negócios */

== Histórico de Alterações ==
{| class="wikitable"
! Data
! Quem
! Comentários
|-
| 28/10/2026 || Renato Lima || Criação do documento
|-
|}

== Necessidade ==
A VIRBAC necessita disponibilizar uma experiência de compra digital por meio de uma plataforma B2V (Business-to-Vet), permitindo que o médico veterinário, após realizar seu cadastro, validação e login, possa consultar o catálogo autorizado, visualizar os preços conforme sua classificação comercial, realizar pedidos, efetuar pagamentos e acompanhar o status de faturamento e entrega.

Para o processo de pagamento, o B2B EVO deverá integrar-se à API da Lyra, permitindo o processamento das transações financeiras e a utilização dos meios de pagamento disponibilizados pelo parceiro.

Para pagamentos com cartão de crédito, deverá ser implementada a tokenização, permitindo a reutilização do cartão em compras futuras sem que os dados sensíveis sejam armazenados pelo B2B EVO.

O processo também deverá contemplar Antifraude, com análise das transações antes da autorização definitiva do pagamento.

Além do pagamento, deverá existir controle da jornada financeira da transação, incluindo pagamentos pendentes, novas tentativas, histórico, cancelamentos, reembolsos, aprovações e respectivos status.

O fluxo deverá ainda contemplar o acompanhamento da entrega, utilizando as informações disponibilizadas pela API da AGV, considerando a relação CEP × prazo de entrega definida pela contratante.

== Solução ==
Será desenvolvido no B2B EVO o fluxo integrado de compra e pagamento para veterinários, utilizando a API da Lyra para processamento das transações financeiras e Antifraude.

O fluxo será iniciado após a seleção dos produtos e confirmação do endereço de entrega. O sistema deverá utilizar o CEP do endereço para disponibilizar as informações relacionadas ao prazo de entrega.

Após a definição da forma de pagamento, o sistema encaminhará a transação para o fluxo correspondente:

'''- Cartão de crédito:''' verificar existência de token previamente armazenado;

'''- Novo cartão:''' realizar o processo de tokenização através da Lyra e armazenar somente o token;

'''- PIX:''' encaminhar os dados necessários para processamento da transação;

'''- Antifraude:''' submeter a transação à análise antes da autorização definitiva;

'''- Pagamento aprovado:''' registrar a transação, atualizar o pedido e prosseguir com o envio ao ERP;

'''- Pagamento recusado ou pendente:''' registrar a ocorrência e disponibilizar nova tentativa de pagamento.

A solução também contemplará o controle de cancelamentos e reembolsos diretamente no B2B EVO. As solicitações de reembolso deverão registrar o motivo e passar pela aprovação dos responsáveis do Financeiro e/ou Comercial, antes do envio da solicitação de estorno à Lyra.

O acompanhamento da entrega será realizado por meio de tela específica no B2B EVO, utilizando as informações retornadas pela integração com a API da AGV, parceira logística da VIRBAC.

== Implementação ==
A implementação será composta pelos seguintes componentes:

'''Fluxo de compra'''

- Acesso do veterinário ao Portal B2B;

- Seleção dos produtos;

- Confirmação do endereço de entrega;

- Identificação do CEP;

- Consulta das informações de prazo de entrega;

- Confirmação do pedido;

- Seleção da forma de pagamento.

'''Pagamento'''

- Integração B2B EVO × API Lyra;

- Processamento de cartão de crédito;

- Processamento de PIX;

- Tokenização de cartão;

- Armazenamento do token;

- Reutilização do cartão tokenizado;

- Registro das transações;

- Tratamento de pagamentos aprovados, recusados e pendentes.

'''Antifraude'''

- Envio da transação para análise;

- Recebimento do resultado da análise;

- Tratamento de transação aprovada;

- Tratamento de transação recusada;

- Tratamento de transação direcionada para análise adicional;

- Registro do resultado da análise.

O documento define que o resultado do Antifraude poderá determinar a aprovação, recusa ou encaminhamento da transação para análise adicional, conforme as regras do parceiro.

'''Controle financeiro'''

Será criada estrutura específica para gerenciamento das transações, contemplando:

- Pagamentos;

- Análises antifraude;

- Pagamentos pendentes;

- Novas tentativas;

- Cancelamentos;

- Reembolsos;

- Histórico das movimentações;

- Status das transações.

'''Cancelamento e reembolso'''

O B2B EVO será responsável por centralizar o controle do processo de cancelamento.

Para pedidos que necessitem de reembolso:

1. Solicitação de reembolso;

2. Registro do motivo;

3. Análise pelo Financeiro e/ou Comercial;

4. Aprovação ou reprovação;

5. Envio da solicitação de estorno à Lyra;
6. Recebimento da confirmação;

7. Atualização do histórico;

8. Atualização dos sistemas envolvidos.

A definição e validação das políticas de cancelamento de pagamento e das políticas de cancelamento/devolução da entrega são de responsabilidade da contratante.

'''Entrega e logística'''

Será desenvolvida uma tela para acompanhamento do status da entrega.

As informações serão obtidas através da integração com a API da AGV, permitindo que o B2B EVO apresente as fases de andamento da entrega ao veterinário.

== Atores ==
{| class="wikitable"
! Ator
! Responsabilidade
|-
| '''Veterinário''' || Realizar cadastro, acessar o B2B EVO, selecionar produtos, realizar pedidos, efetuar pagamentos e acompanhar a entrega.
|-
| '''B2B EVO''' || Centralizar o fluxo de compra, pagamento, cancelamento, reembolso e acompanhamento da entrega.
|-
| '''Lyra''' || Processar pagamentos, tokenização e Antifraude por meio de suas APIs.
|-
| '''Financeiro''' || Analisar e aprovar/reprovar solicitações de reembolso quando aplicável.
|-
| '''Comercial''' || Analisar e aprovar/reprovar solicitações de reembolso quando aplicável.
|-
| '''ERP VIRBAC''' || Receber e atualizar as informações relacionadas aos pedidos.
|-
| '''AGV''' || Disponibilizar informações relacionadas ao andamento da entrega por meio de API.
|-
|}

== Pré-condições ==
- O veterinário deve estar cadastrado e validado.

- O veterinário deve possuir acesso ao B2B EVO.

- O catálogo autorizado deve estar disponível.

- Os preços aplicáveis à classificação comercial do veterinário devem estar configurados.

- O endereço de entrega deve estar cadastrado.

- O CEP do endereço deve estar disponível para utilização no fluxo logístico.

- A integração com a API da Lyra deve estar disponível.

- A integração com o serviço de Antifraude deve estar disponível.

- A integração com a API da AGV deve estar disponível para acompanhamento da entrega.

- As regras de cancelamento e reembolso devem estar definidas e validadas pela VIRBAC.

== Escopo ==
=== Escopo incluso ===
- Integração com a API da Lyra;

- Integração com Antifraude;

- Tokenização de cartões;

- Reutilização de cartões tokenizados;

- Pagamento via meios disponibilizados pela Lyra;

- Controle de pagamentos pendentes;

- Nova tentativa de pagamento;

- Histórico das transações;

- Controle de cancelamento;

- Solicitação e aprovação de reembolso;

- Solicitação de estorno;

- Atualização dos status;

- Integração com ERP VIRBAC;

- Integração com API da AGV;

- Tela de acompanhamento da entrega;

- Controle da relação CEP × prazo de entrega.

O documento contratado também prevê estrutura de banco e telas administrativas para acompanhamento das transações financeiras e seus respectivos retornos.

=== Escopo Não incluso ===
Com base no documento fornecido, não devem ser considerados neste caso de uso:

- Definição das políticas de cancelamento pela CONTRATADA;

- Definição das políticas de devolução da entrega pela CONTRATADA;

- Desenvolvimento de um novo Gateway de Pagamento;

- Armazenamento dos dados sensíveis dos cartões;

- Criação de serviço próprio de Antifraude;

- Cálculo de valor de frete por CEP.

'''Ponto de atenção:''' o fluxograma enviado contém a etapa “Calcular opções e valor do frete”, porém o documento contratual da VIRBAC estabelece expressamente que, neste escopo, o frete será tratado como CEP × prazo de entrega, sem relação de CEP com valor de frete. Portanto, eu recomendaria alterar essa caixa do fluxograma para “Consultar prazo de entrega conforme CEP” para manter o diagrama coerente com o documento contratado.

== Documentos Relacionados ==

== Regras de Negócios ==

'''[RN1] - '''

'''[RN2] - '''

'''[RN3] - '''

'''[RN4] - '''

'''[RN5] - '''

'''[RN6] - '''

'''[RN7] - '''

'''[RN8] - '''

'''[RN9] - '''

'''[RN10] - '''

'''[RN11] - '''

'''[RN12] - '''

'''[RN13] - '''

'''[RN14] - '''

'''[RN15] - '''

== Regras de Integração ==

'''[RI1] - '''

'''[RI2] - '''

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

{| class="wikitable"
! Setor
! Aprovado Por
! Data

|-
| Desenvolvimento - GeoSales || Pessoa que aprovou || 00/00/0000
|-
| Integração - GeoSales || Pessoa que aprovou || 00/00/0000
|-
| Configurações - GeoSales || Pessoa que aprovou || 00/00/0000
|-
|}

=== Empresa solicitante ===

{| class="wikitable"
! 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 ||
|-
|}

Caso de Uso – Pagamento Online no B2B EVO para Veterinários

2026-10-30T18:11:36Z

Renatolima: /* Regras de Negócios */

== Histórico de Alterações ==
{| class="wikitable"
! Data
! Quem
! Comentários
|-
| 28/10/2026 || Renato Lima || Criação do documento
|-
|}

== Necessidade ==
A VIRBAC necessita disponibilizar uma experiência de compra digital por meio de uma plataforma B2V (Business-to-Vet), permitindo que o médico veterinário, após realizar seu cadastro, validação e login, possa consultar o catálogo autorizado, visualizar os preços conforme sua classificação comercial, realizar pedidos, efetuar pagamentos e acompanhar o status de faturamento e entrega.

Para o processo de pagamento, o B2B EVO deverá integrar-se à API da Lyra, permitindo o processamento das transações financeiras e a utilização dos meios de pagamento disponibilizados pelo parceiro.

Para pagamentos com cartão de crédito, deverá ser implementada a tokenização, permitindo a reutilização do cartão em compras futuras sem que os dados sensíveis sejam armazenados pelo B2B EVO.

O processo também deverá contemplar Antifraude, com análise das transações antes da autorização definitiva do pagamento.

Além do pagamento, deverá existir controle da jornada financeira da transação, incluindo pagamentos pendentes, novas tentativas, histórico, cancelamentos, reembolsos, aprovações e respectivos status.

O fluxo deverá ainda contemplar o acompanhamento da entrega, utilizando as informações disponibilizadas pela API da AGV, considerando a relação CEP × prazo de entrega definida pela contratante.

== Solução ==
Será desenvolvido no B2B EVO o fluxo integrado de compra e pagamento para veterinários, utilizando a API da Lyra para processamento das transações financeiras e Antifraude.

O fluxo será iniciado após a seleção dos produtos e confirmação do endereço de entrega. O sistema deverá utilizar o CEP do endereço para disponibilizar as informações relacionadas ao prazo de entrega.

Após a definição da forma de pagamento, o sistema encaminhará a transação para o fluxo correspondente:

'''- Cartão de crédito:''' verificar existência de token previamente armazenado;

'''- Novo cartão:''' realizar o processo de tokenização através da Lyra e armazenar somente o token;

'''- PIX:''' encaminhar os dados necessários para processamento da transação;

'''- Antifraude:''' submeter a transação à análise antes da autorização definitiva;

'''- Pagamento aprovado:''' registrar a transação, atualizar o pedido e prosseguir com o envio ao ERP;

'''- Pagamento recusado ou pendente:''' registrar a ocorrência e disponibilizar nova tentativa de pagamento.

A solução também contemplará o controle de cancelamentos e reembolsos diretamente no B2B EVO. As solicitações de reembolso deverão registrar o motivo e passar pela aprovação dos responsáveis do Financeiro e/ou Comercial, antes do envio da solicitação de estorno à Lyra.

O acompanhamento da entrega será realizado por meio de tela específica no B2B EVO, utilizando as informações retornadas pela integração com a API da AGV, parceira logística da VIRBAC.

== Implementação ==
A implementação será composta pelos seguintes componentes:

'''Fluxo de compra'''

- Acesso do veterinário ao Portal B2B;

- Seleção dos produtos;

- Confirmação do endereço de entrega;

- Identificação do CEP;

- Consulta das informações de prazo de entrega;

- Confirmação do pedido;

- Seleção da forma de pagamento.

'''Pagamento'''

- Integração B2B EVO × API Lyra;

- Processamento de cartão de crédito;

- Processamento de PIX;

- Tokenização de cartão;

- Armazenamento do token;

- Reutilização do cartão tokenizado;

- Registro das transações;

- Tratamento de pagamentos aprovados, recusados e pendentes.

'''Antifraude'''

- Envio da transação para análise;

- Recebimento do resultado da análise;

- Tratamento de transação aprovada;

- Tratamento de transação recusada;

- Tratamento de transação direcionada para análise adicional;

- Registro do resultado da análise.

O documento define que o resultado do Antifraude poderá determinar a aprovação, recusa ou encaminhamento da transação para análise adicional, conforme as regras do parceiro.

'''Controle financeiro'''

Será criada estrutura específica para gerenciamento das transações, contemplando:

- Pagamentos;

- Análises antifraude;

- Pagamentos pendentes;

- Novas tentativas;

- Cancelamentos;

- Reembolsos;

- Histórico das movimentações;

- Status das transações.

'''Cancelamento e reembolso'''

O B2B EVO será responsável por centralizar o controle do processo de cancelamento.

Para pedidos que necessitem de reembolso:

1. Solicitação de reembolso;

2. Registro do motivo;

3. Análise pelo Financeiro e/ou Comercial;

4. Aprovação ou reprovação;

5. Envio da solicitação de estorno à Lyra;
6. Recebimento da confirmação;

7. Atualização do histórico;

8. Atualização dos sistemas envolvidos.

A definição e validação das políticas de cancelamento de pagamento e das políticas de cancelamento/devolução da entrega são de responsabilidade da contratante.

'''Entrega e logística'''

Será desenvolvida uma tela para acompanhamento do status da entrega.

As informações serão obtidas através da integração com a API da AGV, permitindo que o B2B EVO apresente as fases de andamento da entrega ao veterinário.

== Atores ==
{| class="wikitable"
! Ator
! Responsabilidade
|-
| '''Veterinário''' || Realizar cadastro, acessar o B2B EVO, selecionar produtos, realizar pedidos, efetuar pagamentos e acompanhar a entrega.
|-
| '''B2B EVO''' || Centralizar o fluxo de compra, pagamento, cancelamento, reembolso e acompanhamento da entrega.
|-
| '''Lyra''' || Processar pagamentos, tokenização e Antifraude por meio de suas APIs.
|-
| '''Financeiro''' || Analisar e aprovar/reprovar solicitações de reembolso quando aplicável.
|-
| '''Comercial''' || Analisar e aprovar/reprovar solicitações de reembolso quando aplicável.
|-
| '''ERP VIRBAC''' || Receber e atualizar as informações relacionadas aos pedidos.
|-
| '''AGV''' || Disponibilizar informações relacionadas ao andamento da entrega por meio de API.
|-
|}

== Pré-condições ==
- O veterinário deve estar cadastrado e validado.

- O veterinário deve possuir acesso ao B2B EVO.

- O catálogo autorizado deve estar disponível.

- Os preços aplicáveis à classificação comercial do veterinário devem estar configurados.

- O endereço de entrega deve estar cadastrado.

- O CEP do endereço deve estar disponível para utilização no fluxo logístico.

- A integração com a API da Lyra deve estar disponível.

- A integração com o serviço de Antifraude deve estar disponível.

- A integração com a API da AGV deve estar disponível para acompanhamento da entrega.

- As regras de cancelamento e reembolso devem estar definidas e validadas pela VIRBAC.

== Escopo ==
=== Escopo incluso ===
- Integração com a API da Lyra;

- Integração com Antifraude;

- Tokenização de cartões;

- Reutilização de cartões tokenizados;

- Pagamento via meios disponibilizados pela Lyra;

- Controle de pagamentos pendentes;

- Nova tentativa de pagamento;

- Histórico das transações;

- Controle de cancelamento;

- Solicitação e aprovação de reembolso;

- Solicitação de estorno;

- Atualização dos status;

- Integração com ERP VIRBAC;

- Integração com API da AGV;

- Tela de acompanhamento da entrega;

- Controle da relação CEP × prazo de entrega.

O documento contratado também prevê estrutura de banco e telas administrativas para acompanhamento das transações financeiras e seus respectivos retornos.

=== Escopo Não incluso ===
Com base no documento fornecido, não devem ser considerados neste caso de uso:

- Definição das políticas de cancelamento pela CONTRATADA;

- Definição das políticas de devolução da entrega pela CONTRATADA;

- Desenvolvimento de um novo Gateway de Pagamento;

- Armazenamento dos dados sensíveis dos cartões;

- Criação de serviço próprio de Antifraude;

- Cálculo de valor de frete por CEP.

'''Ponto de atenção:''' o fluxograma enviado contém a etapa “Calcular opções e valor do frete”, porém o documento contratual da VIRBAC estabelece expressamente que, neste escopo, o frete será tratado como CEP × prazo de entrega, sem relação de CEP com valor de frete. Portanto, eu recomendaria alterar essa caixa do fluxograma para “Consultar prazo de entrega conforme CEP” para manter o diagrama coerente com o documento contratado.

== Documentos Relacionados ==

== Regras de Negócios ==

'''[RN1] - '''

'''[RN2] - '''

'''[RN3] - '''

== Regras de Integração ==

'''[RI1] - '''

'''[RI2] - '''

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

{| class="wikitable"
! Setor
! Aprovado Por
! Data

|-
| Desenvolvimento - GeoSales || Pessoa que aprovou || 00/00/0000
|-
| Integração - GeoSales || Pessoa que aprovou || 00/00/0000
|-
| Configurações - GeoSales || Pessoa que aprovou || 00/00/0000
|-
|}

=== Empresa solicitante ===

{| class="wikitable"
! 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 ||
|-
|}

Caso de Uso – Pagamento Online no B2B EVO para Veterinários

2026-10-30T18:10:05Z

Renatolima: /* Implementação */

== Histórico de Alterações ==
{| class="wikitable"
! Data
! Quem
! Comentários
|-
| 28/10/2026 || Renato Lima || Criação do documento
|-
|}

== Necessidade ==
A VIRBAC necessita disponibilizar uma experiência de compra digital por meio de uma plataforma B2V (Business-to-Vet), permitindo que o médico veterinário, após realizar seu cadastro, validação e login, possa consultar o catálogo autorizado, visualizar os preços conforme sua classificação comercial, realizar pedidos, efetuar pagamentos e acompanhar o status de faturamento e entrega.

Para o processo de pagamento, o B2B EVO deverá integrar-se à API da Lyra, permitindo o processamento das transações financeiras e a utilização dos meios de pagamento disponibilizados pelo parceiro.

Para pagamentos com cartão de crédito, deverá ser implementada a tokenização, permitindo a reutilização do cartão em compras futuras sem que os dados sensíveis sejam armazenados pelo B2B EVO.

O processo também deverá contemplar Antifraude, com análise das transações antes da autorização definitiva do pagamento.

Além do pagamento, deverá existir controle da jornada financeira da transação, incluindo pagamentos pendentes, novas tentativas, histórico, cancelamentos, reembolsos, aprovações e respectivos status.

O fluxo deverá ainda contemplar o acompanhamento da entrega, utilizando as informações disponibilizadas pela API da AGV, considerando a relação CEP × prazo de entrega definida pela contratante.

== Solução ==
Será desenvolvido no B2B EVO o fluxo integrado de compra e pagamento para veterinários, utilizando a API da Lyra para processamento das transações financeiras e Antifraude.

O fluxo será iniciado após a seleção dos produtos e confirmação do endereço de entrega. O sistema deverá utilizar o CEP do endereço para disponibilizar as informações relacionadas ao prazo de entrega.

Após a definição da forma de pagamento, o sistema encaminhará a transação para o fluxo correspondente:

'''- Cartão de crédito:''' verificar existência de token previamente armazenado;

'''- Novo cartão:''' realizar o processo de tokenização através da Lyra e armazenar somente o token;

'''- PIX:''' encaminhar os dados necessários para processamento da transação;

'''- Antifraude:''' submeter a transação à análise antes da autorização definitiva;

'''- Pagamento aprovado:''' registrar a transação, atualizar o pedido e prosseguir com o envio ao ERP;

'''- Pagamento recusado ou pendente:''' registrar a ocorrência e disponibilizar nova tentativa de pagamento.

A solução também contemplará o controle de cancelamentos e reembolsos diretamente no B2B EVO. As solicitações de reembolso deverão registrar o motivo e passar pela aprovação dos responsáveis do Financeiro e/ou Comercial, antes do envio da solicitação de estorno à Lyra.

O acompanhamento da entrega será realizado por meio de tela específica no B2B EVO, utilizando as informações retornadas pela integração com a API da AGV, parceira logística da VIRBAC.

== Implementação ==
A implementação será composta pelos seguintes componentes:

'''Fluxo de compra'''

- Acesso do veterinário ao Portal B2B;

- Seleção dos produtos;

- Confirmação do endereço de entrega;

- Identificação do CEP;

- Consulta das informações de prazo de entrega;

- Confirmação do pedido;

- Seleção da forma de pagamento.

'''Pagamento'''

- Integração B2B EVO × API Lyra;

- Processamento de cartão de crédito;

- Processamento de PIX;

- Tokenização de cartão;

- Armazenamento do token;

- Reutilização do cartão tokenizado;

- Registro das transações;

- Tratamento de pagamentos aprovados, recusados e pendentes.

'''Antifraude'''

- Envio da transação para análise;

- Recebimento do resultado da análise;

- Tratamento de transação aprovada;

- Tratamento de transação recusada;

- Tratamento de transação direcionada para análise adicional;

- Registro do resultado da análise.

O documento define que o resultado do Antifraude poderá determinar a aprovação, recusa ou encaminhamento da transação para análise adicional, conforme as regras do parceiro.

'''Controle financeiro'''

Será criada estrutura específica para gerenciamento das transações, contemplando:

- Pagamentos;

- Análises antifraude;

- Pagamentos pendentes;

- Novas tentativas;

- Cancelamentos;

- Reembolsos;

- Histórico das movimentações;

- Status das transações.

'''Cancelamento e reembolso'''

O B2B EVO será responsável por centralizar o controle do processo de cancelamento.

Para pedidos que necessitem de reembolso:

1. Solicitação de reembolso;

2. Registro do motivo;

3. Análise pelo Financeiro e/ou Comercial;

4. Aprovação ou reprovação;

5. Envio da solicitação de estorno à Lyra;
6. Recebimento da confirmação;

7. Atualização do histórico;

8. Atualização dos sistemas envolvidos.

A definição e validação das políticas de cancelamento de pagamento e das políticas de cancelamento/devolução da entrega são de responsabilidade da contratante.

'''Entrega e logística'''

Será desenvolvida uma tela para acompanhamento do status da entrega.

As informações serão obtidas através da integração com a API da AGV, permitindo que o B2B EVO apresente as fases de andamento da entrega ao veterinário.

== Atores ==
{| class="wikitable"
! Ator
! Responsabilidade
|-
| '''Veterinário''' || Realizar cadastro, acessar o B2B EVO, selecionar produtos, realizar pedidos, efetuar pagamentos e acompanhar a entrega.
|-
| '''B2B EVO''' || Centralizar o fluxo de compra, pagamento, cancelamento, reembolso e acompanhamento da entrega.
|-
| '''Lyra''' || Processar pagamentos, tokenização e Antifraude por meio de suas APIs.
|-
| '''Financeiro''' || Analisar e aprovar/reprovar solicitações de reembolso quando aplicável.
|-
| '''Comercial''' || Analisar e aprovar/reprovar solicitações de reembolso quando aplicável.
|-
| '''ERP VIRBAC''' || Receber e atualizar as informações relacionadas aos pedidos.
|-
| '''AGV''' || Disponibilizar informações relacionadas ao andamento da entrega por meio de API.
|-
|}

== Pré-condições ==
- O veterinário deve estar cadastrado e validado.

- O veterinário deve possuir acesso ao B2B EVO.

- O catálogo autorizado deve estar disponível.

- Os preços aplicáveis à classificação comercial do veterinário devem estar configurados.

- O endereço de entrega deve estar cadastrado.

- O CEP do endereço deve estar disponível para utilização no fluxo logístico.

- A integração com a API da Lyra deve estar disponível.

- A integração com o serviço de Antifraude deve estar disponível.

- A integração com a API da AGV deve estar disponível para acompanhamento da entrega.

- As regras de cancelamento e reembolso devem estar definidas e validadas pela VIRBAC.

== Escopo ==
=== Escopo incluso ===
- Integração com a API da Lyra;

- Integração com Antifraude;

- Tokenização de cartões;

- Reutilização de cartões tokenizados;

- Pagamento via meios disponibilizados pela Lyra;

- Controle de pagamentos pendentes;

- Nova tentativa de pagamento;

- Histórico das transações;

- Controle de cancelamento;

- Solicitação e aprovação de reembolso;

- Solicitação de estorno;

- Atualização dos status;

- Integração com ERP VIRBAC;

- Integração com API da AGV;

- Tela de acompanhamento da entrega;

- Controle da relação CEP × prazo de entrega.

O documento contratado também prevê estrutura de banco e telas administrativas para acompanhamento das transações financeiras e seus respectivos retornos.

=== Escopo Não incluso ===
Com base no documento fornecido, não devem ser considerados neste caso de uso:

- Definição das políticas de cancelamento pela CONTRATADA;

- Definição das políticas de devolução da entrega pela CONTRATADA;

- Desenvolvimento de um novo Gateway de Pagamento;

- Armazenamento dos dados sensíveis dos cartões;

- Criação de serviço próprio de Antifraude;

- Cálculo de valor de frete por CEP.

'''Ponto de atenção:''' o fluxograma enviado contém a etapa “Calcular opções e valor do frete”, porém o documento contratual da VIRBAC estabelece expressamente que, neste escopo, o frete será tratado como CEP × prazo de entrega, sem relação de CEP com valor de frete. Portanto, eu recomendaria alterar essa caixa do fluxograma para “Consultar prazo de entrega conforme CEP” para manter o diagrama coerente com o documento contratado.

== Documentos Relacionados ==

== Regras de Negócios ==

'''[RN1] - '''

'''[RN2] - '''

'''[RN3] - '''

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

{| class="wikitable"
! Setor
! Aprovado Por
! Data

|-
| Desenvolvimento - GeoSales || Pessoa que aprovou || 00/00/0000
|-
| Integração - GeoSales || Pessoa que aprovou || 00/00/0000
|-
| Configurações - GeoSales || Pessoa que aprovou || 00/00/0000
|-
|}

=== Empresa solicitante ===

{| class="wikitable"
! 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 ||
|-
|}

Caso de Uso – Pagamento Online no B2B EVO para Veterinários

2026-10-30T18:09:23Z

Renatolima: /* Solução */

== Histórico de Alterações ==
{| class="wikitable"
! Data
! Quem
! Comentários
|-
| 28/10/2026 || Renato Lima || Criação do documento
|-
|}

== Necessidade ==
A VIRBAC necessita disponibilizar uma experiência de compra digital por meio de uma plataforma B2V (Business-to-Vet), permitindo que o médico veterinário, após realizar seu cadastro, validação e login, possa consultar o catálogo autorizado, visualizar os preços conforme sua classificação comercial, realizar pedidos, efetuar pagamentos e acompanhar o status de faturamento e entrega.

Para o processo de pagamento, o B2B EVO deverá integrar-se à API da Lyra, permitindo o processamento das transações financeiras e a utilização dos meios de pagamento disponibilizados pelo parceiro.

Para pagamentos com cartão de crédito, deverá ser implementada a tokenização, permitindo a reutilização do cartão em compras futuras sem que os dados sensíveis sejam armazenados pelo B2B EVO.

O processo também deverá contemplar Antifraude, com análise das transações antes da autorização definitiva do pagamento.

Além do pagamento, deverá existir controle da jornada financeira da transação, incluindo pagamentos pendentes, novas tentativas, histórico, cancelamentos, reembolsos, aprovações e respectivos status.

O fluxo deverá ainda contemplar o acompanhamento da entrega, utilizando as informações disponibilizadas pela API da AGV, considerando a relação CEP × prazo de entrega definida pela contratante.

== Solução ==
Será desenvolvido no B2B EVO o fluxo integrado de compra e pagamento para veterinários, utilizando a API da Lyra para processamento das transações financeiras e Antifraude.

O fluxo será iniciado após a seleção dos produtos e confirmação do endereço de entrega. O sistema deverá utilizar o CEP do endereço para disponibilizar as informações relacionadas ao prazo de entrega.

Após a definição da forma de pagamento, o sistema encaminhará a transação para o fluxo correspondente:

'''- Cartão de crédito:''' verificar existência de token previamente armazenado;

'''- Novo cartão:''' realizar o processo de tokenização através da Lyra e armazenar somente o token;

'''- PIX:''' encaminhar os dados necessários para processamento da transação;

'''- Antifraude:''' submeter a transação à análise antes da autorização definitiva;

'''- Pagamento aprovado:''' registrar a transação, atualizar o pedido e prosseguir com o envio ao ERP;

'''- Pagamento recusado ou pendente:''' registrar a ocorrência e disponibilizar nova tentativa de pagamento.

A solução também contemplará o controle de cancelamentos e reembolsos diretamente no B2B EVO. As solicitações de reembolso deverão registrar o motivo e passar pela aprovação dos responsáveis do Financeiro e/ou Comercial, antes do envio da solicitação de estorno à Lyra.

O acompanhamento da entrega será realizado por meio de tela específica no B2B EVO, utilizando as informações retornadas pela integração com a API da AGV, parceira logística da VIRBAC.

== Implementação ==
A implementação será composta pelos seguintes componentes:

'''Fluxo de compra'''

- Acesso do veterinário ao Portal B2B;

- Seleção dos produtos;

- Confirmação do endereço de entrega;

- Identificação do CEP;

- Consulta das informações de prazo de entrega;

- Confirmação do pedido;

- Seleção da forma de pagamento.

'''Pagamento'''

- Integração B2B EVO × API Lyra;

- Processamento de cartão de crédito;

- Processamento de PIX;

- Tokenização de cartão;

- Armazenamento do token;

- Reutilização do cartão tokenizado;

- Registro das transações;

- Tratamento de pagamentos aprovados, recusados e pendentes.

'''Antifraude'''

- Envio da transação para análise;

- Recebimento do resultado da análise;

- Tratamento de transação aprovada;

- Tratamento de transação recusada;

- Tratamento de transação direcionada para análise adicional;

- Registro do resultado da análise.
O documento define que o resultado do Antifraude poderá determinar a aprovação, recusa ou encaminhamento da transação para análise adicional, conforme as regras do parceiro.

'''Controle financeiro'''

Será criada estrutura específica para gerenciamento das transações, contemplando:

- Pagamentos;

- Análises antifraude;

- Pagamentos pendentes;

- Novas tentativas;

- Cancelamentos;

- Reembolsos;

- Histórico das movimentações;

- Status das transações.

'''Cancelamento e reembolso'''

O B2B EVO será responsável por centralizar o controle do processo de cancelamento.

Para pedidos que necessitem de reembolso:

1. Solicitação de reembolso;

2. Registro do motivo;

3. Análise pelo Financeiro e/ou Comercial;

4. Aprovação ou reprovação;

5. Envio da solicitação de estorno à Lyra;
6. Recebimento da confirmação;

7. Atualização do histórico;

8. Atualização dos sistemas envolvidos.

A definição e validação das políticas de cancelamento de pagamento e das políticas de cancelamento/devolução da entrega são de responsabilidade da contratante.

'''Entrega e logística'''

Será desenvolvida uma tela para acompanhamento do status da entrega.

As informações serão obtidas através da integração com a API da AGV, permitindo que o B2B EVO apresente as fases de andamento da entrega ao veterinário.

== Atores ==
{| class="wikitable"
! Ator
! Responsabilidade
|-
| '''Veterinário''' || Realizar cadastro, acessar o B2B EVO, selecionar produtos, realizar pedidos, efetuar pagamentos e acompanhar a entrega.
|-
| '''B2B EVO''' || Centralizar o fluxo de compra, pagamento, cancelamento, reembolso e acompanhamento da entrega.
|-
| '''Lyra''' || Processar pagamentos, tokenização e Antifraude por meio de suas APIs.
|-
| '''Financeiro''' || Analisar e aprovar/reprovar solicitações de reembolso quando aplicável.
|-
| '''Comercial''' || Analisar e aprovar/reprovar solicitações de reembolso quando aplicável.
|-
| '''ERP VIRBAC''' || Receber e atualizar as informações relacionadas aos pedidos.
|-
| '''AGV''' || Disponibilizar informações relacionadas ao andamento da entrega por meio de API.
|-
|}

== Pré-condições ==
- O veterinário deve estar cadastrado e validado.

- O veterinário deve possuir acesso ao B2B EVO.

- O catálogo autorizado deve estar disponível.

- Os preços aplicáveis à classificação comercial do veterinário devem estar configurados.

- O endereço de entrega deve estar cadastrado.

- O CEP do endereço deve estar disponível para utilização no fluxo logístico.

- A integração com a API da Lyra deve estar disponível.

- A integração com o serviço de Antifraude deve estar disponível.

- A integração com a API da AGV deve estar disponível para acompanhamento da entrega.

- As regras de cancelamento e reembolso devem estar definidas e validadas pela VIRBAC.

== Escopo ==
=== Escopo incluso ===
- Integração com a API da Lyra;

- Integração com Antifraude;

- Tokenização de cartões;

- Reutilização de cartões tokenizados;

- Pagamento via meios disponibilizados pela Lyra;

- Controle de pagamentos pendentes;

- Nova tentativa de pagamento;

- Histórico das transações;

- Controle de cancelamento;

- Solicitação e aprovação de reembolso;

- Solicitação de estorno;

- Atualização dos status;

- Integração com ERP VIRBAC;

- Integração com API da AGV;

- Tela de acompanhamento da entrega;

- Controle da relação CEP × prazo de entrega.

O documento contratado também prevê estrutura de banco e telas administrativas para acompanhamento das transações financeiras e seus respectivos retornos.

=== Escopo Não incluso ===
Com base no documento fornecido, não devem ser considerados neste caso de uso:

- Definição das políticas de cancelamento pela CONTRATADA;

- Definição das políticas de devolução da entrega pela CONTRATADA;

- Desenvolvimento de um novo Gateway de Pagamento;

- Armazenamento dos dados sensíveis dos cartões;

- Criação de serviço próprio de Antifraude;

- Cálculo de valor de frete por CEP.

'''Ponto de atenção:''' o fluxograma enviado contém a etapa “Calcular opções e valor do frete”, porém o documento contratual da VIRBAC estabelece expressamente que, neste escopo, o frete será tratado como CEP × prazo de entrega, sem relação de CEP com valor de frete. Portanto, eu recomendaria alterar essa caixa do fluxograma para “Consultar prazo de entrega conforme CEP” para manter o diagrama coerente com o documento contratado.

== Documentos Relacionados ==

== Regras de Negócios ==

'''[RN1] - '''

'''[RN2] - '''

'''[RN3] - '''

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

{| class="wikitable"
! Setor
! Aprovado Por
! Data

|-
| Desenvolvimento - GeoSales || Pessoa que aprovou || 00/00/0000
|-
| Integração - GeoSales || Pessoa que aprovou || 00/00/0000
|-
| Configurações - GeoSales || Pessoa que aprovou || 00/00/0000
|-
|}

=== Empresa solicitante ===

{| class="wikitable"
! 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 ||
|-
|}

Caso de Uso – Pagamento Online no B2B EVO para Veterinários

2026-10-30T17:55:49Z

Renatolima: /* Pré-condições */

== Histórico de Alterações ==
{| class="wikitable"
! Data
! Quem
! Comentários
|-
| 28/10/2026 || Renato Lima || Criação do documento
|-
|}

== Necessidade ==
A VIRBAC necessita disponibilizar uma experiência de compra digital por meio de uma plataforma B2V (Business-to-Vet), permitindo que o médico veterinário, após realizar seu cadastro, validação e login, possa consultar o catálogo autorizado, visualizar os preços conforme sua classificação comercial, realizar pedidos, efetuar pagamentos e acompanhar o status de faturamento e entrega.

Para o processo de pagamento, o B2B EVO deverá integrar-se à API da Lyra, permitindo o processamento das transações financeiras e a utilização dos meios de pagamento disponibilizados pelo parceiro.

Para pagamentos com cartão de crédito, deverá ser implementada a tokenização, permitindo a reutilização do cartão em compras futuras sem que os dados sensíveis sejam armazenados pelo B2B EVO.

O processo também deverá contemplar Antifraude, com análise das transações antes da autorização definitiva do pagamento.

Além do pagamento, deverá existir controle da jornada financeira da transação, incluindo pagamentos pendentes, novas tentativas, histórico, cancelamentos, reembolsos, aprovações e respectivos status.

O fluxo deverá ainda contemplar o acompanhamento da entrega, utilizando as informações disponibilizadas pela API da AGV, considerando a relação CEP × prazo de entrega definida pela contratante.

== Solução ==
Será desenvolvido no B2B EVO o fluxo integrado de compra e pagamento para veterinários, utilizando a API da Lyra para processamento das transações financeiras e Antifraude.

O fluxo será iniciado após a seleção dos produtos e confirmação do endereço de entrega. O sistema deverá utilizar o CEP do endereço para disponibilizar as informações relacionadas ao prazo de entrega.

Após a definição da forma de pagamento, o sistema encaminhará a transação para o fluxo correspondente:
'''- Cartão de crédito:''' verificar existência de token previamente armazenado;
'''- Novo cartão:''' realizar o processo de tokenização através da Lyra e armazenar somente o token;
'''- PIX:''' encaminhar os dados necessários para processamento da transação;
'''- Antifraude:''' submeter a transação à análise antes da autorização definitiva;
'''- Pagamento aprovado:''' registrar a transação, atualizar o pedido e prosseguir com o envio ao ERP;
'''- Pagamento recusado ou pendente:''' registrar a ocorrência e disponibilizar nova tentativa de pagamento.
A solução também contemplará o controle de cancelamentos e reembolsos diretamente no B2B EVO. As solicitações de reembolso deverão registrar o motivo e passar pela aprovação dos responsáveis do Financeiro e/ou Comercial, antes do envio da solicitação de estorno à Lyra.

O acompanhamento da entrega será realizado por meio de tela específica no B2B EVO, utilizando as informações retornadas pela integração com a API da AGV, parceira logística da VIRBAC.

== Implementação ==
A implementação será composta pelos seguintes componentes:

'''Fluxo de compra'''

- Acesso do veterinário ao Portal B2B;

- Seleção dos produtos;

- Confirmação do endereço de entrega;

- Identificação do CEP;

- Consulta das informações de prazo de entrega;

- Confirmação do pedido;

- Seleção da forma de pagamento.

'''Pagamento'''

- Integração B2B EVO × API Lyra;

- Processamento de cartão de crédito;

- Processamento de PIX;

- Tokenização de cartão;

- Armazenamento do token;

- Reutilização do cartão tokenizado;

- Registro das transações;

- Tratamento de pagamentos aprovados, recusados e pendentes.

'''Antifraude'''

- Envio da transação para análise;

- Recebimento do resultado da análise;

- Tratamento de transação aprovada;

- Tratamento de transação recusada;

- Tratamento de transação direcionada para análise adicional;

- Registro do resultado da análise.
O documento define que o resultado do Antifraude poderá determinar a aprovação, recusa ou encaminhamento da transação para análise adicional, conforme as regras do parceiro.

'''Controle financeiro'''

Será criada estrutura específica para gerenciamento das transações, contemplando:

- Pagamentos;

- Análises antifraude;

- Pagamentos pendentes;

- Novas tentativas;

- Cancelamentos;

- Reembolsos;

- Histórico das movimentações;

- Status das transações.

'''Cancelamento e reembolso'''

O B2B EVO será responsável por centralizar o controle do processo de cancelamento.

Para pedidos que necessitem de reembolso:

1. Solicitação de reembolso;

2. Registro do motivo;

3. Análise pelo Financeiro e/ou Comercial;

4. Aprovação ou reprovação;

5. Envio da solicitação de estorno à Lyra;
6. Recebimento da confirmação;

7. Atualização do histórico;

8. Atualização dos sistemas envolvidos.

A definição e validação das políticas de cancelamento de pagamento e das políticas de cancelamento/devolução da entrega são de responsabilidade da contratante.

'''Entrega e logística'''

Será desenvolvida uma tela para acompanhamento do status da entrega.

As informações serão obtidas através da integração com a API da AGV, permitindo que o B2B EVO apresente as fases de andamento da entrega ao veterinário.

== Atores ==
{| class="wikitable"
! Ator
! Responsabilidade
|-
| '''Veterinário''' || Realizar cadastro, acessar o B2B EVO, selecionar produtos, realizar pedidos, efetuar pagamentos e acompanhar a entrega.
|-
| '''B2B EVO''' || Centralizar o fluxo de compra, pagamento, cancelamento, reembolso e acompanhamento da entrega.
|-
| '''Lyra''' || Processar pagamentos, tokenização e Antifraude por meio de suas APIs.
|-
| '''Financeiro''' || Analisar e aprovar/reprovar solicitações de reembolso quando aplicável.
|-
| '''Comercial''' || Analisar e aprovar/reprovar solicitações de reembolso quando aplicável.
|-
| '''ERP VIRBAC''' || Receber e atualizar as informações relacionadas aos pedidos.
|-
| '''AGV''' || Disponibilizar informações relacionadas ao andamento da entrega por meio de API.
|-
|}

== Pré-condições ==
- O veterinário deve estar cadastrado e validado.

- O veterinário deve possuir acesso ao B2B EVO.

- O catálogo autorizado deve estar disponível.

- Os preços aplicáveis à classificação comercial do veterinário devem estar configurados.

- O endereço de entrega deve estar cadastrado.

- O CEP do endereço deve estar disponível para utilização no fluxo logístico.

- A integração com a API da Lyra deve estar disponível.

- A integração com o serviço de Antifraude deve estar disponível.

- A integração com a API da AGV deve estar disponível para acompanhamento da entrega.

- As regras de cancelamento e reembolso devem estar definidas e validadas pela VIRBAC.

== Escopo ==
=== Escopo incluso ===
- Integração com a API da Lyra;

- Integração com Antifraude;

- Tokenização de cartões;

- Reutilização de cartões tokenizados;

- Pagamento via meios disponibilizados pela Lyra;

- Controle de pagamentos pendentes;

- Nova tentativa de pagamento;

- Histórico das transações;

- Controle de cancelamento;

- Solicitação e aprovação de reembolso;

- Solicitação de estorno;

- Atualização dos status;

- Integração com ERP VIRBAC;

- Integração com API da AGV;

- Tela de acompanhamento da entrega;

- Controle da relação CEP × prazo de entrega.

O documento contratado também prevê estrutura de banco e telas administrativas para acompanhamento das transações financeiras e seus respectivos retornos.

=== Escopo Não incluso ===
Com base no documento fornecido, não devem ser considerados neste caso de uso:

- Definição das políticas de cancelamento pela CONTRATADA;

- Definição das políticas de devolução da entrega pela CONTRATADA;

- Desenvolvimento de um novo Gateway de Pagamento;

- Armazenamento dos dados sensíveis dos cartões;

- Criação de serviço próprio de Antifraude;

- Cálculo de valor de frete por CEP.

'''Ponto de atenção:''' o fluxograma enviado contém a etapa “Calcular opções e valor do frete”, porém o documento contratual da VIRBAC estabelece expressamente que, neste escopo, o frete será tratado como CEP × prazo de entrega, sem relação de CEP com valor de frete. Portanto, eu recomendaria alterar essa caixa do fluxograma para “Consultar prazo de entrega conforme CEP” para manter o diagrama coerente com o documento contratado.

== Documentos Relacionados ==

== Regras de Negócios ==

'''[RN1] - '''

'''[RN2] - '''

'''[RN3] - '''

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

{| class="wikitable"
! Setor
! Aprovado Por
! Data

|-
| Desenvolvimento - GeoSales || Pessoa que aprovou || 00/00/0000
|-
| Integração - GeoSales || Pessoa que aprovou || 00/00/0000
|-
| Configurações - GeoSales || Pessoa que aprovou || 00/00/0000
|-
|}

=== Empresa solicitante ===

{| class="wikitable"
! 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 ||
|-
|}

Caso de Uso – Pagamento Online no B2B EVO para Veterinários

2026-10-30T17:54:56Z

Renatolima: /* Escopo Não incluso */

== Histórico de Alterações ==
{| class="wikitable"
! Data
! Quem
! Comentários
|-
| 28/10/2026 || Renato Lima || Criação do documento
|-
|}

== Necessidade ==
A VIRBAC necessita disponibilizar uma experiência de compra digital por meio de uma plataforma B2V (Business-to-Vet), permitindo que o médico veterinário, após realizar seu cadastro, validação e login, possa consultar o catálogo autorizado, visualizar os preços conforme sua classificação comercial, realizar pedidos, efetuar pagamentos e acompanhar o status de faturamento e entrega.

Para o processo de pagamento, o B2B EVO deverá integrar-se à API da Lyra, permitindo o processamento das transações financeiras e a utilização dos meios de pagamento disponibilizados pelo parceiro.

Para pagamentos com cartão de crédito, deverá ser implementada a tokenização, permitindo a reutilização do cartão em compras futuras sem que os dados sensíveis sejam armazenados pelo B2B EVO.

O processo também deverá contemplar Antifraude, com análise das transações antes da autorização definitiva do pagamento.

Além do pagamento, deverá existir controle da jornada financeira da transação, incluindo pagamentos pendentes, novas tentativas, histórico, cancelamentos, reembolsos, aprovações e respectivos status.

O fluxo deverá ainda contemplar o acompanhamento da entrega, utilizando as informações disponibilizadas pela API da AGV, considerando a relação CEP × prazo de entrega definida pela contratante.

== Solução ==
Será desenvolvido no B2B EVO o fluxo integrado de compra e pagamento para veterinários, utilizando a API da Lyra para processamento das transações financeiras e Antifraude.

O fluxo será iniciado após a seleção dos produtos e confirmação do endereço de entrega. O sistema deverá utilizar o CEP do endereço para disponibilizar as informações relacionadas ao prazo de entrega.

Após a definição da forma de pagamento, o sistema encaminhará a transação para o fluxo correspondente:
'''- Cartão de crédito:''' verificar existência de token previamente armazenado;
'''- Novo cartão:''' realizar o processo de tokenização através da Lyra e armazenar somente o token;
'''- PIX:''' encaminhar os dados necessários para processamento da transação;
'''- Antifraude:''' submeter a transação à análise antes da autorização definitiva;
'''- Pagamento aprovado:''' registrar a transação, atualizar o pedido e prosseguir com o envio ao ERP;
'''- Pagamento recusado ou pendente:''' registrar a ocorrência e disponibilizar nova tentativa de pagamento.
A solução também contemplará o controle de cancelamentos e reembolsos diretamente no B2B EVO. As solicitações de reembolso deverão registrar o motivo e passar pela aprovação dos responsáveis do Financeiro e/ou Comercial, antes do envio da solicitação de estorno à Lyra.

O acompanhamento da entrega será realizado por meio de tela específica no B2B EVO, utilizando as informações retornadas pela integração com a API da AGV, parceira logística da VIRBAC.

== Implementação ==
A implementação será composta pelos seguintes componentes:

'''Fluxo de compra'''

- Acesso do veterinário ao Portal B2B;

- Seleção dos produtos;

- Confirmação do endereço de entrega;

- Identificação do CEP;

- Consulta das informações de prazo de entrega;

- Confirmação do pedido;

- Seleção da forma de pagamento.

'''Pagamento'''

- Integração B2B EVO × API Lyra;

- Processamento de cartão de crédito;

- Processamento de PIX;

- Tokenização de cartão;

- Armazenamento do token;

- Reutilização do cartão tokenizado;

- Registro das transações;

- Tratamento de pagamentos aprovados, recusados e pendentes.

'''Antifraude'''

- Envio da transação para análise;

- Recebimento do resultado da análise;

- Tratamento de transação aprovada;

- Tratamento de transação recusada;

- Tratamento de transação direcionada para análise adicional;

- Registro do resultado da análise.
O documento define que o resultado do Antifraude poderá determinar a aprovação, recusa ou encaminhamento da transação para análise adicional, conforme as regras do parceiro.

'''Controle financeiro'''

Será criada estrutura específica para gerenciamento das transações, contemplando:

- Pagamentos;

- Análises antifraude;

- Pagamentos pendentes;

- Novas tentativas;

- Cancelamentos;

- Reembolsos;

- Histórico das movimentações;

- Status das transações.

'''Cancelamento e reembolso'''

O B2B EVO será responsável por centralizar o controle do processo de cancelamento.

Para pedidos que necessitem de reembolso:

1. Solicitação de reembolso;

2. Registro do motivo;

3. Análise pelo Financeiro e/ou Comercial;

4. Aprovação ou reprovação;

5. Envio da solicitação de estorno à Lyra;
6. Recebimento da confirmação;

7. Atualização do histórico;

8. Atualização dos sistemas envolvidos.

A definição e validação das políticas de cancelamento de pagamento e das políticas de cancelamento/devolução da entrega são de responsabilidade da contratante.

'''Entrega e logística'''

Será desenvolvida uma tela para acompanhamento do status da entrega.

As informações serão obtidas através da integração com a API da AGV, permitindo que o B2B EVO apresente as fases de andamento da entrega ao veterinário.

== Atores ==
{| class="wikitable"
! Ator
! Responsabilidade
|-
| '''Veterinário''' || Realizar cadastro, acessar o B2B EVO, selecionar produtos, realizar pedidos, efetuar pagamentos e acompanhar a entrega.
|-
| '''B2B EVO''' || Centralizar o fluxo de compra, pagamento, cancelamento, reembolso e acompanhamento da entrega.
|-
| '''Lyra''' || Processar pagamentos, tokenização e Antifraude por meio de suas APIs.
|-
| '''Financeiro''' || Analisar e aprovar/reprovar solicitações de reembolso quando aplicável.
|-
| '''Comercial''' || Analisar e aprovar/reprovar solicitações de reembolso quando aplicável.
|-
| '''ERP VIRBAC''' || Receber e atualizar as informações relacionadas aos pedidos.
|-
| '''AGV''' || Disponibilizar informações relacionadas ao andamento da entrega por meio de API.
|-
|}

== Pré-condições ==
O veterinário deve estar cadastrado e validado.
O veterinário deve possuir acesso ao B2B EVO.
O catálogo autorizado deve estar disponível.
Os preços aplicáveis à classificação comercial do veterinário devem estar configurados.
O endereço de entrega deve estar cadastrado.
O CEP do endereço deve estar disponível para utilização no fluxo logístico.
A integração com a API da Lyra deve estar disponível.
A integração com o serviço de Antifraude deve estar disponível.
A integração com a API da AGV deve estar disponível para acompanhamento da entrega.
As regras de cancelamento e reembolso devem estar definidas e validadas pela VIRBAC.
== Escopo ==
=== Escopo incluso ===
- Integração com a API da Lyra;

- Integração com Antifraude;

- Tokenização de cartões;

- Reutilização de cartões tokenizados;

- Pagamento via meios disponibilizados pela Lyra;

- Controle de pagamentos pendentes;

- Nova tentativa de pagamento;

- Histórico das transações;

- Controle de cancelamento;

- Solicitação e aprovação de reembolso;

- Solicitação de estorno;

- Atualização dos status;

- Integração com ERP VIRBAC;

- Integração com API da AGV;

- Tela de acompanhamento da entrega;

- Controle da relação CEP × prazo de entrega.

O documento contratado também prevê estrutura de banco e telas administrativas para acompanhamento das transações financeiras e seus respectivos retornos.

=== Escopo Não incluso ===
Com base no documento fornecido, não devem ser considerados neste caso de uso:

- Definição das políticas de cancelamento pela CONTRATADA;

- Definição das políticas de devolução da entrega pela CONTRATADA;

- Desenvolvimento de um novo Gateway de Pagamento;

- Armazenamento dos dados sensíveis dos cartões;

- Criação de serviço próprio de Antifraude;

- Cálculo de valor de frete por CEP.

'''Ponto de atenção:''' o fluxograma enviado contém a etapa “Calcular opções e valor do frete”, porém o documento contratual da VIRBAC estabelece expressamente que, neste escopo, o frete será tratado como CEP × prazo de entrega, sem relação de CEP com valor de frete. Portanto, eu recomendaria alterar essa caixa do fluxograma para “Consultar prazo de entrega conforme CEP” para manter o diagrama coerente com o documento contratado.

== Documentos Relacionados ==

== Regras de Negócios ==

'''[RN1] - '''

'''[RN2] - '''

'''[RN3] - '''

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

{| class="wikitable"
! Setor
! Aprovado Por
! Data

|-
| Desenvolvimento - GeoSales || Pessoa que aprovou || 00/00/0000
|-
| Integração - GeoSales || Pessoa que aprovou || 00/00/0000
|-
| Configurações - GeoSales || Pessoa que aprovou || 00/00/0000
|-
|}

=== Empresa solicitante ===

{| class="wikitable"
! 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 ||
|-
|}

Caso de Uso – Pagamento Online no B2B EVO para Veterinários

2026-10-30T17:54:29Z

Renatolima: /* Escopo Não incluso */

== Histórico de Alterações ==
{| class="wikitable"
! Data
! Quem
! Comentários
|-
| 28/10/2026 || Renato Lima || Criação do documento
|-
|}

== Necessidade ==
A VIRBAC necessita disponibilizar uma experiência de compra digital por meio de uma plataforma B2V (Business-to-Vet), permitindo que o médico veterinário, após realizar seu cadastro, validação e login, possa consultar o catálogo autorizado, visualizar os preços conforme sua classificação comercial, realizar pedidos, efetuar pagamentos e acompanhar o status de faturamento e entrega.

Para o processo de pagamento, o B2B EVO deverá integrar-se à API da Lyra, permitindo o processamento das transações financeiras e a utilização dos meios de pagamento disponibilizados pelo parceiro.

Para pagamentos com cartão de crédito, deverá ser implementada a tokenização, permitindo a reutilização do cartão em compras futuras sem que os dados sensíveis sejam armazenados pelo B2B EVO.

O processo também deverá contemplar Antifraude, com análise das transações antes da autorização definitiva do pagamento.

Além do pagamento, deverá existir controle da jornada financeira da transação, incluindo pagamentos pendentes, novas tentativas, histórico, cancelamentos, reembolsos, aprovações e respectivos status.

O fluxo deverá ainda contemplar o acompanhamento da entrega, utilizando as informações disponibilizadas pela API da AGV, considerando a relação CEP × prazo de entrega definida pela contratante.

== Solução ==
Será desenvolvido no B2B EVO o fluxo integrado de compra e pagamento para veterinários, utilizando a API da Lyra para processamento das transações financeiras e Antifraude.

O fluxo será iniciado após a seleção dos produtos e confirmação do endereço de entrega. O sistema deverá utilizar o CEP do endereço para disponibilizar as informações relacionadas ao prazo de entrega.

Após a definição da forma de pagamento, o sistema encaminhará a transação para o fluxo correspondente:
'''- Cartão de crédito:''' verificar existência de token previamente armazenado;
'''- Novo cartão:''' realizar o processo de tokenização através da Lyra e armazenar somente o token;
'''- PIX:''' encaminhar os dados necessários para processamento da transação;
'''- Antifraude:''' submeter a transação à análise antes da autorização definitiva;
'''- Pagamento aprovado:''' registrar a transação, atualizar o pedido e prosseguir com o envio ao ERP;
'''- Pagamento recusado ou pendente:''' registrar a ocorrência e disponibilizar nova tentativa de pagamento.
A solução também contemplará o controle de cancelamentos e reembolsos diretamente no B2B EVO. As solicitações de reembolso deverão registrar o motivo e passar pela aprovação dos responsáveis do Financeiro e/ou Comercial, antes do envio da solicitação de estorno à Lyra.

O acompanhamento da entrega será realizado por meio de tela específica no B2B EVO, utilizando as informações retornadas pela integração com a API da AGV, parceira logística da VIRBAC.

== Implementação ==
A implementação será composta pelos seguintes componentes:

'''Fluxo de compra'''

- Acesso do veterinário ao Portal B2B;

- Seleção dos produtos;

- Confirmação do endereço de entrega;

- Identificação do CEP;

- Consulta das informações de prazo de entrega;

- Confirmação do pedido;

- Seleção da forma de pagamento.

'''Pagamento'''

- Integração B2B EVO × API Lyra;

- Processamento de cartão de crédito;

- Processamento de PIX;

- Tokenização de cartão;

- Armazenamento do token;

- Reutilização do cartão tokenizado;

- Registro das transações;

- Tratamento de pagamentos aprovados, recusados e pendentes.

'''Antifraude'''

- Envio da transação para análise;

- Recebimento do resultado da análise;

- Tratamento de transação aprovada;

- Tratamento de transação recusada;

- Tratamento de transação direcionada para análise adicional;

- Registro do resultado da análise.
O documento define que o resultado do Antifraude poderá determinar a aprovação, recusa ou encaminhamento da transação para análise adicional, conforme as regras do parceiro.

'''Controle financeiro'''

Será criada estrutura específica para gerenciamento das transações, contemplando:

- Pagamentos;

- Análises antifraude;

- Pagamentos pendentes;

- Novas tentativas;

- Cancelamentos;

- Reembolsos;

- Histórico das movimentações;

- Status das transações.

'''Cancelamento e reembolso'''

O B2B EVO será responsável por centralizar o controle do processo de cancelamento.

Para pedidos que necessitem de reembolso:

1. Solicitação de reembolso;

2. Registro do motivo;

3. Análise pelo Financeiro e/ou Comercial;

4. Aprovação ou reprovação;

5. Envio da solicitação de estorno à Lyra;
6. Recebimento da confirmação;

7. Atualização do histórico;

8. Atualização dos sistemas envolvidos.

A definição e validação das políticas de cancelamento de pagamento e das políticas de cancelamento/devolução da entrega são de responsabilidade da contratante.

'''Entrega e logística'''

Será desenvolvida uma tela para acompanhamento do status da entrega.

As informações serão obtidas através da integração com a API da AGV, permitindo que o B2B EVO apresente as fases de andamento da entrega ao veterinário.

== Atores ==
{| class="wikitable"
! Ator
! Responsabilidade
|-
| '''Veterinário''' || Realizar cadastro, acessar o B2B EVO, selecionar produtos, realizar pedidos, efetuar pagamentos e acompanhar a entrega.
|-
| '''B2B EVO''' || Centralizar o fluxo de compra, pagamento, cancelamento, reembolso e acompanhamento da entrega.
|-
| '''Lyra''' || Processar pagamentos, tokenização e Antifraude por meio de suas APIs.
|-
| '''Financeiro''' || Analisar e aprovar/reprovar solicitações de reembolso quando aplicável.
|-
| '''Comercial''' || Analisar e aprovar/reprovar solicitações de reembolso quando aplicável.
|-
| '''ERP VIRBAC''' || Receber e atualizar as informações relacionadas aos pedidos.
|-
| '''AGV''' || Disponibilizar informações relacionadas ao andamento da entrega por meio de API.
|-
|}

== Pré-condições ==
O veterinário deve estar cadastrado e validado.
O veterinário deve possuir acesso ao B2B EVO.
O catálogo autorizado deve estar disponível.
Os preços aplicáveis à classificação comercial do veterinário devem estar configurados.
O endereço de entrega deve estar cadastrado.
O CEP do endereço deve estar disponível para utilização no fluxo logístico.
A integração com a API da Lyra deve estar disponível.
A integração com o serviço de Antifraude deve estar disponível.
A integração com a API da AGV deve estar disponível para acompanhamento da entrega.
As regras de cancelamento e reembolso devem estar definidas e validadas pela VIRBAC.
== Escopo ==
=== Escopo incluso ===
- Integração com a API da Lyra;

- Integração com Antifraude;

- Tokenização de cartões;

- Reutilização de cartões tokenizados;

- Pagamento via meios disponibilizados pela Lyra;

- Controle de pagamentos pendentes;

- Nova tentativa de pagamento;

- Histórico das transações;

- Controle de cancelamento;

- Solicitação e aprovação de reembolso;

- Solicitação de estorno;

- Atualização dos status;

- Integração com ERP VIRBAC;

- Integração com API da AGV;

- Tela de acompanhamento da entrega;

- Controle da relação CEP × prazo de entrega.

O documento contratado também prevê estrutura de banco e telas administrativas para acompanhamento das transações financeiras e seus respectivos retornos.

=== Escopo Não incluso ===
Com base no documento fornecido, não devem ser considerados neste caso de uso:

- Definição das políticas de cancelamento pela CONTRATADA;

- Definição das políticas de devolução da entrega pela CONTRATADA;

- Desenvolvimento de um novo Gateway de Pagamento;

- Armazenamento dos dados sensíveis dos cartões;

- Criação de serviço próprio de Antifraude;

- Cálculo de valor de frete por CEP.

Ponto de atenção: o fluxograma enviado contém a etapa “Calcular opções e valor do frete”, porém o documento contratual da VIRBAC estabelece expressamente que, neste escopo, o frete será tratado como CEP × prazo de entrega, sem relação de CEP com valor de frete. Portanto, eu recomendaria alterar essa caixa do fluxograma para “Consultar prazo de entrega conforme CEP” para manter o diagrama coerente com o documento contratado.

== Documentos Relacionados ==

== Regras de Negócios ==

'''[RN1] - '''

'''[RN2] - '''

'''[RN3] - '''

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

{| class="wikitable"
! Setor
! Aprovado Por
! Data

|-
| Desenvolvimento - GeoSales || Pessoa que aprovou || 00/00/0000
|-
| Integração - GeoSales || Pessoa que aprovou || 00/00/0000
|-
| Configurações - GeoSales || Pessoa que aprovou || 00/00/0000
|-
|}

=== Empresa solicitante ===

{| class="wikitable"
! 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 ||
|-
|}

Caso de Uso – Pagamento Online no B2B EVO para Veterinários

2026-10-30T17:54:15Z

Renatolima: /* Escopo incluso */

== Histórico de Alterações ==
{| class="wikitable"
! Data
! Quem
! Comentários
|-
| 28/10/2026 || Renato Lima || Criação do documento
|-
|}

== Necessidade ==
A VIRBAC necessita disponibilizar uma experiência de compra digital por meio de uma plataforma B2V (Business-to-Vet), permitindo que o médico veterinário, após realizar seu cadastro, validação e login, possa consultar o catálogo autorizado, visualizar os preços conforme sua classificação comercial, realizar pedidos, efetuar pagamentos e acompanhar o status de faturamento e entrega.

Para o processo de pagamento, o B2B EVO deverá integrar-se à API da Lyra, permitindo o processamento das transações financeiras e a utilização dos meios de pagamento disponibilizados pelo parceiro.

Para pagamentos com cartão de crédito, deverá ser implementada a tokenização, permitindo a reutilização do cartão em compras futuras sem que os dados sensíveis sejam armazenados pelo B2B EVO.

O processo também deverá contemplar Antifraude, com análise das transações antes da autorização definitiva do pagamento.

Além do pagamento, deverá existir controle da jornada financeira da transação, incluindo pagamentos pendentes, novas tentativas, histórico, cancelamentos, reembolsos, aprovações e respectivos status.

O fluxo deverá ainda contemplar o acompanhamento da entrega, utilizando as informações disponibilizadas pela API da AGV, considerando a relação CEP × prazo de entrega definida pela contratante.

== Solução ==
Será desenvolvido no B2B EVO o fluxo integrado de compra e pagamento para veterinários, utilizando a API da Lyra para processamento das transações financeiras e Antifraude.

O fluxo será iniciado após a seleção dos produtos e confirmação do endereço de entrega. O sistema deverá utilizar o CEP do endereço para disponibilizar as informações relacionadas ao prazo de entrega.

Após a definição da forma de pagamento, o sistema encaminhará a transação para o fluxo correspondente:
'''- Cartão de crédito:''' verificar existência de token previamente armazenado;
'''- Novo cartão:''' realizar o processo de tokenização através da Lyra e armazenar somente o token;
'''- PIX:''' encaminhar os dados necessários para processamento da transação;
'''- Antifraude:''' submeter a transação à análise antes da autorização definitiva;
'''- Pagamento aprovado:''' registrar a transação, atualizar o pedido e prosseguir com o envio ao ERP;
'''- Pagamento recusado ou pendente:''' registrar a ocorrência e disponibilizar nova tentativa de pagamento.
A solução também contemplará o controle de cancelamentos e reembolsos diretamente no B2B EVO. As solicitações de reembolso deverão registrar o motivo e passar pela aprovação dos responsáveis do Financeiro e/ou Comercial, antes do envio da solicitação de estorno à Lyra.

O acompanhamento da entrega será realizado por meio de tela específica no B2B EVO, utilizando as informações retornadas pela integração com a API da AGV, parceira logística da VIRBAC.

== Implementação ==
A implementação será composta pelos seguintes componentes:

'''Fluxo de compra'''

- Acesso do veterinário ao Portal B2B;

- Seleção dos produtos;

- Confirmação do endereço de entrega;

- Identificação do CEP;

- Consulta das informações de prazo de entrega;

- Confirmação do pedido;

- Seleção da forma de pagamento.

'''Pagamento'''

- Integração B2B EVO × API Lyra;

- Processamento de cartão de crédito;

- Processamento de PIX;

- Tokenização de cartão;

- Armazenamento do token;

- Reutilização do cartão tokenizado;

- Registro das transações;

- Tratamento de pagamentos aprovados, recusados e pendentes.

'''Antifraude'''

- Envio da transação para análise;

- Recebimento do resultado da análise;

- Tratamento de transação aprovada;

- Tratamento de transação recusada;

- Tratamento de transação direcionada para análise adicional;

- Registro do resultado da análise.
O documento define que o resultado do Antifraude poderá determinar a aprovação, recusa ou encaminhamento da transação para análise adicional, conforme as regras do parceiro.

'''Controle financeiro'''

Será criada estrutura específica para gerenciamento das transações, contemplando:

- Pagamentos;

- Análises antifraude;

- Pagamentos pendentes;

- Novas tentativas;

- Cancelamentos;

- Reembolsos;

- Histórico das movimentações;

- Status das transações.

'''Cancelamento e reembolso'''

O B2B EVO será responsável por centralizar o controle do processo de cancelamento.

Para pedidos que necessitem de reembolso:

1. Solicitação de reembolso;

2. Registro do motivo;

3. Análise pelo Financeiro e/ou Comercial;

4. Aprovação ou reprovação;

5. Envio da solicitação de estorno à Lyra;
6. Recebimento da confirmação;

7. Atualização do histórico;

8. Atualização dos sistemas envolvidos.

A definição e validação das políticas de cancelamento de pagamento e das políticas de cancelamento/devolução da entrega são de responsabilidade da contratante.

'''Entrega e logística'''

Será desenvolvida uma tela para acompanhamento do status da entrega.

As informações serão obtidas através da integração com a API da AGV, permitindo que o B2B EVO apresente as fases de andamento da entrega ao veterinário.

== Atores ==
{| class="wikitable"
! Ator
! Responsabilidade
|-
| '''Veterinário''' || Realizar cadastro, acessar o B2B EVO, selecionar produtos, realizar pedidos, efetuar pagamentos e acompanhar a entrega.
|-
| '''B2B EVO''' || Centralizar o fluxo de compra, pagamento, cancelamento, reembolso e acompanhamento da entrega.
|-
| '''Lyra''' || Processar pagamentos, tokenização e Antifraude por meio de suas APIs.
|-
| '''Financeiro''' || Analisar e aprovar/reprovar solicitações de reembolso quando aplicável.
|-
| '''Comercial''' || Analisar e aprovar/reprovar solicitações de reembolso quando aplicável.
|-
| '''ERP VIRBAC''' || Receber e atualizar as informações relacionadas aos pedidos.
|-
| '''AGV''' || Disponibilizar informações relacionadas ao andamento da entrega por meio de API.
|-
|}

== Pré-condições ==
O veterinário deve estar cadastrado e validado.
O veterinário deve possuir acesso ao B2B EVO.
O catálogo autorizado deve estar disponível.
Os preços aplicáveis à classificação comercial do veterinário devem estar configurados.
O endereço de entrega deve estar cadastrado.
O CEP do endereço deve estar disponível para utilização no fluxo logístico.
A integração com a API da Lyra deve estar disponível.
A integração com o serviço de Antifraude deve estar disponível.
A integração com a API da AGV deve estar disponível para acompanhamento da entrega.
As regras de cancelamento e reembolso devem estar definidas e validadas pela VIRBAC.
== Escopo ==
=== Escopo incluso ===
- Integração com a API da Lyra;

- Integração com Antifraude;

- Tokenização de cartões;

- Reutilização de cartões tokenizados;

- Pagamento via meios disponibilizados pela Lyra;

- Controle de pagamentos pendentes;

- Nova tentativa de pagamento;

- Histórico das transações;

- Controle de cancelamento;

- Solicitação e aprovação de reembolso;

- Solicitação de estorno;

- Atualização dos status;

- Integração com ERP VIRBAC;

- Integração com API da AGV;

- Tela de acompanhamento da entrega;

- Controle da relação CEP × prazo de entrega.

O documento contratado também prevê estrutura de banco e telas administrativas para acompanhamento das transações financeiras e seus respectivos retornos.

=== Escopo Não incluso ===
Com base no documento fornecido, não devem ser considerados neste caso de uso:
- Definição das políticas de cancelamento pela CONTRATADA;
- Definição das políticas de devolução da entrega pela CONTRATADA;
- Desenvolvimento de um novo Gateway de Pagamento;
- Armazenamento dos dados sensíveis dos cartões;
- Criação de serviço próprio de Antifraude;
- Cálculo de valor de frete por CEP.
Ponto de atenção: o fluxograma enviado contém a etapa “Calcular opções e valor do frete”, porém o documento contratual da VIRBAC estabelece expressamente que, neste escopo, o frete será tratado como CEP × prazo de entrega, sem relação de CEP com valor de frete. Portanto, eu recomendaria alterar essa caixa do fluxograma para “Consultar prazo de entrega conforme CEP” para manter o diagrama coerente com o documento contratado.
== Documentos Relacionados ==

== Regras de Negócios ==

'''[RN1] - '''

'''[RN2] - '''

'''[RN3] - '''

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

{| class="wikitable"
! Setor
! Aprovado Por
! Data

|-
| Desenvolvimento - GeoSales || Pessoa que aprovou || 00/00/0000
|-
| Integração - GeoSales || Pessoa que aprovou || 00/00/0000
|-
| Configurações - GeoSales || Pessoa que aprovou || 00/00/0000
|-
|}

=== Empresa solicitante ===

{| class="wikitable"
! 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 ||
|-
|}

Caso de Uso – Pagamento Online no B2B EVO para Veterinários

2026-10-30T17:53:50Z

Renatolima: /* Atores */

== Histórico de Alterações ==
{| class="wikitable"
! Data
! Quem
! Comentários
|-
| 28/10/2026 || Renato Lima || Criação do documento
|-
|}

== Necessidade ==
A VIRBAC necessita disponibilizar uma experiência de compra digital por meio de uma plataforma B2V (Business-to-Vet), permitindo que o médico veterinário, após realizar seu cadastro, validação e login, possa consultar o catálogo autorizado, visualizar os preços conforme sua classificação comercial, realizar pedidos, efetuar pagamentos e acompanhar o status de faturamento e entrega.

Para o processo de pagamento, o B2B EVO deverá integrar-se à API da Lyra, permitindo o processamento das transações financeiras e a utilização dos meios de pagamento disponibilizados pelo parceiro.

Para pagamentos com cartão de crédito, deverá ser implementada a tokenização, permitindo a reutilização do cartão em compras futuras sem que os dados sensíveis sejam armazenados pelo B2B EVO.

O processo também deverá contemplar Antifraude, com análise das transações antes da autorização definitiva do pagamento.

Além do pagamento, deverá existir controle da jornada financeira da transação, incluindo pagamentos pendentes, novas tentativas, histórico, cancelamentos, reembolsos, aprovações e respectivos status.

O fluxo deverá ainda contemplar o acompanhamento da entrega, utilizando as informações disponibilizadas pela API da AGV, considerando a relação CEP × prazo de entrega definida pela contratante.

== Solução ==
Será desenvolvido no B2B EVO o fluxo integrado de compra e pagamento para veterinários, utilizando a API da Lyra para processamento das transações financeiras e Antifraude.

O fluxo será iniciado após a seleção dos produtos e confirmação do endereço de entrega. O sistema deverá utilizar o CEP do endereço para disponibilizar as informações relacionadas ao prazo de entrega.

Após a definição da forma de pagamento, o sistema encaminhará a transação para o fluxo correspondente:
'''- Cartão de crédito:''' verificar existência de token previamente armazenado;
'''- Novo cartão:''' realizar o processo de tokenização através da Lyra e armazenar somente o token;
'''- PIX:''' encaminhar os dados necessários para processamento da transação;
'''- Antifraude:''' submeter a transação à análise antes da autorização definitiva;
'''- Pagamento aprovado:''' registrar a transação, atualizar o pedido e prosseguir com o envio ao ERP;
'''- Pagamento recusado ou pendente:''' registrar a ocorrência e disponibilizar nova tentativa de pagamento.
A solução também contemplará o controle de cancelamentos e reembolsos diretamente no B2B EVO. As solicitações de reembolso deverão registrar o motivo e passar pela aprovação dos responsáveis do Financeiro e/ou Comercial, antes do envio da solicitação de estorno à Lyra.

O acompanhamento da entrega será realizado por meio de tela específica no B2B EVO, utilizando as informações retornadas pela integração com a API da AGV, parceira logística da VIRBAC.

== Implementação ==
A implementação será composta pelos seguintes componentes:

'''Fluxo de compra'''

- Acesso do veterinário ao Portal B2B;

- Seleção dos produtos;

- Confirmação do endereço de entrega;

- Identificação do CEP;

- Consulta das informações de prazo de entrega;

- Confirmação do pedido;

- Seleção da forma de pagamento.

'''Pagamento'''

- Integração B2B EVO × API Lyra;

- Processamento de cartão de crédito;

- Processamento de PIX;

- Tokenização de cartão;

- Armazenamento do token;

- Reutilização do cartão tokenizado;

- Registro das transações;

- Tratamento de pagamentos aprovados, recusados e pendentes.

'''Antifraude'''

- Envio da transação para análise;

- Recebimento do resultado da análise;

- Tratamento de transação aprovada;

- Tratamento de transação recusada;

- Tratamento de transação direcionada para análise adicional;

- Registro do resultado da análise.
O documento define que o resultado do Antifraude poderá determinar a aprovação, recusa ou encaminhamento da transação para análise adicional, conforme as regras do parceiro.

'''Controle financeiro'''

Será criada estrutura específica para gerenciamento das transações, contemplando:

- Pagamentos;

- Análises antifraude;

- Pagamentos pendentes;

- Novas tentativas;

- Cancelamentos;

- Reembolsos;

- Histórico das movimentações;

- Status das transações.

'''Cancelamento e reembolso'''

O B2B EVO será responsável por centralizar o controle do processo de cancelamento.

Para pedidos que necessitem de reembolso:

1. Solicitação de reembolso;

2. Registro do motivo;

3. Análise pelo Financeiro e/ou Comercial;

4. Aprovação ou reprovação;

5. Envio da solicitação de estorno à Lyra;
6. Recebimento da confirmação;

7. Atualização do histórico;

8. Atualização dos sistemas envolvidos.

A definição e validação das políticas de cancelamento de pagamento e das políticas de cancelamento/devolução da entrega são de responsabilidade da contratante.

'''Entrega e logística'''

Será desenvolvida uma tela para acompanhamento do status da entrega.

As informações serão obtidas através da integração com a API da AGV, permitindo que o B2B EVO apresente as fases de andamento da entrega ao veterinário.

== Atores ==
{| class="wikitable"
! Ator
! Responsabilidade
|-
| '''Veterinário''' || Realizar cadastro, acessar o B2B EVO, selecionar produtos, realizar pedidos, efetuar pagamentos e acompanhar a entrega.
|-
| '''B2B EVO''' || Centralizar o fluxo de compra, pagamento, cancelamento, reembolso e acompanhamento da entrega.
|-
| '''Lyra''' || Processar pagamentos, tokenização e Antifraude por meio de suas APIs.
|-
| '''Financeiro''' || Analisar e aprovar/reprovar solicitações de reembolso quando aplicável.
|-
| '''Comercial''' || Analisar e aprovar/reprovar solicitações de reembolso quando aplicável.
|-
| '''ERP VIRBAC''' || Receber e atualizar as informações relacionadas aos pedidos.
|-
| '''AGV''' || Disponibilizar informações relacionadas ao andamento da entrega por meio de API.
|-
|}

== Pré-condições ==
O veterinário deve estar cadastrado e validado.
O veterinário deve possuir acesso ao B2B EVO.
O catálogo autorizado deve estar disponível.
Os preços aplicáveis à classificação comercial do veterinário devem estar configurados.
O endereço de entrega deve estar cadastrado.
O CEP do endereço deve estar disponível para utilização no fluxo logístico.
A integração com a API da Lyra deve estar disponível.
A integração com o serviço de Antifraude deve estar disponível.
A integração com a API da AGV deve estar disponível para acompanhamento da entrega.
As regras de cancelamento e reembolso devem estar definidas e validadas pela VIRBAC.
== Escopo ==
=== Escopo incluso ===
- Integração com a API da Lyra;
- Integração com Antifraude;
- Tokenização de cartões;
- Reutilização de cartões tokenizados;
- Pagamento via meios disponibilizados pela Lyra;
- Controle de pagamentos pendentes;
- Nova tentativa de pagamento;
- Histórico das transações;
- Controle de cancelamento;
- Solicitação e aprovação de reembolso;
- Solicitação de estorno;
- Atualização dos status;
- Integração com ERP VIRBAC;
- Integração com API da AGV;
- Tela de acompanhamento da entrega;
- Controle da relação CEP × prazo de entrega.
O documento contratado também prevê estrutura de banco e telas administrativas para acompanhamento das transações financeiras e seus respectivos retornos.

=== Escopo Não incluso ===
Com base no documento fornecido, não devem ser considerados neste caso de uso:
- Definição das políticas de cancelamento pela CONTRATADA;
- Definição das políticas de devolução da entrega pela CONTRATADA;
- Desenvolvimento de um novo Gateway de Pagamento;
- Armazenamento dos dados sensíveis dos cartões;
- Criação de serviço próprio de Antifraude;
- Cálculo de valor de frete por CEP.
Ponto de atenção: o fluxograma enviado contém a etapa “Calcular opções e valor do frete”, porém o documento contratual da VIRBAC estabelece expressamente que, neste escopo, o frete será tratado como CEP × prazo de entrega, sem relação de CEP com valor de frete. Portanto, eu recomendaria alterar essa caixa do fluxograma para “Consultar prazo de entrega conforme CEP” para manter o diagrama coerente com o documento contratado.
== Documentos Relacionados ==

== Regras de Negócios ==

'''[RN1] - '''

'''[RN2] - '''

'''[RN3] - '''

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

{| class="wikitable"
! Setor
! Aprovado Por
! Data

|-
| Desenvolvimento - GeoSales || Pessoa que aprovou || 00/00/0000
|-
| Integração - GeoSales || Pessoa que aprovou || 00/00/0000
|-
| Configurações - GeoSales || Pessoa que aprovou || 00/00/0000
|-
|}

=== Empresa solicitante ===

{| class="wikitable"
! 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 ||
|-
|}

Caso de Uso – Pagamento Online no B2B EVO para Veterinários

2026-10-30T17:50:10Z

Renatolima: /* Atores */

Caso de Uso – Pagamento Online no B2B EVO para Veterinários

2026-10-30T17:49:10Z

Renatolima: /* Atores */

Caso de Uso – Pagamento Online no B2B EVO para Veterinários

2026-10-30T17:48:15Z

Renatolima: /* Atores */

Caso de Uso – Pagamento Online no B2B EVO para Veterinários

2026-10-30T17:43:59Z

Renatolima: /* Regras de Negócios */

Caso de Uso – Pagamento Online no B2B EVO para Veterinários

2026-10-30T17:43:18Z

Renatolima: /* Implementação */

Caso de Uso – Pagamento Online no B2B EVO para Veterinários

2026-10-30T17:41:06Z

Renatolima: /* Implementação */

Caso de Uso – Pagamento Online no B2B EVO para Veterinários

2026-10-30T17:40:27Z

Renatolima: /* Implementação */

Caso de Uso – Pagamento Online no B2B EVO para Veterinários

2026-10-30T17:38:57Z

Renatolima: /* Solução */

Caso de Uso – Pagamento Online no B2B EVO para Veterinários

2026-10-30T17:38:05Z

Renatolima: /* Solução */

Caso de Uso – Pagamento Online no B2B EVO para Veterinários

2026-10-30T17:36:21Z

Renatolima: /* Necessidade */

Caso de Uso – Pagamento Online no B2B EVO para Veterinários

2026-10-28T12:42:00Z

Renatolima: Criou página com '== Histórico de Alterações == {| class="wikitable" ! Data ! Quem ! Comentários |- | 28/10/2026 || Renato Lima || Criação do documento |- |} == Necessidade == == So...'

== Histórico de Alterações ==
{| class="wikitable"
! Data
! Quem
! Comentários
|-
| 28/10/2026 || Renato Lima || Criação do documento
|-
|}

== Necessidade ==

== Solução ==

== Regras de Negócios ==

'''[RN1] - '''

'''[RN2] - '''

'''[RN3] - '''
== 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 ===

{| class="wikitable"
! Setor
! Aprovado Por
! Data

|-
| Desenvolvimento - GeoSales || Pessoa que aprovou || 00/00/0000
|-
| Integração - GeoSales || Pessoa que aprovou || 00/00/0000
|-
| Configurações - GeoSales || Pessoa que aprovou || 00/00/0000
|-
|}

=== Empresa solicitante ===

{| class="wikitable"
! 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 ||
|-
|}

Projeto/Virbac

2026-10-28T12:40:56Z

Renatolima:

* [[Condição de Pagamento por Item]]

* [[Adicionar Campo Tipo do item e Característica Condição pagamento item]]

* [[Adicionar Campos Relatório de Carteira]]

* [[Caso de Uso – Pagamento Online no B2B EVO para Veterinários]]

Disponibilizar as Informações de Atualização de Versão

2026-10-21T17:47:11Z

Renatolima: /* Pós-condições */

== Histórico de Alterações ==
{| class="wikitable"
! 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 ==

[[Arquivo:Disponibilizar_versao.png|1150px]]

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

{| class="wikitable"
! Setor
! Aprovado Por
! Data

|-
| Integração - GeoSales || || dd/mm/aaaa
|-
|}

=== Empresa solicitante ===

{| class="wikitable"
! 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 ||
|-
|}

Disponibilizar as Informações de Atualização de Versão

2026-10-19T20:29:14Z

Renatolima: /* Fluxograma */

== Histórico de Alterações ==
{| class="wikitable"
! 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.

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

[[Arquivo:Disponibilizar_versao.png|1150px]]

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

{| class="wikitable"
! Setor
! Aprovado Por
! Data

|-
| Integração - GeoSales || || dd/mm/aaaa
|-
|}

=== Empresa solicitante ===

{| class="wikitable"
! 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 ||
|-
|}

Disponibilizar as Informações de Atualização de Versão

2026-10-19T20:29:03Z

Renatolima: /* Fluxograma */

== Histórico de Alterações ==
{| class="wikitable"
! 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.

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

[[Arquivo:Disponibilizar_versao.png|1200px]]

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

{| class="wikitable"
! Setor
! Aprovado Por
! Data

|-
| Integração - GeoSales || || dd/mm/aaaa
|-
|}

=== Empresa solicitante ===

{| class="wikitable"
! 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 ||
|-
|}

Disponibilizar as Informações de Atualização de Versão

2026-10-19T20:28:52Z

Renatolima: /* Fluxograma */

== Histórico de Alterações ==
{| class="wikitable"
! 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.

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

[[Arquivo:Disponibilizar_versao.png|1100px]]

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

{| class="wikitable"
! Setor
! Aprovado Por
! Data

|-
| Integração - GeoSales || || dd/mm/aaaa
|-
|}

=== Empresa solicitante ===

{| class="wikitable"
! 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 ||
|-
|}

Disponibilizar as Informações de Atualização de Versão

2026-10-19T20:28:41Z

Renatolima: /* Fluxo resumido da solução */

== Histórico de Alterações ==
{| class="wikitable"
! 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.

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

---[[Arquivo:Disponibilizar_versao.png|1100px]]

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

{| class="wikitable"
! Setor
! Aprovado Por
! Data

|-
| Integração - GeoSales || || dd/mm/aaaa
|-
|}

=== Empresa solicitante ===

{| class="wikitable"
! 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 ||
|-
|}

Disponibilizar as Informações de Atualização de Versão

2026-10-19T20:25:34Z

Renatolima: /* Fluxograma */

== Histórico de Alterações ==
{| class="wikitable"
! 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.

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

---[[Arquivo:Disponibilizar_versao.png|1100px]]

====Fluxo resumido da solução====

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

{| class="wikitable"
! Setor
! Aprovado Por
! Data

|-
| Integração - GeoSales || || dd/mm/aaaa
|-
|}

=== Empresa solicitante ===

{| class="wikitable"
! 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 ||
|-
|}

Arquivo:Disponibilizar versao.png

2026-10-19T20:25:11Z

Renatolima:

Disponibilizar as Informações de Atualização de Versão

2026-10-19T19:25:52Z

Renatolima: /* Histórico de Alterações */

== Histórico de Alterações ==
{| class="wikitable"
! 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.

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

---[[Arquivo:Inteligence_geração_agenda.png|1100px]]

====Fluxo resumido da solução====

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

{| class="wikitable"
! Setor
! Aprovado Por
! Data

|-
| Integração - GeoSales || || dd/mm/aaaa
|-
|}

=== Empresa solicitante ===

{| class="wikitable"
! 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 ||
|-
|}

Disponibilizar as Informações de Atualização de Versão

2026-10-19T19:25:26Z

Renatolima: /* Pós-condições */

== Histórico de Alterações ==
{| class="wikitable"
! Data
! Quem
! Comentários
|-
| 11/09/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.

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

---[[Arquivo:Inteligence_geração_agenda.png|1100px]]

====Fluxo resumido da solução====

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

{| class="wikitable"
! Setor
! Aprovado Por
! Data

|-
| Integração - GeoSales || || dd/mm/aaaa
|-
|}

=== Empresa solicitante ===

{| class="wikitable"
! 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 ||
|-
|}

Disponibilizar as Informações de Atualização de Versão

2026-10-19T19:25:02Z

Renatolima: /* Pré-condições */

== Histórico de Alterações ==
{| class="wikitable"
! Data
! Quem
! Comentários
|-
| 11/09/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.

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

---[[Arquivo:Inteligence_geração_agenda.png|1100px]]

====Fluxo resumido da solução====

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

{| class="wikitable"
! Setor
! Aprovado Por
! Data

|-
| Integração - GeoSales || || dd/mm/aaaa
|-
|}

=== Empresa solicitante ===

{| class="wikitable"
! 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 ||
|-
|}

Disponibilizar as Informações de Atualização de Versão

2026-10-19T19:24:31Z

Renatolima: /* Escopo Não Incluso */

== Histórico de Alterações ==
{| class="wikitable"
! Data
! Quem
! Comentários
|-
| 11/09/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.

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

---[[Arquivo:Inteligence_geração_agenda.png|1100px]]

====Fluxo resumido da solução====

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

{| class="wikitable"
! Setor
! Aprovado Por
! Data

|-
| Integração - GeoSales || || dd/mm/aaaa
|-
|}

=== Empresa solicitante ===

{| class="wikitable"
! 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 ||
|-
|}

Disponibilizar as Informações de Atualização de Versão

2026-10-19T19:22:54Z

Renatolima: /* Escopo Incluso */

== Histórico de Alterações ==
{| class="wikitable"
! Data
! Quem
! Comentários
|-
| 11/09/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 ===
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.

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

---[[Arquivo:Inteligence_geração_agenda.png|1100px]]

====Fluxo resumido da solução====

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

{| class="wikitable"
! Setor
! Aprovado Por
! Data

|-
| Integração - GeoSales || || dd/mm/aaaa
|-
|}

=== Empresa solicitante ===

{| class="wikitable"
! 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 ||
|-
|}

Disponibilizar as Informações de Atualização de Versão

2026-10-19T19:22:17Z

Renatolima: /* Implementação */

== Histórico de Alterações ==
{| class="wikitable"
! Data
! Quem
! Comentários
|-
| 11/09/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 ===
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.

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

---[[Arquivo:Inteligence_geração_agenda.png|1100px]]

====Fluxo resumido da solução====

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

{| class="wikitable"
! Setor
! Aprovado Por
! Data

|-
| Integração - GeoSales || || dd/mm/aaaa
|-
|}

=== Empresa solicitante ===

{| class="wikitable"
! 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 ||
|-
|}

Disponibilizar as Informações de Atualização de Versão

2026-10-19T19:21:59Z

Renatolima: /* Implementação */

== Histórico de Alterações ==
{| class="wikitable"
! Data
! Quem
! Comentários
|-
| 11/09/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 ===
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.

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

---[[Arquivo:Inteligence_geração_agenda.png|1100px]]

====Fluxo resumido da solução====

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

{| class="wikitable"
! Setor
! Aprovado Por
! Data

|-
| Integração - GeoSales || || dd/mm/aaaa
|-
|}

=== Empresa solicitante ===

{| class="wikitable"
! 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 ||
|-
|}

Disponibilizar as Informações de Atualização de Versão

2026-10-19T19:19:27Z

Renatolima: /* Solução */

== Histórico de Alterações ==
{| class="wikitable"
! Data
! Quem
! Comentários
|-
| 11/09/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 ==
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.

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.

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.

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.

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.

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

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

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

---[[Arquivo:Inteligence_geração_agenda.png|1100px]]

====Fluxo resumido da solução====

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

{| class="wikitable"
! Setor
! Aprovado Por
! Data

|-
| Integração - GeoSales || || dd/mm/aaaa
|-
|}

=== Empresa solicitante ===

{| class="wikitable"
! 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 ||
|-
|}

Disponibilizar as Informações de Atualização de Versão

2026-10-19T19:18:04Z

Renatolima: /* Regras de Negócio */

== Histórico de Alterações ==
{| class="wikitable"
! Data
! Quem
! Comentários
|-
| 11/09/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 ==
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.

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.

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.

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.

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.

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

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

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

---[[Arquivo:Inteligence_geração_agenda.png|1100px]]

====Fluxo resumido da solução====

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

{| class="wikitable"
! Setor
! Aprovado Por
! Data

|-
| Integração - GeoSales || || dd/mm/aaaa
|-
|}

=== Empresa solicitante ===

{| class="wikitable"
! 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 ||
|-
|}

Disponibilizar as Informações de Atualização de Versão

2026-10-19T18:55:51Z

Renatolima: /* Atores */

== Histórico de Alterações ==
{| class="wikitable"
! Data
! Quem
! Comentários
|-
| 11/09/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 ==
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.

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.

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.

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.

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.

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

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

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

---[[Arquivo:Inteligence_geração_agenda.png|1100px]]

====Fluxo resumido da solução====

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

{| class="wikitable"
! Setor
! Aprovado Por
! Data

|-
| Integração - GeoSales || || dd/mm/aaaa
|-
|}

=== Empresa solicitante ===

{| class="wikitable"
! 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 ||
|-
|}

Disponibilizar as Informações de Atualização de Versão

2026-10-19T18:55:06Z

Renatolima: /* Solução */

== Histórico de Alterações ==
{| class="wikitable"
! Data
! Quem
! Comentários
|-
| 11/09/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 ==
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.

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.

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.

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.

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.

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

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

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

---[[Arquivo:Inteligence_geração_agenda.png|1100px]]

====Fluxo resumido da solução====

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

{| class="wikitable"
! Setor
! Aprovado Por
! Data

|-
| Integração - GeoSales || || dd/mm/aaaa
|-
|}

=== Empresa solicitante ===

{| class="wikitable"
! 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 ||
|-
|}

Disponibilizar as Informações de Atualização de Versão

2026-10-19T18:54:07Z

Renatolima:

== Histórico de Alterações ==
{| class="wikitable"
! Data
! Quem
! Comentários
|-
| 11/09/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 ==

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

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.

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.

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.

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.

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

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

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

---[[Arquivo:Inteligence_geração_agenda.png|1100px]]

====Fluxo resumido da solução====

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

{| class="wikitable"
! Setor
! Aprovado Por
! Data

|-
| Integração - GeoSales || || dd/mm/aaaa
|-
|}

=== Empresa solicitante ===

{| class="wikitable"
! 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 ||
|-
|}

Disponibilizar as Informações de Atualização de Versão

2026-10-19T18:39:50Z

Renatolima: /* Fluxograma */

== Histórico de Alterações ==
{| class="wikitable"
! Data
! Quem
! Comentários
|-
| 11/09/2026 || Renato Lima || Criação do documento
|-
|}

== Necessidade ==

== Solução ==

== Implementação ==

== Escopo ==

=== Escopo Incluso ===

=== Escopo Não Incluso ===

== Atores ==

== Pré-condições ==

== Pós-condições ==

== Regras de Negócio ==

'''[RN1] - '''

'''[RN2] - '''

'''[RN3] - '''

'''[RN4] - '''

'''[RN5] - '''

'''[RN6] - '''

'''[RN7] - '''

'''[RN8] - '''

'''[RN9] - '''

'''[RN10] - '''

'''[RN11] - '''

== Fluxograma ==

---[[Arquivo:Inteligence_geração_agenda.png|1100px]]

====Fluxo resumido da solução====

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

{| class="wikitable"
! Setor
! Aprovado Por
! Data

|-
| Integração - GeoSales || || dd/mm/aaaa
|-
|}

=== Empresa solicitante ===

{| class="wikitable"
! 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 ||
|-
|}

Disponibilizar as Informações de Atualização de Versão

2026-10-19T18:39:42Z

Renatolima: /* Fluxograma */

== Histórico de Alterações ==
{| class="wikitable"
! Data
! Quem
! Comentários
|-
| 11/09/2026 || Renato Lima || Criação do documento
|-
|}

== Necessidade ==

== Solução ==

== Implementação ==

== Escopo ==

=== Escopo Incluso ===

=== Escopo Não Incluso ===

== Atores ==

== Pré-condições ==

== Pós-condições ==

== Regras de Negócio ==

'''[RN1] - '''

'''[RN2] - '''

'''[RN3] - '''

'''[RN4] - '''

'''[RN5] - '''

'''[RN6] - '''

'''[RN7] - '''

'''[RN8] - '''

'''[RN9] - '''

'''[RN10] - '''

'''[RN11] - '''

== Fluxograma ==

--[[Arquivo:Inteligence_geração_agenda.png|1100px]]

====Fluxo resumido da solução====

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

{| class="wikitable"
! Setor
! Aprovado Por
! Data

|-
| Integração - GeoSales || || dd/mm/aaaa
|-
|}

=== Empresa solicitante ===

{| class="wikitable"
! 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 ||
|-
|}