Manual_CTe_v2_0 CTE 2013 Manual V2 0

Manual_CTe_v2_0%20

User Manual: Pdf

Open the PDF directly: View PDF .
Page Count: 189 [warning: Documents this large are best viewed by clicking the View PDF Link!]

Conhecimento de Transporte Eletrônico

Manual de Orientações - Contribuinte

Pág. 1 / 189

Projeto Conhecimento de Transporte Eletrônico

Manual de Orientações do Contribuinte

Padrões Técnicos de Comunicação

Versão 2.00

Julho/2013

Conhecimento de Transporte

letrônico

Manual de Orientações – Contribuinte

Pág.

2 / 189

Controle de Versões

Versão

Data

1.00 07/03/2008 – SP

1.01 02/07/2008 – SP/RS

1.01A 07/07/2008 – SP/RS

1.01B 25/08/2008 – Reunião CT-e RJ

1.02pre 03/09/2008 – Reunião CT-e MT

1.02 12/09/2008 – SP/RS

1.03 03/08/2009 – RS/SP/GO

1.04 22/07/2011 – RS

1.04a

12/08/2011 – RS

1.04b 07/12/2011 – RS

1.04c 11/04/2012 – RS – Regras SVC

2.00pre 02/05/2012 – RS

2.00 04/07/2013 – RS

2.00 31/07/2013 – RS (Revisão)

Conhecimento de Transporte

letrônico

Manual de Orientações – Contribuinte

Pág.

3 / 189

Identificação e vigência do Manual

Versão do manual

2.00

Data de divulgação da versão inicial do manual

15/07/2013

Pacote de liberação de Schemas XML

PL_CTe_200

Data de início de vigência no ambiente de homologação

01/09/2013

Data de início de vigência no ambiente de produção

01/11/2013

Pacote de liberação de Schemas XML em vigência

PL_CTe_104c

Data final de vigência do PL_CTe_104c

01/06/2014

Versões de leiautes do PL_CTe_200

Leiaute

ersão

Schema XML Observação

CTe 2.00 cte_v2.00.xsd Leiaute do CT-e (parte Geral).

enviCTe 2.00

enviCte_v2.00.xsd Mensagem de envio de lote de CT-e.

retEnviCTe 2.00

retEnviCte_v2.00.xsd Mensagem de retorno do envio de lote de CT-e.

consReciCTe 2.00

consReciCte_v2.00.xsd Mensagem de consulta processamento do lote

de CT-e transmitido.

retconsReciCTe 2.00

retConsReciCte_v2.00.xsd Mensagem de retorno da consulta de

processamento do lote de CT-e transmitido.

procCTe 2.00

procCte_v2.00.xsd Leiaute de compartilhamento do CT-e.

inutCTe 2.00

inutCTe_v2.00.xsd Mensagem de solicitação de inutilização de

numeração de CT-e.

retInutCTe 2.00

retInutCTe_v2.00.xsd Mensagem de retorno do resultado do

processamento da solicitação de inutilização de

numeração de CT-e.

procInutCTe 2.00

procInutCTe_v2.00.xsd Leiaute de compartilhamento de pedido de

inutilização de numeração de CT-e

consSitCTe 2.00

consSitCte_v2.00.xsd Mensagem de consulta da situação atual da CT-

retConsSitCTe 2.00

retConsSitCte_v2.00.xsd Mensagem de retorno da consulta da situação

atual da CT-e.

consStatServ 2.00

consStatServCte_v2.00.xsd Mensagem da consulta do status do serviço de

autorização de CT-e.

retConsStatServ 2.00

retconsStatServ_v2.00.xsd Mensagem de retorno da consulta do status do

serviço de autorização de CT-e.

aereo 2.00

cteModalAereo_v2.00.xsd Leiaute do modal Aéreo (parte específica)

aquav 2.00

cteModalAquaviario_v2.00.xsd Leiaute do modal Aquaviário (parte específica)

duto 2.00

cteModalDutoviario_v2.00.xsd Leiaute do modal Dutoviário (parte específica)

ferrov 2.00

cteModalFerroviario_v2.00.xsd Leiaute do modal Ferroviário (parte específica)

rodo 2.00

cteModalRodoviario_v2.00.xsd Leiaute do modal Rodoviário (parte específica)

multimodal 2.00 cteMultimodal_v2.00.xsd Leiaute do Multimodal (parte específica)

eventoCTe 2.00 eventoCTe_ v2.00.xsd Mensagem de solicitação de registro de evento

do CT-e

retEventoCTe 2.00 retEventoCTe. V2.00.xsd Mensagem de retorno do resultado da

solicitação de registro de evento do CT-e

procEventoCTe 2.00 procEventoCTe_v2.00.xsd Leiaute de compartilhamento de solicitação de

registro de evento do CT-e

evCancCTe 2.00 evCancCTe_v2.00.xsd Leiaute específico do evento de cancelamento

de CT-e

evEPECCTe 2.00 evEPECCTe_v2.00.xsd Leiaute específico do evento de contingencia

EPEC de CT-e

evCCeCTe 2.00 evCCeCTe_v2.00.xsd Leiaute específico do evento de carta de

correção de CT-e

Conhecimento de Transporte

letrônico

Manual de Orientações – Contribuinte

Pág.

4 / 189

Índice

1. Introdução ......................................................................................................... 8

2. Considerações Iniciais ....................................................................................... 9

2.1 Histórico do Documento Fiscal Eletrônico .............................................................. 9

2.2 Conceito do CT-e ................................................................................................... 9

2.3 Descrição Simplificada do Modelo Operacional ...................................................... 9

3. Arquitetura de Comunicação com Contribuinte ................................................ 11

3.1 Modelo Conceitual ................................................................................................ 11

3.2 Padrões Técnicos ................................................................................................. 12

Padrão de Documento XML ......................................................................................... 12

Padrão de Comunicação .............................................................................................. 14

Padrão de Certificado Digital ........................................................................................ 15

Padrão de Assinatura Digital ........................................................................................ 15

Validação de Assinatura Digital pela Secretaria de Fazenda Estadual ......................... 17

Resumo dos Padrões Técnicos .................................................................................... 18

3.3 Modelo Operacional ............................................................................................. 19

Serviços Síncronos ...................................................................................................... 19

Serviços Assíncronos ................................................................................................... 20

Filas e Mensagens ....................................................................................................... 21

3.4 Padrão de Mensagens dos Web Services ............................................................ 22

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

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

Schemas XML das Mensagens dos Web Services ...................................................... 23

3.5 Versão dos Schemas XML ................................................................................... 24

Liberação de Versões dos Schemas para o Conhecimento de Transporte Eletrônico –

CT-e ............................................................................................................................. 24

Pacote de Liberação Preliminar ................................................................................... 24

Pacote de Liberação de Homologação e Pacote de Liberação Definitivo ..................... 25

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

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

Controle de Versão ...................................................................................................... 25

3.6 Schema XML do CT-e – Estrutura Genérica e Estrutura Específica do Modal de

Transporte ....................................................................................................................... 26

Parte Genérica ............................................................................................................. 26

Parte Específica para Cada Modal de Transporte ........................................................ 27

Parte Genérica e Parte Específica para Cada Modal de Transporte – Versões ........... 27

3.7 Sistema de Registro de Eventos........................................................................... 28

Relação dos Tipos de Evento....................................................................................... 29

3.8 SEFAZ Virtual....................................................................................................... 30

4. Web Services .................................................................................................. 31

4.1 Serviço de Recepção de CT-e .............................................................................. 32

Web Service – CteRecepcao ....................................................................................... 32

Leiaute Mensagem de Entrada .................................................................................... 32

Leiaute Mensagem de Retorno .................................................................................... 33

Descrição do Processo de Recepção de Lotes de CT-e .............................................. 34

Validação do Certificado de Transmissão .................................................................... 34

Validação Inicial da Mensagem no Web Service .......................................................... 34

Validação das Informações de Controle da Chamada ao Web Service ........................ 35

Geração da Resposta com o Recibo ............................................................................ 36

Descrição do Processamento do Lote de CT-e ............................................................ 36

Validação da Área de Dados ........................................................................................ 36

Final do Processamento do Lote .................................................................................. 48

Eventos de Marcação .................................................................................................. 48

4.2 Web Service – CteRetRecepcao .......................................................................... 50

Conhecimento de Transporte

letrônico

Manual de Orientações – Contribuinte

Pág.

5 / 189

Leiaute Mensagem de Entrada .................................................................................... 50

Leiaute Mensagem de Retorno .................................................................................... 50

Descrição do Processo de Web Service ...................................................................... 51

Validação do Certificado de Transmissão .................................................................... 52

Validação Inicial da Mensagem no Web Service .......................................................... 52

Validação das Informações de Controle da Chamada ao Web Service ........................ 53

Validação da Área de Dados ........................................................................................ 53

Final do Processamento............................................................................................... 54

4.3 Web Service - CteInutilizacao ............................................................................... 55

Leiaute Mensagem de Entrada .................................................................................... 55

Leiaute Mensagem de Retorno .................................................................................... 56

Descrição do Processo de Web Service ...................................................................... 56

Validação do Certificado de Transmissão .................................................................... 57

Validação Inicial da Mensagem no Web Service .......................................................... 57

Validação das Informações de Controle da Chamada ao Web Service ........................ 58

Validação da Área de Dados ........................................................................................ 58

Final do Processamento............................................................................................... 60

4.4 Web Service – CteConsulta Protocolo .................................................................. 61

Leiaute Mensagem de Entrada .................................................................................... 61

Leiaute Mensagem de Retorno .................................................................................... 61

Descrição do Processo de Web Service ...................................................................... 62

Validação do Certificado de Transmissão .................................................................... 62

Validação Inicial da Mensagem no Web Service .......................................................... 63

Validação das Informações de Controle da Chamada ao Web Service ........................ 63

Validação da Área de Dados ........................................................................................ 64

Final do Processamento............................................................................................... 65

4.5 Web Service – CteStatusServico .......................................................................... 66

Leiaute Mensagem de Entrada .................................................................................... 66

Leiaute Mensagem de Retorno .................................................................................... 66

Descrição do Processo de Web Service ...................................................................... 67

Validação do Certificado de Transmissão .................................................................... 67

Validação Inicial da Mensagem no Web Service .......................................................... 68

Validação das Informações de Controle da Chamada ao Web Service ........................ 68

Validação da Área de Dados ........................................................................................ 69

Final do Processamento............................................................................................... 69

4.6 Web Service – CadConsultaCadastro .................................................................. 70

Descrição do Processo de Web Service ...................................................................... 70

Onde Obter as Definições deste Web Service ............................................................. 70

Onde Obter os Schemas XML deste Web Service ....................................................... 71

4.7 Sistema de Registro de Eventos........................................................................... 72

Leiaute Mensagem de Entrada .................................................................................... 72

Diagrama Simplificado do Schema: eventoCTe_v9.99.xsd .......................................... 73

Leiaute Mensagem de Retorno .................................................................................... 73

Diagrama Simplificado Schema de retorno: retEventoCTe _v99.99.xsd ....................... 75

Descrição do Processo de Web Service ...................................................................... 75

Validação do Certificado de Transmissão .................................................................... 75

Validação Inicial da Mensagem no Web Service .......................................................... 76

Validação das informações de controle da chamada ao Web Service.......................... 76

Validação da Área de Dados ........................................................................................ 77

Processamento das validações específicas do evento ................................................. 79

Final do Processamento do Evento .............................................................................. 79

5. Sistema de Registro de Eventos (Parte Específica) ......................................... 80

5.1 Evento Prévio de Emissão em Contingência (EPEC) ........................................... 80

Leiaute Mensagem do evento EPEC............................................................................ 80

Diagrama Simplificado do Evento EPEC ...................................................................... 81

Conhecimento de Transporte

letrônico

Manual de Orientações – Contribuinte

Pág.

6 / 189

Regras de Validação Específicas ................................................................................. 81

Final do Processamento............................................................................................... 82

5.2 Evento de Cancelamento ..................................................................................... 83

Leiaute Mensagem do evento de Cancelamento ......................................................... 83

Diagrama Simplificado do Evento de Cancelamento .................................................... 83

Regras de Validação Específicas ................................................................................. 83

Final do Processamento............................................................................................... 84

5.3 Evento Registro do Multimodal ............................................................................. 85

Leiaute Mensagem do evento ...................................................................................... 85

Diagrama Simplificado do Evento ................................................................................ 85

Regras de Validação Específicas ................................................................................. 86

Final do Processamento............................................................................................... 86

5.4 Evento Carta de Correção .................................................................................... 87

Leiaute Mensagem do evento Carta de Correção ........................................................ 87

Diagrama Simplificado do Evento Carta de Correção .................................................. 88

Regras de Validação Específicas ................................................................................. 89

Final do Processamento............................................................................................... 89

6. Web Services – Informações Adicionais .......................................................... 90

6.1 Regras de validação ............................................................................................. 90

Tabela de Códigos de Erros e Descrições de Mensagens de Erros ............................. 90

6.2 Padrão de Nomes para os Arquivos ..................................................................... 98

6.3 Tratamento de Caracteres Especiais no Texto de XML ........................................ 98

6.4 Chave de Acesso do CT-e ................................................................................... 99

6.5 Número do Recibo de Lote ................................................................................. 100

6.6 Número do Protocolo .......................................................................................... 100

6.7 Tempo Médio de Resposta ................................................................................. 101

7. Código de Barra ............................................................................................ 102

7.1 Código de Barras Adicional ................................................................................ 103

7.2 Cálculo do Dígito Verificador do CODE-128C..................................................... 104

7.3 Representação Simbólica do Código .................................................................. 104

8. DACTE .......................................................................................................... 105

9. Contingência ................................................................................................. 106

10. Ambiente de Homologação / Produção ......................................................... 107

11. Distribuição do CT-e para o Tomador do Serviço .......................................... 108

11.1 Processo de Distribuição .................................................................................... 108

11.2 Leiaute da Distribuição: CT-e ............................................................................. 108

12. Compartilhamento de Informações do CT-e entre Órgãos Públicos .............. 109

12.1 Processo de Compartilhamento ......................................................................... 109

12.2 Leiaute de Compartilhamento: CT-e .................................................................. 110

12.3 Leiaute de Compartilhamento: Inutilização de Numeração de CT-e .................. 110

12.4 Leiaute de compartilhamento: Registro de Evento de CT-e ................................ 110

12.5 Compartilhamento de Documentos com Outros Órgãos Públicos ...................... 110

Anexo I – Leiaute do CT-e ................................................................................................. 111

CT-e – Diagrama Simplificado – parte genérica ............................................................. 114

CT-e – Documentos Transportados X Mapeamento da Carga (Unidade de Transporte e

Unidade de Carga) ......................................................................................................... 115

CT-e – Diagrama Simplificado – Rodoviário ................................................................... 117

CT-e – Diagrama Simplificado – Aéreo .......................................................................... 118

CT-e – Diagrama Simplificado – Aquaviário ................................................................... 119

CT-e – Diagrama Simplificado – Ferroviáro ................................................................... 120

Leiaute CT-e – Estrutura Genérica................................................................................. 122

Leiaute – Rodoviário ...................................................................................................... 150

Leiaute – Aéreo.............................................................................................................. 154

Leiaute – Aquaviário ...................................................................................................... 156

Leiaute – Ferroviário ...................................................................................................... 157

Conhecimento de Transporte

letrônico

Manual de Orientações – Contribuinte

Pág.

7 / 189

Leiaute – Dutoviário ....................................................................................................... 159

Leiaute – Multimodal ...................................................................................................... 159

Anexo II –– Tabelas de UF, Município e País .................................................................... 165

1. Tabela de Código de UF do IBGE ................................................................. 165

2. Tabela de Código de Município do IBGE ....................................................... 165

2.1 Validação do Código de Município ..................................................................... 166

2.2 Exemplo de Cálculo do Dígito de Controle do Código de Município ................... 166

2.3 Exceção no Cálculo do Dígito de Controle do Código de Município ................... 167

3. Tabela de Código de País do BACEN ........................................................... 167

3.1 Validação do Código de País ............................................................................. 168

3.2 Exemplo de Cálculo do Dígito de Controle do Código de País ........................... 168

3.3 Exceção no Cálculo do Dígito de Controle do Código de País ........................... 168

Anexo III – WS disponíveis ................................................................................................ 169

Anexo IV – Conjunto de Caracteres Código de Barras CODE-128C .................................. 170

Anexo V – Projeto Piloto do CT-e ...................................................................................... 171

Anexo VI – Manual de Contingência .................................................................................. 172

Anexo VII – Campos Impedidos de Alteração por Carta de Correção ................................ 185

Anexo VIII – Relação de CFOP válidos para CT-e ............................................................. 187

Conhecimento de Transporte

letrônico

Manual de Orientações – Contribuinte

Pág.

8 / 189

1. Introdução

Este documento tem por objetivo a definição das especificações e critérios técnicos necessários

para a integração entre os Portais das Secretarias de Fazendas dos Estados e os sistemas de

informações das empresas emissoras de Conhecimento de Transporte eletrônico - CT-e.

Conhecimento de Transporte

letrônico

Manual de Orientações – Contribuinte

Pág.

9 / 189

Considerações Iniciais

O Conhecimento de Transporte Eletrônico (CT-e) está sendo desenvolvido, de forma integrada,

pelas Secretarias de Fazenda dos Estados, Receita Federal do Brasil, representantes das

transportadoras e Agências 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 Tributários Estaduais (ENCAT) a coordenação e a responsabilidade pelo

desenvolvimento e implantação do Projeto CT-e.

2.1

Histórico do Documento Fiscal Eletrônico

O documento fiscal eletrônico surgiu com o Projeto da Nota Fiscal eletrônica, que tinha como

objetivo a implantação de um modelo nacional de documento fiscal eletrônico para substituir a

sistemática atual de emissão do documento fiscal em papel, modelos 1 e 1A, com validade

jurídica garantida pela assinatura digital do emissor.

Os documentos fiscais eletrônicos simplificam o cumprimento das obrigações acessórias a que

os contribuintes estão sujeitos e permitem ao Fisco um melhor acompanhamento das operações

comerciais, mostrando-se uma solução vantajosa para todos os envolvidos nas transações com

estes documentos.

A possibilidade do uso de documentos fiscais eletrônicos em substituição aos documentos

tradicionalmente emitidos em papeis está prevista no parágrafo único da cláusula segunda do

Protocolo ENAT 03/2005.

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.

2.2

Conceito do CT-e

O Conhecimento de Transporte Eletrônico (CT-e) é 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.

2.3

Descrição Simplificada do Modelo Operacional

De maneira simplificada, a empresa emissora de CT-e gerará um arquivo eletrônico contendo as

informações fiscais da prestação de serviço de transporte, que deverá ser assinado digitalmente,

de maneira a garantir a integridade dos dados e a autoria do emissor. Este arquivo eletrônico,

que corresponderá ao Conhecimento de Transporte Eletrônico (CT-e), será transmitido pela

Conhecimento de Transporte

letrônico

Manual de Orientações – Contribuinte

Pág.

10 / 189

Internet para a Secretaria de Fazenda Estadual de jurisdição do contribuinte emitente. A

Secretaria de Fazenda Estadual fará, então, uma pré-validação do arquivo e devolverá uma

Autorização de Uso, sem a qual não poderá haver a prestação de serviço de transporte.

Após o recebimento do CT-e, a Secretaria de Fazenda Estadual disponibilizará consulta, por

meio da Internet, para o tomador do serviço e outros legítimos interessados que detenham a

chave de acesso do documento eletrônico.

Este mesmo arquivo do CT-e será ainda transmitido pela Secretaria de Fazenda Estadual para a

Receita Federal do Brasil, que será o repositório nacional de todos os CT-e emitidos, e para as

Secretarias de Fazenda de início da prestação do serviço e do tomador do serviço, caso sejam

diferentes da Secretaria de Fazenda de circunscrição do emissor, além da SUFRAMA, quando

aplicável.

O sistema CT-e implementa o conceito de “eventos”, que é o registro de uma ação ou situação

relacionada com o conhecimento, que ocorreu após a autorização de uso, como o registro de um

cancelamento, por exemplo.

Para acobertar a prestação de serviço de transporte será impressa uma representação gráfica

simplificada do Conhecimento de Transporte Eletrônico, intitulada DACTE (Documento Auxiliar

do Conhecimento de Transporte Eletrônico), em papel comum, imprimindo-se, em destaque: o

número do protocolo de autorização do referido documento a chave de acesso e o código de

barras linear, tomando-se por referência o padrão CODE-128C, para facilitar e agilizar a consulta

do CT-e na Internet e a respectiva confirmação de informações pelas unidades fiscais e pelos

tomadores de serviços de transporte.

O DACTE não é o Conhecimento de Transporte Eletrônico, nem o substitui, serve apenas como

instrumento auxiliar para o transporte da mercadoria e para a consulta do CT-e por meio da

chave de acesso numérica ali impressa, representada e impressa em código de barras. Permite

ao detentor do documento confirmar a efetiva existência do CT-e, por meio dos sítios das

Secretarias de Fazenda Estaduais autorizadoras ou Receita Federal do Brasil. O contribuinte

tomador do serviço de transporte, não emissor de Documentos Fiscais Eletrônicos, poderá

escriturar o CT-e com base nas informações apresentadas naquele documento e sua validade

vincula-se à efetiva existência do CT-e com autorização de uso no Banco de Dados das

administrações tributárias envolvidas no processo.

Conhecimento de Transporte

letrônico

Manual de Orientações – Contribuinte

Pág.

11 / 189

Arquitetura de Comunicação com Contribuinte

3.1

Modelo Conceitual

Os Portais das Secretarias de Fazenda Estaduais fornecerão os seguintes serviços:

a) Recepção de CT-e;

1) Recepção de Lote;

2) Consulta Processamento de Lote;

b) Inutilização de Numeração de CT-e;

c) Consulta da Situação Atual do CT-e;

d) Consulta do status do serviço.

e) Registro de Eventos

Para cada serviço oferecido existirá um Web Service específico. O fluxo de comunicação inicia-

se sempre pelo aplicativo do contribuinte por meio do envio de uma mensagem ao Web Service

com a solicitação do serviço desejado.

O Web Service sempre devolve uma mensagem de resposta confirmando o recebimento da

solicitação de serviço ao aplicativo do contribuinte na mesma conexão.

A solicitação de serviço poderá ser atendida na mesma conexão ou ser armazenada em filas de

processamento nos serviços mais críticos para um melhor aproveitamento dos recursos de

comunicação e de processamento das Secretarias de Fazenda Estaduais.

Os serviços podem ser síncronos ou assíncronos, em função da forma de processamento da

solicitação de serviços:

a) Serviços síncronos – o processamento da solicitação de serviço é concluído na mesma

conexão, com a devolução de uma mensagem contendo o resultado do processamento

do serviço solicitado;

b) Serviços assíncronos – o processamento da solicitação de serviço não é concluído na

mesma conexão, havendo a devolução de uma mensagem de resposta contendo recibo

que tão somente confirma a recepção da solicitação de serviço. O aplicativo do

contribuinte deverá realizar uma nova conexão para consultar o resultado do

processamento do serviço solicitado anteriormente.

O diagrama a seguir ilustra o fluxo conceitual de comunicação entre o aplicativo do contribuinte e

o Portal da Secretaria de Fazenda Estadual:

Contribuinte

Secretaria de Fazenda Estadual

Client CTe

(

ERP ou software específico

)

CTe

Aplicativo de Faturamento

(

ERP ou software específico

)

HTTPS

Fluxo de

Comunicação

Serviços

Síncronos

Aplicação CTe

Filas de Msgs

CTes

Arquitetura de Comunicação

–

Visão Conceitual

Serviços

Assíncronos

Web Services

Transações

Conhecimento de Transporte

letrônico

Manual de Orientações – Contribuinte

Pág.

12 / 189

3.2

Padrões Técnicos

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: Importante destacar que cada arquivo XML terá tão somente uma declaração <?xml

version="1.0" encoding="UTF-8"?>. Nas situações em que um documento XML contenha

outros documentos XML, como ocorre com o documento XML de lote de envio de CT-e,

deve-se atentar para que exista apenas uma declaração no início do lote.

b) Declaração namespace

O documento XML terá tão somente UMA 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 CT-e)

Veda-se o uso de declaração namespace diferente do padrão estabelecido para o Projeto.

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

conforme exemplo abaixo.

Cada documento XML terá o seu namespace individual em seu elemento raiz.

No caso específico do lote de envio do CT-e serão aceitas duas formas de declaração do

namespace:

- Uma única declaração namespace no elemento raiz do lote <enviCTe> ou;

- Para cada CT-e deverá ter declarado o seu namespace individual.

Veja exemplos a seguir:

<?xml version="1.0" encoding="UTF-8"?>

...

…

</CTe>

...

…

</CTe>

</enviCTe>

Conhecimento de Transporte

letrônico

Manual de Orientações – Contribuinte

Pág.

13 / 189

<?xml version="1.0" encoding="UTF-8"?>

<CTe>

...

…

</CTe>

<CTe>

...

…

</CTe>

</enviCTe>

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 CT-e com

prefixo cte) deverá ser adotada a declaração:

d) Otimização na Montagem do Arquivo

Na geração do arquivo XML do CT-e, 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 serão 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 CT-e, serão 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. Identificam-se os campos obrigatórios no leiaute 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 estender-se-á para os campos nos quais não exista

indicação de obrigatoriedade, mas com preenchimento 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.

Exemplo 1: SubGrupo de Informações de transporte de produtos perigosos (ocorrência 0-1).

Será preenchido se a legislação específica o exigir.

Exemplo 2: Informação relacionada com o AFRMM - Adicional de Frete para Renovação da

Marinha Mercante (ocorrência 0-1). Será preenchido somente se o negócio do contribuinte for

transporte aquaviário.

Conhecimento de Transporte

letrônico

Manual de Orientações – Contribuinte

Pág.

14 / 189

Para reduzir o tamanho final do arquivo XML do CT-e 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 CT-e e as demais mensagens XML

para validação pelo Schema do XML (XSD – XML Schema Definition), fornecido pela Secretaria

de Fazenda Estadual, antes de seu envio.

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 CT-e utilize serviços de SEFAZ

VIRTUAL, conforme o previsto no item 3.7 deste Manual.

O meio físico de comunicação utilizado será a Internet, com o uso do protocolo SSL versão 3.0,

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 por meio de certificados digitais, eliminando a

necessidade de identificação do usuário mediante 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 Portal da Secretaria de Fazenda Estadual e o

aplicativo do contribuinte será realizada no padrão SOAP versão 1.2, com troca de mensagens

XML no padrão Style/Enconding: Document/Literal.

A chamada dos diferentes Web Services do Projeto CT-e é realizada com o envio de uma

mensagem XML através do campo cteDadosMsg.

A versão do leiaute da mensagem XML contida no campo cteDadosMsg e o código da UF

requisitada serão informados nos campos versaoDados e cUF, ambos do tipo string localizados

no elemento cteCabecMsg do SOAP header.

Exemplo de uma mensagem requisição padrão SOAP:

<?xml version="1.0" encoding="utf-8"?>

<soap12:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap12="http://www.w3.org/2003/05/soap-envelope">

<soap12:Header>

<cUF>string</cUF>

<versaoDados>string</versaoDados>

</cteCabecMsg>

</soap12:Header>

<soap12:Body>

</soap12:Body>

</soap12:Envelope>

Conhecimento de Transporte

letrônico

Manual de Orientações – Contribuinte

Pág.

15 / 189

Exemplo de uma mensagem de retorno padrão SOAP:

<?xml version="1.0" encoding="utf-8"?>

<soap12:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap12="http://www.w3.org/2003/05/soap-envelope">

<soap12:Header>

<cUF>string</cUF>

<versaoDados>string</versaoDados>

</cteCabecMsg>

</soap12:Header>

<soap12:Body>

<cteRecepcaoLoteResult

xmlns="http://www.portalfiscal.inf.br/cte/wsdl/CteRecepcao">xml</cteRecepcaoLoteResult>

</soap12:Body>

</soap12:Envelope>

Padrão de Certificado Digital

O certificado digital utilizado no Projeto do Conhecimento de Transporte eletrônico 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

no campo

otherName

OID =2.16.76.1.3.3.

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

a) Assinatura de Mensagens: o certificado digital utilizado para essa função deverá conter

o CNPJ de um dos estabelecimentos da empresa emissora do CT-e. Por mensagens,

entenda-se: Pedido de Autorização de Uso (Arquivo CT-e), Pedido de Registro de

Evento, Pedido de Inutilização de Numeração de CT-e 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, respeitando-se a Política do Certificado;

b) Transmissão (durante a transmissão das mensagens entre o servidor do contribuinte e o

Portal da Secretaria de Fazenda Estadual): o certificado digital utilizado para

identificação do aplicativo do contribuinte deverá conter o CNPJ do responsável pela

transmissão das mensagens, não necessariamente o mesmo CNPJ do estabelecimento

emissor do CT-e, devendo ter a extensão Extended Key Usage com permissão de

"Autenticação Cliente".

Padrão de Assinatura Digital

As mensagens enviadas ao Portal da Secretaria de Fazenda Estadual são documentos

eletrônicos elaborados no padrão XML e devem ser assinados digitalmente com um certificado

digital contendo o CNPJ do estabelecimento matriz ou o CNPJ do estabelecimento emissor do

CT-e objeto do pedido.

Os elementos abaixo estão contidos no Certificado do contribuinte tornando desnecessária a sua

representação individualizada no arquivo XML. Portanto, o arquivo XML não deve conter os

elementos:

Conhecimento de Transporte

letrônico

Manual de Orientações – Contribuinte

Pág.

16 / 189

Deve-se evitar o uso das TAGs relacionadas a seguir, pois as informações serão obtidas a partir

do Certificado do emitente:

O Projeto CT-e utiliza um subconjunto do padrão de assinatura XML definido pelo

http://www.w3.org/TR/xmldsig-core/, que tem o seguinte leiaute:

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

# Campo Ele

Pai Tipo

Ocor.

Tam.

Dec.

Descrição/Observação

XS01

Signature Raiz

- - - -

XS02

SignedInfo G XS01

- 1-1 Grupo da Informação da assinatura

XS03

CanonicalizationMe

thod G XS02

- 1-1 Grupo do Método de Canonicalização

XS04

Algorithm A XS03

C 1-1 Atributo Algorithm de CanonicalizationMethod:

http://www.w3.org/TR/2001/REC-xml-c14n-

20010315

XS05

SignatureMethod G XS02

- 1-1 Grupo do Método de Assinatura

XS06

Algorithm A XS05

C 1-1 Atributo Algorithm de SignedMethod:

http://www.w3.org/2000/09/xmldsig#rsa-sha1

XS07

Reference G XS02

- 1-1 Grupo de Reference

XS08

URI A XS07

C 1-1 Atributo URI da tag Reference

XS10

Transforms G XS07

- 1-1 Grupo do algorithm de Transform

XS11

unique_Transf_Alg RC

XS10

- 1-1 Regra para o atributo Algorithm do Transform ser

único.

XS12

Transform G XS10

- 2-2 Grupo de Transform

XS13

Algorithm A XS12

C 1-1 Atributos válidos Algorithm do Transform:

http://www.w3.org/TR/2001/REC-xml-c14n-

20010315

http://www.w3.org/2000/09/xmldsig#enveloped-

signature

XS14

XPath E XS12

C 0-N XPath

XS15

DigestMethod G XS07

- 1-1 Grupo do Método de DigestMethod

XS16

Algorithm A XS15

C 1-1 Atributo Algorithm de DigestMethod:

http://www.w3.org/2000/09/xmldsig#sha1

XS17

DigestValue E XS07

C 1-1 Digest Value (Hash SHA-1 – Base64)

XS18

SignatureValue G XS01

- 1-1 Grupo do Signature Value

XS19

KeyInfo G XS01

- 1-1 Grupo do KeyInfo

XS20

X509Data G XS19

- 1-1 Grupo X509

XS21

X509Certificate E XS20

C 1-1 Certificado Digital x509 em Base64

A assinatura do Contribuinte no CT-e será feita na TAG <infCTe> identificada pelo atributo Id.

Seu conteúdo 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 <Reference>. Para as demais mensagens a ser

assinadas o processo é o mesmo, mantendo-se sempre identificador único para o atributo Id na

TAG a ser assinada.

Conhecimento de Transporte

letrônico

Manual de Orientações – Contribuinte

Pág.

17 / 189

Segue um exemplo:

...

</infCTe>

</Transforms>

<DigestValue>vFL68WETQ+mvj1aJAMDx+oVi928=</DigestValue>

</Reference>

</SignedInfo>

<SignatureValue>IhXNhbdL1F9UGb2ydVc5v/gTB/y6r0KIFaf5evUi1i ...</SignatureValue>

<X509Certificate>MIIFazCCBFOgAwIBAgIQaHEfNaxSeOEvZGlVDANB ... </X509Certificate>

</X509Data>

</KeyInfo>

</Signature>

</CTe>

Para o processo de assinatura, o contribuinte não deve fornecer a Lista de Certificados

Revogados, já que essa Lista será montada e validada em cada Portal de Secretaria de Fazenda

Estadual, no momento da conferência da assinatura digital.

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

a) Padrão 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 Certificação: EndCertOnly (Incluir na assinatura apenas o certificado do

usuário final);

d) Tipo do certificado: A1 ou A3 (o uso de HSM é recomendado);

e) Tamanho da Chave Criptográfica: Compatível com os certificados A1 e A3 (1024 bits);

f) Função criptográfica assimétrica: RSA (http://www.w3.org/2000/09/xmldsig#rsa-sha1);

g) Função de “message digest”: SHA-1 (http://www.w3.org/2000/09/xmldsig#sha1);

h) Codificação: Base64 (http://www.w3.org/2000/09/xmldsig#base64);

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

Validação de Assinatura Digital pela Secretaria de Fazenda Estadual

Para a validação da assinatura digital, seguem as regras adotadas pelas Secretarias de Fazenda

Estaduais:

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

Conhecimento de Transporte

letrônico

Manual de Orientações – Contribuinte

Pág.

18 / 189

(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 fica a critério de cada Secretaria de Fazenda Estadual, podendo

ser feita de 2 (duas) maneiras: on-line ou Download periódico. As assinaturas digitais das

mensagens serão verificadas considerando-se a lista de certificados revogados disponível no

momento da conferência da assinatura.

Resumo dos Padrões Técnicos

A tabela a seguir resume os principais padrões de tecnologia utilizados:

Característica

Descrição

Web Services

Padrão definido pelo WS-I Basic Profile 1.1 (http://www.ws-

i.org/Profiles/BasicProfile-1.1-2004-08-24.html).

Meio lógico de comunicação

Web Services, disponibilizados pelo Portal da Secretaria

de Fazenda Estadual.

Meio físico de comunicação

Internet

Protocolo Internet

SSL versão 3.0, com autenticação mútua através de

certificados digitais.

Padrão de troca de mensagens

SOAP versão 1.2.

Padrão da mensagem

XML no padrão Style/Encoding: Document/Literal.

Padrão de certificado digital

X.509 versão 3, emitido por Autoridade Certificadora

credenciada pela Infraestrutura de Chaves Públicas

Brasileira – ICP-Brasil, do tipo A1 ou A3, devendo conter o

CNPJ do proprietário do certificado digital.

Para a assinatura de mensagens, utilizar o certificado

digital de um dos estabelecimentos da empresa emissora

do CT-e.

Para a transmissão, utilizar o certificado digital do

responsável pela transmissão.

Padrão de assinatura digital

XML Digital Signature, Enveloped, com certificado digital

X.509 versão 3, com chave privada de 1024 bits, com

padrões de criptografia assimétrica RSA, algoritmo

message digest SHA-1 e utilização das transformações

Enveloped e C14N.

Validação de assinatura digital

Será validada além da integridade e autoria, a cadeia de

confiança com a validação das LCRs.

Padrões de preenchimento XML

•

Campos não obrigatórios do Schema que não possuam

conteúdo terão suas tags suprimidas no arquivo XML.

• Máscara de números decimais e datas estão definidas

no Schema XML.

• Nos campos numéricos inteiros, não incluir a vírgula ou

ponto decimal.

• Nos campos numéricos com casas decimais, utilizar o

“ponto decimal” na separação da parte inteira.

Conhecimento de Transporte

letrônico

Manual de Orientações – Contribuinte

Pág.

19 / 189

3.3

Modelo Operacional

A forma de processamento das solicitações de serviços no Conhecimento de Transporte

eletrônico pode ser síncrona, caso o atendimento da solicitação de serviço seja realizado na

mesma conexão; ou assíncrona, quando o processamento do serviço solicitado não é atendido

na mesma conexão, nesta situação, torna-se necessária a realização de mais uma conexão para

a obtenção do resultado do processamento.

As solicitações de serviços que exigem processamento intenso serão executadas de forma

assíncrona e as demais solicitações de serviços de forma síncrona.

Assim, os serviços do CT-e serão implementados da seguinte forma:

Serviço Implementação

Recepção de CT-e Assíncrona

Inutilização de Numeração de CT-e Síncrona

Consulta da situação atual do CT-e Síncrona

Registro de Evento de CT-e Síncrona

Consulta do status do serviço Síncrona

Consulta Cadastro (especificação no MOC da NF-e) Síncrona

Serviços Síncronos

As solicitações de serviços de implementação síncrona são processadas imediatamente e o

resultado do processamento é obtido em uma única conexão.

A seguir, o fluxo simplificado de funcionamento:

Etapas do processo ideal:

(1) O aplicativo do contribuinte inicia a conexão enviando uma mensagem de solicitação de

serviço para o Web Service;

(2) O Web Service recebe a mensagem de solicitação de serviço e encaminha ao aplicativo

do CT-e que irá processar o serviço solicitado;

(3) O aplicativo do CT-e recebe a mensagem de solicitação de serviço 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

não exista outra mensagem, encerra a conexão.

Aplicativo

Cliente

Web Service

Processamento

de Serviços

(1) Solicitação de

serviço

(2) Solicitação de

serviço

(4) Resultado (3) Resultado

Contribuinte Secretaria de Fazenda Estadual

Serviço de Implementação Síncrona

Conhecimento de Transporte

letrônico

Manual de Orientações – Contribuinte

Pág.

20 / 189

Serviços Assíncronos

As solicitações de serviços de implementação assíncrona são processadas de forma distribuída

por vários processos e o resultado do processamento somente é obtido na segunda conexão.

A seguir o fluxo simplificado de funcionamento:

Envio de

Solicitação

de Serviços

Consulta

Recibo

Web Service

Recebe Solicitação

de Serviços

Web Service

Consulta recibo

Processamento

de Serviços

(1) Solicitação de serviço (2) Solicitação de serviço

(8) Consulta recibo

(3) Recibo

Fila de

serviços

solicitados

Fila de

recibos

(4)

(7)

(5)

(6)

(10) Resultado processamento

(9) Resultado processamento

Fila de

serviços

processados

Contribuinte Secretaria de Fazenda Estadual

Serviço de Implementação assíncrona

Etapas do processo ideal:

(1) O aplicativo do contribuinte inicia a conexão enviando uma mensagem de solicitação

de serviço para o Web Service de recepção de solicitação de serviços;

(2) O Web Service de recepção de solicitação de serviços recebe a mensagem de

solicitação de serviço e a coloca na fila de serviços solicitados, acrescentando o CNPJ

do transmissor obtido do certificado digital do transmissor;

(3) O Web Service de recepção de solicitação de serviços retorna o recibo da solicitação

de serviço e a data e hora de recebimento da mensagem no Web Service;

(4) O aplicativo do contribuinte recebe o recibo e o coloca na fila de recibos de serviços

solicitados e ainda não processados e, caso não exista outra mensagem, encerra a

conexão;

(5) Na Secretaria de Fazenda Estadual a solicitação de serviços é retirada da fila de

serviços solicitados pelo aplicativo do CT-e;

(6) O serviço solicitado é processado pelo aplicativo do CT-e e o resultado do

processamento é colocado na fila de serviços processados;

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

(8) O aplicativo do contribuinte envia uma consulta de recibo, iniciando uma conexão com

o Web Service “Consulta Recibo (CTeRetRecepcao)”;

(9) O Web Service “Consulta Recibo” recebe a mensagem de consulta recibo e localiza o

resultado de processamento da solicitação de serviço;

Conhecimento de Transporte

letrônico

Manual de Orientações – Contribuinte

Pág.

21 / 189

(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 não exista outra mensagem, encerra a conexão.

Filas e Mensagens

As filas de mensagens de solicitação de serviços são necessárias para a implementação do

processamento assíncrono das solicitações de serviços.

As mensagens de solicitações de serviços no processamento assíncrono são armazenadas em

uma fila de entrada.

Para ilustrar como as filas armazenam as informações, apresenta-se o diagrama a seguir:

A estrutura de um item é composta pela área de controle (identificador) e pela área de detalhe

que contém a mensagem XML. As seguintes informações são adotadas como atributos de

controle:

• CNPJ do transmissor: CNPJ da empresa que enviou a mensagem que não 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 solicitação

de serviços;

• Recibo de entrega: Número sequencial único atribuído para a mensagem pela

Secretaria de Fazenda Estadual. Este atributo identifica a mensagem de solicitação de

serviços na fila de mensagem;

• Data e hora de recebimento da mensagem: Data e hora local do instante de

recebimento da mensagem atribuída pela Secretaria de Fazenda Estadual. Este atributo

é importante como parâmetro de desempenho do sistema, eliminação de mensagens,

adoção do regime de contingência, etc. O tempo médio de resposta é calculado com

base neste atributo;

• cUF: Código da UF (na codificação 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 implementação da SEFAZ Virtual e identificação da UF de origem da

mensagem;

• versaoDados: Versão do leiaute da mensagem existente na área de dados. O atributo é

utilizado para validação de schema XML do XML de dados e verificar a vigência da

versão informada.

Para processar as mensagens de solicitações de serviços, a aplicação 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 solicitação de serviço em uma fila de saída.

A fila de saída terá a mesma estrutura da fila de entrada, a única diferença será o conteúdo do

detalhe da mensagem que contém o resultado do processamento da solicitação de serviço em

formato XML.

Estrutura de um item da fila:

CNPJ do

Transmissor

Número

do Recibo

data e hora

recebimento

cUF

XML de Dados

Área de controle

Área de mensagem

Versão

Dados

Conhecimento de Transporte

letrônico

Manual de Orientações – Contribuinte

Pág.

22 / 189

O tempo médio de resposta que mede a performance do serviço 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 solicitação de serviço na fila de

saída.

Nota: O termo fila é utilizado apenas para designar um repositório de recibos emitidos. A

implementação da fila poderá ser feita por meio de Banco de Dados ou qualquer outra forma, sendo

transparente para o contribuinte que realizará a consulta do processamento efetuado (processos

assíncronos).

3.4

Padrão de Mensagens dos Web Services

As chamadas dos Web Services fornecidos pelas Secretarias de Fazenda Estaduais ou Receita

Federal do Brasil e os respectivos resultados do processamento são realizadas servindo-se de

mensagens com o seguinte padrão:

•

cUF

– código da UF de origem da mensagem

•

versaoDados - versão do leiaute da estrutura XML informada na área de dados

• Área de Dados – estrutura XML variável definida na documentação do Web Service

acessado.

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

As informações de controle das chamadas dos Web Services são armazenadas no elemento

cteCabecMsg do SOAP Header e servem para identificar a UF de origem do emissor e a versão

do leiaute da estrutura XML armazenada na área de dados da mensagem:

<soap12:Header>

<cUF>string</cUF>

<versaoDados>string</versaoDados>

</cteCabecMsg>

</soap12:Header>

A informação armazenada na área de dados é um documento XML que deve atender ao leiaute

definido na documentação do Web Service acessado:

<soap12:Body>

</soap12:Body>

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.

cUF Estrutura XML definida na documentação do Web Service

Padrão de Mensagem de chamada/retorno de Web Service

Elemento cteCabecMsg (SOAP Header)

Área de dados (SOAP Body)

versaoDados

Conhecimento de Transporte

letrônico

Manual de Orientações – Contribuinte

Pág.

23 / 189

As alterações de leiaute e de estrutura de dados XML realizadas nas mensagens são

controladas por meio 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 no campo

versaoDados do elemento cteCabecMsg do SOAP Header.

<soap12:Header>

</cteCabecMsg>

</soap12:Header>

Schemas XML das Mensagens dos Web Services

Toda mudança de leiaute das mensagens dos Web Services implica atualização do 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_v1.00.xsd (Schema XML do CTe, versão 1.00);

tiposGeral_v10.15.xsd (Schema XML dos tipos do CTe, versão 10.15).

A maioria dos Schemas XML do CT-e utilizam as definições de tipos básicos ou tipos complexos

que estão definidos em outros Schemas XML (ex.: tiposGeral_v1.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 (quinze) posições com 2 (dois) decimais é definido no

Schema tiposGeral_v1.01.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.

Exemplo de Schema XML

<?xml version="1.0" encoding="UTF-8"?>

<xs:schema xmlns:ds="http://www.w3.org/2000/09/xmldsig#"

xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns="http://www.portalfiscal.inf.br/cte"

targetNamespace="http://www.portalfiscal.inf.br/cte" elementFormDefault="qualified"

attributeFormDefault="unqualified">

<xs:import namespace="http://www.w3.org/2000/09/xmldsig#" schemaLocation="xmldsig-core-

schema_v1.01.xsd"/>

<xs:include schemaLocation="tiposGeral_v1.01.xsd"/>

<xs:element name="CTe">

<xs:annotation>

<xs:documentation>Conhecimento de Transporte Eletrônico</xs:documentation>

</xs:annotation>

Conhecimento de Transporte

letrônico

Manual de Orientações – Contribuinte

Pág.

24 / 189

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 ocorrerão sempre que se fizerem necessárias.

3.5

Versão dos Schemas XML

Liberação de Versões dos Schemas para o Conhecimento de Transporte Eletrônico – CT-e

Os schemas válidos para o Conhecimento de Transporte Eletrônico estarão disponíveis no sitio

nacional do Projeto (www.cte.fazenda.gov.br) 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 pelas empresas 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 com ele 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_1.00.zip representa o “Pacote de Liberação” de schemas do

Conhecimento de Transporte eletrônico compatíveis com o Manual de Orientações do

Contribuinte – versão 1.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 “Envio de Lotes de Conhecimento de Transporte Eletrônico”,

corresponderá um arquivo com a extensão “.xsd”, que terá o nome de “cteEnvLote_v9.99.xsd”,

em que v9.99, corresponde à versão do respectivo schema.

Para identificar quais schemas sofreram alteração em um determinado pacote liberado, deve-se

comparar o número da versão do schema deste pacote com o número da versão do pacote

anterior.

Exemplificando:

PACOTE

CTe_

.ZIP

PL_

CTe_

1.01

.ZIP

DATA LIBERAÇÃO

01/04/2008 01/06/2008

SCHEMA

cteEnvLote_v1.00.xsd cteEnvLote _v1.30.xsd

inutCTe_v1.00.xsd inutCTe_v1.00.xsd

eventoCTe_v1.00.xsd eventoCTe_v1.00.xsd

tiposGeral_v1.00.xsd tiposGeral _v1.01.xsd

Pacote de Liberação Preliminar

Após a divulgação de uma nova versão do Manual de Orientações do Contribuinte, será

publicado um pacote de liberação preliminar, com vigência limitada até o início da fase de

disponibilização do ambiente de homologação.

Durante esse período, os novos Schemas XML serão avaliados e testados para a identificação

de eventuais falhas de implementação das alterações realizadas no Manual de Orientações do

Contribuinte.

Conhecimento de Transporte

letrônico

Manual de Orientações – Contribuinte

Pág.

25 / 189

O pacote de liberação preliminar será identificado com o acréscimo da literal ‘pre’ na

identificação do pacote, como por exemplo: PL_CTe_1.00pre.zip.

Pacote de Liberação de Homologação e Pacote de Liberação Definitivo

Para o ambiente de homologação, será divulgado um pacote de liberação de homologação que

será identificado com o acréscimo da literal ‘hom’ na identificação do pacote, como por exemplo:

PL_CTe_100hom.zip.

A principal característica do pacote de liberação de homologação é seu uso estar restrito ao

ambiente de homologação por aceitar somente mensagens XML com tpAmb=2-homologação.

O pacote de liberação definitivo será divulgado na véspera da data de início da vigência do

ambiente de produção.

Correção de Pacote de Liberação

Pacotes de liberação intermediários com correções poderão ser publicados caso haja

necessidade de correção de um Schema XML por erro de implementação de regra de validação,

obrigatoriedade de campo, nome de tag divergente do definido no leiaute da mensagem e que

não modifique a estrutura do Schema XML nem exija 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úsculas do

alfabeto, como por exemplo: CTe_PL_1.00a.ZIP, indicando que se trata da primeira versão

corrigida do CTe_PL_1.00.ZIP

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 por meio da publicação de Notas Técnicas no Portal Nacional do CT-e

(www.cte.fazenda.gov.br) com as informações necessárias para a implementação dos novos

pacotes de liberação.

Controle de Versão

O controle de versão de cada um dos schemas válidos do Conhecimento de Transporte

Eletrônico compreende uma definição nacional sobre:

• 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 de transporte suportados pela

parte genérica.

O controle de versão permite a adaptação dos sistemas de informática das empresas

participantes do Projeto em diferentes datas. Ou seja, algumas empresas podem possuir versão

de leiaute mais atualizada, enquanto outras empresas ainda estejam operando com mensagens

em um leiaute anterior.

Não estão previstas mudanças frequentes de leiaute de mensagens e as empresas terão prazo

razoável para implementar as mudanças necessárias, conforme acordo operacional a ser

estabelecido.

Conhecimento de Transporte

letrônico

Manual de Orientações – Contribuinte

Pág.

26 / 189

Mensagens recebidas com uma versão de leiaute não suportada serão rejeitadas com

mensagem de erro específica na versão do leiaute de resposta mais recente.

3.6

Schema XML do CT-e – Estrutura Genérica e Estrutura Específica do Modal de

Transporte

A partir da versão 1.04, a estrutura do Schema XML do CT-e foi modificada, criando-se uma

parte genérica do schema e uma parte específica para cada modal de transporte, com o objetivo

de permitir maior independência entre os modais; assim, uma alteração no leiaute específico

para um modal não repercute nos demais.

Parte Genérica

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

os modais.

Para alcançar este objetivo, foi criada no schema XML do CT-e 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:

Conhecimento de Transporte

letrônico

Manual de Orientações – Contribuinte

Pág.

27 / 189

A versão do schema XML a ser utilizada na parte específica do modal de transporte será

identificada com um atributo de versão próprio (tag versaoModal), conforme figura a seguir:

Parte Específica para Cada Modal de Transporte

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

A parte específica do schema XML para cada modal de transporte será distribuída no mesmo

pacote de liberação em arquivo separado para cada um deles.

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

cteModalXXXXXXXXXXXX_v9.99.xsd

Em que XXXXXXXXXXXX é a identificação do modal de transporte, 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_v2.00.xsd (modal rodoviário, versão 2.00);

• cteModalAereo_v2.00.xsd (modal Aéreo, versão 2.00);

• cteModalFerroviario_v2.00.xsd (modal ferroviário, versão 2.00);

• cteModalAquaviario_v2.00.xsd (modal aquaviario, versão 2.00);

•

cteModalDutoviario_v2.00.xsd (modal dutoviário, versão 2.00).

•

cteMultiModal_v.2.00.xsd (multimodal, versão 2.00)

Parte Genérica e Parte Específica para Cada Modal de Transporte – Versões

Uma versão da parte genérica deverá suportar mais de uma versão da parte específica de cada

modal de transporte. Normalmente, esta relação deve ser de uma para uma (1:1). Apenas em

momentos de transição pode haver empresas de um modal de transporte utilizando uma versão

mais atualizada, enquanto outras empresas ainda operam com um leiaute anterior da parte

específica.

As SEFAZ autorizadoras deverão manter nas suas aplicações o controle de qual(is) versão(ões)

da parte específica é(são) suportada(s) pela parte genérica.

Conhecimento de Transporte

letrônico

Manual de Orientações – Contribuinte

Pág.

28 / 189

3.7

Sistema de Registro de Eventos

O Sistema de Registro de Eventos do CT-e – SRE é o modelo genérico que permite o registro de

evento de interesse do CT-e 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 simplesmente

dar ciência sobre o trânsito deste documento (por exemplo: registro de passagem).

O serviço para registro de eventos será disponibilizado pelas SEFAZ Autorizadoras através de

WebService 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 CT-e contendo a assinatura digital do

emissor do evento (seja ele contribuinte ou fisco).

O registro do evento tipicamente requer a existência do CT-e vinculado na SEFAZ Autorizadora,

contudo alguns eventos do trânsito ou contingência poderão ser registrados sem que exista o

CT-e na base de dados do autorizador em conformidade com as regras de negócio

estabelecidas para este tipo de evento.

Além disso, alguns tipos de evento deverão rejeitar documentos com situação diferente de

Autorizado, enquanto outros permitirão a vinculação do evento ao CT-e independente da

situação do documento, nesses casos a homologação do evento retornará um código de status

específico concatenando a situação do CT-e na mensagem de retorno.

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 CT-e vinculado;

• informações específicas do evento;

• assinatura digital da mensagem;

O WebService 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 da SEFAZ Autorizadora.

O leiaute da mensagem de Registro de Evento seguirá o modelo adotado para o documento CT-

e, 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 em item

específico deste MOC.

As validações específicas de cada tipo de evento estarão descritas em item posterior deste

Manual, originando um novo subitem para cada tipo de evento especificado.

O Pacote de Liberação de schemas do CT-e 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.

Conhecimento de Transporte

letrônico

Manual de Orientações – Contribuinte

Pág.

29 / 189

Relação dos Tipos de Evento

Os eventos identificados abaixo são exemplos que serão construídos gradativamente pelo

ambiente autorizador, assim como novos eventos poderão ser identificados e acrescentados

nesta tabela em futuras versões do MOC do CT-e.

Os eventos de contingência serão autorizados no ambiente da SEFAZ Virtual de Contingência-

SVC.

Tipo de

Evento Descrição Evento Tipo de

Autor do Evento Tipo de Meio Informação

Local

Evento CT-e deve

existir?

*** Evento: Empresa Emitente

110110 Carta de Correção 1-Empresa Emitente

1=via WS Evento SEFAZ

Autoriz. Sim

110111 Cancelamento 1-Empresa Emitente

1=via WS Evento SEFAZ

Autoriz. Sim

110113 EPEC 1-Empresa Emitente

1=via WS Evento SVC Não

110160 Registros do

Multimodal 1-Empresa Emitente

1=via WS Evento SEFAZ

Autoriz. Sim

*** Evento: Fisco

310620 Registro de

Passagem 3-Fisco 1=via WS Evento Ambiente

Nacional Não

*** Evento: Fisco do Emitente

240130 Autorizado CT-e

Complementar 2-Fisco do Emitente

1=via WS Evento ou 4=via

integração SEFAZ

Autoriz. Sim

240131 Cancelado CT-e

Complementar 2-Fisco do Emitente

1=via WS Evento ou 4=via

integração SEFAZ

Autoriz. Sim

240140 CT-e de Substituição

2-Fisco do Emitente 1=via WS Evento

ou 4=via

integração SEFAZ

Autoriz. Sim

240150 CT-e de Anulação 2-Fisco do Emitente

1=via WS Evento ou 4=via

integração SEFAZ

Autoriz. Sim

*** Evento: RFB

440160 Multimodal 4-RFB

1=via WS Evento ou 4=via

integração Ambiente

Nacional Não

Legenda:

Tipo de Autor do Evento: 1 – Empresa Emitente; 2 – Fisco do Emitente; 3 – Fisco; 4 – RFB; 5

– Outros Órgãos / Agência Reguladora;

Tipo de Meio de Informação: 1 – via WS de Evento; 2 – via Extranet CT-e; 3 – via Portal CT-e;

4 – Via integração sistemas;

Conhecimento de Transporte

letrônico

Manual de Orientações – Contribuinte

Pág.

30 / 189

3.8

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 CT-e 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 no item 3.1 do 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.

Conhecimento de Transporte

letrônico

Manual de Orientações – Contribuinte

Pág.

31 / 189

Web Services

Os Web Services disponibilizam os serviços que serão utilizados pelos aplicativos dos

contribuintes. O mecanismo de utilização dos Web Services segue as seguintes premissas:

a) Será fornecido um Web Service por serviço, existindo um método para cada tipo de

serviço;

b) Para os serviços assíncronos, o método de envio retorna uma mensagem de

confirmação de recebimento da solicitação de serviço com o recibo e a data e hora local

de recebimento da solicitação ou retorna uma mensagem de erro.

A Secretaria de Fazenda Estadual autorizadora compromete-se a processar os lotes de

conhecimentos de transportes recebidos em até 3 (três) minutos e em, no mínimo, 95%

(noventa e cinco por cento) do total do volume recebido no período de 24 (vinte e quatro)

horas. Este indicador de performance será constantemente avaliado e aperfeiçoado pelo

Comitê Gestor e os contribuintes emissores de CT-e.

A qualquer momento as empresas poderão verificar a performance do serviço de

processamento dos lotes, observando o tempo médio de resposta do serviço nos últimos

5 (cinco) minutos. A empresa poderá optar por entrar em contingência, ou seja, emitir o

DACTE em formulário de segurança do documento auxiliar (FS-DA), caso julgue que o

tempo de resposta não seja aceitável.

No recibo de recepção do lote, também será informado o tempo médio de resposta do

serviço nos últimos 5 (cinco) minutos.

Cada Portal de Secretaria de Fazenda Estadual disponibilizará o resultado do

processamento do lote por um período mínimo de 24 (vinte e quatro) horas

(cteConsLote). Após o término do processamento, a informação da situação atual de

cada conhecimento de transporte estará disponível para consulta individual (consSitCTe).

c) Para os serviços síncronos, o envio da solicitação e a obtenção do retorno serão

realizados na mesma conexão por meio de um único método.

d) As URLs dos Web Services encontram-se no Anexo III deste manual e no Portal do

Ambiente Nacional (www.cte.fazenda.gov.br). Acessando-se a URL, pode-se obter o

WSDL (Web Services Description Language) de cada Web Service.

e) O processo de utilização dos Web Services sempre é iniciado pelo contribuinte

enviando uma mensagem nos padrões XML e SOAP, através do protocolo SSL com

autenticação mútua.

f) A ocorrência de qualquer erro na validação dos dados recebidos interrompe o processo

com a disponibilização de uma mensagem contendo o código e a descrição do erro.

Conhecimento de Transporte

letrônico

Manual de Orientações – Contribuinte

Pág.

32 / 189

4.1

Serviço de Recepção de CT-e

O Serviço de Recepção de CT-e é o serviço oferecido pelos Portais das Secretarias da Fazenda

dos Estados para recepção dos CT-e emitidos pelos contribuintes credenciados em sua unidade

federada.

A forma de processamento do serviço de recepção de CT-e é assíncrona. O contribuinte deve

transmitir o lote de CT-e através do Web Service de recepção 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

Web Service – CteRecepcao

Contribuinte

Client CT-e

Secretaria de Fazenda Estadual

Aplicação CT-e

Processamento

Envio do lote de CT-e-

Filas de Entrada .

Transmissão de Lote de CT-e-

cteRecepcaoLote

Web Service :

CteRecepcao

msgs Proc.

Recibo

Contribuinte

Client CT-e

Secretaria de Fazenda Estadual

Aplicação CT-e

Processamento

Envio do lote de CT-e-

Filas de Entrada .

Transmissão de Lote de CT-e-

cteRecepcaoLote

Web Service :

CteRecepcao

msgs Proc.

Recibo

Função: serviço destinado à recepção de mensagens de lote de CT-e.

Processo: assíncrono.

Método: cteRecepcaoLote

Leiaute Mensagem de Entrada

Entrada: Estrutura XML com o lote de conhecimento de transporte

Conhecimento de Transporte

letrônico

Manual de Orientações – Contribuinte

Pág.

33 / 189

Schema XML: enviCte_v99.99.xsd

# Campo Ele

Pai Tipo

Ocor.

Tam.

Dec.

Descrição/Observação

AP01

enviCTe Raiz

- - - - TAG raiz

AP02

Versão A AP01

N 1-1 1-4 2 Versão do leiaute

AP03

idLote E AP01

N 1-1 1-15

Identificador de controle do envio do lote.

Número sequencial autoincremental, de controle

correspondente ao identificador único do lote

enviado. A responsabilidade de gerar e controlar

esse número é exclusiva do contribuinte.

AP04

CTe G AP01

xml 1-50 - Conjunto de CT-e transmitidos (máximo de 50

CT-e), seguindo definição do Anexo I - Leiaute do

CT-e. O tamanho máximo do lote de 500k pode

limitar a quantidade máxima de CT-e também).

Leiaute Mensagem de Retorno

Retorno: Estrutura XML com a mensagem do resultado da transmissão.

Schema XML: retEnviCte_v99.99.xsd

# Campo Ele

Pai Tipo

Ocor.

Tam.

Dec.

Descrição/Observação

AR01

retEnviCte Raiz

- - - - TAG raiz da Resposta

AR02

versao A AR01

N 1-1 1-4 2 Versão do leiaute

AR03

tpAmb E AR01

N 1-1 1 Identificação do Ambiente:

1 – Produção / 2 - Homologação

AR03a

cUF E AR01

N 1-1 2 Código da UF que atendeu a solicitação.

AR04

verAplic E AR01

C 1-1 1-20

Versão do Aplicativo que recebeu o Lote.

AR05

cStat E AR01

N 1-1 3 Código do status da resposta (vide item 5.1.1)

AR06

xMotivo E AR01

C 1-1 1-255

Descrição literal do status da resposta

AR07

infRec G AR01

- 0-1 - Dados do Recibo do Lote (Só é gerado se o Lote

for aceito)

AR08

nRec E AR07

N 1-1 15 Número do Recibo gerado pelo Portal da

Secretaria de Fazenda Estadual, composto por

duas posições com o Código da UF (codificação

do IBGE) onde foi entregue o Lote, uma posição

para o Tipo de Autorizador e doze posições

numéricas sequenciais (vide item 5.5)

AR09

dhRecbto E AR07

D 1-1 - Data e Hora do Recebimento

Formato = AAAA-MM-DDTHH:MM:SS

Preenchido com data e hora do recebimento do

lote.

AR10

tMed E AR07

N 1-1 N 1-4 Tempo médio de resposta do serviço (em

segundos) dos últimos 5 minutos (vide item 5.7).

Nota: Caso o tempo médio de resposta fique

abaixo de 1 (um) segundo, o tempo será

informado como 1 segundo. Arredondar as

frações de segundos para cima.

As mensagens recebidas com erro geram uma mensagem de erro. Nas demais hipóteses,

retornar-se-á um recibo com número, data, hora local de recebimento e tempo médio de

resposta do serviço nos últimos 5 (cinco) minutos.

O número do recibo gerado pelo Portal da Secretaria de Fazenda Estadual será a chave de

acesso do serviço de consulta ao resultado do processamento do lote.

Conhecimento de Transporte

letrônico

Manual de Orientações – Contribuinte

Pág.

34 / 189

Descrição do Processo de Recepção de Lotes de CT-e

Este método será responsável por receber as mensagens de envio de lotes de CT-e e colocá-las

na fila de entrada.

Existe um limite de até 50 (cinquenta) CT-e por lote. O agrupamento destes CT-e dentro do lote

deve ser feito, por uma restrição operacional e de controle, respeitando-se a regra em que todos

os CT-e do lote devem ser do mesmo estabelecimento (mesmo CNPJ e IE do emitente).

O tamanho máximo do lote de CT-e é limitado em 500 (quinhentos) kB, assim o contribuinte

deve compor um lote de envio de CT-e que não ultrapasse este limite, mesmo que a quantidade

de CT-e do lote esteja dentro do limite de 50 (cinquenta) conhecimentos.

Deverão ser realizadas as validações e procedimentos que seguem.

Validação do Certificado de Transmissão

Validação do Certificado Digital do Transmissor (protocolo SSL)

Regra de Validação

Crítica

Msg

Efeito

A01

Certificado de Transmissor Inválido:

- Certificado de Transmissor inexistente na mensagem

- Versão difere "3"

- Basic Constraint = true (não pode ser Certificado de AC)

- KeyUsage não define "Autenticação Cliente"

Obrig. 280 Rej.

A02

Validade do Certificado (data início e data fim) Obrig. 281 Rej.

A03

Verifica a Cadeia de Certificação:

- Certificado da AC emissora não cadastrado na SEFAZ

- Certificado de AC revogado

- Certificado não assinado pela AC emissora do Certificado

Obrig. 283 Rej.

A04

LCR do Certificado de Transmissor

- Falta o endereço da LCR (CRL DistributionPoint)

- LCR indisponível

- LCR inválida

Obrig. 286 Rej.

A05

Certificado do Transmissor revogado Obrig. 284 Rej.

A06

Certificado Raiz difere da "ICP-Brasil" Obrig. 285 Rej.

A07

Falta a extensão de CNPJ no Certificado (OtherName -

OID=2.16.76.1.3.3) Obrig. 282 Rej.

As validações de A01, A02, A03, A04 e A05 são realizadas pelo protocolo SSL e não precisam

ser implementadas. A validação A06 também pode ser realizada pelo protocolo SSL, mas pode

falhar se existirem outros certificados digitais de Autoridade Certificadora Raiz que não sejam

“ICP-Brasil” no repositório de certificados digitais do servidor de Web Service da SEFAZ.

Validação Inicial da Mensagem no Web Service

Validação

Inicial

da Mensagem n

o Web Service

Regra de Validação

Aplic.

Msg

Efeito

B01

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

B02

XML de Dados Mal Formado Facult. 243 Rej.

B03

Verifica se o Servidor de Processamento está Paralisado

Momentaneamente Obrig. 108 Rej.

B04

Verifica se o Servidor de Processamento está Paralisado sem Previsão Obrig. 109 Rej.

Conhecimento de Transporte

letrônico

Manual de Orientações – Contribuinte

Pág.

35 / 189

A mensagem será descartada se o tamanho exceder o limite previsto (500 kB). A aplicação do

contribuinte não poderá permitir a geração de mensagem com tamanho superior a 500 kB. Caso

isto ocorra, a conexão poderá ser interrompida sem mensagem de erro se o controle do tamanho

da mensagem for implementado por configurações do ambiente de rede da SEFAZ (ex.: controle

no firewall). No caso de o controle de tamanho ter sido implementado por aplicativo, retorna-se a

mensagem de erro 214.

No momento do recebimento da mensagem no Web Service, a critério de cada unidade federada

autorizadora, poderá ser verificado se o XML de dados está bem formado. Esta verificação é útil

para as UF que desejam armazenar o XML de dados em estrutura XML de banco de dados.

As unidades federadas que mantêm o Web Service disponível mesmo quando o serviço esteja

paralisado, deverão implementar as validações 108 e 109. Estas validações poderão ser

dispensadas caso o Web Service não fique disponível quando o serviço estiver paralisado.

Caso a SEFAZ Autorizadora trabalhe na modalidade de SEFAZ Virtual de Contingência (SVC),

sugere-se que esta mantenha uma tabela de UF atendidas indicando para cada uma se o

Ambiente de Autorização é Normal ou SVC, e ainda, o status de ativação da SVC para cada UF

e o prazo de encerramento desta modalidade.

Validação das Informações de Controle da Chamada ao Web Service

Validação das

nformações de

ontrole da

hamada ao Web Service

Regra de Validação

Aplic.

Msg

Efeito

C01

Elemento cteCabecMsg inexistente no SOAP Header Facult. 242 Rej.

C02

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

C03

Se Ambiente de Autorização Normal:

Verificar se a UF informada no campo cUF é atendida pelo WebService Obrig. 410 Rej.

C04

Se Ambiente de Autorização SVC:

Verificar se UF informada no campo cUF é atendida na SVC-[SP/RS]: Obrig. 513 Rej.

C05

Se Ambiente de Autorização SVC:

Verificar se SVC está ativa para a UF informada Obrig. 114 Rej.

C06

Campo versaoDa

dos inexistente no elemento cteCabecMsg do SOAP

Header Obrig. 411 Rej.

C07

Versão dos Dados informada é superior à versão vigente Facult. 238 Rej.

C08

Versão dos Dados não suportada Obrig. 239 Rej.

Os dados referentes à versão do leiaute do lote e à UF de origem do emissor de CT-e são

informados no elemento cteCabecMsg do SOAP Header (para maiores detalhes, vide item

3.4.1).

A aplicação deverá validar os campos cUF e versaoDados e rejeitar o lote recebido em caso de

informações inexistentes ou inválidas.

O campo versaoDados contém a versão do Schema XML da mensagem contida na área de

dados, que deve ser utilizada pelo Servidor de Processamento do CT-e na validação do Schema

XML do lote. Cabe ressaltar que um lote deve conter somente CT-e da mesma versão.

Conhecimento de Transporte

letrônico

Manual de Orientações – Contribuinte

Pág.

36 / 189

Geração da Resposta com o Recibo

Não existindo qualquer problema nas validações, o aplicativo deverá gerar um número de recibo

de lote (vide item 5.5) e gravar a mensagem juntamente com o CNPJ do transmissor, versão da

mensagem e o código da UF de origem.

Após a gravação da mensagem na fila de entrada, será retornada uma mensagem de

confirmação de recebimento para o transmissor, com as seguintes informações:

• identificação do ambiente;

• versão do aplicativo;

• o código 103 e o literal “Lote recebido com Sucesso”;

• o código da UF que atendeu a solicitação;

• o número do recibo (vide item 5.5), com data, hora local de recebimento da mensagem;

• tempo médio de resposta do serviço de processamento dos lotes nos últimos 5 (cinco)

minutos (vide detalhamento da forma de cálculo no item 5.7).

Caso ocorra algum problema de validação, o aplicativo retornará uma mensagem com as

seguintes informações:

• a identificação do ambiente;

• a versão do aplicativo;

• o código e a respectiva mensagem de erro (vide a tabela do item 5.1.1);

• o código da UF que atendeu a solicitação;

Descrição 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 método CteRecepcao.

Este método faz a validação de forma e das regras de negócio e armazena o resultado do

processamento na fila de saída.

Validação da Área de Dados

a) Validação de Forma da Área de Dados

A validação de forma da área de dados da mensagem é realizada conforme a seguinte regra:

Validação da

rea de

ados da

ensagem

Regra de Validação

Aplic.

Msg

Efeito

D01

Verifica Schema XML da Área de Dados (parte genérica) Obrig. 225 Rej.

D02

Verifica a existência de qualquer namespace diverso do namespace

padrão do CT-e (http://www.portalfiscal.inf.br/cte) Facult. 598 Rej.

D03

Verifica a existência de caracteres de edição no início ou fim da

mensagem ou entre as tags Facult. 599 Rej.

D04

Verifica o uso de prefixo no namespace Obrig. 404 Rej.

D05

Verifica se o XML utiliza codificação diferente de UTF-8 Obrig. 402 Rej.

D06

Verifica se o lote contém CT-

e de mais de um estabelecimento emissor

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

D07

Verifica se o lote contém CT-e de mais de um modal de transporte Obrig. 589 Rej.

D08

Verifica se o lote contem CT-e de mais de uma versão de modal

transporte Obrig. 590 Rej.

Conhecimento de Transporte

letrônico

Manual de Orientações – Contribuinte

Pág.

37 / 189

A existência de qualquer erro na validação de forma da área de dados (item 4.1.10 a) implica a

rejeição de todo o lote.

A validação do schema XML do lote de CT-e pela SEFAZ autorizadora será feita em duas

etapas:

- A primeira etapa deve validar a estrutura genérica do lote, submetendo a mensagem contra o

schema XML definido para o lote. Em caso de erro, retornar o código 225;

- A segunda etapa (realizada mais adiante) deve validar a estrutura específica do modal de

transporte para cada um dos documentos de CT-e do lote. Em caso de erro, retornar o código

580.

b) Validação do Certificado Digital de Assinatura

Nesta fase são extraídos todos os CT-e das mensagens de envio de lote e validadas as

seguintes regras de negócio para cada CT-e:

Validação do Certificado Digital

tilizado na Assinatura Digital

do CT

Regra de Validação

Aplic.

Msg

Efeito

E01

Certificado de Assinatura inválido:

- Certificado de Assinatura inexistente na mensagem (*validado também

pelo Schema)

- Versão difere "3"

- Basic Constraints = true (não pode ser Certificado de AC)

- KeyUsage não define "Assinatura Digital" e “Não Recusa”

Obrig. 290 Rej.

E02

Validade do Certificado (data de início e data de fim) Obrig. 291 Rej.

E03

Falta a extensão de CNPJ no Certificado (OtherName -

OID=2.16.76.1.3.3) Obrig. 292 Rej.

E04

Verifica Cadeia de Certificação:

- Certificado da AC emissora não cadastrado na SEFAZ

- Certificado de AC revogado

- Certificado não assinado pela AC emissora do Certificado

Obrig. 293 Rej.

E05

LCR do Certificado de Assinatura:

- Falta o endereço da LCR (CRLDistributionPoint)

- Erro no acesso a LCR ou LCR inexistente

Obrig. 296 Rej.

E06

Certificado de Assinatura revogado Obrig. 294 Rej.

E07

Certificado Raiz difere da “ICP-Brasil” Obrig. 295 Rej.

c) Validação da Assinatura Digital

Validação da Assinatura Digital

do CT

Regra de Validação

Aplic.

Msg

Efeito

F01

Assinatura difere do padrão do CT-e:

- Não assinado o atributo "ID" (falta "Reference URI" na assinatura)

(*validado também pelo Schema)

- Faltam os "Transform Algorithm" previstos na assinatura ("C14N" e

"Enveloped")

Estas validações são implementadas pelo Schema XML da Signature

Obrig. 298 Rej.

F02

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

F03

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

Conhecimento de Transporte

letrônico

Manual de Orientações – Contribuinte

Pág.

38 / 189

d) Validação de Regras de Negócio do CT-e

Validação

do CT

–

Regras de Negócio

Regra

de Validação

Aplic.

Msg

Efeito

G001 Tipo do ambiente do CT-e difere do ambiente do Web Service Obrig.

252 Rej.

G002 Se Tipo do Ambiente for igual 2 (homologação) e existir remetente, o

campo razão social (xNome) deve ser informado com a literal:

“CT-E EMITIDO EM AMBIENTE DE HOMOLOGACAO - SEM VALOR

FISCAL”

Obrig.

646 Rej.

G003 Se Tipo do Ambiente for igual 2 (homologação) e existir expedidor, o

campo razão social (xNome) deve ser informado com a literal:

“CT-E EMITIDO EM AMBIENTE DE HOMOLOGACAO - SEM VALOR

FISCAL”

Obrig.

647 Rej.

G004 Se Tipo do Ambiente for igual 2 (homologação) e existir recebedor, o

campo razão social (xNome) deve ser informado com a literal:

“CT-E EMITIDO EM AMBIENTE DE HOMOLOGACAO - SEM VALOR

FISCAL”

Obrig.

648 Rej.

G005 Se Tipo do Ambiente for igual 2 (homologação) e existir destinatario, o

campo razão social (xNome) deve ser informado com a literal:

“CT-E EMITIDO EM AMBIENTE DE HOMOLOGACAO - SEM VALOR

FISCAL”

Obrig.

649 Rej.

G006 Verificar se a serie informada está na faixa entre 890-899 (reservada) Obrig.

670 Rej.

G007 Código da UF do Emitente difere da UF Autorizadora Obrig.

226 Rej.

G008 Sigla da UF do Emitente difere da UF Autorizadora Obrig.

247 Rej.

G009 Processo de emissão informado inválido (diferente de 0 ou 3) Obrig.

494 Rej.

G010 Se forma de emissão do CT-e for diferente de 5 (FS-DA):

dhCont e xJust não devem ser informados Obrig.

586 Rej.

G011 Se forma de emissão do CT-e for igual a 5 (FS-DA):

dhCont e xJust devem ser informados Obrig.

587 Rej.

G012 Se Data de entrada em contingência estiver informada, esta deve ser menor

ou igual à data de emissão Obrig 588 Rej.

G013 Se Ambiente de Autorização Normal:

- Não aceitar tpEmis = 7 (SVC-RS) ou 8 (SVC-SP) Obrig 515 Rej.

G014 Se Ambiente de Autorização SVC:

- Tipo de Emissão difere do tpEmis da SVC (7=SVC-RS e 8=SVC-SP) Obrig.

516 Rej.

G015 Se ambiente de Autorização SVC:

- Não aceitar tipo de CT-e diferente de 0 (Normal) Obrig.

517 Rej.

G016 Campo ID inválido

- Falta literal "CTe"

- Chave de Acesso do campo ID difere da concatenação dos campos

correspondentes

Obrig.

227 Rej.

G017 Dígito Verificador inválido da Chave de acesso resultante da concatenação

dos campos correspondentes Obrig.

253 Rej.

G018 Se Tipo do CT-e= 0 (Normal) ou 3 (Substituição): deve existir o grupo de

CT-e Normal Obrig.

458 Rej.

G019 Se Tipo do CT-e= 1 (Complemento): deve existir o grupo de CT-e

Complementar Obrig.

459 Rej.

G020 Tomador do serviço informado como remetente, mas inexiste remetente Obrig.

460 Rej.

G021 Tomador do serviço informado como expedidor, mas inexiste expedidor Obrig.

461 Rej.

G022 Tomador do serviço informado como recebedor, mas inexiste recebedor Obrig.

462 Rej.

G023 Tomador do serviço informado como destinatário, mas inexiste destinatário Obrig.

463 Rej.

G024 Se Tipo do CT-e= 0 (Normal) ou 3 (Substituição):

- verificar se a Versão do modal de transporte é suportada Obrig 579 Rej

Conhecimento de Transporte

letrônico

Manual de Orientações – Contribuinte

Pág.

39 / 189

Validação

do CT

–

Regras de Negócio

Regra

de Validação

Aplic.

Msg

Efeito

G025 Se Tipo do CT-e= 0 (Normal) ou 3 (Substituição):

- verificar Schema XML conforme o modal de transporte

(parte específica do

modal de transporte)

Obrig.

580 Rej.

G026 Se Tipo do CT-e= 0 (Normal) ou 3 (Substituição) e Indicador de Lotação

(lota=1):

- verificar se o grupo de informações do veiculo (veic) foi informado para

modal de transporte Rodoviário

Obrig.

688 Rej.

G027 Se Tipo do CT-e= 0 (Normal) ou 3 (Substituição):

Se modal = Rodoviário e RNTRC for diferente de “ISENTO”

- verificar se o grupo de informações do seguro da carga foi informado (seg)

Obrig.

665 Rej.

G028 Se Tipo do CT-e= 0 (Normal) ou 3 (Substituição):

- verificar se o responsável pelo seguro da carga está relacionado no CT-e Obrig.

666 Rej.

G029 Se Tipo do CT-e= 0 (Normal) ou 3 (Substituição):

- verifica se o Valor Total da Carga <vCarga> foi informado para modal de

transporte diferente de Dutoviário

Obrig 581 Rej.

G030 Se Tipo do CT-e= 0 (Normal) ou 3 (Substituição): e modal=ferroviário

- se <tpTraf=1> (tráfego mútuo), o grupo Tráfego Mútuo <trafMut> deve ser

informado

Obrig 582 Rej

G031 Se Tipo do CT-e= 0 (Normal) ou 3 (Substituição): e modal=ferroviário

- se o responsável pelo faturamento for a ferrovia de origem (<respFat=1>),

a ferrovia emitente do CT-e <ferrEmi> deve ser igual a 1 (ferrovia de

origem).

Obrig 583 Rej

G032 Se Tipo do CT-e= 0 (Normal) ou 3 (Substituição): e modal=ferroviário

- se o responsável pelo faturamento for a ferrovia de destino <respFat=2>

deve ser referenciado o CT-e <refCTe> emitido pela ferrovia de origem

**Esta regra de validação deverá ser aplicada somente a partir da

obrigatoriedade para o modal Ferroviário.

Obrig 584 Rej

G033 Se Tipo do CT-e= 0 (Normal) ou 3 (Substituição) e Tipo de Serviço for

DIFERENTE de Redespacho Intermediário ou Serviço Vinculado a

Multimodal:

O grupo de Documentos Transportados (infDoc) deve ser informado.

Obrig.

693 Rej.

G034 Se Tipo do CT-e= 0 (Normal) ou 3 (Substituição) e Tipo de Serviço for

IGUAL a Redespacho Intermediário ou Serviço Vinculado a Multimodal:

O grupo de Documentos Transportados (infDoc) não deve ser informado .

Obrig.

694 Rej.

G035 Se Tipo do CT-e= 0 (Normal) ou 3 (Substituição) e informado grupo

informação de documentos (infDoc):

Quantidade de documentos informados (infNF/infNFe/infOutros) não pode

ultrapassar 2000 documentos

Obrig.

601 Rej

G036 Se Tipo do CT-e= 0 (Normal) ou 3 (Substituição) e informados grupos de

informações de documentos (infDoc) e NF-e (infNfe), para cada uma das

NF-e´s relacionadas:

- Dígito Verificador inválido na Chave de acesso de NF-e transportada

Retornar a primeira chave de acesso inválida.

Obrig.

591 Rej

G037 Se Tipo do CT-e= 0 (Normal) ou 3 (Substituição) e informados grupos de

informações de documentos (infDoc) e NF-e (infNfe), para cada uma das

NF-e´s relacionadas:

- Chave de acesso de NF-

e inválida (Ano < 2005 ou Ano maior que Ano

corrente)

Retornar a primeira chave de acesso inválida.

Facult.

602 Rej.

G038 Se Tipo do CT-e= 0 (Normal) ou 3 (Substituição) e informados grupos de

informações de documentos (infDoc) e NF-e (infNfe), para cada uma das

NF-e´s relacionadas:

- Chave de acesso de NF-e inválida (Mês = 0 ou Mês > 12)

Retornar a primeira chave de acesso inválida.

Facult.

603 Rej.

G039 Se Tipo do CT-e= 0 (Normal) ou 3 (Substituição) e informados grupos de

informações de documentos (infDoc) e NF-e (infNfe), para cada uma das

NF-e´s relacionadas:

Facult.

604 Rej.

Conhecimento de Transporte

letrônico

Manual de Orientações – Contribuinte

Pág.

40 / 189

Validação

do CT

–

Regras de Negócio

Regra

de Validação

Aplic.

Msg

Efeito

- Chave de acesso de NF-e inválida (CNPJ zerado ou digito inválido)

Retornar a primeira chave de acesso inválida.

G040 Se Tipo do CT-e= 0 (Normal) ou 3 (Substituição) e informados grupos de

informações de documentos (infDoc) e NF-e (infNfe), para cada uma das

NF-e´s relacionadas:

- Chave de acesso de NF-e inválida (modelo diferente de 55)

Retornar a primeira chave de acesso inválida.

Facult.

605 Rej.

G041 Se Tipo do CT-e= 0 (Normal) ou 3 (Substituição) e informados grupos de

informações de documentos (infDoc) e NF-e (infNfe), para cada uma das

NF-e´s relacionadas:

- Chave de acesso de NF-e inválida (numero NF = 0)

Retornar a primeira chave de acesso inválida.

Facult.

606 Rej.

G042 Se Tipo do CT-e= 0 (Normal) ou 3 (Substituição) e informados grupos de

informações de documentos (infDoc) e NF-e (infNfe), para cada uma das

NF-e´s relacionadas:

- Acessar BD CHAVES NFE (Chave: CNPJ Emit, Modelo, Série, Nro):

- Verificar se NF-e não existe

Retornar a primeira chave de acesso de NF-e inexistente.

OBS: A SEFAZ Autorizadora poderá consultar o documento diretamente no

Ambiente Nacional através de WebService.

Facult.

661 Rej.

G043 Se Tipo do CT-e= 0 (Normal) ou 3 (Substituição) e informados grupos de

informações de documentos (infDoc) e NF-e (infNfe), para cada uma das

NF-e´s relacionadas:

- Acessar BD CHAVES NFE (Chave: CNPJ Emit, Modelo, Série, Nro):

- Verificar se NF-e existe com diferença de chave de acesso

Retornar a primeira chave de acesso de NF-e com situação inválida.

OBS: A SEFAZ Autorizadora poderá consultar o documento diretamente no

Ambiente Nacional através de WebService.

Facult.

662 Rej.

G044 Se Tipo do CT-e= 0 (Normal) ou 3 (Substituição) e informados grupos de

informações de documentos (infDoc) e NF-e (infNfe), para cada uma das

NF-e´s relacionadas:

- Acessar BD CHAVES NFE (Chave: CNPJ Emit, Modelo, Série, Nro):

- Verificar se NF-e está cancelada ou denegada

Retornar a primeira chave de acesso de NF-e com situação inválida.

OBS: A SEFAZ Autorizadora poderá consultar o documento diretamente no

Ambiente Nacional através de WebService

Facult.

652 Rej.

G045 Se Tipo do CT-e= 0 (Normal) ou 3 (Substituição), Tipo de Serviço for

DIFERENTE de Redespacho Intermediário ou Serviço Vinculado, Modal

diferente de DUTOVIÁRIO e informado CNPJ do Remetente (rem) com UF

início da prestação diferente da UF de fim da prestação:

Verificar se o CNPJ do remetente do CT-e está habilitado no CNE para

emissão de Nota Fiscal Eletrônica

Se CNPJ estiver habilitado o grupo de documentos NF-e (infDoc/infNFe)

deve estar preenchido

Facult.

540 Rej.

G046 Se Tipo do CT-e= 0 (Normal) ou 3 (Substituição):

- Verificar se valor total do serviço não ultrapassa limite de R$ 9.999.999,99

OBS: A SEFAZ poderá aumentar o limite para contribuintes que operam

com valores acima desse teto.

Obrig,

650 Rej.

G047 - Verificar se Valor do ICMS corresponde ao Valor da base de calculo X

Aliquota.

OBS:.Aplicar a regra de acordo com o grupo de informações de imposto

informado (infCte/imp/ICMS).

Considerar uma tolerância de R$ 0,01 para mais ou para menos.

Obrig.

675 Rej.

G048 - Verificar se o CFOP informado pertence a operação de transporte.

OBS:. Verificar a relação de CFOP válidos no Anexo VIII deste MOC Obrig.

676 Rej.

G049 Remetente não informado para tipo de serviço diferente de redespacho Obrig.

469 Rej.

Conhecimento de Transporte

letrônico

Manual de Orientações – Contribuinte

Pág.

41 / 189

Validação

do CT

–

Regras de Negócio

Regra

de Validação

Aplic.

Msg

Efeito

intermediário ou Serviço vinculado a multimodal

G050 Destinatário não informado para tipo de serviço diferente de redespacho

intermediário ou Serviço vinculado a multimodal Obrig.

470 Rej.

G051 Expedidor deve ser informado para tipo de serviço de redespacho

intermediário e Serviço vinculado a multimodal Obrig.

474 Rej.

G052 Recebedor deve ser informado para tipo de serviço de redespacho

intermediário e Serviço vinculado a multimodal Obrig.

475 Rej.

G053 Se Tipo de Serviço = “Serviço Vinculado a Multimodal” deve ser

referenciado o CT-e autorizado pelo OTM (refCTe) Obrig.

651 Rej.

G054 Se Tipo de Serviço = “Serviço Vinculado a Multimodal”

-Acessar BD CHAVES CTE (Chave: CNPJ Emit, Modelo, Série, Nro):

- Verificar se o CT-e Multimodal referenciado (refCTe) não existe

OBS: A SEFAZ Autorizadora poderá consultar o documento diretamente no

Ambiente Nacional através de WebService

Facult.

690 Rej.

G055 Se Tipo de Serviço = “Serviço Vinculado a Multimodal”

-Acessar BD CHAVES CTE (Chave: CNPJ Emit, Modelo, Série, Nro):

- Verificar se o CT-e Multimodal referenciado (refCTe) existe com

diferença de chave de acesso

OBS: A SEFAZ Autorizadora poderá consultar o documento diretamente no

Ambiente Nacional através de WebService

Facult.

691 Rej.

G056 Se Tipo de Serviço = “Serviço Vinculado a Multimodal”

-Acessar BD CHAVES CTE (Chave: CNPJ Emit, Modelo, Série, Nro):

- Verificar se o CT-e Multimodal referenciado (refCTe) está cancelado ou

denegado

OBS: A SEFAZ Autorizadora poderá consultar o documento diretamente no

Ambiente Nacional através de WebService

Facult.

692 Rej.

G057 Se Tipo de Serviço = “Serviço Vinculado a Multimodal”

O CNPJ do Tomador deve ser igual ao CNPJ do Emitente do CT-e

referenciado (obter na chave de acesso em refCTe)

Obrig.

667 Rej.

G058 Se Tipo do CT-e= 2 (Anulação): deve existir o grupo de CT-e de Anulação Obrig.

496

Rej.

G059 Se Tipo do CT-e= 2 (Anulação): o tipo de emissão dever ser normal Obrig.

499 Rej.

G060 Se Tipo do CT-e= 2 (Anulação): Verificar se existe o CT-e objeto da

Anulação

Acesso BD CTE (Chave: CNPJ Emit, Modelo, Série, Nro)

Obrig.

497 Rej.

G061 Se Tipo do CT-e= 2 (Anulação): Verificar se existe o CT-e objeto da

Anulação com a mesma Chave de Acesso.

- CT-e Objeto de Anulação com diferença na Chave de Acesso

Retornar a chave de acesso já autorizada e o número do recibo do CT-e

[chCTe: 99999999999999999999999999999999999999999999]

[nRec:999999999999999]

Obrig.

674 Rej.

G062 Se Tipo do CT-e= 2 (Anulação): o CT-e objeto da anulação deve estar com

a situação autorizado o uso. Obrig.

498 Rej.

G063 Se Tipo do CT-e= 2 (Anulação): somente o emitente pode anular o CT-e. O

CT-e original e o de anulação devem possuir o mesmo CNPJ de emitente. Obrig.

565 Rej.

G064 Se Tipo do CT-e= 2 (Anulação): o CT-e objeto de anulação deve ter Tipo =

0 (Normal) ou 3 (Substituição) Obrig.

500 Rej.

G065 Se Tipo do CT-e= 2 (Anulação): a data de emissão do CT-e de anulação

deve ocorrer em até 60 dias, ou outro limite conforme critério definido pela

SEFAZ (a SEFAZ Virtual deve considerar a hora local do emissor para a

validação) da data de emissão do CT-e objeto de anulação.

Obrig.

501 Rej.

G066 Se Tipo do CT-e= 2 (Anulação): o valor da prestação do serviço e o do

ICMS devem ser iguais ao do CT-e original. Obrig.

502 Rej.

G067 Se Tipo do CT-e= 2 (Anulação): o CT-e objeto da anulação não pode ter

sido anulado anteriormente Obrig.

566 Rej.

Conhecimento de Transporte

letrônico

Manual de Orientações – Contribuinte

Pág.

42 / 189

Validação

do CT

–

Regras de Negócio

Regra

de Validação

Aplic.

Msg

Efeito

G068 Se Tipo do CT-e= 2 (Anulação): o CT-e objeto da anulação não pode ter

sido substituído anteriormente.

Obrig 567 Rej

G069 Se Tipo do CT-e= 2 (Anulação): o CT-e objeto da anulação não pode ter IE

preenchida para o tomador do serviço.

Obrig.

689 Rej.

G070 Se Tipo do CT-e= 2 (Anulação): o CT-e objeto da anulação não pode ter

sido complementado anteriormente. Obrig.

658 Rej.

G071 Se Tipo do CT-e= 3 (Substituição): o tipo de emissão deve ser normal Obrig.

503 Rej.

G072 Se Tipo do CT-e= 3 (Substituição): deve existir o grupo de informações do

CT-e de substituição Obrig.

505 Rej.

G073 Se Tipo do CT-e= 3 (Substituição): verificar se existe o CT-e Substituído.

Acesso BD CTE (Chave: CNPJ Emit, Modelo, Série, Nro) Obrig 568 Rej

G074 Se Tipo do CT-e= 3 (Substituição): Verificar se existe o CT-e Substituído

com a mesma Chave de Acesso:

- CT-e Substituído com diferença na Chave de Acesso

Retornar a chave de acesso já autorizada e o número do recibo do CT-e

[chCTe: 99999999999999999999999999999999999999999999]

[nRec:999999999999999]

Obrig.

673 Rej.

G075 Se Tipo do CT-e= 3 (Substituição): o CT-e substituído deve estar com

situação autorizada (não pode estar cancelado ou denegado) Obrig 569 Rej

G076 Se Tipo do CT-e= 3 (Substituição): o CT-e substituído não pode ter sido

substituído anteriormente Obrig 570 Rej

G077 Se Tipo do CT-e= 3 (Substituição): o CT-e substituído não pode ter sido

complementado Obrig 659 Rej

G078 Se Tipo do CT-e= 3 (Substituição): o CT-e substituído deve ser do Tipo = 0

(Normal) ou 3 (Substituição) Obrig 571 Rej

G079 Se Tipo do CT-e= 3 (Substituição): se foi informado o grupo tomaICMS

(tomador é contribuinte do ICMS), o CT-e a ser substituído (chCTe) não

pode ter sido anulado.

Obrig 577 Rej

G080 Se Tipo do CT-e=3 (Substituição): CNPJ do emitente do CT-e substituto

deve ser igual ao informado no CT-e substituído Obrig.

510 Rej.

G081 Se Tipo do CT-e=3 (Substituição): CNPJ/CPF do remetente do CT-e

substituto deve ser igual ao informado no CT-e substituído Obrig.

511 Rej.

G082 Se Tipo do CT-e=3 (Substituição): CNPJ/CPF do destinatário do CT-e

substituto deve ser igual ao informado no CT-e substituído Obrig.

512 Rej.

G083 Se Tipo do CT-e=3 (Substituição): CNPJ/CPF do expedidor do CT-e

substituto deve ser igual ao informado no CT-e substituído Obrig.

550

Rej.

G084 Se Tipo do CT-e=3 (Substituição): CNPJ/CPF do recebedor do CT-e

substituto deve ser igual ao informado no CT-e substituído Obrig.

551 Rej.

G085 Se Tipo do CT-e=3 (Substituição): CNPJ/CPF do tomador do CT-e

substituto deve ser igual ao informado no CT-e substituído Obrig.

552 Rej.

G086 Se Tipo do CT-e=3 (Substituição): IE do emitente do CT-e substituto deve

ser igual ao informado no CT-e substituído Obrig.

553 Rej.

G087 Se Tipo do CT-e=3 (Substituição): IE do remetente do CT-e substituto deve

ser igual ao informado no CT-e substituído Obrig.

554 Rej.

G088 Se Tipo do CT-e=3 (Substituição): IE do destinatário do CT-e substituto

deve ser igual ao informado no CT-e substituído Obrig.

555 Rej.

G089 Se Tipo do CT-e=3 (Substituição): IE do recebedor do CT-e substituto deve

ser igual ao informado no CT-e substituído Obrig.

557 Rej.

G090 Se Tipo do CT-e=3 (Substituição): IE do expedidor do CT-e substituto deve

ser igual ao informado no CT-e substituído Obrig.

556 Rej.

G091 Se Tipo do CT-e=3 (Substituição): IE do tomador do CT-e substituto deve

ser igual ao informado no CT-e substituído Obrig.

558 Rej.

G092 Se Tipo do CT-e=3 (Substituição): UF de início da prestação do CT-e

substituto deve ser igual ao informado no CT-e substituído Obrig.

559 Rej.

Conhecimento de Transporte

letrônico

Manual de Orientações – Contribuinte

Pág.

43 / 189

Validação

do CT

–

Regras de Negócio

Regra

de Validação

Aplic.

Msg

Efeito

G093 Se Tipo do CT-e=3 (Substituição): UF de fim da prestação do CT-e

substituto deve ser igual ao informado no CT-e substituído Obrig.

560 Rej.

G094 Se Tipo do CT-e=3 (Substituição): a data de emissão do CT-e de

substituição deve ocorrer em até 90 dias, ou outro limite conforme critério

definido pela SEFAZ (a SEFAZ Virtual deve considerar a hora local do

emissor para a validação) da data de emissão do CT-e objeto substituição

Obrig.

563

Rej.

G095 Se Tipo do CT-e=3 (Substituição): se foi informado o CT-e de anulação no

grupo do “Tomador não é contribuinte do ICMS”, verificar se existe o CT-e

de Anulação:

Acesso BD CTE (Chave: CNPJ Emit, Modelo, Série, Nro)

Obrig 572 Rej

G096 Se Tipo do CT-e=3 (Substituição): se foi informado o CT-e de anulação no

grupo do “Tomador não é contribuinte do ICMS”, verificar se existe o CT-e

de Anulação com a mesma Chave de Acesso:

- CT-e de Anulação com diferença na Chave de Acesso

Retornar a chave de acesso já autorizada e o número do recibo do CT-e

[chCTe: 99999999999999999999999999999999999999999999]

[nRec:999999999999999]

Obrig 672 Rej

G097 Se Tipo do CT-e=3 (Substituição): se foi informado o CT-e de anulação no

grupo do “Tomador não é contribuinte do ICMS”, este CT-e informado deve

ser do Tipo=2(Anulação)

Obrig 573 Rej

G098 Se Tipo do CT-e=3 (Substituição): se foi informado o CT-e de anulação no

grupo do “Tomador não é contribuinte do ICMS”, este CT-e anulação deve

ter anulado o mesmo CT-e que agora está sendo substituído.

Obrig 578 Rej

G099 CNPJ Emitente inválido (dígito controle, zeros ou nulo) Obrig.

207 Rej.

G100 IE Emitente não informada (zeros ou nulo) Obrig.

229 Rej.

G101 IE Emitente inválida (erro no dígito de controle)

Obs.: Antes da validação, a IE deverá ser normalizada, na aplicação da

SEFAZ, com o acréscimo de zeros não significativos previstos na definição

do formato da IE, se necessário.

Ex.: IE informada 130000019, formato da IE: NNNNNNNNNND, a IE deve

ser padronizada para 00130000019, com o acréscimo dos zeros não

significativos necessários para a validação do dígito verificador.

Obrig.

209 Rej.

G102 Acessar Cadastro Contribuinte p/ Emitente:

- CNPJ emitente não cadastrado Obrig.

245 Rej.

G103 - Emitente não credenciado Obrig.

203 Rej.

G104 - IE Emitente não cadastrada Facult.

230 Rej.

G105 - IE Emitente não vinculada ao CNPJ Obrig.

231 Rej.

G106 - IE emitente não autorizada a emitir CT-e para o modal de transporte

informado Obrig.

585 Rej.

G107 - Emitente em situação irregular perante o Fisco (tratar duplicidade na

inserção do CT-e, evitando a inserção de mais de um CT-e denegado) Obrig.

301

205

Den.

G108 Data/Hora de Emissão posterior à Data/Hora de Recebimento

(a SEFAZ Virtual deve considerar a hora local do emissor para a validação).

A SEFAZ deve tolerar uma diferença máxima de 5 minutos quando a

data/hora de emissão for maior que a data de recebimento, em função da

sincronização de horário de servidores.

Obrig.

212 Rej.

G109 Se tipo de emissão for diferente de FS-DA (tpEmis=5) ou EPEC

(tpEmiss=4):

Data de Emissão ocorrida há mais de 60 dias, ou outro limite conforme

critério definido pela SEFAZ (a SEFAZ Virtual deve considerar a hora local

do emissor para a validação)

Obrig.

228 Rej.

G110 CNPJ Remetente informado: CNPJ inválido (dígito de controle, zeros) Obrig.

415 Rej.

G111 CPF Remetente informado: CPF inválido (dígito de controle, zeros) Obrig.

416 Rej.

Conhecimento de Transporte

letrônico

Manual de Orientações – Contribuinte

Pág.

44 / 189

Validação

do CT

–

Regras de Negócio

Regra

de Validação

Aplic.

Msg

Efeito

G112 Remetente informado: Código Município inválido (dígito de controle), vide

item 2.1 do Anexo II. Facult.

417 Rej.

G113 Remetente informado: Município diverge da UF (verificar se as 2 posições

da esquerda do código de município que identifica o código da UF é

compatível com a sigla da UF informada)

Obrig.

418 Rej

G114 IE Remetente informado: IE inválida (erro no dígito de controle)

Obs.: Antes da validação, a IE deverá ser normalizada, na aplicação da

SEFAZ, com o acréscimo de zeros não significativos previstos na definição

do formato da IE se necessário.

Ex.: IE informada 130000019, formato da IE: NNNNNNNNNND, a IE deve

ser padronizada para 00130000019, com o acréscimo dos zeros não

significativos necessários para a validação do dígito verificador.

Obrig.

419 Rej..

G115 Se o Remetente informado for contribuinte do ICMS na UF autorizadora:

- Acessar Cadastro Contribuinte p/ Remetente:

. Se CNPJ Remetente informado: CNPJ não cadastrado

Facult.

420 Rej.

G116 . IE Remetente informada: IE não cadastrada Facult.

421 Rej.

G117 . IE e CNPJ Remetente informados: IE não vinculada ao CNPJ Facult.

422 Rej.

G118 CNPJ Destinatário informado: CNPJ inválido (dígito de controle, zeros) Obrig.

208 Rej.

G119 CPF Destinatário informado: CPF inválido (dígito de controle, zeros) Obrig.

237 Rej.

G120 Destinatário informado: Código Município inválido (dígito de controle), vide

item 2.1 do Anexo II. Facult.

423 Rej.

G121 Destinatário informado: Município diverge da UF (verificar se as 2 posições

da esquerda do código de município que identifica o código da UF estão de

acordo com a sigla da UF informada)

Obrig.

424 Rej.

G122 IE Destinatário informado: IE inválida (erro no dígito

de controle ou conteúdo

diferente de “ISENTO”)

Obs.: Antes da validação, a IE deverá ser normalizada, na aplicação da

SEFAZ, com o acréscimo de zeros não significativos previstos na definição

do formato da IE se necessário.

Ex.: IE informada 130000019, formato da IE: NNNNNNNNNND, a IE deve

ser padronizada para 00130000019, com o acréscimo dos zeros não

significativos necessários para a validação do dígito verificador.

Obrig.

210 Rej.

G123 Se o Destinatário informado for contribuinte do ICMS na UF autorizadora:

- Acessar Cadastro Contribuinte p/ Destinatário:

. Se CNPJ Destinatário informado: CNPJ não cadastrado

Facult.

425 Rej.

G124 . IE Destinatário informada: IE não cadastrada Facult.

426 Rej.

G125 . IE e CNPJ Destinatário informados: IE não vinculada ao CNPJ Facult.

427 Rej.

G126 CNPJ Expedidor informado: CNPJ inválido (dígito de controle, zeros) Obrig.

428 Rej.

G127 CPF Expedidor informado: CPF inválido (dígito de controle, zeros) Obrig.

429 Rej.

G128 Expedidor informado: Código Município inválido (dígito de controle), vide

item 2.1 do Anexo II. Facult.

430 Rej.

G129 Expedidor informado: Município diverge da UF (verificar se as 2 posições da

esquerda do código de município que identifica o código da UF estão de

acordo com a sigla da UF informada)

Obrig.

431 Rej.

G130 IE Expedidor informado: IE inválida (erro no dígito de controle)

Obs.: Antes da validação, a IE deverá ser normalizada, na aplicação da

SEFAZ, com o acréscimo de zeros não significativos previstos na definição

do formato da IE se necessário.

Ex.: IE informada 130000019, formato da IE: NNNNNNNNNND, a IE deve

ser padronizada para 00130000019, com o acréscimo dos zeros não

significativos necessários para a validação do dígito verificador.

Obrig.

432 Rej.

Conhecimento de Transporte

letrônico

Manual de Orientações – Contribuinte

Pág.

45 / 189

Validação

do CT

–

Regras de Negócio

Regra

de Validação

Aplic.

Msg

Efeito

G131 Se o Expedidor for contribuinte do ICMS na UF autorizadora:

- Acessar Cadastro Contribuinte p/ Expedidor:

. Se CNPJ Expedidor informado: CNPJ não cadastrado

Facult.

433 Rej.

G132 . IE Expedidor informada: IE não cadastrada Facult.

434 Rej.

G133 . IE e CNPJ Expedidor informados: IE não vinculada ao CNPJ Facult.

435 Rej.

G134 CNPJ Recebedor informado: CNPJ inválido (dígito de controle, zeros) Obrig.

436 Rej.

G135 CPF Recebedor informado: CPF inválido (dígito de controle, zeros) Obrig.

437 Rej.

G136 Recebedor informado: Código Município inválido (dígito de controle), vide

item 2.1 do Anexo II. Facult.

438 Rej.

G137 Recebedor informado: Município diverge da UF (verificar se as 2 posições

da esquerda do código de município que identifica o código da UF estão de

acordo com a sigla da UF informada)

Obrig.

439 Rej.

G138 IE Recebedor informado: IE inválida (erro no dígito de controle)

Obs.: Antes da validação, a IE deverá ser normalizada, na aplicação da

SEFAZ, com o acréscimo de zeros não significativos previstos na definição

do formato da IE se necessário.

Ex.: IE informada 130000019, formato da IE: NNNNNNNNNND, a IE deve

ser padronizada para 00130000019, com o acréscimo dos zeros não

significativos necessários para a validação do dígito verificador.

Obrig.

440 Rej.

G139 Se Recebedor informado for contribuinte do ICMS na UF autorizadora:

- Acessar Cadastro Contribuinte p/ Recebedor:

. Se CNPJ Recebedor informado: CNPJ não cadastrado

Facult.

441 Rej.

G140 . IE Recebedor informada: IE não cadastrada Facult.

442 Rej.

G141 . IE e CNPJ Recebedor informados: IE não vinculada ao CNPJ Facult.

443 Rej.

G142 CNPJ Tomador informado: CNPJ inválido (dígito de controle, zeros) Obrig.

444 Rej.

G143 CPF Tomador informado: CPF inválido (dígito de controle, zeros) Obrig.

445 Rej.

G144 Tomador informado: Código Município inválido (dígito de controle), vide

item 2.1 do Anexo II.

Facult.

446 Rej.

G145 Tomador informado: Município diverge da UF (verificar se as 2 posições da

esquerda do código de município que identifica o código da UF estão de

acordo com a sigla da UF informada)

Obrig.

447 Rej.

G146 IE Tomador informado: IE inválida (erro no dígito de controle)

Obs.: Antes da validação, a IE deverá ser normalizada, na aplicação da

SEFAZ, com o acréscimo de zeros não significativos previstos na definição

do formato da IE se necessário.

Ex.: IE informada 130000019, formato da IE: NNNNNNNNNND, a IE deve

ser padronizada para 00130000019, com o acréscimo dos zeros não

significativos necessários para a validação do dígito verificador.

Obrig.

448 Rej.

G147 Se o Tomador do serviço for contribuinte do ICMS na UF autorizadora:

- Acessar Cadastro Contribuinte p/ Tomador:

. Se CNPJ Tomador informado: CNPJ não cadastrado

Facult.

449 Rej.

G148 . IE Tomador informada: IE não cadastrada Facult.

489 Rej.

G149 . IE e CNPJ Tomador informados: IE não vinculada ao CNPJ Facult.

490 Rej.

G150 Inscr. SUFRAMA do Destinatário informada: verificar dígito controle Obrig.

235 Rej.

G151 Inscr. SUFRAMA informada: verificar UF destinatário = AC-Acre, ou AM-

Amazonas, ou RO-Rondônia, ou RR-Roraima, ou AP-Amapá (só para

municípios 1600303-Macapá e 1600600-Santana)

Obrig.

251 Rej.

Conhecimento de Transporte

letrônico

Manual de Orientações – Contribuinte

Pág.

46 / 189

Validação

do CT

–

Regras de Negócio

Regra

de Validação

Aplic.

Msg

Efeito

G152 Acesso BD CTE (Chave: CNPJ Emit, Modelo, Série, Nro):

- Duplicidade de CT-e com diferença na Chave de Acesso

(campo de Código Numérico difere)

Retornar a chave de acesso já autorizada e o número do recibo

[chCTe: 99999999999999999999999999999999999999999999]

[nRec:999999999999999]

Obrig 539 Rej.

G153 Acesso BD CTE (Chave: CNPJ Emit, Modelo, Série, Nro):

- Duplicidade de CT-e

Retornar o número do recibo

[nRec:999999999999999]

Obrig.

204 Rej.

G154 - Verificar se CT-e já está Cancelado

Retornar o número do recibo

[nRec:999999999999999]

. Obrig.

218 Rej.

G155 - Verificar se CT-e já está Denegado

Retornar o número do recibo

[nRec:999999999999999]

. Obrig.

205 Rej.

G156 Se Tipo de Emissão diferente de EPEC (tpEmis<>4):

Acesso BD CTE-Inutilização

- Verificar Número do CT-e Inutilizado

Obrig.

206 Rej.

G157 Se Tipo do CT-e = 1 (CT-e complementar): verificar se foi informado um CT-

e para ser complementado Obrig.

254 Rej.

G158 Se Tipo do CT-e = 1 (CT-e complementar): verificar se o Conhecimento

referenciado foi emitido pelo mesmo CNPJ. Obrig.

269 Rej.

G159 Se Tipo do CT-e = 1 (CT-e complementar): verificar se existe o CT-e

referenciado.

Acesso BD CTE (Chave: CNPJ Emit, Modelo, Série, Nro)

Obrig.

267 Rej.

G160 Se Tipo do CT-e = 1 (CT-e complementar): verificar se existe o CT-e

referenciado.

Acesso BD CTE (Chave: CNPJ Emit, Modelo, Série, Nro)

- CT-e referenciado com diferença na Chave de Acesso

Retornar a chave de acesso já autorizada e o número do recibo do CT-e

[chCTe: 99999999999999999999999999999999999999999999]

[nRec:999999999999999]

Obrig.

671 Rej.

G161 Se Tipo do CT-e = 1 (CT-e complementar): verificar se o CT-e referenciado

é do tipo CT-e Complementar.

Acesso BD CTE (Chave: CNPJ Emit, Modelo, Série, Nro)

Obrig;

491 Rej.

G162 Se Tipo do CT-e = 1 (CT-e complementar): verificar se o CT-e referenciado

está com Situação: Autorizado o Uso.

Acesso BD CTE (Chave: CNPJ Emit, Modelo, Série, Nro)

Obrig.

655 Rej.

G163 Se Tipo do CT-e= 1 (Complementar): verificar se o CT-e referenciado foi

Anulado. Obrig.

656 Rej.

G164 Se Tipo do CT-e= 1 (Complementar): verificar se o CT-e referenciado foi

Substituído. Obrig.

657 Rej.

G165 Código Município de envio do CT-e inválido (dígito de controle), vide item

2.1 do Anexo II. Obrig.

492 Rej.

G166 Município de envio do CT-e diverge da UF (verificar se as 2 posições da

esquerda do código de município que identifica o código da UF estão de

acordo com a sigla da UF informada)

Obrig.

493 Rej.

G167 Código Município de início da prestação inválido (dígito de controle), vide

item 2.1 do Anexo II.

Obrig.

455 Rej.

G168 Município de início da prestação diverge da UF (verificar se as 2 posições

da esquerda do código de município que identifica o código da UF estão de

acordo com a sigla da UF informada)

Obrig.

456 Rej.

G169 Código Município de término da prestação inválido (dígito de controle), vide

item 2.1 do Anexo II. Obrig.

413 Rej.

Conhecimento de Transporte

letrônico

Manual de Orientações – Contribuinte

Pág.

47 / 189

Validação

do CT

–

Regras de Negócio

Regra

de Validação

Aplic.

Msg

Efeito

G170 Município de término da prestação diverge da UF (verificar se as 2 posições

da esquerda do código de município que identifica o código da UF estão de

acordo com a sigla da UF informada)

Obrig.

414 Rej.

G171 Se forma de emissão do CT-e for diferente de 4 (EPEC):

Acessar BD CTe-EVENTOS (Chave:CNPJ Emit, Modelo, Série, Nro obtidos

na chave de acesso dos eventos registrados).

Verificar se existe EPEC para a chave natural do CT-e

OBS: Concatenar a chave de acesso do CT-e da EPEC na resposta

Obrig.

640 Rej.

G172 Se forma de emissão do CT-e for 4 (EPEC):

Acessar BD CTe-EVENTOS pela chave de acesso:

Verificar se existe Evento EPEC autorizado na SVC-[XX].

OBS: O processo de sincronização entre as SEFAZ poderá sofrer

algum atraso. Em caso de receb

er essa rejeição, a empresa emitente

deverá tentar a transmissão do CT-

e até que o EPEC esteja

sincronizado com a SEFAZ Autorizadora.

Obrig.

641 Rej.

G173 Se forma de emissão do CT-e for 4 (EPEC):

Valor de ICMS, Valor da Prestação e Valor Total da Carga do CT-e devem

ser iguais aos informados no evento prévio.

Obrig.

642 Rej.

G174 Se forma de emissão do CT-e for 4 (EPEC):

Tipo do Tomador do Serviço, CNPJ/CPF do Tomador e IE do tomador do

CT-e devem ser iguais aos informados no evento prévio.

Obrig.

643 Rej.

G175 Se forma de emissão do CT-e for 4 (EPEC):

Modal do CT-e deve ser igual ao informado no evento prévio. Obrig.

644 Rej.

G176 Se forma de emissão do CT-e for 4 (EPEC):

UF de início e UF de fim de prestação do CT-e devem ser iguais aos

informados no evento prévio.

Obrig.

645 Rej.

G177 Se forma de emissão do CT-e for 4 (EPEC):

Data de emissão do CT-e deve ser igual a data de autorização do evento

prévio

Obrig.

697 Rej.

G178 Se informada autorização download XML com CNPJ:

CNPJ com zeros ou dígito inválido Obrig.

699 Rej.

G179 Se informada autorização download do XML com CPF:

CPF com zeros, nulo, números repetidos (111,222,etc), ou dígito de controle

inválido

Obrig.

700 Rej.

Nota: No caso de envio de lote para a SEFAZ VIRTUAL, todos os CT-e do Lote deverão ser da

mesma UF. Para a SEFAZ VIRTUAL, deverá ser verificado se todos os CT-e são da mesma UF

do primeiro CT-e do Lote. Em caso negativo, rejeitar o Lote de CT-e com erro “408-REJEIÇÃO:

Lote com CT-e de diferentes UF”.

Nota: A critério da SEFAZ Autorizadora a mensagem de erro poderá receber um texto adicional

detalhando melhor a rejeição ou passando alguma instrução ao contribuinte, observando que

esta mensagem complementar deverá vir após a mensagem de rejeição do MOC, entre

colchetes, com o literal “Det:”

[Det: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX]

IMPORTANTE: A numeração autorizada para EPEC na SVC não deve ser inutilizada no

ambiente normal de autorização EM HIPÓTESE ALGUMA. O evento autorizado sempre será

compartilhado entre os ambientes, embora esse processo possa atrasar devido a problemas

operacionais. Solicitamos ao emitente que aguarde para autorizar o CT-e da EPEC caso ocorra

esse atraso.

Conhecimento de Transporte

letrônico

Manual de Orientações – Contribuinte

Pág.

48 / 189

IMPORTANTE: Orientamos o emitente que não tente autorizar a numeração utilizada em um

evento EPEC (autorizado na SVC) no ambiente normal (com tipo de emissão Normal). Essa

situação pode ocorrer em casos de atraso de sincronismo entre os ambientes e na prática

alocará a numeração da EPEC dificultando os processos de validação.

Final do Processamento do Lote

A validação do CT-e poderá resultar em:

• Rejeição – o CT-e será descartado, não sendo armazenado no Banco de Dados

podendo ser corrigido e novamente transmitido;

• Autorização de uso – o CT-e será armazenado no Banco de Dados;

• Denegação de uso – o CT-e será armazenado no Banco de Dados com esse status nos

casos de irregularidade fiscal do emitente.

Ou seja:

Validação

Conseq

ência

de forma

do CT-e da situação fiscal do Emitente Situação do CT-e Para o contribuinte

Banco

de Dados

Inválida Irrelevante Rejeição Corrigir CT-e Não gravar

Válida Irregular Denegação de uso A prestação não

poderá ser

realizada Gravar

Válida Regular Autorização de uso A prestação é

autorizada Gravar

Para cada CT-e autorizado ou denegado será atribuído um número de protocolo da Secretaria

de Fazenda (vide regra de formação no item 6.6).

O resultado do processamento do lote estará disponível na fila de saída e conterá o resultado da

validação de cada CT-e contido no lote.

O resultado do processamento do lote deve ficar disponível na fila de saída por um período

mínimo de 24 (vinte e quatro) horas.

Eventos de Marcação

Serão criados eventos de marcação de CT-e para os casos em que um documento referenciar

outro, por exemplo: Complemento de Valores, Substituição e Anulação.

Esses eventos serão gerados automaticamente pelo Fisco no momento da autorização dos

documentos e serão assinados digitalmente com certificado digital da Secretaria de Fazenda

autorizadora do CT-e que fará a marcação.

Os eventos gerados nos CT-e referenciados deverão constar da consulta pública destes

documentos.

Exemplo de como será o funcionamento das marcações:

1. CT-e de Numeração 001 do tipo Normal é autorizado na SEFAZ-XX.

2. CT-e de Numeração 002 do tipo Complemento de valores é autorizado na SEFAZ-XX,

referenciando o CT-e de Numeração 001.

3. A SEFAZ-XX gera, assina e autoriza um evento “CT-e complementar autorizado” para o CT-e

de Numeração 001.

Conhecimento de Transporte

letrônico

Manual de Orientações – Contribuinte

Pág.

49 / 189

** Esse evento deverá ser relacionado na consulta do CT-e de numeração 001.

Conhecimento de Transporte

letrônico

Manual de Orientações – Contribuinte

Pág.

50 / 189

4.2

Web Service – CteRetRecepcao

Contribuinte

Client CTe

Consulta Lote de CT-e

Consulta Processamento de Lote de CT-e

Retorno

Secretaria de Fazenda Estadual

Aplicação CT-e

Consulta

Processamento

Ret

Proc.

cteRetRecepcao

Web Service

CteRetRecepcao

Contribuinte

Client CTe

Consulta Lote de CT-e

Consulta Processamento de Lote de CT-e

Retorno

Secretaria de Fazenda Estadual

Aplicação CT-e

Consulta

Processamento

Ret

Proc.

cteRetRecepcao

Web Service

CteRetRecepcao

Função: serviço destinado a devolver o resultado do processamento do lote de CT-e.

Processo: assíncrono.

Método: cteRetRecepcao

Leiaute Mensagem de Entrada

Entrada: Estrutura XML contendo o número do recibo que identifica a mensagem de envio de

lotes de CT-e.

Schema XML: consReciCte_v99.99.xsd

# Campo Ele

Pai Tipo

Ocor.

Tam.

Dec.

Descrição/Observação

BP01

consReciCTe Raiz

- - - TAG raiz

BP02

versao A BP01

N 1-1 1-4 2 Versão do leiaute

BP03

tpAmb E BP01

N 1-1 1 Identificação do Ambiente:

1 – Produção / 2 – Homologação

BP04

nRec E BP01

N 1-1 15 Número do Recibo

Número gerado pelo Portal da Secretaria de

Fazenda Estadual, composto por: duas posições

com código da UF onde foi entregue o lote,

codificação de UF do IBGE, e treze posições

numéricas sequenciais.

Leiaute Mensagem de Retorno

Retorno: Estrutura XML com o resultado do processamento da mensagem de envio de lote de

CT-e.

Schema XML: retConsReciCte_v99.99.xsd

# Campo Ele

Pai Tipo

Ocor.

Tam.

Dec.

Descrição/Observação

BR01

retConsReciCTe Raiz

- - - - TAG raiz da Resposta

BR02

versao A BR01

N 1-1 1-4 2 Versão do leiaute

BR03

tpAmb E BR01

N 1-1 1 Identificação do Ambiente:

1 – Produção / 2 – Homologação

BR04

verAplic E BR01

C 1-1 1-20

Versão do Aplicativo que recebeu o Lote.

BR05

nRec E BR01

N 1-1 15 Número do Recibo consultado (vide item 5.5).

Conhecimento de Transporte

letrônico

Manual de Orientações – Contribuinte

Pág.

51 / 189

BR06

cStat E BR01

N 1-1 3 Código do status da resposta para o Lote (vide

item 5.1.1)

BR07

xMotivo E BR01

C 1-1 1-255

Descrição literal do status da resposta para o

Lote.

BR08

cUF E BR01

N 1-1 2 Código da UF que atendeu a solicitação.

Os protocolos são retornados para os lotes processados cStat = 104

BR09

protCTe* xml

BR01

- 0-50 -

Conjunto de resultado do processamento de cada

CT-e (vide leiaute abaixo).

Estas informações são retornadas apenas para o

código do status do lote = 104 (Lote processado)

Para cada Protocolo de um CT-e processado teremos o seguinte leiaute:

# Campo Ele

Pai Tipo

Ocor.

Tam.

Dec.

Descrição/Observação

PR01

protCTe Raiz

- - - - TAG raiz do Protocolo de recebimento do CT-e

PR02

versao A PR01

N 1-1 4 2 Versão do leiaute das informações de Protocolo.

PR03

infProt G PR01

- 1-1 - Informações do Protocolo de resposta.

TAG a ser assinada

PR04

Id ID PR03

C 0-1 - Identificador da TAG a ser assinada, somente

precisa ser informado se a UF assinar a resposta.

Em caso de assinatura da resposta pela SEFAZ

preencher o campo com o Nro do Protocolo,

precedido com o literal “ID”

PR05

tpAmb E PR03

N 1-1 1 Identificação do Ambiente:

1 – Produção / 2 – Homologação

PR06

verAplic E PR03

C 1-1 1-20

Versão do Aplicativo que recebeu o Lote.

PR07

chCTe E PR03

N 1-1 44 Chave de Acesso do CT-e composto por Código

da UF + AAMM da emissão + CNPJ do Emitente

+ Modelo, Série e Número do CT-e + Forma de

Emissão+ Código Numérico + DV.

PR08

dhRecbto E PR03

D 1-1 - Data e hora de processamento

Formato = AAAA-MM-DDTHH:MM:SS

Preenchido com data e hora da gravação do CT-

no Banco de Dados.

Em caso de Rejeição, com data e hora do

recebimento do Lote de CT-e enviado.

PR09

nProt E PR03

N 0-1 15 Número do Protocolo da CT-e (vide item 6.6).

PR10

digVal E PR03

C 0-1 28 Digest Value do CT-e processado

Utilizado para conferir a integridade do CT-e

original.

PR11

cStat E PR03

N 1-1 3 Código do status da resposta para o CT-e (vide

item 5.1.1).

PR12

xMotivo E PR03

C 1-1 1-255

Descrição literal do status da resposta para o CT-

PR13

Signature G PR01

xml 0-1 - Assinatura XML do grupo identificado pelo

atributo “ID”

A decisão de assinar a mensagem fica a critério

da UF interessada.

Descrição do Processo de Web Service

Este método oferece a consulta do resultado do processamento de um lote de CT-e.

O aplicativo do Contribuinte deve ser construído de forma a aguardar um tempo mínimo de 15

(quinze) segundos entre o envio do Lote de CT-e para processamento e a consulta do resultado

deste processamento, evitando a obtenção desnecessária do status de erro 105 – “Lote em

Processamento”.

Deverão ser realizadas as validações e procedimentos que seguem:

Conhecimento de Transporte

letrônico

Manual de Orientações – Contribuinte

Pág.

52 / 189

Validação do Certificado de Transmissão

Validação do Certificado Digital do Transmissor (protocolo SSL)

Regra de Validação

Crítica

Msg

Efeito

A01

Certificado de Transmissor Inválido:

- Certificado de Transmissor inexistente na mensagem

- Versão difere “3”

- Basic Constraint = true (não pode ser Certificado de AC)

- KeyUsage não define “Autenticação Cliente”

Obrig. 280 Rej.

A02

Validade do Certificado (data de início e data de fim) Obrig. 281 Rej.

A03

Verifica a Cadeia de Certificação:

- Certificado da AC emissora não cadastrado na SEFAZ

- Certificado de AC revogado

- Certificado não assinado pela AC emissora do Certificado

Obrig. 283 Rej.

A04

LCR do Certificado de Transmissor

- Falta o endereço da LCR (CRL DistributionPoint)

- LCR indisponível

- LCR inválida

Obrig. 286 Rej.

A05

Certificado do Transmissor revogado Obrig. 284 Rej.

A06

Certificado Raiz difere da “ICP-Brasil” Obrig. 285 Rej.

A07

Falta a extensão de CNPJ no Certificado (OtherName –

OID=2.16.76.1.3.3) Obrig. 282 Rej.

As validações de A01, A02, A03, A04 e A05 são realizadas pelo protocolo SSL e não precisam

ser implementadas. A validação A06 também pode ser realizada pelo protocolo SSL, mas pode

falhar se existirem outros certificados digitais de Autoridade Certificadora Raiz que não sejam

“ICP-BR” no repositório de certificados digitais do servidor de Web Service da SEFAZ.

Validação Inicial da Mensagem no Web Service

Validação Inicial da

Mensagem no Web Service

Regra de Validação

Aplic.

Msg

Efeito

B01

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

B02

XML de Dados Mal Formado Facult. 243 Rej.

B03

Verifica se o Serviço está Paralisado Momentaneamente Obrig. 108 Rej.

B04

Verifica se o Serviço está Paralisado sem Previsão Obrig. 109 Rej.

A mensagem será descartada se o tamanho exceder o limite previsto (500 kB). A aplicação do

contribuinte não poderá permitir a geração de mensagem com tamanho superior a 500 kB. Caso

isto ocorra, a conexão poderá ser interrompida sem mensagem de erro se o controle do tamanho

da mensagem for implementado por configurações do ambiente de rede da SEFAZ (ex.: controle

no firewall). No caso de controle de tamanho ter sido implementado por aplicativo, teremos a

devolução da mensagem de erro 214.

No momento do recebimento da mensagem no Web Service, a critério de cada unidade

federada, poderá ser verificado se o XML de dados está bem formado. Esta verificação é útil

para as UF que desejam armazenar o XML de dados em estrutura XML de banco de dados.

Conhecimento de Transporte

letrônico

Manual de Orientações – Contribuinte

Pág.

53 / 189

As unidades federadas que mantêm o Web Service disponível mesmo quando o serviço esteja

paralisado, deverão implementar as validações 108 e 109. Estas validações poderão ser

dispensadas caso o Web Service não fique disponível quando o serviço estiver paralisado.

Caso a SEFAZ Autorizadora trabalhe na modalidade de SEFAZ Virtual de Contingência (SVC),

sugere-se que esta mantenha uma tabela de UF atendidas indicando para cada uma se o

Ambiente de Autorização é Normal ou SVC, e ainda, o status de ativação da SVC para cada UF

e o prazo de encerramento desta modalidade.

Validação das Informações de Controle da Chamada ao Web Service

Validação das

nformações de

ontrole da

hamada ao Web Service

Regra de Validação

Aplic.

Msg

Efeito

C01

Elemento cteCabecMsg inexistente no SOAP Header Facult. 242 Rej.

C02

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

C03

Se Ambiente de Autorização Normal:

Verificar se a UF informada no cUF é atendida pelo WebService Obrig. 410 Rej.

C04

Se Ambiente de Autorização SVC:

Verificar se UF informada no campo cUF é atendida na SVC-[SP/RS]: Obrig. 513 Rej.

C05

Campo versaoDados inexistente no elemento cteCabecMsg do SOAP

Header Obrig. 411 Rej.

C06

Versão dos Dados informada é superior à versão vigente Facult. 238 Rej.

C07

Versão dos Dados não suportada Obrig. 239 Rej.

Os dados referentes à versão do leiaute do lote e à UF de origem do emissor dos conhecimentos

são informados no elemento cteCabecMsg do SOAP Header (para maiores detalhes vide item

3.4.1).

A aplicação deverá validar os campos cUF e versaoDados, rejeitando a mensagem recebida em

caso de informações inexistentes ou inválidas.

O cabeçalho compreende a versão do Schema XML da mensagem contida na área de dados

que será utilizado pelo Web Service.

Validação da Área de Dados

a) Validação da Forma da Área de Dados

alida

ção da Mensagem do Pedido de Consulta de Lote

Regra de Validação

Aplic.

Msg

Efeito

D01

Verifica Schema XML da Área de Dados Obrig. 215 Rej.

D02

Verifica a existência de qualquer namespace diverso do namespace

padrão do CT-e (http://www.portalfiscal.inf.br/cte) Facul. 598 Rej.

D03

Verifica a existência de caracteres de edição no início ou fim da

mensagem ou entre as tags Facul. 599 Rej.

D04

Verifica o uso de prefixo no namespace Obrig. 404 Rej.

D05

XML utiliza codificação diferente de UTF-8 Obrig. 402 Rej.

Conhecimento de Transporte

letrônico

Manual de Orientações – Contribuinte

Pág.

54 / 189

b) Validação das Regras de Negócio da Consulta Recibo

A seguir são realizadas as seguintes validações:

Valida

ção da Consulta Recibo

Regra de Validação

Aplic.

Msg

Efeito

E01

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

E02

UF do Recibo difere da UF Autorizadora Obrig. 248 Rej.

E03

Tipo Autorizador do Recibo não compatível com o Órgão Autorizador

(0 ou 1=SEFAZ normal, 3=SEFAZ VIRTUAL-RS,5=SEFAZ VIRTUAL-SP

7 = SVC-RS, 8 = SVC-SP)

Obrig. 473 Rej.

E04

- Verifica se o Lote não está na fila de saída, nem na fila de entrada Obrig. 106 Rej.

E05

- Verifica se o Lote não está na fila de resposta, mas está na fila de

entrada Obrig. 105 Rej.

E06

CNPJ do transmissor do lote difere do CNPJ do transmissor da consulta Obrig. 223 Rej.

Final do Processamento

A mensagem de retorno poderá ser:

• Lote processado – cStat=104, com os resultados individuais de processamento dos CT-

e do lote;

• Lote em processamento – cStat=105, o aplicativo do contribuinte deverá fazer uma

nova consulta;

• Lote não localizado – cStat=106, o aplicativo do contribuinte deverá providenciar o

reenvio da mensagem;

• Recibo ou CNPJ do requisitante com problemas – cStat= 248 ou 223, o aplicativo do

contribuinte deverá sanar o problema;

O Ambiente de Autorização SVC retornará apenas resultado de processamento dos lotes

enviados para a SVC, ou seja, caso um lote tenha sido enviado à SEFAZ original e logo após

esta tenha acionado a SVC, a consulta sobre este lote somente poderá ser direcionada á SEFAZ

original quando esta restabelecer seu serviço, já os lotes enviados para a SVC poderão ser

consultados diretamente neste ambiente a qualquer tempo, independente da SVC estar ativa

para recepção.

Conhecimento de Transporte

letrônico

Manual de Orientações – Contribuinte

Pág.

55 / 189

4.3

Web Service - CteInutilizacao

Inutilização de numeração de CT -e

Ret

Contribuinte

Client CTe

Secretaria de Fazenda Estadual

Aplicação CT -e

Inutilizacao

Inutilização de Numeração

Retorno

cteInutilizacaoCT

Web Service :

CteInutilizacao Proc.

Inutilização de numeração de CT -e

Ret

Contribuinte

Client CTe

Secretaria de Fazenda Estadual

Aplicação CT -e

Inutilizacao

Inutilização de Numeração

Retorno

cteInutilizacaoCT

Web Service :

CteInutilizacao Proc.

Função: serviço destinado ao atendimento de solicitações de inutilização de numeração de CT-

Processo: síncrono.

Método: cteInutilizacaoCT

Leiaute Mensagem de Entrada

Entrada: Estrutura XML contendo a mensagem de solicitação de inutilização.

Schema XML: inutCTe _v99.99.xsd

# Campo Ele

Pai Tipo

Ocor.

Tam.

Dec.

Descrição/Observação

DP01

inutCTe Raiz

- - - - TAG raiz

DP02

versao A DP01

N 1-1 1-4 2 Versão do leiaute

DP03

infInut G DP01

- 1-1 - Dados do Pedido

TAG a ser assinada

DP04

Id ID DP03

C 1-1 41 Identificador da TAG a ser assinada formada com

Código da UF + CNPJ + modelo + série + nro

inicial e nro final precedida do literal “ID”

DP05

tpAmb E DP03

N 1-1 1 Identificação do Ambiente:

1 – Produção / 2 - Homologação

DP06

xServ E DP03

C 1-1 10 Serviço solicitado: ‘INUTILIZAR’

DP07

cUF E DP03

N 1-1 2 Código da UF do solicitante

DP08

ano E DP03

N 1-1 2 Ano de inutilização da numeração

DP09

CNPJ E DP03

C 1-1 14 CNPJ do emitente

DP10

mod E DP03

N 1-1 2 Modelo do CT-e

DP11

serie E DP03

N 1-1 1-3 Série do CT -e

DP12

nCTIni E DP03

N 1-1 1-9 Número do CT -e inicial a ser inutilizado

DP13

nCTFin E DP03

N 1-1 1-9 Número do CT -e final a ser inutilizado

DP14

xJust E DP03

C 1-1 15-

255 Informar a justificativa do pedido de inutilização

DP15

Signature G DP01

xml 1-1 - Assinatura XML do grupo identificado pelo

atributo “ID”

Conhecimento de Transporte

letrônico

Manual de Orientações – Contribuinte

Pág.

56 / 189

Leiaute Mensagem de Retorno

Retorno: Estrutura XML contendo a mensagem do resultado da solicitação de inutilização:

Schema XML: retInutCte_v99.99.xsd

# Campo Ele

Pai Tipo

Ocor.

Tam.

Dec.

Descrição/Observação

DR01

retInutCTe Raiz

- - - - TAG raiz da Resposta

DR02

versao A DR01

N 1-1 1-4 2 Versão do leiaute

DR03

infInut G DR01

- 1-1 - Dados da resposta - TAG a ser assinada

DR04

Id ID DR03

C 0-1 17

Identificador da TAG a ser assinada. Informar

somente se a UF assinar a resposta.

Em caso de assinatura da resposta pela SEFAZ,

deve-se preencher o campo com o Nro do

Protocolo, precedido com o literal “ID”.

DR05

tpAmb E DR03

N 1-1 1 Identificação do Ambiente:

1 – Produção / 2 – Homologação

DR06

verAplic E DR03

C 1-1 1-20

Versão do Aplicativo que processou o pedido de

inutilização

DR07

cStat E DR03

N 1-1 3 Código do status da resposta (vide item 5.1.1)

DR08

xMotivo E DR03

C 1-1 1-255

Descrição literal do status da resposta

DR09

cUF E DR03

N 1-1 2 Código da UF que atendeu a solicitação

Os campos a seguir são obrigatórios no caso de homologação da inutilização cStat=102.

Os campos de dhRecbto e nProt não serão preenchidos em caso de erro

DR10

ano E DR03

N 0-1 2 Ano de inutilização da numeração

DR11

CNPJ E DR03

C 0-1 14 CNPJ do emitente

DR12

mod E DR03

N 0-1 2 Modelo do CT-e

DR13

serie E DR03

N 0-1 1-3 Série do CT-e

DR14

nCTIni E DR03

N 0-1 1-9 Número do CT-e inicial a ser inutilizada

DR15

nCTFin E DR03

N 0-1 1-9 Número do CT-e final a ser inutilizada

DR16

dhRecbto E DR03

D 0-1 - Data e hora de processamento

Formato = AAAA-MM-DDTHH:MM:SS

Preenchido com data e hora da gravação no

Banco de Dados em caso de Confirmação.

Em caso de Rejeição, com data e hora do

recebimento do Pedido.

DR17

nProt E DR03

N 0-1 15 Número do Protocolo de Inutilização (vide item

6.6).

O controle de numeração do Protocolo é único

para todos os serviços.

DR18

Signature G DR01

xml 0-1 - Assinatura XML do grupo identificado pelo

atributo “ID”

A decisão de assinar a mensagem fica a critério

da UF interessada.

Descrição do Processo de Web Service

Esse método responsabiliza-se por receber as solicitações referentes à inutilização de faixas de

numeração de Conhecimentos de Transportes eletrônicos. Ao receber a solicitação, a aplicação

CT-e realiza o processamento e devolve o resultado para o aplicativo do transmissor.

A mensagem de pedido de inutilização de numeração de CT-e é um documento eletrônico

assinado digitalmente pelo emitente do CT-e.

As validações e os procedimentos abaixo são obrigatórios.

Conhecimento de Transporte

letrônico

Manual de Orientações – Contribuinte

Pág.

57 / 189

Validação do Certificado de Transmissão

Validação do Certificado Digital do Transmissor (protocolo SSL)

Regra de Validação

Crítica

Msg

Efeito

A01

Certificado de Transmissor Inválido:

- Certificado de Transmissor inexistente na mensagem

- Versão difere "3"

- Basic Constraint = true (não pode ser Certificado de AC)

- KeyUsage não define "Autenticação Cliente"

Obrig. 280 Rej.

A02

Validade do Certificado (data de início e data de fim) Obrig. 281 Rej.

A03

Verifica a Cadeia de Certificação:

- Certificado da AC emissora não cadastrado na SEFAZ

- Certificado de AC revogado

- Certificado não assinado pela AC emissora do Certificado

Obrig. 283 Rej.

A04

LCR do Certificado de Transmissor

- Falta o endereço da LCR (CRL DistributionPoint)

- LCR indisponível

- LCR inválida

Obrig. 286 Rej.

A05

Certificado do Transmissor revogado Obrig. 284 Rej.

A06

Certificado Raiz difere da "ICP-Brasil" Obrig. 285 Rej.

A07

Falta a extensão de CNPJ no Certificado (OtherName -

OID=2.16.76.1.3.3) Obrig. 282 Rej.

As validações de A01, A02, A03, A04 e A05 serão realizadas pelo protocolo SSL e não precisam

ser implementadas. A validação A06 também pode ser realizada pelo protocolo SSL, mas pode

falhar se existirem outros certificados digitais de Autoridade Certificadora Raiz que não sejam

“ICP-BR” no repositório de certificados digitais do servidor de Web Service da SEFAZ

Autorizadora.

Validação Inicial da Mensagem no Web Service

Validação Inicial da

Mensagem no Web Service

Regra de Validação

Aplic.

Msg

Efeito

B01

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

B02

XML de Dados Mal Formado Facult. 243 Rej.

B03

Verifica se o Serviço está Paralisado Momentaneamente Obrig. 108 Rej.

B04

Verifica se o Serviço está Paralisado sem Previsão Obrig. 109 Rej.

A mensagem será descartada se o tamanho exceder o limite previsto (500 KB). A aplicação do

contribuinte não poderá permitir a geração de mensagem com tamanho superior a 500 KB. Caso

isto ocorra, a conexão poderá ser interrompida sem mensagem de erro se o controle do tamanho

da mensagem for implementado por configurações do ambiente de rede da SEFAZ Autorizadora

(ex.: controle no firewall). No caso de controle de tamanho ter sido implementado por aplicativo,

teremos a devolução da mensagem de erro 214.

No momento do recebimento da mensagem no Web Service, a critério de cada unidade federada

autorizadora, poderá ser verificado se o XML de dados esteja bem formado. Esta verificação é

útil para as UF que desejam armazenar o XML de dados em estrutura XML de banco de dados.

Conhecimento de Transporte

letrônico

Manual de Orientações – Contribuinte

Pág.

58 / 189

As unidades federadas que mantêm o Web Service disponível mesmo quando o serviço esteja

paralisado, deverão implementar as validações 108 e 109. Estas validações poderão ser

dispensadas caso o Web Service não fique disponível quando o serviço estiver paralisado.

Caso a SEFAZ Autorizadora trabalhe na modalidade de SEFAZ Virtual de Contingência (SVC),

sugere-se que esta mantenha uma tabela de UF atendidas indicando para cada uma se o

Ambiente de Autorização é Normal ou SVC, e ainda, o status de ativação da SVC para cada UF

e o prazo de encerramento desta modalidade.

Importante: O serviço de inutilização não está disponível para a SEFAZ Virtual de Contingência.

Validação das Informações de Controle da Chamada ao Web Service

Validação das

nformações de

ontrole da

hamada ao Web Service

Regra de Validação

Aplic.

Msg

Efeito

C01

Elemento cteCabecMsg inexistente no SOAP Header Facult. 242 Rej.

C02

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

C03

Se Ambiente de Autorização Normal:

Verificar se a UF informada no cUF é atendida pelo WebService Obrig. 410 Rej.

C04

Se Ambiente de Autorização SVC:

- Serviço não disponível na SVC Obrig. 518 Rej.

C05

Campo versaoDados i

nexistente no elemento cteCabecMsg do SOAP

Header Obrig. 411 Rej.

C06

Versão dos Dados informada é superior à versão vigente Facult. 238 Rej.

C07

Versão dos Dados não suportada Obrig. 239 Rej.

A informação da versão do leiaute do lote e a UF de origem do emissor dos conhecimentos são

informadas no elemento cteCabecMsg do SOAP Header (para maiores detalhes vide item 3.4.1).

A aplicação validará os campos cUF e versaoDados, rejeitando a mensagem recebida em caso

de informações inexistentes ou inválidas.

O cabeçalho contém a versão do Schema XML da mensagem contida na área de dados utilizada

pelo Web Service.

Validação da Área de Dados

a) Validação da Forma da Área de Dados

Validação da Mensagem do Pedido de Inutilização de numeração

de CT

Regra

de Validação

Aplic.

Msg

Efeito

D01

Verifica Schema XML da Área de Dados Obrig. 215 Rej.

D02

Verifica a existência de qualquer namespace diverso do namespace

padrão do CT-e (http://www.portalfiscal.inf.br/cte) Facul. 598 Rej.

D03

Verifica a existência de caracteres de edição no início ou fim da

mensagem ou entre as tags Facul. 599 Rej.

D04

Verifica o uso de prefixo no namespace Obrig. 404 Rej.

D05

XML utiliza codificação diferente de UTF-8 Obrig. 402 Rej.

Conhecimento de Transporte

letrônico

Manual de Orientações – Contribuinte

Pág.

59 / 189

b) Validação do Certificado Digital Utilizado na Assinatura

Validação do Certificado Digital

tilizado na Assinatura Digital

Regra de Validação

Aplic.

Msg

Efeito

E01

Certificado de Assinatura inválido:

- Certificado de Assinatura inexistente na mensagem (*validado também

pelo Schema)

- Versão difere "3"

- Basic Constraints = true (não pode ser Certificado de AC)

- KeyUsage não define "Assinatura Digital" e “Não Recusa”

Obrig. 290 Rej.

E02

Validade do Certificado (data de início e data de fim) Obrig. 291 Rej.

E03

Falta a extensão de CNPJ no Certificado (OtherName -

OID=2.16.76.1.3.3) Obrig. 292 Rej.

E04

Verifica Cadeia de Certificação:

- Certificado da AC emissora não cadastrado na SEFAZ

- Certificado de AC revogado

- Certificado não assinado pela AC emissora do Certificado

Obrig. 293 Rej.

E05

LCR do Certificado de Assinatura:

- Falta o endereço da LCR (CRLDistributionPoint)

- Erro no acesso a LCR

Obrig. 296 Rej.

E06

Certificado de Assinatura revogado Obrig. 294 Rej.

E07

Certificado Raiz difere da “ICP-Brasil” Obrig. 295 Rej.

c) Validação da

Assinatura Digital

Validação da Assinatura Digital

Regra de Validação

Aplic.

Msg

Efeito

F01

Assinatura difere do padrão do Projeto:

- Não assinado o atributo "ID" (falta "Reference URI" na assinatura)

(*validado também pelo Schema)

- Faltam os "Transform Algorithm" previstos na assinatura ("C14N" e

"Enveloped")

Estas validações são implementadas pelo Schema XML da Signature

Obrig. 298 Rej.

F02

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

F03

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

d) Validação das Regras de Negócio da Inutilização de Numeração de CT-e

Pedido de Inutilização de

umeração

de CT

–

Regras de Negócios

Regra de Validação

Aplic.

Msg

Efeito

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

I02 UF do Pedido de inutilização difere da UF Autorizadora Obrig. 250 Rej

I03 Verificar se a serie informada está na faixa entre 890-899 (reservada) Obrig. 670 Rej.

I04 Ano da Inutilização não pode ser superior ao Ano atual Obrig. 471 Rej.

I05 Ano da inutilização não pode ser inferior a 2008 Obrig. 472 Rej.

I06 Número da Faixa Inicial maior do que o número Final Obrig. 224 Rej

I07 Quantidade máxima de numeração a inutilizar ultrapassa o limite (10.000

números) Obrig. 201 Rej

Conhecimento de Transporte

letrônico

Manual de Orientações – Contribuinte

Pág.

60 / 189

I08 Campo ID inválido

- Falta literal “ID”

- Chave de acesso do campo ID difere do campo correspondente

Obrig 227 Rej.

I09 Acesso Cadastro Contribuinte:

- Verificar Emitente não autorizado a emitir CT-e Obrig. 203 Rej

I10 - Verificar Situação Fiscal irregular do Emitente Obrig. 240 Rej

I11 Acesso BD CTE-Inutilização (Chave: CNPJ Emit, Modelo, Série, nCTIni,

nCTFim)::

- Verificar se existe um pedido de inutilização igual.

Obrig. 682 Rej.

I12 Acesso BD CTE-Inutilização:

- Verificar se algum Nro da Faixa de Inutilização atual pertence a uma

faixa anterior

Obrig. 256 Rej

I13 Acesso BD CTE (Chave: CNPJ Emit, Modelo, Série, Nro):

- Verificar se existe CT-e utilizada na faixa de inutilização solicitada Obrig. 241 Rej

I14 Acessar BD CTE-EVENTOS (Chave: CNPJ Emit, Modelo, Série, Nro –

obtidos na chave de acesso):

- Verificar se existe EPEC aguardando CT-e nessa faixa de numeração

Obrig. 696 Rej.

Para cada inutilização de numeração de CT-e homologada cria-se um novo protocolo de status

para CT-e, com a atribuição de um número de protocolo único (vide item 6.6).

Final do Processamento

No caso de homologação da Inutilização retornar o cStat = 102.

Conhecimento de Transporte

letrônico

Manual de Orientações – Contribuinte

Pág.

61 / 189

4.4

Web Service – CteConsulta Protocolo

Consulta situação atual da CT -e

Ret

Contribuinte

Client CTe

Secretaria de Fazenda Estadual

Aplicação CT -e

Consulta CT -e

Retorno

cteConsultaCT

Web Service :

CteConsulta Proc.

Consulta situação atual da CT -e

Ret

Contribuinte

Client CTe

Secretaria de Fazenda Estadual

Aplicação CT -e

Consulta CT -e

Retorno

cteConsultaCT

Web Service :

CteConsulta Proc.

Função: serviço destinado ao atendimento de solicitações de consulta da situação atual do CT-e

na Base de Dados do Portal da Secretaria de Fazenda Estadual.

Processo: síncrono.

Método: cteConsultaCT

Leiaute Mensagem de Entrada

Entrada: Estrutura XML contendo a chave de acesso do CT-e.

Schema XML: consSitCte_v99.99.xsd

# Campo Ele

Pai Tipo

Ocor.

Tam.

Dec.

Descrição/Observação

EP01

consSitCTe Raiz

- - - - TAG raiz

EP02

versao A EP01

N 1-1 1-4 2 Versão do leiaute

EP03

tpAmb E EP01

N 1-1 1 Identificação do Ambiente:

1 – Produção / 2 - Homologação

EP04

xServ E EP01

C 1-1 9 Serviço solicitado

‘CONSULTAR’

EP05

chCTe E EP01

N 1-1 44 Chave de Acesso do CT-e composto por Código

da UF + AAMM da emissão + CNPJ do Emitente

+ Modelo, Série e Número do CT-e + Forma de

Emissão + Código Numérico + DV.

Leiaute Mensagem de Retorno

Retorno: Estrutura XML contendo a mensagem do resultado da consulta de protocolo:

Schema XML: retConsSitCte_v99.99.xsd

# Campo Ele

Pai Tipo

Ocor.

Tam.

Dec.

Descrição/Observação

ER01

retConsSitCTe Raiz

- - - - TAG raiz da Resposta

ER02

versao A ER01

N 1-1 1-4 2 Versão do leiaute

ER03

tpAmb E ER01

N 1-1 1 Identificação do Ambiente:

Conhecimento de Transporte

letrônico

Manual de Orientações – Contribuinte

Pág.

62 / 189

1 – Produção / 2 – Homologação

ER04

verAplic E ER01

C 1-1 1-20

Versão do Aplicativo que processou a consulta

ER05

cStat E ER01

N 1-1 3 Código do status da resposta

ER06

xMotivo E ER01

C 1-1 1-255

Descrição literal do status da resposta

ER07

cUF E ER01

N 1-1 2 Código da UF que atendeu a solicitação

ER08

protCTe CG

ER01

xml 0-1 - Protocolo de autorização ou denegação de uso

do CT-e (vide item 4.2.2).

Informar se localizado um CT-e com cStat = 100

(uso autorizado) ou 110 (uso denegado).

ER09

retCancCTe CG

ER01

xml 0-1 - Protocolo de homologação de cancelamento de

CT-e (vide item 4.3.2).

Informar se localizado um CT-e com cStat = 101

(cancelado).

ER10

procEventoCTe G ER01

xml 0-N -

Informação do evento e respectivo Protocolo

de registro de Evento

Descrição do Processo de Web Service

Esse método responsabiliza-se por receber as solicitações referentes à consulta de situação de

Conhecimentos de Transporte eletrônicos enviados para as Secretarias de Fazendas Estaduais.

Permite-se o acesso somente pela chave única de identificação do CT-e.

O aplicativo do contribuinte envia a solicitação para o Web Service da Secretaria de Fazenda

Estadual autorizadora. Ao receber a solicitação, a aplicação do Portal da Secretaria de Fazenda

Estadual processará a solicitação de consulta, validando a Chave de Acesso do CT-e. Em

seguida retornará uma mensagem contendo a situação atual do CT-e na Base de Dados e o

respectivo Protocolo (mensagem de Autorização de uso, Denegação e os eventos que estiverem

associados ao CT-e (informações do evento e protocolo de registro de evento).

As validações e os procedimentos abaixo são obrigatórios.

Validação do Certificado de Transmissão

Validação do Certificado Digital do Transmissor (protocolo SSL)

Regra de Validação

Crítica

Msg

Efeito

A01

Certificado de Transmissor Inválido:

- Certificado de Transmissor inexistente na mensagem

- Versão difere "3"

- Basic Constraint = true (não pode ser Certificado de AC)

- KeyUsage não define "Autenticação Cliente"

Obrig. 280 Rej.

A02

Validade do Certificado (data de início e data de fim) Obrig. 281 Rej.

A03

Verifica a Cadeia de Certificação:

- Certificado da AC emissora não cadastrado na SEFAZ

- Certificado de AC revogado

- Certificado não assinado pela AC emissora do Certificado

Obrig. 283 Rej.

A04

LCR do Certificado de Transmissor

- Falta o endereço da LCR (CRL DistributionPoint)

- LCR indisponível

- LCR inválida

Obrig. 286 Rej.

A05

Certificado do Transmissor revogado Obrig. 284 Rej.

A06

Certificado Raiz difere da "ICP-Brasil" Obrig. 285 Rej.

A07

Falta a extensão de CNPJ no Certificado (OtherName -

OID=2.16.76.1.3.3) Obrig. 282 Rej.

Conhecimento de Transporte

letrônico

Manual de Orientações – Contribuinte

Pág.

63 / 189

As validações de A01, A02, A03, A04 e A05 serão realizadas pelo protocolo SSL e não precisam

ser implementadas. A validação A06 também pode ser realizada pelo protocolo SSL, mas pode

falhar se existirem outros certificados digitais de Autoridade Certificadora Raiz que não sejam

“ICP-BR” no repositório de certificados digitais do servidor de Web Service da SEFAZ

autorizadora.