Mudanças entre as edições de "Prazo de Pagamento por produto"

De GeoSales
Ir para navegação Ir para pesquisar
 
(37 revisões intermediárias pelo mesmo usuário não estão sendo mostradas)
Linha 11: Linha 11:
  
 
== Necessidade ==
 
== Necessidade ==
−
No processo de vendas da Ocrim, existe um grupo de produto, que tem prazo de pagamento especifico. Então, quando esses produtos estão em um pedido, o prazo a ser apresentado e disponibilizado, deve ser os prazos vinculados a esses produtos, mesmo que tenham outros produto inseridos no pedido, que não tenham o vinculo com esse prazo.
+
No processo de vendas da Ocrim, existem  produtos, que tem prazos de pagamentos específicos. Então, quando estes produtos estão em um pedido, as condições de pagamento que devem ser apresentadas, deve respeitar o menor prazo de pagamento, seja dos produtos ou cliente que estejam naquele pedido. Assim, deve ser apresentado apenas as condições de pagamentos que estejam igual ou abaixo do menor prazo médio.
  
 
== Solução ==
 
== Solução ==
−
Para tratar a venda de determinados produtos, de acordo com um prazo especifico para eles,
+
Para tratar a venda de determinados produtos, de acordo com um prazo especifico para eles, precisamos identificar esses produtos que terão os prazos diferenciados. Com a identificação destes produtos, vamos aplicar solução no fluxo de inserção e edição de pedido. Quando estes produtos estiverem no pedido os prazos para seleção no pedido devem obedecer as regras de prazos do produto, mesmo que haja outros produtos, além disso, vamos levar em consideração os prazo que o cliente tem acesso, pois se o produto permiti que ele tenha acesso a prazos maiores, o que deve prevalecer é o prazo que o cliente tem, já que ele não está habilitado a usar esses prazo.
−
precisamos identificar esses produtos que terão estes prazos diferenciados. Com a identificação destes produtos, vamos aplicar solução no fluxo de inserção e edição de pedido. Quando estes produtos estiverem no pedido os prazos para seleção no pedido devem obedecer as regras de prazos do produto, mesmo que haja outros produtos, o prazo a ser usado será o determinado por esses produto que terão o prazo estabelecido.
 
  
 
== Implementação ==
 
== Implementação ==
  
−
# A ativação da opção de retorno deve ser configurável pelo usuário.
 
−
# Após a efetivação do prospect, ele será enviado à ERP.
 
−
# Todos os processos de tentativa de integração são registrados na tabela ACK_LOG_TABLE.
 
−
# Quando a integração não for realizada, registra-se a falha de integração do prospect na tabela, cenário onde será disparado o trigger de retorno.
 
−
# O usuário deverá ser informado sobre o retorno do prospect (poderá ser por email);
 
−
# O cadastro deverá estar disponível para edição, dependendo da demanda do usuário.
 
−
# Feita as devidas alterações, as seguintes soluções deverão ser permitidas:
 
−
* Nova efetivação do cadastro para nova tentativa de integração;
 
  
 +
Criar estrutura que permite vincular o produto, organização venda a um prazo médio das condições de pagamento, onde essas informações virão via integração.
 +
O produto não deve receber mais de um prazo médio, quando o produto não estiver nesta estrutura, indica que ele pode levar em consideração as condições de pagamento que estão vinculadas ao Grupo meio pagamento do cliente.
  
 +
Com a estrutura de controle populada, no fluxo de inclusão e edição de pedido, o sistema deve validar essa nova estrutura, desta forma, fará com que apresente no campo de condições de pagamento para fechamento do pedido, condições que tenham seu prazo médio, com prazo igual ou inferior ao prazo dos produtos que estão no pedido.
 +
 +
Caso o prazo médio das condições do cliente sejam menor que o prazo médio atribuído aos produtos, o sistema deve respeita os prazos de condição de pagamento atribuídos ao grupo meio pagamento do cliente.
 +
 +
Na tabela de condição de pagamento o campo '''QT_PRAZO_MEDIO''' deve está preenchido, para que assim as validações possam ocorrer. Caso o campo esteja com valor null neste campo, pode não ocorrer a validação da condição de pagamento de acordo com o prazo.
  
 
== Cenários ==
 
== Cenários ==
  
−
<!--=== Cenário 1 - Cancelamento após falha de integração ===
+
'''Para os cenários de teste usaremos a seguinte massa de exemplo''': <br><br>
 +
{| class="wikitable"
 +
! CLIENTE
 +
! QT_PRAZO_MEDIO_CL
 +
! PRODUTO
 +
! QT_PRAZO_MEDIO_PRO
 +
|-
 +
| Cliente A  || 0 || Produto A || 0
 +
|-
 +
| Cliente B  || 7 || Produto B || 7
 +
|-
 +
| Cliente C  || 14|| Produto C || 14
 +
|-
 +
| Cliente D  || 21 || Produto D || 21
 +
|-
 +
| Cliente E  || 28 || Produto E || 28
 +
|-
 +
| Cliente F  || 35 || Produto F || null
 +
|-
 +
|}<br>
 +
'''Campo possível ao inserir ou editar pedido: '''
  
 +
<hr>
  
−
# Criação de cadastro na tela de prospect;
+
'''Dado''' que usuário A acessa a '''inserir pedido''' na plataforma GeoSales EVO;<br>
−
# As alterações são salvas e o cadastro é efetivado;
+
'''E''' seleciona os dados abaixo;<br>
−
# O cadastro é enviado para a ERP e não conclui o processo de integração;
+
{| class="wikitable"
−
# O registro de falha é inserido na tabela ACK_LOG_TABLE;
+
! CLIENTE
−
# A falha de exportação de cadastro irá provocar um disparo de trigger, que fará o retorno do cadastro para edição com status de não efetivado;
+
! QT_PRAZO_MEDIO_CL
−
# Uma notificação de retorno de cadastro pendente será enviado ao usuário, informando que o cadastro não foi integrado e requer uma ação dele.
+
! PRODUTO
−
# O usuário poderá acessar novamente o cadastro e fará o cancelamento do mesmo.-->
+
! QT_PRAZO_MEDIO_PRO
 +
|-
 +
| Cliente D  || 21 || Produto C || 14
 +
|-
 +
|}
 +
'''O''' sistema deve apresentar as condições levando em consideração o prazo do Produto C:<br>
 +
<br>
 +
<hr>
 +
'''Dado''' que usuário A acessa a '''inserir pedido''' na plataforma GeoSales EVO;<br>
 +
'''E''' seleciona os dados abaixo;<br>
 +
{| class="wikitable"
 +
! CLIENTE
 +
! QT_PRAZO_MEDIO_CL
 +
! PRODUTO
 +
! QT_PRAZO_MEDIO_PRO
 +
|-
 +
| Cliente C  || 14 || Produto D || 21
 +
|-
 +
|}
 +
'''O''' sistema deve apresentar as condições levando em consideração o prazo do Cliente C :<br>
 +
<br>
 +
<hr>
  
−
=== Cenário 1 - Re-efetivação após falha de integração ===
+
'''Dado''' que usuário A acessa a '''inserir pedido''' na plataforma GeoSales EVO;<br>
 +
'''E''' seleciona os dados abaixo;<br>
 +
{| class="wikitable"
 +
! CLIENTE
 +
! QT_PRAZO_MEDIO_CL
 +
! PRODUTO
 +
! QT_PRAZO_MEDIO_PRO
 +
|-
 +
| Cliente E  || 28 || Produto E || 28
 +
|-
 +
|}
 +
'''O''' sistema deve apresentar as condições levando em consideração o prazo 28:<br>
 +
<br>
 +
<hr>
 +
'''Dado''' que usuário A acessa a '''inserir pedido''' na plataforma GeoSales EVO;<br>
 +
'''E''' seleciona os dados abaixo;<br>
 +
{| class="wikitable"
 +
! CLIENTE
 +
! QT_PRAZO_MEDIO_CL
 +
! PRODUTO
 +
! QT_PRAZO_MEDIO_PRO
 +
|-
 +
| Cliente F  || 35 || Produto E || null
 +
|-
 +
|}
 +
'''O''' sistema deve apresentar as condições levando em consideração o prazo do Cliente F:<br>
 +
<br>
 +
<hr>
 +
 
 +
'''Dado''' que usuário A acessa a '''inserir pedido''' na plataforma GeoSales EVO;<br>
 +
'''E''' seleciona os dados abaixo;<br>
 +
{| class="wikitable"
 +
! CLIENTE
 +
! QT_PRAZO_MEDIO_CL
 +
! PRODUTO
 +
! QT_PRAZO_MEDIO_PRO
 +
|-
 +
| Cliente E  || 28 || Produto D || 21
 +
|-
 +
|  ||  || Produto B || 14
 +
|-
 +
|}
 +
'''O''' sistema deve apresentar as condições levando em consideração o prazo do Produto B:<br>
 +
<br>
 +
<hr>
  
−
# Criação de cadastro na tela de prospect;
+
'''Dado''' que usuário A acessa a '''inserir pedido''' na plataforma GeoSales EVO;<br>
−
# As alterações são salvas e o cadastro é efetivado;
+
'''E''' seleciona os dados abaixo;<br>
−
# O cadastro é enviado para a ERP e não conclui o processo de integração;
+
{| class="wikitable"
−
# O registro de falha é inserido na tabela ACK_LOG_TABLE;
+
! CLIENTE
−
# A falha de exportação de cadastro irá provocar um disparo de trigger, que fará o retorno do cadastro para edição com status de não efetivado;
+
! QT_PRAZO_MEDIO_CL
−
# Uma notificação de retorno de cadastro pendente será enviado ao usuário, informando que o cadastro não foi integrado e requer uma ação dele.
+
! PRODUTO
−
# O usuário fará nova edição no cadastro, caso seja necessário, e efetivará novamente o cadastro, para novo envio à ERP.
+
! QT_PRAZO_MEDIO_PRO
 +
|-
 +
| Cliente C  || 14 || Produto E || 28
 +
|-
 +
|  ||  || Produto D || 21
 +
|-
 +
|}'''O''' sistema deve apresentar as condições levando em consideração o prazo do Cliente C:<br>
 +
<br>
  
 
== Regras de Negócio ==
 
== Regras de Negócio ==
  
−
'''[RN1] -''' Quando houver produtos que os prazo choquem, deve ser levado em consideração o prazo de pagamento do produto que tem o menor prazo.  
+
'''[RN1] -''' Quando houver produtos que os prazos choquem, deve ser levado em consideração o prazo de pagamento do produto que tem o menor prazo.  
  
 
'''[RN2] -''' Na tabela de condição de pagamento o campo QT_PRAZO_MEDIO da condição de pagamento, deve está preenchido.
 
'''[RN2] -''' Na tabela de condição de pagamento o campo QT_PRAZO_MEDIO da condição de pagamento, deve está preenchido.
  
−
'''[RN3] -''' Pode ocorrer, ainda de muito remotamente, o risco de o cadastro ser integrado '''no momento entre o processo de retorno'''. No caso de ocorrência deste processo, o processo de retorno deverá ser cancelado.
+
'''[RN3] -''' Quando houver produtos e clientes que tenham os prazos diferentes e o prazo do cliente seja o menor, o prazo do cliente deve ser levado em consideração.
−
'''[RN4] -''' A ativação deste procedimento deverá ser realizada via configuração.
+
 
 +
'''[RN4] -''' Para que o Geosales realize as validações, os cadastros de Grupo Meio pagamento do cliente e prazos vinculados a produto, precisam está coerentes. Pois isso pode ocasionar cenários em que não apresente condições para fechamento do pedido.
  
 
== Aprovação ==
 
== Aprovação ==
Linha 75: Linha 167:
  
 
|-  
 
|-  
−
| Desenvolvimento - GeoSales || Renato Lima || 26/04/2021
+
| Desenvolvimento - GeoSales || Renato Lima || 30/04/2021
 
|-  
 
|-  
 
| Integração - GeoSales || Pessoa que aprovou || 00/00/0000
 
| Integração - GeoSales || Pessoa que aprovou || 00/00/0000
Linha 82: Linha 174:
 
|-
 
|-
 
|}
 
|}
 +
f
  
 
=== Empresa solicitante ===  
 
=== Empresa solicitante ===  

Edição atual tal como às 14h31min de 3 de maio de 2021

Histórico de Alterações

Data Quem Comentários
27/04/2021 Renato Lima Criação do documento

Necessidade

No processo de vendas da Ocrim, existem produtos, que tem prazos de pagamentos específicos. Então, quando estes produtos estão em um pedido, as condições de pagamento que devem ser apresentadas, deve respeitar o menor prazo de pagamento, seja dos produtos ou cliente que estejam naquele pedido. Assim, deve ser apresentado apenas as condições de pagamentos que estejam igual ou abaixo do menor prazo médio.

Solução

Para tratar a venda de determinados produtos, de acordo com um prazo especifico para eles, precisamos identificar esses produtos que terão os prazos diferenciados. Com a identificação destes produtos, vamos aplicar solução no fluxo de inserção e edição de pedido. Quando estes produtos estiverem no pedido os prazos para seleção no pedido devem obedecer as regras de prazos do produto, mesmo que haja outros produtos, além disso, vamos levar em consideração os prazo que o cliente tem acesso, pois se o produto permiti que ele tenha acesso a prazos maiores, o que deve prevalecer é o prazo que o cliente tem, já que ele não está habilitado a usar esses prazo.

Implementação

Criar estrutura que permite vincular o produto, organização venda a um prazo médio das condições de pagamento, onde essas informações virão via integração. O produto não deve receber mais de um prazo médio, quando o produto não estiver nesta estrutura, indica que ele pode levar em consideração as condições de pagamento que estão vinculadas ao Grupo meio pagamento do cliente.

Com a estrutura de controle populada, no fluxo de inclusão e edição de pedido, o sistema deve validar essa nova estrutura, desta forma, fará com que apresente no campo de condições de pagamento para fechamento do pedido, condições que tenham seu prazo médio, com prazo igual ou inferior ao prazo dos produtos que estão no pedido.

Caso o prazo médio das condições do cliente sejam menor que o prazo médio atribuído aos produtos, o sistema deve respeita os prazos de condição de pagamento atribuídos ao grupo meio pagamento do cliente.

Na tabela de condição de pagamento o campo QT_PRAZO_MEDIO deve está preenchido, para que assim as validações possam ocorrer. Caso o campo esteja com valor null neste campo, pode não ocorrer a validação da condição de pagamento de acordo com o prazo.

Cenários

Para os cenários de teste usaremos a seguinte massa de exemplo:

CLIENTE QT_PRAZO_MEDIO_CL PRODUTO QT_PRAZO_MEDIO_PRO
Cliente A 0 Produto A 0
Cliente B 7 Produto B 7
Cliente C 14 Produto C 14
Cliente D 21 Produto D 21
Cliente E 28 Produto E 28
Cliente F 35 Produto F null


Campo possível ao inserir ou editar pedido:

Dado que usuário A acessa a inserir pedido na plataforma GeoSales EVO;
E seleciona os dados abaixo;

CLIENTE QT_PRAZO_MEDIO_CL PRODUTO QT_PRAZO_MEDIO_PRO
Cliente D 21 Produto C 14

O sistema deve apresentar as condições levando em consideração o prazo do Produto C:

Dado que usuário A acessa a inserir pedido na plataforma GeoSales EVO;
E seleciona os dados abaixo;

CLIENTE QT_PRAZO_MEDIO_CL PRODUTO QT_PRAZO_MEDIO_PRO
Cliente C 14 Produto D 21

O sistema deve apresentar as condições levando em consideração o prazo do Cliente C :

Dado que usuário A acessa a inserir pedido na plataforma GeoSales EVO;
E seleciona os dados abaixo;

CLIENTE QT_PRAZO_MEDIO_CL PRODUTO QT_PRAZO_MEDIO_PRO
Cliente E 28 Produto E 28

O sistema deve apresentar as condições levando em consideração o prazo 28:

Dado que usuário A acessa a inserir pedido na plataforma GeoSales EVO;
E seleciona os dados abaixo;

CLIENTE QT_PRAZO_MEDIO_CL PRODUTO QT_PRAZO_MEDIO_PRO
Cliente F 35 Produto E null

O sistema deve apresentar as condições levando em consideração o prazo do Cliente F:

Dado que usuário A acessa a inserir pedido na plataforma GeoSales EVO;
E seleciona os dados abaixo;

CLIENTE QT_PRAZO_MEDIO_CL PRODUTO QT_PRAZO_MEDIO_PRO
Cliente E 28 Produto D 21
Produto B 14

O sistema deve apresentar as condições levando em consideração o prazo do Produto B:

Dado que usuário A acessa a inserir pedido na plataforma GeoSales EVO;
E seleciona os dados abaixo;

CLIENTE QT_PRAZO_MEDIO_CL PRODUTO QT_PRAZO_MEDIO_PRO
Cliente C 14 Produto E 28
Produto D 21

O sistema deve apresentar as condições levando em consideração o prazo do Cliente C:


Regras de Negócio

[RN1] - Quando houver produtos que os prazos choquem, deve ser levado em consideração o prazo de pagamento do produto que tem o menor prazo.

[RN2] - Na tabela de condição de pagamento o campo QT_PRAZO_MEDIO da condição de pagamento, deve está preenchido.

[RN3] - Quando houver produtos e clientes que tenham os prazos diferentes e o prazo do cliente seja o menor, o prazo do cliente deve ser levado em consideração.

[RN4] - Para que o Geosales realize as validações, os cadastros de Grupo Meio pagamento do cliente e prazos vinculados a produto, precisam está coerentes. Pois isso pode ocasionar cenários em que não apresente condições para fechamento do pedido.

Aprovação

Considero aprovada a documentação da funcionalidade especificada acima, e autorizo a implementação da mesma no Sistema GeoSales, em nome da Organização a qual estou vinculado.

GeoSales

Setor Aprovado Por Data
Desenvolvimento - GeoSales Renato Lima 30/04/2021
Integração - GeoSales Pessoa que aprovou 00/00/0000
Configurações - GeoSales Pessoa que aprovou 00/00/0000

f

Empresa solicitante

Setor Aprovado Por Data Assinatura
Gerente TI - Cliente ___________________ ___/___/_____ ________________________
Gerente de Projeto - Cliente ___________________ ___/___/_____ ________________________
Gerente Comercial - Cliente ___________________ ___/___/_____ ________________________
Disponível em “http://wiki.geosales.com.br:8000/index.php?title=Prazo_de_Pagamento_por_produto&oldid=15476”