Integração NFS-e GovDigital (v2.00), Conam, PublicSoft, Megasoft e Ágili: Como Resolver os Erros E183, GOV103, GOV105, GOV113 e GOV130

Expandir um ERP ou SaaS B2B para cidades médias do interior de Minas Gerais, São Paulo, Goiás, Mato Grosso e Nordeste rapidamente coloca o seu time de engenharia frente a frente com provedores municipais que fogem do comportamento padrão da ABRASF. Mesmo quando um fornecedor diz seguir o modelo ABRASF 2.0, detalhes como a versão exata no cabeçalho SOAP (versaoDados), prefixos de namespace no XML de retorno (ns2:CompNfse) ou tags proprietárias pós-Reforma Tributária (<MunicipioPrestacao>, <PaisPrestacao>, <CodigoNBS>) derrubam a emissão em produção.

Nas releases v0.56.147 e v0.56.148 da Notaas, concluímos a ativação global no worker de emissão (workers/shared/nfse-processor.ts) das 12 engines OOP municipais (futurize, megasoft, tributus, sintese, fisco, abase, aspec, publicsoft, govdigital, agili, tecnos e conam) — elevando nossa malha auditada para 4.836 municípios ativos em produção (86,81% do Brasil e 98,05% das 4.932 cidades com webservice) — e homologamos em nível de pacote cada peculiaridade do provedor GovDigital (ws.nfe-cidades.com.br) em municípios como Divinópolis/MG (3122306), Poços de Caldas/MG, Lavras/MG, Itaúna/MG, São João del-Rei/MG, Guaxupé/MG e Santa Rosa de Viterbo/SP.

Neste artigo técnico, vou abrir os bastidores dessas duas releases: como funcionam as regras de inferência automática e validação de credenciais das 12 engines OOP e como eliminamos as rejeições E183, GOV103, GOV105, GOV113 e GOV130 no GovDigital.

Homologar um provedor municipal em produção real exige ir além do XSD teórico: é nos prefixos ns2: do envelope SOAP e nos códigos GOV103 a GOV130 que uma integração caseira costuma quebrar.

O que mudou na v0.56.147: Ativação Global das 12 Engines OOP nos Workers e Inferência por Endpoint

Com a atualização do nosso catálogo central NFSE_SYSTEMS (VALID_SISTEMA_NFSE_VALUES, que hoje conta com 45 chaves cadastradas cobrindo 41 famílias de engines ativas no snapshot nacional), a release v0.56.147 ativou globalmente no worker de emissão (workers/shared/nfse-processor.ts) as 12 engines OOP que completam a cobertura regional de polos agroindustriais, industriais e de serviços:

(Nota de transparência arquitetural: no catálogo de 45 chaves, apenas pronim_abrasf permanece mapeada em UnsupportedEmissionStrategy nos workers enquanto finalizamos seu conector específico; as 12 engines OOP acima operam globalmente no worker de emissão unitária e permanecem fail-closed no processador de lotes assíncronos nfse-batch-processor.ts. Já o cancelamento via API — SISTEMAS_COM_CANCELAMENTO_NFSE — está habilitado para saatri e para 11 das 12 engines OOP que possuem supportsCancellation: true, mantendo apenas aspec fora do cancelamento automático).

Além disso, o PublicSoftEmitenteValidator ganhou um fallback inteligente na v0.56.147: como o cabeçalho HTTP da PublicSoft exige o codigoCidade, o validador aceita basic_auth_senha (onde o código municipal pode ser configurado) ou utiliza automaticamente o codigo_tom do município cadastrado na base oficial da plataforma, repassando basic_auth_usuario, basic_auth_senha, sigep_chave_privada e codigo_tom para getValidator(sistemaNfse).validate(...) em POST /api/v1/emitir.

Dissecanado o Protocolo GovDigital (v0.56.148): Solução dos Erros E183, GOV103, GOV105, GOV113 e GOV130

O provedor GovDigital (ws.nfe-cidades.com.br) é um excelente exemplo de como um webservice baseado na ABRASF introduz validações próprias que quebram qualquer cliente SOAP genérico. Durante a homologação em produção na release v0.56.148, mapeamos e resolvemos cinco armadilhas críticas na GovDigitalAbrasfEngine:

1. Rejeição E183 — versaoDados deve ser "2.00" (e não "2.02")

Embora a documentação conceitual e os namespaces do GovDigital sejam referenciados no mercado como ABRASF 2.02, o servidor ws.nfe-cidades.com.br valida estritamente a tag <versaoDados> dentro do <cabecalho> SOAP. Se você enviar <versaoDados>2.02</versaoDados>, o webservice rejeita o lote imediatamente com o erro E183 ("Versão de dados inválida").

• Solução na Notaas (v0.56.148): A GovDigitalAbrasfEngine sobrescreve versaoDados = '2.00' no cabeçalho SOAP mantendo o contrato XML exigido pelo servidor.

2. Rejeição GOV105 — <ItemListaServico> exige cTribNac de 6 dígitos

Na maioria das prefeituras ABRASF, a tag <ItemListaServico> recebe o item da LC 116/2003 com 4 dígitos (ex: 0107 ou 01.07). No GovDigital pós-adequação à Reforma Tributária, enviar apenas 4 dígitos dispara a rejeição GOV105 ("Item da lista de serviço inválido"), pois o validador exige o código nacional de 6 dígitos (cTribNac, com item + subitem + desdobro nacional, ex: 010701).

• Solução na Notaas (v0.56.148): Nosso hook normalizeItemListaServico() na GovDigitalAbrasfEngine converte automaticamente códigos de 4 dígitos (ex: 01.07 ➔ 010701) quando c_trib_nac não vier explícito com 6 dígitos, preservando o desdobro exato caso você envie os 6 dígitos no payload.

3. Rejeições GOV103 e GOV113 — Tags <MunicipioPrestacao>, <PaisPrestacao> e <CodigoNBS> dentro de <Servico>

Ao emitir uma nota no GovDigital enviando apenas as tags clássicas da ABRASF (<Valores>, <IssRetido>, <ItemListaServico>, <Discriminacao>, <CodigoMunicipio>), o servidor retorna duas rejeições simultâneas:

• GOV103: Município/País de prestação do serviço não informado.
• GOV113: Código NBS obrigatório para o item de serviço informado.

Isso ocorre porque o schema atualizado do GovDigital exige três elementos adicionais após <ExigibilidadeISS>:

1. <MunicipioPrestacao>: Código IBGE de 7 dígitos onde o serviço foi prestado.
2. <PaisPrestacao>: Código BACEN do país (1058 para Brasil).
3. <CodigoNBS>: Código da Nomenclatura Brasileira de Serviços de 9 dígitos numéricos.

Veja como o método buildExtraServicoXml() da GovDigitalAbrasfEngine injeta essa estrutura automaticamente (resolvendo o NBS a partir do payload ou da tabela oficial de correlação cTribNac ➔ NBS):

<Servico>
  <Valores>
    <ValorServicos>1500.00</ValorServicos>
    <Aliquota>2.00</Aliquota>
  </Valores>
  <IssRetido>2</IssRetido>
  <ItemListaServico>010701</ItemListaServico>
  <Discriminacao>Suporte tecnico e manutencao de infraestrutura cloud</Discriminacao>
  <CodigoMunicipio>3122306</CodigoMunicipio>
  <ExigibilidadeISS>1</ExigibilidadeISS>
  <MunicipioPrestacao>3122306</MunicipioPrestacao>
  <PaisPrestacao>1058</PaisPrestacao>
  <CodigoNBS>115022000</CodigoNBS>
</Servico>

4. Parser XML Agnóstico de Prefixo (ns2:CompNfse e ns2:MensagemRetorno)

Outro bug silencioso em integrações com o GovDigital (e provedores Java JAX-WS similares) está na leitura da resposta SOAP: o servidor devolve todos os elementos do XML de retorno prefixados com ns2: (ex: <ns2:GerarNfseResposta>, <ns2:CompNfse>, <ns2:MensagemRetorno>, <ns2:Codigo>GOV103</ns2:Codigo>). Na v0.56.148, substituímos doc.getElementsByTagName(...) pelo helper getElementsByLocalName(...) em parseCompNfseResponse, extractErrors e extractFirstText dentro de AbstractAbrasfEngine, garantindo extração 100% confiável tanto da nota autorizada quanto das listas de erros independentemente do prefixo de namespace.

5. Rejeição GOV130 — Auto-Healing CGSN 191/2026 para o Emissor Nacional (snnfse)

Por fim, quando uma empresa optante pelo Simples Nacional tenta emitir pelo webservice municipal do GovDigital com data de prestação a partir de 01/11/2026 em uma prefeitura que aderiu às Resoluções CGSN 189/191, o servidor retorna o código GOV130 ("Não é permitido emitir nota fiscal para o regime Simples Nacional com data de prestação a partir de 01/11/2026").

⚡ Fluxo de Auto-Healing para GOV130 na Notaas (v0.56.148):

• 1. Detecção Instantânea: A regra GOVDIGITAL_GOV130_SIMPLES_EMISSOR_NACIONAL (SIMPLES_ONLY) no Cgsn191RejectionDetector reconhece o código GOV130 retornado pelo GovDigital.
• 2. Promoção Automática de Rota: O worker atualiza o município (adn_aderente_emissor_nac = 1) e o projeto (sistema_nfse_override = 'snnfse') em produção para a API da NFS-e Nacional (snnfse).
• 3. Reemissão Transparente: Na mesma transação, o worker reconstrói o XML no formato DPS v1.01 da Receita Federal, assina com o Certificado A1 do projeto e autoriza a nota no SNNFSE, gerando o DANFSe v2.0 local sem que o seu ERP precise reenviar a chamada.

Para entender a fundo toda a especificação da Receita Federal e os endpoints REST, consulte também nosso guia sobre a Documentação Oficial e Swagger da API NFS-e Nacional e nosso Comparativo Geral de APIs Fiscais no Brasil.

Conecte seu SaaS a 4.836 cidades com um único payload JSON

Chega de perder negócios no interior de Minas Gerais, São Paulo, Goiás ou Nordeste porque a sua API fiscal atual não suporta GovDigital, Conam, PublicSoft, Megasoft ou Ágili — ou cobra taxas extras para homologar cidades:

• 4.836 municípios ativos em produção (86,81% do Brasil e 98,05% das cidades com webservice), sem taxa de ativação por prefeitura.
• 20 notas fiscais gratuitas por mês em Produção Real (1 CNPJ) + até 5 projetos simultâneos em Homologação via Org API.
• Auto-Healing CGSN 189/191 nativo (EL137, L1097, GOV130) e geração local de DANFSe v2.0 em PDF.

👉 Criar Conta Gratuita na Notaas Platform · Explorar a Documentação da API