Contexto
Ao emitir uma NFS-e, o tomador precisa de nome e, na maioria dos municípios,
endereço completo com código IBGE do município. Hoje o integrador coleta esses
dados por conta própria antes de montar o payload de serviceInvoices->create().
Isso é repetitivo e sujeito a erro, principalmente no código IBGE e no
formato do objeto de endereço.
Proposta
Oferecer, de forma 100% opcional, um resolver que preenche o tomador a partir do
CPF ou CNPJ, consultando os dados cadastrais em um provedor externo. A NFE.io
continua responsável por emitir a nota; a consulta apenas complementa os dados
cadastrais antes do envio. Não há sobreposição com a emissão: é um complemento
de dados de cadastro, não um caminho alternativo de emissão.
Desenho proposto, adaptado ao estilo do SDK:
- Interface
PessoaLookup (consultarCpf / consultarCnpj) devolvendo um DTO
normalizado (DadosPessoa), independente do provedor.
- Implementação de referência sobre a API da cpfcnpj.com.br, reaproveitando o
transporte HTTP do próprio SDK (Nfe\Http\Transport), sem novas dependências
em runtime.
TomadorResolver (porCpf / porCnpj / porDocumento) que devolve o
Borrower do próprio SDK, já com o endereço no formato esperado pela API da
NFE.io (city.code recebe o código IBGE do município).
Por que fora do codegen
A consulta cadastral é de um provedor de dados de terceiros, então o recurso
vive em um namespace próprio e desacoplado (Nfe\Cpfcnpj), sem tocar nas
famílias geradas a partir do OpenAPI nem em nenhum fluxo existente. Fica
totalmente inativo até o integrador optar por usá-lo.
Disposição para contribuir
Tenho uma implementação pronta (com testes Pest, PHPStan nível 8 e PHP-CS-Fixer
limpos) e abro um PR caso a proposta faça sentido para o projeto.
Contexto
Ao emitir uma NFS-e, o tomador precisa de nome e, na maioria dos municípios,
endereço completo com código IBGE do município. Hoje o integrador coleta esses
dados por conta própria antes de montar o payload de
serviceInvoices->create().Isso é repetitivo e sujeito a erro, principalmente no código IBGE e no
formato do objeto de endereço.
Proposta
Oferecer, de forma 100% opcional, um resolver que preenche o tomador a partir do
CPF ou CNPJ, consultando os dados cadastrais em um provedor externo. A NFE.io
continua responsável por emitir a nota; a consulta apenas complementa os dados
cadastrais antes do envio. Não há sobreposição com a emissão: é um complemento
de dados de cadastro, não um caminho alternativo de emissão.
Desenho proposto, adaptado ao estilo do SDK:
PessoaLookup(consultarCpf/consultarCnpj) devolvendo um DTOnormalizado (
DadosPessoa), independente do provedor.transporte HTTP do próprio SDK (
Nfe\Http\Transport), sem novas dependênciasem runtime.
TomadorResolver(porCpf/porCnpj/porDocumento) que devolve oBorrowerdo próprio SDK, já com o endereço no formato esperado pela API daNFE.io (
city.coderecebe o código IBGE do município).Por que fora do codegen
A consulta cadastral é de um provedor de dados de terceiros, então o recurso
vive em um namespace próprio e desacoplado (
Nfe\Cpfcnpj), sem tocar nasfamílias geradas a partir do OpenAPI nem em nenhum fluxo existente. Fica
totalmente inativo até o integrador optar por usá-lo.
Disposição para contribuir
Tenho uma implementação pronta (com testes Pest, PHPStan nível 8 e PHP-CS-Fixer
limpos) e abro um PR caso a proposta faça sentido para o projeto.