Sistema Exclusivo Opponet

Gestão Inteligente para sua Franquia de Fibra

Auditoria de vendas, controle de instalações e conciliação financeira automatizada em uma única plataforma integrada.

Auditoria Financeira

Conciliação automática do repasse da Algar com suas vendas reais, identificando divergências e contestações instantaneamente.

Gestão Operacional

Controle total sobre ordens de serviço, agenda de instalações e performance da equipe técnica em tempo real.

Relatórios Estratégicos

Visibilidade completa do churn, novas vendas e lucratividade por região com dashboards intuitivos e exportáveis.

Revise o plano antes da aprovação. 1. Não reutilize nem altere a migration já aplicada: 20260823033000_fix_customer_import_schema_versioning.sql 2. Crie uma nova migration, com timestamp único, por exemplo: 20260823043000_add_import_rows_processed_at.sql 3. A nova migration deve: - adicionar processed_at timestamptz nullable com ADD COLUMN IF NOT EXISTS; - redefinir somente as RPCs que precisam dessa coluna; - preservar a assinatura canônica de execute_customer_import_chunk; - preservar SECURITY DEFINER, SET search_path e grants; - ser transacional e idempotente. 4. Em execute_customer_import_chunk, preencher processed_at somente depois que: - customer foi criado ou reconciliado; - endereço foi criado; - journal foi criado; - target_id foi definido. Tudo deve permanecer na mesma subtransação atômica. Se qualquer etapa falhar, nenhuma delas pode persistir. 5. A validação final não deve considerar somente processed_at. Uma linha definitivamente importada deve possuir simultaneamente: - target_id não nulo; - processed_at não nulo; - customer correspondente existente; - journal correspondente existente. 6. O rollback deve limpar target_id e processed_at somente depois de reverter com sucesso os registros protegidos pelo version_tag. 7. Não presuma regeneração automática dos tipos: - regenere explicitamente os tipos do Supabase ou atualize o tipo local correspondente; - confirme que processed_at aparece nos tipos TypeScript. 8. Antes de concluir, execute uma comparação de todas as colunas utilizadas pelas RPCs contra information_schema.columns e informe se existe qualquer outra referência inexistente. 9. Execute tsgo e bun run build. 10. Não execute dry run, importação, retomada ou rollback. O lote deve permanecer import_failed e as contagens definitivas devem continuar zeradas. Apresente no relatório final: - novo nome da migration; - schema final de import_rows; - ordem atômica das operações; - critério completo da validação final; - contagens finais; - resultados de typecheck e build. Corrija exclusivamente a paginação e a retomada da importação definitiva de Clientes IXC. Lote: 91acd5e5-595d-4144-9f4e-1b8504d97833 Estado comprovado: - 13.158 aptos; - 1.000 importados integralmente; - 12.158 restantes; - 1.000 customers; - 1.000 customer_addresses; - 2.000 journals; - 1.000 import_rows com target_id e processed_at; - linhas processadas: 2 a 1.001; - causa: consulta pendingLines sem paginação, limitada implicitamente a 1.000 pelo PostgREST. Não apagar, reimportar, reverter ou modificar os 1.000 registros já concluídos. 1. Backend paginado e retomável Refatore src/lib/ixc-import.functions.ts para que cada chamada processe no máximo um bloco de 500 linhas. A consulta do próximo bloco deve: - filtrar pelo batch_id; - considerar somente action = 'insert'; - considerar somente linhas ainda não concluídas; - exigir target_id IS NULL; - exigir processed_at IS NULL; - excluir status ignored; - ordenar por line_number crescente; - usar limit(500) explicitamente. Não carregue as 12.158 linhas restantes em uma única consulta. Não dependa do limite padrão do PostgREST. Não use offset para localizar pendências; sempre busque o próximo bloco ainda não processado. 2. Preservação e reconciliação Antes de cada bloco: - reconciliar linhas que já tenham customer + journal válidos, se necessário; - nunca reenviar as 1.000 linhas com target_id e processed_at; - manter idempotência por id_ixc; - impedir criação de customer ou endereço duplicado. 3. Execução incremental Crie ou ajuste uma Server Function para: - autenticar e autorizar o administrador; - processar somente o próximo bloco de até 500; - retornar: - processed_this_call; - processed_total; - pending_total; - failed_total; - expected_total; - progress_percent; - has_more; - não chamar a validação final enquanto pending_total for maior que zero. Use contagens exatas com count: 'exact' e head: true. Não determine totais pela quantidade de registros retornada por uma consulta limitada. 4. Orquestração no frontend O frontend deve: - chamar sequencialmente um bloco por vez; - aguardar a conclusão antes de chamar o próximo; - atualizar o progresso após cada resposta; - mostrar, inicialmente, 1.000 de 13.158; - manter o botão desabilitado durante cada chamada; - impedir chamadas paralelas e cliques duplicados; - permitir interromper com segurança entre os blocos; - se a página for fechada, permitir retomar a partir do primeiro bloco pendente. Não mantenha uma única requisição aberta para processar os 12.158 restantes. 5. Validação final Somente quando pending_total = 0: - executar validate_customer_import_final uma única vez; - exigir exatamente 13.158 linhas com target_id e processed_at; - exigir 13.158 customers distintos correspondentes; - validar journals e integridade dos endereços conforme as regras atuais; - alterar o lote para imported somente após validação completa. 6. Falhas Se um bloco falhar: - interromper o loop; - manter os blocos anteriores preservados; - marcar o lote como import_failed; - mostrar toast amigável com bloco e progresso; - não abrir Error Boundary nem tela branca; - permitir retomada segura do próximo bloco pendente; - não executar automaticamente uma segunda tentativa. 7. Concorrência Implemente proteção no servidor contra duas execuções simultâneas do mesmo lote. Não dependa apenas do botão desabilitado no frontend. Use a trava/estado transacional já compatível com o schema existente, sem criar solução destrutiva. 8. Escopo desta correção Não executar importação, retomada, rollback ou dry run. Não modificar os 1.000 registros persistidos. Não alterar status ou dados do lote durante a implementação. Não alterar banco ou criar migration se não for necessário. Não alterar landing page, planos, produtos ou contratos. 9. Verificação Execute: - tsgo; - bun run build. Ao final, confirme: - os 1.000 clientes continuam íntegros; - continuam existindo 12.158 pendentes; - nenhum cliente duplicado; - nenhuma importação foi executada; - paginação explícita de 500; - validação final somente com pending_total = 0; - arquivos alterados; - resultados de typecheck e build.