Problema: Ocorreu uma diferença na forma como os itens foram impressos na NFCe de acordo com a origem de lançamento. Quando o lançamento foi realizado pelo Mobile o PDV imprimiu cada produto separadamente na NFCe.

Solução: Realizamos os mesmos testes utilizando as versões atualizadas do PDV e Mobile e o problema reportado não foi apresentado. Necessário atualizar para versão 3.0.40.06 ou superior.

Problema: Erro na promoção no momento da Atualização de Tabelas.

Solução: Validação de item de promoção na atualização de tabelas, para não gravar horário de promoção sem item.

Problema:  A observação pré-definida não está sendo enviada para a produção

Solução: Geração de controle para as vendas.
A validação de controle pré-existente validava errado, porque ao sair da tela de venda mesa sempre fazia com que uma venda mesa tivesse controle repetido, mesmo que não tivesse. A validação tinha a intenção de evitar conflitos com o Mobile, no entanto ignorava o número do PDV.

Problema: Ao selecionar o combo utilizando a fidelidade Reshop e finalizar com Pede Pronto no momento do pagamento é aplicado o desconto da fidelidade Reshop + desconto do pede pronto, se cancelado o pagamento pede pronto o desconto desfaz, ficando apenas o desconto do fidelidade, em seguida a venda é finalizada com dinheiro, apresenta o erro de somatório e nota fica rejeitada.

Solução: Correção no calculo dos descontos acumulados em itens que são de combos e possuem mais de uma campanha aplicada.
Correção dos valores enviados para a nota, pois estava dando desconto do pede-pronto mesmo não sendo forma de pagamento pede-pronto.

Problema:  Cliente emitindo notas em contingência, a equipe do Fiscal Flow identificou que as notas estão (CONSUMO INDEVIDO) 

Solução:  Ajustado gravação de "Ativo" no diretório do servidor e ajustado validação de totalizador de nota após consulta no MID

Problema: Não consegue gravar informações no banco Degustlog.fdb

Solução: Alteração para gravar os log's do banco de dados DegustLog.FDB no arquivo de log's do SVC, pasta DegustLog

Problema: Mostrar o ven_controle do documento na tela de consulta de notas logo no inicio após a data, sem a necessidade de rodar a barra de rolagem até o final.

Solução: Alterado a posição da coluna ven_controle do final para a segunda posição. Adicionado também um "atalho" de CTRL + C na linha, para copiar as informações pertinentes para consultas (CAI_DATA, VEN_CONTROLE e NUMERO DOCUMENTO).

Problema:  Era apresentado um erro ao tentar finalizar algumas contas com Pede Pronto ("EMPTY_ZERO_NEGATIVE_BLANK_UNIT_PRICE").

Solução: Realizado tratamento na condição que verifica se o desconto e maior que 0, caso não seja ele ele zera o desconto para não enviar valor negativo para pede pronto.

Problema:  Ao tentar transmitir notas com produtos inativos era retornado uma mensagem de falha:
"Rejeição: Falha no schema XML
O elemento infNFe no espaço para nome apresenta elemento filho total no espaço para nome inválido. Lista possíveis elementos esperados: retirada, entrega, autXML, det no espaço para nome."

Solução: Alteração para considerar itens inativos na emissão da nota fiscal.

Solução: Ajustado Aplicação para trabalhar com caminho do arquivo "Ativo" na rede;

Problema: Ao tentar expedir o pedido no delivery era apresentado a mensagem "A soma das formas de pagamento e inferior ao total da venda".

Solução: Realizado uma correção na validação da soma das formas de pagamento com o total do pedido, que ignorava a taxa de entrega de terceiros.

Problema: Erro intermitente que causa um travamento ao finalizar venda com Pede Pronto.

Solução: Acionado logs no processo de finalizar venda com pagamento Pede Pronto, dessa forma será possível acompanhar a causa raiz do problema.

Problema: Erro intermitente que causava um problema no spooler do Windows, realizando varias impressões indesejadas.

Solução: Realizada melhoria na rotina para evitar impressões em loop infinito do pedido.

Problema: Ao realizar uma vendo, inserindo o CPF do fidelidade no final da venda, porem cancelando o cupom antes do final do fluxo do recebimento, o CPF do cliente ficava gravado em cachê e era lançado para a próxima venda.

Solução: Realizado correção na rotina, limpando o documento do cliente no cancelamento da venda.

Problema: Divergências de valores brutos no sistema quando comparado os valores do relatório de caixa diário no PDV, relatório de consulta de faturamento por data no PDV e relatório de vendas diário no Degust One. 

Solução:  Ajustado valor da venda,  gravando o valor bruto igualmente aos itens, já nos relatórios  foi ajustado o calculo do valor bruto para considerar o desconto Reshop.

Problema:  Apresentado divergência entre CAIXA DIARIO E VENDA HORA- HORA.

Solução: Realizado ajustes nas rotinas dos relatórios corrigindo a divergência apresentada.

Problema: O Degust PDV validava erroneamente se o cliente já existia na importação do Hub Delivery 2, pois considerava configurações que servem para o USPTAGE, o que ocasionava na atualização de cadastros de clientes que nada tinham a ver com o pedido;

Solução:  Agora o Degust PDV passa a validar também pelo ID do telefone quando houver, o problema se dava justamente nestas situações. Após a correção o Degust PDV vai inserir novos clientes ao invés de atualizar outros clientes não relacionados.

Problema: Erro intermitente que acontecia quando o usuário era notificado com a mensagem "Ocorreu erro durante a confirmação de dados. Portanto, eles serão perdidos. Lance-os novamente.", durante o uso do PDV, ao sair e entrar na mesa produto lançado sumiam da mesa, porém, era impresso a as comandas de conferencia. 

Solução:  Realizado uma serie de ajuste na rotinas para que, caso a mensagem seja disparada os cupons não sejam impressos.

Problema: Valores em categoria "DINHEIRO"  estavam divergentes entre a fita impressão do fechamento e relatórios.

Solução: Foi verificado que uma das rotinas de desconto não estava aplicando, sendo assim os valores não batiam e acabava sendo entendido que deveria ser gerado troco. O ajuste na rotina corrigiu o problema.

Realizado melhoria na rotina para que caso o PDV estiver ativo no QRLinx, mas a data do último Pos_ID for anterior à data atual, será feita uma nova solicitação de Pos_Id, e a data será atualizada para a data atual. Isso acontecerá antes de pagar via QRLinx;
Ao ativar o PDV na tela de cadastro de PDV, a data da última atualização do Pos_Id será atualizada, para isso é necessário salvar antes de sair da tela;

Alteração realizada para exibir a mensagem “O pagamento via QRCode será cancelado! Caso algum valor tenha sido debitado, a devolução do valor ocorrerá de forma automática em até 48 horas”, rotina realizada no cancelamento de cupom e também tela de pagamento por QrLinx.