App de Captura

Histórico de versões do aplicativo de captura (POS Android).

v1.0.8 — 28/10/2026

Versão conjunta: SDK 1.0.8 e Aplicativo 1.0.8. O aplicativo desta versão requer o SDK 1.0.8.

Esta entrega concentra a estabilidade do fluxo de transação — operações que se sobrepunham, venda iniciada sem rede e venda durante a carga de tabelas —, o tratamento de terminais recém-ativados, a nova versão do Relatório de Vendas e a tela de Informações do Terminal. O pacote de instalação conclui a segunda etapa de redução de tamanho anunciada na versão 1.0.6.

Chamados atendidos nesta versão

Chamado	Assunto	Onde
0030524	Venda recusada com "Terminal carregando" durante a carga de tabelas	Venda e Pix
0030575	Terminal recém-ativado exibindo falha de conexão	Inicialização
0030511	Relatório de Vendas — crédito à vista e parcelado, cores dos gráficos	Relatório de Vendas
0030512	Relatório de Vendas — contagens da Resumida e estornos da Detalhada	Relatório de Vendas
0030481	Identificação do estabelecimento e informações do terminal	Informações do Terminal
0030510	Rodapé com versão, número de série e ICCID antes da ativação	Informações do Terminal

💳 Venda e Pix

Situação	Comportamento anterior	Comportamento atual
Nova operação iniciada enquanto a anterior ainda finaliza (por exemplo, Pix abandonado com consulta em andamento)	As duas operações podiam disputar o terminal, deixando a tela presa ou o cartão sem resposta	O terminal aguarda a operação anterior ser concluída (“Aguarde, finalizando operação anterior...”). Após 60 segundos sem conclusão, a nova operação não é iniciada e o terminal exibe “Operação em andamento”, orientando a tentar novamente.
Venda iniciada com o terminal sem nenhuma rede	A falha só aparecia depois da leitura do cartão e da senha	A venda não é iniciada: o terminal informa a falta de conexão e oferece nova tentativa. A faixa "Sem conexão" volta a ser exibida na tela inicial
Venda iniciada durante a carga de tabelas	Recusa com "Terminal carregando"	A venda aguarda a carga terminar, com "Aguarde, carregando tabelas...", e prossegue automaticamente. A espera pode ser cancelada pelo operador
Botão voltar do sistema na tela de Processando ou no erro de senha	Podia interromper a transação em andamento	É ignorado nessas telas

Pix — encerramento pelo operador. Alteração relevante para o processo de conciliação.

• Ao voltar da tela do QR Code antes da expiração, o desfazimento passa a ser enviado imediatamente e a cobrança fica com status Cancelada. Na versão 1.0.6, o terminal fazia até duas consultas antes de enviar o desfazimento.
• O terminal continua consultando o status em segundo plano: um pagamento feito nos segundos anteriores ao encerramento é reconhecido e a venda é concluída, sem duplicidade.
• A expiração do QR Code e o tempo esgotado mantêm o comportamento da versão 1.0.6.

🚀 Inicialização e carga de tabelas

• Terminal recém-ativado: enquanto as tabelas ainda não foram disponibilizadas no ambiente, o terminal exibe "Terminal em ativação", em vez de mensagem de falha de conexão. Novas tentativas são feitas automaticamente, apenas com o terminal parado, em intervalos crescentes por até 24 horas.
• Carga condicional: as cargas automáticas só baixam as tabelas quando houve alteração no cadastro, o que torna a inicialização mais rápida. A opção Carga de Tabelas do menu sempre faz a carga completa.

📊 Relatório de Vendas

• Novas abas Resumida, Gráficos e Detalhada, com filtro avançado em todas as abas.
• Período personalizado de até 90 dias e atalho Últimos 3 meses.
• Crédito apresentado separadamente em à vista e parcelado, com as cores da identidade visual do parceiro nos gráficos.
• Contagens alinhadas na aba Resumida; estornos agrupados abaixo da venda de origem na aba Detalhada.
• Status "Negada" passa a se chamar "Recusada". "Cancelada" passa a indicar exclusivamente o desfazimento automático feito pelo sistema, inclusive quando o operador encerra um Pix.
• O card de totais passa a exibir também o BRUTO TOTAL, ao lado do TOTAL DE VENDAS APROVADAS.
• Relatório impresso consolidado, com resumo por status e rótulos que não são mais cortados, inclusive acentos sobre letras maiúsculas.
• Ícones das bandeiras Pluxee, VR, Ticket e Alelo; ícone da Amex corrigido.

ℹ️ Informações do Terminal

• Nova opção Informações no menu, com estabelecimento, número de série em destaque, ICCID, operadora, tipo de conexão com a geração da rede (por exemplo, "Dados móveis (4G)"), versão do aplicativo e versão do agente de gerenciamento, além de via impressa e acesso aos documentos legais.
• As telas de abertura, de identificação do parceiro e de ativação exibem no rodapé a versão do aplicativo, o número de série e o ICCID, o que facilita o atendimento antes da ativação.
• Falta de papel: o terminal avisa "Sem papel — troque a bobina", com dupla verificação para evitar alerta falso.

🖥️ Identidade visual

• Corrigida a condição em que o aplicativo fechava ou reiniciava repetidamente logo após aplicar a identidade visual do parceiro na ativação.
• A cor do parceiro no painel do cliente (segunda tela) passa a ser atualizada sem necessidade de reiniciar o aplicativo.
• Suporte à identidade visual de novos parceiros.

📦 Tamanho do pacote de instalação

Segunda etapa da redução anunciada na versão 1.0.6: o pacote de instalação (APK release, OCTA 400) passa de 39,4 MiB para 9,9 MiB, por meio da otimização e da remoção de código não utilizado na geração do pacote, sem alteração de comportamento em execução.

✅ Roteiro sugerido de validação

#	Cenário	Resultado esperado
1	Abrir um Pix, voltar da tela do QR Code e iniciar uma venda com cartão em seguida	A venda aguarda com "Aguarde, finalizando operação anterior..." e prossegue normalmente
2	Abrir um Pix e voltar antes da expiração	Cobrança registrada como Cancelada, sem valor cobrado do cliente
3	Desligar Wi-Fi e dados móveis e iniciar uma venda	Venda não iniciada, com aviso de falta de conexão e opção de nova tentativa
4	Acionar Carga de Tabelas e iniciar uma venda durante a carga	Venda aguarda com "Aguarde, carregando tabelas..." e prossegue ao final da carga
5	Ativar um terminal recém-cadastrado	"Terminal em ativação" até a disponibilização das tabelas, seguido da conclusão automática
6	Abrir o Relatório de Vendas e navegar pelas abas, com filtro de período e de status	Valores coerentes entre as abas; venda negada pelo emissor exibida como Recusada. O total do período ainda inclui as transações Canceladas (ver Compatibilidade e comportamento conhecido)
7	Imprimir o Relatório de Vendas	Documento consolidado sem cortes nos rótulos
8	Abrir Informações no menu	Número de série, ICCID, operadora, conexão e versões preenchidos
9	Retirar a bobina e imprimir um comprovante	Aviso "Sem papel — troque a bobina"

📌 Compatibilidade e comportamento conhecido

• O aplicativo 1.0.8 requer o SDK 1.0.8. Versões anteriores do SDK não são compatíveis com esta versão do aplicativo.
• A atualização pode ser instalada sobre a versão 1.0.7, mantendo a ativação, a configuração e os usuários do terminal.
• Cobertura automatizada: 855 testes no SDK e 838 no aplicativo, sem falhas. Validação em terminal físico OCTA 400 em quatro rodadas, incluindo a rodada de QA de 23/10.
• Comportamento conhecido: no Relatório de Vendas, o total do período ainda inclui as transações com status Cancelada (desfeitas pelo sistema, de cartão ou de Pix). A correção será feita no ambiente e não exige nova versão do aplicativo.

v1.0.7 — 10/09/2026 (hotfix)

Versão conjunta: SDK 1.0.7 e Aplicativo 1.0.7. O aplicativo desta versão requer o SDK 1.0.7.

Hotfix sobre a versão 1.0.6, com um refinamento na verificação de cartão do fluxo de venda e um ajuste de nomenclatura no Relatório de Vendas.

Chamados atendidos nesta versão

Chamado	Assunto	Onde
0030475	Cartão Não Suportado v1.0.6 — Ultrablue BTG	Venda com cartão — refinamento da verificação
0030477	Ajuste de nomenclatura visão de relatórios — Valor Líquido de Recebível	Relatório de Vendas — nomenclatura do total

💳 Venda com cartão — refinamento da verificação introduzida na 1.0.6

Atende ao chamado 0030475. A versão 1.0.6 passou a verificar, ainda no terminal, a compatibilidade entre o cartão apresentado e o meio de pagamento selecionado — é o que permite a recusa imediata do cartão exclusivo de benefício em Crédito ou Débito. Na rodada de validação subsequente, observou-se que, em determinadas configurações do cadastro de produtos do terminal, pagamentos por aproximação com carteiras digitais (Apple Pay / Google Pay) também podiam ser alcançados por essa verificação.

Nesta versão, a verificação foi refinada e passa a atuar somente nos casos em que a informação disponível no terminal é conclusiva:

Situação	Comportamento
Meio Voucher com cartão sem aplicação de benefício	Recusa imediata, antes da senha: "Cartão Não Suportado"
Meio Crédito ou Débito com cartão exclusivo de benefício	Recusa imediata, antes da senha: "Cartão Não Suportado"
Demais combinações (incluindo carteiras digitais)	A transação segue para autorização do emissor, que decide

🖨️ Relatório de Vendas — nomenclatura do total

Atende ao chamado 0030477. O valor em destaque do card de totais e a linha correspondente do relatório impresso passam de VALOR LÍQUIDO DE RECEBÍVEL / LÍQUIDO DE RECEBÍVEL para TOTAL DE VENDAS APROVADAS. O número exibido não muda — vendas aprovadas descontados os estornos do período; o rótulo anterior sugeria valor de liquidação, o que não corresponde ao dado apresentado.

✅ Roteiro sugerido de validação

#	Cenário	Resultado esperado
1	Venda por aproximação com carteira digital (Apple Pay / Google Pay), em Crédito e em Débito	Transação segue para autorização do emissor e conclui normalmente
2	Selecionar Crédito ou Débito e apresentar cartão exclusivo de benefício	Recusa antes da senha, como na 1.0.6
3	Selecionar Voucher e apresentar cartão sem aplicação de benefício	Recusa antes da senha, como na 1.0.6
4	Abrir o Relatório de Vendas e imprimir o documento	Rótulo TOTAL DE VENDAS APROVADAS no card e no impresso, com o mesmo valor de antes

📌 Compatibilidade

• Fora os itens acima, o comportamento é o da versão 1.0.6 — nenhuma outra tela ou fluxo foi alterado.

v1.0.6 — 04/09/2026

Versão conjunta: SDK 1.0.6 e Aplicativo 1.0.6. O aplicativo desta versão requer o SDK 1.0.6.

Esta entrega concentra os ajustes decorrentes da rodada de validação da versão anterior, somados a melhorias identificadas durante o desenvolvimento. O foco está em três frentes: precisão das recusas e mensagens durante a leitura do cartão, tratamento de transações Pix sem resposta definitiva e redução do tamanho do pacote de instalação.

:::info Requisito de configuração — meio de pagamento Voucher

Nesta versão a exibição do Voucher (venda e estorno) passa a ser controlada pela carga do terminal. O botão é apresentado quando as duas condições forem atendidas:

1. a tabela merchant da carga trouxer merchant.voucherEnabled: true;
2. houver produto voucher habilitado para o terminal.

Recomendamos confirmar o campo no ambiente antes de iniciar a validação. Trata-se de um controle temporário, que permite habilitar o voucher pela carga sem necessidade de nova versão do aplicativo. Será removido em versão futura, após a validação em produção. :::

💳 Venda com cartão

Situação	Comportamento anterior	Comportamento atual
Cartão exclusivo de benefício apresentado em Crédito ou Débito	O fluxo prosseguia e a recusa ocorria em etapa posterior, com a mensagem "Dados Inválidos — Produto não encontrado"	Recusa imediata, antes da digitação da senha: "Cartão Não Suportado — Tente outro meio de pagamento ou outro cartão"
Leitura de tarja incompleta	A falha ocorria após a digitação da senha	O terminal solicita nova passagem do cartão, antes da senha
Indisponibilidade momentânea do serviço de leitura	O fluxo era direcionado imediatamente para tarja	Nova tentativa pelo mesmo meio de leitura, sem direcionamento automático para tarja
Erro no servidor do gateway (HTTP 5xx)	Exibia mensagem de falha de conexão, mesmo com a rede disponível	Exibe mensagem de falha no processamento. O desfazimento da transação segue sendo executado normalmente
Mensagens entre tentativas de leitura	O texto variava entre os fluxos de venda e de estorno	Mensagens padronizadas nos dois fluxos

↩️ Estorno

• A seleção "Cartão ou Voucher" passa a delimitar a lista de transações apresentadas: ao escolher Voucher, são listadas apenas vendas voucher; ao escolher Cartão, são listadas as vendas de crédito e débito.
• Quando o cartão apresentado possui vendas apenas do outro tipo, o terminal exibe mensagem específica orientando o retorno e a troca da opção. Anteriormente era apresentada a mensagem de "nenhuma transação encontrada".
• Em cartões com mais de uma aplicação — como o Caju, em que benefício e crédito possuem numerações distintas —, a escolha de Voucher direciona a leitura para a aplicação de benefício.

🔷 Pix

Alteração relevante para o processo de conciliação.

• O tempo de espera do QR Code passa a ser definido pelo backend (validade do QR acrescida de uma folga de duas consultas), substituindo o valor fixo de 180 segundos utilizado anteriormente.
• Quando a transação Pix encerra sem resposta definitiva — encerramento pelo operador, expiração do cronômetro ou tempo esgotado —, o desfazimento deixa de ser enviado imediatamente. O terminal passa a consultar o status em segundo plano:
  • Encerramento pelo operador: o terminal confirma o status por até duas consultas antes de enviar o desfazimento.
  • Expiração do cronômetro ou tempo esgotado: o terminal mantém a consulta por período equivalente à metade da validade do QR Code (QR de 120 segundos resulta em aproximadamente 1 minuto).
• Consequência prática: uma transação Pix pode ser concluída alguns minutos após o encerramento da tela. O comportamento é intencional e evita o desfazimento de cobranças efetivamente pagas nos segundos finais da validade.
• Esgotado o prazo sem resposta, o desfazimento é enviado e o evento fica registrado para conferência posterior.
• O encerramento da tela não interrompe mais a consulta de status em andamento.

🚀 Inicialização e ativação do terminal

• Parceiro não localizado no ambiente: passa a ser tratado como recusa definitiva, com mensagem específica e sem novas tentativas automáticas. A condição é mantida após reinicialização do terminal, sem retorno ao ciclo de inicialização.
• Revalidação de chaves: o aplicativo relê o pinpad em até quatro tentativas e repete a verificação a cada acionamento de "Tentar Novamente". Terminais que recebem injeção de chave após a primeira falha passam a concluir a inicialização sem reinstalação.
• Credenciais inválidas: as respostas HTTP 401 e 403 passam a apresentar a mesma mensagem de não autorizado.
• Validação de cadastro: a mensagem retornada pelo backend passa a ser exibida ao operador, em substituição ao texto genérico anterior.
• Leitura de chaves de criptografia: o terminal passa a distinguir "chave ausente" de "falha na leitura da chave", o que agiliza o diagnóstico em campo.

🖥️ Painel do cliente (segunda tela)

• Mensagem "Aguardando ativação": corrigida a condição em que o painel permanecia exibindo a mensagem com o terminal já ativado. A mensagem passa a ser apresentada exclusivamente durante a janela de pré-ativação e, uma vez ativado o terminal, o painel exibe a identidade visual do parceiro ou permanece neutro.
• A mensagem passa a cobrir toda a janela de pré-ativação, inclusive nos terminais que recebem o parceiro pela carga.
• Durante a reinicialização da identidade visual, o painel deixa de exibir a mensagem de ativação.
• Nitidez da logo do parceiro: corrigido o serrilhado no cabeçalho do painel. A imagem passa a ser processada no tamanho de exibição de cada destino, com filtragem adequada. A melhoria é aplicada integralmente quando a imagem é obtida novamente — na reativação do terminal.

🖨️ Relatório de vendas impresso

Layout redesenhado a partir do retorno de uso em campo e validado em impressão no OCTA 400.

• Cabeçalho centralizado com logo, título, identificação da loja, TID do terminal e data de emissão.
• Faixa de período entre réguas, com os filtros aplicados em linha única.
• Contagem de transações no formato TRANSAÇÕES | 7 DE 22, com o dia destacado entre réguas.
• Cabeçalhos de status em faixa, com a respectiva contagem — por exemplo, APROVADAS (5).
• Transações sem cartão (Pix e dinheiro) passam a ocupar uma única linha, reduzindo o consumo de papel.
• Total do dia em moldura, bloco de resumo e rodapé com LÍQUIDO DE RECEBÍVEL e LÍQUIDO TOTAL.
• Padronização de notação: o indicador de parcelas passa a ser a única ocorrência de "x" no documento; as contagens passam a ser expressas por número e palavra, como 6 VENDAS e 22 TRANSAÇÕES.

Correções aplicadas ao documento impresso:

• Logo do cabeçalho impressa em dimensão incorreta.
• Valor das transações sem cartão impresso em corpo reduzido.
• Cabeçalho exibindo o filtro de escopo no lugar do TID do terminal emissor.
• Contagem de vendas repetida no cabeçalho do dia e no total do dia.

Nomenclatura em tela: o card de Relatório de Vendas passa a utilizar a terminologia de recebíveis — VALOR LÍQUIDO DE RECEBÍVEL, com "Líquido total" e "Estornado" apresentados em linhas separadas.

📱 Interface e navegação

• Data e hora nas listagens: os cards passam a exibir data e hora no formato dd/MM - HH:mm.
• Telas de senha: o gesto de arrasto lateral não abre mais o menu durante a digitação e a criação de senha. O acesso pelo botão de menu permanece disponível.
• Tela inicial: o gesto de arrasto da esquerda para a direita volta a abrir o menu lateral, mantendo o gesto da direita para a esquerda como atalho para vendas.
• Erros de comunicação ocorridos fora de uma transação deixam de ser apresentados como falha de venda.

📦 Tamanho do pacote de instalação

Atendendo ao apontamento sobre consumo de dados na distribuição, o pacote de instalação (APK release, OCTA 400) foi reduzido de 72,6 MiB para 39,4 MiB — redução de 46%, sem qualquer alteração de comportamento em execução.

Composição do APK	v1.0.5	v1.0.6	Variação
Total do arquivo	72,6 MiB	39,4 MiB	−33,2 MiB (−46%)
Código compilado (DEX)	62,0 MiB (5 arquivos)	35,1 MiB (4 arquivos)	−26,9 MiB
Recursos empacotados	14,3 MiB	1,4 MiB	−12,9 MiB
Bibliotecas nativas	1,8 MiB	1,8 MiB	sem alteração
Demais componentes	1,8 MiB	1,7 MiB	−0,1 MiB

:::note Sobre os valores

Medição realizada sobre os pacotes oficiais de release, com a v1.0.6 apurada nos ambientes de staging e produção. Valores expressos em MiB (1 MiB = 1.048.576 bytes), unidade utilizada pelas ferramentas de análise de APK — o total corresponde a 76,1 MB e 41,3 MB em unidades decimais.

Os valores por componente referem-se ao conteúdo descompactado e, por isso, não somam o tamanho total do arquivo, que é distribuído comprimido. :::

A redução foi obtida por meio da remoção de bibliotecas declaradas e não utilizadas, da otimização das fontes tipográficas empacotadas, da conversão de imagens para formato mais eficiente sem perda de qualidade e da remoção de recursos obsoletos.

Uma segunda etapa de redução está prevista para versão futura, condicionada à execução de regressão completa em terminal físico.

✅ Roteiro sugerido de validação

#	Cenário	Resultado esperado
1	Selecionar Voucher e apresentar cartão de crédito ou débito comum	Mensagem "Cartão Não Suportado — Tente outro meio de pagamento ou outro cartão"
2	Selecionar Crédito ou Débito e apresentar cartão exclusivo de benefício	Recusa apresentada antes da solicitação de senha
3	Realizar venda voucher com cartão válido	Transação aprovada, com exibição do saldo quando informado pelo emissor
4	Estorno com opção Voucher, apresentando cartão que possui apenas venda de crédito	Mensagem indicando ausência de transações para o meio selecionado; ao retornar e selecionar Cartão, a venda é listada
5	Estorno com opção Cartão	Lista apresenta crédito e débito, sem as vendas voucher
6	Passar cartão com tarja em condição irregular	Solicitação de nova passagem do cartão, antes da senha
7	Emitir o relatório de vendas impresso	Layout conforme o desenho validado, com TID do terminal emissor no cabeçalho
8	Reiniciar terminal já ativado e observar o painel do cliente	Identidade visual do parceiro apresentada, sem a mensagem de aguardo de ativação
9	Imprimir e reimprimir um comprovante de venda	Comprovante idêntico ao da versão anterior, com todos os campos preenchidos

🔎 Escopo não alterado nesta versão

Os comprovantes de venda e estorno, a pré-autorização e a captura de pré-autorização permanecem com o comportamento da versão 1.0.5. No Relatório de Vendas, a consulta, os filtros e os totais permanecem inalterados — as mudanças desta versão se restringem ao layout do documento impresso e à nomenclatura do card de totais.

📌 Compatibilidade e qualidade

• O aplicativo 1.0.6 requer o SDK 1.0.6. Versões anteriores do SDK não são compatíveis com esta versão do aplicativo.
• Cobertura automatizada: 539 testes no SDK e 538 no aplicativo, sem falhas.
• Validação em terminal físico realizada em terminais OCTA 400, cobrindo estorno por tipo de cartão, inicialização com parceiro inválido, revalidação de chaves, validação de cadastro e fluxo Pix.

v1.0.5 — 27/08/2026

Release focada no Relatório de Vendas e na legibilidade dos comprovantes, com as correções dos chamados Mantis 0030414 (app preso na tela de comprovante) e Mantis 0030394 (filtros perdidos ao trocar o período).

:::info Compatibilidade Esta versão do app requer o SDK 1.0.5. As duas versões devem ser instaladas juntas. :::

Chamados atendidos nesta versão

Chamado	Assunto	Onde
0030414	Captura — v1.0.3 em piloto Produção	Estabilidade — app preso na tela de comprovante
0030394	Relatórios — Filtros Avançados se sobrepondo quando mais de um filtro é aplicado	Relatório de Vendas — filtros preservados ao trocar o período
0030392	Inconsistência na Soma de Transações Aprovadas	Relatório de Vendas — total do período e contagem do dia
0030337	Ajustes de legibilidade e formatação dos relatórios/comprovantes impressos	Comprovantes e Relatório de Vendas
0030417	Limitar perfis Supervisor	Usuários — teto de 10 supervisores

Chamados encerrados em versões anteriores e já disponíveis no piloto: 0030380 (remover "Dinheiro" dos filtros avançados), 0030393 (alerta de falha de impressão persistindo após reimpressão) e 0030332 (exibição e sincronização da segunda tela) na v1.0.4.1; 0030330 (estorno de PIX) na v1.0.4.

---

🧾 Comprovantes

Fonte maior nos comprovantes impressos (chamado 0030337). Atendendo à observação sobre fonte pequena, a escala tipográfica foi refeita e medida em papel no OCTA 400 — não estimada. O corpo do comprovante subiu para um tamanho em que as letras e a s c o e os dígitos 8 0 deixam de ficar ambíguos na térmica. Nome da loja e identificação da via ganharam destaque; endereço, OUVIDORIA e rodapé ficam no corpo menor.

Bandeira e Código EC nas vias. Campos obrigatórios do checklist BTG v1.1 (itens 7 e 13) e do Book PagSeguro v2.0.1:

• No cartão inserido (chip), a via imprimia o nome comercial do emissor no lugar da bandeira — por exemplo Credito Nubank em vez de MASTERCARD. Corrigido.
• A via de cancelamento saía sem a linha "EC:", enquanto a de venda saía com ela. Agora as duas usam a mesma fonte de dados do estabelecimento.
• No cancelamento, a bandeira vinha genérica: um voucher que imprimia VISA BENEFICIOS na venda saía como VISA no cancelamento. Agora as duas vias coincidem.

Bandeira com grafia consistente entre as telas. A mesma bandeira aparecia como visa, Visa ou VISA dependendo da tela. Padronizada nas cinco telas; o impresso segue em caixa alta.

Forma de captura na reimpressão (C10, QA Positivo de 21/08). Vendas por tarja em fallback reimprimiam Captura: MAGSTRIPE_FALLBACK_801, com o código cru do adquirente. Agora exibe MAGSTRIPE, DIGITADA ou CLESS.

Hora do comprovante em tela igual à do papel. A hora exibida avançava enquanto a tela ficava aberta e passava a divergir do comprovante impresso. Dois documentos da mesma venda com horas diferentes atrapalham a conciliação — a tela agora congela a hora da transação.

Cartão mascarado no mesmo formato em toda a aplicação. A máscara variava entre ••••, **** e ***** conforme a tela. Padronizada em ****.

---

📊 Relatório de Vendas

Total do período, e não só das páginas carregadas (chamado 0030392). O card de totais passa a consultar o agregado do período diretamente no servidor, respeitando exatamente os filtros aplicados na tela. Antes, o número exibido só contemplava as páginas já carregadas na rolagem.

O card foi redesenhado: o líquido é o número principal, com uma barra de composição e a legenda ● Bruto · ● Estornado. A barra só aparece quando houve estorno no período.

Filtros não se perdem mais ao trocar o período (Mantis 0030394). Clicar num atalho rápido (Hoje / Ontem / 7 / 15 dias) ou escolher data no calendário descartava todos os filtros já aplicados. Havia ainda um caso pior: abrir o Filtrar Avançado — que abria com o Período vazio — e aplicar somente "Todos os terminais" gerava uma consulta sem recorte de data, trazendo o histórico inteiro do estabelecimento.

• Atalhos e calendário trocam apenas o período. Terminal, status, bandeira, dígitos, NSU e código de autorização continuam valendo.
• A consulta nunca é enviada sem recorte de data (padrão: Hoje).
• Na busca por NSU ou código de autorização, um período que o operador não escolheu deliberadamente é ignorado — o identificador é único, e recortar por data só esconderia o resultado. Um período escolhido de propósito continua valendo.
• O Filtrar Avançado abre pré-preenchido com o período em uso.

Relatório impresso reorganizado (chamados 0030337 e 0030392).

• Caixa alta em todo o relatório, que imprime melhor na térmica.
• Os dígitos do cartão passam para a segunda linha, junto de data e NSU, liberando a primeira para o contexto do estorno parcial (R$ 20,00 de R$ 50,00).
• Rodapé reordenado, com LÍQUIDO PERÍODO acima de BRUTO PERÍODO.
• Duas correções de leitura: as linhas de venda estornada não informavam o valor original da venda, e a contagem do TOTAL DO DIA incluía as estornadas — uma venda única de R$ 50 podia imprimir 2x R$ 50,00. O valor sempre esteve correto; a contagem é que somava a mais.

Valor exibido segue o que aconteceu. Havendo estorno, a linha mostra o que voltou; não havendo, mostra o que foi vendido. No fluxo de estorno, a tela continua mostrando o saldo disponível para estornar, que é o número que o operador precisa para não devolver valor errado.

---

🛡️ Estabilidade

App preso na tela de comprovante (Mantis 0030414). Em 24/08, no piloto, uma venda de débito por aproximação foi aprovada e o app travou na tela de comprovante: "Sair" não respondia, arrastar a tela e tocar no home não funcionaram, e só o reinício do terminal liberou o aparelho.

A causa que disparou o travamento não foi identificada — o registro de diagnóstico do terminal é volátil e se perdeu no reinício. Por isso a correção foi desenhada para garantir que o operador sempre tenha saída, independentemente do gatilho:

• Toda saída de fluxo (pagamento, pré-autorização e estorno) passou a verificar se a navegação realmente ocorreu; quando não ocorre, a saída é forçada e o evento fica registrado — é exatamente o dado que faltou para explicar o incidente.
• Teto absoluto de 5 minutos na tela de comprovante, que vale mesmo com o operador tocando na tela.
• O tempo de espera em erro de impressora caiu de 5 para 3 minutos. Sair da tela não é destrutivo: a reimpressão recupera o mesmo comprovante.
• O botão voltar deixou de ser inerte: o primeiro toque avisa e o segundo, em até 3 segundos, sai.

Sem falso alarme de erro ao sair do Dashboard. Um erro inexistente de leitura de cartão era registrado a cada troca de tela. Corrigido.

Barra de status na cor do parceiro. A barra podia manter o resíduo de outra tela ao voltar do comprovante ou da reimpressão, e chegava a sobrescrever o vermelho do aviso "Sem conexão".

---

👥 Usuários

Limite de 10 supervisores por terminal (chamado 0030417). A senha de qualquer supervisor cadastrado destrava estorno, pré-autorização, troca de parceiro e o próprio painel de usuários — sem teto, um terminal acumula essas credenciais indefinidamente. Operadores seguem sem limite, e editar alguém que já é supervisor nunca é bloqueado.

---

ℹ️ Versão visível no aparelho

A versão do app agora aparece na tela de abertura e na tela de ativação do estabelecimento, além do menu lateral — útil para confirmar qual build está instalada antes de reportar um comportamento.

---

✅ Roteiro de validação sugerido

#	Cenário	Resultado esperado
1	Venda com chip inserido e impressão da via	Bandeira do cartão (ex.: MASTERCARD), não o nome do emissor
2	Cancelar essa venda e imprimir a via	Linha EC: presente e bandeira igual à da via de venda
3	Comparar a via impressa com a tela de comprovante	Mesma hora nos dois
4	Venda por tarja em fallback → reimprimir	Captura: MAGSTRIPE
5	Relatório: aplicar filtro avançado, depois clicar em "Ontem"	Filtros preservados; só o período muda
6	Relatório: abrir Filtrar Avançado e aplicar só "Todos os terminais"	Consulta com recorte de data (não traz o histórico inteiro)
7	Relatório: buscar um NSU antigo sem escolher período	Encontra a transação
8	Relatório com estornos no período	Card mostra líquido, barra e legenda Bruto/Estornado
9	Imprimir o relatório do período	Rodapé com LÍQUIDO PERÍODO acima de BRUTO PERÍODO; contagem do dia sem as estornadas
10	Concluir uma venda e usar o botão voltar na tela de comprovante	1º toque avisa, 2º sai
11	Cadastrar supervisores até o 11º	Bloqueio no 11º, com mensagem
12	Abrir e salvar um supervisor já existente	Continua supervisor (sem rebaixamento)
13	Abrir o app e observar a tela de abertura	Versão 1.0.5 exibida

---

📌 Observação conhecida

A busca por NSU ou código de autorização não exibe o card de total do período — o agregado não é consultado durante esse tipo de busca. A lista e o resultado da busca funcionam normalmente.

v1.0.4

O que há de novo

EMV-669 — Comprovante seguinte o book do adquirente e sugestão dos clientes

• Comprovante reduzido ajustado (tamanho, campos, etc.)
• Reimpressão passa a usar os dados da venda original
• Ajustes de UI nas telas de comprovante

EMV-667 — NSU do adquirente nas telas e na via do lojista

• NSU do adquirente (RRN) exibido nas telas de histórico, reimpressão e busca
• Código de venda impresso na via do lojista
• Correção de TID e número de série na reimpressão

EMV-671 — Estorno de Pix no POS

• Estorno de Pix habilitado no terminal

EMV-680 — Atalho "Ontem" nos filtros de data

• Atalho "Ontem" incluído nos filtros rápidos e nos filtros avançados de data

EMV-646 — Segunda tela: painel preservado após recriação da activity

• Painel da segunda tela continua funcionando após a recriação da activity

Build / Dependências

• SDK apossdk atualizado para 1.0.4

v1.0.3

O que há de novo

EMV-664 — Relatório de vendas: busca por NSU/autorização e impressão redesenhada

• Busca de transações por NSU ou código de autorização via API de ciclos
• Totalizadores calculados localmente e exibidos em tela sobre os dados carregados
• Impressão do relatório redesenhada: agrupamento por dia e por status, cabeçalho em formato de comprovante e divisórias desenhadas
• Ícones de bandeira na impressão, com matcher de família de bandeiras compartilhado entre tela e impressão
• Inclusão do ícone Amex e remoção da Hipercard (bandeira descontinuada)

EMV-645 — Via do lojista configurável e volume dos beeps

• Nova preferência local de impressão da via do lojista: perguntar sempre, imprimir sempre ou nunca
• Em modo ALWAYS, a via do lojista é impressa automaticamente (disparo único, sem duplicidade)
• Preferência respeitada em todos os fluxos que geram comprovante
• Slider de volume nas configurações, com volume do beep de tecla ajustável e persistido

EMV-644 — Estorno em débito e padronização de saldo

• Estorno em débito restrito ao valor total, garantido por RefundRules como fonte única de elegibilidade de estorno parcial
• Rota de edição de valor bloqueada nos dois fluxos de estorno quando o parcial não é permitido
• Affordance de edição de valor ocultada quando o estorno parcial não se aplica
• Saldo remanescente exibido como informação principal em transações parcialmente estornadas
• Labels do card de estorno padronizadas com o detalhe da transação e remoção do nome do estabelecimento

EMV-643 — Escape para processamento travado e mensagens de operador

• Watchdog de processamento travado com cancelamento forçado nos fluxos transacionais
• BACK passa a cancelar o estorno travado após o limite de espera
• Tratamento de BACK na pré-autorização alinhado aos demais fluxos
• Mensagens de erro reescritas em linguagem de operador

Correções e melhorias

• Impressão de comprovante movida para fora da main thread, com fila de impressão serial única
• Correção no fluxo de pagamento: uso de Flow.collect como membro no lugar do top-level removido
• Nome do adquirente removido do detalhe da transação
• Correção de achado apontado em revisão de PR (Copilot Autofix)
• Cobertura de testes para fila de impressão serial, via do lojista automática, preferência/volume nas configurações e regra de valor total no débito
• APKs (Octa400 — prod e staging) gerados e anexados pelo workflow de release.

v1.0.2

O que há de novo

EMV-631 — Teclado de PIN de acessibilidade e retenção de tela

• Teclado de PIN acessível (AccessibilityPasswordKeypad) para uso com película tátil, habilitado por EC via flag accessibilityKeyboard da inicialização
• Ícones dedicados de cancelar, limpar e confirmar
• Tela sempre ativa durante os fluxos transacionais
• Mensagens de erro amigáveis nos fluxos de pagamento e estorno
• Gestão do estado de inicialização de tabelas

EMV-630 — Ativação sem cadastro obrigatório de supervisor

• Ativação do terminal liberada sem cadastro obrigatório de supervisor
• Suporte a múltiplos supervisores, com proteção contra remoção do último
• Recursos administrativos liberados pela existência de supervisor, no lugar da senha do lojista
• Banner no Dashboard incentivando o cadastro de supervisor
• Remoção do botão de logout do AppDrawer

EMV-627 — Banner de conexão fraca

• Correção de falso positivo, com debounce na exibição do banner offline
• Refinamento da gestão de status de conexão e da validação de rede
• Recuperação correta do estado ao restabelecer a conexão

EMV-626 — Estorno parcial via histórico

• Valor default preenchido com o saldo disponível
• Correção do detalhe da transação (created at, adquirente, RRN), evitando estado incorreto na busca do resumo

Build / Dependências

• SDK apossdk atualizado para 1.0.2 (traz MerchantInfo.accessibilityKeyboard)
• versionCode derivado do semver da tag (1.0.2 -> 10002)

v1.0.1

O que há de novo

EMV-616 — Gestão de usuários e ativação

• Gate de acesso supervisor-only com recuperação de senha
• Perfil de supervisor único e validação do formulário de usuários
• Cadastro obrigatório de supervisor pós-ativação
• Reimpressão de recibo para transações estornadas/canceladas
• Hardening do fluxo de inicialização e ajustes de UX

EMV-617 — Estabilização do fluxo de pagamento (PositivoLib 16.0.12)

• Cancelamento no primeiro toque do CANCEL na tela de PIN
• Exibição de erro de PIN e restauração do teclado após PIN incorreto
• AppHeader com visibilidade determinística

EMV-619 — Estorno via API

• Fluxo de estorno via API e estorno parcial do saldo (dashboard + integração SDK/cache)
• Relatório de vendas (detalhe/recibo via cycles), fuso de São Paulo e correções de UX

Build / Dependências

• SDK apossdk atualizado para 1.0.1
• versionCode agora derivado do semver da tag (1.0.1 -> 10001)