Manual CTe 1.0.4b

Conhecimento de Transporte EletrnicoManual de Orientaes - Contribuinte

Projeto Conhecimento de Transporte Eletrnico

Manual de Orientaes do ContribuintePadres Tcnicos de Comunicao

Verso 1.0.4b Dezembro/2011

Pg. 1 / 158

Conhecimento de Transporte eletrnicoManual de Orientaes Contribuinte

Controle de VersesVerso 1.00 1.01 1.01A 1.01B 1.02pre 1.02 1.03 1.04 1.04a 1.04b Data 07/03/2008 SP 02/07/2008 SP/RS 07/07/2008 SP/RS 25/08/2008 Reunio CT-e RJ 03/09/2008 Reunio CT-e MT 12/09/2008 SP/RS 03/08/2009 RS/SP/GO 22/07/2011 RS 12/08/2011 RS 07/12/2011 - RS

Pg. 2 / 158


Identificao e vigncia do ManualVerso do manual Data de divulgao da verso inicial do manual Data de divulgao da verso corrigida do manual Pacote de liberao de Schemas XML Data de incio de vigncia no ambiente de homologao Data de incio de vigncia no ambiente de produo Pacote de liberao de Schemas XML em vigncia Data final de vigncia do PL_CTe_103

1.04b 12/08/2011 26/11/2011 PL_CTe_104b 15/12/2011 01/01/2012 PL_CTe_103 01/04/2012

Verses de leiautes do PL_CTe_104bLeiaute CTe enviCTe retEnviCTe consReciCTe retconsReciCTe procCTe cancCTe retCancCTeverso

1.04 1.04 1.04 1.04 1.04 1.04 1.04 1.04

Schema XML cte_v104.xsd enviCte_v1.04.xsd retEnviCte_v1.04.xsd consReciCte_v1.04.xsd retConsReciCte_v1.04.xsd procCte_v1.04.xsd cancCte_v1.04.xsd retCancCte_v1.04.xsd

procCancCTe inutCTe retInutCTe

1.04 1.04 1.04

procCancCte_v1.04.xsd inutCTe_v1.04.xsd retInutCTe_v1.04.xsd

procInutCTe consSitCTe retConsSitCTe consStatServ retConsStatServ aereo aquav duto ferrov rodo

1.04 1.04 1.04 1.04 1.04 1.04 1.04 1.04 1.04 1.04

procInutCTe_v1.04.xsd consSitCte_v1.04.xsd retConsSitCte_v1.04.xsd consStatServCte_v1.04.xsd retconsStatServ_v1.04.xsd cteModalAereo_v1.04.xsd cteModalAquaviario_v1.04.xsd cteModalDutoviario_v1.04.xsd cteModalFerroviario_v1.04.xsd cteModalRodoviario_v1.04.xsd

Observao Leiaute do CT-e (parte Geral). Mensagem de envio de lote de CT-e. Mensagem de retorno do envio de lote de CT-e. Mensagem de consulta processamento do lote de CT-e transmitido. Mensagem de retorno da consulta de processamento do lote de CT-e transmitido. Leiaute de compartilhamento do CT-e. Mensagem de solicitao de cancelamento do CT-e. Mensagem de retorno do resultado da solicitao do processamento de cancelamento do CT-e. Leiaute de compartilhamento de Pedido de cancelamento de CT-e Mensagem de solicitao de inutilizao de numerao de CT-e. Mensagem de retorno do resultado do processamento da solicitao de inutilizao de numerao de CT-e. Leiaute de compartilhamento de pedido de inutilizao de numerao de CT-e Mensagem de consulta da situao atual da CTe. Mensagem de retorno da consulta da situao atual da CT-e. Mensagem da consulta do status do servio de autorizao de CT-e. Mensagem de retorno da consulta do status do servio de autorizao de CT-e. Leiaute do modal Aerovirio (parte especfica) Leiaute do modal Aquavirio (parte especfica) Leiaute do modal Dutovirio (parte especfica) Leiaute do modal Ferrovirio (parte especfica) Leiaute do modal Rodovirio (parte especfica)

Pg. 3 / 158


ndiceIntroduo ......................................................................................................... 7 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 .......................................................................... 14 3.2.5 Validao de Assinatura Digital pela Secretaria de Fazenda Estadual ........... 16 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.......................................................................................... 20 3.4 Padro de Mensagens dos Web Services ............................................................ 21 3.4.1 Informaes de Controle e rea de Dados das Mensagens ........................... 21 3.4.2 Validao da Estrutura XML das Mensagens dos Web Services .................... 21 3.4.3 Schemas XML das Mensagens dos Web Services ......................................... 22 3.5 Verso dos Schemas XML ................................................................................... 23 3.5.1 Liberao das Verses dos Schemas para o Conhecimento de Transporte Eletrnico CT-e ......................................................................................................... 23 3.5.2 Pacote de Liberao Preliminar ...................................................................... 23 3.5.3 Pacote de Liberao de Homologao e Pacote de Liberao Definitivo ....... 24 3.5.4 Correo de Pacote de Liberao .................................................................. 24 3.5.5 Divulgao de Novos Pacotes de Liberao ................................................... 24 3.5.6 Controle de Verso ......................................................................................... 24 3.6 Schema XML do CT-e Estrutura Genrica e Estrutura Especfica do Modal de Transporte ....................................................................................................................... 25 3.6.1 Parte Genrica ............................................................................................... 25 3.6.2 Parte Especfica para Cada Modal de Transporte .......................................... 26 3.6.3 Parte Genrica e Parte Especfica para Cada Modal de Transporte Verses 26 3.7 SEFAZ Virtual....................................................................................................... 27 4. Web Services .................................................................................................. 28 4.1 Servio de Recepo de CT-e.............................................................................. 29 4.1.1 Web Service CteRecepcao .......................................................................... 29 4.1.2 Leiaute Mensagem de Entrada ....................................................................... 29 4.1.3 Leiaute Mensagem de Retorno ....................................................................... 30 4.1.4 Descrio do Processo de Recepo de Lotes de CT-e ................................. 31 4.1.5 Validao do Certificado de Transmisso ....................................................... 31 4.1.6 Validao Inicial da Mensagem no Web Service ............................................ 31 4.1.7 Validao das Informaes de Controle da Chamada ao Web Service .......... 32 4.1.8 Gerao da Resposta com o Recibo .............................................................. 32 4.1.9 Descrio do Processamento do Lote de CT-e............................................... 33 4.1.10 Validao da rea de Dados .......................................................................... 33 4.1.11 Final do Processamento do Lote .................................................................... 41 4.2 Web Service CteRetRecepcao .......................................................................... 43 4.2.1 Leiaute Mensagem de Entrada ....................................................................... 43 4.2.2 Leiaute Mensagem de Retorno ....................................................................... 43 1. 2.

Pg. 4 / 158


4.2.3 Descrio do Processo de Web Service ......................................................... 44 4.2.4 Validao do Certificado de Transmisso ....................................................... 45 4.2.5 Validao Inicial da Mensagem no Web Service ............................................ 45 4.2.6 Validao das Informaes de Controle da Chamada ao Web Service .......... 46 4.2.7 Validao da rea de Dados .......................................................................... 46 4.2.8 Final do Processamento ................................................................................. 47 4.3 Web Service CteCancelamento ......................................................................... 48 4.3.1 Leiaute Mensagem de Entrada ....................................................................... 48 4.3.2 Leiaute Mensagem de Retorno ....................................................................... 48 4.3.3 Descrio do Processo de Web Service ......................................................... 49 4.3.4 Validao do Certificado de Transmisso ....................................................... 49 4.3.5 Validao Inicial da Mensagem no Web Service ............................................ 50 4.3.6 Validao das Informaes de Controle da Chamada ao Web Service .......... 50 4.3.7 Validao da rea de Dados .......................................................................... 51 4.3.8 Final do Processamento ................................................................................. 53 4.4 Web Service - CteInutilizacao............................................................................... 54 4.4.1 Leiaute Mensagem de Entrada ....................................................................... 54 4.4.2 Leiaute Mensagem de Retorno ....................................................................... 55 4.4.3 Descrio do Processo de Web Service ......................................................... 55 4.4.4 Validao do Certificado de Transmisso ....................................................... 56 4.4.5 Validao Inicial da Mensagem no Web Service ............................................ 56 4.4.6 Validao das Informaes de Controle da Chamada ao Web Service .......... 57 4.4.7 Validao da rea de Dados .......................................................................... 57 4.4.8 Final do Processamento ................................................................................. 59 4.5 Web Service CteConsulta Protocolo .................................................................. 60 4.5.1 Leiaute Mensagem de Entrada ....................................................................... 60 4.5.2 Leiaute Mensagem de Retorno ....................................................................... 60 4.5.3 Descrio do Processo de Web Service ......................................................... 61 4.5.4 Validao do Certificado de Transmisso ....................................................... 61 4.5.5 Validao Inicial da Mensagem no Web Service ............................................ 62 4.5.6 Validao das Informaes de Controle da Chamada ao Web Service .......... 62 4.5.7 Validao da rea de Dados .......................................................................... 63 4.5.8 Final do Processamento ................................................................................. 63 4.6 Web Service CteStatusServico .......................................................................... 64 4.6.1 Leiaute Mensagem de Entrada ....................................................................... 64 4.6.2 Leiaute Mensagem de Retorno ....................................................................... 64 4.6.3 Descrio do Processo de Web Service ......................................................... 65 4.6.4 Validao do Certificado de Transmisso ....................................................... 65 4.6.5 Validao Inicial da Mensagem no Web Service ............................................ 66 4.6.6 Validao das Informaes de Controle da Chamada ao Web Service .......... 66 4.6.7 Validao da rea de Dados .......................................................................... 67 4.6.8 Final do Processamento ................................................................................. 67 Web Service CadConsultaCadastro .............................................................................. 68 4.6.9 Descrio do Processo de Web Service ......................................................... 68 4.6.10 Onde Obter as Definies deste Web Service ................................................ 68 4.6.11 Onde Obter os Schemas XML deste Web Service ......................................... 69 5. Web Services Informaes Adicionais .......................................................... 70 5.1 Regras de validao ............................................................................................. 70 5.1.1 Tabela de Cdigos de Erros e Descries de Mensagens de Erros ............... 70 5.2 Padro de Nomes para os Arquivos ..................................................................... 76 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............................................................................................ 79 5.7 Tempo Mdio de Resposta................................................................................... 79

Pg. 5 / 158


Cdigo de Barra .............................................................................................. 80 Cdigo de Barras Adicional .................................................................................. 81 Clculo do Dgito Verificador do CODE-128C....................................................... 82 Representao Simblica do Cdigo.................................................................... 82 7. DACTE ............................................................................................................ 83 8. Contingncia ................................................................................................... 84 9. Ambiente de Homologao / Produo ........................................................... 85 10. Distribuio do CT-e para o Tomador do Servio ............................................ 86 10.1 Processo de Distribuio ...................................................................................... 86 10.2 Leiaute da Distribuio: CT-e ............................................................................... 86 11. Compartilhamento de Informaes do CT-e entre rgos Pblicos ................ 87 11.1 Processo de Compartilhamento ........................................................................... 87 11.2 Leiaute de Compartilhamento: CT-e .................................................................... 88 11.3 Leiaute de Compartilhamento: Cancelamento de CT-e ....................................... 88 11.4 Leiaute de Compartilhamento: Inutilizao de Numerao de CT-e .................... 88 11.5 Compartilhamento de Documentos com Outros rgos Pblicos ........................ 88 Anexo I Leiaute do CT-e ................................................................................................... 89 CT-e Diagrama Simplificado parte genrica ............................................................... 92 CT-e Diagrama Simplificado Rodovirio..................................................................... 93 CT-e Diagrama Simplificado Aerovirio...................................................................... 94 CT-e Diagrama Simplificado Aquavirio ..................................................................... 95 CT-e Diagrama Simplificado Ferroviro ..................................................................... 96 Leiaute CT-e Estrutura Genrica................................................................................... 98 Leiaute Rodovirio ...................................................................................................... 126 Leiaute Aerovirio ....................................................................................................... 130 Leiaute Aquavirio ...................................................................................................... 132 Leiaute Ferrovirio ...................................................................................................... 134 Leiaute Dutovirio ....................................................................................................... 136 Anexo II Tabelas de UF, Municpio e Pas .................................................................... 141 1. Tabela de Cdigo de UF do IBGE ................................................................. 141 2. Tabela de Cdigo de Municpio do IBGE ....................................................... 141 2.1 Validao do Cdigo de Municpio ..................................................................... 142 2.2 Exemplo de Clculo do Dgito de Controle do Cdigo de Municpio ................... 142 2.3 Exceo no Clculo do Dgito de Controle do Cdigo de Municpio ................... 143 3. Tabela de Cdigo de Pas do BACEN ........................................................... 143 3.1 Validao do Cdigo de Pas ............................................................................. 144 3.2 Exemplo de Clculo do Dgito de Controle do Cdigo de Pas ........................... 144 3.3 Exceo no Clculo do Dgito de Controle do Cdigo de Pas ........................... 144 Anexo III WS disponveis ................................................................................................ 145 Anexo IV Conjunto de Caracteres Cdigo de Barras CODE-128C.................................. 146 Anexo V Projeto Piloto do CT-e ...................................................................................... 147 Anexo VI Manual de Contingncia .................................................................................. 148 6.1 6.2 6.3

6.

Pg. 6 / 158


1. IntroduoEste 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.

Pg. 7 / 158


2. Consideraes IniciaisO Conhecimento de Transporte Eletrnico (CT-e) est sendo desenvolvido, de forma integrada, pelas Secretarias de Fazenda dos Estados, Receita Federal do Brasil, representantes das transportadoras e Agncias Reguladoras do segmento de transporte, a partir da assinatura do Protocolo ENAT 03/2006 (10/11/2006), que atribuiu 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. Os documentos fiscais eletrnicos simplificam o cumprimento das obrigaes acessrias a que os contribuintes esto sujeitos e permitem ao Fisco um melhor acompanhamento das operaes comerciais, mostrando-se uma soluo vantajosa para todos os envolvidos nas transaes com estes documentos. A possibilidade do uso de documentos fiscais eletrnicos em substituio aos documentos tradicionalmente emitidos em papeis est prevista no pargrafo nico da clusula segunda do Protocolo ENAT 03/2005. O Conhecimento de Transporte Eletrnico (Modelo 57) um 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) um documento de existncia exclusivamente digital, emitido e armazenado eletronicamente com o intuito de documentar prestaes de servio de transporte, com validade jurdica garantida pela assinatura digital do emitente e pela Autorizao de Uso fornecida pela administrao tributria do domiclio do contribuinte.

2.3

Descrio Simplificada do Modelo Operacional

De maneira simplificada, a empresa emissora de CT-e gerar um arquivo eletrnico contendo as informaes fiscais da prestao de servio de transporte, que 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 transmitido pela

Pg. 8 / 158


Internet para a Secretaria de Fazenda Estadual de jurisdio do contribuinte emitente. A Secretaria de Fazenda Estadual far, ento, 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, por meio da 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, imprimindo-se, em destaque: o nmero do protocolo de autorizao do referido documento 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 o Conhecimento de Transporte Eletrnico, nem o substitui, serve apenas como instrumento auxiliar para o transporte da mercadoria e para a consulta do CT-e por meio da chave de acesso numrica ali impressa, representada e impressa em cdigo de barras. Permite ao detentor do documento confirmar a efetiva existncia do CT-e, por meio dos stios das Secretarias de Fazenda Estaduais autorizadoras ou Receita Federal do Brasil. O contribuinte tomador do servio de transporte, no emissor de Documentos Fiscais Eletrnicos, poder escriturar o CT-e com base nas informaes apresentadas naquele documento e sua validade vincula-se efetiva existncia do CT-e com autorizao de uso no Banco de Dados das administraes tributrias envolvidas no processo.

Pg. 9 / 158


3. Arquitetura de Comunicao com Contribuinte3.1Modelo Conceitual

Os Portais das Secretarias de Fazenda Estaduais fornecero 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 iniciase sempre pelo aplicativo do contribuinte por meio 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 contendo 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 contendorecibo que to somente confirma a recepo 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. 10 / 158


Arquitetura de ComunicaoContribuinte

Viso ConceitualSecretaria de Fazenda EstadualHTTPS Web Services Servios Sncronos Aplicao CTe Servios Assncronos Transaes

Client CTe (ERP ou software especfico )

Fluxo de Comunicao

CTe Filas de Msgs

Aplicativo de Faturamento (ERP ou software especfico )

CTes

3.2

Padres Tcnicos

3.2.1 Padro de Documento XMLa) 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: Importante destacar que cada arquivo XML ter to somente uma declarao . Nas situaes em que um documento XML contenha outros documentos XML, como ocorre com o documento XML de lote de envio de CT-e, deve-se atentar para que exista apenas uma declarao no incio do lote. b) Declarao namespace O documento XML ter to somente UMA declarao de namespace no elemento raiz do documento com o seguinte padro: (exemplo para o XML do CT-e) Veda-se o uso de declarao namespace diferente do padro estabelecido para o Projeto. A declarao do namespace da assinatura digital ser realizada na prpria tag , conforme exemplo abaixo. Cada documento XML 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. Veja exemplo a seguir:

Pg. 11 / 158


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 adotada 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 sero includas as TAGs de campos com contedo zero (para campos tipo numrico) ou vazio (para campos tipo caractere). Na gerao do arquivo XML do CT-e, sero preenchidos no modelo apenas as TAGs de campos identificados como obrigatrios no leiaute ou os campos obrigatrios por fora da legislao pertinente. Identificam-se os campos obrigatrios no leiaute pelo primeiro dgito da coluna ocorrncia (Ocorr.) que inicie com 1, ex.: 1-1, 1-2, 1-N . Os campos obrigatrios por fora da legislao pertinente devem ser informados, mesmo que no leiaute seu preenchimento seja facultativo. A regra constante do pargrafo anterior estender-se- para os campos nos quais no exista indicao de obrigatoriedade, mas com preenchimento 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.

Pg. 12 / 158


Exemplo 1: SubGrupo de Informaes de transporte de produtos perigosos (ocorrncia 0-1). Ser preenchido se a legislao especfica o exigir. 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 do 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). e) 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), fornecido pela Secretaria de Fazenda Estadual, antes de seu envio.

3.2.2 Padro de ComunicaoA comunicao entre o contribuinte e a Secretaria de Fazenda Estadual ser baseada em Web Services disponveis no Portal da Secretaria de Fazenda Estadual de circunscrio do contribuinte, exceto nos casos em que a UF autorizadora do CT-e utilize servios de SEFAZ VIRTUAL, conforme o previsto no item 3.7 deste Manual. 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 por meio de certificados digitais, eliminando a necessidade de identificao do usurio mediante 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 dos diferentes Web Services do Projeto CT-e realizada 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. 13 / 158


string string xml

Exemplo de uma mensagem de retorno padro SOAP: string string xml

3.2.3 Padro de Certificado DigitalO certificado digital utilizado no Projeto do Conhecimento de Transporte eletrnico ser emitido por Autoridade Certificadora credenciada pela Infraestrutura 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 de um dos estabelecimentos da empresa emissora do CT-e. Por mensagens, entenda-se: Pedido de Autorizao de Uso (Arquivo CT-e), Pedido de Cancelamento de CT-e, 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-se 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, no necessariamente o mesmo CNPJ do estabelecimento emissor do CT-e, devendo ter a extenso Extended Key Usage com permisso de "Autenticao Cliente".

3.2.4 Padro de Assinatura DigitalAs 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 contendo o CNPJ do estabelecimento matriz ou o CNPJ do estabelecimento emissor do CT-e objeto do pedido.

Pg. 14 / 158


Os elementos abaixo esto contidos no 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 relacionadas a seguir, 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 Raiz G G A Pai XS01 XS02 XS03 Tipo Ocor. Tam. Dec. C 1-1 1-1 1-1 Grupo da Informao da assinatura Grupo do Mtodo de Canonicalizao Atributo Algorithm de CanonicalizationMethod: http://www.w3.org/TR/2001/REC-xml-c14n20010315 Grupo do Mtodo de Assinatura Atributo Algorithm de SignedMethod: http://www.w3.org/2000/09/xmldsig#rsa-sha1 Grupo de Reference Atributo URI da tag Reference Grupo do algorithm de Transform Regra para o atributo Algorithm do Transform ser nico. Grupo de Transform Atributos vlidos Algorithm do Transform: http://www.w3.org/TR/2001/REC-xml-c14n20010315 http://www.w3.org/2000/09/xmldsig#envelopedsignature XPath Grupo do Mtodo de DigestMethod Atributo Algorithm de DigestMethod: http://www.w3.org/2000/09/xmldsig#sha1 Digest Value (Hash SHA-1 Base64) Grupo do Signature Value Grupo do KeyInfo Grupo X509 Certificado Digital x509 em Base64 Descrio/Observao

XS01 Signature XS02 SignedInfo XS03 CanonicalizationMe thod XS04 Algorithm

XS05 SignatureMethod XS06 Algorithm XS07 Reference XS08 URI XS10 Transforms XS11 unique_Transf_Alg XS12 Transform XS13 Algorithm

G A G A G

XS02 XS05 XS02 XS07 XS07

C C C

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

RC XS10 G A XS10 XS12

XS14 XPath XS15 DigestMethod XS16 Algorithm XS17 DigestValue XS18 SignatureValue XS19 KeyInfo XS20 X509Data XS21 X509Certificate

E G A E G G G E

XS12 XS07 XS15 XS07 XS01 XS01 XS19 XS20

C C C C

0-N 1-1 1-1 1-1 1-1 1-1 1-1 1-1

A assinatura do Contribuinte no CT-e ser feita na TAG identificada pelo atributo Id. Seu contedo 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

Pg. 15 / 158


dever ser informado no atributo URI da TAG . Para as demais mensagens a ser assinadas o processo o mesmo, mantendo-se sempre identificador nico para o atributo Id na TAG a ser assinada. Segue 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 essa Lista ser montada e validada em cada Portal de Secretaria de Fazenda Estadual, no momento da conferncia da assinatura digital. A assinatura digital do documento eletrnico 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: (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 EstadualPara a validao da assinatura digital, seguem as regras 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;

Pg. 16 / 158


(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-se a lista de certificados revogados disponvel no momento da conferncia da assinatura.

3.2.6 Resumo dos Padres TcnicosA tabela a seguir resume os principais padres de tecnologia utilizados:Caracterstica Web Services Meio lgico de comunicao Meio fsico de comunicao Protocolo Internet Padro de troca de mensagens Padro da mensagem Padro de certificado digital Descrio

Padro definido pelo WS-I Basic Profile 1.1 (http://www.wsi.org/Profiles/BasicProfile-1.1-2004-08-24.html). Web Services, disponibilizados pelo Portal da Secretaria de Fazenda Estadual. Internet SSL verso 3.0, com autenticao mtua atravs de certificados digitais. SOAP verso 1.2. XML no padro Style/Encoding: Document/Literal. X.509 verso 3, emitido por Autoridade Certificadora credenciada pela Infraestrutura de Chaves Pblicas Brasileira ICP-Brasil, do tipo A1 ou A3, devendo conter o CNPJ do proprietrio do certificado digital. Para a assinatura de mensagens, utilizar o certificado digital de um dos estabelecimentos da empresa emissora do CT-e. Para a transmisso, utilizar o certificado digital do responsvel pela transmisso. XML Digital Signature, Enveloped, com certificado digital 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. Ser validada alm da integridade e autoria, a cadeia de confiana com a validao das LCRs. 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 inteiros, no incluir a vrgula ou ponto decimal. Nos campos numricos com casas decimais, utilizar o ponto decimal na separao da parte inteira.

Padro de assinatura digital

Validao de assinatura digital Padres de preenchimento XML

Pg. 17 / 158


3.3

Modelo Operacional

A forma de processamento das solicitaes de servios no Conhecimento de Transporte eletrnico pode ser sncrona, caso o atendimento da solicitao de servio seja realizado 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 Recepo de CT-e Cancelamento de CT-e Inutilizao de Numerao de CT-e Consulta da situao atual do CT-e Carta de Correo de CT-e Consulta do status do servio Implementao Assncrona Sncrona Sncrona Sncrona Sncrona Sncrona

3.3.1 Servios SncronosAs solicitaes de servios de implementao sncrona so processadas imediatamente e o resultado do processamento obtido em uma nica conexo. A seguir, o fluxo simplificado de funcionamento:Servio de Implementao Sncrona Contribuinte(1) Solicitao de servio

Secretaria de Fazenda Estadual(2) Solicitao de servio

Aplicativo Cliente

Web Service(4) Resultado (3) Resultado

Processamento de Servios

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.

Pg. 18 / 158


3.3.2 Servios AssncronosAs solicitaes de servios de implementao assncrona so processadas de forma distribuda por vrios processos e o resultado do processamento somente obtido na segunda conexo. A seguir o fluxo simplificado de funcionamento:

Servio de Implementao assncrona ContribuinteEnvio de Solicitao de Servios(4) (5) (1) Solicitao de servio (3) Recibo

Secretaria de Fazenda EstadualWeb Service Recebe Solicitao de Servios (2) Solicitao de servio Fila de servios solicitados

Fila de recibos

Processamento de Servios

(7)

(6)

Consulta Recibo

(8) Consulta recibo(10) Resultado processamento

Web Service(9) Resultado processamento

Consulta recibo

Fila de servios processados

Etapas do processo ideal: (1) (2) O aplicativo do contribuinte inicia a conexo enviando uma mensagem de solicitao de servio para o Web Service de recepo de solicitao de servios; 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; 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; 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; Na Secretaria de Fazenda Estadual a solicitao de servios retirada da fila de servios solicitados pelo aplicativo do CT-e; O servio solicitado processado pelo aplicativo do CT-e e o resultado do processamento colocado na fila de servios processados; O aplicativo do contribuinte retira um recibo da fila de recibos de servios solicitados; O aplicativo do contribuinte envia uma consulta de recibo, iniciando uma conexo com o Web Service Consulta Recibo (CTeRetRecepcao); O Web Service Consulta Recibo recebe a mensagem de consulta recibo e localiza o resultado de processamento da solicitao de servio;

(3) (4)

(5) (6) (7) (8) (9)

Pg. 19 / 158


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

3.3.3 Filas e MensagensAs 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, apresenta-se o diagrama a seguir:

Estrutura de um item da fila:

CNPJ do Transmissor

Nmero do Recibo

data e hora recebimento

cUF

Verso Dados

XML de Dados

rea de controle

rea de mensagem

A estrutura de um item composta pela rea de controle (identificador) e pela rea de detalhe que contm 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 usequencial 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 o contedo do detalhe da mensagem que contm o resultado do processamento da solicitao de servio em formato XML.

Pg. 20 / 158


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 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 por meio de Banco de Dados ou qualquer outra forma, sendo transparente para o contribuinte que realizar a consulta do processamento efetuado (processos assncronos).

3.4

Padro de Mensagens dos Web Services

As chamadas dos Web Services fornecidos pelas Secretarias de Fazenda Estaduais ou Receita Federal do Brasil e os respectivos resultados do processamento so realizadas servindo-se de mensagens com o seguinte padro:

Padro de Mensagem de chamada/retorno de Web ServicecUF versaoDados Estrutura XML definida na documentao do Web Servicerea de dados (SOAP Body)

Elemento cteCabecMsg (SOAP Header)

cUF cdigo da UF de origem da mensagem. versaoDados - verso do leiaute da estrutura XML informada 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 MensagensAs 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 ao leiaute definido na documentao do Web Service acessado: xml

3.4.2 Validao da Estrutura XML das Mensagens dos Web ServicesAs informaes so enviadas ou recebidas dos Web Services atravs de mensagens no padro XML definido na documentao de cada Web Service.

Pg. 21 / 158


As alteraes de leiaute e de estrutura de dados XML realizadas nas mensagens so controladas por meio 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, o aplicativo do contribuinte deve estar preparado 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 ServicesToda mudana de leiaute das mensagens dos Web Services implica atualizao do 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); tiposGeral_v10.15.xsd (Schema XML dos tipos 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.: tiposGeral_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 (quinze) posies com 2 (dois) decimais definido no Schema tiposGeral_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 Conhecimento de Transporte Eletrnico

Pg. 22 / 158


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 na norma que introduziu a alterao. As modificaes de ordem tcnica sero divulgadas pela Coordenao Tcnica do ENCAT e ocorrero sempre que se fizerem necessrias.

3.5

Verso dos Schemas XML

3.5.1 Liberao das Verses dos Schemas para o Conhecimento de Transporte Eletrnico CT-e

Os schemas vlidos para o Conhecimento de Transporte Eletrnico estaro disponveis 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 de schema 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 Orientaes com ele compatvel. Os pacotes de liberao sero identificados pelas letras PL_CTe, seguida do nmero da verso do Manual de Orientaes 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 Orientaes do Contribuinte verso 1.00. Os schemas XML das mensagens XML 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, em que v9.99, corresponde verso do respectivo schema. Para identificar quais schemas sofreram alterao em um determinado pacote liberado, deve-se comparar o nmero da verso do schema deste pacote com o nmero da verso do pacote anterior. Exemplificando: PACOTE DATA LIBERAO SCHEMAS PL_ CTe_ 1.00.ZIP 01/04/2008 cteEnvLote_v1.00.xsd inutCTe_v1.00.xsd cancCTe_v1.00.xsd tiposGeral_v1.00.xsd PL_CTe_ 1.01.ZIP 01/06/2008 cteEnvLote _v1.30.xsd inutCTe_v1.00.xsd cancCTe_v1.00.xsd tiposGeral _v1.01.xsd

3.5.2 Pacote de Liberao PreliminarAps a divulgao de uma nova verso do Manual de Orientaes do Contribuinte, ser publicado um pacote de liberao preliminar, com vigncia limitada at o incio da fase de disponibilizao do ambiente de homologao.

Pg. 23 / 158


Durante esse perodo, os novos Schemas XML sero avaliados e testados para a identificao de eventuais falhas de implementao das alteraes realizadas no Manual de Orientaes do Contribuinte. O pacote de liberao 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 DefinitivoPara o ambiente de homologao, ser 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 LiberaoCaso haja necessidade de correo de um Schema XML por erro de implementao de regra de validao, obrigatoriedade de campo, nome de tag divergente do definido no leiaute da mensagem, que no modifique a estrutura do Schema XML nem exija 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 Orientaes do Contribuinte vigente. A identificao dos pacotes mais recentes se dar com o acrscimo de letras minsculas 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 LiberaoA divulgao de novos pacotes de liberao ou atualizaes de pacote de liberao ser realizada por meio da publicao de Notas Tcnicas no Portal Nacional do CT-e (www.cte.fazenda.gov.br) com as informaes necessrias para a implementao dos novos pacotes de liberao.

3.5.6 Controle de VersoO controle de verso de cada um dos schemas vlidos do 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; quais so as verses da parte especfica de cada modal de transporte suportados pela parte genrica. O controle de verso permite a adaptao dos sistemas de informtica das empresas participantes do Projeto em diferentes datas. Ou seja, algumas empresas podem possuir verso de leiaute mais atualizada, enquanto outras empresas ainda estejam operando com mensagens em um leiaute anterior.

Pg. 24 / 158


No esto previstas mudanas ufrequentes de leiaute de mensagens e as empresas tero 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 mensagem de erro especfica na verso do leiaute de resposta mais recente.

3.6

Schema XML do CT-e Estrutura Genrica e Estrutura Especfica do Modal de Transporte

A partir da verso 1.04, a estrutura do Schema XML do CT-e foi modificada, criando-se uma parte genrica do schema e uma parte especfica para cada modal de transporte, com o objetivo de permitir maior independncia entre os modais; assim, uma alterao no leiaute especfico para um modal no repercute nos demais.

3.6.1 Parte GenricaA estrutura genrica a parte que possui os campos (tags) de uso comum utilizados por todos os modais. Para alcanar este objetivo, foi criada no schema XML do CT-e uma estrutura genrica com um elemento do tipo any que permite a insero do XML especfico do modal, conforme demonstrado na figura a seguir:

Pg. 25 / 158


A verso do schema XML a ser utilizada na parte especfica do modal de transporte ser identificada com um atributo de verso prprio (tag versaoModal), conforme figura a seguir:

3.6.2 Parte Especfica para Cada Modal de TransporteA estrutura especfica a parte que possui os campos (tags) exclusivos do modal de transporte. A parte especfica do schema XML para cada modal de transporte ser distribuda no mesmo pacote de liberao em arquivo separado para cada um deles. A identificao do modal de transporte se dar no nome do arquivo, como segue: cteModalXXXXXXXXXXXX_v9.99.xsd Em que XXXXXXXXXXXX a identificao do modal de transporte, e v9.99 a identificao da verso. Segue exemplo de nomes de arquivos de schema XML da parte especfica de cada modal: cteModalRodoviario_v1.04.xsd (modal rodovirio, verso 1.04); cteModalAereo_v1.04.xsd (modal Aerovirio, verso 1.04); cteModalFerroviario_v1.04.xsd (modal ferrovirio, verso 1.04); cteModalAquaviario_v1.04.xsd (modal aquaviario, verso 1.04); cteModalDutoviario_v1.04.xsd (modal dutovirio, verso 1.04).

3.6.3 Parte Genrica e Parte Especfica para Cada Modal de Transporte VersesUma verso da parte genrica dever suportar mais de uma verso da parte especfica de cada modal de transporte. Normalmente, esta relao deve ser de uma para uma (1:1). Apenas em momentos de transio pode haver empresas de um modal de transporte utilizando uma verso mais atualizada, enquanto outras empresas ainda operam com um leiaute anterior da parte especfica. As SEFAZ autorizadoras devero manter nas suas aplicaes o controle de qual(is) verso(es) da parte especfica (so) suportada(s) pela parte genrica.

Pg. 26 / 158


3.7

SEFAZ Virtual

A Secretaria de Fazenda Estadual pode optar por no desenvolver sistema prprio de autorizao do Conhecimento de Transporte Eletrnico para os contribuintes de sua circunscrio. Neste sentido, os servios de autorizao de emisso do CT-e sero supridos por uma SEFAZ VIRTUAL, mediante 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 Orientaes do Contribuinte, O credenciamento de contribuintes bem como a autorizao de uso dos servios de uma determinada SEFAZ VIRTUAL responsabilidade da SEFAZ de circunscrio daqueles contribuintes. Para os sistemas das Empresas ser totalmente transparente se os servios provm da SEFAZ VIRTUAL ou de um sistema de autorizao da prpria SEFAZ de circunscrio do contribuinte. A nica mudana visvel o endereo dos Web Services em que esto disponveis os servios.

Pg. 27 / 158


4. Web ServicesOs 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 fornecido 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. A Secretaria de Fazenda Estadual autorizadora compromete-se a processar os lotes de conhecimentos de transportes recebidos em at 3 (trs) minutos e em, no mnimo, 95% (noventa e cinco por cento) do total do volume recebido no perodo de 24 (vinte e quatro) 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, observando o tempo mdio de resposta do servio nos ltimos 5 (cinco) minutos. A empresa poder optar por entrar em contingncia, ou seja, emitir o DACTE em formulrio de segurana do documento auxiliar (FS-DA), caso julgue que o tempo de resposta no seja aceitvel. No recibo de recepo do lote, tambm ser informado o tempo mdio de resposta do servio nos ltimos 5 (cinco) minutos. Cada Portal de Secretaria de Fazenda Estadual disponibilizar o resultado do processamento do lote por um perodo mnimo de 24 (vinte e quatro) horas (cteConsLote). Aps o trmino do processamento, a informao da situao atual de cada conhecimento de transporte estar disponvel para consulta individual (consSitCTe). c) Para os servios sncronos, o envio da solicitao e a obteno do retorno sero realizados na mesma conexo por meio de um nico mtodo. d) As URLs dos Web Services encontram-se no Anexo III deste manual e no Portal do Ambiente Nacional (www.cte.fazenda.gov.br). Acessando-se a URL, pode-se obter 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 / 158


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 CteRecepcaoTransmisso de Lote de CT-e Contribuinte Secretaria de Fazenda EstadualWeb Service : CteRecepcao Envio do lote de CT-e Client CT-e Recibo cteRecepcaoLote msgs Filas de Entrada . Proc. Processamento Aplicao CT-e

Funo: servio destinado recepo de mensagens de lote de CT-e. Processo: assncrono. Mtodo: cteRecepcaoLote

4.1.2 Leiaute Mensagem de EntradaEntrada: Estrutura XML com o lote de conhecimento de transporte

Pg. 29 / 158


Schema XML: enviCte_v99.99.xsd# Campo Ele Raiz A E Pai AP01 AP01 Tipo Ocor. Tam. Dec. N N 1-1 1-1 1-4 1-15 2 TAG raiz Verso do leiaute Identificador de controle do envio do lote. Nmero sequencial autoincremental, de controle correspondente ao identificador nico do lote enviado. A responsabilidade de gerar e controlar esse nmero exclusiva do contribuinte. Conjunto de CT-e 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). Descrio/Observao

AP01 enviCTe AP02 Verso AP03 idLote

AP04 CTe

G

AP01

xml

1-50

-

4.1.3 Leiaute Mensagem de RetornoRetorno: Estrutura XML com a mensagem do resultado da transmisso. Schema XML: retEnviCte_v99.99.xsd# Campo Ele Raiz A E E E E E G E Pai AR01 AR01 AR01 AR01 AR01 AR01 AR01 AR07 Tipo Ocor. Tam. Dec. N N N C N C N 1-1 1-1 1-1 1-1 1-1 1-1 0-1 1-1 1-4 1 2 1-20 3 1-255 15 2 Descrio/Observao TAG raiz da Resposta Verso do leiaute Identificao do Ambiente: 1 Produo / 2 - Homologao Cdigo da UF que atendeu a solicitao. Verso do Aplicativo que recebeu o Lote. Cdigo do status da resposta (vide item 5.1.1) Descrio literal do status da resposta Dados do Recibo do Lote (S gerado se o Lote for aceito) 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 sequenciais (vide item 5.5) Data e Hora do Recebimento Formato = AAAA-MM-DDTHH:MM:SS Preenchido com data e hora do recebimento do lote. 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.

AR01 retEnviCte AR02 versao AR03 tpAmb AR03a cUF AR04 verAplic AR05 cStat AR06 xMotivo AR07 infRec AR08 nRec

AR09 dhRecbto

E

AR07

D

1-1

-

AR10 tMed

E

AR07

N

1-1

N

As mensagens recebidas com erro geram uma mensagem de erro. Nas demais hipteses, retornar-se- um recibo com nmero, data, hora local de recebimento e tempo mdio de resposta do servio nos ltimos 5 (cinco) 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.

Pg. 30 / 158


4.1.4 Descrio do Processo de Recepo de Lotes de CT-eEste 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 (cinquenta) CT-e por lote. O agrupamento destes CT-e dentro do lote deve ser feito, por uma restrio operacional e de controle, respeitando-se a regra em que todos os CT-e do lote devem ser do mesmo estabelecimento (mesmo CNPJ e IE do emitente). O tamanho mximo do lote de CT-e limitado em 500 (quinhentos) kB, 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 (cinquenta) conhecimentos. Devero ser realizadas as validaes e procedimentos que seguem.

4.1.5 Validao do Certificado de TransmissoValidao do Certificado Digital do Transmissor (protocolo SSL) # Regra de Validao Crtica Obrig. Msg 280 Efeito Rej. 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" A02 Validade do Certificado (data incio e data fim) 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 A04 LCR do Certificado de Transmissor - Falta o endereo da LCR (CRL DistributionPoint) - LCR indisponvel - LCR invlida A05 Certificado do Transmissor revogado A06 Certificado Raiz difere da "ICP-Brasil" A07 Falta a extenso de CNPJ no Certificado (OtherName OID=2.16.76.1.3.3)

Obrig. Obrig.

281 283

Rej. Rej.

Obrig.

286

Rej.

Obrig. Obrig. Obrig.

284 285 282

Rej. Rej. 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 ServiceValidao Inicial da Mensagem no Web Service # Regra de Validao Aplic. Obrig. Facult. Msg 214 243 108 109 Efeito Rej. Rej. Rej. Rej. B01 Tamanho do XML de Dados superior a 500 Kbytes B02 XML de Dados Mal Formado

B03 Verifica se o Servidor de Processamento est Paralisado Obrig. Momentaneamente B04 Verifica se o Servidor de Processamento est Paralisado sem Previso Obrig.

Pg. 31 / 158


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 de o controle de tamanho ter sido implementado por aplicativo, retorna-se a mensagem de erro 214. No momento do recebimento da mensagem no Web Service, a critrio de cada unidade federada autorizadora, poder ser verificado se o XML de dados est bem formado. Esta verificao til para as UF que desejam 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 esteja paralisado, devero implementar as validaes 108 e 109. Estas validaes podero ser dispensadas caso o Web Service no fique disponvel quando o servio estiver paralisado.

4.1.7 Validao das Informaes de Controle da Chamada ao Web ServiceValidao das Informaes de Controle da Chamada ao Web Service# Regra de Validao Aplic. Facult. Obrig. Obrig. Msg 242 409 410 411 238 239 Efeito Rej. Rej. Rej. Rej. Rej. Rej. C01 Elemento cteCabecMsg inexistente no SOAP Header C02 Campo cUF inexistente no elemento cteCabecMsg do SOAP Header C03 Verificar se a UF informada no campo cUF atendida pelo WebService

C04 Campo versaoDados inexistente no elemento cteCabecMsg do SOAP Obrig. Header C05 Verso dos Dados informada superior verso vigente C06 Verso dos Dados no suportada Facult. Obrig.

Os dados referentes verso do leiaute do lote e UF de origem do emissor de CT-e 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 e rejeitar 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 utilizada pelo Servidor de Processamento do 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 ReciboNo existindo qualquer problema nas validaes, o aplicativo dever gerar um nmero de recibo de lote (vide item 5.5) e gravar a mensagem juntamente com 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: identificao do ambiente; verso do aplicativo;

Pg. 32 / 158


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 (cinco) minutos (vide detalhamento da forma de clculo no item 5.7).

Caso ocorra algum problema de validao, o aplicativo 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-eO processamento de Lote de CT-e recepcionado realizado pelo Servidor de Processamento de CT-e, que consome as mensagens armazenadas na fila de entrada pelo mtodo CteRecepcao. Este mtodo faz a validao de forma e das regras de negcio e armazena o resultado do processamento na fila de sada.

4.1.10 Validao da rea de Dadosa) Validao de Forma da rea de Dados A validao de forma da rea de dados da mensagem realizada conforme a seguinte regra:Validao da rea de Dados da Mensagem # Regra de Validao Aplic. Obrig. Facul. Facul. Obrig. Obrig. Msg 225 598 599 404 402 457 589 590 Efeito Rej. Rej. Rej. Rej. Rej. Rej. Rej. Rej. D01 Verifica Schema XML da rea de Dados (parte genrica) D01a Verifica a existncia de qualquer namespace diverso do namespace padro do CT-e (http://www.portalfiscal.inf.br/cte) D01b Verifica a existncia de caracteres de edio no incio ou fim da mensagem ou entre as tags D02 Verifica o uso de prefixo no namespace D03 Verifica se o XML utiliza codificao diferente de UTF-8

D04 Verifica se o lote contm CT-e de mais de um estabelecimento emissor Obrig. (considerar o CNPJ e IE do emitente de cada CT-e) D05 Verifica se o lote contm CT-e de mais de um modal de transporte D06 Verifica se o lote contem CT-e de mais de uma verso de modal de transporte Obrig. Obrig.

A existncia de qualquer erro na validao de forma da rea de dados (item 4.1.10 a) implica a rejeio de todo o lote. A validao do schema XML do lote de CT-e pela SEFAZ autorizadora ser feita em duas etapas: - A primeira etapa deve validar a estrutura genrica do lote, submetendo a mensagem contra o schema XML definido para o lote. Em caso de erro, retornar o cdigo 225; - A segunda etapa (realizada mais adiante) deve validar a estrutura especfica do modal de transporte para cada um dos documentos de CT-e do lote. Em caso de erro, retornar o cdigo 580.

Pg. 33 / 158


b) Validao do Certificado Digital de Assinatura Nesta fase so extrados todos os CT-e das mensagens de envio de lote e validadas as seguintes regras de negcio para cada CT-e:Validao do Certificado Digital Utilizado na Assinatura Digital do CT-e # Regra de Validao Aplic. Obrig. Msg 290 Efeito Rej. 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 E02 Validade do Certificado (data de incio e data de fim) E03 Falta a extenso de CNPJ no Certificado (OtherName OID=2.16.76.1.3.3) 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 E05 LCR do Certificado de Assinatura: - Falta o endereo da LCR (CRLDistributionPoint) - Erro no acesso a LCR ou LCR inexistente E06 Certificado de Assinatura revogado E07 Certificado Raiz difere da ICP-Brasil


291 292 293

Rej. Rej. Rej.

Obrig.

296

Rej.

Obrig. Obrig.

294 295

Rej. Rej.

c) Validao da Assinatura DigitalValidao da Assinatura Digital do CT-e # Regra de Validao Aplic. Obrig. Msg 298 Efeito Rej. F01 Assinatura difere do padro do CT-e: - 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 F02 Valor da assinatura (SignatureValue) difere do valor calculado F03 CNPJ-Base do Emitente difere do CNPJ-Base do Certificado Digital

Obrig. Obrig.

297 213

Rej. Rej.

d) Validao de Regras de Negcio do CT-eValidao do CT-e Regras de Negcio # Regras de Validao Aplic. Obrig. Obrig. Obrig. Obrig. Obrig. Msg 252 226 247 494 586 Efeito Rej. Rej. Rej. Rej. Rej. G001 Tipo do ambiente do CT-e difere do ambiente do Web Service G002 Cdigo da UF do Emitente difere da UF do Web Service G003 Sigla da UF do Emitente difere da UF do Web Service G004 Processo de emisso informado invlido (diferente de 0 ou 3) G004a Se forma de emisso do CT-e = 1 (Normal): dhCont e xJust no devem ser informados

Pg. 34 / 158


Validao do CT-e Regras de Negcio # Regras de Validao Aplic. Obrig. Obrig Obrig. Msg 587 588 227 Efeito Rej. Rej. Rej. G004b Se forma de emisso do CT-e for diferente de 1 (Normal): dhCont e xJust devem ser informados G004c Se Data de entrada em contingncia estiver informada, esta deve ser menor ou igual data de emisso G005 Campo ID invlido - Falta literal "CTe" - Chave de Acesso do campo ID difere da concatenao dos campos correspondentes G006 Dgito Verificador invlido da Chave de acesso resultante da concatenao dos campos correspondentes G007 Se finalidade do CT-e= 0 (Normal) ou 3 (Substituio): deve existir o grupo de CT-e Normal G008 Se finalidade do CT-e= 1 (Complemento): deve existir o grupo de CT-e Complementar G009 Tomador do servio informado como remetente, mas inexiste remetente G010 Tomador do servio informado como expedidor, mas inexiste expedidor G011 Tomador do servio informado como recebedor, mas inexiste recebedor G012 Tomador do servio informado como destinatrio, mas inexiste destinatrio G017a Se finalidade do CT-e= 0 (Normal) ou 3 (Substituio): - verificar se a Verso do modal de transporte suportada G017b Se finalidade do CT-e= 0 (Normal) ou 3 (Substituio): - verifica Schema XML conforme o modal de transporte (parte especfica do modal de transporte) G017c Se finalidade do CT-e= 0 (Normal) ou 3 (Substituio): - verifica se o Valor Total da Carga foi informado para modal de transporte diferente de Dutovirio G017d Se finalidade do CT-e= 0 (Normal) ou 3 (Substituio): e modal=ferrovirio - se (trfego mtuo), o grupo Trfego Mtuo deve ser informado G017e Se finalidade do CT-e= 0 (Normal) ou 3 (Substituio): e modal=ferrovirio - se o responsvel pelo faturamento for a ferrovia de origem (), a ferrovia emitente do CT-e deve ser igual a 1 (ferrovia de origem). G017f Se finalidade do CT-e= 0 (Normal) ou 3 (Substituio): e modal=ferrovirio - se o responsvel pelo faturamento for a ferrovia de destino deve ser referenciado o CT-e emitido pela ferrovia de origem **Esta regra de validao dever ser aplicada somente a partir da obrigatoriedade para o modal Ferrovirio. G017g Se informados remetente e NF-e (infNfe), para cada uma das NF-es relacionadas: - Dgito Verificador invlido na Chave de acesso de NF-e transportada Retornar a primeira chave de acesso invlida. G018 Remetente no informado para tipo de servio diferente de redespacho intermedirio G019 Destinatrio no informado para tipo de servio diferente de redespacho intermedirio G020 Expedidor deve ser informado para tipo de servio de redespacho intermedirio

Obrig. Obrig. Obrig. Obrig. Obrig. Obrig. Obrig. Obrig Obrig.

253 458 459 460 461 462 463 579 580

Rej. Rej. Rej. Rej. Rej. Rej. Rej. Rej Rej.

Obrig

581

Rej.

Obrig

582

Rej

Obrig

583

Rej

Obrig

584

Rej

Obrig

591

Rej


469 470 474

Rej. Rej. Rej.

Pg. 35 / 158


Validao do CT-e Regras de Negcio # Regras de Validao Aplic. Obrig. Obrig. Obrig. Obrig. Obrig. Obrig. Msg 475 496 499 497 498 565 Efeito Rej. Rej. Rej. Rej. Rej. Rej. G021 Recebedor deve ser informado para tipo de servio de redespacho intermedirio G024 Se finalidade do CT-e= 2 (Anulao): deve existir o grupo de CT-e de Anulao G025 Se finalidade do CT-e= 2 (Anulao): o tipo de emisso dever ser normal G026 Se finalidade do CT-e= 2 (Anulao): o CT-e objeto da anulao deve existir G027 Se finalidade do CT-e= 2 (Anulao): o CT-e objeto da anulao deve estar com a situao autorizado o uso. G028 Se finalidade do CT-e= 2 (Anulao): somente o emitente pode anular o CT-e. O CT-e original e o de anulao devem possuir o mesmo CNPJ de emitente. G030 Se finalidade do CT-e= 2 (Anulao): o CT-e objeto de anulao deve ter finalidade = 0 (Normal) G031 Se finalidade do CT-e= 2 (Anulao): a data de emisso do CT-e de anulao deve ocorrer em at 60 dias, ou outro limite conforme critrio definido pela SEFAZ (a SEFAZ Virtual deve considerar a hora local do emissor para a validao) da data de emisso do CT-e objeto de anulao. G032 Se finalidade do CT-e= 2 (Anulao): o valor da prestao do servio e o do ICMS devem ser iguais ao do CT-e original. G033 Se finalidade do CT-e= 2 (Anulao): o CT-e objeto da anulao no pode ter sido anulado anteriormente G034 Se finalidade do CT-e= 2 (Anulao): o CT-e objeto da anulao no pode ter sido substitudo anteriormente G035 Se finalidade do CT-e= 3 (Substituio): o tipo de emisso deve ser normal G036 Se finalidade do CT-e= 3 (Substituio): deve existir o grupo de informaes do CT-e de substituio G037 Se finalidade do CT-e= 3 (Substituio): o CT-e substitudo deve existir G038 Se finalidade do CT-e= 3 (Substituio): o CT-e substitudo deve estar com situao autorizada (no pode estar cancelado ou denegado) G039 Se finalidade do CT-e= 3 (Substituio): o CT-e substitudo no pode ter sido substitudo anteriormente G040 Se finalidade do CT-e= 3 (Substituio): o CT-e substitudo deve ter finalidade = 0 (Normal) G040a Se finalidade do CT-e= 3 (Substituio): se foi informado o grupo tomaICMS (tomador contribuinte do ICMS), o CT-e a ser substitudo (chCte) no pode ter sido anulado. G041 Se finalidade do CT-e=3 (Substituio): CNPJ do emitente do CT-e substituto deve ser igual ao informado no CT-e substitudo G042 Se finalidade do CT-e=3 (Substituio): CNPJ do remetente do CT-e substituto deve ser igual ao informado no CT-e substitudo G043 Se finalidade do CT-e=3 (Substituio): CNPJ do destinatrio do CT-e substituto deve ser igual ao informado no CT-e substitudo G044 Se finalidade do CT-e=3 (Substituio): CNPJ do expedidor do CT-e substituto deve ser igual ao informado no CT-e substitudo G045 Se finalidade do CT-e=3 (Substituio): CNPJ do recebedor do CT-e substituto deve ser igual ao informado no CT-e substitudo G046 Se finalidade do CT-e=3 (Substituio): CNPJ do tomador do CT-e substituto deve ser igual ao informado no CT-e substitudo G047 Se finalidade do CT-e=3 (Substituio): IE do emitente do CT-e substituto deve ser igual ao informado no CT-e substitudo

Obrig. Obrig.

500 501

Rej. Rej.

Obrig. Obrig. Obrig Obrig. Obrig. Obrig Obrig Obrig Obrig Obrig

502 566 567 503 505 568 569 570 571 577

Rej. Rej. Rej Rej. Rej. Rej Rej Rej Rej Rej

Obrig. Obrig. Obrig. Obrig. Obrig. Obrig. Obrig.

510 511 512 550 551 552 553

Rej. Rej. Rej. Rej. Rej. Rej. Rej.

Pg. 36 / 158


Validao do CT-e Regras de Negcio # Regras de Validao Aplic. Obrig. Obrig. Obrig. Obrig. Obrig. Obrig. Obrig. Obrig. Msg 554 555 556 557 558 559 560 563 Efeito Rej. Rej. Rej. Rej. Rej. Rej. Rej. Rej. G048 Se finalidade do CT-e=3 (Substituio): IE do remetente do CT-e substituto deve ser igual ao informado no CT-e substitudo G049 Se finalidade do CT-e=3 (Substituio): IE do destinatrio do CT-e substituto deve ser igual ao informado no CT-e substitudo G050 Se finalidade do CT-e=3 (Substituio): IE do recebedor do CT-e substituto deve ser igual ao informado no CT-e substitudo G051 Se finalidade do CT-e=3 (Substituio): IE do expedidor do CT-e substituto deve ser igual ao informado no CT-e substitudo G052 Se finalidade do CT-e=3 (Substituio): IE do tomador do CT-e substituto deve ser igual ao informado no CT-e substitudo G053 Se finalidade do CT-e=3 (Substituio): UF de incio da prestao do CT-e substituto deve ser igual ao informado no CT-e substitudo G054 Se finalidade do CT-e=3 (Substituio): UF de fim da prestao do CTe substituto deve ser igual ao informado no CT-e substitudo G055 Se finalidade do CT-e=3 (Substituio): a data de emisso do CT-e de substituio deve ocorrer em at 60 dias, ou outro limite conforme critrio definido pela SEFAZ (a SEFAZ Virtual deve considerar a hora local do emissor para a validao) da data de emisso do CT-e objeto substituio G056 Se finalidade do CT-e=3 (Substituio): se foi informado o CT-e de anulao no grupo do Tomador no contribuinte do ICMS, o CT-e de anulao deve existir G057 Se finalidade do CT-e=3 (Substituio): se foi informado o CT-e de anulao no grupo do Tomador no contribuinte do ICMS, este CTe informado deve ter finalidade=2(Anulao) G057a Se finalidade do CT-e=3 (Substituio): se foi informado o CT-e de anulao no grupo do Tomador no contribuinte do ICMS, este CTe anulao deve ter anulado o mesmo CT-e que agora est sendo substitudo. G058 CNPJ Emitente invlido (dgito controle, zeros ou nulo) G059 IE Emitente no informada (zeros ou nulo)

Obrig

572

Rej

Obrig

573

Rej

Obrig

578

Rej

Obrig. Obrig.

207 229 209

Rej. Rej. Rej.

G060 IE Emitente invlida (erro no dgito de controle) Obrig. 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. G061 Acessar Cadastro Contribuinte p/ Emitente: Facult. - CNPJ emitente no cadastrado G062 - Emitente no credenciado G063 - IE Emitente no cadastrada G064 - IE Emitente no vinculada ao CNPJ G064a - IE emitente no autorizada a emitir CT-e para o modal de transporte informado G065 - Emitente em situao irregular perante o Fisco (tratar duplicidade na insero do CT-e, evitando a insero de mais de um CT-e denegado) G066 Data/Hora de Emisso posterior Data/Hora de Recebimento (a SEFAZ Virtual deve considerar a hora local do emissor para a validao). A SEFAZ deve tolerar uma diferena mxima de 5 minutos quando a data/hora de emisso for maior que a data de recebimento, em funo da sincronizao de horrio de servidores. Obrig. Facult. Obrig. Obrig. Obrig.

245 203 230 231 585 301 ou 205 212

Rej. Rej. Rej. Rej. Rej. Den.

Obrig.

Rej.

Pg. 37 / 158


Validao do CT-e Regras de Negcio # Regras de Validao Aplic. Obrig. Msg 228 Efeito Rej. G067 Data de Emisso ocorrida h mais de 60 dias, ou outro limite conforme critrio definido pela SEFAZ (a SEFAZ Virtual deve considerar a hora local do emissor para a validao) G068 CNPJ Remetente informado: CNPJ invlido (dgito de controle, zeros) G069 CPF Remetente informado: CPF invlido (dgito de controle, zeros) G070 Remetente informado: Cdigo Municpio invlido (dgito de controle), vide item 2.1 do Anexo II. G071 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. Obrig. Facult.

415 416 417

Rej. Rej. Rej.

Obrig.

418

Rej

G072 IE Remetente informado: IE invlida (erro no dgito de controle) Obrig. 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. G073 Se o Remetente informado for contribuinte do ICMS

Documents

Manual CTe 1.0.4b