ato cotepe 08-08 manual

7/25/2019 Ato Cotepe 08-08 Manual

1/134

Conhecimento de Transporte Eletrnico

Manual de Integrao - Contribuinte

Pg. 1/ 134

Projeto Conhecimento de Transporte Eletrnico

Manual de Integrao - ContribuintePadres Tcnicos de Comunicao

Verso 1.0.0Maro 2008


2/134



Pg. 2/ 134

Controle de Verses

Verso Data1.00 07/03/2008 - SP


3/134



Pg. 3/ 134

Identificao e vigncia do Manual

Verso do manual 1.0.0Data de divulgao do manual 10/03/2007Pacote de liberao de Schemas XML PL_CTe_100

Data de incio de vigncia no ambiente de homologao 02/06/2008Data de incio de vigncia no ambiente de produo a definir

Verses de leiautes do PL_CTe_100

Leiaute verso Schema XML ObservaoCTe 1.00 cte_v100.xsd Leiaute do CT-e.enviCTe 1.00 enviCte_v1.00.xsd Mensagem de envio de lote de CT-e.retEnviCTe 1.00 retEnviCte_v1.00.xsd Mensagem de retorno do envio de lote de CT-e.consReciCTe 1.00 consReciCte_v1.00.xsd Mensagem de consulta processamento do lote

de CT-e transmitido.retconsReciCTe 1.00 retConsReciCte_v1.00.xsd Mensagem de retorno da consulta de

processamento do lote de CT-e transmitido.procCTe 1.00 procCte_v1.00.xsd Leiaute de compartilhamento do CT-e.cancCTe 1.00 cancCte_v1.00.xsd Mensagem de solicitao de cancelamento do

CT-e.retCancCTe 1.00 retCancCte_v1.00.xsd Mensagem de retorno do resultado da solicitao

do processamento de cancelamento do CT-e.procCancCTe 1.00 procCancCte_v1.00.xsd Leiaute de compartilhamento de Pedido de

cancelamento de CT-einutCTe 1.00 inutCTe_v1.00.xsd Mensagem de solicitao de inutilizao de

numerao de CT-e.retInutCTe 1.00 retInutCTe_v1.00.xsd Mensagem de retorno do resultado do

processamento da solicitao de inutilizao denumerao de CT-e.

procInutCTe 1.00 procInutCTe_v1.00.xsd Leiaute de compartilhamento de pedido deinutilizao de numerao de CT-e

consSitCTe 1.00 consSitCte_v1.00.xsd Mensagem de consulta da situao atual da CT-e.

retConsSitCTe 1.00 retConsSitCte_v1.00.xsd Mensagem de retorno da consulta da situaoatual da CT-e.

consStatServ 1.00 consStatServCte_v1.00.xsd Mensagem da consulta do status do servio deautorizao de CT-e.

retConsStatServ 1.00 retconsStatServ_v1.00.xsd Mensagem de retorno da consulta do status doservio de autorizao de CT-e.

consCad 1.01 consCad_v1.01.xsd Mensagem de consulta ao cadastro decontribuintes do ICMS.

retConsCad 1.01 retConsCad_v1.01.xsd Mensagem de retorno da consulta ao cadastrode contribuintes do ICMS.

cadEmiDFe 1.01 cadEmiDFe_v1.01.xsd Leiaute do Cadastro Nacional de Emissores dedocumentos fiscais eletrnicos.

atuCadEmiDFe 1.01 atuCadEmiDFe_v1.01.xsd Mensagem de atualizao do Cadastro Nacionalde Emissores de documentos fiscais eletrnicos

retAtuCadEmiDFe 1.01 retAtuCadEmiDFe_v1.01.xsd Mensagem de retorno da atualizao doCadastro Nacional de Emissores de documentosfiscais eletrnicos


4/134



Pg. 4/ 134

ndice

1. Introduo ......................................................................................................... 72. Consideraes Iniciais.......................................................................................8

2.1 Histrico do documento fiscal eletrnico................................................................. 8

2.2

Conceito do CT-e ...................................................................................................8

2.3 Descrio Simplificada do Modelo Operacional...................................................... 83. Arquitetura de Comunicao com Contribuinte................................................ 10

3.1 Modelo Conceitual................................................................................................ 103.2 Padres Tcnicos................................................................................................. 11

3.2.1 Padro de documento XML .......................................................................... 113.2.2 Padro de Comunicao ..............................................................................133.2.3 Padro de Certificado Digital ........................................................................ 143.2.4 Padro de Assinatura Digital ........................................................................ 153.2.5 Validao de Assinatura Digital pela Secretaria de Fazenda Estadual ......... 173.2.6 Resumo dos Padres Tcnicos ....................................................................17

3.3 Modelo operacional ..............................................................................................18

3.3.1

Servios sncronos ....................................................................................... 183.3.2 Servios assncronos....................................................................................19

3.3.3 Filas e Mensagens........................................................................................ 213.4 Padro de mensagens dos Web Services............................................................22

3.4.1 Informaes de controle e rea de dados das mensagens........................... 223.4.2 Validao da estrutura XML das Mensagens dos Web Services .................. 233.4.3 Schemas XML das Mensagens dos Web Services....................................... 23

3.5 Verso dos Schemas ........................................................................................... 243.5.1 Liberao das verses dos Schemas para o Projeto do CT Eletrnico......... 243.5.2 Pacote de Liberao Preliminar ....................................................................253.5.3 Pacote de Liberao de Homologao e Pacote de libero definitivo ......... 253.5.4 Correo de Pacote de Liberao ................................................................25

3.5.5

Divulgao de novos Pacotes de Liberao .................................................25

3.5.6 Controle de Verso....................................................................................... 263.6 SEFAZ VIRTUAL..................................................................................................26

4. Web Services ..................................................................................................274.1 Servio de Recepo de CT-e.............................................................................. 28

4.1.1 Web Service CteRecepcao........................................................................ 284.1.2 Leiaute Mensagem de Entrada..................................................................... 284.1.3 Leiaute Mensagem de Retorno.....................................................................294.1.4 Descrio do Processo de Recepo de Lotes de CT-e............................... 294.1.5 Validao do Certificado de Transmisso..................................................... 304.1.6 Validao Inicial da Mensagem no Web Service .......................................... 304.1.7 Validao das informaes de controle da chamada ao Web Service .......... 314.1.8

Gerao da Resposta com o Recibo ............................................................31

4.1.9 Descrio do Processamento do Lote de CT-e............................................. 324.1.10 Validao da rea de Dados.........................................................................324.1.11 Final do Processamento do Lote ..................................................................37

4.2 Web Service CteRetRecepcao.......................................................................... 394.2.1 Leiaute Mensagem de Entrada..................................................................... 394.2.2 Leiaute Mensagem de Retorno.....................................................................394.2.3 Descrio do Processo de Web Service....................................................... 404.2.4 Validao do Certificado de Transmisso..................................................... 414.2.5 Validao Inicial da Mensagem no Web Service .......................................... 414.2.6 Validao das informaes de controle da chamada ao Web Service .......... 42

4.2.7

Validao da rea de Dados ........................................................................ 42

4.2.8 Final do Processamento...............................................................................434.3 Web Service CteCancelamento.........................................................................44


5/134



Pg. 5/ 134

4.3.1 Leiaute Mensagem de Entrada..................................................................... 444.3.2 Leiaute Mensagem de Retorno.....................................................................444.3.3 Descrio do Processo de Web Service....................................................... 454.3.4 Validao do Certificado de Transmisso..................................................... 454.3.5 Validao Inicial da Mensagem no Web Service .......................................... 46

4.3.6

Validao das informaes de controle da chamada ao Web Service .......... 47

4.3.7 Validao da rea de Dados ........................................................................ 474.3.8 Final do Processamento...............................................................................49

4.4 Web Service - CteInutilizacao...............................................................................504.4.1 Leiaute Mensagem de Entrada..................................................................... 504.4.2 Leiaute Mensagem de Retorno.....................................................................514.4.3 Descrio do Processo de Web Service....................................................... 514.4.4 Validao do Certificado de Transmisso..................................................... 524.4.5 Validao Inicial da Mensagem no Web Service .......................................... 524.4.6 Validao das informaes de controle da chamada ao Web Service .......... 534.4.7 Validao da rea de Dados ........................................................................ 534.4.8 Final do Processamento...............................................................................55

4.5

Web Service CteConsulta Protocolo.................................................................. 564.5.1 Leiaute Mensagem de Entrada..................................................................... 56

4.5.2 Leiaute Mensagem de Retorno.....................................................................564.5.3 Descrio do Processo de Web Service....................................................... 574.5.4 Validao do Certificado de Transmisso..................................................... 574.5.5 Validao Inicial da Mensagem no Web Service .......................................... 584.5.6 Validao das informaes de controle da chamada ao Web Service .......... 584.5.7 Validao da rea de Dados ........................................................................ 594.5.8 Final do Processamento...............................................................................59

4.6 Web Service CteStatusServico.......................................................................... 604.6.1 Leiaute Mensagem de Entrada..................................................................... 604.6.2 Leiaute Mensagem de Retorno.....................................................................60

4.6.3

Descrio do Processo de Web Service....................................................... 61

4.6.4 Validao do Certificado de Transmisso..................................................... 614.6.5 Validao Inicial da Mensagem no Web Service .......................................... 624.6.6 Validao das informaes de controle da chamada ao Web Service .......... 624.6.7 Validao da rea de Dados ........................................................................ 634.6.8 Final do Processamento...............................................................................63

4.7 Web Service CadConsultaCadastro ..................................................................644.7.1 Leiaute da Mensagem de Entrada................................................................644.7.2 Leiaute da Mensagem de Retorno................................................................654.7.3 Descrio do Processo de Web Service....................................................... 664.7.4 Verificao do Certificado de Transmisso................................................... 674.7.5 Verificao Inicial da Mensagem no Web Service......................................... 674.7.6

Validao da rea de Cabealho.................................................................. 68

4.7.7 Validao da rea de Dados ........................................................................ 684.7.8 Final do Processamento...............................................................................69

5. Web Services Informaes Adicionais .......................................................... 705.1 Regras de validao............................................................................................. 70

5.1.1 Tabela de cdigos de erros e descries de mensagens de erros................ 705.2 Padro de nomes para os arquivos...................................................................... 745.3 Tratamento de caracteres especiais no texto de XML .......................................... 745.4 Chave de Acesso do CT-e ...................................................................................755.5 Nmero do Recibo de Lote................................................................................... 765.6 Nmero do protocolo............................................................................................77

5.7

Tempo mdio de resposta.................................................................................... 77

6. Cdigo de Barra ..............................................................................................786.1 Clculo do dgito verificador do CODE-128C........................................................ 79


6/134



Pg. 6/ 134

6.2 Representao simblica do cdigo ..................................................................... 797. DACTE............................................................................................................ 808. Contingncia ...................................................................................................819. Ambiente de Homologao / Produo ........................................................... 8210. Distribuio do CT-e para o Destinatrio ......................................................... 83

10.1

Processo de Distribuio...................................................................................... 83

10.2 Leiaute da Distribuio: CT-e ...............................................................................8311. Compartilhamento de informaes do CT-e entre rgos Pblicos................. 84

11.1 Processo de Compartilhamento ........................................................................... 8511.2 Leiaute de compartilhamento: CT-e..................................................................... 8511.3 Leiaute de compartilhamento: Cancelamento de CT-e ........................................ 8611.4 Leiaute de compartilhamento: Inutilizao de Numerao de CT-e..................... 8611.5 Compartilhamento de documentos com outros rgos pblicos........................... 86

12. Cadastro nacional de emissores de DF-e........................................................ 8712.1 Leiaute do Cadastro de Emissor de DF-e............................................................. 8812.2 Leiaute de Atualizao do Cadastro de Emissor de DF-e..................................... 8812.3 Leiaute de Retorno de Atualizao de Cadastro de Emissor de DF-e .................. 89

Anexo I Leiaute do CT-e...................................................................................................91Anexo II Modelo de DACTE............................................................................................ 121

Anexo III Tabelas de UF, Municpio e Pas .....................................................................1281. Tabela de cdigo de UF do IBGE..................................................................1282. Tabela de cdigo de Municpio do IBGE........................................................ 128

2.1 Validao do cdigo de Municpio ...................................................................... 1292.2 Exemplo de clculo do dgito de controle do cdigo de Municpio ...................... 129

3. Tabela de cdigo de Pas do BACEN............................................................ 1303.1 Validao do cdigo de Pas .............................................................................. 1303.2 Exemplo de clculo do dgito de controle do cdigo de Pas .............................. 131

Anexo IV WS disponveis................................................................................................ 132Anexo V Conjunto de caracteres Cdigo de Barras CODE-128C ................................... 133

Anexo VI Projeto Piloto do CT-e .....................................................................................134


7/134



Pg. 7/ 134

1. Introduo

Este documento tem por objetivo a definio das especificaes e critrios tcnicosnecessrios para a integrao entre os Portais das Secretarias de Fazendas dos Estados e

os sistemas de informaes das empresas emissoras de Conhecimento de Transporteeletrnico - CT-e.

Em vista da complexidade do projeto, esclarecemos aos usurios deste manual (equipesfiscal e de TI das empresas integrantes do projeto), que a legislao aprovada, conceitos eespecificaes contidas neste manual podem sofrer ajustes que venham a ser demandadosa partir do aprofundamento das discusses e experincias adquiridas durante a fase deimplantao do projeto.


8/134



Pg. 8/ 134

2. Consideraes Iniciais

O Projeto Conhecimento de Transporte Eletrnico (CT-e) est sendo desenvolvido, de formaintegrada, pelas Secretarias de Fazenda dos Estados e Receita Federal do Brasil, a partir da

assinatura do Protocolo ENAT 03/2006 (10/11/2006), que atribui ao Encontro Nacional deCoordenadores e Administradores Tributrios Estaduais (ENCAT) a coordenao e aresponsabilidade pelo desenvolvimento e implantao do Projeto CT-e.

2.1 Histrico do documento fiscal eletrnico

O documento fiscal eletrnico surgiu com o projeto da Nota Fiscal eletrnica que tinha comoobjetivo a implantao de um modelo nacional de documento fiscal eletrnico para substituira sistemtica atual de emisso do documento fiscal em papel, modelos 1 e 1A, com validade

jurdica garantida pela assinatura digital do emissor.O documento fiscal eletrnica simplifica o cumprimento das obrigaes acessrias doscontribuintes e permite um melhor acompanhamento das operaes comerciais pelo Fisco,mostrando-se uma soluo vantajosa para todos os interessados.

Em outubro de 2006, foi iniciada uma nova fase do projeto da Nota Fiscal eletrnica parapossibilitar o uso do documento fiscal eletrnico em substituio aos demais documentosfiscais existentes no pas, conforme previsto no pargrafo nico da clasula segunda doProtocolo ENAT 03/2005.

O Conhecimento de Transporte eletrnico o novo modelo de documento fiscal eletrnico,

institudo pelo AJUSTE SINIEF 09/07 (25/10/2007), que poder ser utilizado para substituirum dos seguintes documentos fiscais:

Conhecimento de Transporte Rodovirio de Cargas, modelo 8; Conhecimento de Transporte Aquavirio de Cargas, modelo 9; Conhecimento Areo, modelo 10; Conhecimento de Transporte Ferrovirio de Cargas, modelo 11; Nota Fiscal de Servio de Transporte Ferrovirio de Cargas, modelo 27; Nota Fiscal de Servio de Transporte, modelo 7, quando utilizada em transporte de cargas.

O Conhecimento de Transporte eletrnico tambm poder ser utilizado como documentofiscal eletrnico no transporte dutovirio e, futuramente, nos transportes Multimodais.

2.2 Conceito do CT-e

O Conhecimento de Transporte Eletrnico (CT-e) pode ser conceituado como umdocumento de existncia exclusivamente digital, emitido e armazenado eletronicamente,com o intuito de documentar uma prestao de servios de transportes, cuja validadejurdica garantida pela assinatura digital do emitente e a Autorizao de Uso fornecida pelaadministrao tributria do domiclio do contribuinte.

2.3 Descrio Simplificada do Modelo Operacional


9/134



Pg. 9/ 134

De maneira simplificada, a empresa emissora de CT-e gerar um arquivo eletrnicocontendo as informaes fiscais da prestao de servios de transportes, o qual dever serassinado digitalmente, de maneira a garantir a integridade dos dados e a autoria do emissor.Este arquivo eletrnico, que corresponder ao Conhecimento de Transporte Eletrnico (CT-e), ser ento transmitido, pela Internet, para a Secretaria de Fazenda Estadual de

jurisdio do contribuinte emitente, que far uma pr-validao do arquivo e devolver umaAutorizao de Uso, sem a qual no poder haver a prestao de servio de transporte.

Aps o recebimento do CT-e, a Secretaria de Fazenda Estadual disponibilizar consulta,atravs Internet, para o tomador do servio e outros legtimos interessados que detenham achave de acesso do documento eletrnico.

Este mesmo arquivo do CT-e ser ainda transmitido, pela Secretaria de Fazenda Estadual,para a Receita Federal do Brasil, que ser o repositrio nacional de todos os CT-e emitidos,e para as Secretarias de Fazenda de incio da prestao do servio e do tomador doservio, caso sejam diferentes da Secretaria de Fazenda de circunscrio do emissor, almda SUFRAMA, quando aplicvel.

Para acobertar a prestao de servio de transporte ser impressa uma representaogrfica simplificada do Conhecimento de Transporte Eletrnico, intitulada DACTE(Documento Auxiliar do Conhecimento de Transporte Eletrnico), em papel comum, queconter impressos, em destaque, a chave de acesso e o cdigo de barras linear tomando-sepor referncia o padro CODE-128C, para facilitar e agilizar a consulta do CT-e na Internet ea respectiva confirmao de informaes pelas unidades fiscais e pelos tomadores deservios de transporte.

O DACTE no um conhecimento de transporte, nem o substitui, servindo apenas comoinstrumento auxiliar para consulta do CT-e, pois contm a chave de acesso do CT-e, quepermite ao detentor desse documento confirmar a efetiva existncia do CT-e, atravs dos

stios das Secretarias de Fazenda Estaduais autorizadoras ou Receita Federal. No primeiromomento de implantao do projeto, o contribuinte tomador do servio de transporte, noemissor de Documentos Fiscais eletrnicos, poder escriturar o CT-e com base nasinformaes deste documento, sendo que sua validade ficar vinculada efetiva existnciado CT-e com autorizao de uso no Banco de Dados das administraes tributriasenvolvidas no processo.


10/134



Pg. 10/ 134

3. Arquitetura de Comunicao com Contribuinte

3.1 Modelo Conceitual

Os Portais das Secretarias de Fazenda Estaduais iro disponibilizar os seguintes servios:

a) Recepo de CT-e;1) Recepo de Lote;2) Consulta Processamento de Lote;

b) Cancelamento de CT-e;c) Inutilizao de numerao de CT-e;d) Consulta da situao atual do CT-e;e) Carta de Correo de CT-e;f) Consulta do status do servio.

Para cada servio oferecido existir um Web Service especfico. O fluxo de comunicao sempre iniciado pelo aplicativo do contribuinte atravs do envio de uma mensagem ao WebService com a solicitao do servio desejado.

O Web Service sempre devolve uma mensagem de resposta confirmando o recebimento dasolicitao de servio ao aplicativo do contribuinte na mesma conexo.

A solicitao de servio poder ser atendida na mesma conexo ou ser armazenada emfilas de processamento nos servios mais crticos para um melhor aproveitamento dosrecursos de comunicao e de processamento das Secretarias de Fazenda Estaduais.

Os servios podem ser sncronos ou assncronos em funo da forma de processamento dasolicitao de servios:

a) Servios sncronos o processamento da solicitao de servio concludo namesma conexo, com a devoluo de uma mensagem com o resultado doprocessamento do servio solicitado;

b) Servios assncronos o processamento da solicitao de servio no concludona mesma conexo, havendo a devoluo de uma mensagem de resposta com umrecibo que apenas confirma o recebimento da solicitao de servio. O aplicativo docontribuinte dever realizar uma nova conexo para consultar o resultado doprocessamento do servio solicitado anteriormente.

O diagrama a seguir ilustra o fluxo conceitual de comunicao entre o aplicativo docontribuinte e o Portal da Secretaria de Fazenda Estadual:


11/134



Pg. 11/ 134

3.2 Padres Tcnicos

3.2.1 Padro de documento XML

a) Padro de Codificao

A especificao do documento XML adotada a recomendao W3C para XML 1.0,disponvel em www.w3.org/TR/REC-xmle a codificao dos caracteres ser em UTF-8,assim todos os documentos XML sero iniciados com a seguinte declarao:

OBS: Lembrando que cada arquivo XML somente poder ter uma nica declarao. Nas situaes em que um documento XMLpode conter outros documentos XML, como ocorre com o documento XML de lote deenvio de CT-e, deve-se tomar o cuidado para que exista uma nica declarao no inciodo lote.

b) Declarao namespace

O documento XML dever ter uma nica declarao de namespaceno elemento raiz dodocumento com o seguinte padro:

(exemplo para o XML da CT-e)

O uso de declarao namespace diferente do padro estabelecido para o Projeto vedado.

A declarao do namespaceda assinatura digital dever ser realizada na prpria tag, conforme exemplo abaixo.

Cada documento XML dever ter o seu namespaceindividual em seu elemento raiz. Nocaso especfico do lote de envio do CT-e, cada CT-e dever ter declarado o seunamespaceindividual.Segue abaixo um exemplo:

Contribuinte Secretaria de Fazenda Estadual

Client CTe( ERP ou software especfico)

CTe

Aplicativo de Faturamento( ERP ou software especfico)

HTTPSFluxo de

Comunicao

ServiosSncronos

Aplicao CTe

Filas de Msgs

CTes

Arquitetura de Comunicao Viso

ServiosAssncronos

Web Services Transaes


12/134



Pg. 12/ 134

200602220000001

...

...

...

c) Prefixo de namespace

No permitida a utilizao de prefixos de namespace. Essa restrio visa otimizar otamanho do arquivo XML.

Assim, ao invs da declarao: (exemplo para o XML do CT-ecom prefixo cte) dever ser adotado a declarao:

d) Otimizao na montagem do arquivo

Na gerao do arquivo XML do CT-e, excetuados os campos identificados como obrigatriosno modelo (primeiro dgito da coluna de ocorrncias do leiaute iniciada com 1, ex.: 1-1, 1-2,

1-N), no devero ser includas as TAGs de campos com contedo zero (para campos tiponumrico) ou vazio (para campos tipo caractere).

A regra constante do pargrafo anterior dever estender-se para os campos onde no hindicao de obrigatoriedade e que, no entanto, seu preenchimento torna-se obrigatrio porestar condicionado legislao especfica ou ao negcio do contribuinte. Neste caso,dever constar a TAG com o valor correspondente e, para os demais campos, devero sereliminadas as TAGs.

Exemplo 1: SubGrupo de Informaes de transporte de produtos perigosos (ocorrncia 0-1).Ser preenchido se a legislao especfica o exigir.


13/134



Pg. 13/ 134

Exemplo 2: Informao relacionada com o AFRMM - Adicional de Frete para Renovao daMarinha Mercante (ocorrncia 0-1). Ser preenchido somente se o negcio do contribuintefor transporte aquavirio.

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

devero ser assumidos: no incluir "zeros no significativos" para campos numricos; no incluir "espaos" ("line-feed", "carriage return", "tab", caractere de "espao" entre

as TAGs.) 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).

d) Validao de Schema

Para garantir minimamente a integridade das informaes prestadas e a correta formaodos arquivos XML, o contribuinte dever submeter o arquivo do CT-e e as demaismensagens XML para validao pelo Schema do XML (XSD XML Schema Definition),disponibilizado pela Secretaria de Fazenda Estadual, antes de seu envio.

3.2.2 Padro de Comunicao

A comunicao entre o contribuinte e a Secretaria de Fazenda Estadual ser baseada emWeb Services disponibilizados no Portal da Secretaria de Fazenda Estadual decircunscrio do contribuinte.

O meio fsico de comunicao utilizado ser a Internet, com o uso do protocolo SSL verso3.0, com autenticao mtua, que alm de garantir um duto de comunicao seguro naInternet, 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 usurioe senha.

O modelo de comunicao segue o padro de Web Services definido pelo WS-I BasicProfile.

A troca de mensagens entre os Web Services do Portal da Secretaria de Fazenda Estaduale o aplicativo do contribuinte ser realizada no padro SOAP verso 1.2, com troca demensagens XML no padro Style/Enconding: Document/Literal.

A chamada do diferentes Web Services do Projeto CT-e realizado com o envio de umamensagem XML atravs do campo cteDadosMsg.

A verso do leiaute da mensagem XML contida no campo cteDadosMsg e o cdigo da UFrequisitada sero informados nos campos versaoDados e cUF, ambos do tipo stringlocalizados no elemento cteCabecMsg do SOAP header.

Exemplo de uma mensagem requisio padro SOAP:


14/134



Pg. 14/ 134

stringstring

xml

Exemplo de uma mensagem de retorno padro SOAP:

string

string

xml

3.2.3 Padro de Certificado Digital

O certificado digital utilizado no Projeto do Conhecimento de Transporte eletrnico seremitido por Autoridade Certificadora credenciada pela Infra-estrutura de Chaves PblicasBrasileira ICP-Brasil, tipo A1 ou A3, devendo conter o CNPJ da pessoa jurdica titular docertificado digital no campo otherNameOID =2.16.76.1.3.3.

Os certificados digitais sero exigidos em 2 (dois) momentos distintos para o projeto:

a) Assinatura de Mensagens: O certificado digital utilizado para essa funo deverconter o CNPJ do estabelecimento emissor do CT-e ou o CNPJ do estabelecimentomatriz. Por mensagens, entenda-se: o Pedido de Autorizao de Uso (Arquivo CT-e),

o Pedido de Cancelamento de CT-e, o Pedido de Inutilizao de Numerao de CT-ee demais arquivos XML que necessitem de assinatura. O certificado digital dever ter


15/134



Pg. 15/ 134

o uso da chave previsto para a funo de assinatura digital, respeitando a Polticado Certificado.

b) Transmisso (durante a transmisso das mensagens entre o servidor docontribuinte e o Portal da Secretaria de Fazenda Estadual): O certificado digitalutilizado para identificao do aplicativo do contribuinte dever conter o CNPJ do

responsvel pela transmisso das mensagens, mas no necessita ser o mesmoCNPJ do estabelecimento emissor do CT-e, devendo ter a extenso Extended KeyUsage com permisso de "Autenticao Cliente".

3.2.4 Padro de Assinatura Digital

As mensagens enviadas ao Portal da Secretaria de Fazenda Estadual so documentoseletrnicos elaborados no padro XML e devem ser assinados digitalmente com umcertificado digital que contenha o CNPJ do estabelecimento matriz ou o CNPJ doestabelecimento emissor do CT-e objeto do pedido.

Os elementos abaixo esto presentes dentro do Certificado do contribuinte tornandodesnecessria a sua representao individualizada no arquivo XML. Portanto, o arquivoXML no deve conter os elementos:

Deve-se evitar o uso das TAGs abaixo, pois as informaes sero obtidas a partir doCertificado do emitente:

O Projeto CT-e utiliza um subconjunto do padro de assinatura XML definido pelohttp://www.w3.org/TR/xmldsig-core/, que tem o seguinte leiaute:

Schema XML: xmldsig-core-schema_v1.01.xsd

# Campo Ele Pai Tipo Ocor. Tam. Dec. Descrio/Observao

XS01 Signature Raiz - - - -

XS02 SignedInfo G XS01 - 1-1 Grupo da Informao da assinaturaXS03 CanonicalizationM

ethodG XS02 - 1-1 Grupo do Mtodo de Canonicalizao

XS04 Algorithm A XS03 C 1-1 Atributo Algorithm de CanonicalizationMethod:http://www.w3.org/TR/2001/REC-xml-c14n-20010315

XS05 SignatureMethod G XS02 - 1-1 Grupo do Mtodo de Assinatura

XS06 Algorithm A XS05 C 1-1 Atributo Algorithm de SignedMethod:http://www.w3.org/2000/09/xmldsig#rsa-sha1

XS07 Reference G XS02 - 1-1 Grupo de Reference

XS08 URI A XS07 C 1-1 Atributo URI da tag Reference

XS10 Transforms G XS07 - 1-1 Grupo do algorithm de Transform

XS11 unique_Transf_Alg RC XS10 - 1-1 Regra para o atributo Algorithm do Transformser nico.


16/134



Pg. 16/ 134

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-20010315http://www.w3.org/2000/09/xmldsig#enveloped-signature

XS14 XPath E XS12 C 0-N XPathXS15 DigestMethod G XS07 - 1-1 Grupo do Mtodo de DigestMethod

XS16 Algorithm A XS15 C 1-1 Atributo Algorithm de DigestMethod:http://www.w3.org/2000/09/xmldsig#sha1

XS17 DigestValue E XS07 C 1-1 Digest Value (Hash SHA-1 Base64)

XS18 SignatureValue G XS01 - 1-1 Grupo do Signature ValueXS19 KeyInfo G XS01 - 1-1 Grupo do KeyInfo

XS20 X509Data G XS19 - 1-1 Grupo X509

XS21 X509Certificate E XS20 C 1-1 Certificado Digital x509 em Base64

A assinatura do Contribuinte no CT-e ser feita na TAG identificada pelo atributo

Id, cujo contedo dever ser um identificador nico (chave de acesso) precedido do literalCTe para cada CT-e, conforme leiaute descrito no Anexo I. O identificador nico precedidodo literal #CTe dever ser informado no atributo URI da TAG . Para as demaismensagens a serem assinadas, o processo o mesmo mantendo sempre um identificadornico para o atributo Idna TAG a ser assinada. Segue abaixo um exemplo:

...

vFL68WETQ+mvj1aJAMDx+oVi928=

IhXNhbdL1F9UGb2ydVc5v/gTB/y6r0KIFaf5evUi1i ...MIIFazCCBFOgAwIBAgIQaHEfNaxSeOEvZGlVDANB ...

Para o processo de assinatura, o contribuinte no deve fornecer a Lista de CertificadosRevogados, j que a mesma ser montada e validada por cada Portal da Secretaria deFazenda Estadual no momento da conferncia da assinatura digital.

A assinatura digital do documento eletrnico dever atender aos seguintes padresadotados:

a) Padro de assinatura: XML Digital Signature, utilizando o formato Enveloped(http://www.w3.org/TR/xmldsig-core/);

b) Certificado digital: Emitido por AC credenciada no ICP-Brasil(http://www.w3.org/2000/09/xmldsig#X509Data);


17/134



Pg. 17/ 134

c) Cadeia de Certificao:EndCertOnly (Incluir na assinatura apenas o certificado dousurio final);

d) Tipo do certificado:A1 ou A3 (o uso de HSM recomendado); e) Tamanho da Chave Criptogrfica:Compatvel com os certificados A1 e A3 (1024

bits);

f) Funo criptogrfica assimtrica: RSA (http://www.w3.org/2000/09/xmldsig#rsa-sha1);g) Funo de message digest: SHA-1 (http://www.w3.org/2000/09/xmldsig#sha1);h) Codificao: Base64 (http://www.w3.org/2000/09/xmldsig#base64);i) Transformaes exigidas: til para realizar a canonicalizao do XML enviado para

realizar a validao correta da Assinatura Digital. So elas:(1) Enveloped (http://www.w3.org/2000/09/xmldsig#enveloped-signature)(2) C14N (http://www.w3.org/TR/2001/REC-xml-c14n-20010315)

3.2.5 Validao de Assinatura Digital pela Secretaria de Fazenda Estadual

Para a validao da assinatura digital, seguem as regras que sero adotadas pelasSecretarias de Fazenda Estaduais:

(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 fica a critrio de cada Secretaria de Fazenda Estadual,podendo ser feita de 2 (duas) maneiras: On-line ou Download peridico. As assinaturasdigitais das mensagens sero verificadas considerando a lista de certificados revogadosdisponvel no momento da conferncia da assinatura.

3.2.6 Resumo dos Padres Tcnicos

A tabela a seguir resume os principais padres de tecnologia utilizados:

Caracterstica DescrioWeb Services Padro definido pelo WS-I Basic Profile 1.1

(http://www.ws-i.org/Profiles/BasicProfile-1.1-2004-08-24.html).

Meio lgico de comunicao Web Services, disponibilizados pelo Portal da Secretariade Fazenda Estadual.

Meio fsico de comunicao InternetProtocolo Internet SSL verso 3.0, com autenticao mtua atravs de

certificados digitais.Padro de troca de mensagens SOAP verso 1.2.Padro da mensagem XML no padro Style/Encoding: Document/Literal.Padro de certificado digital X.509 verso 3, emitido por Autoridade Certificadora


18/134



Pg. 18/ 134

credenciada pela Infra-estrutura de Chaves PblicasBrasileira ICP-Brasil, do tipo A1 ou A3, devendo contero CNPJ do proprietrio do certificado digital.

Para assinatura de mensagens, utilizar o certificado

digital do estabelecimento matriz ou do estabelecimentoemissor do CT-e.

Para transmisso, utilizar o certificado digital doresponsvel pela transmisso.

Padro de assinatura digital XML Digital Signature, Enveloped, com certificado digitalX.509 verso 3, com chave privada de 1024 bits, compadres de criptografia assimtrica RSA, algoritmomessage digest SHA-1 e utilizao das transformaesEnveloped e C14N.

Validao de assinatura digital Ser validada alm da integridade e autoria, a cadeia deconfiana com a validao das LCRs.

Padres de preenchimento XML Campos no obrigatrios do Schema que nopossuam contedo tero suas tags suprimidas noarquivo XML.

Mscara de nmeros decimais e datas estodefinidas no Schema XML.

Nos campos numricos inteiro, no incluir a vrgulaou ponto decimal.

Nos campos numricos com casas decimais, utilizar oponto decimal na separao da parte inteira.

3.3 Modelo operacional

A forma de processamento das solicitaes de servios no projeto projeto Conhecimento deTransporte eletrnico pode ser sncrona, caso o atendimento da solicitao de servio sejarealizada na mesma conexo, ou assncrona, quando o processamento do servio solicitadono atendido na mesma conexo, nesta situao torna-se necessria a realizao de maisuma conexo para a obteno do resultado do processamento.

As solicitaes de servios que exigem processamento intenso sero executadas de formaassncrona e as demais solicitaes de servios de forma sncrona.

Assim, os servios do CT-e sero implementados da seguinte forma:

Servio ImplementaoRecepo de CT-e AssncronaCancelamento de CT-e SncronaInutilizao de Numerao de CT-e SncronaConsulta da situao atual do CT-e SncronaCarta de Correo de CT-e SncronaConsulta do status do servio Sncrona

3.3.1 Servios sncronos


19/134



Pg. 19/ 134

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

Abaixo, o fluxo simplificado de funcionamento:

Etapas do processo ideal:

(1) O aplicativo do contribuinte inicia a conexo enviando uma mensagem de solicitaode servio para o Web Service;

(2) O Web Service recebe a mensagem de solicitao de servio e encaminha aoaplicativo do CT-e que ir processar o servio solicitado;

(3) O aplicativo do CT-e recebe a mensagem de solicitao de servio e realiza oprocessamento, devolvendo uma mensagem de resultado do processamento aoWeb Service;

(4) O Web Service recebe a mensagem de resultado do processamento e o encaminhaao aplicativo do contribuinte;

(5) O aplicativo do contribuinte recebe a mensagem de resultado do processamento e,caso no exista outra mensagem, encerra a conexo.

3.3.2 Servios assncronosAs solicitaes de servios de implementao assncrona so processadas de formadistribuda por vrios processos e o resultado do processamento somente obtido nasegunda conexo.

Abaixo, o fluxo simplificado de funcionamento:

AplicativoCliente

Web Service Processamentode Servios

(1) Solicitao deservio (2) Solicitao de servio

(4) Resultado (3) Resultado

Contribuinte Secretaria de Fazenda EstadualServio de Implementao sncrona


20/134



Pg. 20/ 134

Envio deSolicitaode Servios

ConsultaRecibo

Web Service

Recebe Solicitaode Servios

Web Service

Consulta recibo

Processamentode Servios

(1) Solicitao de servio(2) Solicitao de servio

(8) Consulta recibo

(3) Recibo

Fila deservios

solicitados

Fila derecibos

(4)

(7)

(5)

(6)

(10) Resultado processamento(9) Resultado processamento

Fila deservios

processados

Contribuinte Secretaria de Fazenda Estadual

Servio de Implementao assncrona

Etapas do processo ideal:

(1) O aplicativo do contribuinte inicia a conexo enviando uma mensagem desolicitao 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 desolicitao de servio e a coloca na fila de servios solicitados, acrescentando oCNPJ do transmissor obtido do certificado digital do transmissor;

(3) O Web Service de recepo de solicitao de servios retorna o recibo dasolicitao de servio e a data e hora de recebimento da mensagem no WebService;

(4) O aplicativo do contribuinte recebe o recibo e o coloca na fila de recibos deservios solicitados e ainda no processados e, caso no exista outra mensagem,encerra a conexo;

(5) Na Secretaria de Fazenda Estadual a solicitao de servios retirada da fila deservios solicitados pelo aplicativo do CT-e;

(6) O servio solicitado processado pelo aplicativo do CT-e e o resultado doprocessamento colocado na fila de servios processados;

(7) O aplicativo do contribuinte retira um recibo da fila de recibos de serviossolicitados;

(8) O aplicativo do contribuinte envia uma consulta de recibo, iniciando uma conexocom o Web Service Consulta Recibo (CTeRetRecepcao);

(9) O Web Service Consulta Recibo recebe a mensagem de consulta recibo elocaliza o resultado de processamento da solicitao de servio;

(10) O Web Service Consulta Recibo (CTeRetRecepcao) devolve o resultado do

processamento ao aplicativo contribuinte;(11) O aplicativo do contribuinte recebe a mensagem de resultado do processamento e,caso no exista outra mensagem, encerra a conexo.


21/134



Pg. 21/ 134

3.3.3 Filas e Mensagens

As filas de mensagens de solicitao de servios so necessrias para a implementao do

processamento assncrono das solicitaes de servios.

As mensagens de solicitaes de servios no processamento assncrono so armazenadasem uma fila de entrada.

Para ilustrar como as filas armazenam as informaes, observe o diagrama a seguir:

A estrutura de um item composta pela rea de controle (identificador) e pela rea dedetalhe que contem a mensagem XML. As seguintes informaes so adotadas comoatributos de controle:

CNPJ do transmissor: CNPJ da empresa que enviou a mensagem que nonecessita estar vinculado ao CNPJ do estabelecimento emissor do CT-e. Somente otransmissor da mensagem ter acesso ao resultado do processamento dasmensagens de solicitao de servios;

Recibo de entrega: Nmero seqencial nico atribudo para a mensagem pela

Secretaria de Fazenda Estadual. Este atributo identifica a mensagem de solicitaode servios na fila de mensagem;

Data e hora de recebimento da mensagem: Data e hora local do instante derecebimento da mensagem atribuda pela Secretaria de Fazenda Estadual. Esteatributo importante como parmetro de desempenho do sistema, eliminao demensagens, adoo do regime de contingncia, etc. O tempo mdio de resposta calculado com base neste atributo;

cUF: Cdigo da UF (na codificao utilizada pelo IBGE) de origem do emissor doCT-e informada no campo cUF do elemento cteCabecMsg do SOAP Header. Oatributo importante para a implementao da SEFAZ Virtual e identificao da UFde origem da mensagem;

versaoDados: Verso do leiaute da mensagem existente na rea de dados. Oatributo utilizado para validao de schema XML do XML de dados e verificar avigncia da verso informada.

Para processar as mensagens de solicitaes de servios, a aplicao do CT-e ir retirar amensagem da fila de entrada de acordo com a ordem de chegada, devendo armazenar oresultado do processamento da solicitao de servio em uma fila de sada.

A fila de sada ter a mesma estrutura da fila de entrada, a nica diferena ser no contedodo detalhe da mensagem que contm o resultado do processamento da solicitao deservio em formato XML.

O tempo mdio de resposta que mede a performance do servio de processamento doslotes calculado com base no tempo decorrido entre o momento de recebimento da

Estrutura de um item da fila:

CNPJ doTransmissor Nmerodo Recibo data e horarecebimento cUF XML de Dados

rea de controle rea de mensagem

VersoDados


22/134



Pg. 22/ 134

mensagem e o momento de armazenamento do resultado do processamento da solicitaode servio na fila de sada.

Nota: O termo fila utilizado apenas para designar um repositrio de recibos emitidos. Aimplementao da fila poder ser feita atravs de Banco de Dados ou qualquer outra forma,sendo transparente ao contribuinte que realizar a consulta do processamento efetuado(processos assncronos).

3.4 Padro de mensagens dos Web Services

As chamadas dos Web Services disponibilizados pelas Secretarias de Fazenda Estaduaisou Receita Federal do Brasil e os respectivos resultados do processamento so realizadasatravs das mensagens com o seguinte padro:

cUF cdigo da UF de origem da mensagem. versaoDados -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.4.1 Informaes de controle e rea de dados das mensagens

As informaes de controle das chamadas dos Web Services so armazenadas noelemento cteCabecMsg do SOAP Header e servem para identificar a UF de origem doemissor e a verso do leiaute da estrutura XML armazenada na rea de dados damensagem:

stringstring

A informao armazenada na rea de dados um documento XML que deve atender oleiaute definido na documentao do Web Service acessado:

xml

cUF Estrutura XML definida na documentao do Web Service

Padro de Mensagem de chamada/retorno de Web Service

Elemento cteCabecMsg (SOAP Header) rea de dados (SOAP Body)versaoDados


23/134



Pg. 23/ 134

3.4.2 Validao da estrutura XML das Mensagens dos Web Services

As informaes so enviadas ou recebidas dos Web Services atravs de mensagens no padro XMLdefinido na documentao de cada Web Service.

As alteraes de leiaute e da estrutura de dados XML realizadas nas mensagens so controladasatravs da atribuio de um nmero de verso para a mensagem.

Um Schema XML uma linguagem que define o contedo do documento XML, descrevendo os seuselementos e a sua organizao, alm de estabelecer regras de preenchimento de contedo e deobrigatoriedade de cada elemento ou grupo de informao.

A validao da estrutura XML da mensagem realizada por um analisador sinttico (parser) queverifica se a mensagem atende as definies e regras de seu Schema XML.

Qualquer divergncia da estrutura XML da mensagem em relao ao seu Schema XML, provoca umerro de validao do Schema XML.

A primeira condio para que a mensagem seja validada com sucesso que ela seja submetida aoSchema XML correto.

Assim, os aplicativos do contribuinte devem estar preparados para gerar as mensagens no leiaute emvigor, devendo ainda informar a verso do leiaute da estrutura XML da mensagem no campoversaoDados do elemento cteCabecMsg do SOAP Header.

351.00

3.4.3 Schemas XML das Mensagens dos Web Services

Toda mudana de leiaute das mensagens dos Web Services implica na atualizao do seurespectivo Schema XML.

A identificao da verso dos Schemas ser realizada com o acrscimo do nmero daverso no nome do arquivo precedida da literal _v, como segue:

cte_v1.00.xsd (Schema XML do CTe, verso 1.00);tiposBasico_v10.15.xsd (Schema XML dos tipos bsicos do CTe, verso 10.15).

A maioria dos Schemas XML do CT-e utilizam as definies de tipos bsicos ou tiposcomplexos que esto definidos em outros Schemas XML (ex.: tiposBasico_v1.00.xsd, etc.),nestes casos, a modificao de verso do Schema bsico ser repercutida no Schemaprincipal.

Por exemplo, o tipo numrico de 15 posies com 2 decimais definido no Schema

tiposBasico_v1.01.xsd, caso ocorra alguma modificao na definio deste tipo, todos osSchemas que utilizam este tipo bsico devem ter a sua verso atualizada e as declaraesimport ou include devem ser atualizadas com o nome do Schema bsico atualizado.


24/134



Pg. 24/ 134

Exemplo de Schema XML


As modificaes de leiaute das mensagens dos Web Services podem ser causadas pornecessidades tcnicas ou em razo da modificao de alguma legislao. As modificaesdecorrentes de alterao da legislao devero ser implementadas nos prazos previstos noato normativo que introduziu a alterao. As modificaes de ordem tcnica sero

divulgadas pela Coordenao Tcnica do ENCAT e podero ocorrer sempre que se fizeremnecessrias.

3.5 Verso dos Schemas

3.5.1 Liberao das verses dos Schemas para o Projeto do CT Eletrnico

Os schemas vlidos para o Projeto do Conhecimento de Transporte Eletrnico serodisponibilizados no sitio nacional do Projeto (www.nfe.fazenda.gov.br), e sero liberadosaps autorizao da equipe de Gesto do Projeto formada pelos Lderes dos Projetos nos

Estados e representante das Empresas.A cada nova liberao ser disponibilizado um arquivo compactado contendo o conjunto deschemas a serem utilizados pelas empresas para a gerao dos arquivos XML. Este arquivoser denominado Pacote de Liberao e ter a mesma numerao da verso do Manualde Integrao que lhe compatvel. Os pacotes de liberao sero identificados pelas letrasPL_ CTe, seguida do nmero da verso do Manual de Integrao correspondente.Exemplificando: O pacote PL_CTe_1.00.zip representa o Pacote de Liberao de schemasdo Conhecimento de Transporte eletrnico compatveis com o Manual de Integrao doContribuinte verso 1.00.

Os schemas XML das mensagens XML do projeto so identificados pelo seu nome, seguido

da verso do respectivo schema.

Assim, para o schema XML de Envio de Lotes de Conhecimento de Transporte eletrnico,corresponder um arquivo com a extenso .xsd, que ter o nome decteEnvLote_v9.99.xsd, onde v9.99, corresponde a verso do respectivo schema.

Para identificar quais os schemas que sofreram alterao em um determinado pacoteliberado, deve-se comparar o nmero da verso do schema deste pacote com o do pacoteanterior.

Exemplificando:

PACOTE PL_ CTe_ 1.00.ZIP PL_CTe_ 1.01.ZIPDATA LIBERAO 01/04/2008 01/06/2008


25/134



Pg. 25/ 134

cteEnvLote_v1.00.xsd cteEnvLote _v1.30.xsdinutCTe_v1.00.xsd inutCTe_v1.00.xsdcancCTe_v1.00.xsd cancCTe_v1.00.xsd

SCHEMAS

tiposBasico_v1.00.xsd tiposBasico _v1.01.xsd

3.5.2 Pacote de Liberao Preliminar

Aps a divulgao de uma nova verso do Manual de Integrao do Contribuinte, serdivulgado um pacote de liberao preliminar com vigncia limitada at o incio da fase dedisponibilizao do ambiente de homologao.

Durante este perodo, os novos Schemas XML sero avaliados e testados para aidentificao de eventuais falhas de implementao das alteraes realizadas no Manual deIntegrao do Contribuinte.

O PL preliminar ser identificado com o acrscimo da literal pre na identificao do pacote,como por exemplo: PL_CTe_1.00pre.zip.

3.5.3 Pacote de Liberao de Homologao e Pacote de libero definitivo

Para o ambiente de homologao ser um divulgado um pacote de liberao dehomologao que ser identificado com o acrscimo da literal hom na identificao dopacote, como por exemplo: PL_CTe_100hom.zip.

A principal caracterstica do pacote de liberao de homologao seu uso estar restrito aoambiente de homologao por aceitar somente mensagens XML com tpAmb=2-

homologao.

O pacote de liberao definitivo ser divulgado na vspera da data de incio da vigncia doambiente de produo.

3.5.4 Correo de Pacote de Liberao

Em algumas situaes pode surgir a necessidade de correo de um Schema XML por umerro de implementao de regra de validao, obrigatoriedade de campo, nome de tagdivergente do definido no leiaute da mensagem, que no modifica a estrutura do SchemaXML e nem exige a alterao dos aplicativos da SEFAZ ou dos contribuintes.

Nesta situao, divulgaremos um novo pacote de liberao com o Schema XML corrigido,sem modificar o nmero da verso do PL para manter a compatibilidade com o Manual deIntegrao do Contribuinte vigente.

A identificao dos pacotes mais recentes se dar com o acrscimo de letras minscula doalfabeto, como por exemplo: CTe_PL_1.00a.ZIP, indicando que se trata da primeira versocorrigida do CTe_PL_1.00.ZIP

3.5.5 Divulgao de novos Pacotes de Liberao


26/134



Pg. 26/ 134

A divulgao de novos pacotes de liberao ou atualizaes de pacote de liberao serrealizada atravs da publicao de Notas Tcnicas no Portal Nacional do CT-e(www.nfe.fazenda.gov.br) com as informaes necessrias para a implementao dosnovos pacotes de liberao.

3.5.6 Controle de Verso

O controle de verso de cada um dos schemas vlidos para o Projeto Conhecimento deTransporte Eletrnico compreende uma definio nacional sobre:

qual a verso vigente (verso mais atualizada); quais so as verses anteriores ainda suportadas por todas as SEFAZ.

Este controle de verses permite a adaptao dos sistemas de informtica das empresasparticipantes do Projeto em diferentes datas. Ou seja, algumas empresas podero estar comuma verso de leiaute mais atualizada, enquanto outras empresas podero ainda estaroperando com mensagens em um leiaute anterior.

No esto previstas mudanas freqentes de leiaute de mensagens e as empresas deveroter um prazo razovel para implementar as mudanas necessrias, conforme acordooperacional a ser estabelecido.

Mensagens recebidas com uma verso de leiaute no suportada sero rejeitadas com umamensagem de erro especfica na verso do leiaute de resposta mais recente em uso.

3.6 SEFAZ VIRTUAL

As Secretarias da Fazenda Estadual podem optar por no desenvolver sistemas prprios deautorizao da emisso do Conhecimento de Transporte Eletrnico para os Contribuintes dasua jurisdio. Neste caso, os servios da autorizao de emisso do CT-e sero supridospor uma SEFAZ VIRTUAL, atravs de um Protocolo de cooperao assinado entre asSEFAZ e/ou entre a SEFAZ e a RFB.

Os servios da SEFAZ VIRTUAL compreendem os Web Services descritos no ModeloConceitual da Arquitetura de Comunicao, conforme consta no item 3.1 do Manual deIntegrao com o Contribuinte,

A responsabilidade sobre o credenciamento e sobre a autorizao para o contribuinte usaros servios de uma determinada SEFAZ VIRTUAL, da SEFAZ de circunscrio do

contribuinte.

Para os sistemas das Empresas, deve ser totalmente transparente se os servios estosendo disponibilizados pela SEFAZ VIRTUAL ou por um sistema de autorizao da prpriaSEFAZ de circunscrio do contribuinte. A nica mudana visvel no endereo dos WebServices onde ficam disponibilizados os servios.


27/134



Pg. 27/ 134

4. Web Services

Os Web Services disponibilizam os servios que sero utilizados pelos aplicativos doscontribuintes. O mecanismo de utilizao dos Web Services segue as seguintes premissas:

a) Ser disponibilizado um Web Service por servio, existindo um mtodo para cadatipo de servio;

b) Para os servios assncronos, o mtodo de envio retorna uma mensagem deconfirmao de recebimento da solicitao de servio com o recibo e a data e horalocal de recebimento da solicitao ou retorna uma mensagem de erro.

As Secretarias de Fazenda Estaduais se comprometem a processar os lotes deconhecimentos de transportes recebidas em at 3 minutos em no mnimo 95% dototal do volume recebido no perodo de 24 horas. Este indicador de performance serconstantemente avaliado e aperfeioado pelo Comit Gestor e os contribuintesemissores de CT-e.

A qualquer momento as empresas podero verificar a performance do servio deprocessamento dos lotes, verificando o tempo mdio de resposta do servio nosltimos 5 minutos. A empresa poder optar por entrar em contingncia, ou seja,emitir o DANFE em formulrio de segurana, caso julgue que o tempo de respostano aceitvel.

No recibo de recepo do lote, tambm ser informado o tempo mdio de respostado servio nos ltimos 5 minutos.

Cada Portal de Secretaria de Fazenda Estadual disponibilizar o resultado doprocessamento do lote por um perodo mnimo de 24 horas (cteConsLote). Aps otrmino do processamento, a informao da situao atual de cada conhecimento detransporte ser disponibilizada para consulta individual (consSitCTe).

c) Para os servios sncronos, o envio da solicitao e a obteno do retorno serorealizados na mesma conexo atravs de um nico mtodo.

d) As URLs dos Web Services encontram-se no Anexo IV deste manual e no Portaldo Ambiente Nacional (www.nfe.fazenda.gov.br). Acessando a URL pode ser obtidoo WSDL (Web Services Description Language) de cada Web Service.

e) O processo de utilizao dos Web Services sempre iniciado pelo contribuinteenviando uma mensagem nos padres XML e SOAP, atravs do protocolo SSL comautenticao mtua.

f) A ocorrncia de qualquer erro na validao dos dados recebidos interrompe oprocesso com a disponibilizao de uma mensagem contendo o cdigo e a descriodo erro.


28/134



Pg. 28/ 134

4.1 Servio de Recepo de CT-e

O Servio de Recepo de CT-e o servio oferecido pelos Portais das Secretarias daFazenda dos Estados para recepo dos CT-e emitidos pelos contribuintes credenciados

em sua unidade federada.

A forma de processamento do servio de recepo de CT-e assncrona. O contribuintedeve transmitir o lote de CT-e atravs do Web Service de recepo de lote de CT-e e buscaro resultado do processamento do Lote de CT-e no Web Service de consulta resultado deprocessamento de lote

4.1.1 Web Service CteRecepcao

Contribuinte

Client CT-e

Secretaria de Fazenda Estadual

Aplicao CT-e

ProcessamentoEnvio do lote de CT-e-

Filas de Entrada .

Transmisso de Lote de CT-e-

cteRecepcaoLote

Web Service:CteRecepcao

msgs Proc.

Recibo

Contribuinte

Client CT-e

Secretaria de Fazenda Estadual

Aplicao CT-e

ProcessamentoEnvio do lote de CT-e-

Filas de Entrada .

Transmisso de Lote de CT-e-

cteRecepcaoLote

Web Service:CteRecepcao

msgs Proc.

Recibo

Funo: servio destinado recepo de mensagens de lote de CT-e.

Processo: assncrono.

Mtodo: cteRecepcaoLote

4.1.2 Leiaute Mensagem de Entrada

Entrada: Estrutura XML com o lote de conhecimento de transporte

Schema XML: enviCte_v99.99.xsd


AP01 enviCTe Raiz - - - - TAG raizAP02 Verso A AP01 N 1-1 1-4 2 Verso do leiaute

AP03 idLote E AP01 N 1-1 1-15 Identificador de controle do envio do lote.Nmero seqencial auto-incremental, decontrole correspondente ao identificador nicodo lote enviado. A responsabilidade de gerar econtrolar esse nmero exclusiva docontribuinte.

AP04 CTe G AP01 xml 1-50 - Conjunto de CT-es transmitidos (mximo de 50CT-e), seguindo definio do Anexo I - Leiautedo CT-e. O tamanho mximo do lote de 500kpode limitar a quantidade mxima de CT-etambm).


29/134



Pg. 29/ 134

4.1.3 Leiaute Mensagem de Retorno

Retorno: Estrutura XML com a mensagem do resultado da transmisso.

Schema XML: retEnviCte_v99.99.xsd


AR01 retEnviCte Raiz - - - - TAG raiz da Resposta

AR02 versao A AR01 N 1-1 1-4 2 Verso do leiaute

AR03 tpAmb E AR01 N 1-1 1 Identificao do Ambiente:1 Produo / 2 - Homologao

AR04 verAplic E AR01 C 1-1 1-20 Verso do Aplicativo que recebeu o Lote.

AR05 cStat E AR01 N 1-1 3 Cdigo do status da resposta (vide item 5.1.1)

AR06 xMotivo E AR01 C 1-1 1-255 Descrio literal do status da resposta

AR06acUF E AR01 N 1-1 2 Cdigo da UF que atendeu a solicitao.AR07 infRec G AR01 - 0-1 - Dados do Recibo do Lote (S gerado se o

Lote for aceito)

AR08 nRec E AR07 N 1-1 15 Nmero do Recibo gerado pelo Portal daSecretaria de Fazenda Estadual, composto porduas posies com o Cdigo da UF(codificao do IBGE) onde foi entregue oLote, uma posio para o Tipo de Autorizadore doze posies numricas seqenciais (videitem 5.5)

AR09 dhRecbto E AR07 D 1-1 - Data e Hora do RecebimentoFormato = AAAA-MM-DDTHH:MM:SSPreenchido com data e hora do recebimentodo lote.

AR10 tMed E AR07 N 1-1 N 1-4 Tempo mdio de resposta do servio (emsegundos) dos ltimos 5 minutos (vide item

5.7).Nota: Caso o tempo mdio de resposta fiqueabaixo de 1 (um) segundo, o tempo serinformado como 1 segundo. Arredondar asfraes de segundos para cima.

As mensagens recebidas com erro geram uma mensagem de erro. Nas demais hiptesesser retornado um recibo com nmero, data, hora local de recebimento e tempo mdio deresposta do servio nos ltimos 5 minutos.

O nmero do recibo gerado pelo Portal da Secretaria de Fazenda Estadual ser a chave deacesso do servio de consulta ao resultado do processamento do lote.

4.1.4 Descrio do Processo de Recepo de Lotes de CT-e

Este mtodo ser responsvel por receber as mensagens de envio de lotes de CT-e ecoloc-las na fila de entrada.

Existe um limite de at 50 CT-e por lote e o agrupamento destas CT-e dentro do lote podeser feito de qualquer uma das formas que seguem:

todos os CT-e so do mesmo estabelecimento (mesmo CNPJ do Emitente); todos os CT-e so da mesma empresa (mesmo CNPJ-Base do Emitente); os CT-e so de diferentes Empresas.


30/134



Pg. 30/ 134

Em qualquer um dos casos acima, por uma restrio operacional e de controle, todos osCNPJ emitentes devem ser da mesma Unidade da Federao.

O tamanho mximo do lote de CT-e limitado em 500k, assim o contribuinte deve comporum lote de envio de CT-e que no ultrapasse este limite, mesmo que a quantidade de CT-e

do lote esteja dentro do limite de 50 conhecimentos.Devero ser realizadas as validaes e procedimentos que seguem.

4.1.5 Validao do Certificado de Transmisso

Validao do Certificado Digital do Transmissor (protocolo SSL)

# Regra de Validao Crtica Msg Efeito

A01 Certificado de Transmissor Invlido:- Certificado de Transmissor inexistente na mensagem- Verso difere "3"- Basic Constraint = true (no pode ser Certificado de AC)- KeyUsage no define "Autenticao Cliente"

Obrig. 280 Rej.

A02 Validade do Certificado (data incio e data fim) Obrig. 281 Rej.

A03 Verifica a Cadeia de Certificao:- Certificado da AC emissora no cadastrado na SEFAZ- Certificado de AC revogado- Certificado no assinado pela AC emissora do Certificado

Obrig. 283 Rej.

A04 LCR do Certificado de Transmissor- Falta o endereo da LCR (CRL DistributionPoint)- LCR indisponvel- LCR invlida

Obrig. 286 Rej.

A05 Certificado do Transmissor revogado Obrig. 284 Rej.A06 Certificado Raiz difere da "ICP-Brasil" Obrig. 285 Rej.

A07 Falta a extenso de CNPJ no Certificado (OtherName -OID=2.16.76.1.3.3)

Obrig. 282 Rej.

As validaes de A01, A02, A03, A04 e A05 so realizadas pelo protocolo SSL e noprecisam ser implementadas. A validao A06 tambm pode ser realizada pelo protocoloSSL, mas pode falhar se existirem outros certificados digitais de Autoridade CertificadoraRaiz que no sejam ICP-Brasil no repositrio de certificados digitais do servidor de WebService da SEFAZ.

4.1.6 Validao Inicial da Mensagem no Web Service

Validao Inicial da Mensagem no Web Service

# Regra de Validao Aplic. Msg Efeito

B01 Tamanho do XML de Dados superior a 500 Kbytes Obrig. 214 Rej.

B02 XML de Dados Mal Formado Facult. 243 Rej.

B03 Verifica se o Servidor de Processamento est ParalisadoMomentaneamente

Obrig. 108 Rej.

B04 Verifica se o Servidor de Processamento est Paralisado semPreviso

Obrig. 109 Rej.


31/134



Pg. 31/ 134

A mensagem ser descartada se o tamanho exceder o limite previsto (500 KB). A aplicaodo contribuinte no poder permitir a gerao de mensagem com tamanho superior a 500KB. Caso isto ocorra, a conexo poder ser interrompida sem mensagem de erro se ocontrole do tamanho da mensagem for implementado por configuraes do ambiente derede da SEFAZ (ex.: controle no firewall). No caso do controle de tamanho ser

implementado por aplicativo teremos a devoluo da mensagem de erro 214.A critrio de cada unidade federada poder ser verificado se o XML de dados est bemformado, no momento do recebimento da mensagem no Web Service. Esta verificao tilpara as UF que desejarem armazenar o XML de dados em estrutura XML de banco dedados.

As unidades federadas que mantm o Web Service disponvel, mesmo quando o servioestiver paralisado, devero implementar as verificaes 108 e 109. Estas validaespodero ser dispensadas se o Web Service no ficar disponvel quando o servio estiverparalisado.

4.1.7 Validao das informaes de controle da chamada ao Web Service

Validao das informaes de controle da chamada ao Web Service# Regra de Validao Aplic. Msg Efeito

C01 Elemento cteCabecMsg inexistente no SOAP Header Facult. 242 Rej.

C02 Campo cUF inexistente no elemento cteCabecMsg do SOAP Header Obrig. 409 Rej.

C03 Verificar se a UF informada no campo cUF atendida peloWebService

Obrig. 410 Rej.

C04 Campo versaoDados inexistente no elemento cteCabecMsg do

SOAP Header

Obrig. 411 Rej.

C05 Verso dos Dados informada superior verso vigente Facult. 238 Rej.

C06 Verso dos Dados no suportada Obrig. 239 Rej.

A informao da verso do leiaute do lote e a UF de origem do emissor dos conhecimentosso informados no elemento cteCabecMsg do SOAP Header (para maiores detalhes videitem 3.4.1).

A aplicao dever validar os campos cUF e versaoDados, rejeitando o lote recebido emcaso de informaes inexistentes ou invlidas.

O campo versaoDados contm a verso do Schema XML da mensagem contida na rea dedados que deve ser utilizado pelo Servidor de Processamento da CT-e na validao doSchema XML do lote. Cabe ressaltar que um lote deve conter somente CT-e da mesmaverso.

4.1.8 Gerao da Resposta com o Recibo

No existindo qualquer problema nas validaes acima referidas, o aplicativo dever gerarum nmero de recibo (vide item 5.5)e gravar a mensagem, juntamente com o nmero dorecibo, o CNPJ do transmissor, verso da mensagem e o cdigo da UF de origem.


32/134



Pg. 32/ 134

Aps a gravao da mensagem na fila de entrada ser retornada uma mensagem deconfirmao de recebimento para o transmissor, com as seguintes informaes:

a identificao do ambiente; a verso do aplicativo;

o cdigo 103 e o literal Lote recebido com Sucesso; o cdigo da UF que atendeu a solicitao; o nmero do recibo (vide item 5.5), com data, hora local de recebimento da

mensagem; tempo mdio de resposta do servio de processamento dos lotes nos ltimos 5

minutos (vide detalhamento da forma de clculo no item 5.7).

Caso ocorra algum problema de validao, o aplicativo dever retornar uma mensagem comas seguintes informaes:

a identificao do ambiente; a verso do aplicativo; o cdigo e a respectiva mensagem de erro (vide a tabela do item 5.1.1); o cdigo da UF que atendeu a solicitao;

4.1.9 Descrio do Processamento do Lote de CT-e

O processamento de Lote de CT-e recepcionada realizada pelo Servidor deProcessamento de CT-e que consome as mensagens armazenadas na fila de entrada pelomtodo CteRecepcao e faz a validao de forma e das regras de negcios e armazena oresultado do processamento na fila de sada.

4.1.10 Validao da rea de Dados

a) Validao de forma da rea de dados

A validao de forma da rea de dados da mensagem realizada com a aplicao daseguinte regra:

Validao da rea de dados da mensagem


D01 Verifica Schema XML da rea de Dados Obrig. 225 Rej.D02 Verifica o uso de prefixo no namespace Obrig. 404 Rej.

D03 XML utiliza codificao diferente de UTF-8 Obrig. 402 Rej.

Como a validao do Schema XML realizada em toda mensagem de entrada, a existnciade um erro em um CT-e implica na rejeio de todo o lote.

b) Validao do Certificado Digital de Assinatura

A seguir so extradas todas CT-e das mensagens de envio de lote e validadas as seguintesregras de negcios para cada CT-e:

Validao do Certificado Digital utilizado na Assinatura Digital do CT-e


33/134



Pg. 33/ 134


E01 Certificado de Assinatura invlido:- Certificado de Assinatura inexistente na mensagem (*validadotambm pelo Schema)- Verso difere "3"

- Basic Constraints = true (no pode ser Certificado de AC)- KeyUsage no define "Assinatura Digital" e No Recusa

Obrig. 290 Rej.

E02 Validade do Certificado (data incio e data fim) Obrig. 291 Rej.

E03 Falta a extenso de CNPJ no Certificado (OtherName -OID=2.16.76.1.3.3)

Obrig. 292 Rej.

E04 Verifica Cadeia de Certificao:- Certificado da AC emissora no cadastrado na SEFAZ- Certificado de AC revogado- Certificado no assinado pela AC emissora do Certificado

Obrig. 293 Rej.

E05 LCR do Certificado de Assinatura:- Falta o endereo da LCR (CRLDistributionPoint)- Erro no acesso a LCR ou LCR inexistente

Obrig. 296 Rej.

E06 Certificado de Assinatura revogado Obrig. 294 Rej.

E07 Certificado Raiz difere da ICP-Brasil Obrig. 295 Rej.

c) Validao da Assinatura Digital

Validao da Assinatura Digital do CT-e


F01 Assinatura difere do padro do Projeto:- No assinado o atributo "ID" (falta "Reference URI" na assinatura)

(*validado tambm pelo Schema)- Faltam os "Transform Algorithm" previstos na assinatura ("C14N" e"Enveloped")Estas validaes so implementadas pelo Schema XML da Signature

Obrig. 298 Rej.

F02 Valor da assinatura (SignatureValue) difere do valor calculado Obrig. 297 Rej.

F03 CNPJ-Base do Emitente difere do CNPJ-Base do Certificado Digital Obrig. 213 Rej.

F04 CNPJ do Certificado Digital difere do CNPJ da Matriz e do CNPJ doEmitente

Facult. 244 Rej.

d) Validao de regras de negcios do CT-e

Validao do CT-e Regras de Negcios


G01 Tipo do ambiente do CT-e difere do ambiente do Web Service Obrig. 252 Rej.

G02 Cdigo da UF do Emitente difere da UF do Web Service Obrig. 226 Rej.

G03 Sigla da UF do Emitente difere da UF do Web Service Obrig. 247 Rej.

G04 Campo ID invlido- Falta literal "CTe"- Chave de Acesso do campo ID difere da concatenao dos camposcorrespondentes

Obrig. 227 Rej.

G05 Dgito Verificador invlido da Chave de acesso resultante daconcatenao dos campos correspondentes

Obrig. 253 Rej.


34/134



Pg. 34/ 134



G06 CNPJ Emitente invlido (dgito controle, zeros ou nulo) Obrig. 207 Rej.

G07 IE Emitente no informada (zeros ou nulo) Obrig. 229 Rej.

G08 IE Emitente invlida (erro no dgito de controle)Obs.: Antes da validao, a IE dever ser normalizada, na aplicao daSEFAZ, com o acrscimo de zeros no significativos previstos na definiodo formato da IE se necessrio.Ex.: IE informada 130000019, formato da IE: NNNNNNNNNND, a IE deveser padronizada para 00130000019, com o acrscimo dos zeros nosignificativos necessrios para a validao do dgito verificador.

Obrig. 209 Rej.

G09 Acessar Cadastro Contribuinte p/ Emitente:- CNPJ emitente no cadastrado

Facult. 245 Rej.

G10 - Emitente no credenciado Obrig. 203 Rej.

G11 - IE Emitente no cadastrada Facult. 230 Rej.

G12 - IE Emitente no vinculada ao CNPJ Obrig. 231 Rej.

G13 - Emitente em situao irregular perante o Fisco (tratar duplicidadena insero do CT-e, evitando a insero de mais de um CT-edenegado)

Obrig. 301ou205

Den.

G14 Data de Emisso posterior a data de recebimento(a SEFAZ Virutal deve considerar a hora local do emissor para avalidao)

Obrig. 212 Rej.

G15 Data de Emisso ocorrida h mais de 60 dias, ou outro limiteconforme critrio definido pela SEFAZ (a SEFAZ Virutal deveconsiderar a hora local do emissor para a validao)

Obrig. 228 Rej.

G16 CNPJ Remetente informado: CNPJ invlido (dgito de controle, zeros) Obrig. 415 Rej.

G17 CPF Remetente informado: CPF invlido (dgito de controle, zeros) Obrig. 416 Rej.

G18 Remetente informado: Cdigo Municpio invlido (dgito de controle),vide item 2.1 do Anexo III.

Facult. 417 Rej.

G19 Remetente informado: Municpio diverge da UF (verificar se as 2posies da esquerda do cdigo de municpio que identifica o cdigoda UF compatvel com a sigla da UF informada)

Obrig. 418 Rej

G20 IE Remetente informado: IE invlida (erro no dgito de controle)Obs.: Antes da validao, a IE dever ser normalizada, na aplicao daSEFAZ, com o acrscimo de zeros no significativos previstos na definiodo formato da IE se necessrio.Ex.: IE informada 130000019, formato da IE: NNNNNNNNNND, a IE deveser padronizada para 00130000019, com o acrscimo dos zeros nosignificativos necessrios para a validao do dgito verificador.

Obrig. 419 Rej..

G21 Se o Remetente informado for contribuinte do ICMS na UFautorizadora:- Acessar Cadastro Contribuinte p/ Remetente:

. Se CNPJ Remetente informado: CNPJ no cadastrado

Facult. 420 Rej.

G22 . IE Remetente informada: IE no cadastrada Facult. 421 Rej.

G23 . IE e CNPJ Remetente informados: IE no vinculada ao CNPJ Facult. 422 Rej.

G24 . CNPJ ou IE Remetente informado: Remetente em situaoirregular perante o Fisco (tratar duplicidade na insero do CT-e,evitando a insero de mais de um CT-e denegado)

Facult. 302ou205

Den.

G25 CNPJ Destinatrio informado: CNPJ invlido (dgito de controle,zeros)

Obrig. 208 Rej.

G26 CPF Destinatrio informado: CPF invlido (dgito de controle, zeros) Obrig. 237 Rej.


35/134



Pg. 35/ 134



G27 Destinatrio informado: Cdigo Municpio invlido (dgito decontrole), vide item 2.1 do Anexo III.

Facult. 423 Rej.

G28 Destinatrio informado: Municpio diverge da UF (verificar se as 2posies da esquerda do cdigo de municpio que identifica o cdigoda UF esto de acordo com a sigla da UF informada)

Obrig. 424 Rej.

G29 IE Destinatrio informado: IE invlida (erro no dgito de controle oucontedo diferente de ISENTO)Obs.: Antes da validao, a IE dever ser normalizada, na aplicao daSEFAZ, com o acrscimo de zeros no significativos previstos na definiodo formato da IE se necessrio.Ex.: IE informada 130000019, formato da IE: NNNNNNNNNND, a IE deveser padronizada para 00130000019, com o acrscimo dos zeros nosignificativos necessrios para a validao do dgito verificador.

Obrig. 210 Rej.

G30 Se o Destinatrio informado for contribuinte do ICMS na UF

autorizadora:- Acessar Cadastro Contribuinte p/ Destinatrio:

. Se CNPJ Destinatrio informado: CNPJ no cadastrado

Facult. 425 Rej.

G31 . IE Destinatrio informada: IE no cadastrada Facult. 426 Rej.

G32 . IE e CNPJ Destinatrio informados: IE no vinculada ao CNPJ Facult. 427 Rej.

G33 . CNPJ ou IE Destinatrio informado: Destinatrio em situaoirregular perante o Fisco (tratar duplicidade na insero do CT-e,evitando a insero de mais de um CT-e denegado)

Facult. 303ou205

Den.

G34 CNPJ Expedidor informado: CNPJ invlido (dgito de controle, zeros) Obrig. 428 Rej.

G35 CPF Expedidor informado: CPF invlido (dgito de controle, zeros) Obrig. 429 Rej.

G36 Expedidor informado: Cdigo Municpio invlido (dgito de controle),

vide item 2.1 do Anexo III.

Facult. 430 Rej.

G37 Expedidor informado: Municpio diverge da UF (verificar se as 2posies da esquerda do cdigo de municpio que identifica o cdigoda UF esto de acordo com a sigla da UF informada)

Obrig. 431 Rej.

G38 IE Expedidor informado: IE invlida (erro no dgito de controle)Obs.: Antes da validao, a IE dever ser normalizada, na aplicao daSEFAZ, com o acrscimo de zeros no significativos previstos na definiodo formato da IE se necessrio.Ex.: IE informada 130000019, formato da IE: NNNNNNNNNND, a IE deveser padronizada para 00130000019, com o acrscimo dos zeros nosignificativos necessrios para a validao do dgito verificador.

Obrig. 432 Rej.

G39 Se o Expedidor for contribuinte do ICMS na UF autorizadora:- Acessar Cadastro Contribuinte p/ Expedidor:. Se CNPJ Expedidor informado: CNPJ no cadastrado

Facult. 433 Rej.

G40 . IE Expedidor informada: IE no cadastrada Facult. 434 Rej.

G41 . IE e CNPJ Expedidor informados: IE no vinculada ao CNPJ Facult. 435 Rej.

G42 . CNPJ ou IE Expedidor informado: Expedidor em situao irregularperante o Fisco (tratar duplicidade na insero do CT-e, evitando ainsero de mais de um CT-e denegado)

Facult. 304ou205

Den.

G43 CNPJ Recebedor informado: CNPJ invlido (dgito de controle, zeros) Obrig. 436 Rej.

G44 CPF Recebedor informado: CPF invlido (dgito de controle, zeros) Obrig. 437 Rej.

G45 Expedidor informado: Cdigo Municpio invlido (dgito de controle),

vide item 2.1 do Anexo III.

Facult. 438 Rej.


36/134



Pg. 36/ 134



G46 Expedidor informado: Municpio diverge da UF (verificar se as 2posies da esquerda do cdigo de municpio que identifica o cdigoda UF esto de acordo com a sigla da UF informada)

Obrig. 439 Rej.

G47 IE Recebedor informado: IE invlida (erro no dgito de controle)Obs.: Antes da validao, a IE dever ser normalizada, na aplicao daSEFAZ, com o acrscimo de zeros no significativos previstos na definiodo formato da IE se necessrio.Ex.: IE informada 130000019, formato da IE: NNNNNNNNNND, a IE deveser padronizada para 00130000019, com o acrscimo dos zeros nosignificativos necessrios para a validao do dgito verificador.

Obrig. 440 Rej.

G48 Se Recebedor informado for contribuinte do ICMS na UFautorizadora:- Acessar Cadastro Contribuinte p/ Recebedor:

. Se CNPJ Recebedor informado: CNPJ no cadastrado

Facult. 441 Rej.

G49 . IE Recebedor informada: IE no cadastrada Facult. 442 Rej.

G50 . IE e CNPJ Recebedor informados: IE no vinculada ao CNPJ Facult. 443 Rej.

G51 . CNPJ ou IE Recebedor informado: Recebedor em situaoirregular perante o Fisco (tratar duplicidade na insero do CT-e,evitando a insero de mais de um CT-e denegado)

Facult. 305ou205

Den.

G52 CNPJ Tomador informado: CNPJ invlido (dgito de controle, zeros) Obrig. 444 Rej.

G53 CPF Tomador informado: CPF invlido (dgito de controle, zeros) Obrig. 445 Rej.

G54 Tomador informado: Cdigo Municpio invlido (dgito de controle),vide item 2.1 do Anexo III.

Facult. 446 Rej.

G55 Tomador informado: Municpio diverge da UF (verificar se as 2posies da esquerda do cdigo de municpio que identifica o cdigo

da UF esto de acordo com a sigla da UF informada)

Obrig. 447 Rej.

G56 IE Tomador informado: IE invlida (erro no dgito de controle)Obs.: Antes da validao, a IE dever ser normalizada, na aplicao daSEFAZ, com o acrscimo de zeros no significativos previstos na definiodo formato da IE se necessrio.Ex.: IE informada 130000019, formato da IE: NNNNNNNNNND, a IE deveser padronizada para 00130000019, com o acrscimo dos zeros nosignificativos necessrios para a validao do dgito verificador.

Obrig. 448 Rej.

G57 Se o Tomador do servio for contribuinte do ICMS na UFautorizadora:- Acessar Cadastro Contribuinte p/ Tomador:

. Se CNPJ Tomador informado: CNPJ no cadastrado

Facult. 449 Rej.

G58 . IE Tomador informada: IE no cadastrada Facult. 450 Rej.G59 . IE e CNPJ Tomador informados: IE no vinculada ao CNPJ Facult. 451 Rej.

G60 . CNPJ ou IE Tomador informado: Tomador em situao irregularperante o Fisco (tratar duplicidade na insero do CT-e, evitando ainsero de mais de um CT-e denegado)

Facult. 306ou205

Den.

G61 Inscr. SUFRAMA do Destinatrio informada: verificar dgito controle Obrig. 235 Rej.

G62 Inscr. SUFRAMA informada: verificar UF destinatrio = AC-Acre, ouAM-Amazonas, ou RO-Rondnia, ou RR-Roraima, ou AP-Amap(s para municpios 1600303-Macap e 1600600-Santana)

Obrig. 251 Rej.

G63 Acesso BD CTE (Chave: Ano, CNPJ Emit, Modelo, Srie, Nro):- CT-e j cadastrado e no Cancelado/Denegado

Obrig. 204 Rej.

G60 - Verificar se CT-e j est Cancelado Obrig. 218 Rej.


37/134



Pg. 37/ 134



G61 - Verificar se CT-e j est Denegado Obrig. 205 Rej.

G62 Acesso BD CTE-Inutilizao- Verificar Nmero do CT-e Inutilizado

Obrig. 206 Rej.

G63 Se finalidade do CT-e = 1 (CT-e complementar): verificar se foiinformado pelo menos um CT-e ou CTRC referenciado

Obrig. 254 Rej.

G64 Se finalidade do CT-e = 1 (CT-e complementar): verificar se o(s)Conhecimento(s) referenciados (eletrnico ou normal) so emitidospelo mesmo CNPJ.

Obrig. 269 Rej.

G65 Se finalidade do CT-e = 1 (CT-e complementar): verificar se existe(m) o(s) CT-e referenciado(s).Acesso BD CTE (Chave: Ano, Ms, CNPJ Emit, Modelo, Srie, Nro)

Facult. 267 Rej.

G66 Se finalidade do CT-e = 1 (CT-e complementar): verificar se o(s) CT-e referenciado(s) (so) normal(is).Acesso BD CTE (Chave: Ano, Ms, CNPJ Emit, Modelo, Srie, Nro)

Facult. 452 Rej.

G67 Cdigo Municpio de emisso do CT-e invlido (dgito de controle),vide item 2.1 do Anexo III.

Facult. 453 Rej.

G68 Municpio de emisso do CT-e diverge da UF (verificar se as 2posies da esquerda do cdigo de municpio que identifica o cdigoda UF esto de acordo com a sigla da UF informada)

Obrig. 454 Rej.

G69 Cdigo Municpio de incio da prestao invlido (dgito de controle),vide item 2.1 do Anexo III.

Facult. 455 Rej.

G70 Municpio de incio da prestao diverge da UF (verificar se as 2posies da esquerda do cdigo de municpio que identifica o cdigo

da UF esto de acordo com a sigla da UF informada)

Obrig. 456 Rej.

G71 Cdigo Municpio de trmino da prestao invlido (dgito decontrole), vide item 2.1 do Anexo III.

Facult. 413 Rej.

G72 Municpio de trmino da prestao diverge da UF (verificar se as 2posies da esquerda do cdigo de municpio que identifica o cdigoda UF esto de acordo com a sigla da UF informada)

Obrig. 414 Rej.

Nota:No caso de envio de lote para a SEFAZ VIRTUAL, todos os CT-e do Lote devero serda mesma UF. Para a SEFAZ VIRTUAL, dever ser verificado se todos os CT-e so damesma UF do primeiro CT-e do Lote. Em caso negativo, rejeitar o Lote de CT-e com erro

408-REJEIO: Lote com CT-e de diferentes UF.

4.1.11 Final do Processamento

ato cotepe 08-08 manual

Documents