01. DADOS GERAIS

02. SITUAÇÃO/REQUISITO

Ao resgatar um pedido no PDV Omni que não possui forma de pagamento associada, o sistema permite remover a tela de seleção de forma de pagamento utilizando a tecla ESC. Entretanto, o botão Pagar permanece desabilitado, obrigando o operador a abandonar o pedido e resgatá-lo novamente.

Esse comportamento foi identificado nas versões 4.1 e 4.2 do sistema. Na versão 4.0, o menu lateral de pagamento não é carregado e o botão Pagar já vem habilitado, permitindo a continuidade da operação.

03. SOLUÇÃO

Visão Negocial

Foi identificado que o problema acontecia porque o PDV entendia, em algumas situações, que o pedido não poderia ser editado durante o resgate. Isso fazia com que os botões da tela de pagamento ficassem desabilitados, impedindo a continuidade do processo.

Ajustamos a regra que define quando um pedido resgatado pode ser editado ou não. Com essa correção, o PDV agora:

• • Se o pedido resgatado pode ser editado:

    • O operador consegue acessar a tela de itens com o botão Pagar habilitado.

    • É possível voltar para a tela de itens tanto pelo botão Voltar quanto pela tecla ESC.

  • Se o pedido resgatado não pode ser editado:

    • O sistema já abre direto a tela de formas de pagamento.

    • Os botões Voltar e a tecla ESC ficam desabilitados, garantindo que o fluxo fique na finalização do pagamento.

Esse ajuste garante que o comportamento do sistema seja consistente com a configuração definida, evitando que o operador precise abandonar e resgatar o pedido novamente.

Visão Técnica

A análise apontou que o problema estava relacionado à propriedade PermiteEdicaoPedido, localizada na classe DesktopPagamentoViewModel, que era avaliada incorretamente devido à forma como a variável BloquearAlteracaoCondicaoPagamento era tratada.

Ajuste realizado

• • Foi removida a negação (!) da variável BloquearAlteracaoCondicaoPagamento na composição da propriedade PermiteEdicaoPedido.

  • Além disso, no método VoltarTelaCarrinho, foi adicionada uma condição para que, quando PermiteEdicaoPedido estiver definido como false, a ação de voltar (tecla ESC ou botão Voltar) não execute nenhuma operação.

04. DEMAIS INFORMAÇÕES

Como o PermiteEdicaoPedido funciona

A propriedade PermiteEdicaoPedido define se um pedido resgatado pode ou não ser editado. Ela é formada por duas partes que precisam estar verdadeiras ao mesmo tempo:

1. Uma verificação que impede a edição em casos muito específicos de resgate.

2. Uma regra que considera as condições de pagamento e integração do pedido.

   1) Bloqueio de edição no resgate

   O sistema considera três fatores juntos:

   • Se o parâmetro 180 (Permite incluir itens no recebimento de pedido no PDV) está desligado.

   • Se o tipo da pré-venda é Pedido.

   • Se o pedido está sendo resgatado.

   Quando essas três condições acontecem ao mesmo tempo, a edição é bloqueada.
   Em qualquer outro cenário, essa parte não impede a edição.

   ---

   2) Alteração de condição de pagamento

   Além disso, existe a propriedade BloquearAlteracaoCondicaoPagamento, que pode bloquear ou liberar a edição dependendo de algumas situações. Ela fica ativa (true) em dois casos:

   • Integração com Retaguarda: quando o pedido veio de outro sistema (origem retaguarda), tem um identificador de retaguarda e está na situação RECEBIDO.

   • Preço por condição de pagamento: quando o parâmetro 282 (Aplica preço por condição de pagamento) está ligado, o tipo é Pedido e o modo de operação não é “Pedido de Venda”.

   Se nenhum desses cenários acontece, essa regra fica inativa (false).

   3) Resultado final

   Combinando as duas partes, temos:

   • A edição só é permitida quando não estamos no triplo-bloqueio do resgate (parâmetro 180 desligado + Pedido + Resgate) e ao mesmo tempo estamos em um dos cenários que ativam a alteração de condição de pagamento (Retaguarda RECEBIDO ou Parâmetro 282 ativo).

   • Se qualquer uma dessas condições não for atendida, a edição fica bloqueada.

   Condições para o PermiteEdicaoPedido

   Parâmetros / Situação	Resultado	Explicação
   Parâmetro 180 = desligado + Tipo = Pedido + Resgate = true	❌ Não permite edição	Triplo-bloqueio ativo → sempre bloqueia a edição, independente dos outros fatores.
   Parâmetro 180 = ligado + Parâmetro 282 = ligado + Tipo = Pedido + Modo ≠ PedidoVenda	✅ Permite edição	Cenário de “Preço por condição de pagamento” → edição liberada.
   Integração com Retaguarda ativa (PDVSync = true, Origem = Retaguarda, Situação = RECEBIDO)	✅ Permite edição	Pedido vindo da retaguarda com status RECEBIDO libera a edição.
   Parâmetro 180 = ligado, mas Parâmetro 282 = desligado e sem Retaguarda	❌ Não permite edição	Não há bloqueio inicial, mas também não há regra que libere a edição.
   Parâmetro 180 = desligado (independente dos demais)	❌ Não permite edição	Quando o triplo-bloqueio se confirma, a edição sempre é barrada.

Além disso:

• Quando o operador opta por clicar no botão Continuar Comprando em um pedido resgatado que pode editado e que já tenha a forma de pagamento escolhida, os pagamentos existentes são descartados, sendo necessário incluir manualmente um novo pagamento no momento de finalizar o pedido.

• Caso não seja possível editar um pedido resgatado que já tenha a forma de pagamento escolhida, o botão Continuar Comprando ficará desabilitado.

• Independentemente do cenário, o botão Abandonar Recebimento permanece disponível, permitindo ao operador sair do pedido e resgatar outro.

• A situação ocorrida na versão 4.0 foi possível devido a configuração dos parâmetros (que estavam diferentes nas versões 4.1 e 4.2), que permitia a edição do pedido, porém o comportamento do botão voltar continuava errado e somente foi percebido depois da correção.