Nota Fiscal de Serviço Eletrônica (Nfs-E) Manual de Integração

NOTA FISCAL DE SERVIÇO
ELETRÔNICA (NFS-e)
Manual de Integração
Versão 1.4
1. INTRODUÇÃO ................................
................................................................................................
........................................................ 4
2. CONSIDERAÇÕES INICIAIS ................................................................................................
...................................... 5
NOTA FISCAL DE SERVIÇOS ELETRÔNICA - NFS-E .............................................................
................................ 5
RECIBO PROVISÓRIO DE SERVIÇO - RPS ................................................................
................................................. 5
3. ARQUITETURA DE COMUNICAÇÃO COM O CONTRIBUINTE .............................................6
................................
MODELO CONCEITUAL ................................
................................................................................................
..........................................6
....................................6
Recepção e Processamento de Lote de RPS ................................................................
Consulta de Situação de Lote de RPS ................................................................
.................................... 6
................................................... 7
Consulta de NFS-e por RPS ................................................................
Consulta de Lote de RPS ................................................................
........................................................... 8
Consulta de NFS-e ................................ ....................................... 8
................................................................................................
Cancelamento de NFS .............................................................. 9
NFS-e ................................................................
PADRÕES TÉCNICOS ................................
................................................................................................
........................................10
Padrão de Comunicação ................................................................
............................................................ 10
................................................. 11
Padrão de Certificado Digital ................................................................
Padrão de Assinatura Digital ................................................................
................................................. 11
Validação de Assinatura Digital pelo Sistema NFS-e ............................................
................................ 13
............................................................. 13
Uso de Assinatura com Certificado Digital................................
PADRÃO DAS MENSAGENS XML ................................................................
.....................................................14
Área do Cabeçalho................................ ................................ 14
................................................................................................
Validação da estrutura das Mensagens XML .............................................................
................................ 14
................................................... 15
Schemas XML (arquivos XSD) ................................................................
......................................................... 15
Versão dos Schemas XML ................................................................
4. ESTRUTURA DE DADOS DO WEB SERVICE ................................................................
...................................... 16
MODELO OPERACIONAL ................................................................................................
..................................... 16
Serviços Síncronos ................................ ............................... 16
...............................................................................................
............................................................ 17
Serviços Assíncronos................................................................
FORMATOS E PADRÕES UTILIZADOS ................................................................
.............................................18
TIPOS SIMPLES ................................ ...................................... 19
................................................................................................
TIPOS COMPLEXOS ................................ ............................... 22
...............................................................................................
SERVIÇOS ................................
................................................................................................
.................................................... 27
.................................. 28
Recepção de Lote de RPS ................................................................................................
Consulta de Situação de Lote de RPS ................................................................
.................................. 28
................................................. 29
Consulta de NFS-e por RPS ................................................................
Consulta de NFS-e ................................ ..................................... 29
................................................................................................
......................................................... 29
Consulta de Lote de RPS ................................................................
Cancelamento NFS-e ................................. 30
e ................................................................................................
5. ANEXO ................................
................................................................................................................................
.................................. 30
TABELA DE ERROS ................................
................................................................................................
........................................... 30
TABELA DE ERROS ESPECÍFICOS DE CURITIBA............................................................
................................ 31
REGRAS ESPECÍFICAS DE CURITIBA ................................................................
................................................ 31
Este manual tem como objetivo apresentar as especificações e critérios técnicos
necessários para utilização do Web Service disponibilizado pela Prefeitura Municipal de
Curitiba, conforme modelo ABRASF - Associação Brasileira
ileira de Secretários e Dirigentes
das Finanças dos Municípios das Capitais, para as empresas prestadoras e/ou
tomadoras de serviços.
Através do Web Service as empresas poderão integrar seus próprios sistemas de
informações com o Sistema da Prefeitura. Des
Desta
ta forma, consegue-se
consegue automatizar o
processo de geração, consulta e cancelamento de NFS
NFS-e.
3
A Nota Fiscal de Serviços Eletrônica (NFS(NFS-e)
e) é um documento de existência
exclusivamente digital, gerado e armazenado eletronicamente pela Prefeitura ou por
outra entidade conveniada, para documentar as operações de prestação de serviços.
A geração da NFS-e e será feita, automaticamente, por meio de serviços informatizados,
disponibilizados aos contribuintes. Para que sua geração seja efet
efetuada, dados que a
compõem serão informados, analisados, processados, validados e, se corretos, gerarão
o documento.
A responsabilidade pelo cumprimento da obrigação acessória de emissão da NFS
NFS-e e
pelo correto fornecimento dos dados à Prefeitura, para a geração da mesma, é do
contribuinte.
A NFS-e somente será gerada através dos services informatizados disponibilizados

pela Prefeitura. Esse tipo de serviço é seguido de alguns riscos inerentes à ininterrupta
disponibilidade, podendo, portanto, em alguns momentos tornar-se indisponível.
Visando manter as atividades dos contribuintes ininterruptas, independente de os
serviços informatizados disponibilizados pela Prefeitura Municipal de Curitiba estarem
disponíveis, foi criado o Recibo Provisório dde
e Serviços (RPS), que é um documento de
posse e responsabilidade do contribuinte, que deverá ser gerado manualmente ou por
alguma aplicação local, possuindo uma numeração seqüencial crescente e devendo ser
convertido em NFS-e e no prazo estipulado pela legis
legislação
lação tributária municipal.
4
Através do Web Service, o Sistema de Notas Fiscais de Serviço Eletrônicas da
Prefeitura de Curitiba disponibilizará serviços que poderão ser acessados pelos
sistemas dos contribuintes. A seguir, estão resumidos os serviços disponíveis e suas
respectivas funcionalidades básicas.
Esse serviço compreende a recepção do Lote de RPS, a resposta com o número do

protocolo gerado para esta transação e o processamento do lote. Quando efetuada a
recepção, o Lote entrará na fila para processamento posterior onde serão feitas as
validações necessárias e geração das NFS
NFS-e.
Passos para execução

1.
2. A requisição é recebida pelo servidor do Web Service que grava as informações

recebidas e gera o número de protocolo de recebimento (fluxo
3. O Web Service retorna uma mensagem com o resultado do processamento do
serviço (
Esse serviço efetua a consulta da situação de um Lote de RPS já enviado.
5
1.
os dados para processamento (fluxo
2. A requisição é recebida pelo servidor do Web Service, que verifica os dados

serviço
Esse serviço efetua a consulta de uma NFS

NFS-e
e a partir do número de RPS que a gerou.
6
1. -
dados para processamento (fluxo
preenchidos e identifica a NFS
NFS-
se
Esse serviço permite ao contribuinte obter as NFS

NFS-ee que foram geradas a partir do
Lote de RPS enviado, quando o proc processamento
essamento ocorrer sem problemas; ou obter a
lista de erros e/ou inconsistências encontradas nos RPS.
Na validação do lote, devem ser retornados todos os erros verificados.
Excepcionalmente, havendo uma excessiva quantidade de erros, poderá ser definido
um limitador para a quantidade de erros retornados.

1. A aplicação acessa o

preenchidos e identifica as NFS-
3. O Web Service retorna uma mensagem (a estrutura com a lista da NFS-
NFS e geradas
ou as mensagens de erro) com o resultado do processamento do serviço (fluxo
Esse serviço permite a obtenção de determinada NFS

NFS-e já gerada.
7
XML de Envio é validado pelo arquivo: servico_consultar_nfse_envio.xsd
XML de Resposta é validado pelo arquivo: servico_consultar_nfse_resposta.xsd

1. -
processamento ().
preenchidos e identifica as NFS
NFS-e correspondentes.
3. O Web Service retorna uma mensagem com o resultado
do processamento do serviço.
Esse serviço permite o cancelamento direto de uma NFS

NFS-e
e sem substituição da
mesma por outra.

1. -

preenchidos, identifica a NFS
NFS-e correspondente e efetua o seu cancelamento (fluxo
3. O Web Service retorna uma mensagem c o m o resultado do processamento

do serviço (fluxo
8
O meio físico de comunicação utilizado entre os sistemas de informação dos
contribuintes e o Sistema de Notas Fiscais de Serviço Eletrônicas da Prefeitura de
Curitiba será a Internet, com o uso do protocolo SSL, que além de garantir um duto
de comunicação seguro na Internet, permite a identificação do servidor e do cliente
através de certificados digitais, eliminando a necessidade de identificação do usuário
através de nome ou código de usuário e senha.
O modelo de comunicação segue o padrão de Web Services definido pelo WS-I
WS Basic
Profile.
A troca de mensagens entre o Web Service do Sistema de Notas Fiscais de Serviço
Eletrônicas da Prefeitura de Curitiba e o sistema do contribuinte será realizada no
padrão SOAP,
OAP, com troca de mensagens XML no padrão Style/Enconding:
métodos disponíveis com a passagem de mais de um parâmetro. Para descrever os

serviços disponibilizados, será utilizado um documento WSDL (Web Service
Description Language). O WSDL é o padrão recom
recomendado
endado para descrição de serviços
SOAP.
9
As chamadas aos serviços serão feitas enviando como parâmetro um
documento XML a ser processado pelo sistema. Esse documento não fará
parte da descrição do serviço (arquivo WSDL), e o formato do XML
correspondente ao serviço deverá ser consultado nesse manual de integração,
seção 4.5.
Os certificados digitais utilizados no sistema de Notas Fiscais de Serviço

Eletrônicas, da Prefeitura de Curitiba, serão emitidos por Autoridade
Certificadora credenciada pela Infra
Infra-estrutura
estrutura de Chaves Públicas Brasileira
ICP-Brasil,
Brasil, de pessoa física ou jurídica, dos tipos A1, A3 ou certificado de
servidor (híbrido).
Para a assinatura digital dos documentos envolvidos aceitar-se se-á que o
certificado digital seja de quaisquer dos estabelecimentos da empresa.
Os certificados digitais serão exigidos em 2 (dois) momentos distintos para a
integração entre o sistema do contribuinte e o Web Service da Prefeitura de
Curitiba:
Assinatura de Mensagens: O certificado digital utilizado para essa função
deverá conter o CNPJ do estabelecimento emissor da NFS NFS-ee ou o CNPJ do
estabelecimento matriz. O certificado digital deverá ter
previsto para a função de assinatura digital, respei respeitando
tando a Política do
Certificado.
Transmissão (durante a transmissão das mensagens entre os servidores do
contribuinte e os serviços disponibilizados pela Prefeitura de
Curitiba): O certificado digital utilizado para identificação do aplicat
aplicativo do
contribuinte deverá conter o CNPJ do responsável pela transmissão das
mensagens, mas não necessita ser o mesmo CNPJ do estabelecimento
emissor da NFS-e, e, devendo ter a extensão extended Key Usage com
permissão de "Autenticação Cliente".
As mensagens enviadas aos serviços disponibilizados pela Prefeitura de

Curitiba são documentos eletrônicos elaborados no padrão XML e devem ser
assinados digitalmente com um certificado digital que contenha o CNPJ do
estabelecimento matriz ou o CNPJ do estab
estabelecimento
elecimento emissor da NFS-e
NFS
objeto do pedido.
Para garantir minimamente a integridade das informações prestadas e a
correta formação dos arquivos XML, o contribuinte deverá submeter as
mensagens XML para validação pela linguagem de Schema do XML (XSD
XML Schema Definition), disponibilizada pela Prefeitura de Curitiba antes de
seu envio.
10
Os elementos abaixo estão presentes dentro do Certificado do contribuinte
tornando desnecessária a sua representação individualizada no arquivo XML.
Portanto, o arquivo XML não deve conter os elementos:
<X509SubjectName>
<X509IssuerSerial>
<X509IssuerName>
<X509SerialNumber>
<X509SKI>
Deve-se evitar o uso das TAGs abaixo, pois as informações serão obtidas a partir do
Certificado do emitente:
<KeyValue>
<RSAKeyValue>
<Modulus>
<Exponent>
O Projeto NFS-e utiliza um subconjunto do padrão de assinatura XML definido pelo

http://www.w3.org/TR/xmldsig-core/, que tem o seguinte leiaute:
# Campo Elemento Pai Tipo Ocorrênci Descrição

XS01 Signature Raiz
XS02 Id A XS01 C 1-1
XS03 SignedInfo G XS01 1-1 Grupo da Informação da assinatura
XS04 CanonicalizationMethod G XS03 1-1 Grupo do Método de Canonicalização
XS05 Algorithm A XS04 C 1-1 Atributo Algorithm de CanonicalizationMethod:
http://www.w3.org/TR/2001/REC-xml-c14n-
XS06 SignatureMethod G XS03 1-1 Grupo do Método de Assinatura
XS07 Algorithm A XS06 C 1-1 Atributo Algorithm de SignedInfo:
XS08 Reference G XS03 1-1 Grupo do Método de Reference

XS09 URI A XS08 C 1-1 Atributo URI da tag Reference
XS10 Transforms G XS08 1-1 Grupo do algorithm de Transform
XS11 Unique_Transf_Alg RC XS10 1-1 Regra para o atributo Algorithm do Transform ser
único
XS12 Transform G XS10 2-2 Grupo de Transform
XS13 Algorithm A XS12 C 1-1 Atributos válidos Algorithm do Transform:
http://www.w3.org/TR/2001/REC-xml-c14n-
20010315
XS14 Xpath E XS12 C 0-N Xpath
XS15 DigestMethod G XS08 1-1 Grupo do Método de DigestMethod
XS16 Algorithm A XS15 C 1-1 Atributo Algorithm de DigestMethod:
XS17 DigestValue E XS08 C 1 Digest Value (Hash SHA-1 Base64)
XS18 SignatureValue G XS01 1-1 Grupo do Signature Value
XS19 KeyInfo G XS01 1-1 Grupo do KeyInfo
11
XS20 X509Data G XS19 1-1 Grupo X509
XS21 X509Certificate E XS20 C 1-1 Certificado Digital x509 em Base64b
Para a validação da assinatura digital, seguem as regras que serão adotadas pela
Prefeitura de Curitiba:
1. Extrair a chave pública do certificado;
2. Verificar o prazo de validade do certificado utilizado;
3. Montar e validar a cadeia de confiança dos certificados validando também a
LCR (Lista de Certificados Revogados) de cada certificado da cadeia;
4. Validar o uso da chave utilizada (Assinatura Digital) de tal forma a aceitar
certificados somente do tipo A (não serão aceitos certificados do tipo S);
5. Garantir
arantir que o certificado utilizado é de um usuário final e não de uma
Autoridade Certificadora;
6. Adotar as regras definidas pelo RFC 3280 para LCRs e cadeia de confiança;
7. Validar a integridade de todas as LCR utilizadas pelo sistema;
8. Prazo de validade de cada LCR utilizada (verificar data inicial e final).
A forma de conferência da LCR pode ser feita de 2 (duas) maneiras: On

On-line ou
Download periódico. As assinaturas digitais das mensagens serão verificadas
considerando o horário fornecido pelo Observató
Observatório Nacional.
Para garantir a autenticidade dos dados gerados, algumas informações deverão

ser assinadas digitalmente. Abaixo segue as informações que deverão ser assinadas
e quem deverá fazê-lolo em cada momento:
O RPS, pelo contribuinte, antes do envio do mesmo através do Lote de RPS;

O Lote de RPS, pelo contribuinte, antes do envio do mesmo;
A NFS-e:
Pela prefeitura e pelo contribuinte, quando gerada pela Aplicação On Line;
Pela prefeitura nos demais casos;
O Pedido de cancelamento da NFS
NFS-e, pelo contribuinte;
A Confirmação de cancelamento da NFS
NFS-e, pela prefeitura;
12
A especificação adotada para as mensagens XML é a recomendação W3C para XML
1.0, disponível em www.w3.org/TR/REC
www.w3.org/TR/REC-xml e a codificação dos caracteres será em
UTF-8.
As chamadas dos Web Services disponibilizados pela Prefeitura de Curitiba e os
respectivos resultados do processamento são realizadas através das mensagens
com o seguinte padrão:
Área de Cabeçalho estrutura XML padrão para todas as mensagens de chamada e
retorno de resultado dos Web Services disponibilizados pela Prefeitura de Curitiba,
que contém os dados de controle da mensagem. A área de cabeçalho está sendo
utilizada para armazenar a versão do leiaute da estrutura XML informado na área de
dados.
Área de Dados estrutura XML variável definida na documentação do Web Service
acessado.
Abaixo, o leiaute da Área de Cabeçalho padrão:

# Nome Elemento Pai Tipo Ocorrência Tamanho Descrição
1 cabecalho G 1-1 TAG raiz do cabeçalho da
Versão A 1 N 1-1 4 Versão do leiaute.

2 versaoDados E 1 N 1-1 4 O conteúdo deste campo indica a
versão do leiaute XML da estrutura
O campo versaoDados deve conter a informação da versão do leiaute da estrutura

XML armazenada na área de dados da mensagem.
A estrutura XML armazenada na área de dados está definida na documentação do
Web Service acessado.
Para garantir minimamente a integridade das informações prestadas e a correta

formação das mensagens XML, o contribuinte deverá submeter cada uma das
mensagens XML de pedido de serviço para validação pelo seu respectivo arquivo
XSD (XML Schema Definition, definição de esquemas XML) antes de seu envio.
Neste manual utilizaremos a nomenclatura Schema XML para nos referir a arquivo
XSD.
Um Schema XML define
efine o conteúdo de uma mensagem XML, descrevendo os
seus atributos, elementos e a sua organização, além de estabelecer regras de
preenchimento de conteúdo e de obrigatoriedade de cada elemento ou grupo de
informação.
13
A validação da estrutura
strutura da mensagem XML é realizada por um analisador sintático
(parser) que verifica se a mensagem XML atende as definições e regras de seu
respectivo Schema XML.
Qualquer divergência da estrutura da mensagem XML em relação ao seu respectivo
Schema XML, provoca um erro de validação do Schema XML. Neste caso o conteúdo
da mensagem XML de pedido do serviço não poderá ser processado.
A primeira condição para que a mensagem XML seja validada com sucesso é que ela
seja submetida ao Schema XML correto.
Assim, os sistemas de informação dos contribuintes devem estar preparados para
gerar mensagens XML em seus respectivos Schemas XML em vigor.
O Schema XML (arquivo XSD) correspondente a cada uma das mensagens XML de
pedido e de retorno utilizadas pelo Web Service pode ser obtido na internet
acessando o Portal da Nota Curitibana da Prefeitura de Curitiba.
Toda mudança de layout das mensagens XML do Web Service implica na atualização
do seu respectivo Schema XML.
A identificação da versão dos Schemas XML será realizada com o acréscimo do
como segue:
<Nome do Arquivo>_v<Número da Versão>.xsd

Exemplo: EnvioLoteRps_v01.xsd
A maioria dos Schemas XML definidos para a utilização do Web Service do Sistema
de Notas Fiscais de Serviço Eletrôn
Eletrônicas
icas da Prefeitura de Curitiba utilizam as
definições de tipos simples ou tipos complexos que estão definidos em outros
Schemas XML, nestes casos, a modificação de versão do Schema básico será
repercutida no Schema principal.
As modificações de layout das mensagens XML do Web Service podem ser causadas
por necessidades técnicas ou em razão da modificação de alguma legislação. As
modificações decorrentes de alteração da legislação deverão ser implementadas nos
prazos previstos no ato normativo que introduziu a alteração. As modificações de
ordem técnica serão divulgadas pela Prefeitura de Curitiba e poderão ocorrer sempre
que se fizerem necessárias.
14
Existirá um único Web Service com todos os serviços apresentados no item
3.1. O fluxo de comunicação é sempre iniciado pelo sistema do contribuinte através
do envio de uma mensagem XML ao Web Service com o pedido do serviço desejado.
A forma de processamento das solicitações de serviços no projeto Nota Fiscal de

Serviços Eletrônica pode ser síncrona, caso o atendimento da solicitação de serviço
seja realizada na mesma conexão ou assíncrona, quando o
processamento do serviço solicitado não é atendido na mesma conexão, devido à
uma demanda de processamento de grande quantidade de
informação. Nesta situação torna
torna-se necessária a realização de mais uma conexão
para a obtenção do resultado do processamento.
As solicitações de serviços que exigem processamento intenso serão executadas de
forma assíncrona e as demais solicitações de serviços de forma síncrona.
Assim, os serviços da NFS--e
e serão implementados da seguinte forma:
Serviço Implementaç
Implementação
Recepção e Processamento de Lote de RPS Assíncrona
Consulta de Situação de Lote de RPS Síncrona
Consulta de NFS-e por RPS Síncrona
Consulta de Lote de RPS Síncrona
Consulta de NFS-e Síncrona
Cancelamento de NFS-e Síncrona
As solicitações de serviços de implementação síncrona são processadas

imediatamente e o resultado do processamento é obtido em uma única conexão.
Abaixo, o fluxo simplificado de funcionamento:
15
Etapas do processo ideal:
1. O aplicativo do contribuinte inicia a conexão enviando uma mensagem de
solicitação de serviço para o Web Service;
2. O Web Service recebe a mensagem de solicitação de serviço e encaminha ao
aplicativo da NFS-e
e que irá processar o serviço solicitado;
3. O aplicativo da NFS-e
e recebe a mensagem de solicitação de serviços e realiza o
processamento, devolvendo uma mensagem de resultado do processamento ao Web
Service;
4. O Web Service recebe a mensagem de resultado do processamento e o
encaminha ao aplicativo do contribuinte;
5. O aplicativo do contribuinte recebe a mensagem de resultado do processamento e
caso não exista outra mensagem, encerra a conexão.
As solicitações de serviços de implementação assíncrona são processadas de forma

distribuída por vários processos e o resultado do processamento somente é
obtido na segunda conexão.
Abaixo, o fluxo simplificado de funcionamento:
Etapas do processo ideal: Solicitação e processamento:

1. O aplicativo do contribuinte inicia a conexão enviando uma mensagem de
solicitação de serviço para o Web Service de recepção de solicitação de serviços;
2. O Web Service de recepção de solicitação de serviços recebe a mensagem de
solicitação de serviço e a coloca na fila de serviços solicitados, acrescentando o
CNPJ do transmissor obtido do certificado digital do transmissor;
3. O Web Service de recepção de solicitação de serviços retorna o protocolo
da solicitação de serviço e a data e hora de gravação na fila de serviços solicitados
ao aplicativo do contribuinte;
nte;
16
4. O aplicativo do contribuinte recebe o protocolo;
5. Na estrutura interna do aplicativo de NFS
NFS-e
e a solicitação de serviços é retirada da
fila de serviços solicitados pelo aplicativo da NFS
NFS-e e em momento específico,
definido pela equipe
ipe técnica da NFS-e;
6. O serviço solicitado é processado pelo aplicativo da NFS
NFS-e
e e o resultado do
processamento é colocado na fila de serviços processados;
Obtenção do resultado do serviço:
7. O aplicativo do contribuinte, através do protocolo recebido, envia uma consulta ao
serviço que retornará o resultado do processamento daquele protocolo, iniciando uma
conexão com o Web Service;
8. O Web Service recebe a mensagem de consulta e localiza o resul
resultado de
processamento da solicitação de serviço;
9. O Web Service devolve o resultado do processamento ao aplicativo contribuinte;
10. O aplicativo do contribuinte recebe a mensagem de resultado do
processamento e, caso não exista outra mensagem, encerra a conexão.
conexã
Abaixo segue algumas formatações de dados que devem ser seguidas para geração
correta na estrutura dos arquivos.
Formato Observação
Data (date) Formato: AAAA
AAAA-MM-DD
onde:
AAAA = ano com 4 caracteres MM = mês com 2 caracteres DD = dia com 2 caracteres
Data/Hora (datetime) Formato AAAA
AAAA-MM-DDTHH:mm:ss onde:
AAAA = ano com 4 caracteres MM = mês com 2 caracteres DD = dia com 2 caracteres
T = caractere de formatação que deve existir separando a data da hora
HH = hora com 2 caracteres mm: minuto com 2 caracteres ss: segundo com 2 caracteres
Valores Decimais Formato: 0.00
(decimal) Não deve ser utilizado separador de milhar. O ponto (.) deve ser utilizado para separar a
parte inteira da fracionária.
Exemplo:
Valores Percentuais Formato 0.0000
(decimal) O formato em percentual presume o valor percentual em sua forma fracionária, contendo 5
dígitos. O ponto (.) separa a parte inteira da fracionária.
Exemplo:
62% = 0.62
17
Não deve ser inserido caractere não significativo para preencher o tamanho completo
do campo, ou seja, zeros antes de número ou espaço em branco após cadeia de
caracteres. A posição do campo é definida na estrutura do documento XML através de
TAGs (<tag>conteúdo</tag>).
A regra constante do parágrafo anterior deverá estender
estender-se
se para os campos onde não
há indicação de obrigatoriedade e que, no entanto, seu preenchimento torna-se
torna
obrigatório por estar condicionado à legislação específica ou ao negócio do
contribuinte. Neste caso, deverá constar a TAG com o valor correspondente e, para os
demais campos, deverão ser eliminadas as TAGs.
Para reduzir o tamanho final do arquivo XML da NFS

NFS-e
e alguns cuidados de
programação deverão ser assumidos:
não incluir "zeros não significativos" para campos numéricos;
não incluir "espaços" no início ou no final de campos numéricos e

alfanuméricos;
não incluir comentários no arquivo XML;
não incluir anotação e documentação no arquivo XML (TAG annotation e
TAG documentation);
não incluir caracteres de formatação no arquivo XML ("line-feed",

("line
"carriage return", "tab", caractere de "espaço" entre as TAGs).
As TAGs que permitirem valores nulos devem ser omitidas da estrutura

XML a ser enviada.
A seguir encontra-se
se a tabela com a lista dos tipos si
simples
mples que serão utilizados como
tipos de dados. A tabela está dividida em 4 colunas, a saber:
Campo: nome do tipo simples;

Tipo: tipo primitivo de dados utilizados pelo campo:
C: Caractere;
N: Número;
D: Data ou Data/Hora;
Descrição: descreve informações sobre o campo;
Tam.: tamanho do campo:
18
Quando for caracteres o tamanho define a quantidade máxima de
caracteres que o texto poderá ter;
Quando for numérico o tamanho pode ser representado das

seguintes formas:
-
significa que o número poderá ter, no máximo, 15 dígitos;
- Número fracionário, que define o total de dígitos e quantos deles serão designados
para a parte fracionária. Exem
15 dígitos sendo 2 deles a identificação da parte fracionária. A parte fracionária não é
obrigatória quando assim definido;
Quando for data, não haverá definição de tamanho.
Campo Tipo Descrição Tam.

TsNumeroNfse N Número da Nota Fiscal de Serviço Eletrônica, formado15
pelo ano com 04 (quatro) dígitos e um número seqüencial
com 11 posições Formato AAAANNNNNNNNNNN.
tsCodigoVerificacao C Código de verificação do número da nota 9
TsStatusRps N Código de status do RPS 1
1 Normal
2 Cancelado
TsStatusNfse N Código de status da NFS-e 1
1 Normal
2 Cancelado
tsNaturezaOperacao N Código de natureza da operação 2
1 Tributação no município
2 - Tributação fora do município
3 Isenção
4 - Imune
5 Exigibilidade suspensa por decisão judicial
6 Exigibilidade suspensa por procedimento

administrativo
19
tsRegimeEspecialTributacao N Código de identificação do regime especial de tributação 2
1 Microempresa municipal
2 - Estimativa
3 Sociedade de profissionais
4 Cooperativa
TsSimNao N Identificação de Sim/Não 1
1 - Sim
2 Não
TsQuantidadeRps N Quantidade de RPS do Lote 4

TsNumeroRps N Número do RPS 15
TsSerieRps C Número de série do RPS 5
TsTipoRps N Código de tipo de RPS 1
1 - RPS
2 Nota Fiscal Conjugada (Mista) Não utilizado em

Curitiba
3 Cupom Não utilizado em Curitiba

tsOutrasInformacoes C Informações adicionais ao documento. 255
TsValor N Valor monetário. 15,2
Formato: 0.00 (ponto separando casa decimal) Ex:

1.234,56 = 1234.56
tsItemListaServico C Código de item da lista de serviço 5

TsCodigoCnae N Código CNAE 7
tsCodigoTributacao C Código de Tributação 20
TsAliquota N Alíquota. Valor percentual. Formato: 0.0000 5,4
Ex: 1% = 0.01
25,5% = 0.255
100% = 1.0000 ou 1
tsDiscriminacao C Discriminação do conteúdo da NFS-e 2000

tsCodigoMunicipioIbge N Código de identificação do município conforme tabela do 7
IBGE
tsIncricaoMunicipal C Número de inscrição municipal 15
tsRazaoSocial C Razão Social do contribuinte 115
tsNomeFantasia C Nome fantasia 60
TsCnpj C Número CNPJ 14
tsEndereco C Endereço 125
tsNumeroEndereco C Número do endereço 10
tsComplementoEndereco C Complemento de endereço 60
tsBairro C Bairro 60
tsUf C Sigla da unidade federativa 2
tsCep N Número do CEP 8
tsEmail C E-mail 80
tsTelefone C Telefone 11
TsCpf C Número de CPF 11
20
tsIndicacaoCpfCnpj N Indicador de uso de CPF ou CNPJ 1
1 CPF
2 CNPJ
3 Não Informado
tsCodigoObra C Código de Obra 15

tsArt C Código ART 15
tsNumeroLote N Número do Lote de RPS 15
TsNumeroProtocolo C Número do protocolo de recebimento do RPS 50
tsSituacaoLoteRps N Código de situação de lote de RPS 1
1 Não Recebido
2 Não Processado
3 Processado com Erro
4 Processado com Sucesso
tsCodigoMensagemAlerta C Código de mensagem de retorno de serviço. 4

TsDescricaoMensagemAlerta C Descrição da mensagem de retorno de serviço. 200
TsCodigoCancelamentoNfse C Código de cancelamento com base na tabela de 4
tsIdTag C Atributo de identificação da tag a ser assinada no 255

documento XML
tsNumeroDeducao N Numero da dedução gerada pelo modulo de 19
deduções
A seguir serão detalhadas as tabelas de cada tipo composto e seus campos. A tabela
está dividida da seguinte forma:
(1)
(2)
Nome Tipo Ocorrência Descrição
(3) (4) (5) (6) (7)
(4) (5) (6) (7)
1. Nome do tipo complexo;

2. Descrição do tipo complexo;
3. Identifica se a seqüência de campos fará parte de uma escolha (Choice);
4. Nome do campo que faz parte do tipo complexo;
5. Tipo do campo, que pode ser de um tipo simples ou complexo;
6. Quantas vezes o campo se repete na estrutura de dados:
a. -
21
7. Descrição do campo.
22
TcCpfCnpjNúmero de CPF ou CNPJ
Choice Cpf tsCpf 1-1 Número do Cpf
Cnpj tsCnpj 1-1 Número do Cnpj
TcEndereco
Representação completa do endereço
Endereco tsEndereco 0-1 Endereço
Numero tsNumeroEndereco 0-1 Número do endereço
Complemento tsComplementoEndereco 0-1 Complemento do Endereço
Bairro tsBairro 0-1 Nome do bairro
CodigoMunicipio tsCodigoMunicipioIbge 0-1 Código da cidade
Uf tsUf 0-1 Sigla do estado
Cep tsCep 0-1 CEP da localidade
TcContato
Representa forma de contato com a pessoa (física/jurídica)
Telefone tsTelefone 0-1
Email tsEmail 0-1
tcIdentificacaoOrgaoGerador
Representa dados para identificação de órgão gerador
CodigoMunicipio tsCodigoMunicipioIbge 1-1
Uf tsUf 1-1
tcIdentificacaoRps
Dados de identificação do RPS
Numero tsNumeroRps 1-1
Serie tsSerieRps 1-1
Tipo tsTipoRps 1-1
tcIdentificacaoPrestador
Representa dados para identificação do prestador de serviço
Cnpj tsCnpj 1-1
InscricaoMunicipal tsInscricaoMunicipal 0-1
tcIdentificacaoTomador
Representa dados para identificação do tomador de serviço
CpfCnpj tcCpfCnpj 0-1
tcDadosTomador
Representa dados do tomador de serviço
IdentificacaoTomador TcIdentificacaoTomador 0-1
RazaoSocial TsRazaoSocial 0-1

Endereco TcEndereco 0-1
Contato TcContato 0-1
TcIdentificacaoIntermediarioServico
Representa dados para identificação de intermediário do serviço
23
RazaoSocial tsRazaoSocial 1-1
CpfCnpj tcCpfCnpj 1-1
TcValores
Representa um conjunto de valores que compõe o documento fiscal
ValorServicos tsValor 1-1
ValorDeducoes tsValor 0-1
NumeroDeducao tsNumeroDeducao 0-1
ValorPis tsValor 0-1
ValorCofins tsValor 0-1
ValorInss tsValor 0-1
ValorIr tsValor 0-1
ValorCsll tsValor 0-1
IssRetido tsSimNao 1-1
ValorIss tsValor 0-1
OutrasRetencoes tsValor 0-1
BaseCalculo tsValor 1-1 (Valor dos serviços - Valor das
deduções - descontos incondicionados)
Aliquota tsAliquota 0-1

ValorLiquidoNfse tsValor 0-1 (ValorServicos - ValorPIS -
ValorCOFINS - ValorINSS - ValorIR -
ValorCSLL - OutrasRetençoes -
ValorISSRetido -
DescontoIncondicionado -
DescontoCondicionado)
ValorIssRetido tsValor 0-1
DescontoCondicionado tsValor 0-1
DescontoIncondicionado tsValor 0-1
TcDadosServico
Representa dados que compõe o serviço prestado
Valores tcValores 1-1
ItemListaServico tsItemListaServico 1-1
CodigoCnae tsCodigoCnae 0-1
CodigoTributacaoMunicipio tsCodigoTributacao 0-1
Discriminacao tsDiscriminacao 1-1
CodigoMunicipio tsCodigoMunicipioIbge 1-1
tcDadosConstrucaoCivil
Representa dados para identificação de construção civil
CodigoObra tsCodigoObra 1-1
Art tsArt 1-1
tcDadosPrestador
Representa dados do prestador do serviço
IdentificacaoPrestador tcIdentificacaoPrestador 1-1
RazaoSocial tsRazaoSocial 1-1
NomeFantasia tsNomeFantasia 0-1
Endereco tcEndereco 1-1
Contato tcContato 0-1
TcInfRps
Representa dados informativos do Recibo Provisório de Serviço (RPS)
Id tsIdTag Identificador da TAG

IdentificacaoRps TcIdentificacaoRps 1-1
24
DataEmissao Datetime 1-1
NaturezaOperacao TsNaturezaOperacao 1-1
RegimeEspecialTributacao TsRegimeEspecialTributacao 0-1
OptanteSimplesNacional TsSimNao 1-1
IncentivadorCultural TsSimNao 1-1
Status TsStatusRps 1-1
RpsSubstituido TcIdentificacaoRps 0-1
Servico TcDadosServico 1-1
Prestador TcIdentificacaoPrestador 1-1
Tomador TcDadosTomador 1-1
IntermediarioServico tcIdentificacaoIntermediarioServico 0-1
ConstrucaoCivil TcDadosContrucaoCivil 0-1
TcRps
Representa a estrutura do Recibo Provisório de Serviço (RPS) assinada
InfRps tcInfRps 1-1
Signature dsig:Signature 0-1
tcIdentificacaoNfse
Representa dados que identificam uma Nota Fiscal de Serviços Eletrônica
Numero tsNumeroNfse 1-1
Cnpj tsCnpj 1-1
CodigoMunicipio tsCodigoMunicipioIbge
TcInfNfse
Representa os dados informativos da Nota Fiscal de Serviços Eletrônica
Numero tsNumeroNfse 1-1

CodigoVerificacao tsCodigoVerificacao 1-1
DataEmissao Datetime 1-1
IdentificacaoRps tcIdentificacaoRps 0-1
DataEmissaoRps Date 0-1
NaturezaOperacao tsNaturezaOperacao 1-1
RegimeEspecialTributacao tsRegimeEspecialTributacao 0-1
OptanteSimplesNacional TsSimNao 1-1
IncetivadorCultural TsSimNao 1-1
Competencia Date 1-1
NfseSubstituida tsNumeroNfse 0-1
OutrasInformacoes tsOutrasInformacoes 0-1
Servico tcDadosServico 1-1
ValorCredito TsValor 0-1
PrestadorServico tcDadosPrestador 1-1
TomadorServico tcDadosTomador 1-1
IntermediarioServico tcIdentificacaoIntermediarioServico 0-1
OrgaoGerador tcIdentificacaoOrgaoGerador 1-1
ConstrucaoCivil tcDadosContrucaoCivil 0-1
TcNfse
Representa a estrutura da Nota Fiscal de Serviços Eletrônica assinada
InfNfse tcInfNfse 1-1
Signature Dsig:Signature 1-2
tcInfPedidoCancelamento
Representa a estrutura de dados do pedido de cancelamento enviado pelo prestador ao cancelar uma
Nome Tipo Ocorrência Observação

Id tsIdTag Identificador da TAG a ser
assinada
25
IdentificacaoNfse tcIdentificacaoNfse 1-1
CodigoCancelamento tsCodigoCancelamentoNfse 1-1
TcPedidoCancelamento
Representa a estrutura de Pedido de Cancelamento da Nota Fiscal de Serviços Eletrônica assinada
InfPedidoCancelamento tcInfPedidoCancelamento 1-1
tcInfConfirmacaoCancelamento
Representa a estrutura de dados da confirmação de cancelamento Nota Fiscal de Serviços Eletrônica feito pelo Fisco
Municipal.
Sucesso boolean 1-1
DataHora datetime 1-1
TcConfirmacaoCancelamento
Representa a estrutura de Confirmação de Cancelamento da Nota Fiscal de Serviços Eletrônica assinada
Pedido TcPedidoCancelamento 1-1
InfConfirmacaoCancelamento tcInfConfirmacaoCancelamento 1-1
TcCancelamentoNfse
Representa a estrutura completa (pedido + confirmação) de cancelamento de NFS
NFS-e.
Confirmacao TcConfirmacaoCancelamento 1-1
TcInfSubstituicaoNfse
Representa os dados de registro de substituição de NFS
NFS-e.
assinada
NfseSubstituidora tsNumeroNfse 1-1
TcSubstituicaoNfse
Representa a estrutura de substituição de NFS
NFS-e.
SubstituicaoNfse tcInfSubstituicaoNfse 1-1
Signature dsig:Signature 1-2
TcCompNfse
Representa a estrutura de compartilhamento de dados de uma NFS
NFS-e.
Nfse tcNfse 1-1
NfseCancelamento tcCancelamentoNfse 0-1
NfseSubstituicao tcSubstituicaoNfse 0-1
tcMensagemRetorno
Representa a estrutura de mensagem de retorno de serviço.
Codigo TsCodigoMensagemAlerta 1-1
Mensagem tsDescricaoMensagemAlerta 1-1
Correcao tsDescricaoMensagemAlerta 0-1
26
MensagemRetorno tcMensagemRetorno 1-N
tcMensagemRetornoLote
Representa a estrutura de mensagem de retorno de serviço.
IdentificacaoRps TcIdentificacaoRps 1-1
Codigo TsCodigoMensagemAlerta 1-1
Mensagem tsDescricaoMensagemAlerta 1-1
tcLoteRps
assinada
NumeroLote TsNumeroLote 1-1
Cnpj TsCnpj 1-1
InscricaoMunicipal TsInscricaoMunicipal 1-1
QuantidadeRps TsQuantidadeRps 1-1
ListaRps 1-1
Rps TcRps 1-N
A seguir estão os serviços disponíveis, conforme descritos no item 3.1, no WebService

e seus XML Schema. O XML Schema define a estrutura e formatação do arquivo XML
que conterá os dados a serem trafegados. Esses documentos serão enviados de forma
textual (como uma string) como parâmetros do serviço oferecido pelo Web Service,
como descrito em 3.2.1.
As tabelas que detalham cada XML Schema estão divididas da seguinte forma:
(1)
# Nome Tipo Pai Ocorrência Observação
(2) (3) (4) (5) (6) (7)
(8)
(9)
1. Nome do arquivo XSD;

2. Número identificador do campo, quando este contiver subitens;
3. Nome do campo;
4. Nome do tipo do campo que pode ser tipo primitivo, simples ou complexo;
5. Indica quem é o campo pai, para definição da hierarquia;
6. Quantas vezes o campo se repete na estrutura de dados:
a. -
7. Descreve alguma observação pertinente;

8. Formato de grupo, utilizado para definição de uma escolha (ver próximo item);
27
9. Identifica os campos ou grupos que farão parte de uma escolha
(Choice).
Esse serviço será executado, inicialmente, através da chamada ao método

RecepcionarLoteRps, passando a mensagem XML como parâmetro com a estrutura
definida na tabela que segue.
servico_enviar_lote_rps_envio.xsd
1 EnviarLoteRpsEnvio 1-1
LoteRps TcLoteRps 1 1-1
Signature dsig:Signature 1 0-1
Em resposta a chamada do serviço será devolvida a estrutura definida na tabela a

seguir.
servico_enviar_lote_rps_resposta.xsd
1 EnviarLoteRpsResposta 1-1
NumeroLote tsNumeroLote 1
DataRecebimento Datetime 1
Protocolo tsNumeroProtocolo 1 1-1 Choice
2 ListaMensagemRetorno ListaMensagemRetorno 1 1-1
O lote será processado posteriormente, sendo o seu resultado disponibilizado para

consulta.
Esse serviço será executado através da chamada ao método

ConsultarSituacaoLoteRps, passando a mensagem XML como parâmetro com a
estrutura definida na tabela que segue.
servico_consultar_situacao_lote_rps_envio.xsd
1 ConsultarSituacaoLoteRpsEn vio 1-1
Prestador TcIdentificacaoPrestador 1 1-1

Protocolo TsNumeroProtocolo 1 1-1

seguir.
28
1 ConsultarSituacaoLoteRpsRe 1-1
sposta
NumeroLote tsNumeroLote 1 1-1 Choice
Situação tsSituacaoLoteRps 1

ConsultarNfsePorRps, passando a mensagem XML como parâmetro com a estrutura
servico_consultar_nfse_rps_envio.xsd
1 ConsultarNfseRpsEnvio
IdentificacaoRps tcIdentificacaoRps 1 1-1
Prestador tcIdentificacaoPrestador 1 1-1

seguir.
servico_consultar_nfse_rps_resposta.xsd
1 ConsultarNfseRpsResposta
CompNfse tcCompNfse 1 1-1 Choice
Esse serviço será executado através da chamada ao método ConsultarNfse, passando

a mensagem XML como parâmetro com a estrutura definida na tabela que segue.
servico_consultar_nfse_envio.xsd
1 ConsultarNfseEnvio 1-1
Prestador tcIdentificacaoPrestador 1 1-1
NumeroNfse tsNumeroNfse 1 0-1
2 PeriodoEmissao 1 0-1
DataInicial date 2 1-1
DataFinal date 2 1-1
Tomador tcIdentificacaoTomador 1 0-1
IntermediarioServico TcIdentificacaoIntermediar 1 0-1
ioServico

seguir.
servico_consultar_nfse_resposta.xsd
1 ConsultarNfseResposta 1-1
2 ListaNfse 1 1-1 Choice
CompNfse tcCompNfse 2
29
ConsultarLoteRps, passando a mensagem XML como parâmetro com a estrutura
servico_consultar_lote_rps_envio.xsd
1 ConsultarLoteRpsEnvio 1-1
Prestador TcIdentificacaoPrestador 1 1-1
Protocolo TsNumeroProtocolo 1 1-1

seguir.
servico_consultar_lote_rps_resposta.xsd
1 ConsultarLoteRpsResposta 1-1
2 ListaNfse 1 1-1
CompNfse tcCompNfse 2 1-N
3 ListaMensagemRetorno ListaMensagemRetorno 1 1-1 Choice
Esse serviço será executado através da chamada ao método CancelarNfse, passando

a mensagem XML como parâmetro com a estrutura definida na tabela que segue.
servico_cancelar_nfse_envio.xsd
1 CancelarNfseEnvio 1-1
Pedido TcPedidoCancelamento 1 1-1

seguir.
servico_cancelar_nfse_resposta.xsd
1 CancelarNfseResposta
Cancelamento TcCancelamentoNfse 1 1-1 Choice
As mensagens de erro definidas pela ABRASF podem ser encontradas na

Tabela de Erros, Alertas e Regras V1.1 na
endereço:
http://nota.curitiba.pr.gov.br/ no menu Dúvidas -> Saiba mais! ->

- Manuais ->
Manuais para o Prestador.
30
As mensagens de erro definidas pela ABRASF podem ser encontradas na
Tabela de Erros, Alertas e Regras V1.1 na Curitiba), disponibilizada
no endereço:

- Manuais ->
As regras específicas para o município de Curitiba podem ser encontradas na

planilha disponibilizada na página:

- Manuais ->
31

Nota Fiscal de Serviço Eletrônica (Nfs-E) Manual de Integração

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Nota Fiscal de Serviço Eletrônica (Nfs-E) Manual de Integração

Enviado por

Direitos autorais:

Formatos disponíveis

NOTA FISCAL DE SERVIÇO

A NFS-e somente será gerada através dos services informatizados disponibilizados

Esse serviço compreende a recepção do Lote de RPS, a resposta com o número do

Passos para execução

2. A requisição é recebida pelo servidor do Web Service que grava as informações

Esse serviço efetua a consulta da situação de um Lote de RPS já enviado.

3. O Web Service retorna uma mensagem com o resultado do processamento do

Esse serviço efetua a consulta de uma NFS

Esse serviço permite ao contribuinte obter as NFS

Passos para execução

2. A requisição é recebida pelo servidor do Web Service, que verifica os dados

Esse serviço permite a obtenção de determinada NFS

Passos para execução

Esse serviço permite o cancelamento direto de uma NFS

Passos para execução

2. A requisição é recebida pelo servidor do Web Service, que verifica os dados

3. O Web Service retorna uma mensagem c o m o resultado do processamento

métodos disponíveis com a passagem de mais de um parâmetro. Para descrever os

Os certificados digitais utilizados no sistema de Notas Fiscais de Serviço

As mensagens enviadas aos serviços disponibilizados pela Prefeitura de

O Projeto NFS-e utiliza um subconjunto do padrão de assinatura XML definido pelo

# Campo Elemento Pai Tipo Ocorrênci Descrição

XS08 Reference G XS03 1-1 Grupo do Método de Reference

A forma de conferência da LCR pode ser feita de 2 (duas) maneiras: On

Para garantir a autenticidade dos dados gerados, algumas informações deverão

O RPS, pelo contribuinte, antes do envio do mesmo através do Lote de RPS;

Abaixo, o leiaute da Área de Cabeçalho padrão:

Versão A 1 N 1-1 4 Versão do leiaute.

versão do leiaute XML da estrutura

O campo versaoDados deve conter a informação da versão do leiaute da estrutura

Para garantir minimamente a integridade das informações prestadas e a correta

<Nome do Arquivo>_v<Número da Versão>.xsd

A forma de processamento das solicitações de serviços no projeto Nota Fiscal de

As solicitações de serviços de implementação síncrona são processadas

Abaixo, o fluxo simplificado de funcionamento:

As solicitações de serviços de implementação assíncrona são processadas de forma

Abaixo, o fluxo simplificado de funcionamento:

Etapas do processo ideal: Solicitação e processamento:

T = caractere de formatação que deve existir separando a data da hora

Valores Decimais Formato: 0.00

Valores Percentuais Formato 0.0000

Para reduzir o tamanho final do arquivo XML da NFS

não incluir "zeros não significativos" para campos numéricos;

não incluir "espaços" no início ou no final de campos numéricos e

não incluir comentários no arquivo XML;

não incluir anotação e documentação no arquivo XML (TAG annotation e

não incluir caracteres de formatação no arquivo XML ("line-feed",

As TAGs que permitirem valores nulos devem ser omitidas da estrutura

Campo: nome do tipo simples;

Quando for numérico o tamanho pode ser representado das

Campo Tipo Descrição Tam.

tsCodigoVerificacao C Código de verificação do número da nota 9

TsStatusRps N Código de status do RPS 1

TsStatusNfse N Código de status da NFS-e 1

tsNaturezaOperacao N Código de natureza da operação 2

2 - Tributação fora do município

5 Exigibilidade suspensa por decisão judicial

6 Exigibilidade suspensa por procedimento

TsSimNao N Identificação de Sim/Não 1

TsQuantidadeRps N Quantidade de RPS do Lote 4

2 Nota Fiscal Conjugada (Mista) Não utilizado em

3 Cupom Não utilizado em Curitiba

Formato: 0.00 (ponto separando casa decimal) Ex: