NOTA FISCAL DE SERVIO

ELETRNICA (NFS-e)

Manual de Integrao
Verso 1.3

SUMRIO
1 INTRODUO

2 CONSIDERAES INICIAIS

2.1 NOTA FISCAL DE SERVIOS ELETRNICA - NFS-E

2.2 RECIBO PROVISRIO DE SERVIO - RPS
3 ARQUITETURA DE COMUNICAO COM O CONTRIBUINTE
3.1
3.1.1
3.1.2
3.1.3
3.1.4
3.1.5
3.1.6
3.2
3.2.1
3.2.2
3.2.3
3.2.4
3.2.5
3.3
3.3.1
3.3.2
3.3.3
3.3.4

MODELO CONCEITUAL
Recepo e Processamento de Lote de RPS
Consulta de Situao de Lote de RPS
Consulta de NFS-e por RPS
Consulta de Lote de RPS
Consulta de NFS-e
Cancelamento de NFS-e
PADRES TCNICOS
Padro de Comunicao
Padro de Certificado Digital
Padro de Assinatura Digital
Validao de Assinatura Digital pelo Sistema NFS-e
Uso de Assinatura com Certificado Digital
PADRO DAS MENSAGENS XML
rea do Cabealho
Validao da estrutura das Mensagens XML
Schemas XML (arquivos XSD)
Verso dos Schemas XML

4 ESTRUTURA DE DADOS DO WEB SERVICE

4.1
4.1.1
4.1.2
4.2
4.3
4.4
4.5
4.5.1
4.5.2
4.5.3
4.5.4
4.5.5
4.5.6

MODELO OPERACIONAL
Servios Sncronos
Servios Assncronos
FORMATOS E PADRES UTILIZADOS
TIPOS SIMPLES
TIPOS COMPLEXOS
SERVIOS
Recepo de Lote de RPS
Consulta de Situao de Lote de RPS
Consulta de NFS-e por RPS
Consulta de NFS-e
Consulta de Lote de RPS
Cancelamento NFS-e

5
5
6
6
6
6
7
8
8
9
10
10
11
11
13
13
14
14
14
15
15
16
16
16
17
18
19
21
26
27
27
28
28
29
29
2

5 ANEXOS
5.1 TABELA DE ERROS
5.2 REGRAS ESPECFICAS DE CURITIBA

30
30
35

1 INTRODUO
Este manual tem como objetivo apresentar as especificaes e critrios tcnicos
necessrios para utilizao do Web Service disponibilizado pela Prefeitura Municipal de
Curitiba, conforme modelo ABRASF - Associao Brasileira de Secretrios e Dirigentes
das Finanas dos Municpios das Capitais, para as empresas prestadoras e/ou
tomadoras de servios.
Atravs do Web Service as empresas podero integrar seus prprios sistemas de
informaes com o Sistema da Prefeitura. Desta forma, consegue-se automatizar o
processo de gerao, consulta e cancelamento de NFS-e.

2 CONSIDERAES INICIAIS

2.1 NOTA FISCAL DE SERVIOS ELETRNICA - NFS-E

A Nota Fiscal de Servios Eletrnica (NFS-e) um documento de existncia
exclusivamente digital, gerado e armazenado eletronicamente pela Prefeitura ou por
outra entidade conveniada, para documentar as operaes de prestao de servios.
A gerao da NFS-e ser feita, automaticamente, por meio de servios informatizados,
disponibilizados aos contribuintes. Para que sua gerao seja efetuada, dados que a
compem sero informados, analisados, processados, validados e, se corretos, geraro
o documento.
A responsabilidade pelo cumprimento da obrigao acessria de emisso da NFS-e e
pelo correto fornecimento dos dados Prefeitura, para a gerao da mesma, do
contribuinte.

2.2 RECIBO PROVISRIO DE SERVIO - RPS

A NFS-e somente ser gerada atravs dos services informatizados disponibilizados
pela Prefeitura. Esse tipo de servio seguido de alguns riscos inerentes ininterrupta
disponibilidade, podendo, portanto, em alguns momentos tornar-se indisponvel.
Visando manter as atividades dos contribuintes ininterruptas, independente de os
servios informatizados disponibilizados pela Prefeitura Municipal de Curitiba estarem
disponveis, foi criado o Recibo Provisrio de Servios (RPS), que um documento de
posse e responsabilidade do contribuinte, que dever ser gerado manualmente ou por
alguma aplicao local, possuindo uma numerao seqencial crescente e devendo ser
convertido em NFS-e no prazo estipulado pela legislao tributria municipal.

3 ARQUITETURA DE COMUNICAO COM O CONTRIBUINTE

3.1 MODELO CONCEITUAL

Atravs do Web Service, o Sistema de Notas Fiscais de Servio Eletrnicas da
Prefeitura de Curitiba disponibilizar servios que podero ser acessados pelos
sistemas dos contribuintes. A seguir, esto resumidos os servios disponveis e suas
respectivas funcionalidades bsicas.

3.1.1 Recepo e Processamento de Lote de RPS

Esse servio compreende a recepo do Lote de RPS, a resposta com o nmero do
protocolo gerado para esta transao e o processamento do lote. Quando efetuada a
recepo, o Lote entrar na fila para processamento posterior onde sero feitas as
validaes necessrias e gerao das NFS-e.

Passos para execuo

1. A aplicao acessa o servio de Recepo e Processamento de Lote de RPS
enviando o lote (fluxo b).
2. A requisio recebida pelo servidor do Web Service que grava as informaes
recebidas e gera o nmero de protocolo de recebimento (fluxo c).
3. O Web Service retorna uma mensagem com oresultado do processamento do
servio (fluxo d).

3.1.2 Consulta de Situao de Lote de RPS

Esse servio efetua a consulta da situao de um Lote de RPS j enviado.

Passos para execuo

1. A aplicao acessa o servio de Consulta de Situao de Lote de RPS e submete
os dados para processamento (fluxo 2.b).
2. A requisio recebida pelo servidor do Web Service, que verifica os dados
preenchidos e identifica o status do lote (fluxox 2.c e 2.d).
3. O Web Service retorna uma mensagem com o resultado do processamento do
servio (fluxo 2.e).

3.1.3 Consulta de NFS-e por RPS

Esse servio efetua a consulta de uma NFS-e a partir do nmero de RPS que a gerou.

Passos para execuo

1. A aplicao acessa o servio de Consulta de NFS-e por RPS e submete
os dados para processamento (fluxo 2.b).
2. A requisio recebida pelo servidor do Web Service, que verifica os dados
preenchidos e identifica a NFS-e correspondente (fluxos 2.c e 2.d).
3. O Web Service retorna uma mensagem com o resultado do processamento do
servio (fluxo 2.e).

3.1.4 Consulta de Lote de RPS

Esse servio permite ao contribuinte obter as NFS-e que foram geradas a partir do
Lote de RPS enviado, quando o processamento ocorrer sem problemas; ou obter a
lista de erros e/ou inconsistncias encontradas nos RPS.
Na validao 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.

Passos para execuo

1. A aplicao acessa o servio de Consulta de Lote de RPS e submete os dados
para processamento (fluxo b).
2. A requisio recebida pelo servidor do Web Service, que verifica os dados
preenchidos e identifica as NFS-e correspondentes (fluxos c e d).
3. O Web Service retorna uma mensagem (a estrutura com a lista da NFS- e geradas
ou as mensagens de erro) com o resultado do processamento do servio (fluxo e).

3.1.5 Consulta de NFS-e

Esse servio permite a obteno de determinada NFS-e j gerada.

XML de Envio validado pelo arquivo: servico_consultar_nfse_envio.xsd

XML de Resposta validado pelo arquivo: servico_consultar_nfse_resposta.xsd

Passos para execuo

1. A aplicao acessa o servio de Consulta de NFS-e e submete os dados para
processamento ().
2. A requisio recebida pelo servidor do Web Service, que verifica os dados
preenchidos e identifica as NFS-e correspondentes.
3. O Web Service
retorna
do processamento do servio.

uma

mensagem

com

resultado

3.1.6 Cancelamento de NFS-e

Esse servio permite o cancelamento direto de uma NFS-e sem substituio da
mesma por outra.

Passos para execuo

1. A aplicao acessa o servio de Cancelamento de NFS-e e submete os dados
para processamento (fluxo 2.b).
2. A requisio recebida pelo servidor do Web Service, que verifica os dados
preenchidos, identifica a NFS-e correspondente e efetua o seu cancelamento (fluxo
2.c).
3. O Web Service retorna uma mensagem com
do servio (fluxo 2.d).

o resultado do processamento

3.2

PADRES TCNICOS

3.2.1 Padro de Comunicao

O meio fsico de comunicao utilizado entre os sistemas de informao dos
contribuintes e o Sistema de Notas Fiscais de Servio Eletrnicas da Prefeitura de
Curitiba ser a Internet, com o uso do protocolo SSL, que alm de garantir um duto
de comunicao seguro na Internet, permite a identificao do servidor e do cliente
atravs de certificados digitais, eliminando a necessidade de identificao do usurio
atravs de nome ou cdigo de usurio e senha.
O modelo de comunicao segue o padro de Web Services definido pelo WS-I Basic
Profile.
A troca de mensagens entre o Web Service do Sistema de Notas Fiscais de Servio
Eletrnicas da Prefeitura de Curitiba e o sistema do contribuinte ser realizada no
padro SOAP, com troca de mensagens XML no padro Style/Enconding:
Document/Literal, wrapped. A opo wrapped representa a chamada aos
mtodos disponveis com a passagem de mais de um parmetro. Para descrever os
servios disponibilizados, ser utilizado um documento WSDL (Web Service
Description Language). O WSDL o padro recomendado para descrio de servios
SOAP.

10

As chamadas aos servios sero feitas enviando como parmetro um

documento XML a ser processado pelo sistema. Esse documento no far
parte da descrio do servio (arquivo WSDL), e o formato do XML
correspondente ao servio dever ser consultado nesse manual de integrao,
seo 4.5.

3.2.2 Padro de Certificado Digital

Os certificados digitais utilizados no sistema de Notas Fiscais de Servio
Eletrnicas, da Prefeitura de Curitiba, sero emitidos por
Autoridade
Certificadora credenciada pela Infra-estrutura de Chaves Pblicas Brasileira
ICP-Brasil, de pessoa fsica ou jurdica, dos tipos A1, A3 ou certificado de
servidor (hbrido).
Para a assinatura digital dos documentos envolvidos aceitar-se- que o
certificado digital seja de quaisquer dos estabelecimentos da empresa.
Os certificados digitais sero exigidos em 2 (dois) momentos distintos para a
integrao entre o sistema do contribuinte e o Web Service da Prefeitura de
Curitiba:
Assinatura de Mensagens: O certificado digital utilizado para essa funo
dever conter o CNPJ do estabelecimento emissor da NFS-e ou o CNPJ do
estabelecimento matriz. O certificado digital dever ter o uso da chave
previsto para a funo de assinatura digital, respeitando a Poltica do
Certificado.
Transmisso (durante a transmisso das mensagens entre os servidores do
contribuinte e
os
servios
disponibilizados
pela Prefeitura de
Curitiba): O certificado digital utilizado para identificao do aplicativo do
contribuinte dever conter o CNPJ do responsvel pela transmisso das
mensagens, mas no necessita ser o mesmo CNPJ do estabelecimento
emissor da NFS-e, devendo ter a extenso extended Key Usage com
permisso de "Autenticao Cliente".

3.2.3 Padro de Assinatura Digital

As mensagens enviadas aos servios disponibilizados pela Prefeitura de
Curitiba so documentos eletrnicos elaborados no padro XML e devem ser
assinados digitalmente com um certificado digital que contenha o CNPJ do
estabelecimento matriz ou o CNPJ do estabelecimento emissor da NFS-e
objeto do pedido.
Para garantir minimamente a integridade das informaes prestadas e a
correta formao dos arquivos XML, o contribuinte dever submeter as
mensagens XML para validao pela linguagem de Schema do XML (XSD
XML Schema Definition), disponibilizada pela Prefeitura de Curitiba antes de
seu envio.

11

Os elementos abaixo esto presentes dentro do Certificado do contribuinte

tornando desnecessria a sua representao individualizada no arquivo XML.
Portanto, o arquivo XML no deve conter os elementos:
<X509SubjectName>
<X509IssuerSerial>
<X509IssuerName>
<X509SerialNumber>
<X509SKI>

Deve-se evitar o uso das TAGs abaixo, pois as informaes sero obtidas a partir do
Certificado do emitente:
<KeyValue>
<RSAKeyValue>
<Modulus>
<Exponent>

O Projeto NFS-e utiliza um subconjunto do padro de assinatura XML definido pelo

http://www.w3.org/TR/xmldsig-core/, que tem o seguinte leiaute:

#
XS01
XS02
XS03
XS04
XS05

Campo
Signature
Id
SignedInfo
CanonicalizationMethod
Algorithm

Elemento
Raiz
A
G
G
A

Pai

Tipo

Ocorrnci
a
1-1
1-1
1-1
1-1

XS01
XS01
XS03
XS04

XS06
XS07

SignatureMethod
Algorithm

G
A

XS03
XS06

XS08
XS09
XS10
XS11

Reference
URI
Transforms
Unique_Transf_Alg

G
A
G
RC

XS03
XS08
XS08
XS10

Grupo da Informao da assinatura

Grupo do Mtodo de Canonicalizao
Atributo Algorithm de CanonicalizationMethod:

1-1
1-1

http://www.w3.org/TR/2001/REC-xml-c14nGrupo do Mtodo de Assinatura

Atributo Algorithm de SignedInfo:

XS12
XS13

Transform
Algorithm

G
A

XS10
XS12

1-1
1-1
1-1
1-1
2-2
1-1

Descrio

http://www.w3.org/2000/09/xmldsig#rsa-sha1
Grupo do Mtodo de Reference
Atributo URI da tag Reference
Grupo do algorithm de Transform
Regra para o atributo Algorithm do Transform ser
nico
Grupo de Transform
Atributos vlidos Algorithm do Transform:
http://www.w3.org/TR/2001/REC-xml-c14n-

XS14
XS15
XS16

Xpath
DigestMethod
Algorithm

E
G
A

XS12
XS08
XS15

XS17
XS18
XS19

DigestValue
SignatureValue
KeyInfo

E
G
G

XS08
XS01
XS01

0-N
1-1
1-1

20010315
http://www.w3.org/2000/09/xmldsig#envelopedXpath
Grupo do Mtodo de DigestMethod
Atributo Algorithm de DigestMethod:

1
1-1
1-1

Digest Value (Hash SHA-1 Base64)

Grupo do Signature Value
Grupo do KeyInfo

12

XS20
XS21

X509Data
X509Certificate

G
E

XS19
XS20

1-1
1-1

Grupo X509
Certificado Digital x509 em Base64b

3.2.4 Validao de Assinatura Digital pelo Sistema NFS-e

Para a validao da assinatura digital, seguem as regras que sero adotadas pela
Prefeitura de Curitiba:
1. Extrair a chave pblica do certificado;
2. Verificar o prazo de validade do certificado utilizado;
3. Montar e validar a cadeia de confiana dos certificados validando tambm 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 (no sero aceitos certificados do tipo S);
5. Garantir que o certificado utilizado de um usurio final e no de uma
Autoridade Certificadora;
6. Adotar as regras definidas pelo RFC 3280 para LCRs e cadeia de confiana;
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 conferncia da LCR pode ser feita de 2 (duas) maneiras: On-line ou

Download peridico. As assinaturas
digitais das mensagens sero verificadas
considerando o horrio fornecido pelo Observatrio Nacional.

3.2.5 Uso de Assinatura com Certificado Digital

Para garantir a autenticidade dos dados gerados, algumas informaes devero
ser assinadas digitalmente. Abaixo segue as informaes que devero ser assinadas
e quem dever faz-lo em cada momento:
O RPS, pelo contribuinte, antes do envio do mesmo atravs 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 Aplicao On Line;
Pela prefeitura nos demais casos;
O Pedido de cancelamento da NFS-e, pelo contribuinte;
A Confirmao de cancelamento da NFS-e, pela prefeitura;
13

3.3

PADRO DAS MENSAGENS XML

A especificao adotada para as mensagens XML a recomendao W3C para XML

1.0, disponvel em www.w3.org/TR/REC-xml e a codificao dos caracteres ser em
UTF-8.
As chamadas dos Web Services disponibilizados pela Prefeitura de Curitiba e os
respectivos resultados do processamento so realizadas atravs das mensagens
com o seguinte padro:
rea de Cabealho estrutura XML padro para todas as mensagens de chamada e
retorno de resultado dos Web Services disponibilizados pela Prefeitura de Curitiba,
que contm os dados de controle da mensagem. A rea de cabealho est sendo
utilizada para armazenar a verso do leiaute da estrutura XML informado na rea de
dados.
rea de Dados estrutura XML varivel definida na documentao do Web Service
acessado.

3.3.1 rea do Cabealho

Abaixo, o leiaute da rea de Cabealho padro:
#
1

Nome
cabecalho

Elemento
G

Pai Tipo

Ocorrncia
1-1

Tamanho

Descrio
TAG raiz do cabealho da

Verso
versaoDados

A
E

1
1

1-1
1-1

4
4

Verso do leiaute.
O contedo deste campo indica a

N
N

verso do leiaute XML da estrutura

O campo versaoDados deve conter a informao da verso do leiaute da estrutura

XML armazenada na rea de dados da mensagem.
A estrutura XML armazenada na rea de dados est definida na documentao do
Web Service acessado.

3.3.2 Validao da estrutura das Mensagens XML

Para garantir minimamente a integridade das informaes prestadas e a correta
formao das mensagens XML, o contribuinte dever submeter cada uma das
mensagens XML de pedido de servio para validao pelo seu respectivo arquivo
XSD (XML Schema Definition, definio de esquemas XML) antes de seu envio.
Neste manual utilizaremos a nomenclatura Schema XML para nos referir a arquivo
XSD.
Um Schema XML define o contedo de uma mensagem XML, descrevendo os
seus atributos, elementos e a sua organizao, alm de estabelecer regras de
preenchimento de contedo e de obrigatoriedade de cada elemento ou grupo de
informao.
14

A validao da estrutura da mensagem XML realizada por um analisador sinttico

(parser) que verifica se a mensagem XML atende as definies e regras de seu
respectivo Schema XML.
Qualquer divergncia da estrutura da mensagem XML em relao ao seu respectivo
Schema XML, provoca um erro de validao do Schema XML. Neste caso o contedo
da mensagem XML de pedido do servio no poder ser processado.
A primeira condio para que a mensagem XML seja validada com sucesso que ela
seja submetida ao Schema XML correto.
Assim, os sistemas de informao dos contribuintes devem estar preparados para
gerar mensagens XML em seus respectivos Schemas XML em vigor.

3.3.3 Schemas XML (arquivos XSD)

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 Boa Nota da Prefeitura de Curitiba.

3.3.4 Verso dos Schemas XML

Toda mudana de layout das mensagens XML do Web Service implica na atualizao
do seu respectivo Schema XML.
A identificao da verso dos Schemas XML ser realizada com o acrscimo do
nmero da verso com dois dgitos no nome do arquivo XSD precedida da literal _v,
como segue:
<Nome do Arquivo>_v<Nmero da Verso>.xsd
Exemplo: EnvioLoteRps_v01.xsd
A maioria dos Schemas XML definidos para a utilizao do Web Service do Sistema
de Notas Fiscais de Servio Eletrnicas da Prefeitura de Curitiba utilizam as
definies de tipos simples ou tipos complexos que esto definidos em outros
Schemas XML, nestes casos, a modificao de verso do Schema bsico ser
repercutida no Schema principal.
As modificaes de layout das mensagens XML do Web Service podem ser causadas
por necessidades tcnicas ou em razo da modificao de alguma legislao. As
modificaes decorrentes de alterao da legislao devero ser implementadas nos
prazos previstos no ato normativo que introduziu a alterao. As modificaes de
ordem tcnica sero divulgadas pela Prefeitura de Curitiba e podero ocorrer sempre
que se fizerem necessrias.

15

4 ESTRUTURA DE DADOS DO WEB SERVICE

Existir um nico Web Service com todos os servios apresentados no item
3.1. O fluxo de comunicao sempre iniciado pelo sistema do contribuinte atravs
do envio de uma mensagem XML ao Web Service com o pedido do servio desejado.

4.1 MODELO OPERACIONAL

A forma de processamento das solicitaes de servios no projeto Nota Fiscal de
Servios Eletrnica pode ser sncrona, caso o atendimento da solicitao de servio
seja realizada
na
mesma
conexo
ou
assncrona, quando o
processamento do servio solicitado no atendido na mesma conexo, devido
uma demanda
de
processamento
de grande quantidade de
informao. Nesta situao torna-se necessria a realizao de mais uma conexo
para a obteno do resultado do processamento.
As solicitaes de servios que exigem processamento intenso sero executadas de
forma assncrona e as demais solicitaes de servios de forma sncrona.
Assim, os servios da NFS-e sero implementados da seguinte forma:
Servio

Implementao

Recepo e Processamento de Lote de RPS

Assncrona

Consulta de Situao de Lote de RPS

Sncrona

Consulta de NFS-e por RPS

Sncrona

Consulta de Lote de RPS

Sncrona

Consulta de NFS-e

Sncrona

Cancelamento de NFS-e

Sncrona

4.1.1 Servios Sncronos

As solicitaes de servios de implementao sncrona so processadas
imediatamente e o resultado do processamento obtido em uma nica conexo.

Abaixo, o fluxo simplificado de funcionamento:

16

Etapas do processo ideal:

1. O aplicativo do contribuinte inicia a conexo enviando uma mensagem de
solicitao de servio para o Web Service;
2. O Web Service recebe a mensagem de solicitao de servio e encaminha ao
aplicativo da NFS-e que ir processar o servio solicitado;
3. O aplicativo da NFS-e recebe a mensagem de solicitao de servios 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 no exista outra mensagem, encerra a conexo.

4.1.2 Servios Assncronos

As solicitaes de servios de implementao assncrona so processadas de forma
distribuda por vrios processos e o resultado do processamento somente
obtido na segunda conexo.
Abaixo, o fluxo simplificado de funcionamento:

Etapas do processo ideal: Solicitao e processamento:

1. O aplicativo do contribuinte inicia a conexo enviando uma mensagem de
solicitao de servio para o Web Service de recepo de solicitao de servios;
2. O Web Service de recepo de solicitao de servios recebe a mensagem de
solicitao de servio e a coloca na fila de servios solicitados, acrescentando o
CNPJ do transmissor obtido do certificado digital do transmissor;
3. O Web Service de recepo de solicitao de servios retorna o protocolo
da solicitao de servio e a data e hora de gravao na fila de servios solicitados
ao aplicativo do contribuinte;

17

4. O aplicativo do contribuinte recebe o protocolo;

5. Na estrutura interna do aplicativo de NFS-e a solicitao de servios retirada da
fila de servios solicitados pelo aplicativo da NFS-e em momento especfico,
definido pela equipe tcnica da NFS-e;
6. O servio solicitado processado pelo aplicativo da NFS-e e o resultado do
processamento colocado na fila de servios processados;
Obteno do resultado do servio:
7. O aplicativo do contribuinte, atravs do protocolo recebido, envia uma consulta ao
servio que retornar o resultado do processamento daquele protocolo, iniciando uma
conexo com o Web Service;
8. O Web Service recebe a mensagem de consulta e localiza o resultado de
processamento da solicitao de servio;
9. O Web Service devolve o resultado do processamento ao aplicativo contribuinte;
10. O aplicativo do contribuinte recebe a mensagem de resultado
processamento e, caso no exista outra mensagem, encerra a conexo.

4.2

do

FORMATOS E PADRES UTILIZADOS

Abaixo segue algumas formataes de dados que devem ser seguidas para gerao
correta na estrutura dos arquivos.

Formato

Observao

Data (date)

Formato: AAAA-MM-DD
onde:

Data/Hora (datetime)

AAAA = ano com 4 caracteres MM = ms com 2 caracteres DD = dia com 2 caracteres

Formato AAAA-MM-DDTHH:mm:ss onde:
AAAA = ano com 4 caracteres MM = ms com 2 caracteres DD = dia com 2 caracteres
T = caractere de formatao 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)

No deve ser utilizado separador de milhar. O ponto (.) deve ser utilizado para separar a
parte inteira da fracionria.
Exemplo:

Valores Percentuais

48.562,250.0000
= 48562.25
Formato

(decimal)

O formato em percentual presume o valor percentual em sua forma fracionria, contendo 5

dgitos. O ponto (.) separa a parte inteira da fracionria.
Exemplo:
62% = 0.62

18

No deve ser inserido caractere no significativo para preencher o tamanho completo

do campo, ou seja, zeros antes de nmero ou espao em branco aps cadeia de
caracteres. A posio do campo definida na estrutura do documento XML atravs de
TAGs (<tag>contedo</tag>).
A regra constante do pargrafo anterior dever estender-se para os campos onde no
h
indicao de
obrigatoriedade
e
que, no
entanto,
seu
preenchimento
torna-se
obrigatrio por estar
condicionado legislao
especfica ou ao negcio do contribuinte. Neste caso, dever constar a TAG com o
valor correspondente e, para os demais campos, devero ser eliminadas as TAGs.

Para reduzir o tamanho final do arquivo XML da NFS-e alguns cuidados de

programao devero ser assumidos:

no incluir "zeros no significativos" para campos numricos;

no incluir "espaos" no incio ou no final de campos numricos e

alfanumricos;

no incluir comentrios no arquivo XML;

no incluir anotao e documentao no arquivo XML (TAG annotation e

TAG documentation);

no incluir caracteres de formatao no arquivo XML ("line-feed",

"carriage return", "tab", caractere de "espao" entre as TAGs).

As TAGs que permitirem valores nulos devem ser omitidas da estrutura

XML a ser enviada.

4.3 Tipos Simples

A seguir encontra-se a tabela com a lista dos tipos simples que sero 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: Nmero;

D: Data ou Data/Hora;

Descrio: descreve informaes sobre o campo;

Tam.: tamanho do campo:
19

Quando for caracteres o tamanho define a quantidade mxima de

caracteres que o texto poder ter;

Quando for numrico

seguintes formas:

tamanho

pode

ser

representado

das

- Nmero inteiro, que define o total de dgitos existente no nmero. Exemplo: 15

significa que o nmero poder ter, no mximo, 15 dgitos;
- Nmero fracionrio, que define o total de dgitos e quantos deles sero designados
para a parte fracionria. Exemplo: 15,2 significa que o nmero poder ter, no mximo,
15 dgitos sendo 2 deles a identificao da parte fracionria. A parte fracionria no
obrigatria quando assim definido;
Quando for data, no haver definio de tamanho.

Campo

Tipo

Descrio

TsNumeroNfse

Nmero da Nota Fiscal de Servio Eletrnica, formado 15

pelo ano com 04 (quatro) dgitos e um nmero seqencial
com 11 posies Formato AAAANNNNNNNNNNN.

Tam.

tsCodigoVerificacao

Cdigo de verificao do nmero da nota

TsStatusRps

Cdigo de status do RPS

1 Normal
2 Cancelado
TsStatusNfse

Cdigo de status da NFS-e

1 Normal
2 Cancelado
tsNaturezaOperacao

Cdigo de natureza da operao

1 Tributao no municpio
2 - Tributao fora do municpio
3 Iseno
4 - Imune
5 Exigibilidade suspensa por deciso judicial
6 Exigibilidade
administrativo

suspensa

por

procedimento

20

tsRegimeEspecialTributacao

Cdigo de identificao do regime especial de tributao 2

1 Microempresa municipal
2 - Estimativa
3 Sociedade de profissionais
4 Cooperativa

TsSimNao

Identificao de Sim/No

1 - Sim
2 No
TsQuantidadeRps
TsNumeroRps
TsSerieRps
TsTipoRps

N
N
C
N

Quantidade de RPS do Lote

Nmero do RPS
Nmero de srie do RPS
Cdigo de tipo de RPS

4
15
5
1

1 - RPS
2 Nota Fiscal Conjugada (Mista) No utilizado em
Curitiba
3 Cupom No utilizado em Curitiba
tsOutrasInformacoes
TsValor

C
N

Informaes adicionais ao documento.

Valor monetrio.

255
15,2

Formato: 0.00 (ponto separando casa decimal) Ex:

1.234,56 = 1234.56
tsItemListaServico
TsCodigoCnae
tsCodigoTributacao
TsAliquota

C
N
C
N

1.000,00de= item
1000.00
Cdigo
da lista de servio
Cdigo CNAE
Cdigo de Tributao
Alquota. Valor percentual. Formato: 0.0000

5
7
20
5,4

Ex: 1% = 0.01
25,5% = 0.255
100% = 1.0000 ou 1

tsDiscriminacao
tsCodigoMunicipioIbge

C
N

tsIncricaoMunicipal
tsRazaoSocial
tsNomeFantasia
TsCnpj
tsEndereco
tsNumeroEndereco
tsComplementoEndereco
tsBairro
tsUf
tsCep
tsEmail
tsTelefone
TsCpf

C
C
C
C
C
C
C
C
C
N
C
C
C

Discriminao do contedo da NFS-e

2000
Cdigo de identificao do municpio conforme tabela do 7
IBGE
Nmero de inscrio municipal
15
Razo Social do contribuinte
115
Nome fantasia
60
Nmero CNPJ
14
Endereo
125
Nmero do endereo
10
Complemento de endereo
60
Bairro
60
Sigla da unidade federativa
2
Nmero do CEP
8
E-mail
80
Telefone
11
Nmero de CPF
11

21

tsIndicacaoCpfCnpj

Indicador de uso de CPF ou CNPJ

1 CPF
2 CNPJ
3 No Informado
tsCodigoObra
tsArt
tsNumeroLote
TsNumeroProtocolo
tsSituacaoLoteRps

C
C
N
C
N

Cdigo de Obra
Cdigo ART
Nmero do Lote de RPS
Nmero do protocolo de recebimento do RPS
Cdigo de situao de lote de RPS

15
15
15
50
1

1 No Recebido
2 No Processado
3 Processado com Erro
4 Processado com Sucesso

tsCodigoMensagemAlerta
TsDescricaoMensagemAlerta
TsCodigoCancelamentoNfse

C
C
C

Cdigo de mensagem de retorno de servio.

Descrio da mensagem de retorno de servio.
Cdigo de cancelamento com base na tabela de

4
200
4

tsIdTag

Erros e alertas.
Atributo
de identificao da tag a ser assinada no 255
documento XML

4.4 Tipos Complexos

A seguir sero detalhadas as tabelas de cada tipo composto e seus campos. A tabela
est dividida da seguinte forma:

(1)
(2)
Nome
(3)

(4)
(4)

Tipo
(5)
(5)

Ocorrncia
(6)
(6)

Descrio
(7)
(7)

1. Nome do tipo complexo;

2. Descrio do tipo complexo;
3. Identifica se a seqncia 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. Formato: x-y onde x a quantidade mnima e y a quantidade mxima. Se a
quantidade mxima for indefinida, ser utilizado N no lugar do y;
7. Descrio do campo.
22

TcCpfCnpjNmero de CPF ou CNPJ

Nome
Choice
Cpf
Cnpj

Tipo
tsCpf
tsCnpj

Ocorrncia
1-1
1-1

Descrio
Nmero do Cpf
Nmero do Cnpj

TcEndereco
Representao completa do endereo
Nome
Endereco
Numero
Complemento
Bairro
CodigoMunicipio
Uf
Cep

Tipo
tsEndereco
tsNumeroEndereco
tsComplementoEndereco
tsBairro
tsCodigoMunicipioIbge
tsUf
tsCep

Ocorrncia
0-1
0-1
0-1
0-1
0-1
0-1
0-1

Descrio
Endereo
Nmero do endereo
Complemento do Endereo
Nome do bairro
Cdigo da cidade
Sigla do estado
CEP da localidade

TcContato
Representa forma de contato com a pessoa (fsica/jurdica)
Nome
Tipo
Telefone
tsTelefone
Email
tsEmail

Ocorrncia
0-1
0-1

Descrio

tcIdentificacaoOrgaoGerador
Representa dados para identificao de rgo gerador
Nome
Tipo
CodigoMunicipio
tsCodigoMunicipioIbge
Uf
tsUf

Ocorrncia
1-1
1-1

Descrio

tcIdentificacaoRps
Dados de identificao do RPS
Nome
Numero
Serie
Tipo

Tipo
tsNumeroRps
tsSerieRps
tsTipoRps

Ocorrncia
1-1
1-1
1-1

Descrio

tcIdentificacaoPrestador
Representa dados para identificao do prestador de servio
Nome
Tipo
Cnpj
tsCnpj
InscricaoMunicipal
tsInscricaoMunicipal

Ocorrncia
1-1
0-1

Descrio

Ocorrncia
0-1
0-1

Descrio

tcIdentificacaoTomador
Representa dados para identificao do tomador de servio
Nome
Tipo
CpfCnpj
tcCpfCnpj
InscricaoMunicipal
tsInscricaoMunicipal

tcDadosTomador
Representa dados do tomador de servio
Nome
Tipo
IdentificacaoTomador
TcIdentificacaoTomador

Ocorrncia
0-1

RazaoSocial
Endereco
Contato

0-1
0-1
0-1

TsRazaoSocial
TcEndereco
TcContato

Descrio

TcIdentificacaoIntermediarioServico
Representa dados para identificao de intermedirio do servio
Nome
Tipo

Ocorrncia

Descrio

23

RazaoSocial
CpfCnpj
InscricaoMunicipal

tsRazaoSocial
tcCpfCnpj
tsInscricaoMunicipal

1-1
1-1
0-1

TcValores
Representa um conjunto de valores que compe o documento fiscal
Nome
Tipo
Ocorrncia
ValorServicos
tsValor
1-1
ValorDeducoes
tsValor
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

Aliquota
ValorLiquidoNfse

tsAliquota
tsValor

0-1
0-1

ValorIssRetido
DescontoCondicionado
DescontoIncondicionado

tsValor
tsValor
tsValor

0-1
0-1
0-1

Descrio

(Valor dos servios - Valor das

dedues - descontos incondicionados)

(ValorServicos
ValorPIS
ValorCOFINS - ValorINSS - ValorIR
ValorCSLL - OutrasRetenoes
ValorISSRetido
DescontoIncondicionado
DescontoCondicionado)

TcDadosServico
Representa dados que compe o servio prestado
Nome
Tipo
Valores
tcValores
ItemListaServico
tsItemListaServico
CodigoCnae
tsCodigoCnae
CodigoTributacaoMunicipio
tsCodigoTributacao
Discriminacao
tsDiscriminacao
CodigoMunicipio
tsCodigoMunicipioIbge

Ocorrncia
1-1
1-1
0-1
0-1
1-1
1-1

Descrio

tcDadosConstrucaoCivil
Representa dados para identificao de construo civil
Nome
Tipo
CodigoObra
tsCodigoObra
Art
tsArt

Ocorrncia
1-1
1-1

Descrio

tcDadosPrestador
Representa dados do prestador do servio
Nome
Tipo
IdentificacaoPrestador
tcIdentificacaoPrestador
RazaoSocial
tsRazaoSocial
NomeFantasia
tsNomeFantasia
Endereco
tcEndereco
Contato
tcContato

Ocorrncia
1-1
1-1
0-1
1-1
0-1

Descrio

TcInfRps
Representa dados informativos do Recibo Provisrio de Servio (RPS)
Nome
Tipo

Ocorrncia

Id
IdentificacaoRps
DataEmissao

1-1
1-1

tsIdTag
TcIdentificacaoRps
Datetime

Descrio

Identificador da TAG

24

NaturezaOperacao
RegimeEspecialTributacao
OptanteSimplesNacional
IncentivadorCultural
Status
RpsSubstituido
Servico
Prestador
Tomador
IntermediarioServico
ConstrucaoCivil

TsNaturezaOperacao
TsRegimeEspecialTributacao
TsSimNao
TsSimNao
TsStatusRps
TcIdentificacaoRps
TcDadosServico
TcIdentificacaoPrestador
TcDadosTomador
tcIdentificacaoIntermediarioServico
TcDadosContrucaoCivil

1-1
0-1
1-1
1-1
1-1
0-1
1-1
1-1
1-1
0-1
0-1

TcRps
Representa a estrutura do Recibo Provisrio de Servio (RPS) assinada
Nome
Tipo
Ocorrncia
InfRps
tcInfRps
1-1
Signature
dsig:Signature
0-1

Descrio

tcIdentificacaoNfse
Representa dados que identificam uma Nota Fiscal de Servios Eletrnica
Nome
Tipo
Ocorrncia
Numero
tsNumeroNfse
1-1
Cnpj
tsCnpj
1-1
InscricaoMunicipal
tsInscricaoMunicipal
0-1
CodigoMunicipio
tsCodigoMunicipioIbge

Descrio

TcInfNfse
Representa os dados informativos da Nota Fiscal de Servios Eletrnica
Nome
Tipo
Id
tsIdTag

Ocorrncia

Descrio
Identificador da TAG

Numero
CodigoVerificacao
DataEmissao
IdentificacaoRps
DataEmissaoRps
NaturezaOperacao
RegimeEspecialTributacao
OptanteSimplesNacional
IncetivadorCultural
Competencia
NfseSubstituida
OutrasInformacoes
Servico
ValorCredito
PrestadorServico
TomadorServico
IntermediarioServico
OrgaoGerador
ConstrucaoCivil

1-1
1-1
1-1
0-1
0-1
1-1
0-1
1-1
1-1
1-1
0-1
0-1
1-1
0-1
1-1
1-1
0-1
1-1
0-1

a ser assinada

Ocorrncia
1-1
1-2

Descrio

tsNumeroNfse
tsCodigoVerificacao
Datetime
tcIdentificacaoRps
Date
tsNaturezaOperacao
tsRegimeEspecialTributacao
TsSimNao
TsSimNao
Date
tsNumeroNfse
tsOutrasInformacoes
tcDadosServico
TsValor
tcDadosPrestador
tcDadosTomador
tcIdentificacaoIntermediarioServico
tcIdentificacaoOrgaoGerador
tcDadosContrucaoCivil

TcNfse
Representa a estrutura da Nota Fiscal de Servios Eletrnica assinada
Nome
Tipo
InfNfse
tcInfNfse
Signature
Dsig:Signature

tcInfPedidoCancelamento
Representa a estrutura de dados do pedido de cancelamento enviado pelo prestador ao cancelar uma
Nota Fiscal de Servios Eletrnica. Tipo
Nome
Id
tsIdTag

Ocorrncia

Observao
Identificador da TAG a ser
assinada

25

IdentificacaoNfse
CodigoCancelamento

tcIdentificacaoNfse
tsCodigoCancelamentoNfse

1-1
1-1

TcPedidoCancelamento
Representa a estrutura de Pedido de Cancelamento da Nota Fiscal de Servios Eletrnica assinada
Nome
Tipo
Ocorrncia
Descrio
InfPedidoCancelamento
tcInfPedidoCancelamento
1-1
Signature
Dsig:Signature
0-1

tcInfConfirmacaoCancelamento
Representa a estrutura de dados da confirmao de cancelamento Nota Fiscal de Servios Eletrnica feito pelo Fisco
Municipal.
Nome
Tipo
Ocorrncia
Observao
Sucesso
boolean
1-1
DataHora
datetime
1-1

TcConfirmacaoCancelamento
Representa a estrutura de Confirmao de Cancelamento da Nota Fiscal de Servios Eletrnica assinada
Nome
Tipo
Ocorrncia
Descrio
Id
tsIdTag
Identificador da TAG
Pedido
InfConfirmacaoCancelamento

TcPedidoCancelamento
tcInfConfirmacaoCancelamento

1-1
1-1

TcCancelamentoNfse
Representa a estrutura completa (pedido + confirmao) de cancelamento de NFS-e.
Nome
Tipo
Ocorrncia
Confirmacao
TcConfirmacaoCancelamento
1-1
Signature
Dsig:Signature
1-1

Descrio

TcInfSubstituicaoNfse
Representa os dados de registro de substituio de NFS-e.
Nome
Tipo
Id
tsIdTag

Ocorrncia

NfseSubstituidora

1-1

tsNumeroNfse

Descrio
Identificador
assinada

da

TAG

ser

TcSubstituicaoNfse
Representa a estrutura de substituio de NFS-e.
Nome
Tipo
SubstituicaoNfse
tcInfSubstituicaoNfse
Signature
dsig:Signature

Ocorrncia
1-1
1-2

Descrio

TcCompNfse
Representa a estrutura de compartilhamento de dados de uma NFS-e.
Nome
Tipo
Ocorrncia
Nfse
tcNfse
1-1
NfseCancelamento
tcCancelamentoNfse
0-1
NfseSubstituicao
tcSubstituicaoNfse
0-1

Descrio

tcMensagemRetorno
Representa a estrutura de mensagem de retorno de servio.
Nome
Tipo
Codigo
TsCodigoMensagemAlerta
Mensagem
tsDescricaoMensagemAlerta
Correcao
tsDescricaoMensagemAlerta

Ocorrncia
1-1
1-1
0-1

Descrio

ListaMensagemRetorno
Representa a estrutura de mensagem de retorno de servio.

26

Nome
MensagemRetorno

Tipo
tcMensagemRetorno

Ocorrncia
1-N

Descrio

Ocorrncia
1-1
1-1
1-1

Descrio

Observao
Identificador
assinada

tcMensagemRetornoLote
Representa a estrutura de mensagem de retorno de servio.
Nome
Tipo
IdentificacaoRps
TcIdentificacaoRps
Codigo
TsCodigoMensagemAlerta
Mensagem
tsDescricaoMensagemAlerta

tcLoteRps
Nome
Id

Tipo
tsIdTag

Ocorrncia

NumeroLote
Cnpj
InscricaoMunicipal
QuantidadeRps
ListaRps
Rps

TsNumeroLote
TsCnpj
TsInscricaoMunicipal
TsQuantidadeRps

1-1
1-1
1-1
1-1
1-1
1-N

TcRps

da

TAG

ser

4.5 Servios
A seguir esto os servios disponveis, conforme descritos no item 3.1, no WebService
e seus XML Schema. O XML Schema define a estrutura e formatao do arquivo XML
que conter os dados a serem trafegados. Esses documentos sero enviados de forma
textual (como uma string) como parmetros do servio oferecido pelo Web Service,
como descrito em 3.2.1.

As tabelas que detalham cada XML Schema esto divididas da seguinte forma:
(1)
#
(2)

Nome
(3)

Tipo
(4)

Pai
(5)

Ocorrncia
(6)
(8)

Observao
(7)

(9)

1. Nome do arquivo XSD;

2. Nmero 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 definio da hierarquia;
6. Quantas vezes o campo se repete na estrutura de dados:
a. Formato: z-y onde x a quantidade mnima e y a quantidade mxima. Se a
quantidade mxima for indefinida, ser utilizado N no lugar do y;
7. Descreve alguma observao pertinente;
8. Formato de grupo, utilizado para definio de uma escolha (ver prximo item);
27

9. Identifica os campos ou grupos que faro parte de uma escolha

(Choice).

4.5.1 Recepo de Lote de RPS

Esse servio ser executado, inicialmente, atravs da chamada ao mtodo
RecepcionarLoteRps, passando a mensagem XML como parmetro com a estrutura
definida na tabela que segue.

servico_enviar_lote_rps_envio.xsd
#
1

Nome
EnviarLoteRpsEnvio
LoteRps
Signature

Tipo

Pai

TcLoteRps
dsig:Signature

1
1

Ocorrncia
1-1
1-1
0-1

Observao

Em resposta a chamada do servio ser devolvida a estrutura definida na tabela a

seguir.

servico_enviar_lote_rps_resposta.xsd
#
1

Nome
EnviarLoteRpsResposta
NumeroLote
DataRecebimento
Protocolo
ListaMensagemRetorno

Tipo

Pai

tsNumeroLote
Datetime
tsNumeroProtocolo
ListaMensagemRetorno

1
1
1
1

Ocorrncia
1-1

Observao

1-1
1-1

Choice

O lote ser processado posteriormente, sendo o seu resultado disponibilizado para

consulta.

4.5.2 Consulta de Situao de Lote de RPS

Esse servio
ser executado atravs
da
chamada
ao
mtodo
ConsultarSituacaoLoteRps, passando a mensagem XML como parmetro com a
estrutura definida na tabela que segue.

servico_consultar_situacao_lote_rps_envio.xsd
#
1

Nome
ConsultarSituacaoLoteRpsEn vio

Tipo

Pai

Ocorrncia
1-1

Prestador
Protocolo

TcIdentificacaoPrestador
TsNumeroProtocolo

1
1

1-1
1-1

Observao

Em resposta a chamada do servio ser devolvida a estrutura definida na tabela a

seguir.
servico_consultar_situacao_lote_rps_resposta.xsd

28

#
1

Nome
ConsultarSituacaoLoteRpsRe
sposta
NumeroLote
Situao
ListaMensagemRetorno

Tipo

Pai

Ocorrncia
1-1

Observao

tsNumeroLote
tsSituacaoLoteRps
ListaMensagemRetorno

1
1
1

1-1

Choice

1-1

4.5.3 Consulta de NFS-e por RPS

Esse servio
ser executado atravs
da
chamada
ao
mtodo
ConsultarNfsePorRps, passando a mensagem XML como parmetro com a estrutura
definida na tabela que segue.
servico_consultar_nfse_rps_envio.xsd
#
1

Nome
ConsultarNfseRpsEnvio
IdentificacaoRps
Prestador

Tipo

Pai

Ocorrncia

tcIdentificacaoRps
tcIdentificacaoPrestador

1
1

1-1
1-1

Observao

Em resposta a chamada do servio ser devolvida a estrutura definida na tabela a

seguir.
servico_consultar_nfse_rps_resposta.xsd
#
1
2

Nome
ConsultarNfseRpsResposta
CompNfse
ListaMensagemRetorno

Tipo

Pai

Ocorrncia

Observao

tcCompNfse
ListaMensagemRetorno

1
1

1-1
1-1

Choice

4.5.4 Consulta de NFS-e

Esse servio ser executado atravs da chamada ao mtodo ConsultarNfse, passando
a mensagem XML como parmetro com a estrutura definida na tabela que segue.
servico_consultar_nfse_envio.xsd
#
1

Nome
ConsultarNfseEnvio
Prestador
NumeroNfse
PeriodoEmissao
DataInicial
DataFinal
Tomador
IntermediarioServico

Tipo

Pai

tcIdentificacaoPrestador
tsNumeroNfse

1
1
1
2
2
1
1

date
date
tcIdentificacaoTomador
TcIdentificacaoIntermediar
ioServico

Ocorrncia
1-1
1-1
0-1
0-1
1-1
1-1
0-1
0-1

Observao

Em resposta a chamada do servio ser devolvida a estrutura definida na tabela a

seguir.
servico_consultar_nfse_resposta.xsd
#
1
2
3

Nome
ConsultarNfseResposta
ListaNfse
CompNfse
ListaMensagemRetorno

Tipo

Pai

tcCompNfse
ListaMensagemRetorno

1
2
1

Ocorrncia
1-1
1-1

Observao
Choice

1-1

4.5.5 Consulta de Lote de RPS

29

Esse servio
ser executado atravs
da
chamada
ao
mtodo
ConsultarLoteRps, passando a mensagem XML como parmetro com a estrutura
definida na tabela que segue.
servico_consultar_lote_rps_envio.xsd
#
1

Nome
ConsultarLoteRpsEnvio
Prestador
Protocolo

Tipo

Pai

TcIdentificacaoPrestador
TsNumeroProtocolo

1
1

Ocorrncia
1-1
1-1
1-1

Observao

Em resposta a chamada do servio ser devolvida a estrutura definida na tabela a

seguir.
servico_consultar_lote_rps_resposta.xsd
#
1
2
3

Nome
ConsultarLoteRpsResposta
ListaNfse
CompNfse
ListaMensagemRetorno

Tipo

Pai

tcCompNfse
ListaMensagemRetorno

1
2
1

Ocorrncia
1-1
1-1
1-N
1-1

Observao

Choice

4.5.6 Cancelamento NFS-e

Esse servio ser executado atravs da chamada ao mtodo CancelarNfse, passando
a mensagem XML como parmetro com a estrutura definida na tabela que segue.
servico_cancelar_nfse_envio.xsd
#
1

Nome
CancelarNfseEnvio
Pedido

Tipo

Pai

TcPedidoCancelamento

Ocorrncia
1-1
1-1

Observao

Em resposta a chamada do servio ser devolvida a estrutura definida na tabela a

seguir.
servico_cancelar_nfse_resposta.xsd
#
1
2

Nome
CancelarNfseResposta
Cancelamento
ListaMensagemRetorno

Tipo

Pai

Ocorrncia

Observao

TcCancelamentoNfse
ListaMensagemRetorno

1
1

1-1
1-1

Choice

5 ANEXO
5.1 TABELA DE ERROS
As mensagens de erro definidas pela ABRASF pdem ser encontradas na Planilha
de Mensagens de Erro, Alerta e Regras Curitiba aba (Erros), disponibilizada no
endereo: https://isscuritiba.curitiba.pr.gov.br/portalnfse/manuais.aspx.
5.2 TABELA DE ERROS ESPECFICOS DE CURITIBA
As mensagens de erro especficas para o municpio de Curitiba podem ser
encontradas na Planilha de Mensagens de Erro, Alerta e Regras Curitiba aba (Erros
30

Curitiba), disponibilizada no endereo:

https://isscuritiba.curitiba.pr.gov.br/portalnfse/manuais.aspx.
5.3 REGRAS ESPECFICAS DE CURITIBA
As regras especficas para o municpio de Curitiba podem ser encontradas na
planilha disponiblizada na pgina de Manuais do portal Boa Nota Fiscal (Planilha de
Mensagens
de
Erro,
Alerta
e
Regras
Curitiba)
no
endereo:
https://isscuritiba.curitiba.pr.gov.br/portalnfse/manuais.aspx.

31