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

Edição das 18h58min de 27 de abril 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, existe um grupo de produto, que tem prazos de pagamentos específicos. Então, quando estes 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.

Solução

Para tratar a venda de determinados produtos, de acordo com um prazo especifico para eles, 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

Cenários

Cenário 1 - Re-efetivação após falha de integração

Criação de cadastro na tela de prospect;
As alterações são salvas e o cadastro é efetivado;
O cadastro é enviado para a ERP e não conclui o processo de integração;
O registro de falha é inserido na tabela ACK_LOG_TABLE;
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;
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.
O usuário fará nova edição no cadastro, caso seja necessário, e efetivará novamente o cadastro, para novo envio à ERP.

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.

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

[RN4] - A ativação deste procedimento deverá ser realizada via configuraçã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

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

Empresa solicitante

Setor	Aprovado Por	Data	Assinatura
Gerente TI - Cliente	___________________	___/___/_____	________________________
Gerente de Projeto - Cliente	___________________	___/___/_____	________________________
Gerente Comercial - Cliente	___________________	___/___/_____	________________________

@@ Linha 18: / Linha 18: @@
 == 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;
 == Cenários ==