manual cte v101

Conhecimento de Transporte Eletrnico Manual de Integrao - Contribuinte

Pg. 1 / 133

Projeto Conhecimento de Transporte Eletrnico

Manual de Integrao - Contribuinte Padres Tcnicos de Comunicao

Verso 1.0.1 Julho 2008


Pg. 2 / 133

Controle de Verses

Verso Data 1.00 07/03/2008 - SP 1.01 02/07/2008 SP/RS


Pg. 3 / 133

Identificao e vigncia do Manual

Verso do manual 1.0.1 Data de divulgao do manual 02/07/2007 Pacote de liberao de Schemas XML PL_CTe_101 Data de incio de vigncia no ambiente de homologao A definir Data de incio de vigncia no ambiente de produo a definir

Verses de leiautes do PL_CTe_101

Leiaute verso Schema XML Observao CTe 1.01 cte_v101.xsd Leiaute do CT-e. enviCTe 1.01 enviCte_v1.01.xsd Mensagem de envio de lote de CT-e. retEnviCTe 1.01 retEnviCte_v1.01.xsd Mensagem de retorno do envio de lote de CT-e. consReciCTe 1.01 consReciCte_v1.01.xsd Mensagem de consulta processamento do lote

de CT-e transmitido. retconsReciCTe 1.01 retConsReciCte_v1.01.xsd Mensagem de retorno da consulta de

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

CT-e. retCancCTe 1.01 retCancCte_v1.01.xsd

Mensagem de retorno do resultado da solicitao do processamento de cancelamento do CT-e.

procCancCTe 1.01 procCancCte_v1.01.xsd Leiaute de compartilhamento de Pedido de cancelamento de CT-e

inutCTe 1.01 inutCTe_v1.01.xsd Mensagem de solicitao de inutilizao de numerao de CT-e.

retInutCTe 1.01 retInutCTe_v1.01.xsd Mensagem de retorno do resultado do processamento da solicitao de inutilizao de numerao de CT-e.

procInutCTe 1.01 procInutCTe_v1.01.xsd Leiaute de compartilhamento de pedido de inutilizao de numerao de CT-e

consSitCTe 1.01 consSitCte_v1.01.xsd Mensagem de consulta da situao atual da CT-e.

retConsSitCTe 1.01 retConsSitCte_v1.01.xsd Mensagem de retorno da consulta da situao atual da CT-e.

consStatServ 1.01 consStatServCte_v1.01.xsd Mensagem da consulta do status do servio de autorizao de CT-e.

retConsStatServ 1.01 retconsStatServ_v1.01.xsd Mensagem de retorno da consulta do status do servio de autorizao de CT-e.

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

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


Pg. 4 / 133

ndice

1. Introduo ......................................................................................................... 7 2. 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...................................................... 8

3. Arquitetura de Comunicao com Contribuinte................................................ 10 3.1 Modelo Conceitual................................................................................................ 10 3.2 Padres Tcnicos................................................................................................. 11

3.2.1 Padro de documento XML .......................................................................... 11 3.2.2 Padro de Comunicao .............................................................................. 13 3.2.3 Padro de Certificado Digital ........................................................................ 14 3.2.4 Padro de Assinatura Digital ........................................................................ 15 3.2.5 Validao de Assinatura Digital pela Secretaria de Fazenda Estadual ......... 17 3.2.6 Resumo dos Padres Tcnicos .................................................................... 17

3.3 Modelo operacional .............................................................................................. 18 3.3.1 Servios sncronos ....................................................................................... 18 3.3.2 Servios assncronos.................................................................................... 19 3.3.3 Filas e Mensagens........................................................................................ 21

3.4 Padro de mensagens dos Web Services ............................................................ 22 3.4.1 Informaes de controle e rea de dados das mensagens........................... 22 3.4.2 Validao da estrutura XML das Mensagens dos Web Services .................. 22 3.4.3 Schemas XML das Mensagens dos Web Services ....................................... 23

3.5 Verso dos Schemas ........................................................................................... 24 3.5.1 Liberao das verses dos Schemas para o Projeto do CT Eletrnico ......... 24 3.5.2 Pacote de Liberao Preliminar .................................................................... 25 3.5.3 Pacote de Liberao de Homologao e Pacote de liberao definitivo ....... 25 3.5.4 Correo de Pacote de Liberao ................................................................ 25 3.5.5 Divulgao de novos Pacotes de Liberao ................................................. 25 3.5.6 Controle de Verso....................................................................................... 26

3.6 SEFAZ VIRTUAL.................................................................................................. 26 4. Web Services .................................................................................................. 27

4.1 Servio de Recepo de CT-e.............................................................................. 28 4.1.1 Web Service CteRecepcao........................................................................ 28 4.1.2 Leiaute Mensagem de Entrada..................................................................... 28 4.1.3 Leiaute Mensagem de Retorno..................................................................... 29 4.1.4 Descrio do Processo de Recepo de Lotes de CT-e............................... 29 4.1.5 Validao do Certificado de Transmisso..................................................... 30 4.1.6 Validao Inicial da Mensagem no Web Service .......................................... 30 4.1.7 Validao das informaes de controle da chamada ao Web Service .......... 31 4.1.8 Gerao da Resposta com o Recibo ............................................................ 31 4.1.9 Descrio do Processamento do Lote de CT-e............................................. 32 4.1.10 Validao da rea de Dados......................................................................... 32 4.1.11 Final do Processamento do Lote .................................................................. 38

4.2 Web Service CteRetRecepcao .......................................................................... 40 4.2.1 Leiaute Mensagem de Entrada..................................................................... 40 4.2.2 Leiaute Mensagem de Retorno..................................................................... 40 4.2.3 Descrio do Processo de Web Service ....................................................... 41 4.2.4 Validao do Certificado de Transmisso..................................................... 42 4.2.5 Validao Inicial da Mensagem no Web Service .......................................... 42 4.2.6 Validao das informaes de controle da chamada ao Web Service .......... 43 4.2.7 Validao da rea de Dados ........................................................................ 43 4.2.8 Final do Processamento ............................................................................... 44

4.3 Web Service CteCancelamento......................................................................... 45


Pg. 5 / 133

4.3.1 Leiaute Mensagem de Entrada..................................................................... 45 4.3.2 Leiaute Mensagem de Retorno..................................................................... 45 4.3.3 Descrio do Processo de Web Service ....................................................... 46 4.3.4 Validao do Certificado de Transmisso..................................................... 46 4.3.5 Validao Inicial da Mensagem no Web Service .......................................... 47 4.3.6 Validao das informaes de controle da chamada ao Web Service .......... 48 4.3.7 Validao da rea de Dados ........................................................................ 48 4.3.8 Final do Processamento ............................................................................... 50

4.4 Web Service - CteInutilizacao............................................................................... 51 4.4.1 Leiaute Mensagem de Entrada..................................................................... 51 4.4.2 Leiaute Mensagem de Retorno..................................................................... 52 4.4.3 Descrio do Processo de Web Service ....................................................... 52 4.4.4 Validao do Certificado de Transmisso..................................................... 53 4.4.5 Validao Inicial da Mensagem no Web Service .......................................... 53 4.4.6 Validao das informaes de controle da chamada ao Web Service .......... 54 4.4.7 Validao da rea de Dados ........................................................................ 54 4.4.8 Final do Processamento ............................................................................... 56

4.5 Web Service CteConsulta Protocolo.................................................................. 57 4.5.1 Leiaute Mensagem de Entrada..................................................................... 57 4.5.2 Leiaute Mensagem de Retorno..................................................................... 57 4.5.3 Descrio do Processo de Web Service ....................................................... 58 4.5.4 Validao do Certificado de Transmisso..................................................... 58 4.5.5 Validao Inicial da Mensagem no Web Service .......................................... 59 4.5.6 Validao das informaes de controle da chamada ao Web Service .......... 59 4.5.7 Validao da rea de Dados ........................................................................ 60 4.5.8 Final do Processamento ............................................................................... 60

4.6 Web Service CteStatusServico.......................................................................... 61 4.6.1 Leiaute Mensagem de Entrada..................................................................... 61 4.6.2 Leiaute Mensagem de Retorno..................................................................... 61 4.6.3 Descrio do Processo de Web Service ....................................................... 62 4.6.4 Validao do Certificado de Transmisso..................................................... 62 4.6.5 Validao Inicial da Mensagem no Web Service .......................................... 63 4.6.6 Validao das informaes de controle da chamada ao Web Service .......... 63 4.6.7 Validao da rea de Dados ........................................................................ 64 4.6.8 Final do Processamento ............................................................................... 64

4.7 Web Service CadConsultaCadastro .................................................................. 65 4.7.1 Leiaute da Mensagem de Entrada ................................................................ 65 4.7.2 Leiaute da Mensagem de Retorno................................................................ 66 4.7.3 Descrio do Processo de Web Service ....................................................... 67 4.7.4 Verificao do Certificado de Transmisso................................................... 68 4.7.5 Verificao Inicial da Mensagem no Web Service......................................... 68 4.7.6 Validao da rea de Cabealho.................................................................. 69 4.7.7 Validao da rea de Dados ........................................................................ 69 4.7.8 Final do Processamento ............................................................................... 70

5. Web Services Informaes Adicionais .......................................................... 71 5.1 Regras de validao............................................................................................. 71

5.1.1 Tabela de cdigos de erros e descries de mensagens de erros................ 71 5.2 Padro de nomes para os arquivos ...................................................................... 75 5.3 Tratamento de caracteres especiais no texto de XML .......................................... 76 5.4 Chave de Acesso do CT-e ................................................................................... 77 5.5 Nmero do Recibo de Lote................................................................................... 78 5.6 Nmero do protocolo............................................................................................ 78 5.7 Tempo mdio de resposta.................................................................................... 79

6. Cdigo de Barra .............................................................................................. 80 6.1 Clculo do dgito verificador do CODE-128C........................................................ 81


Pg. 6 / 133

6.2 Representao simblica do cdigo ..................................................................... 81 7. DACTE ............................................................................................................ 82 8. Contingncia ................................................................................................... 83 9. Ambiente de Homologao / Produo ........................................................... 84 10. Distribuio do CT-e para o Tomador do Servio ............................................ 85

10.1 Processo de Distribuio...................................................................................... 85 10.2 Leiaute da Distribuio: CT-e ............................................................................... 85

11. Compartilhamento de informaes do CT-e entre rgos Pblicos................. 86 11.1 Processo de Compartilhamento ........................................................................... 86 11.2 Leiaute de compartilhamento: CT-e..................................................................... 87 11.3 Leiaute de compartilhamento: Cancelamento de CT-e ........................................ 87 11.4 Leiaute de compartilhamento: Inutilizao de Numerao de CT-e ..................... 87 11.5 Compartilhamento de documentos com outros rgos pblicos........................... 87

Anexo I Leiaute do CT-e ................................................................................................... 88 Anexo II Modelo de DACTE............................................................................................ 118 Anexo III Tabelas de UF, Municpio e Pas ..................................................................... 125

1. Tabela de cdigo de UF do IBGE .................................................................. 125 2. Tabela de cdigo de Municpio do IBGE........................................................ 125

2.1 Validao do cdigo de Municpio ...................................................................... 126 2.2 Exemplo de clculo do dgito de controle do cdigo de Municpio ...................... 126 2.3 Exceo no clculo do dgito de controle do cdigo de Municpio ...................... 127

3. Tabela de cdigo de Pas do BACEN............................................................ 127 3.1 Validao do cdigo de Pas .............................................................................. 128 3.2 Exemplo de clculo do dgito de controle do cdigo de Pas .............................. 128 3.3 Exceo no clculo do dgito de controle do cdigo de Pas .............................. 128

Anexo IV WS disponveis................................................................................................ 130 Anexo V Conjunto de caracteres Cdigo de Barras CODE-128C ................................... 132 Anexo VI Projeto Piloto do CT-e ..................................................................................... 133


Pg. 7 / 133

1. Introduo

Este documento tem por objetivo a definio das especificaes e critrios tcnicos necessrios para a integrao entre os Portais das Secretarias de Fazendas dos Estados e os sistemas de informaes das empresas emissoras de Conhecimento de Transporte eletrnico - CT-e.

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


Pg. 8 / 133

2. Consideraes Iniciais

O Projeto Conhecimento de Transporte Eletrnico (CT-e) est sendo desenvolvido, de forma integrada, 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 de Coordenadores e Administradores Tributrios Estaduais (ENCAT) a coordenao e a responsabilidade 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 como objetivo a implantao de um modelo nacional de documento fiscal eletrnico para substituir a 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 dos contribuintes 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 para possibilitar o uso do documento fiscal eletrnico em substituio aos demais documentos fiscais existentes no pas, conforme previsto no pargrafo nico da clasula segunda do Protocolo 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 substituir um 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 documento fiscal 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 um documento de existncia exclusivamente digital, emitido e armazenado eletronicamente, com o intuito de documentar uma prestao de servios de transportes, cuja validade jurdica garantida pela assinatura digital do emitente e a Autorizao de Uso fornecida pela administrao tributria do domiclio do contribuinte.

2.3 Descrio Simplificada do Modelo Operacional


Pg. 9 / 133

De maneira simplificada, a empresa emissora de CT-e gerar um arquivo eletrnico contendo as informaes fiscais da prestao de servios de transportes, o qual dever ser assinado 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 uma Autorizao 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 a chave 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 do servio, caso sejam diferentes da Secretaria de Fazenda de circunscrio do emissor, alm da SUFRAMA, quando aplicvel.

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

O DACTE no um conhecimento de transporte, nem o substitui, servindo apenas como instrumento auxiliar para consulta do CT-e, pois contm a chave de acesso do CT-e, que permite ao detentor desse documento confirmar a efetiva existncia do CT-e, atravs dos stios das Secretarias de Fazenda Estaduais autorizadoras ou Receita Federal. No primeiro momento de implantao do projeto, o contribuinte tomador do servio de transporte, no emissor de Documentos Fiscais eletrnicos, poder escriturar o CT-e com base nas informaes deste documento, sendo que sua validade ficar vinculada efetiva existncia do CT-e com autorizao de uso no Banco de Dados das administraes tributrias envolvidas no processo.


Pg. 10 / 133

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 Web Service com a solicitao do servio desejado.

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

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

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

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

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

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


Pg. 11 / 133

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-xml e 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 XML pode conter outros documentos XML, como ocorre com o documento XML de lote de envio de CT-e, deve-se tomar o cuidado para que exista uma nica declarao no incio do lote.

b) Declarao namespace

O documento XML dever ter uma nica declarao de namespace no elemento raiz do documento 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 namespace da assinatura digital dever ser realizada na prpria tag , conforme exemplo abaixo.

Cada documento XML dever ter o seu namespace individual em seu elemento raiz. No caso especfico do lote de envio do CT-e, cada CT-e dever ter declarado o seu namespace individual. Segue abaixo um exemplo:

Contribuinte Secretaria de Fazenda Estadual

Client CTe ( ERP ou software especfico )

CTe

Aplicativo de Faturamento ( ERP ou software especfico )

HTTPS

Fluxo de Comunicao

Servios Sncronos

Aplicao CTe

Filas de Msgs

CTes

Arquitetura de Comunicao Viso Conceitual

Servios Assncronos

Web Services Transaes


Pg. 12 / 133

200602220000001

...

...

...

c) Prefixo de namespace

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

Assim, ao invs da declarao:

(exemplo para o XML do CT-e com 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 obrigatrios no 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 tipo numrico) ou vazio (para campos tipo caractere).

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.

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


Pg. 13 / 133

Exemplo 2: Informao relacionada com o AFRMM - Adicional de Frete para Renovao da Marinha Mercante (ocorrncia 0-1). Ser preenchido somente se o negcio do contribuinte for 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 formao dos arquivos XML, o contribuinte dever submeter o arquivo do CT-e e as demais mensagens 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 em Web Services disponibilizados no Portal da Secretaria de Fazenda Estadual de circunscrio do contribuinte.

O meio fsico de comunicao utilizado ser a Internet, com o uso do protocolo SSL verso 3.0, com autenticao mtua, 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 os Web Services do Portal da Secretaria de Fazenda Estadual e o aplicativo do contribuinte ser realizada no padro SOAP verso 1.2, com troca de mensagens XML no padro Style/Enconding: Document/Literal.

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

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

Exemplo de uma mensagem requisio padro SOAP:


Pg. 14 / 133

string string 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 ser emitido por Autoridade Certificadora credenciada pela Infra-estrutura de Chaves Pblicas Brasileira ICP-Brasil, tipo A1 ou A3, devendo conter o CNPJ da pessoa jurdica titular do certificado digital no campo otherName OID =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 dever conter o CNPJ do estabelecimento emissor do CT-e ou o CNPJ do estabelecimento matriz. 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-e e demais arquivos XML que necessitem de assinatura. O certificado digital dever ter o uso da chave previsto para a funo de assinatura digital, respeitando a Poltica do Certificado.

b) Transmisso (durante a transmisso das mensagens entre o servidor do contribuinte e o Portal da Secretaria de Fazenda Estadual): 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 do CT-e, devendo ter a extenso Extended Key Usage com permisso de "Autenticao Cliente".


Pg. 15 / 133

3.2.4 Padro de Assinatura Digital

As mensagens enviadas ao Portal da Secretaria de Fazenda Estadual 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 do CT-e objeto do pedido.

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:

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

O Projeto CT-e utiliza um subconjunto do padro de assinatura XML definido pelo http://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 assinatura XS03 CanonicalizationM

ethod G 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 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-signature

XS14 XPath E XS12 C 0-N XPath XS15 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)


Pg. 16 / 133

XS18 SignatureValue G XS01 - 1-1 Grupo do Signature Value XS19 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 literal CTe para cada CT-e, conforme leiaute descrito no Anexo I. O identificador nico precedido do literal #CTe dever ser informado no atributo URI da TAG . Para as demais mensagens a serem assinadas, o processo o mesmo mantendo sempre um identificador nico para o atributo Id na 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 Certificados Revogados, j que a mesma ser montada e validada por cada Portal da Secretaria de Fazenda Estadual no momento da conferncia da assinatura digital.

A assinatura digital do documento eletrnico dever atender aos seguintes padres adotados:

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);

c) Cadeia de Certificao: EndCertOnly (Incluir na assinatura apenas o certificado do usurio 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:


Pg. 17 / 133

(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 pelas Secretarias 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 assinaturas digitais das mensagens sero verificadas considerando a lista de certificados revogados disponvel 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 Descrio Web 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 Secretaria de Fazenda Estadual.

Meio fsico de comunicao Internet Protocolo 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

credenciada pela Infra-estrutura de Chaves Pblicas Brasileira ICP-Brasil, do tipo A1 ou A3, devendo conter o CNPJ do proprietrio do certificado digital.

Para assinatura de mensagens, utilizar o certificado digital do estabelecimento matriz ou do estabelecimento emissor do CT-e.

Para transmisso, utilizar o certificado digital do responsvel pela transmisso.

Padro de assinatura digital XML Digital Signature, Enveloped, com certificado digital


Pg. 18 / 133

X.509 verso 3, com chave privada de 1024 bits, com padres de criptografia assimtrica RSA, algoritmo message digest SHA-1 e utilizao das transformaes Enveloped e C14N.

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

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

Mscara de nmeros decimais e datas esto definidas no Schema XML.

Nos campos numricos inteiro, no incluir a vrgula ou ponto decimal.

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

3.3 Modelo operacional

A forma de processamento das solicitaes de servios no projeto projeto Conhecimento de Transporte eletrnico 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, 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 do CT-e sero implementados da seguinte forma:

Servio Implementao Recepo de CT-e Assncrona Cancelamento de CT-e Sncrona Inutilizao de Numerao de CT-e Sncrona Consulta da situao atual do CT-e Sncrona Carta de Correo de CT-e Sncrona Consulta do status do servio Sncrona

3.3.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:


Pg. 19 / 133

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 do CT-e que ir processar o servio solicitado;

(3) O aplicativo do CT-e recebe a mensagem de solicitao de servio 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.

3.3.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:

Aplicativo Cliente

Web Service

Processamento de Servios

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

(4) Resultado (3) Resultado


Servio de Implementao sncrona


Pg. 20 / 133

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


Servio de Implementao assncrona

Etapas do processo ideal:

(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 recibo da solicitao de servio e a data e hora de recebimento da mensagem no Web Service;

(4) O aplicativo do contribuinte recebe o recibo e o coloca na fila de recibos de servios 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 de servios solicitados pelo aplicativo do CT-e;

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

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

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

(9) O Web Service Consulta Recibo recebe a mensagem de consulta recibo e localiza 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.


Pg. 21 / 133

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 armazenadas em 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 de detalhe que contem a mensagem XML. As seguintes informaes so adotadas como atributos de controle:

CNPJ do transmissor: CNPJ da empresa que enviou a mensagem que no necessita estar vinculado ao CNPJ do estabelecimento emissor do CT-e. Somente o transmissor da mensagem ter acesso ao resultado do processamento das mensagens 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 solicitao de servios na fila de mensagem;

Data e hora de recebimento da mensagem: Data e hora local do instante de recebimento da mensagem atribuda pela Secretaria de Fazenda Estadual. Este atributo importante como parmetro de desempenho do sistema, eliminao de mensagens, 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 do CT-e informada no campo cUF do elemento cteCabecMsg do SOAP Header. O atributo importante para a implementao da SEFAZ Virtual e identificao da UF de origem da mensagem;

versaoDados: Verso do leiaute da mensagem existente na rea de dados. O atributo utilizado para validao de schema XML do XML de dados e verificar a vigncia da verso informada.

Para processar as mensagens de solicitaes de servios, a aplicao do CT-e ir retirar a mensagem da fila de entrada de acordo com a ordem de chegada, devendo armazenar o resultado 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 contedo do detalhe da mensagem que contm o resultado do processamento da solicitao de servio em formato XML.

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

Estrutura de um item da fila:

CNPJ do Transmissor

Nmero do Recibo

data e hora recebimento

cUF XML de Dados

rea de controle rea de mensagem Verso Dados


Pg. 22 / 133

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

Nota: O termo fila utilizado apenas para designar um repositrio de recibos emitidos. A implementao 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 Estaduais ou Receita Federal do Brasil e os respectivos resultados do processamento so realizadas atravs 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 no elemento cteCabecMsg do SOAP Header e servem para identificar a UF de origem do emissor e a verso do leiaute da estrutura XML armazenada na rea de dados da mensagem:

string string

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

xml

3.4.2 Validao da estrutura XML das Mensagens dos Web Services

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


Pg. 23 / 133

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

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

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

A validao da estrutura XML da mensagem realizada por um analisador sinttico (parser) que verifica 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 um erro de validao do Schema XML.

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

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

35 1.00

3.4.3 Schemas XML das Mensagens dos Web Services

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

A identificao da verso dos Schemas ser realizada com o acrscimo do nmero da verso 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 tipos complexos 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 Schema principal.

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 os Schemas que utilizam este tipo bsico devem ter a sua verso atualizada e as declaraes import ou include devem ser atualizadas com o nome do Schema bsico atualizado.

Exemplo de Schema XML


Pg. 24 / 133

schema_v1.01.xsd"/> Conhecimento de Transporte Eletrnico

As modificaes de leiaute das mensagens dos Web Services 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 Coordenao Tcnica do ENCAT e podero ocorrer sempre que se fizerem necessrias.

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 sero disponibilizados no sitio nacional do Projeto (www.cte.fazenda.gov.br), e sero liberados aps 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 de schemas a serem utilizados pelas empresas para a gerao dos arquivos XML. Este arquivo ser denominado Pacote de Liberao e ter a mesma numerao da verso do Manual de Integrao que lhe compatvel. Os pacotes de liberao sero identificados pelas letras PL_ 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 schemas do Conhecimento de Transporte eletrnico compatveis com o Manual de Integrao do Contribuinte 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 de cteEnvLote_v9.99.xsd, onde v9.99, corresponde a verso do respectivo schema.

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

Exemplificando:

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

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

SCHEMAS

tiposBasico_v1.00.xsd tiposBasico _v1.01.xsd


Pg. 25 / 133

3.5.2 Pacote de Liberao Preliminar

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

Durante este perodo, os novos Schemas XML sero avaliados e testados para a identificao de eventuais falhas de implementao das alteraes realizadas no Manual de Integrao 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 liberao definitivo

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

A principal caracterstica do pacote de liberao de homologao seu uso estar restrito ao ambiente 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 do ambiente de produo.

3.5.4 Correo de Pacote de Liberao

Em algumas situaes pode surgir a necessidade de correo de um Schema XML por um erro de implementao de regra de validao, obrigatoriedade de campo, nome de tag divergente do definido no leiaute da mensagem, que no modifica a estrutura do Schema XML 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 de Integrao do Contribuinte vigente.

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

3.5.5 Divulgao de novos Pacotes de Liberao

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


Pg. 26 / 133

3.5.6 Controle de Verso

O controle de verso de cada um dos schemas vlidos para o Projeto Conhecimento de Transporte 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 empresas participantes do Projeto em diferentes datas. Ou seja, algumas empresas podero estar com uma verso de leiaute mais atualizada, enquanto outras empresas podero ainda estar operando com mensagens em um leiaute anterior.

No esto previstas mudanas freqentes de leiaute de mensagens e as empresas devero ter um prazo razovel para implementar as mudanas necessrias, conforme acordo operacional a ser estabelecido.

Mensagens recebidas com uma verso de leiaute no suportada sero rejeitadas com uma mensagem 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 de autorizao da emisso do Conhecimento de Transporte Eletrnico para os Contribuintes da sua jurisdio. Neste caso, os servios da autorizao de emisso do CT-e sero supridos por uma SEFAZ VIRTUAL, atravs de um Protocolo de cooperao assinado entre as SEFAZ e/ou entre a SEFAZ e a RFB.

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

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

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


Pg. 27 / 133

4. Web Services

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

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

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

As Secretarias de Fazenda Estaduais se comprometem a processar os lotes de conhecimentos de transportes recebidas em at 3 minutos em no mnimo 95% do total do volume recebido no perodo de 24 horas. Este indicador de performance ser constantemente avaliado e aperfeioado pelo Comit Gestor e os contribuintes emissores de CT-e.

A qualquer momento as empresas podero verificar a performance do servio de processamento dos lotes, verificando o tempo mdio de resposta do servio nos ltimos 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 resposta no aceitvel.

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

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

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

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

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

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


Pg. 28 / 133

4.1 Servio de Recepo de CT-e

O Servio de Recepo de CT-e o servio oferecido pelos Portais das Secretarias da Fazenda 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 contribuinte deve transmitir o lote de CT-e atravs do Web Service de recepo de lote de CT-e e buscar o resultado do processamento do Lote de CT-e no Web Service de consulta resultado de processamento 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

# Campo Ele Pai Tipo Ocor. Tam. Dec. Descrio/Observao AP01 enviCTe Raiz - - - - TAG raiz AP02 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, de controle correspondente ao identificador nico do lote enviado. A responsabilidade de gerar e controlar esse nmero exclusiva do contribuinte.

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


Pg. 29 / 133

4.1.3 Leiaute Mensagem de Retorno

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

Schema XML: retEnviCte_v99.99.xsd

# Campo Ele Pai Tipo Ocor. Tam. Dec. Descrio/Observao 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 AR03a cUF E AR01 N 1-1 2 Cdigo da UF que atendeu a solicitao. 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 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 da

Secretaria de Fazenda Estadual, composto por duas posies com o Cdigo da UF (codificao do IBGE) onde foi entregue o Lote, uma posio para o Tipo de Autorizador e doze posies numricas seqenciais (vide item 5.5)

AR09 dhRecbto E AR07 D 1-1 - Data e Hora do Recebimento Formato = AAAA-MM-DDTHH:MM:SS Preenchido com data e hora do recebimento do lote.

AR10 tMed E AR07 N 1-1 N 1-4 Tempo mdio de resposta do servio (em segundos) dos ltimos 5 minutos (vide item 5.7). Nota: Caso o tempo mdio de resposta fique abaixo de 1 (um) segundo, o tempo ser informado como 1 segundo. Arredondar as fraes de segundos para cima.

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

O nmero do recibo gerado pelo Portal da Secretaria de Fazenda Estadual ser a chave de acesso 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 e coloc-las na fila de entrada.

Existe um limite de at 50 CT-e por lote. O agrupamento destes CT-e dentro do lote deve ser feito, por uma restrio operacional e de controle, respeitando a regra em que todos os CT-e do lote devam ser do mesmo estabelecimento (mesmo CNPJ e IE do emitente).

O tamanho mximo do lote de CT-e limitado em 500k, assim o contribuinte deve compor um 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.


Pg. 30 / 133

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 no precisam ser implementadas. A validao A06 tambm pode ser realizada pelo protocolo SSL, mas pode falhar se existirem outros certificados digitais de Autoridade Certificadora Raiz que no sejam ICP-Brasil no repositrio de certificados digitais do servidor de Web Service 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 Paralisado

Momentaneamente Obrig. 108 Rej.

B04 Verifica se o Servidor de Processamento est Paralisado sem Previso

Obrig. 109 Rej.

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


Pg. 31 / 133

A critrio de cada unidade federada poder ser verificado se o XML de dados est bem formado, no momento do recebimento da mensagem no Web Service. Esta verificao til para as UF que desejarem armazenar o XML de dados em estrutura XML de banco de dados.

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

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 pelo

WebService 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 conhecimentos so informados no elemento cteCabecMsg do SOAP Header (para maiores detalhes vide item 3.4.1).

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

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

4.1.8 Gerao da Resposta com o Recibo

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

Aps a gravao da mensagem na fila de entrada ser retornada uma mensagem de confirmao 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;


Pg. 32 / 133

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 com as 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 de Processamento de CT-e que consome as mensagens armazenadas na fila de entrada pelo mtodo CteRecepcao e faz a validao de forma e das regras de negcios e armazena o resultado 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 da seguinte regra:

Validao da rea de dados da mensagem # Regra de Validao Aplic. Msg Efeito

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. D04 O lote contm CT-e de mais de um estabelecimento emissor

(considerar o CNPJ e IE do emitente de cada CT-e) Obrig. 457 Rej.

Como a validao do Schema XML realizada em toda mensagem de entrada, a existncia de 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 seguintes regras de negcios para cada CT-e:

Validao do Certificado Digital utilizado na Assinatura Digital do CT-e # Regra de Validao Aplic. Msg Efeito


Pg. 33 / 133

E01 Certificado de Assinatura invlido: - Certificado de Assinatura inexistente na mensagem (*validado tambm 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 # Regra de Validao Aplic. Msg Efeito

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 do Emitente

Facult. 244 Rej.

d) Validao de regras de negcios do CT-e

Validao do CT-e Regras de Negcios # Regra de Validao Aplic. Msg Efeito

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. G03c Processo de emisso informado invlido (diferente de 0 ou 3) Obrig. 474 Rej. G04 Campo ID invlido

- Falta literal "CTe" - Chave de Acesso do campo ID difere da concatenao dos campos correspondentes

Obrig. 227 Rej.

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

Obrig. 253 Rej.


Pg. 34 / 133


G05a Se finalidade do CT-e= 0 (Normal): deve existir o grupo de CT-e Normal

Obrig. 458 Rej.

G05b Se finalidade do CT-e= 1 (Complemento): deve existir o grupo de CT-e Complementar

Obrig. 459 Rej.

G05c Tomador do servio informado como remetente, mas inexiste remetente

Obrig. 460 Rej.

G05d Tomador do servio informado como expedidor, mas inexiste expedidor

Obrig. 461 Rej.

G05e Tomador do servio informado como recebedor, mas inexiste recebedor

Obrig. 462 Rej.

G05f Tomador do servio informado como destinatrio, mas inexiste destinatrio

Obrig. 463 Rej.

G05g CT-e normal e modal = rodovirio, mas inexiste o grupo do modal Obrig. 464 Rej. G05h CT-e normal e modal = areo, mas inexiste o grupo do modal Obrig. 465 Rej. G05i CT-e normal e modal = aquavirio, mas inexiste o grupo do modal Obrig. 466 Rej. G05j CT-e normal e modal = ferrovirio, mas inexiste o grupo do modal Obrig. 467 Rej. G05k CT-e normal e modal = dutovirio, mas inexiste o grupo do modal Obrig. 468 Rej. G05l Remetente no informado para tipo de servio diferente de

redespacho intermedirio Obrig. 469 Rej.

G05m Destinatrio no informado para tipo de servio diferente de redespacho intermedirio

Obrig. 470 Rej.

G05n Expedidor deve ser informado para tipo de servio de redespacho intermedirio

Obrig. 474 Rej.

G05o Recebedor deve ser informado para tipo de servio de redespacho intermedirio

Obrig. 475 Rej.

G05p O tomador do servio no tipo de servio normal no pode ser o expedidor

Obrig. 476 Rej.

G05q O tomador do servio no tipo de servio normal no pode ser o recebedor

Obrig. 477 Rej.

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 da SEFAZ, com o acrscimo de zeros no significativos previstos na definio do formato da IE se necessrio. Ex.: IE informada 130000019, formato da IE: NNNNNNNNNND, a IE deve ser padronizada para 00130000019, com o acrscimo dos zeros no significativos 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 duplicidade

na insero do CT-e, evitando a insero de mais de um CT-e denegado)

Obrig. 301 ou 205

Den.

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

Obrig. 212 Rej.


Pg. 35 / 133


G15 Data de Emisso ocorrida h mais de 60 dias, ou outro limite conforme critrio definido pela SEFAZ (a SEFAZ Virutal deve considerar 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 2 posies da esquerda do cdigo de municpio que identifica o cdigo da 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 da SEFAZ, com o acrscimo de zeros no significativos previstos na definio do formato da IE se necessrio. Ex.: IE informada 130000019, formato da IE: NNNNNNNNNND, a IE deve ser padronizada para 00130000019, com o acrscimo dos zeros no significativos necessrios para a validao do dgito verificador.

Obrig. 419 Rej..

G21 Se o Remetente informado for contribuinte do ICMS na UF autorizadora: - 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 situao

irregular perante o Fisco (tratar duplicidade na insero do CT-e, evitando a insero de mais de um CT-e denegado)

Facult. 302 ou 205

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. G27 Destinatrio informado: Cdigo Municpio invlido (dgito de

controle), vide item 2.1 do Anexo III.

Facult. 423 Rej.

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

Obrig. 424 Rej.

G29 IE Destinatrio informado: IE invlida (erro no dgito de controle ou contedo diferente de ISENTO) Obs.: Antes da validao, a IE dever ser normalizada, na aplicao da SEFAZ, com o acrscimo de zeros no significativos previstos na definio do formato da IE se necessrio. Ex.: IE informada 130000019, formato da IE: NNNNNNNNNND, a IE deve ser padronizada para 00130000019, com o acrscimo dos zeros no significativos 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.


Pg. 36 / 133


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

Facult. 303 ou

205

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 2 posies da esquerda do cdigo de municpio que identifica o cdigo da 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 da SEFAZ, com o acrscimo de zeros no significativos previstos na definio do formato da IE se necessrio. Ex.: IE informada 130000019, formato da IE: NNNNNNNNNND, a IE deve ser padronizada para 00130000019, com o acrscimo dos zeros no significativos 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 irregular

perante o Fisco (tratar duplicidade na insero do CT-e, evitando a insero de mais de um CT-e denegado)

Facult. 304 ou 205

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 Recebedor informado: Cdigo Municpio invlido (dgito de controle),


Facult. 438 Rej.

G46 Recebedor informado: Municpio diverge da UF (verificar se as 2 posies da esquerda do cdigo de municpio que identifica o cdigo da 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 da SEFAZ, com o acrscimo de zeros no significativos previstos na definio do formato da IE se necessrio. Ex.: IE informada 130000019, formato da IE: NNNNNNNNNND, a IE deve ser padronizada para 00130000019, com o acrscimo dos zeros no significativos necessrios para a validao do dgito verificador.

Obrig. 440 Rej.

G48 Se Recebedor informado for contribuinte do ICMS na UF autorizadora: - 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 situao

irregular perante o Fisco (tratar duplicidade na insero do CT-e, evitando a insero de mais de um CT-e denegado)

Facult. 305 ou 205

Den.

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


Pg. 37 / 133


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


Facult. 446 Rej.

G55 Tomador informado: Municpio diverge da UF (verificar se as 2 posies 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 da SEFAZ, com o acrscimo de zeros no significativos previstos na definio do formato da IE se necessrio. Ex.: IE informada 130000019, formato da IE: NNNNNNNNNND, a IE deve ser padronizada para 00130000019, com o acrscimo dos zeros no significativos necessrios para a validao do dgito verificador.

Obrig. 448 Rej.

G57 Se o Tomador do servio for contribuinte do ICMS na UF autorizadora: - 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 irregular

perante o Fisco (tratar duplicidade na insero do CT-e, evitando a insero de mais de um CT-e denegado)

Facult. 306 ou 205

Den.

G61 Inscr. SUFRAMA do Destinatrio informada: verificar dgito controle Obrig. 235 Rej. G62 Inscr. SUFRAMA informada: verificar UF destinatrio = AC-Acre, ou

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

G64 - Verificar se CT-e j est Cancelado Obrig. 218 Rej. G65 - Verificar se CT-e j est Denegado Obrig. 205 Rej. G66 Acesso BD CTE-Inutilizao

- Verificar Nmero do CT-e Inutilizado Obrig. 206 Rej.

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

Obrig. 254 Rej.

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

Obrig. 269 Rej.

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

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

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

Facult. 453 Rej.

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

Obrig. 454 Rej.


Pg. 38 / 133


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

Facult. 455 Rej.

G74 Municpio de incio da prestao diverge da

manual cte v101

Documents