Manual de Orientação ao Contribuinte do Conhecimento de Transporte Eletrônico

Conceitos, arquitetura, padrões técnicos e visão operacional do CT-e.

2. Documentos Consolidados

3. Conceitos

4. Conceitos Complementares

4.1. CT-e (Modelo 57) e CT-e Outros Serviços (Modelo 67)

O Conhecimento de Transporte Eletrônico (CTe) é um documento de existência exclusivamente digital, emitido e armazenado eletronicamente com o intuito de documentar prestações de serviço de transporte, com validade jurídica garantida pela assinatura digital do emitente e pela Autorização de Uso fornecida pela administração tributária do domicílio do contribuinte.

O Conhecimento de Transporte Eletrônico (Modelo 57) é um documento fiscal eletrônico, instituído pelo AJUSTE SINIEF 09/07 (25/10/2007), que poderá ser utilizado para substituir um dos seguintes documentos fiscais:

• Conhecimento de Transporte Rodoviário de Cargas, modelo 8;
• Conhecimento de Transporte Aquaviário de Cargas, modelo 9;
• Conhecimento Aéreo, modelo 10;
• Conhecimento de Transporte Ferroviário de Cargas, modelo 11;
• Nota Fiscal de Serviço de Transporte Ferroviário de Cargas, modelo 27;
• Nota Fiscal de Serviço de Transporte, modelo 7, quando utilizada em transporte de cargas.

O Conhecimento de Transporte Eletrônico também poderá ser utilizado como documento fiscal eletrônico no transporte dutoviário e nos transportes Multimodais.

O Conhecimento de Transporte para outros serviços (modelo 67), substitui a Nota Fiscal de Serviço de Transporte modelo 7 no que se refere aos serviços que não envolvem o transporte de cargas, a saber:

• Transporte de Pessoas;
• Transporte de Valores;
• Excesso de Bagagem.

4.2. GTV-e (Modelo 64)

A Guia de Transporte de Valores Eletrônica (GTVe) é um documento de existência exclusivamente digital, emitido e armazenado eletronicamente com o intuito de documentar prestações de serviço de transporte de valores, cuja validade jurídica é garantida pela assinatura digital do emitente e pela autorização de uso fornecida pela administração tributária do domicílio do contribuinte.

A GTVe (modelo 64) substitui a Guia de Transporte de Valores e o Extrato de Faturamento das empresas prestadoras de serviço de transporte de valores.

4.3. DACTE

O DACTE (Documento Auxiliar do Conhecimento de Transporte Eletrônico) é um documento auxiliar impresso em papel e sua especificação/modelos de leiaute encontram-se disponíveis no documento Anexo II: Manual de Orientações do Contribuinte – DACTE.

4.4. Chave de Acesso do CT-e

A Chave de Acesso do CT-e é composta pelos campos abaixo, que se encontram dispersos no leiaute do CT-e (vide Anexo I):

• cUF - Código da UF do emitente do Documento Fiscal
• AAMM - Ano e Mês de emissão do CTe
• CNPJ- CNPJ do emitente
• mod - Modelo do Documento Fiscal
• serie - Série do Documento Fiscal
• nCT - Número do Documento Fiscal
• tpEmis - forma de emissão do CTe
• cCT - Código Numérico que compõe a Chave de Acesso
• cDV - Dígito Verificador da Chave de Acesso

O Dígito Verificador (DV) irá garantir a integridade da chave de acesso, protegendo-a principalmente contra digitações erradas.

4.5. Chave Natural do CT-e

A Chave Natural do CTe é composta pelos campos de UF, CNPJ/CPF do Emitente, Série e Número do CTe, além do modelo do documento fiscal eletrônico e sua forma de emissão. O Sistema de Autorização de Uso das SEFAZ valida a existência de um CTe previamente autorizado e rejeita novos pedidos de autorização para CTe com duplicidade da Chave Natural.

4.6. Regime Especial da Nota Fiscal Fácil (NFF)

O objetivo do Regime Especial Nota Fiscal Fácil (NFF) é tornar o processo de emissão de documentos fiscais eletrônicos, de vendas de mercadorias e prestação de serviços de transportes, mais simples para os contribuintes, deixando a complexidade trazida pela legislação fiscal sob a responsabilidade de um sistema centralizado, disponível no Portal Nacional da NFF, que a partir de sua “inteligência fiscal” possibilita uma emissão fácil e completamente intuitiva do documento.

Para atingir este ambicioso objetivo, as Secretarias de Fazenda dos Estados estão disponibilizando um aplicativo de geração da solicitação de emissão de documentos fiscais, denominado Aplicativo Emissor de Documentos Fiscais Eletrônicos (App NFF), cuja principal funcionalidade é coletar as informações necessárias e suficientes para esta finalidade. Uma das premissas do projeto NFF é a não rejeição de documentos fiscais originadas no aplicativo emissor, como a geração do XML do CTe será em ambiente controlado e ainda, transmitida e assinada pelo certificado digital da SEFAZ Virtual RS, existem garantias suficientes para os controles da emissão do CTe e sua respectiva autorização. A chave de acesso de um CTe gerado pelo aplicativo emissor NFF possui as seguintes características:

• cUF - Código da UF do carregamento do DF-e
• AAMM - Ano e Mês de emissão do CTe
• CPF- CPF do emitente TAC preenchido com zeros a esquerda.
• mod - Modelo do Documento Fiscal (57)
• serie - Série do Documento Fiscal o Gerado e controlado por dispositivo
• 1 dígito para identificar o Nro. Do dispositivo
• 2 dígitos para identificar o ano
• nCT - Número do Documento Fiscal o Gerado e controlado sequencialmente por dispositivo:
• 2 dígitos do mês da emissão
• 2 dígitos do dia da emissão
• 5 dígitos sequenciais para o número com reinício diário por dispositivo
• tpEmis - forma de emissão do DF-e o 3 – Emissão pelo regime especial da NFF
• cCT - Código Numérico que compõe a Chave de Acesso o Randômico de 8 dígitos
• cDV - Dígito Verificador da Chave de Acesso

4.7. Provedor de Assinatura e Autorização

O contribuinte emitente de Documento Fiscal Eletrônico, pessoa física ou Microempreendedor Individual - MEI, poderá utilizar os serviços de um Provedor de Assinatura e Autorização de Documentos Fiscais Eletrônicos - PAA, com a finalidade de realizar comunicações com os sistemas de autorização de uso de documentos fiscais eletrônicos providos pelas administrações tributárias, em nome do contribuinte.

O ambiente de autorização das Administrações Tributárias através do Portal Nacional dos Documentos Fiscais Eletrônicos irá permitir a vinculação entre contribuintes que se enquadrarem nesse perfil (devidamente identificados na plataforma gov.br do governo federal) com Provedores de Assinatura e Autorização previamente homologados pela Coordenação do ENCAT.

O contribuinte deverá utilizar ferramenta de emissão de documento fiscal fornecida pelo PAA, preferencialmente na internet e com identificação do usuário.

O PAA receberá o pedido de emissão no formato que seu software estiver construído e providenciará a geração do XML do documento fiscal eletrônico identificado com o preenchimento do grupo infPAA assinando o atributo Id do DFe com a chave criptográfica no padrão RSA fornecida pela administração tributária, além da assinatura digital do DFe com certificado ICP-Brasil do PAA.

O PAA deverá transmitir o XML do DFe para o ambiente de autorização onde será submetido a todas as regras de validação estabelecidas no MOC. O documento poderá ser autorizado ou rejeitado, devendo o PAA guardar o protocolo de autorização e atuar nos casos em que houver rejeição.

4.8. Assinatura RSA e Geração do DFe pelo PAA

A empresa usuária do serviço de Provedor de Assinatura e Autorização deverá solicitar o vínculo a um Provedor homologado no portal da SEFAZ Virtual RS, o resultado dessa solicitação entregará um par de chaves RSA (chave pública e chave privada) para o emitente.

Com a chave privada, a aplicação do PAA deverá assinar o conteúdo do atributo Id do CTe / Evento (convertido para array de bytes) com padrão de assinatura assimétrica RSA SHA1 originando um SignatureValue no formato base64.

A chave pública deverá ser informada no grupo RSAKeyValue no padrão XML Signature para chaves RSA.

Passos a executar:

1. Solicitar o vínculo com o Provedor de Assinatura e Autorização no portal DFe da SVRS com CPF do responsável pelo MEI autenticado na plataforma gov.br
2. Obter no portal o par de chaves RSA (chave privada e chave pública)
3. No software do PAA: utilizar a chave privada para assinar o conteúdo da tag Id do DFe (RSA SHA1 base64)
4. Informar a chave pública no padrão XML Signature no grupo RSAKeyValue
5. O PAA deverá assinar o DFe com certificado X509 padrão ICP-Brasil
6. PAA deverá transmitir o DFe para o serviço de autorização da SVRS A qualquer tempo o Emitente poderá solicitar o término do vínculo e utilização do PAA acessando o portal da SVRS. A administração tributária e o PAA também poderão comandar o encerramento do vínculo.

4.9. Estrutura das Informações do PAA no XML do DFe

5. Arquitetura de Comunicação

O fluxo de comunicação é sempre iniciado pelo aplicativo do contribuinte. Para cada solicitação, o Web Service devolve a resposta na mesma conexão, segundo o modelo síncrono definido pelo MOC 4.00.

6. Padrões Técnicos

6.1. Padrão de Documento XML

a) Padrão de Codificação

A especificação do documento XML adotada é a recomendação W3C para XML 1.0, disponível em www.w3.org/TR/REC-xml e a codificação dos caracteres será em UTF-8, assim todos os documentos XML serão iniciados com a seguinte declaração: <?xml version="1.0" encoding="UTF-8"?>

OBS: Lembrando que cada arquivo XML somente poderá ter uma única declaração <?xml version="1.0" encoding="UTF-8"?>.

b) Declaração namespace

O documento XML deverá ter uma única declaração de namespace no elemento raiz do documento com o seguinte padrão: <CTe xmlns=”http://www.portalfiscal.inf.br/cte” > (exemplo para o XML do CTe)

O uso de declaração namespace diferente do padrão estabelecido para o Projeto é vedado.

A declaração do namespace da assinatura digital deverá ser realizada na própria tag <Signature>, conforme exemplo abaixo.

<?xml version="1.0" encoding="UTF-8"?> <CTe xmlns="http://www.portalfiscal.inf.br/cte"> <infCte Id="CTe41100600242640000108570000000446060832911308" versao="4.00"> ... <Signature xmlns="http://www.w3.org/2000/09/xmldsig#"> … </CTe>

c) Prefixo de namespace Não é permitida a utilização de prefixos de namespace. Essa restrição visa otimizar o tamanho do arquivo XML. Assim, ao invés da declaração: <cte:CTe xmlns:cte=”http://www.portalfiscal.inf.br/cte”> (exemplo para o XML do CTe com

prefixo cte) deverá ser adotada a declaração: <CTe xmlns =”http://www.portalfiscal.inf.br/cte” > d) Otimização na montagem do arquivo

Na geração do arquivo XML do CTe, excetuados os campos identificados como obrigatórios no modelo (primeiro dígito da coluna de ocorrências do leiaute iniciada com 1, ex.: 1-1, 1-2, 1-N), não deverão ser incluídas as TAGs de campos com conteúdo zero (para campos tipo numérico) ou vazio (para campos tipo caractere).

Na geração do arquivo XML do CTe, deverão ser preenchidos no modelo apenas as TAGs de campos identificados como obrigatórios no leiaute ou os campos obrigatórios por força da legislação pertinente. Os campos obrigatórios no leiaute são identificados pelo primeiro dígito da coluna ocorrência (“Ocorr”) que inicie com 1, ex.: 1-1, 1-2, 1-N. Os campos obrigatórios por força da legislação pertinente devem ser informados, mesmo que no leiaute seu preenchimento seja facultativo.

A regra constante do parágrafo anterior deverá estender-se para os campos onde não há indicação de obrigatoriedade e que, no entanto, seu preenchimento torna-se obrigatório por estar condicionado à legislação específica ou ao negócio do contribuinte. Neste caso, deverá constar a TAG com o valor correspondente e, para os demais campos, deverão ser eliminadas as TAGs.

Para reduzir o tamanho final do arquivo XML do CTe alguns cuidados de programação deverão ser assumidos:

• Não incluir "zeros não significativos" para campos numéricos;
• Não incluir "espaços" ("line-feed", "carriage return", "tab", caractere de "espaço" entre as TAGs) no início ou no final de campos numéricos e alfanuméricos;
• Não incluir comentários no arquivo XML;
• Não incluir anotação e documentação no arquivo XML (TAG annotation e TAG documentation);
• Não incluir caracteres de formatação no arquivo XML ("line-feed", "carriage return", "tab", caractere de "espaço" entre as TAGs). e) Validação de Schema

Para garantir minimamente a integridade das informações prestadas e a correta formação dos arquivos XML, o contribuinte deverá submeter o arquivo do CTe e as demais mensagens XML para validação pelo Schema (XSD – XML Schema Definition), disponibilizado pelo Ambiente Autorizador, antes de seu envio.

6.2. Padrão de Comunicação

A comunicação entre o contribuinte e a Secretaria de Fazenda Estadual será baseada em Web Services disponíveis no Portal da Secretaria de Fazenda Estadual de circunscrição do contribuinte, exceto nos casos em que a UF autorizadora do CTe utilize serviços de SEFAZ VIRTUAL.

O meio físico de comunicação utilizado será a Internet, com o uso do protocolo TLS versão 1.2, com autenticação mútua, que além de garantir um duto de comunicação seguro na Internet, permite a identificação do servidor e do cliente através de certificados digitais, eliminando a necessidade de identificação do usuário através de nome ou código de usuário e senha.

O modelo de comunicação segue o padrão de Web Services definido pelo WS-I Basic Profile.

A troca de mensagens entre os Web Services do Ambiente Autorizador e o aplicativo do contribuinte será realizada no padrão SOAP versão 1.2, com troca de mensagens XML no padrão Style/Encoding: Document/Literal.

A chamada dos diferentes Web Services do Projeto CTe é realizada com o envio de uma mensagem através do campo cteDadosMsg. A versão do leiaute da mensagem XML e o código da UF serão obtidos nos dados informados no leiaute da mensagem.

6.3. Padrão de Certificado Digital

O certificado digital utilizado no Projeto do CTe será emitido por Autoridade Certificadora credenciada pela Infraestrutura de Chaves Públicas Brasileira – ICP-Brasil, tipo A1 ou A3, devendo conter o CNPJ da pessoa jurídica titular do certificado digital.

Os certificados digitais serão exigidos em 3 (três) momentos distintos para o projeto: a) Assinatura de Mensagens: O certificado digital utilizado para essa função deverá conter: a. O CNPJ de um dos estabelecimentos da empresa emissora do CTe; b. O CNPJ da SVRS para emitente TAC (regime especial da NFF).

Por mensagens, entenda-se: o Pedido de Autorização de Uso (Arquivo CTe/CTeOS/GTVe), o Registro de Eventos e demais arquivos XML que necessitem de assinatura. O certificado digital deverá ter o “uso da chave” previsto para a função de assinatura digital e atributo de “não recusa” obrigatoriamente com o CNPJ no campo otherName OID = 2.16.76.1.3.3, respeitando a Política do Certificado.

b) Transmissão (durante a transmissão das mensagens entre o servidor do contribuinte e o Ambiente Autorizador): O certificado digital utilizado para identificação do aplicativo do contribuinte deverá conter o CNPJ do responsável pela transmissão das mensagens, que não necessita ser o mesmo do emissor do CTe, devendo ter a extensão Extended Key Usage com permissão de "Autenticação Cliente".

c) Geração do QR Code do CTe: O certificado digital utilizado para a assinatura do CTe deverá ser utilizado para assinar a chave de acesso do CTe na geração do QR Code na hipótese de emissão em contingência, conforme será descrito em item futuro deste manual.

6.4. Padrão da Assinatura Digital

As mensagens enviadas ao Ambiente Autorizador são documentos eletrônicos elaborados no padrão XML e devem ser assinados digitalmente com um certificado digital que contenha o CNPJ do estabelecimento (matriz ou filial) emissor do CTe objeto do pedido.

Os elementos abaixo estão presentes dentro do Certificado do contribuinte tornando desnecessária a sua representação individualizada no arquivo XML. Portanto, o arquivo XML não deve conter os elementos: <X509SubjectName> <X509IssuerSerial> <X509IssuerName> <X509SerialNumber> <X509SKI>

Deve-se evitar o uso das TAGs relacionadas a seguir, pois as informações serão obtidas a partir do Certificado do emitente: <KeyValue> <RSAKeyValue> <Modulus> <Exponent>

O Projeto CTe utiliza um subconjunto do padrão de assinatura XML definido pelo http://www.w3.org/TR/xmldsig-core/, que tem o seguinte leiaute:

A assinatura do Contribuinte no CTe será feita na TAG <infCte> identificada pelo atributo Id, cujo conteúdo deverá ser um identificador único (chave de acesso) precedido do literal ‘CTe’ para o CTe, conforme leiaute descrito no Anexo I. O identificador único precedido do literal ‘#CTe’ deverá ser informado no atributo URI da TAG <Reference>. Para as demais mensagens a serem assinadas, o processo será o mesmo mantendo sempre um identificador único para o atributo Id na TAG a ser assinada. Para o processo de assinatura, o contribuinte não deve fornecer a Lista de Certificados Revogados, já que ela será montada e validada no Ambiente Autorizador no momento da conferência da assinatura digital.

A assinatura digital do documento eletrônico deverá atender aos seguintes padrões adotados:

• Padrão de assinatura: “XML Digital Signature”, utilizando o formato “Enveloped” (http://www.w3.org/TR/xmldsig-core/);
• Certificado digital: Emitido por AC credenciada no ICP-Brasil (http://www.w3.org/2000/09/xmldsig#X509Data);
• Cadeia de Certificação: EndCertOnly (Incluir na assinatura apenas o certificado do usuário final);
• Tipo do certificado: A1 ou A3 (o uso de HSM é recomendado);
• Tamanho da Chave Criptográfica: Compatível com os certificados A1 e A3 (1024 bits);
• Função criptográfica assimétrica: RSA (http://www.w3.org/2000/09/xmldsig#rsa-sha1);
• Função de “message digest”: SHA-1 (http://www.w3.org/2000/09/xmldsig#sha1);
• Codificação: Base64 (http://www.w3.org/2000/09/xmldsig#base64);
• Transformações exigidas: Útil para realizar a canonicalização do XML enviado para realizar a validação correta da Assinatura Digital. São elas: (1) Enveloped (http://www.w3.org/2000/09/xmldsig#enveloped-signature) (2) C14N (http://www.w3.org/TR/2001/REC-xml-c14n-20010315)

6.5. Validação da Assinatura Digital pelo Ambiente Autorizador

Para a validação da assinatura digital, seguem as regras que serão adotadas pelo Ambiente Autorizador:

1. Extrair a chave pública do certificado.
2. Verificar o prazo de validade do certificado utilizado.
3. Montar e validar a cadeia de confiança dos certificados validando também 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 (não serão aceitos certificados do tipo S).
5. Garantir que o certificado utilizado é de um usuário final e não de uma Autoridade Certificadora.
6. Adotar as regras definidas pelo RFC 3280 para LCRs e cadeia de confiança.
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 conferência da LCR pode ser feita de 2 (duas) maneiras: On-line ou Download periódico. As assinaturas digitais das mensagens serão verificadas considerando a lista de certificados revogados disponível no momento da conferência da assinatura.

6.6. Resumo dos Padrões Técnicos

7. Modelo Operacional

8. Sistema de Registro de Eventos

9. Padrão de Mensagens dos Web Services

9.1. Informações de Controle e Área de Dados das Mensagens

A informação armazenada na área de dados <Body> é um documento que deve atender o leiaute definido na documentação do Web Service acessado: Para o serviço de recepção de CTe (modelo 57), CTe OS (modelo 67) e GTVe (modelo 64), a mensagem deverá ser compactada no padrão GZip, onde o resultado da compactação é convertido para Base64, reduzindo o tamanho da mensagem em aproximadamente 70%, conforme abaixo:

<soap12:Body> <cteDadosMsg xmlns="http://www.portalfiscal.inf.br/cte/wsdl/CTeRecepcaoSinc">string</cteDadosMsg> </soap12:Body>

Para os demais serviços a mensagem deverá utilizar XML sem compactação.

9.2. Validação da Estrutura XML das Mensagens dos Web Services

As informações são enviadas ou recebidas dos Web Services através de mensagens no padrão XML definido na documentação de cada Web Service.

As alterações de leiaute e da estrutura de dados XML realizadas nas mensagens são controladas através da atribuição de um número de versão para a mensagem.

Um Schema XML é uma linguagem que define o conteúdo do documento XML, descrevendo os seus elementos e a sua organização, além de estabelecer regras de preenchimento de conteúdo e de obrigatoriedade de cada elemento ou grupo de informação.

A validação da estrutura XML da mensagem é realizada por um analisador sintático (parser) que verifica se a mensagem atende as definições e regras de seu Schema XML.

Qualquer divergência da estrutura XML da mensagem em relação ao seu Schema XML provoca um erro de validação do Schema XML.

A primeira condição 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 versão do leiaute da estrutura XML da mensagem na TAG correspondente em cada mensagem.

9.3. Schemas XML das Mensagens dos Web Services

Toda mudança de leiaute das mensagens dos Web Services implica na atualização do seu respectivo Schema XML. A identificação da versão dos Schemas será realizada com o acréscimo do número da versão no nome do arquivo precedida da literal ‘_v’, como segue:

cte_v4.00.xsd (Schema XML do CTe, versão 4.00); tiposGeral_v4.00.xsd (Schema XML dos tipos do CTe, versão 4.00). A maioria dos Schemas XML do CTe utilizam as definições de tipos básicos ou tipos complexos que estão definidos em outros Schemas XML (ex.: tiposGeralCTe_v4.00.xsd, etc.), nestes casos, a modificação de versão do Schema básico será repercutida no Schema principal.

Por exemplo, o tipo numérico de 15 posições com 2 decimais é definido no Schema tiposGeralCT_v4.00.xsd, caso ocorra alguma modificação na definição deste tipo, todos os Schemas que utilizam este tipo básico devem ter a sua versão atualizada e as declarações “import” ou “include” devem ser atualizadas com o nome do Schema básico atualizado.

As modificações de leiaute das mensagens dos Web Services podem ser causadas por necessidades técnicas ou em razão da modificação de alguma legislação. As modificações decorrentes de alteração da legislação deverão ser implementadas nos prazos previstos na norma que introduziu a alteração. As modificações de ordem técnica serão divulgadas pela Coordenação Técnica do ENCAT e poderão ocorrer sempre que se fizerem necessárias.

10. Versão dos Schemas XML

10.1. Liberação das Versões dos Schemas para o CT-e

Os schemas válidos para o CTe serão disponibilizados no sítio nacional do Projeto (www.cte.fazenda.gov.br) ou no portal da SVRS (dfe-portal.svrs.rs.gov.br/cte), e serão liberados após autorização da equipe de Gestão do Projeto formada pelos Líderes dos Projetos nos Estados e representante das Empresas.

A cada nova liberação de schema será disponibilizado um arquivo compactado contendo o conjunto de schemas a serem utilizados pelos contribuintes para a geração dos arquivos XML. Este arquivo será denominado “Pacote de Liberação” e terá a mesma numeração da versão do Manual de Orientações que lhe é compatível. Os pacotes de liberação serão identificados pelas letras “PL_CTe”, seguida do número da versão do Manual de Orientações correspondente. Exemplificando: O pacote PL_CTe_4.00.zip representa o “Pacote de Liberação” de schemas do CTe compatíveis com o Manual de Orientações do Contribuinte – versão 4.00.

Os schemas XML das mensagens XML são identificados pelo seu nome, seguido da versão do respectivo schema.

Assim, para o schema XML de “cte”, corresponderá um arquivo com a extensão “.xsd”, que terá o nome de “cte_v9.99.xsd”, onde v9.99, corresponde a versão do respectivo schema. Para identificar quais os schemas que sofreram alteração em um determinado pacote liberado, deve-se comparar o número da versão do schema deste pacote com o do pacote anterior.

10.2. Correção de Pacote de Liberação

Em alguma situação pode surgir a necessidade de correção de um Schema XML por um erro de implementação de regra de validação, obrigatoriedade de campo, nome de tag divergente do definido no leiaute da mensagem, que não modifica a estrutura do Schema XML e nem exige a alteração dos aplicativos da SEFAZ ou dos contribuintes.

Nesta situação, divulgaremos um novo pacote de liberação com o Schema XML corrigido, sem modificar o número da versão do PL para manter a compatibilidade com o Manual de Orientações do Contribuinte vigente.

A identificação dos pacotes mais recentes se dará com o acréscimo de letras minúscula do alfabeto, como por exemplo: CTe_PL_4.00a.ZIP, indicando que se trata da primeira versão corrigida do CTe_PL_4.00.ZIP.

10.3. Divulgação de Novos Pacotes de Liberação

A divulgação de novos pacotes de liberação ou atualizações de pacote de liberação será realizada através da publicação de Notas Técnicas no Portal Nacional do CTe com as informações necessárias para a implementação dos novos pacotes de liberação.

10.4. Controle de Versão

O controle de versão de cada um dos schemas válidos do CTe compreende uma definição nacional: Qual a versão vigente (versão mais atualizada)? Quais são as versões anteriores ainda suportadas por todas as SEFAZ? Quais são as versões da parte específica de cada modal suportadas pela parte genérica?

Este controle de versão permite a adaptação dos sistemas de informática dos contribuintes participantes do Projeto em diferentes datas. Ou seja, alguns contribuintes poderão estar com uma versão de leiaute mais atualizada, enquanto outros poderão ainda estar operando com mensagens em um leiaute anterior.

Não estão previstas mudanças frequentes de leiaute de mensagens e os contribuintes deverão ter um prazo razoável para implementar as mudanças necessárias, conforme acordo operacional a ser estabelecido. Mensagens recebidas com uma versão de leiaute não suportada serão rejeitadas com uma mensagem de erro específica na versão do leiaute de resposta mais recente em uso.

11. Schema XML: Estrutura Genérica e Estrutura Específica do Modal

A estrutura do Schema XML do CTe foi criada como sendo composta de uma parte genérica do schema e uma parte específica para cada modal, com o objetivo de criar uma maior independência entre os modais, onde uma alteração no leiaute específico para um modal não repercuta nos demais.

11.1. Parte Genérica

A estrutura genérica é a parte que possui os campos (tags) de uso comum a serem utilizados por todos os modais.

Para alcançar este objetivo foi criada no schema XML do CTe uma estrutura genérica com um elemento do tipo any que permite a inserção do XML específico do modal, conforme demonstrado na figura a seguir:

A versão do schema XML a ser utilizada na parte específica do modal será identificada com um atributo de versão próprio (tag versaoModal), conforme figura a seguir:

11.2. Parte Específica para Cada Modal

A estrutura específica é a parte que possui os campos (tags) exclusivos do modal.

A parte específica do schema XML para cada modal será distribuída no mesmo pacote de liberação em arquivo separado para cada um deles.

A identificação do modal se dará no nome do arquivo, como segue:

cteModalXXXXXXXXXXXX_v9.99.xsd Onde XXXXXXXXXXXX é a identificação do modal, e v9.99 é a identificação da versão. Segue exemplo de nomes de arquivos de schema XML da parte específica de cada modal:

• cteModalRodoviario_v4.00.xsd (modal rodoviário, versão 4.00);
• cteModalAereo_v4.00.xsd (modal aéreo, versão 4.00);
• cteModalFerroviario_v4.00.xsd (modal ferroviário, versão 4.00);
• cteModalAquaviario_v4.00.xsd (modal aquaviário, versão 4.00);
• cteModalDutoviario_v4.00.xsd (modal dutoviário, versão 4.00);
• cteMultiModal_v4.00.xsd (multimodal, versão 4.00).

11.3. Parte Genérica e Parte Específica: Versões

Uma versão da parte genérica deverá suportar mais de uma versão da parte específica de cada modal. Normalmente esta relação deve ser de uma para uma (1:1). Apenas em momentos de transição poderemos ter empresas de um modal utilizando uma versão mais atualizada, enquanto outras empresas poderão ainda estar operando com um leiaute anterior da parte específica.

O Ambiente autorizador deverá manter na sua aplicação o controle de versões da parte específica suportadas pela parte genérica.

12. Catálogo e Regras dos Eventos

O Sistema de Registro de Eventos do CTe – SRE é o modelo genérico que permite o registro de evento de interesse do CTe originado a partir do próprio contribuinte ou da administração tributária.

Um evento é o registro de um fato relacionado com o documento fiscal eletrônico, esse evento pode ou não modificar a situação do documento (por exemplo: cancelamento) ou até mesmo substituí-lo por outro (por exemplo: substituição).

O serviço para registro de eventos será disponibilizado pelo Ambiente Autorizador através de Web Service de processamento síncrono e será propagado para os demais órgãos interessados pelo mecanismo de compartilhamento de documentos fiscais eletrônicos. As mensagens de evento utilizarão o padrão XML já definido para o projeto CTe contendo a assinatura digital do emissor do evento (seja ele contribuinte ou fisco).

O registro do evento requer a existência do CTe vinculado no Ambiente Autorizador, contudo alguns tipos de eventos poderão ser registrados sem que exista o CTe na base de dados do autorizador em conformidade com as regras de negócio estabelecidas para este tipo de evento.

O modelo de mensagem do evento deverá ter um conjunto mínimo de informações comuns, a saber:

• Identificação do autor da mensagem;
• Identificação do evento;
• Identificação do CTe vinculado;
• Informações específicas do evento;
• Assinatura digital da mensagem. O Web Service será único com a funcionalidade de tratar eventos de forma genérica para facilitar a criação de novos eventos sem a necessidade de criação de novos serviços e com poucas alterações na aplicação de Registro de Eventos do Ambiente Autorizador.

O leiaute da mensagem de Registro de Evento seguirá o modelo adotado para o documento CTe, contendo uma parte genérica (comum a todos os tipos de evento) e uma parte específica onde será inserido o XML correspondente a cada tipo de evento em uma tag do tipo any.

As regras de validação referentes à parte genérica dos eventos estarão descritas no item 5 deste manual.

As validações específicas de cada tipo de evento estarão descritas no item 6 deste Manual, originando um novo subitem para cada tipo de evento especificado. O Pacote de Liberação de schemas do CTe deverá conter o leiaute da parte genérica do Registro de Eventos e um schema para cada leiaute específico dos eventos definidos neste manual.

12.1. Relação dos Tipos de Evento

Os eventos identificados abaixo serão construídos gradativamente pelo ambiente autorizador, assim como novos eventos poderão ser identificados e acrescentados nesta tabela em futuras versões deste MOC.

12.2. Eventos de Marcação

Serão gerados eventos de marcação a partir do CTe para os casos em que o documento referenciar outro, seja CTe ou NFe.

Eventos dessa natureza ocorrem por necessidade de marcação dos documentos relacionados na carga de um CTe, para evitar seu cancelamento e dar ciência às administrações tributárias da efetiva prestação do serviço de transporte.

Esses eventos serão gerados automaticamente pelo Fisco no momento da autorização dos documentos e assinados digitalmente com certificado digital do ambiente autorizador ou ambiente nacional do CTe. São exemplos de eventos de marcação:

• Evento CTe autorizado/cancelado nas NFe;
• Evento registro de passagem posto fiscal/automático nas NFe;
• Evento autorizado Redespacho em CTe relacionados;
• Evento autorizado CTe de Substituição.

13. Data e Hora de Emissão e Outros Horários

Todos os campos que representam Data e Hora no leiaute das mensagens do CTe seguem o formato UTC completo com a informação do TimeZone. Este tipo de representação de dados é tecnicamente adequado para a representação do horário para um País com dimensões continentais como o Brasil. Serão aceitos os horários de qualquer região do mundo (faixa de horário UTC de -11 a +12) e não apenas as faixas de horário do Brasil.

Exemplo: no formato UTC para os campos de Data-Hora, "TZD" pode ser -02:00 (Fernando de Noronha), -03:00 (Brasília) ou -04:00 (Manaus), no horário de verão serão -01:00, -02:00 e -03:00. Exemplo: "2010-08-19T13:00:15-03:00".

14. SEFAZ Virtual

A Secretaria de Fazenda Estadual pode optar por não desenvolver sistema próprio de autorização do Conhecimento de Transporte Eletrônico para os contribuintes de sua circunscrição. Neste sentido, os serviços de autorização de emissão do CTe serão supridos por uma SEFAZ VIRTUAL, mediante Protocolo de Cooperação assinado entre as SEFAZ e/ou entre a SEFAZ e a RFB.

Os serviços da SEFAZ VIRTUAL compreendem os Web Services descritos no Modelo Conceitual da Arquitetura de Comunicação conforme consta neste Manual de Orientações do Contribuinte.

O credenciamento de contribuintes bem como a autorização de uso dos serviços de uma determinada SEFAZ VIRTUAL é responsabilidade da SEFAZ de circunscrição daqueles contribuintes.

Para os sistemas das Empresas será totalmente transparente se os serviços provêm da SEFAZ VIRTUAL ou de um sistema de autorização da própria SEFAZ de circunscrição do contribuinte. A única mudança visível é o endereço dos Web Services em que estão disponíveis os serviços.

15. Web Services

Os Web Services utilizados pelos aplicativos dos contribuintes seguem estas premissas: