Histórico da Página

...

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