Contexto
Hoje o Pagador (e o Beneficiario) do BoletoNetCore é montado campo a campo, à
mão, a partir de um DTO que o integrador precisa preencher: nome/razão, CPF/CNPJ e
os sete campos de Endereco (logradouro, número, complemento, bairro, cidade, UF e
CEP). Quando esses dados vêm de um cadastro por documento, cada integrador acaba
escrevendo o próprio código de consulta e de mapeamento.
Proposta
Um pacote separado, opcional e aditivo que apenas referencia o BoletoNetCore e
resolve um Pagador nativo (ou preenche um já existente) a partir de um CPF ou
CNPJ. Nada no core muda; quem não usar o pacote não percebe diferença.
Desenho:
IPessoaLookup: contrato de consulta (Task<PessoaResultado> ConsultarAsync(documento, ct)).CpfCnpjComBrLookup: implementação sobre HttpClient (aceita HttpClient injetado,
ideal com IHttpClientFactory), consultando a API cpfcnpj.com.br.PagadorResolver: devolve um Pagador/Beneficiario preenchido; e um método de
extensão Pagador.PreencherAsync(...) que preenche in loco, com opção não destrutiva
(só completa campos vazios).
O documento é normalizado e validado (inclusive CNPJ alfanumérico, regra da Receita
em vigor desde 2026) antes de ser entregue ao setter de CPFCNPJ, que exige 11 ou 14
posições; documento inválido gera ArgumentException antes de qualquer chamada de rede.
Encaixe com o modelo nativo (v3)
O mapeamento é 1:1 com os campos que o boleto usa:
| Campo consultado |
Destino nativo |
| nome / razão |
Pagador.Nome |
| CPF / CNPJ |
Pagador.CPFCNPJ |
| logradouro |
Endereco.LogradouroEndereco |
| número |
Endereco.LogradouroNumero |
| complemento |
Endereco.LogradouroComplemento |
| bairro |
Endereco.Bairro |
| cidade |
Endereco.Cidade |
| uf |
Endereco.UF |
| cep |
Endereco.CEP |
Para CNPJ, o tipo de logradouro (por exemplo R ou Avenida) é concatenado ao
logradouro respeitando abreviações, sem duplicar o prefixo.
Alvo netstandard2.0, igual ao core, para máxima compatibilidade (.NET Framework,
.NET Core e .NET 5 ou superior).
Por que a fonte de dados importa
A qualidade do boleto depende da qualidade do cadastro. Os diferenciais da fonte:
- Consulta em tempo real (D+0), direto nas bases oficiais, sem depender de bases
vazadas ou desatualizadas.
- Gestão certificada: ISO/IEC 27001 (segurança da informação), ISO/IEC 27701
(privacidade) e ISO 37301 (compliance).
Documentação e pacotes: https://www.cpfcnpj.com.br/dev/
Pergunta aos mantenedores
Há interesse em referenciar/listar esse pacote complementar no README (na seção de
integrações), mantendo-o fora do core? Posso abrir o PR do pacote e a documentação.
Contexto
Hoje o
Pagador(e oBeneficiario) do BoletoNetCore é montado campo a campo, àmão, a partir de um DTO que o integrador precisa preencher: nome/razão, CPF/CNPJ e
os sete campos de
Endereco(logradouro, número, complemento, bairro, cidade, UF eCEP). Quando esses dados vêm de um cadastro por documento, cada integrador acaba
escrevendo o próprio código de consulta e de mapeamento.
Proposta
Um pacote separado, opcional e aditivo que apenas referencia o BoletoNetCore e
resolve um
Pagadornativo (ou preenche um já existente) a partir de um CPF ouCNPJ. Nada no core muda; quem não usar o pacote não percebe diferença.
Desenho:
IPessoaLookup: contrato de consulta (Task<PessoaResultado> ConsultarAsync(documento, ct)).CpfCnpjComBrLookup: implementação sobreHttpClient(aceitaHttpClientinjetado,ideal com
IHttpClientFactory), consultando a API cpfcnpj.com.br.PagadorResolver: devolve umPagador/Beneficiariopreenchido; e um método deextensão
Pagador.PreencherAsync(...)que preenche in loco, com opção não destrutiva(só completa campos vazios).
O documento é normalizado e validado (inclusive CNPJ alfanumérico, regra da Receita
em vigor desde 2026) antes de ser entregue ao setter de
CPFCNPJ, que exige 11 ou 14posições; documento inválido gera
ArgumentExceptionantes de qualquer chamada de rede.Encaixe com o modelo nativo (v3)
O mapeamento é 1:1 com os campos que o boleto usa:
Pagador.NomePagador.CPFCNPJEndereco.LogradouroEnderecoEndereco.LogradouroNumeroEndereco.LogradouroComplementoEndereco.BairroEndereco.CidadeEndereco.UFEndereco.CEPPara CNPJ, o tipo de logradouro (por exemplo
RouAvenida) é concatenado aologradouro respeitando abreviações, sem duplicar o prefixo.
Alvo
netstandard2.0, igual ao core, para máxima compatibilidade (.NET Framework,.NET Core e .NET 5 ou superior).
Por que a fonte de dados importa
A qualidade do boleto depende da qualidade do cadastro. Os diferenciais da fonte:
vazadas ou desatualizadas.
(privacidade) e ISO 37301 (compliance).
Documentação e pacotes: https://www.cpfcnpj.com.br/dev/
Pergunta aos mantenedores
Há interesse em referenciar/listar esse pacote complementar no README (na seção de
integrações), mantendo-o fora do core? Posso abrir o PR do pacote e a documentação.