DMAISNEG-124 - DT - Alteração do Pedido de Venda

01. DADOS GERAIS

02. SITUAÇÃO/REQUISITO

Visão Geral

Durante o fluxo de liberação do pedido de venda, será realizado o envio da solicitação de pré-autorização de um pedido de venda para o Mais Negócios, que possui a Cobrança SUPP, quando ele for Autorizado pelas regras internas de liberação do pedido de venda.

Caso este Pedido seja alterado após ser reenviado uma solicitação de pré-autorização para o mais negócios, a rotina deverá enviar o cancelamento do envio anterior e gerar um novo envio com as novas informações.

 Quando a solicitação de pré-autorização passou por Rejeição pode ser liberado a solicitação de reenvio de uma nova solicitação para a plataforma mais negócios.

Critérios de aceitação:

 No fluxo de  Alteração do Pedido - Envio de Alteração de Solicitação de Pré-Autorização 

1 . Para alteração da cobrança do pedido.

1. Somente permitir mudar a cobrança de Supplier (CODCOB = SUPP) para Cobrança interna.
2. Não permitir alterar de  cobrança Interna para Supplier. 

2. Ao solicitar a  alteração do Pedido  com Cobrança Supplier (codcob = SUPP),  deve ser validado se o pedido já foi enviado ao Mais Negócios, validar na tabela PCFILAMAISNEGLOG, se o campo DTHORAENVIOSUPPLI IS NOT NULL. 

2.1 - Caso não foi encontrado o registro do envio de pré-autorização do pedido na PCFILAMAISNEGLOG, o mesmo ainda não foi encaminhado para a tabela de fila de integração para o mais negócios, ao finalizar a sua Alteração (edição), ele será liberado para o fluxo de Liberação do Pedido e seguirá com as regras do item 1.     

    obs: Este cenário ocorrerá quando o pedido for alterado antes de ser liberado pelas regras atuais de liberação de pedido da 336. 

2.2- Caso positivo (pré autorização do pedido já enviado ao mais negócios): O pedido está registrado na PCFILAMAISNEGLOG e o campo DTHORAENVIOSUPPLI IS NOT NULL.  (já foi enviado para a API o pedido de pre autorização)

• A  rotina irá incluir dois registros na PCFILAMAISNEGENVIO, sendo um registro para CANCELAR a pré-autorização anterior (PCFILAMAISNEGENVIO.TIPOINF = 2); e um NOVO para encaminhar uma nova pré-autorização (PCFILAMAISNEGENVIO.TIPOINF = 1).
• Atualizar o registro da PCFILAMAISNEGLOG preenchendo os campos CANCELADO e IDCANCELAMENTO (este é o identificador da PCFILASUPPLIENVIO do tipoinf=2, referente ao cancelamento).
• Incluir um novo registro na PCFILAMAISNEGLOG, com o campo IDPCFILAMAISNEGENVIO, referente ao novo envio tipoinf =1.

 2.3- Caso negativo (pré autorização do pedido  não foi enviado ao mais negócios): O pedido está registrado na PCFILAMAISNEGLOG e o campo DTHORAENVIOSUPPLI IS  NULL. 

• A rotina apenas deverá TRAVAR o registro na tabela PCFILAMAISNEGENVIO , para que o serviço do WTA não pegue o pedido e envie ao Mais Negócios enquanto o mesmo estiver em edição. 

obs: conferir com o time da API (Time WinThor) se o melhor caminho é travar ou retirar da fila de envio, pois de acordo com a solução técnica do agendador a ação de tratar não atende o requisito . Talvez deverá retirar da fila de envio e após finalizar a edição registra novamente.

Pedido Rejeitado Pelo MAIS NEGÓCIOS - Retorno da API

3.  Se o pedido foi REJEITADO pelo Mais Negócios, a alteração do pedido será permitida, para solicitar o pedido de Reenvio da Pré-Autorização.

1. A rotina deverá apresentar o motivo da rejeição ao usuário (CAMPO PCFILAMAISNEGLOG.MOTIVOREJEICAO).
2. Para a Cobrança igual a Supplier (codcob = SUPP), a rotina deverá incluir novo registro para envio a Supplier  (PCFILAMAISNEGENVIO.TIPOINF = 1).
3. O usuário devera efetuar as alterações necessárias do pedido, conforme o motivo da rejeição;
4. Incluir um novo registro na PCFILAMAISNEGLOG, com o campo IDPCFILAMAISNEGENVIO.

REGRAS GERAIS de ATUALIZAÇÃO DA 336

4. Para as opções de Desconto financeiro e Desconto/Acréscimo: se a Cobrança for supplier (CODCOB = SUPP), a rotina deverá desabilitar este botão de desconto financeiro, pois ficou acordado que o processo de desconto financeiro ou bonificação será realizado direto na plataforma do mais negócios.

5. Alterar todos os pontos da rotina que realiza a validação do limite disponível interno, para desconsiderar os pedidos que estão na cobrança SUPP, pois estes pedidos são do limite Supplier, logo não podem entrar no cálculo do limite disponível.

6. Ao solicitar a edição de um pedido Liberado pelas regras internas da 336 e pela Supplier (SUPP), o sistema deverá bloquear a sua edição/alteração, quando o mesmo for de CODCOB =  SUPP, para os campos abaixo.

6.1 Campo que precisam ser bloqueados quando a Cobrança for Supplier (CODCOB = SUPP), cujo o Status interno e Mais Negócios esteja Liberado.

1. Desconto Financ.
2. Cobrança
3. Despesas Rodapé
4. Simulador
5. Cobrança todos os pedidos
6. Entrega/Obs
7. Subs. Produtos
8. Alterar plano de pagamento
9. Abatimento
10. Desconto/Acréscimo
11. Indenizações/Troca
12. Incluir produto/Aut
13. Simulador com frete
14. Incluir Item
15. Quantidade
16. Preço

7 - Se o cliente não puder realizar compras a prazo ( PCCLIENT.PERMITEFATURARAPRAZOMAISNEG ='N'), a rotina não poderá apresentar os planos de pagamento com Venda a Prazo em cobranças internas e se o Status do cliente na supply (PCCLIENT.STATUSMAISNEG) for bloqueado o cliente não pode realizar vendas a prazo com a cobrança Mais negócio (codcob = SUPP) ;

• Neste caso deve ser apresentado somente o plano de pagamento que possui o Prazo Médio = 0 , ou seja, o plano de pagamento A Vista.
• Quando a Cobrança por de Limite Interno: a Validação de liberação de VENDA A PRAZO, deve ser realizada para todas as Origens de Venda e Tipos de Venda. E se está bloqueado na Supplier para vender a prazo, também não pode vender no limite interno.
  8 - Se o cliente pode realizar compras a prazo ( PCCLIENT.PERMITEFATURARAPRAZOMAISNEG = 'S'), a rotina poderá apresentar os planos de pagamento com Venda a Prazo e A Vista ;
• Se a cobrança for Supplier (SUPP), deverá ser apresentado o Plano de Pagamento A Vista e os Planos de Pagamento configurados para a Cobrança na Aba (Relacionar Cobrança x Plano de Pagamento, da rotina 523)

9. Caso o campo PCCLIENT.dataHoraConsultaMaisNegocios seja nulo ou tenha diferença de mais de uma hora em relação a hora atual, os seguintes campos não devem ser utilizados e eles devem ser substituídos por consulta na API do mais negócio:

PCCLIENT.PERMITEFATURARAPRAZOMAISNEG -> (realizar chamada do serviço do WTA, que será criado na história DMAISNEG-27).
API :http://localhost:8080/api/maisnegocios/v1/venda/customers/installment_sale
PCCLIENT.LIMITELIBERADOMAISNEG -> (história para construção do serviço para retornar o limite disponível DMAISNEG-28)
API: http://localhost:8080/api/maisnegocios/v1/venda/customers/purchase_limit
PCCLIENT.STATUSMAISNEG -> Mesma api do campo PCCLIENT.LIMITELIBERADOMAISNEG
Obs. Não pode fica fixo localhost:8080, tem que pegar da 132, parametro do WTA

Informações adicionais idenfiticadas depois do desenvolvimento:

A 336 sempre deve consultar a API e nunca validar os campos da PCCLIENT

03. SOLUÇÃO

CÓDIGO - NOME DA ROTINA

• 336

*VERSÃO PARA TESTE:

• 30.4.0.169

*ALTERAÇÃO EFETUADA NA ROTINA:

• Adaptado a rotina para trabalhar no projeto Mais Negócio
• Não será possível mudar uma cobrança qualquer para a cobrança SUPP
• Poderá do SUPP mudar para outra cobrança, quando o mesmo não tiver sido aprovado
• Ao escolher uma forma de pagamento e a cobrança for SUPP validar se pode usar plano a vista ou a prazo
• Desabilitar algumas funções da tela.
• Liberação do pedido usando o limite do Mais Negócio

04. DEMAIS INFORMAÇÕES

05. ASSUNTOS RELACIONADOS

• Como atualizar as rotinas do WinThor?