Diagnóstico — por que 5 meses estão em aberto (atualizado)
O cliente enviou 10 DAS (02/2025 a 11/2025) e reclama que "consta débitos em aberto". A análise atualizada (janela 16 meses) mudou a causa-raiz: não é ETL — as 5 competências em aberto (11/2025 a 03/2026) não têm DAS gerada nem pagamento registrado nem no .85 nem no planum. O problema está upstream — o cliente precisa apresentar os comprovantes.
TL;DR — hipótese principal mudou
Cliente precisa apresentar comprovantes
O pgdas_local do planum e o pgdas do .85 estão 100% sincronizados para este CNPJ. Os mesmos 15 registros de transmissão, 10 DAS geradas, 10 pagamentos. As 5 competências em aberto não existem em lugar nenhum — nem como DAS, nem como pagamento. A próxima ação não é técnica — é ligar pro cliente pedir os PDFs e o número_guia de cada DAS que ele pagou.
Pagamento por canal não-PGDAS-D
Se o cliente pagou por boleto avulso, parcelamento antigo, ou outro canal que não alimenta o pgdas.pagamentosset, o pagamento pode estar em outro lugar (ex.: dividaativadebitossset). A frase "guias criadas fora do sistema" sugere isso. Mas o dassendaguiaset mostra que as 10 DAS pagas vieram do sistema_origem='0001' (PGDAS oficial), então se a 11/2025 foi paga por canal paralelo, a RFB também não tem registro.
A cadeia RFB → .85 → planum (atualizada)
flowchart LR
RFB([RFB / SIMPLES Nacional])
P85[".85 · banco PGDAS
pgdas.pagamentosset
pgdas.pgdascontribuinteset"]
P85G["pgdas.pgdasguias
situacao_guia=1"]
PGM[".85 · PGDAS
pgdas.cnpjmunicipioset"]
ETL["srv-app · auditoria
pgdas_local.carregar_pagamentos()"]
PL["planum · pgdas_local
pgdas_local.pagamentosset"]
BAIXA["pgdas_local.simples_baixar_guia_2()
↳ pgdasguias.situacao_guia=2
↳ pgdascontribuinteset.quitada=t"]
CLI([Cliente · vê 'em aberto'])
RFB -->|arquivo mensal| P85
P85 --> P85G
P85 -.->|precisa| PGM
PGM --> ETL
P85 --> ETL
ETL --> PL
PL --> BAIXA
BAIXA -.->|se pipeline rodasse| CLI
style P85 fill:#0a2a40,stroke:#007acc,color:#dcdcaa
style PGM fill:#2d2533,stroke:#c586c0
style ETL fill:#1f3a2e,stroke:#4ec9b0,color:#dcdcaa
style PL fill:#0a2a40,stroke:#007acc,color:#dcdcaa
style BAIXA fill:#1f3a2e,stroke:#4ec9b0
style CLI fill:#3a2a1f,stroke:#f0883e
Por que a causa-raiz mudou (16 meses provam)
A versão anterior da análise (19/06 manhã) culpava o ETL. A análise com 16 meses desmente isso: se o ETL estivesse quebrado, o planum estaria atrás do .85 — mas ambos têm exatamente as 10 DAS pagas e as 5 em aberto.
ETL do carregar_pagamentos
As 10 DAS pagas (01-10/2025) foram replicadas do .85 → planum, e a simples_baixar_guia_2 marcou quitada=t em todas. O pipeline ETL está funcionando pra este CNPJ.
Replicação do arquivo da RFB → .85
Os pagamentos de 11/2025 em diante não chegaram ao armazém nacional (pgdas.pagamentosset do .85). Não é falha do ETL do nosso lado — é falha do ETL da RFB/PGDAS-D/DEFIS que popula o .85. Ou o cliente não pagou.
O que não é
Não é ETL atrasado
Se fosse, o planum estaria atrás do .85. Não está. O planum enxerga exatamente o que o .85 enxerga para este CNPJ. As 10 DAS pagas foram replicadas, as 5 em aberto estão idem em ambos.
Não é erro de competência
Cada DAS paga (01-10/2025) tem numero_guia, vencimento, valor e fkpgdascontribuinte corretos. O pagamento casa 1-a-1. A divergência não é "mês errado".
Não é CNPJ errado
O CNPJ bate nos três bancos: 59048820000104 = GCL DE FREITAS PSICANALISE LTDA no planum e no .85. Razão social idêntica. Não é "CNPJ parecido".
Não é parcelamento
parcsndebitosset (planum e PGDAS) e parcsnparcelamentoset estão vazios para o CNPJ. Não há débitos parcelados. O cliente não está devendo "antigos".
Não é "débitos federais no GLOBAL"
O GLOBAL é só cadastro — não tem DAS individuais. E o CNPJ nem consta em public.cnpj do GLOBAL (49,5M de CNPJs cadastrados, este não está).
Não é filtro de data do ETL
O ETL filtra pgdas.pagset.data_inicial >= '01/01/2018'. Inválido: as DAS replicadas são de 2025, então o filtro passou. Não é causa.
pgdas_local.carregar_pagamentos · pgdas_local.simples_baixar_guia_2
·
Diagnóstico READ-ONLY · 2026-06-19