| Produto: |
|
|---|---|
| Linha de Produto: | |
| Segmento: |
|
| Módulo: |
|
| Função: | Resgate de Pedido |
| País: | Brasil |
| Ticket: | |
| Requisito/Story/Issue (informe o requisito relacionado) : |
Pedidos classificados como "Recebimento Antecipado" possuem regras comerciais que exigem que eles sejam pagos e faturados exatamente como foram criados, sem alterações no PDV.
A necessidade é garantir que pedidos de Recebimento Antecipado nunca possam ser editados no PDV, independentemente da configuração do Parâmetro 180 ("Permite incluir itens no Recebimento do pedido no PDV").

Visão Negocial Com esta correção, o sistema passa a tratar o Recebimento Antecipado como uma regra prioritária. Ao resgatar um pedido no PDV que esteja marcado como "Recebimento Antecipado":
O sistema irá bloquear totalmente a edição do pedido.
O operador será direcionado diretamente para a tela de pagamento, não sendo possível acessar a tela de itens, alterar o cliente ou mudar o tipo de negociação.
Isso garante que, mesmo que a loja permita edições em pedidos comuns (Parâmetro 180 ligado), os pedidos de Recebimento Antecipado seguirão seu fluxo correto de pagamento e faturamento, mantendo a integridade da operação.
Visão Técnica A lógica de bloqueio de edição no resgate da pré-venda (pedido) foi ajustada.
Anteriormente, o bloqueio (BloqueiaEdicaoPedido = true) só ocorria se o Parâmetro 180 estivesse desabilitado.
A alteração introduziu uma nova verificação: recebimentoAntecipado. Agora, o sistema verifica duas condições para bloquear a edição:
Se o Parâmetro 180 está desabilitado (comportamento antigo mantido).
OU se o pedido resgatado possui a property RecebimentoAntecipado como true.
Dessa forma, a flag ConfiguracaoDispositivoModel.BloqueiaEdicaoPedido é ativada se qualquer uma dessas condições for verdadeira, forçando o fluxo de pagamento (ExibeTelaPagamento = true) para todos os pedidos de Recebimento Antecipado.
O critério de aceite que mencionava uma mensagem de erro ("Não é permitido alterar o tipo de negociação...") foi atendido de forma funcional: como o operador não tem acesso à tela de edição, ele é impedido de realizar a ação, não sendo necessária uma mensagem de bloqueio específica.