|
|
Versão liberada em Versão mínima do PFWIN: 19.0.0 Versão mínima do LiveUpdate: 9.0.3 Versão mínima do PFCBI: 14.0.0 |
Orientações Importantes
O sistema de vendas da SmartPOS deve garantir o envio correto do NSU para a retaguarda.
O NSU utilizado na conciliação deve ser o NSU correto da transação, evitando divergências entre sistemas.
O campo NSUlocal não deve ser utilizado como referência para conciliação quando houver inconsistência com o NSU da transação.
A integração com a Getnet via SmartPOS deve seguir o NSU oficial retornado na autorização da venda.
Pontos de Atenção
Foi identificada inconsistência na captura do NSU durante o fluxo de venda.
Em alguns casos, o sistema estava utilizando o valor do NSUlocal (ex.: 013518), em vez do NSU correto da transação.
Essa divergência impactava diretamente a conciliação, gerando duplicidade de vendas na retaguarda.
Exemplo identificado:
NSU correto: 22703
NSU local incorreto: 013518
Autorização: 21171
Valor: R$ 150,00
Problema Corrigido
Correção aplicada no fluxo de vendas da Getnet via SmartPOS.
O sistema agora passa a utilizar o NSU correto da transação, evitando duplicidade de vendas.
Ajuste garante consistência entre a venda registrada e a conciliação na retaguarda.
A correção foi validada em ambiente piloto, apresentando funcionamento conforme esperado.
Benefícios
Eliminação de duplicidade de vendas na retaguarda.
Maior precisão no processo de conciliação financeira.
Redução de inconsistências entre SmartPOS e retaguarda.
Aumento da confiabilidade dos dados de transações.
Melhoria na estabilidade e rastreabilidade das vendas realizadas via Getnet.
2 - (POSTOSPF-17213) - Saldo remanescente incorreto após lançamento com cupom fiscal.
Orientações Importantes
O problema ocorre principalmente em clientes sem automação.
Recomenda-se atenção ao processo de lançamento com emissão de cupom fiscal.
Como alternativa temporária (paliativa), é possível manter a versão 15.1.2, onde o problema não ocorre.
Pontos de Atenção
Ao emitir cupom fiscal, o valor estava sendo lançado diretamente no encerrante final.
Esse comportamento causava divergência no saldo remanescente.
A inconsistência era semelhante a casos de falta de documento fiscal.
É importante validar o saldo após operações para garantir consistência.
Problema Corrigido
Foi corrigido um erro no lançamento de saldo remanescente.
Em alguns cenários, o sistema incrementava indevidamente o encerrante final ao emitir cupom fiscal.
Isso gerava divergências na quantidade e no valor do saldo remanescente.
Após o ajuste, testes confirmaram o funcionamento correto:
Saldo inicial: 10,00 litros
Após duas vendas: saldo remanescente de 8,000 litros
Os valores e quantidades passaram a ser calculados corretamente, sem inconsistências.
Benefícios
Maior precisão nos lançamentos.
Eliminação de divergências no saldo remanescente.
Correção de inconsistências relacionadas à emissão de cupom fiscal.
Mais confiabilidade nas informações fiscais.
3 - (POSTOSPF-17219) Implementar funcionalidade de armazenamento de logs do aplicativo - Jira Linx
Orientações Importantes
O app passa a permitir o envio automático de logs para a retaguarda, conforme configuração recebida via settings.
A retaguarda deve informar:
Se está habilitada para receber logs
O intervalo de envio (em milissegundos)
O tempo de timeout para resposta (em milissegundos)
Caso não haja configuração da retaguarda, o envio continuará ocorrendo apenas para a monitoria, conforme fluxo atual.
O envio manual de logs pelo menu de configurações continuará disponível, respeitando a prioridade:
Retaguarda (se habilitada)
Monitoria (caso contrário)
A retaguarda deve disponibilizar a rota /v1/log/ para recebimento dos logs via requisição POST.
Pontos de Atenção
O envio automático de logs será pausado durante fluxos críticos, como venda e pagamento, para evitar conflitos de requisição.
Durante a pausa, os logs continuarão sendo armazenados normalmente.
Logs não enviados poderão ser transmitidos posteriormente:
No próximo intervalo automático
Ou via envio manual nas configurações
O app aguardará resposta da retaguarda conforme o tempo de timeout configurado.
É responsabilidade da retaguarda gerenciar o armazenamento e processamento dos logs recebidos.
Problema Corrigido
Correção no envio de logs internos do app (Smart), que apresentava falhas e impactava a análise de erros.
Ajuste realizado para garantir maior consistência e confiabilidade das informações enviadas.
A correção foi validada em ambiente piloto com cliente, apresentando funcionamento conforme esperado.
Benefícios
Maior controle da retaguarda sobre o recebimento de logs (frequência e disponibilidade).
Redução no volume de dados enviados, transmitindo apenas logs novos (desde o último envio bem-sucedido).
Melhor desempenho nas requisições, tornando os envios mais rápidos e eficientes.
Aumento da confiabilidade na análise de erros com logs mais consistentes.
Limpeza automática de logs antigos (mais de 15 dias), evitando acúmulo desnecessário no dispositivo.
4 - (POSTOSPF-17172) - Valor do IBS e CBS informado indevidamente.
Orientações Importantes
O parâmetro DataAtivacaoCBSIBSSimplesNacional define quando passa a ser obrigatório o destaque de CBS/IBS para postos optantes pelo Simples Nacional.
A data é configurada no ADM Restrita, seguindo determinação do governo.
Após essa data, o sistema aplica automaticamente a regra no caixa ao realizar login.
Pontos de Atenção
Se o parâmetro no caixa estiver desmarcado, o destaque de CBS/IBS não será realizado.
Após a data de ativação, o sistema fará o flag automático no login do caixa.
É importante garantir que a configuração no ADM Restrita esteja correta para evitar inconsistências.
Problema Corrigido
Foram identificadas inconsistências no MID-e ao realizar o destaque de CBS/IBS, gerando erros.
O comportamento anterior não respeitava corretamente a vigência configurada no parâmetro.
Benefícios
Melhor controle da vigência do parâmetro.
Adequação automática às exigências governamentais.
Redução de erros no MID-e relacionados ao destaque de CBS/IBS.
Maior confiabilidade no processo de emissão.
|
