Painel de leitura da documentação, planejamento e implementação por feature, com seleção centralizada antes da navegação.
Author: Thiago
Date: 2026-04-11
Project: cobranca-hml
Esta feature cria uma estrategia local de sincronizacao dos dados da Chronos para eliminar a dependencia de chamadas remotas em tempo real nos grids e indicadores do sistema de cobranca. Hoje a integracao da Travessia depende de consulta online durante a renderizacao dos fluxos operacionais, o que introduz timeout, variacao de latencia, risco de indisponibilidade e dificuldade de homologacao previsivel. A proposta e inverter esse modelo: sincronizar os dados da API em jobs controlados, persistir localmente e passar a alimentar dashboard, cards e acoes a partir dessa base local consolidada.
O objetivo nao e substituir a logica funcional ja homologada da feature chronos-titulos, e sim mudar a forma de abastecimento da origem Travessia. A regra de negocio continua a mesma: ownership segue no MySQL, enriquecimento pode seguir usando SQL Server, classificacao entre quebras, 30 dias, advogado e renegociacoes permanece centralizada, e a identidade visual B/T continua igual. O ganho esperado e operacional: tela mais rapida, menor risco de timeout, maior previsibilidade e menor acoplamento da dashboard com disponibilidade da API Chronos.
O modelo atual de consulta online da Chronos causa quatro problemas concretos:
QuebrasMesmo com ajustes de timeout, lote e otimizacao, esse desenho continua fragil para uso diario. A aplicacao precisa passar a trabalhar com uma base local sincronizada, com atualizacao controlada e rastreavel.
chronos-tituloscobranca-hmlO sistema deve persistir localmente os dados necessarios da Chronos para alimentar os fluxos da Travessia sem consultar a API a cada request da dashboard.
O sistema deve permitir uma carga completa inicial da carteira Chronos homologada, com registros suficientes para construir historico local e permitir reprocessamento.
O sistema deve permitir sincronizacao recorrente incremental, em janelas programadas, para atualizar contratos, parcelas e estados relevantes.
Os endpoints impactados do dashboard devem ler prioritariamente da base local sincronizada, e nao da API remota da Chronos em tempo real.
Antes de um registro Travessia entrar em qualquer grid operacional, o sistema deve continuar validando ownership por cpf_cnpj em cobranca_atribuicao_cliente com status = 'ATIVO'.
As regras de classificacao entre quebras, 30 dias, advogado e renegociacoes devem permanecer equivalentes ao comportamento homologado atual.
Quando a base sincronizada nao tiver todo o contexto operacional necessario, o sistema pode continuar enriquecendo via SQL Server por cpf_cnpj e referencias derivadas.
Cada lote sincronizado deve registrar metadados minimos de execucao, incluindo inicio, fim, status, quantidade processada e eventual erro resumido.
O sistema deve permitir reprocessar dados sincronizados localmente sem depender de refazer imediatamente toda a coleta externa.
O frontend atual nao deve exigir redesign para consumir a base local. Os contratos de resposta devem continuar compativeis com a dashboard existente.
cobranca-hmlO cobrador acessa dashboard_cobrador.php e carrega Quebras, Renegociacoes, Recebimentos 30 Dias e Recebimentos Advogado. Em vez de aguardar consulta remota da Chronos durante a renderizacao, o backend responde a partir da base local sincronizada, preservando o mesmo comportamento operacional e visual dos grids.
Ao investigar um titulo Travessia, o analista consegue verificar nao so a classificacao funcional, mas tambem de qual sincronizacao aquele dado veio, quando foi atualizado localmente e se houve enriquecimento complementar via SQL Server.
Se a Chronos ficar indisponivel durante uma janela de sincronizacao, a dashboard continua operando com a ultima base local valida. A equipe tecnica recebe rastros suficientes para diagnosticar a falha e repetir o job depois, sem interromper a rotina dos cobradores.
chronos-titulosA recomendacao para esta feature e implementar uma camada local de persistencia e sincronizacao da Chronos antes de qualquer expansao funcional nova na dashboard. O sistema ja validou a regra de negocio da Travessia; agora a prioridade correta e estabilidade, previsibilidade e performance operacional.