Histórico da Página

Image Removed

1 - (POSTOSPF-16900) - NSU incorreto sendo replicado para o retaguarda e gerando duplicidade na conciliação de cartão 

2 - (POSTOSPF-17213) - Saldo remanescente incorreto após lançamento com cupom fiscal.

3 - (POSTOSPF-17219) Implementar funcionalidade de armazenamento de logs do aplicativo

4 - (POSTOSPF-17172) - Valor do IBS e CBS informado indevidamente.

1 - (POSTOSPF-16900) - NSU incorreto sendo replicado para o retaguarda e gerando duplicidade na conciliação de cartão 

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.