# Mapeamento do dump Monetarie 23/07 (contabilidade + crédito + securitização) e desenho do ETL

Data: 2026-07-24. Trabalho READ-ONLY sobre `~/Downloads/2026-07-23-dump-dbs-monetarie/` (523MB, CSV por tabela, origem MySQL — datas `0000-00-00`, UTF-8). **Este é o backup que a frente contábil aguardava** (pausada em 21/07 na decisão "aguardar backup da Dimensa"): contabilidade, crédito, consignado, securitização, debêntures e administrativo. PII abundante (CPF/CNPJ, endereços) — o dump NÃO entra no repo; cargas de laboratório em `.scratch/` (gitignorado), como no ETL PIX/SPB de 01/07.

## 1. Inventário das 5 bases

| Base | Conteúdo | Tabelas-chave | Volumes | Período |
|---|---|---|---|---|
| **monetarie_webctb** | **CONTABILIDADE** (o WEBCTB do balancete assinado) | `diario2021..2026` (lançamentos), `placon2021..2026` (plano + visão mensal) | 80.677 lançamentos; ~2.053 contas/ano | **2021-12-02 → 2026-07-17** |
| **monetarie_webcred** | Crédito (capital de giro, consignado via conveniadas, FIDC) | `operacao` (4.909), `cronograma` (64.853 parcelas), `rup` (4.385 pessoas), `clientes` (3.627), `conveniadas` (246), `produtos`, garantias/avalistas/sócios, `ioperfidc` | — | aceites 2022-06-08 → **2026-07-21**; parcelas até 2032 |
| **monetarie_websec** | Securitização/cessão (portfólio histórico; bate com a MAIOR receita do balancete: cessão R$ 1,88M) | `operacao` (36.193), `cronograma` (212.727), `rup` (44MB), `fundo` | — | 2013-08-01 → **2026-07-23** |
| **monetarie_webdebenture** | Captação por debêntures | `compra` (83), `investidor` (37), `cronograma` (3.794), série/empresa | — | 2021-08-02 → 2024-03-19 |
| **monetarie_websif** | Administrativo/financeiro (alimenta o diário) | `ctblan` (6.681 lançamentos), `pagar` (3.639 títulos c/ retenções ISS/IR/PIS/COFINS/INSS), `fornecedores`, `contadesembolso`, `bancos`, `carteira` | — | 2022-06-14 → **2026-07-23** |

Movimento do diário por ano (soma de VALOR): 2022 R$ 57,7M; 2023 R$ 243,0M; 2024 R$ 441,8M; 2025 R$ 8.455,4M; 2026 (até 17/07) R$ 1.028,8M.

## 2. PROVA DE FIDELIDADE (o teste de ouro passou)

O `diario2026` foi batido contra o **balancete assinado de Maio/2026** (PDF do contador, o mesmo do cruzamento de 10/07): débitos E créditos de maio das 5 contas críticas do money path — CORNER SPI, CELCOIN, PIXCARD, TRANSITÓRIA CELCOIN e SALDO LIVRE PJ — **10/10 EXATOS AO CENTAVO**. Contas sem movimento (capital social 7,3M, depósito BACEN 2M) idem.

Conclusões estruturais:
- **`diario*` é a fonte autoritativa** — reconstruímos qualquer balancete a partir dele.
- `placon*` é visão derivada com semântica própria (as colunas mensais NÃO são o movimento simples nem acumulado — incluem outras dimensões); **não usar como fonte**; serve no máximo como conferência secundária depois de decifrada.
- Como o diário vai até 17/07/2026, dá para carregar a **HISTÓRIA CONTÁBIL COMPLETA** (não só saldos de abertura) — muda a estratégia da frente contábil para melhor.

## 3. Formato e gotchas de parsing

- CSV com **quebras de linha embutidas** no COMPLEMENTO (registros multi-linha sem quoting consistente): ~0,3-1,7% das linhas por arquivo quebram o parser ingênuo (diario2023: 120 de 6.979). O ETL precisa de um leitor tolerante (recompor registro pela âncora `^\d{4}-\d{2}-\d{2},` OU csv.reader com validação de aridade + costura da linha anterior) e **contabilizar 100% das linhas** (gate: nenhum registro descartado em silêncio).
- Datas MySQL `0000-00-00` = nulo semântico.
- `diario.DEBITO/CREDITO` = contas WEBCTB de 13 dígitos — **exatamente o vocabulário do de/para já mapeado** em `docs/reports/2026-07-10-balancete-oficial-vs-plano-vivo.md` (§3: 242 analíticas → plano vivo; §5: 34 folhas novas propostas ids 50_305-50_338).
- Chaves de ligação vivas: `diario.SISTEMA/CODOPERACAO/CODCRONOGRAMA/CODLANC_CTBLAN` ligam o lançamento contábil à operação de crédito/parcela/lançamento administrativo de origem — trilha completa contabilidade↔operacional.
- `fundo.CODCONTA*` (webcred/websec): o binding operação→conta contábil por fundo JÁ EXISTE nos dados (contas de desconto/juros/empréstimo/financiamento/retenção por fundo).
- `rup` = cadastro único de pessoas (PII pesada).

## 4. De/para com o nosso core (mapa de destino)

| Origem | Destino no core | Observações |
|---|---|---|
| `webctb.diario*` | `cosif_journal_entries` (+ `cosif_account_balances` via SnapshotGenerator mensal) | Conversão de conta WEBCTB→COSIF vivo pelo de/para de 10/07 (§3/§5); valores em CENTAVOS; conta sem de/para = **fail-closed em staging** (relatório de lacunas p/ o contador), nunca chute |
| `webctb.placon*` | (não carrega) | Conferência secundária apenas |
| `webcred.operacao/cronograma` | `loans`/`loan_installments` (frente de crédito existente do Bruno) | `COSIFCONTABANCO` + fundo dão o binding contábil; modalidades EM/BL etc. a decifrar com 1 amostra por tipo; consignado via `conveniadas` |
| `webcred.rup/clientes` | conciliar com `users`/`accounts` já migrados (ETL AutBank) | NÃO recriar pessoas: match por CPF/CNPJ; divergência = relatório |
| `websec.*` | decisão do dono: carregar como acervo de cessão (read model) ou ignorar histórico pré-SCD | 36k operações desde 2013 — maioria é história da securitizadora; a RECEITA de cessão já está no diário |
| `webdebenture.*` | `investments`/captação (frente de investimentos do time) | 83 compras; conferir com o Bruno o destino |
| `websif.pagar/fornecedores` | contas a pagar (`payables`) | Retenções por título (ISS/IR/PIS/COFINS/INSS) prontas; espelha as 77 analíticas de fornecedores do balancete |
| `websif.ctblan` | já refletido no diário (SISTEMA=WEBSIF) | NÃO carregar em dobro — usar só para trilha/validação |

## 5. Desenho do ETL (fases com gates de conciliação, padrão do ETL v2 de 01/07)

**Fase 0 — Staging local (laboratório, sem tocar HML/PROD):** carga integral dos CSVs em schemas `stg_webctb/stg_webcred/...` num Postgres local (`.scratch/`), leitor tolerante a multi-linha, contagem linha a linha origem×staging (gate: 100%).

**Fase 1 — Contabilidade (o coração):**
1. De/para WEBCTB→COSIF materializado em tabela (`etl_conta_depara`), semeado do relatório de 10/07 + `fundo.CODCONTA*`; TODA conta do diário sem destino → relatório de lacunas (decisão contador/dono ANTES de carregar).
2. Transform: diário → `cosif_journal_entries` (centavos, entry_date, histórico/complemento, source `webctb_etl`, chave idempotente por hash da linha origem).
3. **Gates de conciliação:** (a) balancete reconstruído de Maio/2026 == PDF assinado AO CENTAVO, conta a conta; (b) totais mensais por grupo 2022-2026; (c) fechamento diário débito==crédito.
4. Snapshots mensais via `SnapshotGenerator` (meses COMPLETOS — o guard novo de data futura já protege).
5. **Costura com o vivo:** nosso core contabiliza PIX/SPB/SISBAJUD desde o go-live — a janela de sobreposição (diário legado vs journal vivo, ~jun-jul/2026) precisa de política anti-duplo-lançamento (decisão de corte: até que data vale o legado, a partir de quando vale o nosso). **Decisão do dono.**

**Fase 2 — Crédito:** operações+cronogramas→loans (com o modelo do Bruno), match de pessoas por CPF/CNPJ, PDD/perdas conferidas contra o diário (contas 1612001400/1600). Gate: carteira bruta e perdas de Maio == balancete (965.254,70 / -36.288,88 / -348.068,49 etc.).

**Fase 3 — Satélites:** payables (websif), debêntures (com o time de investimentos), decisão websec.

**Promoção:** laboratório → HML (com OK) → PROD (com OK + janela), sempre re-rodando os gates no destino.

## 6. Decisões abertas (dono/contador)

1. ✅ **DECIDIDO pelo dono (24/07): data de corte legado×vivo = 30/06/2026.** O diário legado é autoritativo até 30/06; a partir de 01/07 vale o journal do nosso core. Virá um **backup COMPLEMENTAR** para fechar junho; nesta rodada, **MAIO é o último mês considerado fechado** (a conciliação/carga trabalha até 31/05; junho entra quando o complementar chegar). Item de validação derivado: conferir se o nosso core tem lançamentos COSIF com data ≤ 30/06 que colidam com o legado (política: legado vence até o corte).
2. **Lacunas do de/para**: contas WEBCTB sem folha no plano vivo (as 34 propostas de 10/07 + o que o diário completo revelar) — validação do contador para semear (ids 50_305+).
3. **websec**: carregar acervo histórico ou só a posição/receita (que já está no diário)?
4. **webdebenture**: destino junto à frente de investimentos (falar com o Bruno).
5. Retomada do desenho da frente contábil (opção A de 21/07: COSIF vivo como espinha + de/para WEBCTB como atributo + visão "balancete do contador") — agora com carga HISTÓRICA em vez de abertura provisória.

## 7. Próximos passos propostos

1. OK do dono neste mapeamento → montar o laboratório (Fase 0) e o de/para materializado.
2. Rodar a Fase 1 no laboratório até os 3 gates passarem; produzir o relatório de lacunas para o contador.
3. Sessão de decisões (§6) → só então promover.

---

## 8. RESULTADOS DO LABORATÓRIO (Fase 0 executada em 24/07)

Laboratório em `.scratch/etl-dump-20260724/` (gitignorado): `normalize.py` (leitor tolerante v2), `load_staging.sh` (Postgres local `stg_monetarie`), `conciliacao_maio.py` (gate mestre), `lacunas_depara.csv`.

**Normalização:** webctb 100% limpo — todos os diários e placons fecham contagem (80.229 lançamentos em staging; costura de registros multi-linha + reparo de vírgulas sem aspas por coluna absorvedora). webcred carregado; ficam 57 linhas com MÚLTIPLOS registros fundidos numa linha física (rup 56, cronograma 1) — recuperáveis com splitter dedicado na fase de crédito, logadas.

**DESCOBERTA ESTRUTURAL — renumeração do plano em 2025:** diários 2022-2024 usam códigos de 10 dígitos; 2025-2026 usam os 13 dígitos do balancete. Consequência: a reconstrução de saldos usa `placon<ano>.SDO_ANT` como ABERTURA do ano + diário do ano como movimento (o placon É útil: como fonte de abertura anual, não de movimento). Para o histórico completo 2022-2024 será preciso também o de/para 10→13 dígitos (ou carga por era com conciliação por período).

**GATE MESTRE (fechado): balancete de Maio/2026 reconstruído × PDF assinado — 243/243 explicadas.**
- Fórmula: `SDO_ANT(placon2026) + Σ(débitos-créditos) do diário2026 até 31/05`.
- 233/243 analíticas AO CENTAVO.
- 10 restantes = 5 pares perfeitamente espelhados (soma global ZERO), **comprovadamente edições do contador (REGINALDO) em 21/07**, após a foto do PDF (10/07): 17 lançamentos retroativos de impostos inseridos 21/07 18h (R$ 118.559,80) + linhas com `DTHR_ALT` de 21/07 nas exatas contas divergentes. O dump é mais NOVO e mais correto que o PDF.
- Corolário do ETL: conciliações contra snapshots (PDFs) devem usar corte por `DTHR_INCL/DTHR_ALT` ≤ data da foto.

**Lacunas do de/para (13 dígitos):** 418 contas usadas no diário 2025-2026; 243 cobertas pelo de/para de 10/07; 175 nominalmente sem destino — MAS a maioria resolve por REGRA de família (4999200xxx → credores diversos/subledger de fornecedores; 1139xxx → reservas livres; 1123xxx → depósitos bancários). Lista completa com nome e giro em `lacunas_depara.csv`; destaques que precisam de resposta individual: `1123000000083` (giro R$ 17,5M — banco/liquidante não presente no balancete de maio), `1139000000058` (R$ 10,7M — conta MONBANK nova), `3331010000013`/`9331010000017` (compensação nova). **Próximo passo: materializar o de/para com regras de família + lista residual para o contador.**

## 9. Estado e próximos passos (pós-laboratório)

1. ✅ Fase 0 completa com gate mestre fechado (fidelidade da fonte estabelecida em nível de auditoria).
2. Materializar `etl_conta_depara` (regras de família + individuais do relatório de 10/07) → residual para o contador.
3. De/para 10→13 dígitos para o histórico 2022-2024 (investigar se o placon2025 traz a ponte na renumeração).
4. Decisões do dono (§6) antes de qualquer carga no mon_core.
5. Crédito (fase 2): splitter das 57 linhas fundidas + match de pessoas por CPF/CNPJ.

## 10. FASE 1 EXECUTADA NO LAB (24/07 tarde) — contabilidade jan-mai/2026 CARREGADA no mon_core local

Decisões do dono aplicadas: corte legado×vivo = 30/06; **maio fechado** nesta rodada (junho vem no backup complementar); escopo = contabilidade + crédito (websec/debenture/websif próxima rodada).

- **De/para completo para o escopo**: 100% das contas patrimoniais/resultado usadas em jan-mai/2026 com destino (individuais de 10/07 + extras + regras de família); 60 contas PENDENTE_CONTADOR são TODAS de compensação (3x/9x, fora desta carga — ver `pendentes_contador.csv`).
- **Folhas provisórias** semeadas SÓ NO LOCAL (ids explícitos 50_3xx little-endian; nome marcado PROVISÓRIA): propostas §5 usadas + `2.1.6.10.01.10.001` consórcios (50_339) + transitória de implantação `1.9.9.99.01.10.999` (50_399) + ponte de partidas `1.9.9.99.01.10.998` (50_398). NADA foi para seeds do repo — isso exige validação do contador.
- **Descoberta de formato**: 31% do diário 2026 é partida em DUAS LINHAS (linha só-débito + linha só-crédito do mesmo lote) — resolvido com a conta-ponte, que **zera exato por construção** (resíduo R$ 0,00). A transitória de implantação idem (abertura fecha em zero).
- **Carga**: 8.280 lançamentos no `cosif_journal_entries` local (`reference_type='webctb_etl'`, idempotente por DELETE+reload; metadata carrega conta WEBCTB original dos 2 lados + sistema + dthr_incl). 181 lançamentos de compensação FORA (pendência contador); 2 anômalas reais logadas (códigos de 10 dígitos vazados em 23/03/2026, R$ 3.046 — tratar na rodada do histórico com a ponte 10→13).
- **GATE origem×destino: 0 divergências em 45 contas COSIF** (lados débito/crédito agregados separadamente — lição: de/para N→1 cria lançamentos com débito==crédito no destino, que zeram; o backend do balancete já agrega assim e é imune).
- Visualização: core admin local (5174) → Contabilidade → Relatórios Contábeis → período 01/01/2026 a 31/05/2026.

Cadeia de fidelidade completa: PDF assinado ⇄ (243/243) ⇄ staging ⇄ (0 divergências) ⇄ mon_core local.

Próximos: fase 2 crédito (operações→loans, splitter das 57 linhas fundidas, match CPF/CNPJ); ponte 10→13 dígitos p/ histórico 2022-2024; residual de compensação ao contador; junho com o backup complementar.

## 11. FASE 2 EXECUTADA NO LAB (24/07) — crédito webcred CARREGADO no mon_core local com gates fechados

Scripts novos em `.scratch/etl-dump-20260724/`: `match_pessoas.py`, `load_loans.py`, `conciliacao_credito.py` (+ `normalize.py` v3). Tudo LOCAL, idempotente por `metadata.source='webcred_etl'` (DELETE+reload); NADA em HML/PROD.

**Staging 100% (splitter concluído):** rup 4.385/4.385 e cronograma 64.853/64.853, zero irrecuperáveis. As "linhas fundidas" eram vírgulas SEM aspas em campo texto de posição variável (não registros múltiplos): resolvidas com (a) tipos de coluna APRENDIDOS dos registros bons (≥99% conformes) + alinhamento ótimo por programação dinâmica (partição dos n campos em ncols grupos minimizando violações de tipo, aceita só custo zero); (b) heurística vírgula+espaço; (c) 1 fusão manual auditada (rup L3567, `COMPLEMENTO='km7,5'` — vírgula decimal).

**Semânticas provadas empiricamente (codificadas no moduledoc do loader):** `codstatus` 07=PAGO/desembolsada, 05=CANCELADA, 06/18=INDEFERIDA, 03/09/17=aprovada, 01=DIGITANDO; juros da parcela = `vl_dcp` (`vl_face==capitalamortizar+vl_dcp` em 95,4%; DE: face==capital, receita = desconto retido); IOF é da OPERAÇÃO (`tot_iof`); `tot_fac` = capital financiado (≠ Σ faces); `taxa` = % a.m.; `liquida` = DATA de liquidação (NULL = aberta); `baixadopdd='S'` + `dtbaixapdd` = baixa a prejuízo; `ioperfidc` = registro de cessão FIDC por operação (3.095); datas-zero MySQL (`0000-00-00`) = nulo; 15.006 parcelas 100% zeradas (venc. zero, valores zero, nunca liquidadas) de 2 operações rascunho/cancelada = lixo de template, DESCARTADAS explicitamente e contadas no gate.

**Match de pessoas (CPF/CNPJ):** documentos vinham de coluna NUMÉRICA no MySQL (zeros à esquerda perdidos) — o pad 11/14 RESTAURA o documento (doc_invalido caiu de 70 para 2). Resultado: 145 tomadores JÁ SÃO members do core (inclui os grandes de capital de giro, correntistas reais); 3.473 são clientes SÓ-CRÉDITO (consignado/CCB via conveniadas — CERTEL etc.) e viraram `cooperative_members` PROVISÓRIOS (member_number `WC<codcliente>`, `user_id` NULL, metadata com procedência; 27 sem cadastro rup ganham nome placeholder); 1 cliente órfão (apagado de `clientes`) recuperado via cronograma/rup. Divergências de nome nos matched = só abreviação/acentuação. NENHUM user/account criado.

**Carga (gates internos exatos):** 18 `loan_products` provisórios `WC*` (inativos, 1:1 com webcred.produtos), 3.371 members provisórios, **4.909/4.909 loans**, **49.847/49.847 loan_installments** (64.853 − 15.006 zeradas). Dinheiro origem×destino ao CENTAVO: principal R$ 162.431.227,76, recebido R$ 44.095.603,82, face e juros — diff 0 nos quatro. Consistência interna: nenhuma active sem parcela aberta, nenhuma settled com aberta, `outstanding_balance` == Σ capital aberto. Status: 3.519 settled / 943 rejected / 216 approved / 201 draft / 28 active / 1 written_off; 3.094 cedidas (FIDC/LUMEN, aberto 0). Carteira ativa não-cedida hoje: 28 contratos, R$ 2.533.800,00.

**GATE CONTÁBIL 31/05 (carteira × balancete reconstruído), decomposição explicada:**
- EM (`1612001100014`, alvo 965.442,56): capital contratado aberto 1.617.019,11 − 576.443,83 (op 2672 cedida CONTABILMENTE em 06/02 ao DORO FIDC; webcred registra a cessão só em 16/06) − 74.731,94 (capital amortizado parcial até o corte, `icronoparcial` datado) = 965.843,34 → **resíduo R$ 400,78 (0,042%)**, rotulado (rendas acumuladas não recebidas / micro-divergências pré-2026).
- DE (`1613001100013`, alvo 73.606,67; conta sem movimento jan-mai — saldo = abertura): 76.739,67 − 433,00 (parcial) − 2.700,00 (título da op 855, venc. 2023-05-10, aberto no webcred mas FORA da abertura contábil 2026 — divergência pré-legado) = **73.606,67 EXATO**.
- PDD (conferência, não igualdade — conta de perda é PROVISÃO): baixas a prejuízo até 31/05 = DE 3 parcelas/217.210,00 + EM 5/37.235,89; saldos contábeis: perda incorrida EM −36.288,88, esperada EM −348.068,49, incorrida DE −71.378,50, esperada DE −1.306,17.

**Achados para contador/Bruno:** (1) cessão da op 2672: data contábil 06/02 × registro operacional 16/06 (qual data vale?); (2) título op 855 R$ 2.700,00 vivo no webcred e fora do contábil desde antes de 2026; (3) 2 documentos que não validam no DV (metadata `doc_invalido`); (4) 791 parcelas com capital NEGATIVO (ajustes/estornos, preservados com flag); (5) 1 operação com `codstatus=99` desconhecido; (6) produtos `WC*` e members provisórios exigem validação/de-para oficial antes de qualquer promoção.

**Pendências fase 2:** validação do Bruno (produtos WC*→oficiais; destino dos members só-crédito); decisão sobre materializar `loan_movements`/accruals históricos; conveniadas→`consignors`/employers; websec/webdebenture/websif (fase 3); junho com o backup complementar.