Bugs Out/Nov/Dez 2025 - Histórico de revisão

Caio.silva: /* BUG - Duplicidade de contratos em processos de upgrade/downgrade */

2025-12-16T15:00:34Z

BUG - Duplicidade de contratos em processos de upgrade/downgrade

← Edição anterior		Edição das 15h00min de 16 de dezembro de 2025
Linha 21:		Linha 21:
	O usuário só consegue avançar conscientemente no fluxo, reduzindo o risco de múltiplas execuções		O usuário só consegue avançar conscientemente no fluxo, reduzindo o risco de múltiplas execuções

	Permanece possível avançar utilizando TAB + ENTER~~, mantendo acessibilidade sem permitir duplicidade~~		Permanece possível avançar utilizando TAB + ENTER.

	~~Após o ajuste, o comportamento foi validado em homologação, eliminando os cenários de duplicação de contratos durante upgrade ou downgrade~~.

	==BUG - Duplicidade de movimentação de materiais ao falhar fechamento de OS==		==BUG - Duplicidade de movimentação de materiais ao falhar fechamento de OS==

Caio.silva em 14h59min de 16 de dezembro de 2025

2025-12-16T14:59:11Z

← Edição anterior		Edição das 14h59min de 16 de dezembro de 2025
Linha 1:		Linha 1:
			==BUG - Duplicidade de contratos em processos de upgrade/downgrade==

			Erro identificado:
			No processo de upgrade/downgrade de contratos, era possível ocorrer a criação de dois ou mais contratos quando a ação era confirmada mais de uma vez pelo teclado (ENTER) nos modais do fluxo.
			Esse comportamento gerava duplicidade mesmo sem erros aparentes na execução, resultando em:

			Contratos duplicados ou triplicados para um único upgrade/downgrade

			Em alguns casos, contratos gerados sem todos os vínculos esperados (ex.: ausência de registro em log)

			Inconsistência de dados e necessidade de correções manuais

			O problema foi identificado como relacionado à confirmação repetida da ação via teclado, especialmente pelo uso contínuo da tecla ENTER.

			Correção aplicada:
			O fluxo de confirmação foi ajustado para impedir a continuidade do processo apenas com o uso da tecla ENTER, evitando múltiplas submissões da mesma ação.
			Com a correção:

			A confirmação via ENTER direto foi desabilitada nos modais do processo de upgrade/downgrade

			O usuário só consegue avançar conscientemente no fluxo, reduzindo o risco de múltiplas execuções

			Permanece possível avançar utilizando TAB + ENTER, mantendo acessibilidade sem permitir duplicidade

			Após o ajuste, o comportamento foi validado em homologação, eliminando os cenários de duplicação de contratos durante upgrade ou downgrade.

			==BUG - Duplicidade de movimentação de materiais ao falhar fechamento de OS==

			Erro identificado:
			No app do técnico, ao executar uma OS do tipo Alteração de Endereço com movimentação de material, quando ocorria erro no fechamento da OS, o sistema realizava a movimentação dos materiais mesmo sem concluir o atendimento.
			Em novas tentativas de finalização, os mesmos materiais eram movimentados novamente, gerando duplicidade de registros na TB_Movimento (estoque).
			O problema ocorria porque a movimentação era executada antes da confirmação final da atualização do atendimento, fazendo com que falhas no fluxo não impedissem a gravação das movimentações.

			Correção aplicada:
			O fluxo de finalização da OS foi ajustado com a reordenação do método de conclusão do atendimento, garantindo que:

			A atualização do atendimento seja concluída primeiro

			A movimentação de materiais seja executada somente após o atendimento ser atualizado com sucesso

			Em caso de erro no fechamento da OS, nenhuma movimentação de material ou equipamento seja registrada

			Com a correção, o sistema evita movimentações duplicadas, garantindo consistência no estoque e integridade no processo de finalização das ordens de serviço.

			==BUG - Erro e duplicidade no envio de imagens em OS no app do técnico==

			Erro identificado:
			No app do técnico, durante a execução de uma OS, ao anexar imagens ocorria erro no momento do envio. Em cenários com múltiplas imagens:

			Apenas parte das imagens era vinculada com sucesso

			Novas tentativas de envio resultavam em duplicidade de registros na TB_AtendimentoDocumento

			O processo falhava devido a deadlock no banco de dados, causado por múltiplas inserções concorrentes durante o envio unitário das imagens

			Esse comportamento comprometia a finalização da OS e gerava inconsistência nos anexos vinculados ao atendimento.

			Correção aplicada:
			Foram realizados ajustes tanto no app quanto no comercial para garantir consistência e evitar duplicidades:

			No app, o método de envio de imagens foi reescrito para envio em lotes, limitando o processamento a até 6 imagens por vez, reduzindo concorrência e risco de deadlock.

			No comercial, foi criada uma tratativa para não persistir nenhuma imagem no banco caso ocorra erro no processamento, evitando gravações parciais e duplicadas.

			Com esses ajustes, o envio de imagens passou a ser transacional e consistente, garantindo que as imagens sejam anexadas corretamente ou não persistidas em caso de falha.

			==BUG - Erro ao alterar o estado no cadastro de cidade==

			Erro identificado:
			Na tela de cadastro de cidades, ao alterar o estado (UF) de uma cidade já cadastrada e tentar salvar, o sistema retornava erro de NullPointerException, impedindo a conclusão da edição.
			O problema ocorria de forma consistente, inclusive em cidades sem vínculos, em diferentes bases e ambientes, indicando falha no tratamento da alteração do estado durante o salvamento.

			Esse comportamento gerava incerteza ao usuário, pois o sistema não informava claramente se a alteração era inválida por regra ou se se tratava de erro técnico.

			Correção aplicada:
			O fluxo de salvamento do cadastro de cidades foi ajustado para tratar corretamente a alteração do estado, evitando a ocorrência de exceção durante o processo.
			Além disso, foi implementado tratamento adequado para o cenário, garantindo que:

			A alteração seja processada corretamente quando permitida

			Ou, caso a regra não permita a mudança de estado para cidades já cadastradas, o sistema apresente uma mensagem clara e orientativa ao usuário, em vez de erro técnico

			Com o ajuste, o cadastro de cidades passa a ter comportamento previsível e estável ao editar o estado.

	==BUG - Alteração de titularidade de pacote gerando erro de integração e migração parcial de contratos==		==BUG - Alteração de titularidade de pacote gerando erro de integração e migração parcial de contratos==

Caio.silva em 14h55min de 16 de dezembro de 2025

2025-12-16T14:55:41Z

← Edição anterior		Edição das 14h55min de 16 de dezembro de 2025
Linha 1:		Linha 1:
			==BUG - Alteração de titularidade de pacote gerando erro de integração e migração parcial de contratos==

			Erro identificado:
			No processo de alteração de titularidade de pacotes com planos de TV, foram identificadas falhas que causavam inconsistência na migração dos contratos e erros de integração.

			Os principais problemas observados eram:

			A requisição de integração era enviada mais de uma vez durante a alteração de titularidade, ocasionando erro por duplicidade de cadastro (ex.: e-mail já registrado).

			Em caso de erro retornado pela integração, o sistema migrava apenas parte dos contratos do pacote para o novo titular, mantendo outros contratos vinculados ao titular anterior.

			Em cenários de alteração de pacote, contratos de TV cancelados no sistema não tinham o cancelamento enviado à plataforma externa, fazendo com que o serviço permanecesse ativo externamente.

			Esse comportamento resultava em pacotes com contratos vinculados a dois titulares diferentes, além de impedir vendas ou alterações futuras devido a serviços ainda ativos na plataforma.

			Esse conjunto de falhas comprometia a integridade do processo de alteração de titularidade e a consistência entre o sistema e a plataforma integrada.

			Correção aplicada:
			O fluxo de alteração de titularidade e alteração de pacote foi ajustado para garantir que:

			As requisições de integração sejam executadas apenas uma vez, evitando envios duplicados.

			Em caso de qualquer erro durante a integração, nenhum contrato do pacote seja migrado, mantendo o pacote íntegro no titular original.

			Sempre que um contrato de TV for cancelado em decorrência de alteração de pacote, seja chamada corretamente a ação de cancelamento na integração, assim como ocorre no cancelamento padrão.

			A migração de pacotes ocorra de forma atômica, impedindo que contratos fiquem distribuídos entre titulares diferentes.

			Com a correção, a alteração de titularidade e de pacotes passa a ocorrer de forma consistente, mantendo alinhamento entre os contratos no sistema e os serviços ativos na plataforma integrada.

			==BUG - Histórico da Integração PlayHub exibindo logs de outros clientes==

			Erro identificado:
			Na tela Comercial > Clientes > Histórico > Integrações > Integração PlayHub, a consulta retornava todos os registros da TB_LogIntegracaoPlayHub, incluindo logs de outros clientes, independentemente do cliente selecionado.
			Esse comportamento causava:

			Exibição incorreta do histórico de integrações

			Grande volume de registros retornados

			Erros de carregamento na tela em cenários com muitos dados

			A consulta não estava utilizando corretamente o vínculo entre IDContrato e IDCliente para restringir os resultados ao cliente em questão.

			Correção aplicada:
			A consulta do histórico foi ajustada para filtrar os registros exclusivamente pelo cliente selecionado, utilizando o relacionamento entre IDContrato e IDCliente.
			Com isso, a tela passa a exibir apenas os logs de integração PlayHub relacionados ao cliente consultado, reduzindo o volume de dados, evitando erros de carregamento e garantindo a correta visualização do histórico.

			==BUG - Duplicidade de registros na TB_InformacaoAdicionalFatura ao gerar remessa==

			Erro identificado:
			Foi identificado um problema no fluxo de geração de linha digitável e remessa, onde uma mesma fatura podia gerar dois registros distintos na TB_InformacaoAdicionalFatura.
			O cenário ocorria quando:

			A fatura era gerada e a rotina de linha digitável criava o primeiro registro na TB_InformacaoAdicionalFatura.

			Posteriormente, ao gerar a remessa eletrônica (com Pix), o sistema realizava um INSERT de um novo registro para o mesmo IDFatura, em vez de atualizar o registro já existente.

			Esse comportamento causava duplicidade de dados, além de erros em chamadas da stored procedure spuAtualizaRemessaFatura, incluindo falhas de sintaxe SQL em produção após ajustes manuais.

			Correção aplicada:
			A lógica da spuAtualizaRemessaFatura foi corrigida para garantir que:

			Quando já existir um registro para o IDFatura na TB_InformacaoAdicionalFatura, o sistema realize UPDATE do registro existente.

			A operação de INSERT ocorra apenas quando não houver registro prévio para a fatura.

			A stored procedure corrigida foi validada em ambiente de homologação e ajustada para evitar erros de sintaxe ao atualizar campos como ChavePix, linha digitável e demais informações retornadas pela remessa.
			Com a correção, o fluxo passa a manter apenas um único registro por fatura, garantindo integridade dos dados e estabilidade no processo de geração de remessa e Pix.

	==BUG - Desconto superior ao valor do extrato na contestação de faturas==		==BUG - Desconto superior ao valor do extrato na contestação de faturas==

Caio.silva em 14h53min de 16 de dezembro de 2025

2025-12-16T14:53:11Z

← Edição anterior		Edição das 14h53min de 16 de dezembro de 2025
Linha 1:		Linha 1:
			==BUG - Desconto superior ao valor do extrato na contestação de faturas==

			Erro identificado:
			Na tela de Contestação de Faturas, o sistema permitia aplicar um desconto maior que o valor original do extrato. Como consequência, o extrato gerado passava a ter valor negativo, ocasionando erros em etapas posteriores do fluxo, como na geração de notas fiscais.

			Correção aplicada:
			Foi implementada uma validação no momento da aplicação do desconto, impedindo que o valor final do extrato seja menor que zero.
			Com o ajuste, o sistema permite que o extrato resultante seja igual a 0, porém nunca negativo, garantindo a integridade dos dados e evitando falhas nos processos subsequentes.

			==BUG - Bloqueio indevido na edição de endereço de contratos em pacote==

			Erro identificado:
			Na tela Cliente > Dados pessoais > Endereço, ao iniciar a edição do endereço e optar por “Não” no modal “Deseja apenas corrigir algum erro no cadastro deste endereço?”, o sistema exibia a mensagem “Todos os componentes de um pacote precisam ser selecionados.”, impedindo a continuidade do processo.
			O bloqueio ocorria mesmo quando todos os contratos do pacote estavam selecionados, devido a uma validação que comparava a quantidade de planos cadastrados no pacote (que pode mudar ao longo do tempo) com os contratos efetivamente vendidos, gerando inconsistência e travando a edição.

			Esse comportamento afetava pacotes que tiveram alterações posteriores em sua composição, impossibilitando a edição de endereço de contratos vendidos anteriormente.

			Correção aplicada:
			A validação do modal foi ajustada para, em casos de pacotes, verificar apenas se todos os contratos vinculados ao mesmo IDContratoPacote foram selecionados, independentemente da quantidade atual de planos cadastrados no pacote.
			Com isso, a edição de endereço passa a funcionar corretamente para contratos de pacote, evitando bloqueios indevidos e mantendo o comportamento esperado para contratos que não pertencem a pacotes.

			==BUG - Refidelização incorreta na alteração de titularidade==

			Erro identificado:
			No processo de alteração de titularidade, ao selecionar “SIM” para refidelizar, a nova fidelidade não estava sendo aplicada corretamente para contratos individuais e pacotes.
			Mesmo com a chave FIDELIZACAO_CONTRATOS_FIXA = 1 e sem a permissão de fidelização livre, o sistema não definia a fidelidade para 12 meses a partir da data da alteração, conforme o fluxo esperado. Com isso, as datas de início e vencimento da fidelidade ficavam incorretas.

			Correção aplicada:
			O fluxo foi ajustado para que, quando FIDELIZACAO_CONTRATOS_FIXA = 1, ao optar por refidelizar:

			DataInicioFidelidade seja definida como a data/hora da alteração de titularidade

			DataVencimentoFidelidade seja definida para 12 meses após a data de início

			Quando FIDELIZACAO_CONTRATOS_FIXA = 0, o comportamento permanece inalterado, mantendo o fluxo atual.

			==BUG - Remessa eletrônica não gerada para faturas criadas por contestação==

			Erro identificado:
			As faturas geradas por meio de contestação, quando vinculadas a formas de cobrança eletrônica, não estavam tendo a remessa eletrônica gerada automaticamente.
			Esse comportamento divergia do fluxo esperado e do padrão já aplicado a outros cenários, como a geração de faturas via negociação, onde a remessa eletrônica é criada de forma automática.

			A inconsistência fazia com que faturas válidas ficassem sem remessa, impactando o processo de cobrança eletrônica.

			Correção aplicada:
			O fluxo de geração de faturas por contestação foi ajustado para que, quando a forma de cobrança for eletrônica, a remessa eletrônica seja gerada automaticamente, seguindo o mesmo comportamento já adotado para faturas criadas via negociação.

			Com a correção, o sistema passa a manter padronização no processo de cobrança eletrônica, independentemente da origem da fatura.

			==BUG - Falha na criação de location para Pix recorrente por limite de descrição==

			Erro identificado:
			No fluxo de Pix recorrente, a ação CRIAR_LOCATION_DEBITO_RECORRENTE_PIX não estava sendo executada em determinados cenários. A causa foi identificada no conteúdo enviado no campo de descrição do plano, que excedia o limite de 35 caracteres exigido pela ação responsável pelo cadastro da autorização de débito recorrente via QR Code.
			Como a mesma descrição era reutilizada por outras integrações, o excesso de caracteres impedia a execução correta da ação, resultando na não geração do location para o Pix recorrente.

			Correção aplicada:
			Foi criada a chave DESCRICAO_PLANO_LIMIT, que garante o envio da descrição do plano limitada a até 35 caracteres, atendendo ao requisito da ação de Pix recorrente.
			Com o ajuste, a geração de location passa a ocorrer corretamente apenas quando a ação de cadastro de autorização de débito recorrente via QR Code é executada, sem impacto nas demais integrações que utilizam a descrição completa.

			==BUG - Filtro não retornando registros na primeira página da aba Notas==

			Erro identificado:
			Na tela Financeiro > Integração > Aba NOTAS, ao aplicar determinados filtros, os registros não eram exibidos na primeira página, mesmo havendo resultados válidos.
			No cenário identificado, ao filtrar pelo Modelo de NF, o sistema indicava a existência de milhares de registros, porém a primeira página era carregada vazia. Os dados só passavam a aparecer ao navegar para a última página ou páginas intermediárias, caracterizando falha na paginação associada ao filtro.

			Esse comportamento causava confusão ao usuário, dando a impressão de que o filtro não havia retornado resultados.

			Correção aplicada:
			O mecanismo de paginação com filtros foi ajustado para garantir que, sempre que o filtro aplicado possuir registros válidos, os resultados sejam exibidos corretamente a partir da primeira página.
			Com a correção, a navegação entre páginas mantém consistência e os registros filtrados passam a ser apresentados de forma adequada desde o carregamento inicial.

			==BUG - Rotina habilitando contrato já cancelado==

			Erro identificado:
			Foi identificado um cenário em que a rotina de habilitação alterava o status de um contrato que havia sido cancelado durante a execução da própria rotina.
			O contrato era corretamente selecionado no início da execução por estar com status “HABILITADO EM CONFIANÇA”, porém, antes da atualização final do status pela rotina, o usuário realizou a alteração manual para CANCELADO. Mesmo assim, a rotina prosseguiu e reverteu o status de CANCELADO para HABILITADO, gerando inconsistência no estado do contrato.

			Correção aplicada:
			O endpoint utilizado pela rotina foi ajustado para validar novamente o status do contrato no momento da atualização, considerando apenas contratos que não estejam com status CANCELADO.
			Com esse ajuste, a rotina não altera contratos que tenham sido cancelados durante sua execução, evitando reativações indevidas e garantindo a integridade do status do contrato.

	==BUG - Otimizar consulta para selecionar produto na movimentação interna==		==BUG - Otimizar consulta para selecionar produto na movimentação interna==

Caio.silva: /* BUG - Erro na geração de nota por impostos nulos na composição */

2025-12-16T14:48:27Z

BUG - Erro na geração de nota por impostos nulos na composição

← Edição anterior		Edição das 14h48min de 16 de dezembro de 2025
Linha 210:		Linha 210:
	O salvamento da composição foi ajustado para que, quando os campos de impostos não forem informados, os valores sejam persistidos como 0 (zero) no banco de dados.		O salvamento da composição foi ajustado para que, quando os campos de impostos não forem informados, os valores sejam persistidos como 0 (zero) no banco de dados.
	Com isso, a geração de notas fiscais passa a ocorrer normalmente, evitando exceções por valores nulos mesmo quando os impostos não são obrigatórios no cadastro da composição.		Com isso, a geração de notas fiscais passa a ocorrer normalmente, evitando exceções por valores nulos mesmo quando os impostos não são obrigatórios no cadastro da composição.

			==BUG - Duplicação de endereço do cliente na alteração de titularidade==

	Erro identificado:		Erro identificado:

Caio.silva em 14h47min de 16 de dezembro de 2025

2025-12-16T14:47:52Z

← Edição anterior		Edição das 14h47min de 16 de dezembro de 2025
Linha 210:		Linha 210:
	O salvamento da composição foi ajustado para que, quando os campos de impostos não forem informados, os valores sejam persistidos como 0 (zero) no banco de dados.		O salvamento da composição foi ajustado para que, quando os campos de impostos não forem informados, os valores sejam persistidos como 0 (zero) no banco de dados.
	Com isso, a geração de notas fiscais passa a ocorrer normalmente, evitando exceções por valores nulos mesmo quando os impostos não são obrigatórios no cadastro da composição.		Com isso, a geração de notas fiscais passa a ocorrer normalmente, evitando exceções por valores nulos mesmo quando os impostos não são obrigatórios no cadastro da composição.

			Erro identificado:
			No processo de alteração de titularidade em pacotes, quando os contratos do titular anterior utilizavam o mesmo IDEnderecoCliente, o sistema passava a criar múltiplos IDEnderecoCliente distintos para o novo titular.
			Com isso, um único endereço existente no cliente original resultava em dois ou mais endereços duplicados no novo cliente, mesmo sendo o mesmo local físico.

			Esse comportamento gerava inconsistência cadastral e duplicidade indevida de endereços vinculados aos contratos.

			Correção aplicada:
			O fluxo de alteração de titularidade foi ajustado para reutilizar corretamente o mesmo IDEnderecoCliente no novo titular quando os contratos de origem compartilham o mesmo endereço.
			Com a correção, o sistema garante que:

			Um único endereço no titular anterior gere apenas um endereço correspondente no novo titular

			Todos os contratos migrados mantenham a referência correta ao mesmo endereço, evitando duplicidades

			Assim, a integridade dos dados de endereço é preservada durante a alteração de titularidade em pacotes.

Caio.silva em 14h46min de 16 de dezembro de 2025

2025-12-16T14:46:17Z

← Edição anterior		Edição das 14h46min de 16 de dezembro de 2025
Linha 200:		Linha 200:

	Após o ajuste, a rotina foi validada, garantindo o envio correto das faturas e notas fiscais em ambos os cenários de execução.		Após o ajuste, a rotina foi validada, garantindo o envio correto das faturas e notas fiscais em ambos os cenários de execução.

			==BUG - Erro na geração de nota por impostos nulos na composição==

			Erro identificado:
			No cadastro de composição, quando os campos de impostos (ex.: COFINS, PIS, ICMS, etc.) não eram informados, os valores eram salvos como NULL na base.
			Ao gerar a nota fiscal em cenários que exigiam esses impostos, o processo falhava com NullPointerException, interrompendo a geração da nota.

			Correção aplicada:
			O salvamento da composição foi ajustado para que, quando os campos de impostos não forem informados, os valores sejam persistidos como 0 (zero) no banco de dados.
			Com isso, a geração de notas fiscais passa a ocorrer normalmente, evitando exceções por valores nulos mesmo quando os impostos não são obrigatórios no cadastro da composição.

Caio.silva em 14h45min de 16 de dezembro de 2025

2025-12-16T14:45:41Z

← Edição anterior		Edição das 14h45min de 16 de dezembro de 2025
Linha 182:		Linha 182:

	Com esses ajustes, o processo de débito recorrente via Pix passa a operar de forma consistente, com dados corretos, histórico confiável e configuração completa pelo usuário.		Com esses ajustes, o processo de débito recorrente via Pix passa a operar de forma consistente, com dados corretos, histórico confiável e configuração completa pelo usuário.

			==BUG - Rotina de envio não encontra faturas ao validar log de envio==

			Erro identificado:
			Na execução da Rotina-EnvioFaturasNotasFiscais, quando o oitavo parâmetro (enviar somente para clientes sem log de envio) era definido como 1, a rotina não retornava nenhuma fatura, mesmo quando existiam faturas elegíveis sem registro na TB_LogEnvioFatura.
			Com o mesmo comando, alterando apenas o oitavo parâmetro para 0, as faturas eram encontradas e enviadas corretamente, evidenciando falha na lógica de validação do log.

			Esse comportamento impedia o envio correto de faturas e notas fiscais em execuções que utilizavam o filtro por ausência de log, inclusive em cenários com grande volume de faturas pendentes.

			Correção aplicada:
			A lógica de busca da rotina foi ajustada para validar corretamente a existência (ou não) de registros na TB_LogEnvioFatura quando o oitavo parâmetro estiver habilitado.
			Com a correção, a rotina passa a:

			Localizar corretamente as faturas sem log de envio quando o parâmetro estiver definido como 1

			Manter o comportamento já existente quando o parâmetro estiver definido como 0

			Após o ajuste, a rotina foi validada, garantindo o envio correto das faturas e notas fiscais em ambos os cenários de execução.

Caio.silva em 14h44min de 16 de dezembro de 2025

2025-12-16T14:44:51Z

← Edição anterior		Edição das 14h44min de 16 de dezembro de 2025
Linha 98:		Linha 98:

	Com isso, o fluxo de movimentação interna passa a funcionar corretamente em todos os cenários de local de origem.		Com isso, o fluxo de movimentação interna passa a funcionar corretamente em todos os cenários de local de origem.

			==BUG - Conteúdo cortado na tela inicial do aplicativo Android==

			Erro identificado:
			Na tela inicial do aplicativo do cliente (Android), algumas informações estavam sendo exibidas de forma cortada, prejudicando a visualização do conteúdo.
			O problema foi replicado em dispositivos específicos, onde a tela não se adaptava corretamente à resolução e versão do sistema operacional, mesmo funcionando normalmente em outros aparelhos e em emulador.

			Correção aplicada:
			O layout da tela inicial foi ajustado para garantir responsividade adequada, assegurando que todos os elementos sejam exibidos corretamente em diferentes resoluções e versões do Android.
			Quando necessário, foi implementado scroll na tela, evitando o corte de informações e garantindo uma experiência consistente e funcional para todos os usuários.

			==BUG - Problemas de layout e scroll no aplicativo móvel (iOS e Android)==

			Erro identificado:
			Foram identificados problemas de visualização e usabilidade em diferentes telas do aplicativo móvel:

			iOS

			Na tela “Meu plano”, não havia scroll, impedindo a visualização completa das informações.

			Nessa mesma tela, o texto “pacote” estava desalinhado e ultrapassando os limites da tela.

			Na tela principal do app (após selecionar o contrato), as informações estavam cortadas na parte superior.

			O nome do aplicativo exibido após a instalação estava com capitalização incorreta.

			Android

			Na tela “Meu plano”, não havia scroll, impedindo a visualização completa dos dados.

			Na tela “Perfil”, a ausência de scroll impedia o acesso ao botão “Sair do app”.

			Esses problemas comprometiam a experiência do usuário em determinados modelos de aparelhos e versões do sistema operacional.

			Correção aplicada:
			Foram realizados ajustes de layout e responsividade nas telas afetadas para garantir:

			Implementação correta de scroll sempre que o conteúdo exceder o tamanho da tela.

			Correção de alinhamento e dimensionamento dos textos.

			Adequação da exibição de informações no topo das telas, evitando cortes.

			Ajuste do nome exibido do aplicativo após a instalação.

			Com as correções, as telas passam a se adaptar corretamente a diferentes resoluções, modelos de dispositivos e versões de iOS e Android, garantindo usabilidade e visualização completas.

			==BUG - Cobrança duplicada após alteração de titularidade==

			Erro identificado:
			No processo de alteração de titularidade, ao optar pela opção “Não” no modal “Deseja faturar o valor integral no novo titular do contrato?”, o novo contrato era gerado com o campo UltimoFaturamento nulo.
			Como a data de habilitação do contrato anterior é migrada para o novo contrato, isso fazia com que a cobrança do novo titular considerasse um período que já havia sido faturado, gerando cobrança duplicada.

			Correção aplicada:
			O fluxo de alteração de titularidade foi ajustado para definir corretamente o UltimoFaturamento do novo contrato, conforme as seguintes regras:

			Quando o UltimoFaturamento do contrato anterior for menor que a data atual, o novo contrato recebe o UltimoFaturamento como um dia anterior à data atual.

			Quando o UltimoFaturamento do contrato anterior for igual à data atual, essa mesma data é atribuída ao UltimoFaturamento do novo contrato.

			Quando o UltimoFaturamento do contrato anterior for maior que a data atual ou nulo, o comportamento permanece inalterado.

			Com esse ajuste, o sistema passa a evitar cobranças de períodos já faturados, garantindo a correta continuidade da cobrança após a alteração de titularidade.

			==BUG - Inconsistências na criação e registro de débito recorrente via Pix==

			Erro identificado:
			Foram identificados problemas no fluxo de criação e registro de débito recorrente Pix, envolvendo integração, persistência de dados e interface:

			Na resposta da ação CRIAR_LOCATION_DEBITO_RECORRENTE_PIX, o campo id estava sendo armazenado em formato exponencial (ex.: 7.0722491541282673E18), enquanto o valor correto gerado pela plataforma era um número inteiro completo.

			A ação CRIAR_LOCATION_DEBITO_RECORRENTE_PIX estava sendo registrada incorretamente na tabela TB_LogDebitoRecorrente como CONFIRMAR_AUTORIZACAO_DEBITO_RECORRENTE_PIX, gerando inconsistência no histórico das operações.

			Na tela do contrato, ao salvar uma conta de débito, não era possível vincular o tipo de conta de débito, impedindo a configuração correta da cobrança recorrente.

			Correção aplicada:

			O tratamento da resposta da integração foi ajustado para garantir que o campo id seja armazenado corretamente como valor inteiro, sem conversão para notação exponencial.

			O registro de logs foi corrigido para que a ação CRIAR_LOCATION_DEBITO_RECORRENTE_PIX seja gravada com a identificação correta na TB_LogDebitoRecorrente.

			A tela de cadastro de conta de débito no contrato foi ajustada para permitir a seleção e vinculação correta do tipo de conta, concluindo o fluxo de configuração do débito recorrente.

			Com esses ajustes, o processo de débito recorrente via Pix passa a operar de forma consistente, com dados corretos, histórico confiável e configuração completa pelo usuário.

Caio.silva em 14h42min de 16 de dezembro de 2025

2025-12-16T14:42:22Z

← Edição anterior		Edição das 14h42min de 16 de dezembro de 2025
Linha 63:		Linha 63:
	A rotina de integração foi ajustada para respeitar a mesma validação aplicada na tela, desconsiderando extratos com EmiteNotaPosPagamento = 1 que não possuam data de pagamento.		A rotina de integração foi ajustada para respeitar a mesma validação aplicada na tela, desconsiderando extratos com EmiteNotaPosPagamento = 1 que não possuam data de pagamento.
	Com isso, esses extratos deixam de ser enviados para integração quando acionada a opção “Integrar de acordo com filtro”, garantindo consistência entre a interface e o processamento automático.		Com isso, esses extratos deixam de ser enviados para integração quando acionada a opção “Integrar de acordo com filtro”, garantindo consistência entre a interface e o processamento automático.

			==BUG - Datas incorretas na impressão de NFCOM==

			Erro identificado:
			Na impressão de NFCOM, os campos início de período, fim de período e data de vencimento estavam sendo exibidos com um dia anterior ao valor correto.
			O problema ocorria mesmo quando os dados estavam corretamente gravados na fatura e na nota, resultando em divergência entre as informações do sistema e o PDF gerado.
			Os campos afetados eram $F{dataVencimentoFatura}, $F{inicioPeriodo} e $F{fimPeriodo}.

			Correção aplicada:
			Foi realizado o ajuste no processo de geração/impressão da NFCOM para garantir que as datas sejam renderizadas corretamente no PDF, respeitando exatamente os valores armazenados no sistema, sem aplicação indevida de offset de data.
			Com a correção, os campos de período e vencimento passam a ser exibidos corretamente na impressão da nota fiscal.

			==BUG - Falha no envio em lote de cobranças recorrentes por erro individual==

			Erro identificado:
			Na tela de geração de cobranças recorrentes de cartão de crédito, ao acionar a opção “Enviar cobranças para adquirente”, quando uma das faturas do lote retornava um erro não esperado pela plataforma, o sistema lançava um NullPointerException.
			Esse erro interrompia todo o processamento, impedindo o envio das demais faturas válidas do lote. A situação ocorria quando a resposta da integradora não podia ser interpretada corretamente, mesmo sendo um erro específico de apenas uma fatura (ex.: dados inválidos do cartão).

			Correção aplicada:
			O processamento do lote foi ajustado para tratar corretamente erros individuais retornados pela integradora, evitando a geração de exceção não tratada.
			Com a correção, uma fatura que retorne erro passa a ser isolada, permitindo que as demais faturas do lote continuem sendo enviadas normalmente, sem impacto no processamento geral das cobranças recorrentes.

			==BUG - Bloqueio indevido do botão de filtro na movimentação interna==

			Erro identificado:
			Na tela Estoque > Movimentações > Movimentação interna > Nova movimentação, quando o Local de origem selecionado não possui EntidadeCustodia = CONTRATO, o campo “Cód. contrato” não é exibido. Nessa situação, o botão de filtrar permanecia bloqueado, impedindo o avanço do processo, mesmo não sendo necessário informar contrato para esse tipo de local.

			Correção aplicada:
			O comportamento do botão de filtro foi ajustado para considerar a exibição do campo “Cód. contrato”.

			Quando o campo não estiver disponível na tela, o botão de filtro permanece habilitado.

			Quando o campo estiver disponível, o botão fica desabilitado até o preenchimento do código do contrato, seguindo o funcionamento esperado.

			Com isso, o fluxo de movimentação interna passa a funcionar corretamente em todos os cenários de local de origem.