ITN-03 na Prática: 3 Achados de uma Implementação de Referência do ONR-CAD

Contexto

A ITN 003/2025 define como cada serventia informa mensalmente ao ONR os atos praticados, alimentando o ONR-CAD (o cadastro nacional de imóveis). Os dados trafegam num arquivo JSON validado contra os schemas do Anexo IV (pacote ITN003_AnexoIV_v1.0), com um schema para imóveis urbanos e outro para rurais. Se você quer o panorama do processo (quem envia, prazos, o que entra), veja ITN-03: o que é e como enviar os atos ao ONR.

Este artigo é o lado técnico. Ao construir uma implementação de referência do envio à ITN-03 — geração do arquivo, validação contra os schemas oficiais e conferência contra dados reais de produção — a equipe de engenharia da Mupi Systems (responsável pelo RI-Online) encontrou três pontos que merecem atenção. Cada um vem com evidência reproduzível, análise de impacto e uma proposta de correção. A intenção é somar ao padrão: nenhum achado vem sem um caminho de solução.

Um schema só se confirma correto quando uma implementação independente consegue gerar e validar documentos reais contra ele sem contornos.

Como os achados foram levantados

Boa parte das arestas de uma especificação só aparece na tentativa de implementá-la de ponta a ponta. Construímos um gerador e validador de arquivos ITN-03 rodando contra os schemas do Anexo IV (JSON Schema Draft 7) e o exercitamos com um acervo real de produção (452 atos, 18 deles rurais). Foi validando esse arquivo contra o schema, campo a campo, que os pontos abaixo apareceram.

Cada achado segue o formato Evidência → Impacto → Proposta. Todos são reproduzíveis a partir dos arquivos de schema do pacote ITN003_AnexoIV_v1.0.

Resumo dos achados

#	Achado	Severidade
1	Identificadores do imóvel rural (car, ccir_sncr, cib) são escalares únicos — não representam fusão de imóveis com múltiplos cadastros	Alta
2	ccir_sncr modelado como number (identificador tratado como quantidade)	Média
3	car com maxLength: 41 exige o CAR sem máscara; combinado à rejeição do arquivo inteiro por um único imóvel inválido	Média

Os achados em detalhe

1. Identificadores do imóvel rural não comportam fusão (múltiplos cadastros) — Alta

Evidência. No imoveis-rurais-onr.schema.json, os identificadores cadastrais do imóvel são escalares únicos no nível da matrícula, não listas:

"ccir_sncr": { "anyOf": [ { "type": "number" }, { "type": "null" } ] },
"cib":       { "anyOf": [ { "type": "string", "maxLength": 8 }, { "type": "null" } ] },
"car":       { "anyOf": [ { "type": "string", "maxLength": 41 }, { "type": "null" } ] }

São um car, um ccir_sncr, um cib por imóvel. O array dados_imovel que existe no schema guarda endereço e descrição (logradouro, CEP, município), não os identificadores cadastrais — então não serve de escape para repetir cadastros.

Agora considere uma fusão de imóveis rurais: duas (ou mais) matrículas, cada uma com seu próprio CAR (e seu CCIR/CIB), são unificadas em uma única matrícula. No mundo real, o imóvel resultante continua correspondendo a múltiplos CARs — o Cadastro Ambiental Rural (SICAR), o CCIR (Incra) e o CIB (Receita) só são consolidados num único registro quando o proprietário atualiza cada base, o que não é imediato nem garantido no momento do ato registral.

Impacto. No instante da fusão, a matrícula legitimamente aponta para N cadastros ambientais/fiscais, mas o schema só aceita um. O implementador é forçado a escolher um CAR e descartar os demais — perdendo informação e enviando um retrato incompleto do imóvel — ou a deixar o imóvel de fora do envio. Não há como o ONR-CAD saber que aquele imóvel tem outros cadastros vinculados. É uma perda estrutural, não um detalhe de formatação: a topologia “uma matrícula ↔ vários cadastros”, comum em fusões (e também em imóveis que ainda não consolidaram seus CARs), não tem representação.

Proposta.

• Permitir cardinalidade N para os identificadores cadastrais do imóvel rural: aceitar car, ccir_sncr e cib como listas, ou introduzir um bloco cadastros_vinculados com múltiplas entradas, cada uma com seu tipo (CAR/CCIR/CIB) e situação (ativo/em consolidação).
• Documentar explicitamente o tratamento de fusão e desmembramento nos exemplos do Anexo IV — hoje nenhum dos exemplos cobre esse caso.

2. ccir_sncr modelado como número — Média

Evidência. O campo ccir_sncr é modelado como type: "number". Mas o CCIR/código SNCR é um identificador de cadastro, não um valor sobre o qual se faça aritmética.

Impacto. Modelar um identificador como número traz dois riscos concretos: perda de zeros à esquerda (um código como 0123456 vira 123456) e o tratamento por ponto flutuante, que pode reformatar ou arredondar códigos longos. Além disso, sugere semanticamente uma grandeza numérica onde há um rótulo. É a mesma classe de problema que a modelagem de números como string com vírgula na ITN-04 — só que no sentido inverso.

Proposta. Modelar ccir_sncr como type: "string" com pattern (se houver formato fixo), preservando zeros à esquerda e a fidelidade do identificador. A regra geral: identificadores são strings, mesmo quando compostos só por dígitos.

3. car sem máscara e a rejeição do arquivo inteiro — Média

Evidência. O car aceita type: "string" com maxLength: 41. O número do CAR, sem máscara, é a concatenação de UF (2) + código IBGE do município (7) + hash de 32 caracteres = 41. Ou seja, maxLength: 41 é exatamente o comprimento do CAR cru, sem nenhuma folga. Só que todo sistema que lida com CAR o exibe e armazena com máscara (MG-3132008-EBED.0781...), o que passa de 40 caracteres com hífens e pontos e ultrapassa o limite. Esse foi o nosso principal bloqueador em produção: o CAR salvo com máscara simplesmente não validava.

Impacto. O padrão exige, sem dizer, que o CAR seja enviado sem a máscara — uma decisão de formatação que não está documentada e que quebra silenciosamente quem envia o valor na forma como ele aparece em qualquer tela. Some-se a isso o comportamento do portal: um único imóvel inválido reprova o arquivo inteiro. Um lote de dezenas de imóveis rurais é recusado por causa de um CAR mal formatado ou de um cadastro incompleto em uma matrícula, sem sinalizar qual.

Proposta.

• Aceitar o CAR com ou sem máscara, normalizando no recebimento; ou documentar explicitamente o formato esperado (sem máscara) e o comprimento.
• No processo de recepção, permitir validação e aceite por imóvel (ou um endpoint de validação prévia), em vez de reprovar o arquivo inteiro — assim o cartório corrige pontualmente, sem reenviar tudo.

Enquanto o padrão não muda, do lado do implementador tratamos os dois pontos: normalizamos o CAR removendo a máscara e exportamos apenas os imóveis válidos, listando à parte as matrículas pendentes e o motivo (CAR, CCIR ou CIB faltando/mal formado). Assim o lote nunca é recusado por inteiro.

Uma nota de processo

Dois dos três achados (o 2 e a primeira parte do 3) poderiam ser detectados antes da publicação com uma etapa de validação automatizada dos schemas e dos exemplos: verificar identificadores modelados como número e limites de tamanho que não acomodam o formato real do dado. O achado 1 é de outra natureza — é modelagem de domínio (a cardinalidade imóvel ↔ cadastros) e só aparece confrontando o schema com casos reais como a fusão.

Conclusão

O ONR-CAD só cumpre seu papel se o retrato que cada cartório envia for fiel e completo. Nos três pontos acima, essa fidelidade hoje depende de contornos de cada implementador: escolher qual CAR sacrificar numa fusão, remover uma máscara não documentada, driblar a rejeição do lote inteiro. Dois são correções de baixo esforço no schema; o primeiro pede uma decisão de modelagem sobre imóveis com múltiplos cadastros.

Documentamos os achados de forma aberta para que possam ser verificados, contestados ou incorporados por quem mantém a especificação. É uma contribuição técnica ao SREI e ao ONR: um padrão mais sólido reduz o custo de adoção e aumenta a confiabilidade do cadastro nacional. Vale registrar que pontos semelhantes de consistência entre normas já foram levantados no lado da escrituração, em SREI e ITN-04: 14 Melhorias para a Interoperabilidade.

Críticas, correções e dúvidas sobre qualquer um dos achados são bem-vindas em suporte@mupisystems.com.br.

Os achados deste artigo são reproduzíveis a partir dos schemas do pacote ITN003 Anexo IV v1.0, com base em uma implementação de referência exercitada contra um acervo real de 452 atos (18 rurais).