Manual CTe v103

Conhecimento de Transporte EletrnicoManual de Integrao - Contribuinte

Projeto Conhecimento de Transporte Eletrnico

Manual de Integrao - ContribuintePadres Tcnicos de Comunicao

Verso 1.0.3 Agosto 2009

Pg. 1 / 136


Controle de VersesVerso 1.00 1.01 1.01A 1.01B 1.02pre 1.02 1.03 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

Pg. 2 / 136


Identificao e vigncia do ManualVerso do manual Data de divulgao 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

1.0.3 04/08/2009 PL_CTe_103 01/09/2009 a definir

Verses de leiautes do PL_CTe_103Leiaute CTe enviCTe retEnviCTe consReciCTe retconsReciCTe procCTe cancCTe retCancCTe procCancCTe inutCTe retInutCTeverso

1.03 1.03 1.03 1.03 1.03 1.03 1.03 1.03 1.03 1.03 1.03

Schema XML cte_v103.xsd enviCte_v1.03.xsd retEnviCte_v1.03.xsd consReciCte_v1.03.xsd retConsReciCte_v1.03.xsd procCte_v1.03.xsd cancCte_v1.03.xsd retCancCte_v1.03.xsd procCancCte_v1.03.xsd inutCTe_v1.03.xsd retInutCTe_v1.03.xsd

procInutCTe consSitCTe retConsSitCTe consStatServ retConsStatServ

1.03 1.03 1.03 1.03 1.03

procInutCTe_v1.03.xsd consSitCte_v1.03.xsd retConsSitCte_v1.03.xsd consStatServCte_v1.03.xsd retconsStatServ_v1.01.xsd

Observao Leiaute do CT-e. 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 CT-e. 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.

Pg. 3 / 136


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 ........... 17 3.2.6 Resumo dos Padres Tcnicos ...................................................................... 18 3.3 Modelo operacional .............................................................................................. 19 3.3.1 Servios sncronos ......................................................................................... 19 3.3.2 Servios assncronos...................................................................................... 20 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 Conhecimento de Transporte Eletrnico CT-e ......................................................................................................... 24 3.5.2 Pacote de Liberao Preliminar ...................................................................... 24 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 ......................................................................................... 25 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 ................................. 30 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 .................................................................... 39 4.2 Web Service CteRetRecepcao .......................................................................... 41 4.2.1 Leiaute Mensagem de Entrada ....................................................................... 41 4.2.2 Leiaute Mensagem de Retorno ....................................................................... 41 4.2.3 Descrio do Processo de Web Service ......................................................... 42 4.2.4 Validao do Certificado de Transmisso ....................................................... 43 4.2.5 Validao Inicial da Mensagem no Web Service ............................................ 43 4.2.6 Validao das informaes de controle da chamada ao Web Service ............ 44 4.2.7 Validao da rea de Dados .......................................................................... 44 4.2.8 Final do Processamento ................................................................................. 45 1. 2.

Pg. 4 / 136


4.3 Web Service CteCancelamento ......................................................................... 46 4.3.1 Leiaute Mensagem de Entrada ....................................................................... 46 4.3.2 Leiaute Mensagem de Retorno ....................................................................... 46 4.3.3 Descrio do Processo de Web Service ......................................................... 47 4.3.4 Validao do Certificado de Transmisso ....................................................... 47 4.3.5 Validao Inicial da Mensagem no Web Service ............................................ 49 4.3.6 Validao das informaes de controle da chamada ao Web Service ............ 49 4.3.7 Validao da rea de Dados .......................................................................... 49 4.3.8 Final do Processamento ................................................................................. 51 4.4 Web Service - CteInutilizacao............................................................................... 52 4.4.1 Leiaute Mensagem de Entrada ....................................................................... 52 4.4.2 Leiaute Mensagem de Retorno ....................................................................... 53 4.4.3 Descrio do Processo de Web Service ......................................................... 53 4.4.4 Validao do Certificado de Transmisso ....................................................... 54 4.4.5 Validao Inicial da Mensagem no Web Service ............................................ 54 4.4.6 Validao das informaes de controle da chamada ao Web Service ............ 55 4.4.7 Validao da rea de Dados .......................................................................... 55 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 .......................................................................... 63 4.6.8 Final do Processamento ................................................................................. 64 4.7 Web Service CadConsultaCadastro .................................................................. 65 4.7.1 Descrio do Processo de Web Service ......................................................... 65 4.7.2 Onde obter as definies deste Web Service ................................................. 65 4.7.3 Onde obter os schemas XML deste Web Service ........................................... 66 4.7.4 Diferenas na estrutura de chamada do Web Service .................................... 66 5. Web Services Informaes Adicionais .......................................................... 67 5.1 Regras de validao ............................................................................................. 67 5.1.1 Tabela de cdigos de erros e descries de mensagens de erros.................. 67 5.2 Padro de nomes para os arquivos ...................................................................... 72 5.3 Tratamento de caracteres especiais no texto de XML .......................................... 73 5.4 Chave de Acesso do CT-e ................................................................................... 73 5.5 Nmero do Recibo de Lote ................................................................................... 74 5.6 Nmero do protocolo ............................................................................................ 75 5.7 Tempo mdio de resposta .................................................................................... 75 6. Cdigo de Barra .............................................................................................. 76 6.1 Clculo do dgito verificador do CODE-128C........................................................ 77 6.2 Representao simblica do cdigo ..................................................................... 77 7. DACTE ............................................................................................................ 78 8. Contingncia ................................................................................................... 79

Pg. 5 / 136


9. Ambiente de Homologao / Produo ........................................................... 80 10. Distribuio do CT-e para o Tomador do Servio ............................................ 81 10.1 Processo de Distribuio ...................................................................................... 81 10.2 Leiaute da Distribuio: CT-e ............................................................................... 81 11. Compartilhamento de informaes do CT-e entre rgos Pblicos................. 82 11.1 Processo de Compartilhamento ........................................................................... 82 11.2 Leiaute de compartilhamento: CT-e..................................................................... 83 11.3 Leiaute de compartilhamento: Cancelamento de CT-e ........................................ 83 11.4 Leiaute de compartilhamento: Inutilizao de Numerao de CT-e ..................... 83 11.5 Compartilhamento de documentos com outros rgos pblicos ........................... 83 Anexo I Leiaute do CT-e ................................................................................................... 84 Anexo II Modelo de DACTE ............................................................................................ 123 Anexo III Tabelas de UF, Municpio e Pas ..................................................................... 130 1. Tabela de cdigo de UF do IBGE .................................................................. 130 2. Tabela de cdigo de Municpio do IBGE ........................................................ 130 2.1 Validao do cdigo de Municpio ...................................................................... 131 2.2 Exemplo de clculo do dgito de controle do cdigo de Municpio ...................... 131 2.3 Exceo no clculo do dgito de controle do cdigo de Municpio ...................... 132 3. Tabela de cdigo de Pas do BACEN ............................................................ 132 3.1 Validao do cdigo de Pas .............................................................................. 132 3.2 Exemplo de clculo do dgito de controle do cdigo de Pas .............................. 133 3.3 Exceo no clculo do dgito de controle do cdigo de Pas .............................. 133 Anexo IV WS disponveis ................................................................................................ 134 Anexo V Conjunto de caracteres Cdigo de Barras CODE-128C ................................... 135 Anexo VI Projeto Piloto do CT-e ..................................................................................... 136

Pg. 6 / 136


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. 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 no decorrer do aprofundamento das discusses e experincias adquiridas durante a fase de implantao do projeto.

Pg. 7 / 136


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 Agencias 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. Documentos fiscais eletrnicos simplificam o cumprimento das obrigaes acessrias dos contribuintes e permitem um melhor acompanhamento das operaes comerciais pelo Fisco, mostrando-se uma soluo vantajosa para todos os envolvidos nas transaes com estes documentos. A possibilidade do uso de documentos fiscais eletrnicos em vez dos documentos tradicionalmente emitidos em papeis esta prevista no pargrafo nico da clasula segunda do Protocolo ENAT 03/2005. O Conhecimento de Transporte Eletrnico 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 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

De maneira simplificada, a empresa emissora de CT-e gerar um arquivo eletrnico contendo as informaes fiscais da prestao de servio de transporte, o qual dever ser assinado digitalmente, de maneira a garantir a integridade dos dados e a autoria do emissor. Este arquivo

Pg. 8 / 136


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 dever 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, 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 um Conhecimento de Transporte, nem o substitui, servindo apenas como instrumento auxiliar para o transporte da mercadoria e consulta do CT-e por meio da chave de acesso impressa no mesmo, representada e tambm impressa em cdigo de barras, permitindo ao detentor do documento confirmar a efetiva existncia do CT-e, atravs dos stios das Secretarias de Fazenda Estaduais autorizadoras ou Receita Federal. 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. 9 / 136


3. Arquitetura de Comunicao com Contribuinte3.1Modelo 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. 10 / 136


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 3.2.1

Padres TcnicosPadro 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. Veja exemplo a seguir:

Pg. 11 / 136


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). Na gerao do arquivo XML do CT-e, devero ser preenchidos no modelo apenas as TAGs de campos identificados como obrigatrios no leiaute ou os campos obrigatrios por fora da legislao pertinente. Os campos obrigatrios no leiaute so identificados pelo primeiro dgito da coluna ocorrncia (Ocorr.) do leiaute 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 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.

Pg. 12 / 136


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 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 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 / 136


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

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

Pg. 14 / 136


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, 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

Pg. 15 / 136


serem assinadas, o processo o mesmo mantendo sempre um identificador nico para o atributo Id na TAG a ser assinada. Segue um exemplo:

Pg. 16 / 136


... 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 em cada Portal de 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: (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);

Pg. 17 / 136


(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 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 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. 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 inteiro, 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. 18 / 136


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 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 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 sncronos

As 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. 19 / 136


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. 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. 20 / 136


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

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

Pg. 21 / 136


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

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 informado na rea de dados. rea de Dados estrutura XML varivel definida na documentao do Web Service acessado.Informaes de controle e rea de dados das mensagens

3.4.1

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

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

Pg. 22 / 136


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, o aplicativo do contribuinte deve esta 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 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); 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 posies com 2 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. 23 / 136


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 podero ocorrer sempre que se fizerem necessrias.

3.5 3.5.1

Verso dos SchemasLiberao das verses dos Schemas para o Conhecimento de Transporte Eletrnico CT-e

Os schemas vlidos para o 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 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 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 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 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 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.

Pg. 24 / 136


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 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 alguma situao 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.cte.fazenda.gov.br) com as informaes necessrias para a implementao dos novos pacotes de liberao.

3.5.6

Controle de Verso

O 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. Este controle de verso 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.

Pg. 25 / 136


3.6

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 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. 26 / 136


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 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. A Secretaria de Fazenda Estadual autorizadora se compromete a processar os lotes de conhecimentos de transportes recebidos 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 seja 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. 27 / 136


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

Transmisso 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 Entrada

Entrada: Estrutura XML com o lote de conhecimento de transporte

Pg. 28 / 136


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 seqencial auto-incremental, 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 Retorno

Retorno: 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 seqenciais (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 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.

Pg. 29 / 136


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. 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 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 Service Validao Inicial da Mensagem no Web Service

#

Regra de Validao

Aplic. Obrig. Facult. de Processamento est Paralisado Obrig. Obrig.

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 Momentaneamente

B04 Verifica se o Servidor de Processamento est Paralisado sem Previso

Pg. 30 / 136


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 controle de tamanho ter sido implementado por aplicativo, teremos a devoluo da mensagem de erro 214. No momento do recebimento da mensagem no Web Service, a critrio de cada unidade federada, poder ser verificado se o XML de dados esteja 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 Service

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

A informao da verso do leiaute do lote e a 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, 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 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 Recibo

No 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; o cdigo 103 e o literal Lote recebido com Sucesso;

Pg. 31 / 136


o cdigo da UF que atendeu a solicitao; o nmero do recibo (vide item 5.5), com data, hora local de recebimento da mensagem; tempo mdio de resposta do servio de processamento dos lotes nos ltimos 5 minutos (vide detalhamento da forma de clculo no item 5.7).

Caso ocorra algum problema de validao, o aplicativo dever retornar uma mensagem 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 recepcionado realizado pelo Servidor de Processamento de CT-e que consome as mensagens armazenadas na fila de entrada pelo mtodo CteRecepcao que 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 com a seguinte regra:Validao da rea de dados da mensagem # Regra de Validao Aplic. Obrig. Obrig. Obrig. Msg 225 404 402 457 Efeito Rej. Rej. Rej. Rej. D01 Verifica Schema XML da rea de Dados 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)

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 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 incio e data fim)

Obrig.

291

Rej.

Pg. 32 / 136


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

Obrig. Obrig.

292 293

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 F04 CNPJ do Certificado Digital difere do CNPJ da Matriz e do CNPJ do Emitente

Obrig. Obrig. Facult.

297 213 244

Rej. 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 227 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 ServiceG004 Processo de emisso informado invlido (diferente de 0 ou 3)

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): deve existir o grupo de CT-e NormalG008 Se finalidade do CT-e= 1 (Complemento): deve existir o grupo de CT-e

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

253 458 459 460 461 462 463

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

Complementar G009 Tomador do servio informado como remetente, mas inexiste remetenteG010 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

Pg. 33 / 136


Validao do CT-e Regras de Negcio # Regras de Validao Aplic. Obrig. Obrig. Obrig. Obrig. Obrig. Obrig. Obrig. Obrig. Obrig. Obrig. Obrig. Obrig. Obrig. Obrig. Obrig. Obrig. Msg 464 465 466 467 468 469 470 474 475 476 477 496 499 497 498 565 Efeito Rej. Rej. Rej. Rej. Rej. Rej. Rej. Rej. Rej. Rej. Rej. Rej. Rej. Rej. Rej. Rej.G013 CT-e normal e modal = rodovirio, mas inexiste o grupo do modal G014 CT-e normal e modal = areo, mas inexiste o grupo do modal G015 CT-e normal e modal = aquavirio, mas inexiste o grupo do modal G016 CT-e normal e modal = ferrovirio, mas inexiste o grupo do modal G017 CT-e normal e modal = dutovirio, mas inexiste o grupo do modal G018 Remetente no informado para tipo de servio diferente de redespacho G019 G020 G021 G022 G023G024 G025

intermedirio Destinatrio no informado para tipo de servio diferente de redespacho intermedirio Expedidor deve ser informado para tipo de servio de redespacho intermedirio Recebedor deve ser informado para tipo de servio de redespacho intermedirio O tomador do servio no tipo de servio normal no pode ser o expedidor O tomador do servio no tipo de servio normal no pode ser o recebedor Se finalidade do CT-e= 2 (Anulao): deve existir o grupo de CT-e de Anulao Se finalidade do CT-e= 2 (Anulao): o tipo de emisso dever ser normal existir Se finalidade do CT-e= 2 (Anulao): o CT-e objeto da anulao deve estar com a situao autorizado o uso. 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. Se finalidade do CT-e= 2 (Anulao): o CT-e objeto de anulao deve ter finalidade = 0 (Normal) 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. 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. Se finalidade do CT-e= 2 (Anulao): o CT-e objeto da anulao no pode ter sido anulado anteriormente Se finalidade do CT-e= 2 (Anulao): o CT-e objeto da anulao no pode ter sido substitudo anteriormente Se finalidade do CT-e= 3 (Substituio): o tipo de emisso deve ser normal Se finalidade do CT-e= 3 (Substituio): deve existir o grupo de informaes do CT-e de substituio Se finalidade do CT-e= 3 (Substituio): o CT-e substitudo deve existir

G026 Se finalidade do CT-e= 2 (Anulao): o CT-e objeto da anulao deve G027 G028

G030 G031

Obrig. Obrig.

500 501

Rej. Rej.

G032 G033 G034 G035 G036 G037

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

502 566 567 503 505 568 569 570 571 510

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

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) G041 Se finalidade do CT-e=3 (Substituio): CNPJ do emitente do CT-e

Pg. 34 / 136


Validao do CT-e Regras de Negcio # Regras de Validao substituto deve ser igual ao informado no CT-e substitudoG042 Se finalidade do CT-e=3 (Substituio): CNPJ do remetente do CT-e G043 G044 G045 G046 G047 G048 G049 G050 G051 G052 G053 G054 G055

Aplic. Obrig. Obrig. Obrig. Obrig. Obrig. Obrig. Obrig. Obrig. Obrig. Obrig. Obrig. Obrig. Obrig. Obrig.

Msg 511 512 550 551 552 553 554 555 556 557 558 559 560 563

Efeito Rej. Rej. Rej. Rej. Rej. Rej. Rej. Rej. Rej. Rej. Rej. Rej. Rej. Rej.

G056

G057

G058

substituto deve ser igual ao informado no CT-e substitudo Se finalidade do CT-e=3 (Substituio): CNPJ do destinatrio do CT-e substituto deve ser igual ao informado no CT-e substitudo Se finalidade do CT-e=3 (Substituio): CNPJ do expedidor do CT-e substituto deve ser igual ao informado no CT-e substitudo Se finalidade do CT-e=3 (Substituio): CNPJ do recebedor do CT-e substituto deve ser igual ao informado no CT-e substitudo Se finalidade do CT-e=3 (Substituio): CNPJ do tomador do CT-e substituto deve ser igual ao informado no CT-e substitudo Se finalidade do CT-e=3 (Substituio): IE do emitente do CT-e substituto deve ser igual ao informado no CT-e substitudo Se finalidade do CT-e=3 (Substituio): IE do remetente do CT-e substituto deve ser igual ao informado no CT-e substitudo Se finalidade do CT-e=3 (Substituio): IE do destinatrio do CT-e substituto deve ser igual ao informado no CT-e substitudo Se finalidade do CT-e=3 (Substituio): IE do recebedor do CT-e substituto deve ser igual ao informado no CT-e substitudo Se finalidade do CT-e=3 (Substituio): IE do expedidor do CT-e substituto deve ser igual ao informado no CT-e substitudo Se finalidade do CT-e=3 (Substituio): IE do tomador do CT-e substituto deve ser igual ao informado no CT-e substitudo 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 Se finalidade do CT-e=3 (Substituio): UF de fim da prestao do CT-e substituto deve ser igual ao informado no CT-e substitudo 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 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 Se finalidade do CT-e=3 (Substituio): se foi informado o CT-e de anulao no grupo do Tomador no contribuinte do ICMS, este CT-e informado deve ter finalidade=2(Anulao) CNPJ Emitente invlido (dgito controle, zeros ou nulo)

Obrig

572

Rej

Obrig

573

Rej

Obrig. Obrig. Obrig.

207 229 209

Rej. Rej. Rej.

G059 IE Emitente no informada (zeros ou nulo) G060 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.

G061 Acessar Cadastro Contribuinte p/ Emitente: - CNPJ emitente no cadastrado G062 - Emitente no credenciado G063 - IE Emitente no cadastrada G064 - IE Emitente no vinculada ao CNPJ G065 - Emitente em situao irregular perante o Fisco (tratar duplicidade na

Facult. Obrig. Facult. Obrig. Obrig.

245 203 230 231 301

Rej. Rej. Rej. Rej. Den.

Pg. 35 / 136


Validao do CT-e Regras de Negcio # Regras de Validao insero do CT-e, evitando a insero de mais de um CT-e denegado) G066 Data de Emisso posterior a data de recebimento (a SEFAZ Virutal deve considerar a hora local do emissor para a validao) G067 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) G068 CNPJ Remetente informado: CNPJ invlido (dgito de controle, zeros) G069 CPF Remetente informado: CPF invlido (dgito de controle, zeros) Obrig. Aplic. Msg ou 205 212 Efeito

Rej.

Obrig.

228

Rej.

Obrig. Obrig.

415 416 417

Rej. Rej. Rej.

G070 Remetente informado: Cdigo Municpio invlido (dgito de controle), vide Facult. item 2.1 do Anexo III. 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) G072 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.

418

Rej

Obrig.

419

Rej..

G073 Se o Remetente informado for contribuinte do ICMS na UF autorizadora: - Acessar Cadastro Contribuinte p/ Remetente: . Se CNPJ Remetente informado: CNPJ no cadastrado G074 G075 G076 . IE Remetente informada: IE no cadastrada . IE e CNPJ Remetente informados: IE no vinculada ao CNPJ

Facult.

420

Rej.

Facult. Facult. Facult.

421 422 302 ou 205 208 237 423

Rej. Rej. Den.

. 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) G077 CNPJ Destinatrio informado: CNPJ invlido (dgito de controle, zeros) G078 CPF Destinatrio informado: CPF invlido (dgito de controle, zeros) G079 Destinatrio informado: Cdigo Municpio invlido (dgito de controle), vide item 2.1 do Anexo III. G080 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) G081 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.


Rej. Rej. Rej.

Obrig.

424

Rej.

Obrig.

210

Rej.

G082 Se o Destinatrio informado for contribuinte do ICMS na UF autorizadora: Facult. - Acessar Cadastro Contribuinte p/ Destinatrio: . Se CNPJ Destinatrio informado: CNPJ no cadastrado G083 G084 . IE Destinatrio informada: IE no cadastrada . IE e CNPJ Destinatrio informados: IE no vinculada ao CNPJ Facult. Facult.

425

Rej.

426 427

Rej. Rej.

Pg. 36 / 136


Validao do CT-e Regras de Negcio # G085 Regras de Validao Aplic. Msg 303 ou 205 428 429 430 431 Efeito Den. . CNPJ ou IE Destinatrio informado: Destinatrio em situao irregular Facult. perante o Fisco (tratar duplicidade na insero do CT-e, evitando a insero de mais de um CT-e denegado) G086 CNPJ Expedidor informado: CNPJ invlido (dgito de controle, zeros) Obrig. G087 CPF Expedidor informado: CPF invlido (dgito de controle, zeros) G088 Expedidor informado: Cdigo Municpio invlido (dgito de controle), vide item 2.1 do Anexo III. G089 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) G090 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.

Rej. Rej. Rej. Rej.

Obrig. Facult. Obrig.

Obrig.

432

Rej.

G091 Se o Expedidor for contribuinte do ICMS na UF autorizadora: - Acessar Cadastro Contribuinte p/ Expedidor: . Se CNPJ Expedidor informado: CNPJ no cadastrado G092 G093 G094 . IE Expedidor informada: IE no cadastrada . IE e CNPJ Expedidor informados: IE no vinculada ao CNPJ

Facult.

433

Rej.


434 435 304 ou 205 436 437 438

Rej. Rej. Den.

. 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) G095 CNPJ Recebedor informado: CNPJ invlido (dgito de controle, zeros) G096 CPF Recebedor informado: CPF invlido (dgito de controle, zeros) G097 Recebedor informado: Cdigo Municpio invlido (dgito de controle), vide item 2.1 do Anexo III. G098 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) G099 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.


Rej. Rej. Rej.

Obrig.

439

Rej.

Obrig.

440

Rej.

G100 Se Recebedor informado for contribuinte do ICMS na UF autorizadora: - Acessar Cadastro Contribuinte p/ Recebedor: . Se CNPJ Recebedor informado: CNPJ no cadastrado G101 G102 G103 . IE Recebedor informada: IE no cadastrada . IE e CNPJ Recebedor informados: IE no vinculada ao CNPJ

Facult.

441

Rej.


442 443 305 ou 205 444 445

Rej. Rej. Den.

. 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) G104 CNPJ Tomador informado: CNPJ invlido (dgito de controle, zeros) G105 CPF Tomador informado: CPF invlido (dgito de controle, zeros)

Obrig. Obrig.

Rej. Rej.

Pg. 37 / 136


Validao do CT-e Regras de Negcio # Regras de Validao Aplic. Facult. Msg 446 Efeito Rej. G106 Tomador informado: Cdigo Municpio invlido (dgito de controle), vide item 2.1 do Anexo III. G107 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) G108 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.

447

Rej.

Obrig.

448

Rej.

G109 Se o Tomador do servio for contribuinte do ICMS na UF autorizadora: - Acessar Cadastro Contribuinte p/ Tomador: . Se CNPJ Tomador informado: CNPJ no cadastrado G110 G111 G112 . IE Tomador informada: IE no cadastrada . IE e CNPJ Tomador informados: IE no vinculada ao CNPJ . 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.

449

Rej.


489 490 306 ou 205 235 251

Rej. Rej. Den.

G113 Inscr. SUFRAMA do Destinatrio informada: verificar dgito controle G114 Inscr. SUFRAMA informada: verificar UF destinatrio = AC-Acre, ou AMAmazonas, ou RO-Rondnia, ou RR-Roraima, ou AP-Amap (s para municpios 1600303-Maca

Documents

Manual CTe v103