Melhoria:
Agora o PDV identifica corretamente de qual marketplace vem o desconto aplicado no pedido. Quando um desconto é enviado pelo parceiro, o sistema passa a reconhecer automaticamente o marketplace de origem e vincular à forma de pagamento correta. Isso evita confusão entre descontos de parceiros diferentes, melhora a clareza no fechamento da venda e garante maior controle financeiro para a loja.

Expandir
title Como configurar
1️⃣ Cadastrar as receitas por marketplace Na retaguarda, cadastre uma receita do tipo HUB_OUTROS para cada marketplace utilizado pela loja. Sugestão de nomenclatura: HUB OUTROS IFOOD HUB OUTROS KEETA HUB OUTROS 99 FOODS Isso facilita a identificação no PDV e nos relatórios. 2️⃣ Configurar os dados de integração da receita Em cada receita criada: Informe o Código de Integração Delivery como: HUB_OUTROS Selecione o Marketplace correspondente àquela receita. Cada marketplace deve ter sua própria receita vinculada. 3️⃣ Integrar o cardápio no PDV Após configurar as receitas: Gere um novo cardápio na retaguarda Atualize o cardápio no PDV Esse passo é essencial para que o PDV reconheça corretamente as novas configurações. 4️⃣ Funcionamento esperado Quando o pedido chegar com desconto do parceiro, o sistema identifica automaticamente o marketplace. O desconto é aplicado na receita correta, conforme o marketplace configurado. Caso não seja possível identificar o marketplace, o sistema utiliza a receita padrão configurada, garantindo que o pedido não seja bloqueado.

Melhoria:
O PDV passou a reconhecer corretamente o tipo de documento do cliente em pedidos recebidos pelo iFood. A partir dessa melhoria, o sistema identifica se o documento informado é um CPF, CNPJ ou documento estrangeiro e utiliza essa informação corretamente na emissão do cupom fiscal. Isso garante mais conformidade com as informações enviadas pelo parceiro e evita inconsistências na identificação do cliente.

Problema:
No pagamento parcial de vendas com produtos de rodízio com desconto, alguns comportamentos incorretos podiam ocorrer. Após o primeiro pagamento parcial, os itens deixavam de ficar agrupados corretamente, os valores unitários eram exibidos de forma incorreta e o total do fechamento parcial ficava errado. Em casos de vários pagamentos parciais, podia ocorrer um erro crítico ao selecionar os itens. Esse problema aparecia apenas na tela de seleção para o pagamento parcial e não ocorria em vendas sem desconto.

Correção:
O processo de retorno à tela de pagamento parcial foi ajustado para recarregar automaticamente a venda antes da seleção dos itens. Com isso, os produtos permanecem corretamente agrupados, os valores são recalculados de forma adequada e o pagamento parcial passa a funcionar normalmente, mesmo quando há desconto aplicado.

Problema:
Durante a tentativa de fechamento parcial da venda, o sistema apresentava erro na tela, impedindo a conclusão da operação. Em alguns casos, a tela travava sem exibir nenhuma mensagem para o operador, mesmo com a venda não sendo finalizada corretamente.

Correção:
O processo de fechamento parcial foi ajustado para evitar falhas durante a finalização da venda. Com isso, o sistema passa a tratar corretamente esse cenário, evitando travamentos e permitindo que o fechamento parcial seja concluído de forma estável e segura para o operador.

Problema:
Pedidos enviados pelo tablet da Goomer estavam sendo recebidos de forma incompleta no Degust PDV quando eram feitos para mesas que já estavam abertas. Nesses casos, alguns itens não apareciam na mesa, não eram enviados para produção e não eram impressos no momento do pedido, sendo registrados apenas no fechamento da mesa. Isso gerava inconsistência no atendimento e confusão na operação.

Correção:
O sistema passou a identificar claramente quando uma mesa está bloqueada por outro dispositivo do PDV. Além disso, a mensagem de retorno foi ajustada para informar de forma clara que a mesa já está em uso e não pode ser acessada naquele momento. Com isso, integrações como a Goomer conseguem tratar corretamente a situação, evitando o envio parcial de itens e garantindo mais estabilidade e previsibilidade na operação.

Problema:
De forma esporádica, ao lançar produtos pelo mobile ou pela Goomer em vendas por cartão com informação adicional, o número do cartão impresso na produção aparecia como 0. Isso causava confusão na cozinha e dificultava a identificação correta do pedido.

Correção:
O processo de identificação do cartão foi ajustado para garantir que o número impresso corresponda corretamente ao cartão utilizado na venda. Com isso, os lançamentos feitos pelo mobile ou pela Goomer passam a imprimir o número correto do cartão na produção, evitando inconsistências e garantindo mais clareza e organização no atendimento.

Problema:
Quando a opção de utilizar informação adicional estava ativada na venda por cartão, o cupom de produção era impresso fora do padrão. Nessa situação, o número do cartão aparecia com fonte menor, deslocado para o final do cupom e sem destaque, dificultando a identificação da comanda pela equipe de produção.

Correção:
A impressão do cupom de produção foi ajustada para exibir corretamente o número do cartão e o controle no topo da comanda, mantendo o padrão visual utilizado normalmente. Com isso, a identificação do cartão volta a ficar clara e em destaque, mesmo quando a opção de informação adicional está ativada.

Problema:
Em vendas delivery integradas pelo iFood, quando o pedido chegava com o CPF do cliente preenchido, mas com o telefone incompleto, a NFC-e era emitida em contingência. Isso ocorria porque o sistema tentava enviar o telefone incompleto, impedindo a transmissão normal da nota. Para contornar, o operador precisava editar manualmente o cadastro do cliente e preencher um telefone fictício, gerando retrabalho e atrasos na operação.

Correção:
O tratamento das informações do cliente foi ajustado para validar o telefone antes da emissão da NFC-e. Agora, o telefone só é enviado quando estiver válido. Com isso, a nota fiscal pode ser transmitida normalmente mesmo quando o pedido chega com telefone incompleto, eliminando a necessidade de ajustes manuais e evitando contingência indevida.

Problema:
Em algumas vendas delivery integradas pelo Voxline, pedidos chegavam ao Degust PDV com valor de troco indevido, mesmo não existindo troco nesse tipo de venda. Isso gerava inconsistências financeiras, como lançamentos incorretos no dinheiro, saldo negativo no fechamento de caixa e divergências em relatórios e no borderô. O comportamento ocorria de forma esporádica, dificultando a identificação do problema.

Correção:
Foram incluídos controles adicionais para identificar e registrar situações anormais, ajudando a prevenir novas inconsistências e facilitando a análise caso o cenário volte a ocorrer.

Problema:
Lojas não conseguiam realizar a subida de vendas via SVO quando existia item com quantidade acima do limite suportado pelo campo numérico, gerando Arithmetic Overflow durante a consolidação.

Correção:
Criação de blindagem para impedir lançamento de quantidades superiores a 99.999,99, evitando que vendas inválidas cheguem ao SVO e causem falha de processamento.