NOTA FISCAL DE SERVIO

ELETRNICA (NFS-e)

Manual de Integrao


Verso 1.3


2
SUMRIO

1 INTRODUO 4

2 CONSIDERAES INICIAIS 5

2.1 NOTA FISCAL DE SERVIOS ELETRNICA - NFS-E 5
2.2 RECIBO PROVISRIO DE SERVIO - RPS 5

3 ARQUITETURA DE COMUNICAO COM O CONTRIBUINTE 6

3.1 MODELO CONCEITUAL 6
3.1.1 Recepo e Processamento de Lote de RPS 6
3.1.2 Consulta de Situao de Lote de RPS 6
3.1.3 Consulta de NFS-e por RPS 7
3.1.4 Consulta de Lote de RPS 8
3.1.5 Consulta de NFS-e 8
3.1.6 Cancelamento de NFS-e 9
3.2 PADRES TCNICOS 10
3.2.1 Padro de Comunicao 10
3.2.2 Padro de Certificado Digital 11
3.2.3 Padro de Assinatura Digital 11
3.2.4 Validao de Assinatura Digital pelo Sistema NFS-e 13
3.2.5 Uso de Assinatura com Certificado Digital 13
3.3 PADRO DAS MENSAGENS XML 14
3.3.1 rea do Cabealho 14
3.3.2 Validao da estrutura das Mensagens XML 14
3.3.3 Schemas XML (arquivos XSD) 15
3.3.4 Verso dos Schemas XML 15

4 ESTRUTURA DE DADOS DO WEB SERVICE 16

4.1 MODELO OPERACIONAL 16
4.1.1 Servios Sncronos 16
4.1.2 Servios Assncronos 17
4.2 FORMATOS E PADRES UTILIZADOS 18
4.3 TIPOS SIMPLES 19
4.4 TIPOS COMPLEXOS 21
4.5 SERVIOS 26
4.5.1 Recepo de Lote de RPS 27
4.5.2 Consulta de Situao de Lote de RPS 27
4.5.3 Consulta de NFS-e por RPS 28
4.5.4 Consulta de NFS-e 28
4.5.5 Consulta de Lote de RPS 29
4.5.6 Cancelamento NFS-e 29
3

5 ANEXOS 30
5.1 TABELA DE ERROS 30
5.2 REGRAS ESPECFICAS DE CURITIBA 35



























4

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.

5
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.

6
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.


7

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.

8
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.

9

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 uma mensagem com o resultado
do processamento do servio.

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 o resultado do processamento
do servio (fluxo 2.d).

10
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.

11
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.
12
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:

# Campo Elemento Pai Tipo Ocorrnci
a
Descrio
XS01 Signature Raiz
XS02 Id A XS01 C 1-1
XS03 SignedInfo G XS01 1-1 Grupo da Informao da assinatura
XS04 CanonicalizationMethod G XS03 1-1 Grupo do Mtodo de Canonicalizao
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 Mtodo de Assinatura
XS07 Algorithm A XS06 C 1-1 Atributo Algorithm de SignedInfo:
http://www.w3.org/2000/09/xmldsig#rsa-sha1 XS08 Reference G XS03 1-1 Grupo do Mtodo 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 vlidos Algorithm do Transform:
http://www.w3.org/TR/2001/REC-xml-c14n-
20010315
http://www.w3.org/2000/09/xmldsig#enveloped-
XS14 Xpath E XS12 C 0-N Xpath
XS15 DigestMethod G XS08 1-1 Grupo do Mtodo 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
13
XS20 X509Data G XS19 1-1 Grupo X509
XS21 X509Certificate E XS20 C 1-1 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;
14
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:
# Nome Elemento Pai Tipo Ocorrncia Tamanho Descrio
1 cabecalho G 1-1 TAG raiz do cabealho da
Verso A 1 N 1-1 4 Verso do leiaute.
2 versaoDados E 1 N 1-1 4 O contedo deste campo indica a
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.
15
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.


16
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:
17
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;



18

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 do
processamento e, caso no exista outra mensagem, encerra a conexo.

4.2 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:
AAAA = ano com 4 caracteres MM = ms com 2 caracteres DD = dia com 2 caracteres
Data/Hora (datetime) 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
(decimal)
Formato: 0.00
No deve ser utilizado separador de milhar. O ponto (.) deve ser utilizado para separar a
parte inteira da fracionria.
Exemplo:
48.562,25 = 48562.25
Valores Percentuais
(decimal)
Formato 0.0000
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
19
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:
20
Quando for caracteres o tamanho define a quantidade mxima de
caracteres que o texto poder ter;
Quando for numrico o tamanho pode ser representado das
seguintes formas:
- 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 Tam.
TsNumeroNfse N Nmero da Nota Fiscal de Servio Eletrnica, formado
pelo ano com 04 (quatro) dgitos e um nmero seqencial
com 11 posies Formato AAAANNNNNNNNNNN.
15
tsCodigoVerificacao C Cdigo de verificao do nmero da nota 9
TsStatusRps N Cdigo de status do RPS
1 Normal
2 Cancelado
1
TsStatusNfse N Cdigo de status da NFS-e
1 Normal
2 Cancelado
1
tsNaturezaOperacao N 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 suspensa por procedimento
administrativo
2
21
tsRegimeEspecialTributacao N Cdigo de identificao do regime especial de tributao
1 Microempresa municipal
2 - Estimativa
3 Sociedade de profissionais
4 Cooperativa
2
TsSimNao N Identificao de Sim/No
1 - Sim
2 No
1
TsQuantidadeRps N Quantidade de RPS do Lote 4
TsNumeroRps N Nmero do RPS 15
TsSerieRps C Nmero de srie do RPS 5
TsTipoRps N Cdigo de tipo de RPS
1 - RPS
2 Nota Fiscal Conjugada (Mista) No utilizado em
Curitiba
3 Cupom No utilizado em Curitiba
1
tsOutrasInformacoes C Informaes adicionais ao documento. 255
TsValor N Valor monetrio.
Formato: 0.00 (ponto separando casa decimal) Ex:
1.234,56 = 1234.56
1.000,00 = 1000.00
15,2
tsItemListaServico C Cdigo de item da lista de servio 5
TsCodigoCnae N Cdigo CNAE 7
tsCodigoTributacao C Cdigo de Tributao 20
TsAliquota N Alquota. Valor percentual. Formato: 0.0000
Ex: 1% = 0.01
25,5% = 0.255
100% = 1.0000 ou 1
5,4
tsDiscriminacao C Discriminao do contedo da NFS-e 2000
tsCodigoMunicipioIbge N Cdigo de identificao do municpio conforme tabela do
IBGE
7
tsIncricaoMunicipal C Nmero de inscrio municipal 15
tsRazaoSocial C Razo Social do contribuinte 115
tsNomeFantasia C Nome fantasia 60
TsCnpj C Nmero CNPJ 14
tsEndereco C Endereo 125
tsNumeroEndereco C Nmero do endereo 10
tsComplementoEndereco C Complemento de endereo 60
tsBairro C Bairro 60
tsUf C Sigla da unidade federativa 2
tsCep N Nmero do CEP 8
tsEmail C E-mail 80
tsTelefone C Telefone 11
TsCpf C Nmero de CPF 11
22
tsIndicacaoCpfCnpj N Indicador de uso de CPF ou CNPJ
1 CPF
2 CNPJ
3 No Informado
1
tsCodigoObra C Cdigo de Obra 15
tsArt C Cdigo ART 15
tsNumeroLote N Nmero do Lote de RPS 15
TsNumeroProtocolo C Nmero do protocolo de recebimento do RPS 50
tsSituacaoLoteRps N Cdigo de situao de lote de RPS
1 No Recebido
2 No Processado
3 Processado com Erro
4 Processado com Sucesso
1
tsCodigoMensagemAlerta C Cdigo de mensagem de retorno de servio. 4
TsDescricaoMensagemAlerta C Descrio da mensagem de retorno de servio. 200
TsCodigoCancelamentoNfse C Cdigo de cancelamento com base na tabela de
Erros e alertas.
4
tsIdTag C Atributo de identificao da tag a ser assinada no
documento XML
255


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 Tipo Ocorrncia Descrio
(4) (5) (6) (7) (3)
(4) (5) (6) (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.
23
TcCpfCnpjNmero de CPF ou CNPJ
Nome Tipo Ocorrncia Descrio
Cpf tsCpf 1-1 Nmero do Cpf Choice
Cnpj tsCnpj 1-1 Nmero do Cnpj

TcEndereco
Representao completa do endereo
Nome Tipo Ocorrncia Descrio
Endereco tsEndereco 0-1 Endereo
Numero tsNumeroEndereco 0-1 Nmero do endereo
Complemento tsComplementoEndereco 0-1 Complemento do Endereo
Bairro tsBairro 0-1 Nome do bairro
CodigoMunicipio tsCodigoMunicipioIbge 0-1 Cdigo da cidade
Uf tsUf 0-1 Sigla do estado
Cep tsCep 0-1 CEP da localidade

TcContato
Representa forma de contato com a pessoa (fsica/jurdica)
Nome Tipo Ocorrncia Descrio
Telefone tsTelefone 0-1
Email tsEmail 0-1

tcIdentificacaoOrgaoGerador
Representa dados para identificao de rgo gerador
Nome Tipo Ocorrncia Descrio
CodigoMunicipio tsCodigoMunicipioIbge 1-1
Uf tsUf 1-1

tcIdentificacaoRps
Dados de identificao do RPS
Nome Tipo Ocorrncia Descrio
Numero tsNumeroRps 1-1
Serie tsSerieRps 1-1
Tipo tsTipoRps 1-1

tcIdentificacaoPrestador
Representa dados para identificao do prestador de servio
Nome Tipo Ocorrncia Descrio
Cnpj tsCnpj 1-1
InscricaoMunicipal tsInscricaoMunicipal 0-1

tcIdentificacaoTomador
Representa dados para identificao do tomador de servio
Nome Tipo Ocorrncia Descrio
CpfCnpj tcCpfCnpj 0-1
InscricaoMunicipal tsInscricaoMunicipal 0-1

tcDadosTomador
Representa dados do tomador de servio
Nome Tipo Ocorrncia Descrio
IdentificacaoTomador TcIdentificacaoTomador 0-1

RazaoSocial TsRazaoSocial 0-1
Endereco TcEndereco 0-1
Contato TcContato 0-1

TcIdentificacaoIntermediarioServico
Representa dados para identificao de intermedirio do servio
Nome Tipo Ocorrncia Descrio

24
RazaoSocial tsRazaoSocial 1-1
CpfCnpj tcCpfCnpj 1-1
InscricaoMunicipal tsInscricaoMunicipal 0-1

TcValores
Representa um conjunto de valores que compe o documento fiscal
Nome Tipo Ocorrncia Descrio
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 (Valor dos servios - Valor das
dedues - descontos incondicionados)
Aliquota tsAliquota 0-1
ValorLiquidoNfse tsValor 0-1 (ValorServicos - ValorPIS -
ValorCOFINS - ValorINSS - ValorIR -
ValorCSLL - OutrasRetenoes -
ValorISSRetido -
DescontoIncondicionado -
DescontoCondicionado)
ValorIssRetido tsValor 0-1
DescontoCondicionado tsValor 0-1
DescontoIncondicionado tsValor 0-1

TcDadosServico
Representa dados que compe o servio prestado
Nome Tipo Ocorrncia Descrio
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 identificao de construo civil
Nome Tipo Ocorrncia Descrio
CodigoObra tsCodigoObra 1-1
Art tsArt 1-1

tcDadosPrestador
Representa dados do prestador do servio
Nome Tipo Ocorrncia Descrio
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 Provisrio de Servio (RPS)
Nome Tipo Ocorrncia Descrio

Id tsIdTag Identificador da TAG
IdentificacaoRps TcIdentificacaoRps 1-1
DataEmissao Datetime 1-1
25
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 Provisrio de Servio (RPS) assinada
Nome Tipo Ocorrncia Descrio
InfRps tcInfRps 1-1
Signature dsig:Signature 0-1

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

TcInfNfse
Representa os dados informativos da Nota Fiscal de Servios Eletrnica
Nome Tipo Ocorrncia Descrio
Id tsIdTag Identificador da TAG
a ser assinada 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 Servios Eletrnica assinada
Nome Tipo Ocorrncia Descrio
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
Nota Fiscal de Servios Eletrnica. Nome Tipo Ocorrncia Observao
Id tsIdTag Identificador da TAG a ser
assinada
26
IdentificacaoNfse tcIdentificacaoNfse 1-1
CodigoCancelamento tsCodigoCancelamentoNfse 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 TcPedidoCancelamento 1-1
InfConfirmacaoCancelamento tcInfConfirmacaoCancelamento 1-1

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

TcInfSubstituicaoNfse
Representa os dados de registro de substituio de NFS-e.
Nome Tipo Ocorrncia Descrio
Id tsIdTag Identificador da TAG a ser
assinada
NfseSubstituidora tsNumeroNfse 1-1

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

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

tcMensagemRetorno
Representa a estrutura de mensagem de retorno de servio.
Nome Tipo Ocorrncia Descrio
Codigo TsCodigoMensagemAlerta 1-1
Mensagem tsDescricaoMensagemAlerta 1-1
Correcao tsDescricaoMensagemAlerta 0-1

ListaMensagemRetorno
Representa a estrutura de mensagem de retorno de servio.
27
Nome Tipo Ocorrncia Descrio
MensagemRetorno tcMensagemRetorno 1-N

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

tcLoteRps
Nome Tipo Ocorrncia Observao
Id tsIdTag Identificador da TAG a ser
assinada
NumeroLote TsNumeroLote 1-1
Cnpj TsCnpj 1-1
InscricaoMunicipal TsInscricaoMunicipal 1-1
QuantidadeRps TsQuantidadeRps 1-1
ListaRps 1-1
Rps TcRps 1-N

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)
# Nome Tipo Pai Ocorrncia Observao
(2) (3) (4) (5) (6) (7)


(8)


(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);
28
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
# Nome Tipo Pai Ocorrncia Observao
1 EnviarLoteRpsEnvio 1-1
LoteRps TcLoteRps 1 1-1
Signature dsig:Signature 1 0-1

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

servico_enviar_lote_rps_resposta.xsd
# Nome Tipo Pai Ocorrncia Observao
1 EnviarLoteRpsResposta 1-1
NumeroLote tsNumeroLote 1
DataRecebimento Datetime 1
Protocolo tsNumeroProtocolo 1

1-1
2 ListaMensagemRetorno ListaMensagemRetorno 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
# Nome Tipo Pai Ocorrncia Observao
1 ConsultarSituacaoLoteRpsEn vio 1-1
Prestador TcIdentificacaoPrestador 1 1-1
Protocolo TsNumeroProtocolo 1 1-1

Em resposta a chamada do servio ser devolvida a estrutura definida na tabela a
seguir.
servico_consultar_situacao_lote_rps_resposta.xsd
29
# Nome Tipo Pai Ocorrncia Observao
1 ConsultarSituacaoLoteRpsRe
sposta
1-1
NumeroLote tsNumeroLote 1
Situao tsSituacaoLoteRps 1
1-1
2 ListaMensagemRetorno ListaMensagemRetorno 1 1-1
Choice

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
# Nome Tipo Pai Ocorrncia Observao
1 ConsultarNfseRpsEnvio
IdentificacaoRps tcIdentificacaoRps 1 1-1
Prestador tcIdentificacaoPrestador 1 1-1

Em resposta a chamada do servio ser devolvida a estrutura definida na tabela a
seguir.
servico_consultar_nfse_rps_resposta.xsd
# Nome Tipo Pai Ocorrncia Observao
1 ConsultarNfseRpsResposta
CompNfse tcCompNfse 1 1-1
2 ListaMensagemRetorno ListaMensagemRetorno 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
# Nome Tipo Pai Ocorrncia Observao
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
ioServico
1 0-1

Em resposta a chamada do servio ser devolvida a estrutura definida na tabela a
seguir.
servico_consultar_nfse_resposta.xsd
# Nome Tipo Pai Ocorrncia Observao
1 ConsultarNfseResposta 1-1
2 ListaNfse 1 1-1 Choice
CompNfse tcCompNfse 2
3 ListaMensagemRetorno ListaMensagemRetorno 1 1-1


4.5.5 Consulta de Lote de RPS
30
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
# Nome Tipo Pai Ocorrncia Observao
1 ConsultarLoteRpsEnvio 1-1
Prestador TcIdentificacaoPrestador 1 1-1
Protocolo TsNumeroProtocolo 1 1-1

Em resposta a chamada do servio ser devolvida a estrutura definida na tabela a
seguir.
servico_consultar_lote_rps_resposta.xsd
# Nome Tipo Pai Ocorrncia Observao
1 ConsultarLoteRpsResposta 1-1
2 ListaNfse 1 1-1
CompNfse tcCompNfse 2 1-N
3 ListaMensagemRetorno ListaMensagemRetorno 1 1-1

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
# Nome Tipo Pai Ocorrncia Observao
1 CancelarNfseEnvio 1-1
Pedido TcPedidoCancelamento 1 1-1

Em resposta a chamada do servio ser devolvida a estrutura definida na tabela a
seguir.
servico_cancelar_nfse_resposta.xsd
# Nome Tipo Pai Ocorrncia Observao
1 CancelarNfseResposta
Cancelamento TcCancelamentoNfse 1 1-1
2 ListaMensagemRetorno ListaMensagemRetorno 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
31
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.