Developers / Documentos Fiscais / NFC-e
Documentos Fiscais · NFC-e

Emitir NFC-e POST

NFC-e (modelo 65, venda a consumidor final) usa o mesmo endpoint de NF-e -- é o campo ide.modelo: "65" que muda o documento, não uma rota separada. Esta página documenta o fluxo completo com foco nas diferenças reais; o que não é mencionado aqui funciona igual à NF-e.

Quando utilizar

Sempre que seu PDV/ERP precisar emitir uma NFC-e de venda de balcão a consumidor final, identificado ou não. Cada chamada gera exatamente um documento -- para venda B2B com destinatário identificado por CNPJ, normalmente é NF-e (modelo 55) que se aplica, ver NF-e.

Pré-requisitos além dos de NF-e

  • Tudo que NF-e já exige (contribuinte cadastrado, certificado A1).
  • CSC (Código de Segurança do Contribuinte) cadastrado -- sem ele a emissão falha antes de tentar montar o XML, porque não dá pra gerar o QR Code obrigatório do NFC-e. Hoje o cadastro do CSC é só pela Área do Cliente (tela de sessão logada) -- não existe endpoint público /v1/... pra isso ainda.

Fluxo da operação

POST /v1/nfe/emissoes (ide.modelo="65")
Motor calcula tributos, resolve o CSC, monta o QR Code, assina e transmite pra SEFAZ
200 OK · resultado final (mesma chamada)
💡
Síncrono, mesmo padrão de NF-e/CT-e/MDF-e/NFS-e. A própria chamada POST já calcula os tributos, resolve o CSC, monta o QR Code, assina e transmite pra SEFAZ -- a resposta já vem com status final (AUTHORIZED/REJECTED/ERROR/PROCESSING), não um "recebido, consulte depois".

Endpoint

POST https://areacliente.centralfiscal.com.br/v1/nfe/emissoes
⚠️
Cobertura de QR Code hoje: só RS. A URL do QR Code e a URL de consulta por chave variam por UF -- só temos a fórmula e as URLs oficiais confirmadas pra RS. Emitir NFC-e (modelo 65) pra outra UF falha explicitamente (NFCe ainda nao suportada para esta UF/ambiente) em vez de gerar um QR Code com URL genérica ou inventada.

Campos que mudam pra NFC-e

CampoDiferença
ide.modeloEnvie "65" -- se omitido, o padrão é "55" (NF-e).
destinatarioOpcional -- pode omitir inteiro em venda a consumidor final não identificado. Se informar, precisa vir completo (mesma validação da NF-e).
ide.presenca_compradorImportante informar -- o padrão da API é NAO_PRESENCIAL_OUTROS (indPres=9), errado pra venda de balcão. Use PRESENCIAL pra PDV comum. Ver Enums pros demais valores.
ide.consumidor_finalNormalmente CONSUMIDOR_FINAL pra NFC-e (o padrão da API é NORMAL, que é o certo pra NF-e B2B).

Exemplo mínimo

Venda de balcão, um item com ICMS já retido por ST anteriormente (CST 60) -- comum em PDV de varejo -- veja o código ao lado.

Resposta de sucesso

200 OK -- mesmo formato de resposta da NF-e, mas o detalhes.xml gerado já vem com o grupo infNFeSupl (QR Code + URL de consulta por chave) -- é isso que sua tela de PDV ou impressora fiscal precisa pra montar o DANFCe. O QR Code em si não vem como campo separado no JSON -- extraia o elemento qrCode do XML baixável pela URL em detalhes.

Resposta de erro

Exemplo real: emitir pra uma UF ainda sem cobertura de QR Code -- 400 Bad Request. Catálogo completo de erros: Tratamento de Erros.

Notificação assíncrona

Não existe webhook genérico hoje -- e como a chamada já é síncrona (a resposta já traz o resultado final), normalmente você não precisa de nada além do próprio POST.

Cancelamento

Usa o mesmo POST /v1/nfe/cancelamentos da NF-e (mesmos campos: chave_acesso/protocolo/justificativa com pelo menos 15 caracteres). Mesmo padrão síncrono da emissão: a resposta já vem com o resultado final do evento de cancelamento na SEFAZ. Exemplo de request/resposta: ver na página de NF-e (é o mesmo endpoint, documentar duas vezes só divergiria com o tempo).

Outros eventos (mesmos endpoints da NF-e)

Carta de Correção, Ator Interessado, os eventos RTC e a Manifestação do Destinatário também usam exatamente os mesmos endpoints documentados pra NF-e -- não existe rota nem motor separado pra NFC-e, a chave de acesso de 44 dígitos já identifica o modelo (65) sozinha. Tecnicamente qualquer um deles aceita uma chave de NFC-e.

⚠️
Nem todos fazem sentido pra venda de balcão. A CentralFiscal não bloqueia nenhum deles no seu lado -- quem decide se um evento se aplica ao modelo 65 é a SEFAZ, na hora de processar. Na prática:
  • Carta de Correção e Manifestação do Destinatário normalmente são rejeitados pela SEFAZ pra NFC-e -- venda de balcão em geral não tem destinatário identificado, e a regra de negócio do modelo 65 não prevê esses dois fluxos. Envie só se você já confirmou que a UF em questão aceita.
  • Ator Interessado e os eventos RTC são cenários de B2B/importação/apuração -- raro fazer sentido numa venda a consumidor final, mas nada nosso impede o envio.
Se a SEFAZ rejeitar por regra de negócio do modelo, o erro vem no mesmo formato de sempre -- ver Rejeições SEFAZ.

O que ainda não existe

  • Cadastro de CSC via API pública -- só pelo portal, sessão logada.
  • Cobertura de QR Code fora do RS.

Próximos passos

  • Baixar o XML (com infNFeSupl) usando a URL em detalhes e extrair o elemento qrCode pra imprimir/exibir no PDV.
  • Se precisar cancelar, ver POST /v1/nfe/cancelamentos acima.
  • Reconsultar mais tarde, se precisar: GET /v1/nfe/emissoes/{transmissao_id}.