POST /v1/service-invoices. Se a operação envolve produtos, veja Emissão
de NF-e ou Emissão de
NFC-e.
A emissão de NFS-e também é assíncrona — a resposta
2xx confirma
apenas que a nota foi aceita. Veja Síncrono vs
assíncrono e Ciclo de vida da
nota.NFS-e é o modelo mais heterogêneo dos três: cada prefeitura define seu
próprio layout, regras de validação e, às vezes, autenticação. Os
campos e o comportamento descritos aqui variam por provedor municipal —
trate esta página como um guia geral, não como a especificação exata do
seu município.
Exemplo de criação
cURL
description (discriminação dos serviços) e total são os únicos campos
formalmente obrigatórios pelo schema. Na prática, cada provedor municipal
costuma exigir também cnaeCode, federalServiceCode (código da lista de
serviço da LC 116/03) ou cityServiceCode — confirme com
GET /v1/service-invoices/cities e com as regras do seu município antes
de emitir em produção.DPS, RPS e a variação por prefeitura
Diferente de NF-e/NFC-e, que seguem um layout único definido pela SEFAZ nacional, a NFS-e historicamente foi implementada município a município, cada um com seu próprio provedor de emissão (Ginfes, Webiss, Betha, ISSNet, entre outros). Dois conceitos aparecem na maioria dos provedores:- RPS (Recibo Provisório de Serviços) — número provisório emitido antes da nota definitiva, usado por provedores tradicionais como comprovante interino enquanto o lote é processado.
- DPS (Declaração de Prestação de Serviços) — o documento equivalente no Ambiente Nacional da NFS-e (o padrão mais novo, que várias prefeituras vêm adotando para substituir seus sistemas próprios).
rpsNumber e rpsSeries representam tanto o
RPS quanto o DPS — o que eles significam depende do provedor do município.
O batchNumber identifica o lote, quando o provedor trabalha com envio em
lote. Qual formato seu município usa depende do provedor configurado para a
empresa.
Descobrindo se seu município é suportado
Antes de emitir, confirme que a cidade da sua empresa (ou da prestação do serviço) está integrada:code (código IBGE do município), state ou filterText (busca
por nome). Cada cidade retornada traz:
cURL
Ambiente Nacional e autenticação do provedor
O campoissueType (nas configurações da empresa,
bloco serviceInvoice) define a forma de emissão da NFS-e:
Muitos provedores municipais exigem, além do certificado digital da
empresa, uma autenticação própria — login e senha (ou token) cadastrados
junto à prefeitura ou ao provedor. Isso é configurado, não enviado por nota:
Nem todo município exige
userName/password/authNumber — alguns
autenticam só pelo certificado digital da empresa. Consulte o retorno de
GET /v1/service-invoices/cities e a documentação do provedor da sua
cidade para saber o que é necessário.Tributação de serviço (ISS)
O blocototal (ServiceInvoiceTotalDto) carrega a base de cálculo e as
alíquotas do serviço, incluindo issBaseTax, issRate, issAmount e as
flags de retenção (issWithheld, além de irWithheld, pisWithheld,
cofinsWithheld, inssWithheld, csllWithheld). O campo taxationType
define a natureza da tributação:
O local de apuração do ISS (
taxLocation) define de quem é a competência:
município da empresa, do cliente ou da prestação do serviço
(companyMunicipality, customerMunicipality, serviceProvisionMunicipality)
— a regra correta depende da natureza do serviço (Lei Complementar 116/03) e
varia por município.
O taxLocation não deve ser confundido com o campo location: este é a
cidade onde o serviço foi prestado (objeto CitySimpleDto — code IBGE,
name, state), informado quando a prestação ocorre em município diferente
do da empresa. taxLocation escolhe a competência; location diz qual é a
cidade da prestação.
Operações relacionadas
Próximos passos
- Estados possíveis da nota: Ciclo de vida da nota
- Configurar
serviceInvoice(série,issueType, credenciais do provedor): Configuração inicial - Cancelamento: Cancelamento, correção e inutilização