Sumário das Issues:

Melhoria:

Foi implementada uma melhoria no módulo Venda Cartão do Degust PDV, permitindo que a taxa de serviço deixe de ser fixa em 10% e passe a ser configurável por loja.

Com essa alteração, o sistema passa a utilizar o parâmetro valorTaxaServicoCartao para calcular a taxa de serviço, possibilitando definir qualquer percentual conforme a necessidade da operação (ex.: 12%).

Também é possível configurar se a taxa será aplicada como acréscimo direto na venda ou por meio de um produto específico, garantindo maior flexibilidade para diferentes modelos de operação em restaurantes.

Melhoria:

Foi implementada uma melhoria na integração com pedidos realizados via tablet (ex.: Goomer) para melhorar a identificação do cliente na operação.

Anteriormente, a informação adicional do cartão e a área da mesa eram exibidas apenas na impressão de produção, não aparecendo no KDS, o que dificultava a localização do cliente pela equipe.

Com essa melhoria, essas informações passam a ser exibidas no cabeçalho dos pedidos no KDS, tanto no modo Automático quanto Por Área/Pedido, permitindo que a equipe identifique com mais facilidade onde o cliente está localizado no estabelecimento e agilize o atendimento.

Melhoria:

Foi realizada uma atualização fiscal no sistema para atender à Instrução Normativa SEE nº 1.615/2025, publicada no Diário Oficial do Estado de Goiás.

Com essa alteração, foram incluídos na tabela do sistema os códigos de benefício fiscal (cBenef) específicos do estado de GO, garantindo que as operações fiscais realizadas no PDV estejam adequadas às novas exigências da legislação estadual.

Problema:
Ao executar a função “Executar todos os scripts do sistema”, o Degust PDV estava reenviando desnecessariamente todas as vendas para o SVO, ocasionando reprocessamentos indevidos na integração.

Correção:
Realizada melhoria de performance na tela de “Consulta Integração Degust One”, além de ajustes para evitar alterações na tabela de vendas durante o reset da execução dos scripts. Também foram removidos scripts de atualização, impedindo o reenvio indevido das vendas.

Problema:

O finalizador auxiliar do AA One estava configurado na retaguarda como Master Débito, porém mesmo após gerar novo cardápio e atualizar o PDV, o sistema continuava exibindo ELO Crédito, fazendo com que as vendas do Autoatendimento fossem registradas no finalizador incorreto.

Correção:
Ajustado o processo de sincronização do finalizador auxiliar entre a retaguarda e o PDV. Após a correção, o sistema passa a atualizar corretamente o finalizador configurado, garantindo que as vendas do Autoatendimento sejam registradas no meio de pagamento correto.

Problema:

Em alguns casos, após a transação TEF ser concluída com sucesso, a venda estava sendo cancelada automaticamente pelo PDV, impedindo a emissão do cupom fiscal. Como a loja utiliza o módulo de venda cartão, a comanda já se encontrava finalizada, gerando inconsistência no processo de venda.

Correção:
Ajustado o tratamento de vendas em cenário de contingência para garantir a geração correta da nota espelho e evitar o cancelamento indevido da venda após a aprovação da transação TEF. Também foram realizados ajustes internos para melhoria do funcionamento do sistema.

Problema:
Foi identificada uma divergência entre as informações registradas na nota fiscal e os itens enviados para a produção, ocasionando inconsistência entre o que foi vendido e o que foi encaminhado para preparo.

Correção:
Ajustado o controle interno de reconexão do sistema para evitar conflitos durante o processamento simultâneo de operações. Com isso, foi eliminada a possibilidade de envio duplicado de comandos para a produção, garantindo que os itens sejam encaminhados corretamente.

Problema:
Foi identificada uma divergência de valores no relatório de fechamento de caixa, onde o resultado operacional apresentado estava maior que o valor da contagem de numerários exibida pelo sistema.

Correção:
Ajustada a regra de cálculo do relatório para considerar corretamente os descontos das vendas, garantindo que os valores apresentados no fechamento de caixa reflitam fielmente as operações realizadas.

Problema:
Uma venda foi finalizada no PDV, porém não houve geração da nota fiscal. A análise dos logs identificou a ocorrência de um erro de deadlock durante o processo de emissão da nota no módulo de venda cartão, causado por transações concorrentes que tentavam atualizar os mesmos registros simultaneamente.

Correção:
Realizado ajuste no processo de atualização dos registros para garantir uma ordem consistente de execução, evitando conflitos entre transações simultâneas. Também foi corrigido o controle de transações no fluxo de processamento da venda, garantindo que elas sejam concluídas corretamente e eliminando a possibilidade de deadlock durante a geração da nota fiscal.

Problema:
Foi identificada uma venda registrada no sistema sem forma de pagamento vinculada, o que gerou divergência nos valores apresentados no fechamento de caixa.

Correção:
Implementado mecanismo de retentativa automática do processo em casos de conflito de transação (deadlock), realizando até três novas tentativas com pequenos intervalos entre elas. Também foi mantida a validação para que outros tipos de erro continuem sendo reportados normalmente, garantindo a integridade do processo.

Problema:
Foi identificada uma divergência entre a contagem de numerários e o valor da nota fiscal. A situação ocorreu porque a venda possuía nota fiscal gerada, porém não havia finalizador registrado na venda, resultando em valores diferentes entre o controle de numerários e o documento fiscal. Esse cenário ocorreu de forma específica após um erro no momento de finalização da venda, logo após a transmissão da nota.

Correção:
Implementada uma validação para impedir a remoção dos finalizadores quando a venda já possuir nota fiscal transmitida, evitando inconsistências entre os valores da venda e da nota fiscal.

Problema:
Foi identificada uma venda de mesa que permaneceu com status de finalizada no sistema, porém sem geração de nota fiscal e sem registro de pagamento, resultando no lançamento incorreto como Outras Moedas no Borderô. Esse comportamento gerava divergência no controle financeiro, pois vendas canceladas ou finalizadas não estavam sendo registradas corretamente no fechamento.

Correção:
Realizado ajuste no controle de atualização do mapa de mesas para evitar interferências durante o processo de finalização da venda. O timer responsável pela atualização do mapa passa a ser desativado ao acessar a mesa e reativado ao sair, garantindo que o fluxo de finalização ocorra corretamente e evitando inconsistências no registro da venda.

Problema:
Foi identificado que o campo TRP_CODIGO, presente na base de dados em bases antigas, ainda estava preenchido para alguns produtos. Mesmo não sendo mais utilizado na interface há anos, o sistema ainda considerava esse campo no direcionamento dos pedidos. Com isso, quando o campo possuía valor diferente de zero, o pedido era enviado apenas para uma estação específica, ignorando as configurações atuais de roteamento de produção. Esse comportamento causava direcionamento incorreto de pedidos e impactava a operação em ambientes com KDS.

Correção:
Aplicado ajuste para desconsiderar o uso desse campo nos produtos existentes. Foi feito um update para limpar os valores antigos, garantindo que o direcionamento dos pedidos passe a respeitar apenas as configurações atuais de roteamento da operação. A correção foi incorporada à versão 3.0.49.49.

Problema:
Foi identificado que vendas realizadas por operadores com nomes superiores a 20 caracteres não eram exibidas no relatório “Vendas por Pessoa” no Degust One. Esse comportamento ocorria porque o nome do operador era gravado de forma truncada no momento da venda, impedindo que o relatório identificasse corretamente o vínculo com o usuário.

Correção:
Realizado ajuste para ampliar o limite de caracteres do nome do operador armazenado nas vendas, garantindo que nomes maiores sejam gravados corretamente. Com isso, as vendas passam a ser reconhecidas normalmente pelos relatórios do sistema.