| Data de elaboração | 15/07/2026 |
| Responsável pelo estudo | Rodrigo Stefano Sales Nascimento (Assessor) |
| Equipe do estudo | CAOS |
| Alvo | Sistemas Governa - Gestão (Admin) e Governa - Recursos Humanos |
| Origem | Card GG-23 — Analise de impacto da mudança para novo modelo de CNPJ alfanumérico. |
| Objetivo | Verificar como o CNPJ é registrado hoje (telas, validação, gravação e banco), confirmar com dados reais de produção o formato armazenado, e propor a implementação para aceitar o novo CNPJ alfanumérico mantendo total compatibilidade com os registros existentes. |
A Receita Federal instituiu o CNPJ alfanumérico (IN RFB nº 2.229/2024): a partir de julho/2026, novas inscrições poderão conter letras e números. O formato muda assim:
| CNPJ atual | CNPJ alfanumérico | |
|---|---|---|
| Posições 1–12 (raiz + ordem) | Somente dígitos | Letras maiúsculas (A–Z) e dígitos |
| Posições 13–14 (dígitos verificadores) | Dígitos | Continuam somente dígitos |
| Máscara visual | 99.999.999/9999-99 |
SS.SSS.SSS/SSSS-99 (S = letra ou dígito) |
| CNPJs já existentes | — | Não mudam (não há recadastramento) |
O cálculo do dígito verificador continua sendo o módulo 11 com os mesmos pesos, porém cada caractere entra com o valor ASCII − 48: dígitos mantêm o valor de face ('0’→0 … '9’→9) e letras valem de 17 (‘A’) a 42 (‘Z’).
📌 Consequência importante: o algoritmo novo é retrocompatível — para um CNPJ 100% numérico, ele produz exatamente o mesmo DV de hoje. Um único validador atende os dois formatos.
Fontes oficiais (Receita Federal):
O card define dois cenários de aceite:
O campo CNPJ é gravado por 8 fluxos de cadastro, distribuídos entre os dois sistemas:
| Sistema | Cadastro | Tabela de destino |
|---|---|---|
| Admin (Gestão) | Pessoa Jurídica | admin.pessoa_juridica |
| Admin (Gestão) | Empresa | admin.empresa |
| Admin (Gestão) | Administração | admin.administracao |
| RH | Sindicato | rh.sindicato |
| RH | Cedência de servidor | rh.servidor_cedencia |
| RH | Experiência anterior do servidor | rh.servidor_experiencia_anterior |
| RH | Administração complementar | admin.administracao — grava via o mesmo AdministracaoBO do Admin |
| RH | Verba de consignação (consulta PJ) | usa FK para admin.pessoa_juridica |
São 11 telas (levantadas por grep pelas chaves mascara.cnpj / mascara.cnpj.opcional nos fontes dos dois sistemas). Nenhuma exige alteração individual: a máscara vem centralizada dos 2 arquivos properties (seção 2.1) e a validação/normalização acontece nos BOs (seções 2.2 e 2.3). A tela usada no teste de aceite do Cenário 1 é a de Pessoa Jurídica, mas a melhoria vale para todas.
Os caminhos abaixo são relativos à raiz webapp de cada sistema — Admin: governa-admin-all/governa-admin-web/src/main/webapp/; RH: governa-rh-all/governa-rh-web/src/main/webapp/.
Admin (Gestão) — 3 telas:
| Tela (caminho no webapp) | Natureza |
|---|---|
| usuario/pessoa/manterPessoaJuridica.xhtml | Cadastro/edição de Pessoa Jurídica + filtro de pesquisa (teste de aceite do Cenário 1) |
| super/empresa/manterEmpresa.xhtml | Cadastro/edição de Empresa |
| administrador/empresa/manterAdministracao.xhtml | Cadastro/edição de Administração |
RH — 8 telas:
| Tela (caminho no webapp) | Natureza |
|---|---|
| usuario/cadastro/sindicato/manterSindicato.xhtml | Cadastro/edição de Sindicato |
| usuario/servidor/lancarServidorCedencia.xhtml | Lançamento de cedência de servidor |
| usuario/servidor/manterServidorExperienciaAnterior.xhtml | Cadastro de experiência anterior |
| usuario/cadastro/estruturaOrganizacional/manterAdministracaoComplementar.xhtml | Edição de administração pelo RH (grava via AdministracaoBO do Admin) |
| usuario/movimentacaoMensal/controleBancario/manterVerbaConsignacao.xhtml | Filtro de consulta de PJ |
| resources/componentes/dialogConsultarPessoaJuridicaRh.xhtml | Componente de diálogo — filtro de consulta de PJ |
| todos/servico/incluirPessoaJuridicaRh.xhtml | Consulta/exibição de PJ no serviço RH (a manutenção redireciona para a tela do Admin) |
| usuario/movimentacaoAnual/rais.xhtml | Parâmetro «CNPJ contribuição sindical» na geração da RAIS (a exportação em si está fora do escopo — seção 7) |
Resumo: 7 telas gravam CNPJ (6 fluxos de cadastro + administração complementar), 3 são filtros/consulta e 1 é parâmetro de exportação.
O caminho do CNPJ passa por 3 camadas, e o alfanumérico esbarra nas três:
Todas as telas usam p:inputMask do PrimeFaces com o token 9, que aceita somente dígitos. As máscaras são centralizadas em 2 arquivos:
mascara.cnpj=99.999.999/9999-99
mascara.cnpj.opcional=?99.999.999/9999-99
📌 Hoje o usuário nem consegue digitar uma letra no campo — a máscara descarta a tecla. Como as máscaras são centralizadas, a correção em 2 arquivos propaga para as 11 telas listadas na seção 1.2.
A validação é feita por uma única classe, compartilhada pelos dois sistemas: Validacao.java:45, do módulo governa-admin-comum — os BOs do RH importam o jar do Admin. São 13 pontos de chamada (3 no Admin; 10 no RH, sendo 3 em cadastros e 7 nos BOs de visão do SEFIP).
public static boolean validarCNPJ(String cnpj) {
...
cnpj = cnpj.replace(".", "").replace("/", "").replace("-", "").trim();
if (cnpj.length() != 14) { return false; }
Integer digito1 = calcularDigito(cnpj.substring(0, 12), pesoCNPJ); // <- sem try/catch
...
}
private static int calcularDigito(String str, int[] peso) {
...
digito = Integer.parseInt(str.substring(indice, indice + 1)); // <- letra = NumberFormatException
...
}
📌 Com uma letra no CNPJ, o
Integer.parseIntlançaNumberFormatException. Diferente dovalidarCPF(que tem try/catch), ovalidarCNPJnão trata a exceção: em vez de «CNPJ inválido», o usuário receberia um erro de sistema.
Antes de salvar, cada fluxo limpa o valor digitado. Há dois métodos diferentes em uso:
| Fluxo | Limpeza no save | Efeito com letra |
|---|---|---|
| Pessoa Jurídica — PessoaJuridicaMB.java:113 | replace de . / - |
OK — preserva letras |
| Empresa — EmpresaBO.java:80 | replace de . / - |
OK — preserva letras |
| Administração — AdministracaoBO.java:63 (também usado pela Administração complementar do RH) | StringUtil.apenasNumeros |
⚠ apaga as letras |
| Sindicato — SindicatoBO.java:83 | StringUtil.apenasNumeros |
⚠ apaga as letras |
| Experiência anterior — ServidorExperienciaAnteriorBO.java:105 | StringUtil.apenasNumeros |
⚠ apaga as letras |
Cedência — ServidorCedenciaBO |
nenhuma (grava com máscara) | OK — preserva letras |
O StringUtil.apenasNumeros é um replaceAll("\\D", "") — remove tudo que não é dígito, inclusive letras:
public static String apenasNumeros(String string) {
...
return string.replaceAll("\\D", ""); // "12ABC34501DE35" viraria "123450135"
}
📌 Este é o risco mais grave do estudo: a validação roda antes dessa limpeza. Se apenas a máscara e o validador fossem corrigidos, um CNPJ alfanumérico passaria na validação e seria gravado corrompido, sem nenhum erro — corrupção silenciosa de dado. A correção deste ponto é obrigatória.
Pedido: o campo CNPJ deve aceitar letras e números (Cenário 1), sem alterar os registros existentes (Cenário 2), tanto em Gestão quanto em Recursos/Folha.
Premissas verificadas antes de propor a implementação:
As três premissas foram levadas ao banco de produção e ao rastreamento changeset a changeset do Liquibase dos dois sistemas.
Todas as consultas são somente leitura e foram executadas em produção em 14/07/2026. O script completo está em verificacao-banco-cnpj.sql.
Varredura do catálogo (INFORMATION_SCHEMA.COLUMNS) por todas as colunas %cnpj% do banco:
SELECT TABLE_SCHEMA, TABLE_NAME, COLUMN_NAME, DATA_TYPE, CHARACTER_MAXIMUM_LENGTH, IS_NULLABLE
FROM INFORMATION_SCHEMA.COLUMNS
WHERE COLUMN_NAME LIKE '%cnpj%'
ORDER BY TABLE_SCHEMA, TABLE_NAME, COLUMN_NAME;
Resultado: 20 colunas, todas varchar — nenhuma numérica em nenhum schema (incluindo views SEFIP/TCE/pensão judicial, Portal de Serviços e tabelas de integração). Também não foi encontrado nenhum CONVERT/CAST de CNPJ para tipo numérico em queries, procedures ou views dos dois sistemas.
Nota:
rh.tce_pessoal_view.pesCnpjVinculoExternoaparece na varredura comovarchar(1)— apesar do nome, é um campo indicador (S/N), não um CNPJ armazenado.
| Schema.tabela (principais) | Coluna | Tipo |
|---|---|---|
admin.pessoa_juridica |
cnpj | varchar(18) |
admin.empresa |
cnpj | varchar(14) |
admin.administracao |
cnpj | varchar(14) |
rh.sindicato |
cnpj | varchar(14) |
rh.servidor_cedencia |
cnpj | varchar(18) |
rh.servidor_experiencia_anterior |
cnpj_empresa | varchar(14) |
📌 Conclusão da prova: no nível de armazenamento, o banco inteiro já comporta CNPJ alfanumérico. Não há alteração de schema nem migração de dados.
Distribuição de tamanho e presença de pontuação, por tabela:
SELECT LEN(cnpj) AS tamanho, COUNT(*) AS qtd,
SUM(CASE WHEN cnpj LIKE '%[./-]%' THEN 1 ELSE 0 END) AS com_mascara
FROM rh.servidor_cedencia WHERE cnpj IS NOT NULL GROUP BY LEN(cnpj);
-- (repetida para cada tabela — ver script completo)
| Tabela | Registros | Formato confirmado |
|---|---|---|
admin.empresa |
1 | 14 dígitos, sem máscara |
admin.administracao |
25 | 14 dígitos, sem máscara |
admin.pessoa_juridica |
~1.376 | predominantemente 14 dígitos sem máscara |
rh.sindicato |
27 | 14 dígitos, sem máscara |
rh.servidor_experiencia_anterior |
27.785 | 14 dígitos, sem máscara |
rh.servidor_cedencia |
1.995 | 100% COM máscara 99.999.999/9999-99 (18 caracteres) |
Amostra de rh.servidor_cedencia confirmando o formato com máscara:
| id | cnpj | tamanho |
|---|---|---|
| 2 | 04.092.672/0001-25 | 18 |
| 4 | 04.632.212/0001-42 | 18 |
| 6 | 05.888.813/0001-83 | 18 |
📌 O formato não é uniforme entre as tabelas: a cedência grava com máscara porque o seu fluxo é o único que não remove a pontuação antes de salvar. Isso não é um problema para o card — mas define uma decisão de projeto (seção 6).
| Camada | Situação hoje | Impacto do alfanumérico |
|---|---|---|
| Banco (schema) | 20 colunas, todas varchar | ✅ Nenhum — letras cabem em todas |
| Banco (dados existentes) | Registros numéricos | ✅ Nenhum — não mudam (Cenário 2 por construção) |
| Formatação de exibição | formatarCNPJ, CNPJformatado() etc. usam substring por posição fixa |
✅ Nenhuma alteração — funcionam com letras |
| Filtros de pesquisa | replace de pontuação + upper() na query |
✅ Compatível (atenção só à caixa alta) |
| Máscara das telas | Token 9 (só dígito) |
❌ Bloqueia a digitação de letras |
| Validador de DV | Integer.parseInt por caractere, sem try/catch |
❌ Exceção de sistema em vez de mensagem |
| Normalização no save | apenasNumeros em 3 fluxos |
❌ Corrupção silenciosa do dado |
Conclusão da análise: todo o impacto está concentrado na camada de aplicação, em pontos poucos e centralizados. O Cenário 2 (compatibilidade) é atendido por construção: os dados não mudam, os formatadores são posicionais e o algoritmo novo de DV valida os CNPJs numéricos existentes com o mesmo resultado de hoje.
Todo o ajuste fica na camada de aplicação — nada muda no banco. São três frentes:
| Frente | Onde | Direção |
|---|---|---|
| 1. Validador compartilhado | 1 classe do módulo comum, usada pelos 2 sistemas | Passar a aceitar letras nas 12 primeiras posições e calcular o DV pela regra oficial da RFB — retrocompatível: os CNPJs numéricos continuam validando exatamente como hoje. Entrada inesperada vira mensagem de campo inválido, não erro de sistema |
| 2. Máscaras das telas | 2 arquivos properties centralizados | Permitir letra ou dígito nas 12 primeiras posições (DVs continuam numéricos); propaga automaticamente para as 11 telas da seção 1.2 |
| 3. Normalização no save | 1 método único, reutilizado pelos fluxos de gravação | Padronizar a limpeza do campo preservando letras — elimina o risco de corrupção silenciosa nos 3 fluxos que hoje as apagariam |
Como o RH importa o jar comum do Admin, a frente 1 corrige os 13 pontos de validação dos dois sistemas de uma vez — a publicação do jar deve acompanhar um deploy coordenado dos dois.
| Decisão | Definição |
|---|---|
rh.servidor_cedencia (grava com máscara) |
Manter o formato atual — apenas a máscara da tela passa a aceitar letras. Sem migração dos 1.995 registros; o validador tolera os dois formatos. |
| Mensagem de validação | Manter a mensagem genérica atual de campo inválido |
| Exportações posicionais | Fora do escopo deste card (ver seção 7) |
O RH gera arquivos de layout posicional para órgãos externos, nos quais o CNPJ é declarado como campo numérico de 14 posições: SEFIP (CAIXA), DIRF e MANAD (Receita Federal), RAIS (Min. do Trabalho), arquivos bancários (consignação/pensão) e eSocial.
Esses layouts pertencem aos órgãos e só mudam quando cada um publicar a versão com suporte ao CNPJ alfanumérico — não há especificação para o sistema se antecipar. O risco imediato é baixo: os CNPJs desses arquivos são majoritariamente dos entes públicos, que permanecem numéricos.
📌 Tratar por demanda, criando card específico quando cada órgão publicar seu novo layout.
Conclusão: O banco inteiro já comporta o CNPJ alfanumérico (todas as colunas são texto, confirmado em produção), e a exibição dos registros existentes não é afetada.
Recomendação: implementar as quatro frentes da seção 6 — validador retrocompatível, máscaras alfanuméricas, normalização única e testes de regressão — antes de 31/07/2026 (primeira inscrição alfanumérica na Receita). Sem migração de dados, sem alteração de schema e sem downtime.