CNPJ Alfanumérico
- PROC001 - Núcleo de validação e formatação de CNPJ
- 1. Cadastros
- PROC002 - Cadastro de Nova Empresa
- PROC003 - Cadastro de Cliente e Fornecedor
- PROC004 - Cadastro de Vendedor
- 2. Fiscal - NFe
- PROC005 - Ajustes Chave de Acesso Alfanumérica NF-e e NFC-e
- PROC005.1 - Ajustes em Preenchimentos em Tela
- PROC005.2 - Alterações em XML
- PROC005.3 - Ajustes Jasper
- 3. Fiscal - CTe
PROC001 - Núcleo de validação e formatação de CNPJ
| Projeto/Sistema: GERENCIEAQUI - MIGRAÇÃO CNPJ ALFANUMERICO (NT 2026.004) |
Versão do Template: 1.2 |
| Processo: PROC001 - Núcleo de validação e formatação de CNPJ |
Versão do Documento: 1.0 |
| Responsável(eis): Luís Leite |
Data: 05/01/2026 |
1. Introdução
Este processo descreve a adaptação dos utilitários centrais de CNPJ do projeto GerencieAqui para suportar o CNPJ Alfanumérico previsto pela NT 2026.004 (Instrução Normativa RFB nº 2.229/2024), com entrada em produção em 01/07/2026.
O CNPJ Alfanumérico mantém 14 caracteres, sendo as 12 primeiras posições alfanuméricas (letras maiúsculas A–Z e dígitos 0–9) e os 2 últimos dígitos verificadores numéricos. A máscara de exibição XX.XXX.XXX/XXXX-XX permanece inalterada. O cálculo dos DV usa o valor de cada caractere por ASCII menos 48 (módulo 11), o que já é implementado pelo ModValidador atual.
Esta especificação é a FUNDAÇÃO de toda a migração todas as demais frentes (NF-e, NFC-e, CT-e, MDF-e, NFS-e, DCE, integrações, banco e front-end) reutilizam estes utilitários. A correção do núcleo deve ser a primeira entrega da iniciativa.
2. Processo
|
Processo |
Envolvidos |
Dados de Entrada |
Dados de Saída |
|
PROC001 - Núcleo de validação e formatação de CNPJ |
- |
- |
- |
Processos Relacionados
Especificação Funcional
PROC001 - Núcleo de validação e formatação de CNPJ:
Descrição dos Campos:
|
Campo |
Tipo |
Tamanho |
Obrig. ? |
Máscara |
Observações |
|
CNPJ (entrada) |
Texto |
14 ou 18 |
- |
99.999.999/9999-99 (legado) ou *9.***.***/****-99 (alfanumérico) |
As 12 primeiras posições alfanuméricas A–Z e 0–9; as 2 últimas posições numéricas (DV). |
|
CNPJ (armazenado) |
Texto |
14 |
Sim |
- |
Sempre em maiúsculas, sem pontuação. Coluna varchar(14) a varchar(20) já existente. |
|
CNPJ (exibido) |
Texto |
18 |
N/A |
XX.XXX.XXX/XXXX-XX |
- |
|
Dígitos Verificadores |
Numérico |
2 |
Sim |
99 |
Calculado por módulo 11 com pesos 5,4,3,2,9,8,7,6,5,4,3,2 sobre (char-48). |
Regras de Negócio:
1. Algoritmo de validação dos DV (mantido): O cálculo permanece módulo 11 sobre os 12 primeiros caracteres, utilizando o valor (char-48) de cada posição: '0'→0 … '9'→9, 'A'→17 … 'Z'→42. ModValidador.java já realiza esta operação corretamente (linhas 179, 192).
2. Limpeza preservando letras: CnpjUtil.clean (linha ~35) deve substituir replaceAll("\D", "") por replaceAll("[^A-Za-z0-9]", "") e em seguida toUpperCase(). Isto preserva as letras do CNPJ alfanumérico e elimina a corrupção silenciosa do dado.
3. Padrão de validação simples: CnpjUtil.isValidSimple (linha 31) deve trocar matches("\d{14}") por matches("[A-Z0-9]{12}[0-9]{2}") sobre o valor limpo, e contemplar variação com máscara: matches("[A-Z0-9]{2}\.[A-Z0-9]{3}\.[A-Z0-9]{3}/[A-Z0-9]{4}-[0-9]{2}").
4. Formatação: CnpjUtil.format (linhas ~38–47) deve usar replaceFirst("(.{2})(.{3})(.{3})(.{4})(.{2})", "$1.$2.$3/$4-$5") em vez de grupos \d, suportando qualquer caractere.
5. Consolidação do util legado @Deprecated: O CnpjUtil legado em util/CnpjUtil.java (com isCNPJValido / isCNPJ / imprimeCNPJ via charAt-48 e substring) é tecnicamente compatível com alfanumérico mas mantém duplicidade.
6. Caracteres repetidos: A verificação matches("^(\d)\1*$") em CnpjUtil.java (linha 16) já não casa com alfanumérico sem quebra. Avaliar estender para detectar também sequências repetidas de letras (ex.: AAAAAAAAAAAA00).
7. Desambiguação CPF × CNPJ em CpfOrCnpjUtil: A distinção continua por comprimento (11 vs 14) sobre o valor limpo. Toda lógica que dependa de "ser numérico" para classificar precisa ser revista, um valor de 14 caracteres com letras é necessariamente CNPJ.
Questões Técnicas:
1. Alterações:
|
Arquivo : linha |
Risco |
Descrição / Ação |
|
util/datatypes/CnpjUtil.java : ~31 |
Crítico |
isValidSimple — trocar matches("\d{14}") por padrão alfanumérico. |
|
util/datatypes/CnpjUtil.java : ~35 |
Crítico |
clean — substituir replaceAll("\D","") por replaceAll("[^A-Za-z0-9]","") + toUpperCase(). |
|
util/datatypes/CnpjUtil.java : ~38–47 |
Alto |
format — usar regex genérica (.{2})(.{3})(.{3})(.{4})(.{2}). |
|
validadores/ModValidador.java : ~179, 192 |
Sem ação |
charAt(i) - '0' já é o algoritmo oficial alfanumérico. |
|
util/datatypes/CpfOrCnpjUtil.java : ~8–42 |
Alto |
Delega a CnpjUtil — herda correções. |
|
util/CnpjUtil.java (legado @Deprecated) |
Baixo |
Tolerante a alfanumérico. Consolidar no util moderno. |
|
util/ValidaCNPJ.java |
Alto |
Reescrever detecção CPF×CNPJ; aceitar alfanumérico 14 sem máscara e 18 com máscara. |
|
test/.../CnpjUtilTest.java |
Alto |
Adicionar casos alfanuméricos válidos e inválidos. |
2. Mudança na base de dados: Nenhuma alteração de schema. Todas as colunas de CNPJ já comportam 14 caracteres alfanuméricos (varchar(14)–varchar(20)).
©SOFTEN SISTEMAS 2026
1. Cadastros
PROC002 - Cadastro de Nova Empresa
| Projeto/Sistema: GERENCIEAQUI - MIGRAÇÃO CNPJ ALFANUMÉRICO (NT 2026.004) |
Versão do Template: 1.2 |
| Processo: PROC002 - Cadastro de Nova Empresa |
Versão do Documento: 1.0 |
| Responsável(eis): Luís Leite |
Data: 25/05/2026 |
1. Introdução
Este processo descreve a adaptação do fluxo de cadastro inicial e do cadastro adicional de empresa pelo usuário logado ao CNPJ Alfanumérico (NT 2026.004).
2. Processo
|
Processo |
Envolvidos |
Dados de Entrada |
Dados de Saída |
|
PROC002 - Cadastro de Nova Empresa |
Usuário |
CNPJ Alfanumérico |
CNPJ Alfanumérico validado e cadastrado em banco. |
Processos Relacionados
PROC001 — Núcleo de validação e formatação de CNP
Especificação Funcional
PROC002 - Cadastro de Nova Empresa:
Protótipo de Tela:
Descrição dos Campos:
|
Campo |
Tipo |
Tamanho |
Obrig. ? |
Máscara |
Observações |
|
CNPJ* |
Texto |
14 |
Sim |
- |
- |
Regras de Interface:
1.Ajuste de validação: Conferir validação do campo para aceitar alfanumérico. Reaproveitar validações do PROC001 - Núcleo de validação de formatação de CNPJ
2. Normalização: Deve ser tratado para deixar todas as letras em caixa maior (maiúsculo) visando a padronização da informação.
Regras de Negócio:
1. Validação tripla mantida: O fluxo atual valida o CNPJ em três pontos (ajax onChange, novaEmpresa, EmpresaService.salvarNovaEmpresa) via CnpjUtil.isCnpjValidoSalvar. Como o util legado já usa charAt-48 e substring (tolerantes a alfanumérico), a validação funciona após a correção do PROC001.
2. Unicidade global do CNPJ: isDBContainCnpj (CnpjUtil:400) verifica via EmpresaDao.existsByCnpj se já há empresa cadastrada com o mesmo CNPJ. Bloqueia o cadastro com mensagem "Já existe uma empresa com esse CNPJ!". A collation default do MariaDB é case-insensitive — a normalização para maiúsculas elimina ambiguidades em comparações externas.
3. Token A3 sensível à caixa: Empresa.gerarTokenA3 (Empresa.java:736) faz gerarHash(cnpj + email, "SHA-256"). Como SHA-256 é sensível a caixa, o CNPJ DEVE ser gravado em maiúsculas — caso contrário, "ABC..." e "abc..." gerariam tokens diferentes e quebrariam a integração com certificado A3.
Regras de Interface:
1. Mudança na base de dados: Sem alteração. Coluna 'empresa'.'cnpj' é varchar(20).
©SOFTEN SISTEMAS 2026
PROC003 - Cadastro de Cliente e Fornecedor
| Projeto/Sistema: GERENCIAMENTO DE PROJETOS |
Versão do Template: 1.2 |
| Processo: Descrição Processo |
Versão do Documento: 1.0 |
| Responsável(eis): - |
Data: 05/01/2026 |
1. Introdução
Este processo descreve a adaptação dos cadastros de Cliente e Fornecedor ao CNPJ Alfanumérico (NT 2026.004). Inclui o cadastro principal (tela de edição com aba de informações), o diálogo de cadastro rápido (dialogNovoCliente) e a listagem com filtro de busca. O fornecedor é representado pela mesma entidade Cliente.
2. Processo
|
Processo |
Envolvidos |
Dados de Entrada |
Dados de Saída |
|
PROC003 - Cadastro de Cliente e Fornecedor |
Usuario |
CPF (11 dígitos) ou CNPJ alfanumérico (14 caracteres) — com ou sem máscara |
Cliente/Fornecedor persistido com CPF/CNPJ normalizado em maiúsculas; listagem com filtro alfanumérico |
|
PROC003.1 - Listagem de Clientes e Fornecedores |
|
Query de Consulta |
Retorno em Listagem em Tela |
Processos Relacionados
PROC001 — Núcleo de validação e formatação de CNPJ
Especificação Funcional
PROC003 - Cadastro de Cliente e Fornecedor:
Protótipo de Tela:
Descrição dos Campos:
|
Campo |
Tipo |
Tamanho |
Obrig. ? |
Máscara |
Observações |
|
CPF/CNPJ |
Texto |
11-14 |
Sim |
- |
11 dígitos = CPF (numérico); 14 caracteres = CNPJ (alfanumérico). |
Regras de Interface:
1. Ajuste de validação: Deve ser alterada a validação de campo para permitir informar alfanumérico. Reaproveita util/ValidaCNPJ.java (corrigido em PROC001).
2. Caracteres especiais bloqueados: Deve ser mantida validação para caracteres especiais como acentos, til e outras pontuações não esperadas. Apenas A–Z, 0–9 e os separadores . / - (estes apenas na máscara, removidos na gravação).
3. Normalização para maiúsculas: Tratar para que as letras sejam salvas em caixa maior (maiúsculo), normalizando a informação no banco e garantindo coerência em comparações case-sensitive.
Regras de Negócio:
1. Consulta API: A requisição à API de consulta de CNPJ deve ser feita enviando o CNPJ como campo alfanumérico, preservando letras na URL/payload.
2. Detecção CPF × CNPJ por comprimento: Continua por length() sobre o valor limpo: 11 = CPF (numérico); 14 = CNPJ (alfanumérico ou numérico).
3. Verificação de duplicidade: A normalização para maiúsculas garante que CNPJ alfanumérico digitado em caixa diferente não seja considerado duplicado.
PROC003.1 - Listagem de Clientes e Fornecedores:
|
Campo |
Tipo |
Tamanho |
Obrig. ? |
Máscara |
Observações |
|
Busca |
Texto |
- |
- |
- |
- |
Regras de Interface:
1. O campo de Busca deve ser alterado para realizar a consulta de CNPJ alfanumérico. Validar 3 caracteres ou mais para a busca.
Questões Técnicas:
1. Banco de dados: O campo 'empresa'.'cnpj' no banco de dados já é definido como VARCHAR(20), não necessitando mudanças.
2. Query de busca: O campo usa LIKE compatível com texto alfanumérico. Normalizar o termo de busca para maiúsculas antes de aplicar.
©SOFTEN SISTEMAS 2026
PROC004 - Cadastro de Vendedor
| Projeto/Sistema: GERENCIEAQUI - MIGRAÇÃO CNPJ ALFANUMÉRICO (NT 2026.004) |
Versão do Template: 1.2 |
| Processo: PROC004 - Cadastro de Vendedor |
Versão do Documento: 1.0 |
| Responsável(eis): Luís Leite |
Data: 26/05/2026 |
1. Introdução
Este processo descreve a adaptação do cadastro de Vendedor ao CNPJ Alfanumérico (NT 2026.004). Cobre o cadastro principal, o cadastro rápido e a listagem com filtro de busca.
2. Processo
|
Processo |
Envolvidos |
Dados de Entrada |
Dados de Saída |
|
PROC004 - Cadastro de Vendedor |
Usuário |
CPF (11 dígitos) ou CNPJ alfanumérico (14 caracteres), com ou sem máscara. |
Vendedor cadastrado em banco com CPF/CNPJ normalizado em maiúsculas. |
|
PROC004.1 - Listagem de Vendedor |
|
Query de Consulta |
Retorno em Listagem em Tela |
Processos Relacionados
PROC001 — Núcleo de validação e formatação de CNPJ
Especificação Funcional
PROC004 - Cadastro de Vendedor
Protótipo de Tela:
Descrição dos Campos:
|
Campo |
Tipo |
Tamanho |
Obrig. ? |
Máscara |
Observações |
|
CPF / CNPJ * |
Texto |
20 |
Sim |
- |
- |
Regras de Interface:
1. Ajuste de validação: Deve ser alterada a validação de campo para permitir informar alfanumérico. Reaproveita util/ValidaCNPJ.java (corrigido em PROC001).
2. Caracteres especiais bloqueados: Deve ser mantida validação para caracteres especiais como acentos, til e outras pontuações não esperadas.
3. Normalização para maiúsculas: Tratar para que as letras sejam salvas em caixa maior (maiúsculo), normalizando a informação no banco.
PROC004.1 - Listagem de Vendedor
Protótipo de Tela:
|
Campo |
Tipo |
Tamanho |
Obrig. ? |
Máscara |
Observações |
|
Busca |
Texto |
- |
- |
- |
- |
Regras de Interface:
1. O campo de Busca deve ser alterado para realizar a consulta de CNPJ alfanumérico. Validar 3 caracteres ou mais para a busca.
Questões Técnicas:
1. O campo 'vendedor'.'cnpj' no banco de dados já é definido como VARCHAR(20), não necessitando mudanças.
2. Query de Busca: Usa LIKE compatível com alfanumérico. Normalizar para maiúsculas para a consulta.
©SOFTEN SISTEMAS 2026
2. Fiscal - NFe
PROC005 - Ajustes Chave de Acesso Alfanumérica NF-e e NFC-e
| Projeto/Sistema: GERENCIAMENTO DE PROJETOS |
Versão do Template: 1.2 |
| Processo: Descrição Processo |
Versão do Documento: 1.0 |
| Responsável(eis): - |
Data: 05/01/2026 |
1. Introdução
Este processo visa exemplificar a documentação padrão
2. Processo (adicionar fluxograma exemplo)
I - Fluxograma Exemplo
|
Processo |
Envolvidos |
Dados de Entrada |
Dados de Saída |
|
Processo |
N/A |
N/A |
N/A |
Processos Relacionados
Documentação Exemplo 1
Documentação Exemplo 2
Especificação Funcional
PROC005 - Ajustes Chave de Acesso Alfanumérica NF-e e NFC-e:
Regras de Negócio:
1. Estrutura da chave de acesso (44 caracteres): A chave é composta por 9 blocos concatenados: UF(2) + AAMM(4) + CNPJ emitente(14) + modelo(2) + série(3) + número da nota(9) + tipo de emissão(1) + código numérico aleatório(8) + DV(1). Apenas o bloco do CNPJ pode conter letra, os demais blocos permanecem numéricos.
1.1 Exemplo de chave NUMÉRICA legada (referência): Para CNPJ numérico 12.345.678/0001-95 emitindo NF-e em SP (UF=35) em julho/2026, modelo 55, série 1, nota 123, tipo emissão normal (1), código 12345678 — a chave fica: 35 2607 12345678000195 55 001 000000123 1 12345678 + DV. Resultado: 35260712345678000195550010000001231123456786 (DV=6 calculado).
1.2. Exemplo de chave ALFANUMÉRICA nova: Para o mesmo cenário mas com CNPJ alfanumérico oficial 12.ABC.345/01DE-35 (publicado pela RFB como exemplo), a chave fica: 35 2607 12ABC34501DE35 55 001 000000123 1 12345678 + DV. Resultado: 35260712ABC34501DE3555001000000123112345678 + DV. O DV é calculado pelo mesmo algoritmo, agora considerando os valores ASCII das letras.
2. DV da chave gerado localmente (não pela lib): O dígito verificador da chave de acesso (44º caractere) é calculado pelo próprio projeto antes de enviar para a SEFAZ. A biblioteca de comunicação fiscal apenas recebe a chave já pronta. O algoritmo de cálculo (módulo 11 sobre os 43 caracteres anteriores, usando ASCII menos 48 para cada caractere) já é compatível com o formato alfanumérico.
2.1 Calculo: Serão utilizados, no cálculo do módulo 11, os valores relativos a letras maiúsculas da tabela código ASCII, como solução para unificar a representação de caracteres alfanuméricos.
2.2 Na rotina de cálculo do Dígito Verificador (DV) no CNPJ, serão substituídos os valores numéricos e alfanuméricos pelo valor decimal correspondente ao código constante na tabela ASCII e dele subtraído o valor 48. Desta forma os caracteres numéricos continuarão com os mesmos montantes, e os caracteres alfanuméricos terão os seguintes valores: A=17, B=18, C=19… e assim sucessivamente.
| Caractere | ASCII | Valor no cálculo |
|---|---|---|
'0' a '9' |
48–57 | 0 a 9 |
'A' |
65 | 17 |
'B' |
66 | 18 |
'C' |
67 | 19 |
'D' |
68 | 20 |
'E' |
69 | 21 |
'F' |
70 | 22 |
'G' |
71 | 23 |
'H' |
72 | 24 |
'I' |
73 | 25 |
'J' |
74 | 26 |
'K' |
75 | 27 |
'L' |
76 | 28 |
'M' |
77 | 29 |
'N' |
78 | 30 |
'O' |
79 | 31 |
'P' |
80 | 32 |
'Q' |
81 | 33 |
'R' |
82 | 34 |
'S' |
83 | 35 |
'T' |
84 | 36 |
'U' |
85 | 37 |
'V' |
86 | 38 |
'W' |
87 | 39 |
'X' |
88 | 40 |
'Y' |
89 | 41 |
'Z' |
90 | 42 |
1.3 O calculo do DV chave de acesso deverá ser feito considerando o valor ASCII das letras do CNPJ contidos na chave, ATUALMENTE O SISTEMA JÁ APLICARIA ESSE ALGORITMO.
Exemplo de chave:
| CHAVE ALFANUMÉRICA: 35260712ABC34501DE3555001000000123112345678 | |||
|---|---|---|---|
| Bloco | Tam | Valor | Significado |
| cUF | 2 | 35 |
São Paulo |
| AAMM | 4 | 2607 |
Julho/2026 |
| CNPJ emitente | 14 | 12ABC34501DE35 |
CNPJ alfanumérico (sem pontuação, em maiúsculas) |
| mod | 2 | 55 |
NF-e |
| série | 3 | 001 |
Série 1 (preenchida com zeros à esquerda) |
| nNF | 9 | 000000123 |
Nota nº 123 (zeros à esquerda) |
| tpEmis | 1 | 1 |
Emissão normal |
| cNF | 8 | 12345678 |
Código numérico aleatório da nota |
1.3.1 Aplicado pesos cíclicos 2,3,4,5,6,7,8,9,2,3,4,5,6,7,8,9... da direita para a esquerda.
1.3.2 Soma dos produtos (por blocos para conferência):
-
-
-
-
- Posições 1–8 (cUF + AAMM + parte do CNPJ):
12+15+4+54+0+49+6+10= 150 - Posições 9–16 (CNPJ — bloco com
A B C):68+54+38+27+32+35+0+5= 259 - Posições 17–24 (CNPJ
D E+ mod + série + início nNF):80+63+6+45+40+35+0+0= 269 - Posições 25–32 (nNF):
4+0+0+0+0+0+0+5= 9 - Posições 33–40 (tpEmis + parte do cNF):
8+9+2+9+16+21+24+25= 114 - Posições 41–43 (final do cNF):
24+21+16= 61 - Total = 862
- Aplicado módulo 11 = 862 / 11 = 78 (resto 4, porque 78 x 11 = 858 e 862 - 858 = 4).
- Resto = 4
- Como o resto foi acima de 1, DV = 11-4=7.
- Posições 1–8 (cUF + AAMM + parte do CNPJ):
-
-
-
2. Composição da chave preservando letras: Hoje a composição da chave aplica uma rotina que apaga letras do CNPJ antes de concatená-lo. Essa rotina precisa ser substituída por uma que preserve A-Z e 0-9, removendo apenas pontuação. Após a correção, o CNPJ alfanumérico entra na chave inteira e o DV sai correto automaticamente.
Questões Técnicas:
1. A coluna 'nfe'.'chaveAcesso' esta como VARCHAR(255), não sendo necessário ajuste em banco.
2. Arquivos a alterar da composição da chave - Pontos críticos da montagem da chave:
|
Arquivo : linha |
Risco |
Descrição / Ação |
|
adapters/xml/nfe/EnvioNfeAdapter.java : 29 |
Crítico |
CpfOrCnpjUtil.clean(empresa.getCnpj()) — herda correção de PROC001 (clean preserva letras). |
|
adapters/xml/nfe/EnvioNfeAdapter.java : 46 |
Sem ação |
ModValidador.of(11, value, value.length(), 4).calc() — algoritmo já compatível. |
|
adapters/xml/nfce/EnvioNfceAdapter.java : 36, 53 |
Crítico/Sem ação |
Mesma estrutura do NFe — herda PROC001. |
|
util/NFCeUtil.java : 145, 151 |
Crítico |
lpadTo(cnpjCpf.replaceAll("\D",""), 14, '0') — substituir limpeza por uma que preserve letras. |
|
adapters/xml/nfe/NfeAdapter.java : 67 |
Sem ação |
Apenas extrai o DV via chaveAcesso.substring(chaveAcesso.length() - 1) — agnóstico. |
|
validadores/ModValidador.java : 179, 192 |
Sem ação |
char - '0' é o algoritmo oficial alfanumérico. |
©SOFTEN SISTEMAS 2026
PROC005.1 - Ajustes em Preenchimentos em Tela
| Projeto/Sistema: GERENCIAMENTO DE PROJETOS |
Versão do Template: 1.2 |
| Processo: PROC005.1 - Ajustes em Preenchimentos em Tela |
Versão do Documento: 1.0 |
| Responsável(eis): Luís Leite |
Data: 27/05/2026 |
1. Introdução
Este processo visa exemplificar a documentação padrão
2. Processo
|
Processo |
Envolvidos |
Dados de Entrada |
Dados de Saída |
|
PROC005.1.1 - NFE - Ajustes em Preenchimentos em Tela - Referenciar Documento |
|
|
|
|
PROC005.1.2 - NFE - Ajustes em Preenchimentos em Tela - Imposto por Produto
|
|
|
|
Processos Relacionados
Documentação Exemplo 1
Documentação Exemplo 2
Especificação Funcional
PROC005.1.1 - NFE - Ajustes em Preenchimentos em Tela - Referenciar Documento:
Tela:
Imagem I - Chave NFe Referenciada.
Imagem II - Chave NFe Referenciada de antecipação de pagamento.
Imagem III - NF-e de Produtor Rural.
Descrição dos Campos:
|
Campo |
Tipo |
Tamanho |
Obrig. ? |
Máscara |
Observações |
|
Chave Nota (Ref NF-e) |
Texto |
44 |
- |
- |
- |
|
CNPJ/CPF Emitente* |
Texto |
14 |
Sim |
- |
- |
Regras de Interface:
1. Chave Nota (Ref NF-e): Deve ser alterado para permitir o uso de alfanumérico. Atualmente existe tratamento para limpar a chave caso existam valores incorretos para a validação atual. Manter normalização para remoção de espaços e caracteres especiais. Normalizar para caixa alta as letras inseridas.
2. CNPJ/CPF Emitente*: Conferir validação do campo para aceitar alfanumérico. Reaproveitar validações do PROC001 - Núcleo de validação de formatação de CNPJ
2.1. Normalização: Deve ser tratado para deixar todas as letras em caixa alta(maiúsculo) visando a padronização da informação.
Regras de Negócio:
1. Chave Nota (Ref NF-e): A chave de acesso passa por validação de DV. Manter a validação de chave vazia e 44 digitos. O tratamento para caixa maior visa manter a validação do DV.
1.1. Mapeamento de valores para o cálculo (ASCII menos 48): Cada caractere da chave entra no cálculo do DV com seu valor ASCII menos 48: dígitos '0' a '9' valem 0 a 9 (como sempre); letras 'A' a 'Z' valem 17 a 42 ('A'=17, 'B'=18, 'C'=19, 'D'=20, 'E'=21, ..., 'Z'=42). O salto entre '9' (valor 9) e 'A' (valor 17) é por causa dos caracteres ASCII entre eles (':;<=>?@') que não são usados.
1.2. Cálculo do DV (algoritmo mantido): O DV é calculado por módulo 11 sobre os 43 caracteres anteriores, lendo da direita para a esquerda, multiplicando cada caractere por pesos cíclicos 2, 3, 4, 5, 6, 7, 8, 9, 2, 3, 4... Soma-se tudo, calcula o resto da divisão por 11. Se o resto for 0 ou 1, DV = 0; senão DV = 11 - resto. O resultado é sempre um dígito de 0 a 9, o DV NUNCA é letra.
1.3 O calculo do DV chave de acesso deverá ser feito considerando o valor ASCII das letras do CNPJ contidos na chave, ATUALMENTE O SISTEMA JÁ APLICARIA ESSE ALGORITMO.
Exemplo de chave:
| CHAVE ALFANUMÉRICA: 35260712ABC34501DE3555001000000123112345678 | |||
|---|---|---|---|
| Bloco | Tam | Valor | Significado |
| cUF | 2 | 35 |
São Paulo |
| AAMM | 4 | 2607 |
Julho/2026 |
| CNPJ emitente | 14 | 12ABC34501DE35 |
CNPJ alfanumérico (sem pontuação, em maiúsculas) |
| mod | 2 | 55 |
NF-e |
| série | 3 | 001 |
Série 1 (preenchida com zeros à esquerda) |
| nNF | 9 | 000000123 |
Nota nº 123 (zeros à esquerda) |
| tpEmis | 1 | 1 |
Emissão normal |
| cNF | 8 | 12345678 |
Código numérico aleatório da nota |
1.3.1 Aplicado pesos cíclicos 2,3,4,5,6,7,8,9,2,3,4,5,6,7,8,9... da direita para a esquerda.
1.3.2 Soma dos produtos (por blocos para conferência):
-
-
-
-
-
-
- Posições 1–8 (cUF + AAMM + parte do CNPJ):
12+15+4+54+0+49+6+10= 150 - Posições 9–16 (CNPJ — bloco com
A B C):68+54+38+27+32+35+0+5= 259 - Posições 17–24 (CNPJ
D E+ mod + série + início nNF):80+63+6+45+40+35+0+0= 269 - Posições 25–32 (nNF):
4+0+0+0+0+0+0+5= 9 - Posições 33–40 (tpEmis + parte do cNF):
8+9+2+9+16+21+24+25= 114 - Posições 41–43 (final do cNF):
24+21+16= 61 - Total = 862
- Aplicado módulo 11 = 862 / 11 = 78 (resto 4, porque 78 x 11 = 858 e 862 - 858 = 4).
- Resto = 4
- Como o resto foi acima de 1, DV = 11-4=7.
- Posições 1–8 (cUF + AAMM + parte do CNPJ):
-
-
-
-
-
PROC005.1.2 - NFE - Ajustes em Preenchimentos em Tela - Imposto por Produto:
Tela:
Imagem I - CNPJ Encomendante da importação na Tela de Imposto Produto na Nota
Imagem II - Chave de Acesso de exportação na Tela de Imposto Produto na Nota
Imagem III - CNPJ Fabricante na aba 'Outros' na Nota Fiscal.
Imagem IV - CNPJ Fabricante na aba 'Outros' na Nota Fiscal.
Descrição dos Campos:
|
Campo |
Tipo |
Tamanho |
Obrig. ? |
Máscara |
Observações |
| Aba de Importação | |||||
|
CNPJ Encomendante |
Texto |
14 |
- |
- |
- |
| Aba de Exportação | |||||
|
Chave da NF-e |
Texto |
44 |
- |
- |
- |
| Aba Outros | |||||
|
CNPJ Fabricante |
Texto |
14 |
- |
- |
- |
|
DFe Referenciado |
Texto |
44 |
- |
- |
- |
Regras de Interface:
1. CNPJ Encomendante: O campo aceita alfanumérico. Validar o tamanho máximo e a normalização para caixa alta.
2. Chave da NF-e: Atualmente permite a inserção alfanumérica. Normalizar para remoção de espaços e caracteres especiais e transformar em caixa alta as letras inseridas.
3. CNPJ Fabricante: O campo aceita alfanumérico. Validar o tamanho máximo e a normalização para caixa alta.
4. DFe Referenciado: Deve ser alterado para permitir o uso de alfanumérico. Normalizar removendo espaços e caracteres especiais, manter as letras em caixa alta.
Regras de Negócio:
1. Não são feitas validações de DV.
Questões Técnicas:
1. O campo 'nfereferenciada'.'refNfe' esta como VARCHAR(255), não necessitando mudanças.
2. O campo 'nfeproduto'.'cnpjEncomendante' esta como VARCHAR(255), não necessitando mudanças.
3. O campo 'nfeproduto'.'chaveNfeExport' esta como VARCHAR(44), não necessitando mudanças.
4. O campo 'nfeprodutosinfo'.'CNPJFab' esta como VARCHAR(14), não necessitando mudanças.
5. O campo 'nfeproduto'.'chaveDfe' esta como VARCHAR(44), não necessitando mudanças.
©SOFTEN SISTEMAS 2026
PROC005.2 - Alterações em XML
| Projeto/Sistema: GERENCIAMENTO DE PROJETOS |
Versão do Template: 1.2 |
| Processo: PROC005.2 - Alterações em XML |
Versão do Documento: 1.0 |
| Responsável(eis): - |
Data: 05/01/2026 |
1. Introdução
Este processo visa exemplificar a documentação padrão
2. Processo
|
Processo |
Envolvidos |
Dados de Entrada |
Dados de Saída |
|
Processo |
N/A |
N/A |
N/A |
Processos Relacionados
Documentação Exemplo 1
Especificação Funcional
PROC005.2 - Alterações em XML:
Regras de Negócio:
1. A geração de XML é realizada pela LIB, basta passar os valores tratados em concordância com o alfanumérico.
2. Os retornos do governo de eventos e autorizações também irão retornar CNPJ alfanumérico.
3. O Schema XSD deve estar atualizado em conformidade com a ultima versão.
Questões Técnicas:
1. Grupo BA. Documento Fiscal Referenciado:
2. Grupo C. Identificação do Emitente da Nota Fiscal eletrônica:
3. Grupo E. Identificação do Destinatário da Nota Fiscal eletrônica
4. Grupo G. Identificação do Local de Retirada
5. Grupo G. Identificação do Local de Entrega
6. Grupo GA. Autorização para obter XML
7. Grupo I. Produtos e Serviços da NF-e
8. Grupo I01. Produtos e Serviços / Declaração de Importação
9. Grupo I03. Produtos e Serviços / Grupo de Exportação
10. Grupo O. Imposto sobre Produtos Industrializados
11. Grupo X. Informações do Transporte da NF-e
12.Grupo YA. Informações de Pagamento
13. Grupo YB. Informações do Intermediador da Transação
14. Grupo VC. Referenciamento de item de outro Documento Fiscal Eletrônico - DF-e
14. Grupo ZD. Informações do Responsável Técnico
©SOFTEN SISTEMAS 2026
PROC005.3 - Ajustes Jasper
| Projeto/Sistema: GERENCIAMENTO DE PROJETOS |
Versão do Template: 1.2 |
| Processo: Descrição Processo |
Versão do Documento: 1.0 |
| Responsável(eis): - |
Data: 05/01/2026 |
1. Introdução
Este processo descreve a adaptação dos relatórios Jasper (DANFE NF-e, DANFE NFC-e e Carta de Correção) ao CNPJ Alfanumérico previsto pela NT 2026.004. Com a entrada das letras nas 12 primeiras posições do CNPJ, a chave de acesso de 44 caracteres também pode conter letras (nas posições 7 a 20, faixa do CNPJ do emitente).
2. Processo
|
Processo |
Envolvidos |
Dados de Entrada |
Dados de Saída |
|
Processo |
N/A |
N/A |
N/A |
Processos Relacionados
Documentação Exemplo 1
Documentação Exemplo 2
Especificação Funcional
PROC005.3 - Ajustes Jasper:
Protótipo de Tela:
Descrição dos Campos:
|
Campo |
Tipo |
Tamanho |
Obrig. ? |
Máscara |
Observações |
|
Campo |
Texto |
100 |
Sim |
- |
- |
Regras de Interface:
1.Renderização visual mantida: O layout do DANFE NF-e, DANFE NFC-e e Carta de Correção permanece inalterado. As mudanças são internas ao template e ao subtipo do código de barras.
Regras de Negócio:
1. Subtipo do código de barras da chave: O código de barras Code 128 usado para representar a chave de acesso na DANFE NF-e e na Carta de Correção deve aceitar caracteres alfanuméricos. O subtipo atual (Code 128C, otimizado para apenas pares de dígitos) precisa ser substituído por Code 128B (que aceita letras A-Z, dígitos 0-9 e símbolos) ou Code 128 em modo automático (que escolhe o subtipo conforme o conteúdo).
2. Formatação visual do CNPJ e da chave: A formatação do CNPJ na máscara XX.XXX.XXX/XXXX-XX e da chave em blocos de 4 caracteres é feita por substring. Funciona corretamente com letras sem nenhum ajuste.
3. Determinação do rótulo CPF × CNPJ no destinatário (NFC-e): O rótulo do destinatário ("CPF:" ou "CNPJ:") deve ser determinado pelo número de caracteres do documento APÓS remover pontuação, considerando que letras devem ser preservadas. CPF tem 11 caracteres (numéricos); CNPJ tem 14 caracteres (alfanuméricos ou numéricos). A lógica atual baseada exclusivamente no comprimento do valor formatado (14 = CPF formatado, 18 = CNPJ formatado) falha quando o CNPJ alfanumérico chega sem máscara passa a ter 14 caracteres e seria rotulado erroneamente como CPF.
PROC005.3.1 - Ajustes Jasper - DANFe - Código de Barras da Chave de Acesso:
Regras de Negócio:
1. Troca obrigatória de subtipo Code 128: O subtipo Code 128C é incompatível com letras. Precisa ser trocado por Code 128B (alfanumérico maiúsculo) ou Code 128 (modo automático).
2. Sem mudança no conteúdo codificado: O dado codificado no código de barras continua sendo a chave de acesso de 44 caracteres. Apenas o algoritmo de codificação muda.
PROC005.3.2 - Ajustes Jasper - DANFCe:
Regras de Negócio:
1. Ajustes Label consumidor: O rótulo deve ser escolhido pelo número de caracteres do documento APÓS remover pontuação (preservando letras): 11 caracteres = CPF (numérico); 14 caracteres = CNPJ (alfanumérico ou numérico); qualquer outro tamanho = Id. Estrangeiro. A lógica atual decide pelo comprimento do valor formatado (14 = CPF, 18 = CNPJ), o que falha quando o CNPJ alfanumérico chega sem máscara pois tem 14 caracteres e seria rotulado como CPF.
2. Identificador estrangeiro inalterado: Documentos que não se enquadrem em 11 ou 14 caracteres continuam sendo rotulados como "Id. Estrangeiro:".
3. CPF continua exclusivamente numérico: Apenas CPF formatado (14 com pontuação) ou puro (11 numérico) recebe rótulo "CPF:". CPF não tem letras.
PROC005.3.2 - Ajustes Jasper - DANFCe:
Regras de Negócio:
1. Ajustes Label consumidor: O rótulo deve ser escolhido pelo número de caracteres do documento APÓS remover pontuação (preservando letras): 11 caracteres = CPF (numérico); 14 caracteres = CNPJ (alfanumérico ou numérico); qualquer outro tamanho = Id. Estrangeiro. A lógica atual decide pelo comprimento do valor formatado (14 = CPF, 18 = CNPJ), o que falha quando o CNPJ alfanumérico chega sem máscara pois tem 14 caracteres e seria rotulado como CPF.
2. Identificador estrangeiro inalterado: Documentos que não se enquadrem em 11 ou 14 caracteres continuam sendo rotulados como "Id. Estrangeiro:".
3. CPF continua exclusivamente numérico: Apenas CPF formatado (14 com pontuação) ou puro (11 numérico) recebe rótulo "CPF:". CPF não tem letras.6
©SOFTEN SISTEMAS 2026