Produto
Degust PDV Delphi
Versão

FileVersion: 3.0.48.18

ProductVersion: 3.0.48.18

PrivateBuildStr: 0002

SpecialBuildStr: Versão Oficial

Segmento Linx
Food
Data da Release

Responsáveis





🧩 Resumo:

A versão 3.0.48.18 entrega correções importantes para estabilidade e operação do Degust PDV, com foco na emissão fiscal, jornadas com produtos de rodízio e comunicação com a Sefaz. Destacam-se ajustes no campo de protocolo da nota, melhorias no envio de notas no estado do Paraná, correção de falhas ao utilizar DLLs, além de maior confiabilidade em integrações com sistemas como Goomer e Gerenciador Mobile. As melhorias visam garantir fluidez no atendimento, evitar rejeições fiscais e manter a rastreabilidade das vendas.


 


Sumário das Issues:


ISSUE

RESUMO

TIPO

DETALHES

FOOD-40926

Aumentar o campo VNE_PROTOCOLO da tabela VENDANFE

Problema: A nota fiscal era enviada normalmente para a Sefaz, mas não estava sendo salva no banco de dados por causa de um erro no campo VNE_PROTOCOLO, que era pequeno demais para o novo formato. A mudança estava prevista para outubro, mas a Sefaz alterou antes e depois voltou ao formato antigo.

Correção: O campo VNE_PROTOCOLO foi aumentado para 30 caracteres, garantindo que a nota seja salva corretamente mesmo com possíveis mudanças futuras.

FOOD-40888

Melhoria Robô Transmissão de notas - Paraná

Problema: Lojas no estado do Paraná enfrentavam falhas na transmissão de notas fiscais, resultando em bloqueios pela Sefaz devido a múltiplas tentativas automáticas de envio. Também foram identificados arquivos de log muito grandes e falhas na comunicação com o sistema de envio.

Correção:

  • Corrigido erro ao tentar reiniciar a comunicação após falhas consecutivas.

  • Reduzida a quantidade de dados gravados nos logs.

  • Adicionado registro de falhas em uma tabela específica para facilitar o monitoramento.

FOOD-40845

PRODUTOS RODIZIO / SABORES RODÍZIO

Problema: O sistema não estava relacionando corretamente dois produtos necessários para o funcionamento do rodízio. Isso gerava divergências nos fechamentos parciais, com quantidades incorretas de itens lançados ou ausentes em alguns pagamentos.

Correção: Ajustada a lógica de distribuição dos itens do rodízio no pagamento parcial, que agora é feita com base na média entre os itens participantes e os produtos de rodízio.

FOOD-40713

Não foi possível realizar a requisição ao servidor via DLL.

Problema: Após a atualização para a versão 48.12, as vendas com o Sem Parar pararam de funcionar. Mesmo com a DLL correta, o sistema apresentava erro ao tentar se comunicar com ela.

O problema era causado por cópias da DLL espalhadas em várias pastas da máquina, o que confundia o sistema na hora de carregá-la.

Correção: Foi ajustado o sistema para que, em modo normal, sempre utilize a DLL da pasta C:\DegustWin. Isso evita conflitos e garante que a versão correta seja usada.

FOOD-40658

Numero de telefone extenso rejeitando notas

Problema: Pedidos de delivery estavam sendo importados com telefones de clientes muito longos, incluindo números 0800. Isso causava erro na emissão da nota fiscal.

Correção: Foi ajustado o sistema para ignorar números 0800 ao importar os telefones dos clientes, evitando rejeição na emissão da nota fiscal.

FOOD-40639

Gerenciador Mobile Travando

Problema: O Gerenciador Mobile estava abrindo várias instâncias ao mesmo tempo e parava de enviar pedidos, tanto pelo Degust Mobile quanto pelo Abrahão. Para voltar a funcionar, era necessário reiniciar a aplicação manualmente. Isso acontecia porque o sistema não finalizava corretamente quando solicitado.

Correção: Foi ajustado o processo de encerramento da aplicação para que ela aguarde a finalização das tarefas em andamento, garantindo que o sistema feche corretamente e evite falhas no envio de pedidos.

FOOD-40652

Controle ps_NomeIntegracao

Ajustado para que integrações da Goomer sejam corretamente identificadas nos campos de origem e dispositivo da venda, e essas informações sejam enviadas à retaguarda.

FOOD-40583

Tipo de venda que iniciou e finalizou o pedido

Melhoria para registrar separadamente o tipo de venda na abertura e no fechamento do pedido, preservando ambos os dados em campos distintos para todos os modos de venda, garantindo histórico correto mesmo quando o fechamento é feito pelo PDV.