Histórico da Página
...
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.
Foram identificados dois problemas
- Não havia o tratamento no método para voltar para o carrinho ao pressionar a tecla ESC.
- A verificação de Bloqueio de Edição de Pedido não estava levando em consideração o parâmetro 282 - Aplica preço por condição de pagamento?
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 propriedadePermiteEdicaoPedido. Além disso, no método VoltarTelaCarrinho, foi adicionada uma condição para que- No método VoltarTelaCarrinho, quando
PermiteEdicaoPedidoestiver 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:
...
Uma verificação que impede a edição em casos muito específicos de resgate.
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:
- Incluído a verificação do Bloqueio de Edição do Pedido no construtor da Classe
DesktopPagamentoViewModel
- Teste com o parâmetro 282 - Aplica preço por condição de pagamento? Desligado (Deve permitir a edição do Pedido Resgatado)
- Teste com o parâmetro 282 - Aplica preço por condição de pagamento? Ligado (Não deve permitir a edição do Pedido Resgatado)
- Teste com o Parâmetro 180 - Permite incluir itens no recebimento de pedido no PDV? Desligado (Não deve permitir a edição do pedido resgatado, independente do valor do parâmetro 282)
04. DEMAIS INFORMAÇÕES
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.
Visão Geral
Import HTML Content
Conteúdo das Ferramentas
Tarefas