Manual de Cte 3 para leituras e interpretação de tags, Manuais, Projetos, Pesquisas de Legislação Tributária

Baixe Manual de Cte 3 para leituras e interpretação de tags e outras Manuais, Projetos, Pesquisas em PDF para Legislação Tributária, somente na Docsity! Conhecimento de Transporte Eletrônico MOC CT-e 3.00 Pág. 1 / 231 Projeto Conhecimento de Transporte Eletrônico Manual de Orientações do Contribuinte Padrões Técnicos de Comunicação Versão 3.00 Julho/2016 Conhecimento de Transporte eletrônico MOC CT-e 3.00 Pág. 2 / 231 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) 2.00a 10/2013 – RS 2.00a 01/2014 – RS 3.00 07/2016 – RS Conhecimento de Transporte eletrônico MOC CT-e 3.00 Pág. 5 / 231 Eventos de Marcação .................................................................................................. 60 4.2 Serviço de Recepção de CT-e Outros Serviços (Modelo 67) ................................ 61 Web Service – CteRecepcaoOS .................................................................................. 61 Leiaute Mensagem de Entrada .................................................................................... 61 Leiaute Mensagem de Retorno .................................................................................... 61 Validação do Certificado de Transmissão .................................................................... 62 Validação Inicial da Mensagem no Web Service .......................................................... 62 Validação das Informações de Controle da Chamada ao Web Service ........................ 63 Descrição do Processamento do CT-e Outros Serviços ............................................... 63 Validação da Área de Dados ........................................................................................ 63 Final do Processamento do Lote .................................................................................. 73 4.3 Web Service – CteRetRecepcao .......................................................................... 74 Leiaute Mensagem de Entrada .................................................................................... 74 Leiaute Mensagem de Retorno .................................................................................... 74 Descrição do Processo de Web Service ...................................................................... 75 Validação do Certificado de Transmissão .................................................................... 76 Validação Inicial da Mensagem no Web Service .......................................................... 76 Validação das Informações de Controle da Chamada ao Web Service ........................ 77 Validação da Área de Dados ........................................................................................ 77 Final do Processamento............................................................................................... 78 4.4 Web Service - CteInutilizacao ............................................................................... 79 Leiaute Mensagem de Entrada .................................................................................... 79 Leiaute Mensagem de Retorno .................................................................................... 80 Descrição do Processo de Web Service ...................................................................... 80 Validação do Certificado de Transmissão .................................................................... 81 Validação Inicial da Mensagem no Web Service .......................................................... 81 Validação das Informações de Controle da Chamada ao Web Service ........................ 82 Validação da Área de Dados ........................................................................................ 82 Final do Processamento............................................................................................... 84 4.5 Web Service – CteConsulta Protocolo .................................................................. 85 Leiaute Mensagem de Entrada .................................................................................... 85 Leiaute Mensagem de Retorno .................................................................................... 85 Descrição do Processo de Web Service ...................................................................... 86 Validação do Certificado de Transmissão .................................................................... 86 Validação Inicial da Mensagem no Web Service .......................................................... 87 Validação das Informações de Controle da Chamada ao Web Service ........................ 88 Validação da Área de Dados ........................................................................................ 88 Final do Processamento............................................................................................... 89 4.6 Web Service – CteStatusServico .......................................................................... 90 Leiaute Mensagem de Entrada .................................................................................... 90 Leiaute Mensagem de Retorno .................................................................................... 90 Descrição do Processo de Web Service ...................................................................... 91 Validação do Certificado de Transmissão .................................................................... 91 Validação Inicial da Mensagem no Web Service .......................................................... 92 Validação das Informações de Controle da Chamada ao Web Service ........................ 92 Validação da Área de Dados ........................................................................................ 93 Final do Processamento............................................................................................... 93 4.7 Web Service – CadConsultaCadastro .................................................................. 94 Descrição do Processo de Web Service ...................................................................... 94 Onde Obter as Definições deste Web Service ............................................................. 95 Onde Obter os Schemas XML deste Web Service ....................................................... 95 4.8 Sistema de Registro de Eventos........................................................................... 96 Leiaute Mensagem de Entrada .................................................................................... 96 Diagrama Simplificado do Schema: eventoCTe_v9.99.xsd .......................................... 97 Leiaute Mensagem de Retorno .................................................................................... 97 Conhecimento de Transporte eletrônico MOC CT-e 3.00 Pág. 6 / 231 Diagrama Simplificado Schema de retorno: retEventoCTe _v99.99.xsd ....................... 98 Descrição do Processo de Web Service ...................................................................... 99 Validação do Certificado de Transmissão .................................................................... 99 Validação Inicial da Mensagem no Web Service .......................................................... 99 Validação das informações de controle da chamada ao Web Service........................ 100 Validação da Área de Dados ...................................................................................... 101 Processamento das validações específicas do evento ............................................... 103 Final do Processamento do Evento ............................................................................ 103 5. Sistema de Registro de Eventos (Parte Específica) ....................................... 104 5.1 Evento Prévio de Emissão em Contingência (EPEC) ......................................... 104 Leiaute Mensagem do evento EPEC.......................................................................... 104 Diagrama Simplificado do Evento EPEC .................................................................... 105 Regras de Validação Específicas ............................................................................... 105 Final do Processamento............................................................................................. 106 5.2 Evento de Cancelamento ................................................................................... 107 Leiaute Mensagem do evento de Cancelamento ....................................................... 107 Diagrama Simplificado do Evento de Cancelamento .................................................. 107 Regras de Validação Específicas ............................................................................... 107 Final do Processamento............................................................................................. 108 5.3 Evento Registro do Multimodal ........................................................................... 109 Leiaute Mensagem do evento .................................................................................... 109 Diagrama Simplificado do Evento .............................................................................. 109 Regras de Validação Específicas ............................................................................... 110 Final do Processamento............................................................................................. 110 5.4 Evento Carta de Correção .................................................................................. 111 Leiaute Mensagem do evento Carta de Correção ...................................................... 111 Diagrama Simplificado do Evento Carta de Correção ................................................ 112 Regras de Validação Específicas ............................................................................... 113 Final do Processamento............................................................................................. 113 5.5 Evento Prestação de Serviço em Desacordo ..................................................... 114 Leiaute Mensagem do evento .................................................................................... 114 Diagrama Simplificado do Evento .............................................................................. 114 Regras de Validação Específicas ............................................................................... 115 Final do Processamento............................................................................................. 115 5.6 Evento Informações da GTV .............................................................................. 116 Leiaute Mensagem do evento .................................................................................... 116 Diagrama Simplificado do Evento .............................................................................. 117 Regras de Validação Específicas ............................................................................... 118 Final do Processamento............................................................................................. 118 6. Web Services – Informações Adicionais ........................................................ 119 6.1 Regras de validação ........................................................................................... 119 Tabela de Códigos de Erros e Descrições de Mensagens de Erros ........................... 119 6.2 Padrão de Nomes para os Arquivos ................................................................... 130 6.3 Tratamento de Caracteres Especiais no Texto de XML ...................................... 131 6.4 Chave de Acesso do CT-e ................................................................................. 131 6.5 Número do Recibo de Lote ................................................................................. 132 6.6 Número do Protocolo .......................................................................................... 133 6.7 Tempo Médio de Resposta ................................................................................. 133 7. Código de Barra ............................................................................................ 134 7.1 Código de Barras Adicional ................................................................................ 135 7.2 Cálculo do Dígito Verificador do CODE-128C..................................................... 136 7.3 Representação Simbólica do Código .................................................................. 136 8. DACTE .......................................................................................................... 137 9. Contingência ................................................................................................. 138 10. Ambiente de Homologação / Produção ......................................................... 139 Conhecimento de Transporte eletrônico MOC CT-e 3.00 Pág. 7 / 231 11. Distribuição do CT-e para o Tomador do Serviço .......................................... 140 11.1 Processo de Distribuição .................................................................................... 140 11.2 Leiaute da Distribuição: CT-e ............................................................................. 140 12. Compartilhamento de Informações do CT-e entre Órgãos Públicos .............. 141 12.1 Processo de Compartilhamento ......................................................................... 141 12.2 Leiaute de Compartilhamento: CT-e .................................................................. 142 12.3 Leiaute de Compartilhamento: Inutilização de Numeração de CT-e .................. 142 12.4 Leiaute de compartilhamento: Registro de Evento de CT-e ................................ 142 12.5 Compartilhamento de Documentos com Outros Órgãos Públicos ...................... 142 Anexo I – Leiaute do CT-e ................................................................................................. 143 CT-e – Diagrama Simplificado – parte genérica ............................................................. 146 CT-e OS – Diagrama Simplificado – parte genérica ....................................................... 147 CT-e – Diagrama Simplificado – Rodoviário ................................................................... 148 CT-e – Diagrama Simplificado – Rodoviário Outros Serviços......................................... 148 CT-e – Diagrama Simplificado – Aéreo .......................................................................... 149 CT-e – Diagrama Simplificado – Aquaviário ................................................................... 150 CT-e – Diagrama Simplificado – Ferroviário ................................................................... 151 CT-e – Diagrama Simplificado – Dutoviário .................................................................... 152 CT-e – Diagrama Simplificado – Multimodal .................................................................. 152 Leiaute CT-e – Estrutura Genérica................................................................................. 153 Leiaute CT-e OS – Estrutura Genérica .......................................................................... 179 Leiaute – Rodoviário ...................................................................................................... 189 Leiaute – Rodoviário OS ................................................................................................ 190 Leiaute – Aéreo.............................................................................................................. 191 Leiaute – Aquaviário ...................................................................................................... 195 Leiaute – Ferroviário ...................................................................................................... 197 Leiaute – Dutoviário ....................................................................................................... 199 Leiaute – Multimodal ...................................................................................................... 199 Anexo II –– Tabelas de UF, Município e País .................................................................... 205 1. Tabela de Código de UF do IBGE ................................................................. 205 2. Tabela de Código de Município do IBGE ....................................................... 205 2.1 Validação do Código de Município ..................................................................... 206 3. Tabela de Código de País do BACEN ........................................................... 207 3.1 Validação do Código de País ............................................................................. 207 Anexo III – WS disponíveis ................................................................................................ 208 Anexo IV – Conjunto de Caracteres Código de Barras CODE-128C .................................. 209 Anexo V – Projeto Piloto do CT-e ...................................................................................... 210 Anexo VI – Manual de Contingência .................................................................................. 212 Anexo VII – Campos Impedidos de Alteração por CC-e ..................................................... 225 Anexo VIII – Relação de CFOP válidos para CT-e (Mod. 57) ............................................. 227 Anexo IX – Relação de CFOP válidos para CT-e OS (Mod. 67) ........................................ 230 Conhecimento de Transporte eletrônico MOC CT-e 3.00 Pág. 10 / 231 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 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 podem ocorrer após a autorização de uso, como o registro de um cancelamento, ou de forma prévia, que é o caso da forma de contingência EPEC. 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 eletrônico MOC CT-e 3.00 Pág. 11 / 231 3. 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 (Modelo 57); 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 f) Recepção do CT-e Outros Serviços (Modelo 67) 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 eletrônico MOC CT-e 3.00 Pág. 12 / 231 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"?> <enviCTe xmlns="http://www.portalfiscal.inf.br/cte" versao="2.00"> <idLote>200602220000001</idLote> <CTe xmlns="http://www.portalfiscal.inf.br/cte"> <infCte Id="CTe41100600242640000108570000000446060832911308" versao="2.00"> ... <Signature xmlns="http://www.w3.org/2000/09/xmldsig#"> … </CTe> <CTe xmlns="http://www.portalfiscal.inf.br/cte"> <infCte Id="CTe41100600242640000108570000000446060832911308" versao="2.00"> ... <Signature xmlns="http://www.w3.org/2000/09/xmldsig#"> … </CTe> </enviCTe> <?xml version="1.0" encoding="UTF-8"?> <enviCTe xmlns="http://www.portalfiscal.inf.br/cte" versao="2.00"> <idLote>200602220000001</idLote> Conhecimento de Transporte eletrônico MOC CT-e 3.00 Pág. 15 / 231 </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: <X509SubjectName> <X509IssuerSerial> <X509IssuerName> <X509SerialNumber> <X509SKI> Deve-se evitar o uso das TAGs relacionadas a seguir, pois as informações serão obtidas a partir do Certificado do emitente: <KeyValue> <RSAKeyValue> <Modulus> <Exponent> Conhecimento de Transporte eletrônico MOC CT-e 3.00 Pág. 16 / 231 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. Segue um exemplo: <CTe xmlns="http://www.portalfiscal.inf.br/cte" > <infCTe Id="CTe31060243816719000108650000000010001234567897" versao="2.00"> ... </infCTe> <Signature xmlns="http://www.w3.org/2000/09/xmldsig#"> <SignedInfo> <CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/> <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" /> <Reference URI="#CTe31060243816719000108650000000010001234567897"> <Transforms> <Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/> <Transform Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/> </Transforms> <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> <DigestValue>vFL68WETQ+mvj1aJAMDx+oVi928=</DigestValue> Conhecimento de Transporte eletrônico MOC CT-e 3.00 Pág. 17 / 231 </Reference> </SignedInfo> <SignatureValue>IhXNhbdL1F9UGb2ydVc5v/gTB/y6r0KIFaf5evUi1i ...</SignatureValue> <KeyInfo> <X509Data> <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; (6) Adotar as regras definidas pelo RFC 3280 para LCRs e cadeia de confiança; (7) Validar a integridade de todas as LCRs 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. Conhecimento de Transporte eletrônico MOC CT-e 3.00 Pág. 20 / 231 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; (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. Conhecimento de Transporte eletrônico MOC CT-e 3.00 Pág. 21 / 231 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 mensagens; • 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. 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. 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 eletrônico MOC CT-e 3.00 Pág. 22 / 231 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). Serviços Compartilhados – Modelo 57 e Modelo 67 A versão 3.00 do CT-e apresenta a possibilidade de autorização de Conhecimentos de Transporte relacionados a outros tipos de serviços de transporte, tais como pessoas, valores e excesso de bagagem, através do modelo 67. Nesse sentido será construído um webservice dedicado à autorização síncrona desse novo CT-e através de um layout específico e regras de validação próprias. Esse novo Webservice de Recepção CT-e Outros Serviços estará especificado neste manual, e o novo documento modelo 67 terá seu layout detalhado mais adiante. Visando otimizar o processo de autorização e evitar a duplicação da estrutura das SEFAZ Autorizadoras, o modelo 67 utilizará os mesmos webservices do modelo 57 para suprir os demais serviços essenciais para o contribuinte: • Consulta Situação; • Inutilização numérica; • Recepção de Eventos; • Consulta Status Serviço; O modelo do documento fiscal eletrônico, identificado na chave de acesso do mesmo, deverá sinalizar para a aplicação da SEFAZ Autorizadora qual documento está sendo solicitado o serviço permitindo que a mesma possa aplicar as regras conforme o caso, mesmo quando internamente existirem bases de dados diferentes. O WebService de retorno recepção não será necessário ao modelo 67 uma vez que o mesmo deverá responder de forma síncrona em uma conexão, para tal, o lote de CT-e outros serviços deverá conter apenas um documento por vez. 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. 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 eletrônico MOC CT-e 3.00 Pág. 25 / 231 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 PL_ CTe_ 1.00.ZIP PL_CTe_ 1.01.ZIP DATA LIBERAÇÃO 01/04/2008 01/06/2008 SCHEMAS 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. 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 Conhecimento de Transporte eletrônico MOC CT-e 3.00 Pág. 26 / 231 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. 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. Conhecimento de Transporte eletrônico MOC CT-e 3.00 Pág. 27 / 231 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: 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: Conhecimento de Transporte eletrônico MOC CT-e 3.00 Pág. 30 / 231 Observe no quadro abaixo a aplicação do evento conforme o modelo de CT-e. Legenda: Tipo de Autor do Evento: 1 – Empresa Emitente; 2 – Fisco do Emitente; 3 – Fisco; 4 – RFB; 5 – Outros Órgãos / Agência Reguladora; 6 - Tomador 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; Tipo de Evento Modelo de CT-e Descrição Evento Tipo de Autor do Evento Tipo de Meio Informação Local Evento CT-e deve existir? *** Evento: Empresa Emitente 110110 57 e 67 Carta de Correção 1-Empresa Emitente 1=via WS Evento SEFAZ Autoriz. Sim 110111 57 e 67 Cancelamento 1-Empresa Emitente 1=via WS Evento SEFAZ Autoriz. Sim 110113 57 EPEC 1-Empresa Emitente 1=via WS Evento SVC Não 110160 57 Registros do Multimodal 1-Empresa Emitente 1=via WS Evento SEFAZ Autoriz. Sim 110170 67 Informações da GTV 1-Empresa Emitente 1=via WS Evento SEFAZ Autoriz. Sim *** Evento: Fisco 310620 57 Registro de Passagem 3-Fisco 1=via WS Evento Ambiente Nacional Não 510620 57 Registro de Passagem Automático 3-Fisco 1=via WS Evento Ambiente Nacional Não 310610 57 MDF-e Autorizado 3-Fisco 1=via WS Evento Ambiente Nacional MDFe Não 310611 57 MDF-e Cancelado 3-Fisco 1=via WS Evento Ambiente Nacional MDFe Não *** Evento: Fisco do Emitente 240130 57 e 67 Autorizado CT-e Complementar 2-Fisco do Emitente 1=via WS Evento ou 4=via integração SEFAZ Autoriz. Sim 240131 57 e 67 Cancelado CT-e Complementar 2-Fisco do Emitente 1=via WS Evento ou 4=via integração SEFAZ Autoriz. Sim 240140 57 e 67 CT-e de Substituição 2-Fisco do Emitente 1=via WS Evento ou 4=via integração SEFAZ Autoriz. Sim 240150 57 e 67 CT-e de Anulação 2-Fisco do Emitente 1=via WS Evento ou 4=via integração SEFAZ Autoriz. Sim 240160 57 Liberação de EPEC 2-Fisco do Emitente 1=via WS Evento ou 4=via integração SVC Sim 240170 57 e 67 Liberação Prazo Cancelamento 2–Fisco do Emitente 1=via WS Evento ou 4=via integração SEFAZ Autoriz. Sim *** Evento: RFB 440130 57 Autorizado Redespacho 4-RFB 4=via integração Ambiente Nacional Não 440140 57 Autorizado Redespacho intermediário 4-RFB 4=via integração Ambiente Nacional Não 440150 57 Autorizado Subcontratação 4=RFB 4=via integração Ambiente Nacional Não 440160 57 Autorizado Serviço Vinculado Multimodal 4-RFB 4=via integração Ambiente Nacional Não *** Evento: Tomador 610110 57 e 67 Prestação do Serviço em Desacordo 6-Tomador 1=via WS Evento SEFAZ Autoriz. Sim Conhecimento de Transporte eletrônico MOC CT-e 3.00 Pág. 31 / 231 3.8 Data e Hora de Emissão e Outros Horários Alterado o campo de Data de Emissão para o formato UTC completo com a informação do TimeZone. Este tipo de representação de dados já é utilizado atualmente no projeto da NF-e e é tecnicamente adequado para a representação do horário para um País com dimensões continentais como o Brasil. Todos os demais campos com horário foram migrados para este tipo de dado, inclusive os horários que constam nas mensagens de resposta fornecidas pelas SEFAZ. Nesta nova versão do leiaute, serão aceitos os horários de qualquer região do mundo (faixa de horário UTC de -11 a +12) e não apenas as faixas de horário do Brasil Exemplo: no formato UTC para os campos de Data-Hora, "TZD" pode ser -02:00 (Fernando de Noronha), -03:00 (Brasília) ou -04:00 (Manaus), no horário de verão serão -01:00, -02:00 e - 03:00. Exemplo: "2010-08-19T13:00:15-03:00". Conhecimento de Transporte eletrônico MOC CT-e 3.00 Pág. 32 / 231 3.9 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 eletrônico MOC CT-e 3.00 Pág. 35 / 231 Schema XML: enviCTe_v99.99.xsd # Campo Ele Pai Tipo Ocor. Tam. Dec. Descrição/Observação AP01 enviCTe Raiz - - - - TAG raiz AP02 versao 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 6.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 6.5) AR09 dhRecbto E AR07 D 1-1 - Data e Hora do Recebimento Formato = AAAA-MM-DDTHH:MM:SS TZD 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 6.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 eletrônico MOC CT-e 3.00 Pág. 36 / 231 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/TLS) # Regra de Validação Crítica Msg Efeito A01 Varificar Certificado de Transmissor: - 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 Verificar Validade do Certificado (data início e data fim) Obrig. 281 Rej. A03 Verificar 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 Verificar LCR do Certificado de Transmissor - Falta o endereço da LCR (CRL DistributionPoint) - LCR indisponível - LCR inválida Obrig. 286 Rej. A05 Verificar se Certificado do Transmissor está revogado Obrig. 284 Rej. A06 Verificar se o Certificado Raiz difere da "ICP-Brasil" Obrig. 285 Rej. A07 Verificar falta da 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 / TLS e não precisam ser implementadas. A validação A06 também pode ser realizada pelo protocolo, 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 no Web Service # Regra de Validação Aplic. Msg Efeito B01 Tamanho do XML de Dados não pode ser superior a 500 Kbytes Obrig. 214 Rej. B02 Verificar XML de Dados Mal Formado Facult. 243 Rej. B03 Verificar se o Servidor de Processamento está Paralisado Momentaneamente Obrig. 108 Rej. B04 Verificar se o Servidor de Processamento está Paralisado sem Previsão Obrig. 109 Rej. Conhecimento de Transporte eletrônico MOC CT-e 3.00 Pág. 37 / 231 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 Informações de Controle da Chamada ao Web Service # Regra de Validação Aplic. Msg Efeito C01 Verificar se o elemento cteCabecMsg inexiste no SOAP Header Facult. 242 Rej. C02 Verificar se o campo cUF inexiste 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 Verificar se o campo versaoDados inexiste no elemento cteCabecMsg do SOAP Header Obrig. 411 Rej. C07 Verificar se a Versão dos Dados informada é superior à versão vigente Facult. 238 Rej. C08 Verificar se a 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). 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 eletrônico MOC CT-e 3.00 Pág. 40 / 231 d) Validação de Regras de Negócio do CT-e Validação do CT-e – Regras de Negócio Cód. Regras de Validação Aplic. Msg Efeito Validações Gerais G01 Verificar se o tipo do ambiente do CT-e difere do ambiente do Web Service Obrig. 252 Rej. G02 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. G03 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. G04 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. G05 Se Tipo do Ambiente for igual 2 (homologação) e existir destinatário, 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. G06 A série informada não deve estar na faixa entre 890-899 (reservada) Obrig. 670 Rej. G07 Código da UF do Emitente difere da UF Autorizadora Obrig. 226 Rej. G08 Sigla da UF do Emitente difere da UF Autorizadora Obrig. 247 Rej. G09 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. G10 Se forma de emissão do CT-e for igual a 5 (FS-DA): dhCont e xJust devem ser informados Obrig. 587 Rej. G11 Se Data de entrada em contingência estiver informada, esta deve ser menor ou igual à data de emissão Obrig 588 Rej. G12 Se Ambiente de Autorização Normal: - Não aceitar tpEmis = 7 (SVC-RS) ou 8 (SVC-SP) Obrig 515 Rej. G13 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. G14 Se ambiente de Autorização SVC: - Não aceitar tipo de CT-e diferente de 0 (Normal) Obrig. 517 Rej. G15 Chave de acesso inválida (modelo diferente de 57) Obrig. 732 Rej. G16 Verificar Campo ID: - Falta literal "CTe" - Chave de Acesso do campo ID difere da concatenação dos campos correspondentes Obrig. 227 Rej. G17 Dígito Verificador inválido da Chave de acesso resultante da concatenação dos campos correspondentes Obrig. 253 Rej. G18 Se Tipo do CT-e= 0 (Normal) ou 3 (Substituição): deve existir o grupo de CT-e Normal Obrig. 458 Rej. G19 Se Tipo do CT-e= 1 (Complemento): deve existir o grupo de CT-e Complementar Obrig. 459 Rej. G20 Tomador do serviço informado como remetente, mas inexiste remetente Obrig. 460 Rej. G21 Tomador do serviço informado como expedidor, mas inexiste expedidor Obrig. 461 Rej. G22 Tomador do serviço informado como recebedor, mas inexiste recebedor Obrig. 462 Rej. G23 Tomador do serviço informado como destinatário, mas inexiste destinatário Obrig. 463 Rej. Conhecimento de Transporte eletrônico MOC CT-e 3.00 Pág. 41 / 231 Validação do CT-e – Regras de Negócio Cód. Regras de Validação Aplic. Msg Efeito G24 Se indicador de tomador for igual a Contribuinte (indIEToma=1): - Rejeitar se o tomador indicado (toma3 ou toma4) não possuir informação da IE ou se estiver informado “ISENTO” Obrig, 481 Rej. G25 Se indicador de tomador for igual a Isento de Inscrição (indIEToma=2): - Rejeitar se o tomador indicado (toma3 ou toma4) não possuir informação de IE ou se estiver informada diferente do literal “ISENTO" Obrig. 482 Rej. G26 Se indicador de tomador for igual a Não Contribuinte (indIEToma=9): - Rejeitar se o tomador indicado (toma3 ou toma4) possuir a tag IE informada Obrig. 483 Rej. G27 Rejeitar quando informado tomador como Contribuinte Isento de Inscrição Estadual (indIEToma=2) em UF que não permite esta situação, conforme abaixo: - AM, BA, CE, GO, MG, MS, MT, PE, RN, SE, SP Obrig. 617 Rej. Validações dos Modais G28 Se Tipo do CT-e= 0 (Normal) ou 3 (Substituição): - Verificar se a Versão do modal de transporte é suportada Obrig 579 Rej G29 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. G30 Se Tipo do CT-e= 0 (Normal) ou 3 (Substituição): - O Valor Total da Carga <vCarga> deve ser informado para modal de transporte diferente de Dutoviário Obrig 581 Rej. G31 Se CT-e do tipo normal ou substituição, modal Aquaviário e tipo de serviço for igual a Redespacho Intermediário / Serviço vinculado a multimodal: - Exigir preenchimento do grupo de informações de detalhamento dos containers no modal Aquaviário Obrig. 526 Rej. Validações Tráfego Mútuo (Modal Ferroviário) G32 Se Tipo do CT-e= 0 (Normal) ou 3 (Substituição), modal = ferroviário e <tpTraf=1> (tráfego mútuo), - O grupo Tráfego Mútuo <trafMut> deve ser informado Obrig 582 Rej G33 Se Tipo do CT-e= 0 (Normal) ou 3 (Substituição), modal = ferroviário, 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 G34 Se Tipo do CT-e= 0 (Normal) ou 3 (Substituição), modal = ferroviário e o responsável pelo faturamento for a ferrovia de destino <respFat=2> - Deve ser referenciado o CT-e <chCTeFerroOrigem> emitido pela ferrovia de origem Obrig 584 Rej G35 Se Tipo do CT-e= 0 (Normal) ou 3 (Substituição), modal = ferroviário e informado CT-e emitido pela ferrovia de origem <chCTeFerroOrigem> - Rejeitar se o Dígito Verificador for inválido na Chave de acesso do CT-e Ferrovia de Origem Obrig. 701 Rej G36 Se Tipo do CT-e= 0 (Normal) ou 3 (Substituição), modal = ferroviário e informado CT-e emitido pela ferrovia de origem <chCTeFerroOrigem> - Rejeitar Chave de acesso de CT-e da Ferrovia de Origem inválida (Ano < 2009 ou Ano maior que Ano corrente) Obrig. 702 Rej. G37 Se Tipo do CT-e= 0 (Normal) ou 3 (Substituição), modal = ferroviário e informado CT-e emitido pela ferrovia de origem <chCTeFerroOrigem> - Rejeitar Chave de acesso de CT-e da Ferrovia de Origem inválida (Mês = 0 ou Mês > 12) Obrig. 703 Rej. G38 Se Tipo do CT-e= 0 (Normal) ou 3 (Substituição), modal = ferroviário e informado CT-e emitido pela ferrovia de origem <chCTeFerroOrigem> - Rejeitar Chave de acesso de CT-e da Ferrovia de Origem inválida (CNPJ zerado ou digito inválido) Obrig. 704 Rej. Conhecimento de Transporte eletrônico MOC CT-e 3.00 Pág. 42 / 231 Validação do CT-e – Regras de Negócio Cód. Regras de Validação Aplic. Msg Efeito G39 Se Tipo do CT-e= 0 (Normal) ou 3 (Substituição), modal = ferroviário e informado CT-e emitido pela ferrovia de origem <chCTeFerroOrigem> - Rejeitar Chave de acesso de CT-e da Ferrovia de Origem inválida (modelo diferente de 57) Obrig. 705 Rej. G40 Se Tipo do CT-e= 0 (Normal) ou 3 (Substituição), modal = ferroviário e informado CT-e emitido pela ferrovia de origem <chCTeFerroOrigem> - Rejeitar Chave de acesso de CT-e da Ferrovia de Origem inválida (numero CT = 0) Obrig. 706 Rej. G41 Se Tipo do CT-e= 0 (Normal) ou 3 (Substituição), modal = ferroviário e informado CT-e emitido pela ferrovia de origem <chCTeFerroOrigem> - Rejeitar Chave de acesso de CT-e da Ferrovia de Origem inválida (Tipo de emissão inválido) Obrig. 707 Rej. G42 Se Tipo do CT-e= 0 (Normal) ou 3 (Substituição), modal = ferroviário e informado CT-e emitido pela ferrovia de origem <chCTeFerroOrigem> - Rejeitar Chave de acesso de CT-e da Ferrovia de Origem inválida (UF inválida) Obrig. 708 Rej. G43 Se Tipo do CT-e= 0 (Normal) ou 3 (Substituição), modal = ferroviário e informado CT-e emitido pela ferrovia de origem <chCTeFerroOrigem> - Acessar BD CHAVES CTE (Chave: CNPJ Emit, Modelo, Série, Nro): - O CT-e da Ferrovia de Origem deve existir OBS: A SEFAZ Autorizadora poderá consultar o documento diretamente no Ambiente Nacional através de WebService Facult. 709 Rej. G44 Se Tipo do CT-e= 0 (Normal) ou 3 (Substituição), modal = ferroviário e informado CT-e emitido pela ferrovia de origem <chCTeFerroOrigem> - O CT-e da Ferrovia de Origem (chCTeFerroOrigem) não pode existir com diferença na chave de acesso OBS: A SEFAZ Autorizadora poderá consultar o documento diretamente no Ambiente Nacional através de WebService Facult. 710 Rej. G45 Se Tipo do CT-e= 0 (Normal) ou 3 (Substituição), modal = ferroviário e informado CT-e emitido pela ferrovia de origem <chCTeFerroOrigem> -Acessar BD CHAVES CTE (Chave: CNPJ Emit, Modelo, Série, Nro): - O CT-e da Ferrovia de Origem não pode estar cancelado ou denegado OBS: A SEFAZ Autorizadora poderá consultar o documento diretamente no Ambiente Nacional através de WebService Facult. 711 Rej. Validações Documentos Transportados G46 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. G47 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. G48 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 G49 Se Tipo do CT-e= 0 (Normal) ou 3 (Substituição) e informados grupos de informações de documentos (infDoc) e NF-e (infNFe) - Verificar se existe alguma chave de acesso de NF-e duplicada no CT-e Retornar a chave duplicada Obrig. 527 Rej. G50 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: - Rejeitar Dígito Verificador inválido na Chave de acesso de NF-e transportada Retornar a primeira chave de acesso inválida. Obrig. 591 Rej Conhecimento de Transporte eletrônico MOC CT-e 3.00 Pág. 45 / 231 Validação do CT-e – Regras de Negócio Cód. Regras de Validação Aplic. Msg Efeito Validações do Redespacho Intermediário e Serviço Vinculado a Multimodal G69 Remetente deverá ser informado para tipo de serviço diferente de redespacho intermediário ou Serviço vinculado a multimodal Obrig. 469 Rej. G70 Destinatário deverá ser informado para tipo de serviço diferente de redespacho intermediário ou Serviço vinculado a multimodal Obrig. 470 Rej. G71 Expedidor deverá ser informado para tipo de serviço de redespacho intermediário e Serviço vinculado a multimodal Obrig. 474 Rej. G72 Recebedor deverá ser informado para tipo de serviço de redespacho intermediário e Serviço vinculado a multimodal Obrig. 475 Rej. G73 Se Tipo de Serviço = “Serviço Vinculado a Multimodal” deve ser referenciado pelo menos um CT-e autorizado pelo OTM (infServVinc/infCTeMultimodal/chCTeMultimodal) Obrig. 651 Rej. G74 Se Tipo do CT-e= 0 (Normal) ou 3 (Substituição) e Tipo de Serviço for IGUAL a Redespacho / Redespacho Intermediário / Subcontratação: - O grupo de Documentos Anteriores (docAnt) deve ser informado Obrig. 521 Rej. G75 Se estiver informado o grupo de documentos anteriores: - Rejeitar se o CT-e estiver com tipo de serviço Normal (tpServ=0) Obrig. 747 Rej. G76 Se estiver informado o grupo de documentos eletrônicos (idDocAntEle) em documentos anteriores: - Verificar se existe alguma chave de acesso de CT-e duplicada nos documentos anteriores. Retornar a chave duplicada Obrig. 543 Rej. G77 Se estiver informado o grupo de documentos eletrônicos (idDocAntEle) em documentos anteriores: - Rejeitar se o CNPJ do emitente de algum CT-e relacionado for diferente do CNPJ do emissor indicado no grupo emiDocAnt/CNPJ ou se estiver informado CPF Obrig. 733 Rej G78 Se estiver informado o grupo de documentos eletrônicos (idDocAntEle) em documentos anteriores: - Rejeitar se o CNPJ base do tomador for diferente do CNPJ base do emissor indicado no grupo emiDocAnt/CNPJ Obrig. 745 Rej G79 Se tomador do serviço for emitente de CT-e (verificar CNE), for contribuinte do ICMS (indIEToma=1) e diferente do CNPJ Base do Remetente ou Destinatário: - Rejeitar se o tipo de serviço informado for Normal (tpServ=0) OBS: Nas prestações de serviço que o tomador figurar como não contribuinte, indIEToma deve ser informado com 9, mesmo que exista uma Inscrição Estadual para o mesmo. Obrig. 746 Rej. G80 Se estiver informado o grupo de documentos eletrônicos (idDocAntEle) em documentos anteriores: - Rejeitar Dígito Verificador inválido na Chave de acesso do CT-e anterior Retornar a primeira chave de acesso inválida. Obrig. 544 Rej G81 Se estiver informado o grupo de documentos eletrônicos (idDocAntEle) em documentos anteriores: - Rejeitar Chave de acesso de CT-e anterior inválida (Ano < 2009 ou Ano maior que Ano corrente) Retornar a primeira chave de acesso inválida. Obrig. 545 Rej. G82 Se estiver informado o grupo de documentos eletrônicos (idDocAntEle) em documentos anteriores: - Rejeitar Chave de acesso de CT-e anterior inválida (Mês = 0 ou Mês > 12) Retornar a primeira chave de acesso inválida. Obrig. 546 Rej. Conhecimento de Transporte eletrônico MOC CT-e 3.00 Pág. 46 / 231 Validação do CT-e – Regras de Negócio Cód. Regras de Validação Aplic. Msg Efeito G83 Se estiver informado o grupo de documentos eletrônicos (idDocAntEle) em documentos anteriores: - Rejeitar Chave de acesso de CT-e anterior inválida (CNPJ zerado ou digito inválido) Retornar a primeira chave de acesso inválida. Obrig. 547 Rej. G84 Se estiver informado o grupo de documentos eletrônicos (idDocAntEle) em documentos anteriores: - Rejeitar Chave de acesso de CT-e anterior inválida (modelo diferente de 57) Retornar a primeira chave de acesso inválida. Obrig. 548 Rej. G85 Se estiver informado o grupo de documentos eletrônicos (idDocAntEle) em documentos anteriores: - Rejeitar Chave de acesso de CT-e anterior inválida (número CT = 0) Retornar a primeira chave de acesso inválida. Obrig. 549 Rej. G86 Se estiver informado o grupo de documentos eletrônicos (idDocAntEle) em documentos anteriores: - Rejeitar Chave de acesso de CT-e anterior inválida (Tipo de emissão inválido) Retornar a primeira chave de acesso inválida. Obrig. 480 Rej. G87 Se estiver informado o grupo de documentos eletrônicos (idDocAntEle) em documentos anteriores: - Rejeitar Chave de acesso de CT-e anterior inválida (UF inválida) Retornar a primeira chave de acesso inválida. Obrig. 538 Rej. G88 Se estiver informado o grupo de documentos eletrônicos (idDocAntEle) em documentos anteriores: - Acessar BD CHAVES CTE (Chave: CNPJ Emit, Modelo, Série, Nro): - Os CT-e informados em DocAnt (chCTe) devem existir OBS: A SEFAZ Autorizadora poderá consultar o documento diretamente no Ambiente Nacional através de WebService OBS: Retornar a primeira chave do CT-e anterior inexistente Facult. 748 Rej. G89 Se estiver informado o grupo de documentos eletrônicos (idDocAntEle) em documentos anteriores: -Acessar BD CHAVES CTE (Chave: CNPJ Emit, Modelo, Série, Nro): - Os CT-e informados em DocAnt (chCTe) não podem existir com diferença de chave de acesso OBS: A SEFAZ Autorizadora poderá consultar o documento diretamente no Ambiente Nacional através de WebService OBS: Retornar a primeira chave do CT-e anterior com chave divergente Facult. 749 Rej. G90 Se estiver informado o grupo de documentos eletrônicos (idDocAntEle) em documentos anteriores: -Acessar BD CHAVES CTE (Chave: CNPJ Emit, Modelo, Série, Nro): - Os CT-e informados em DocAnt (chCTe) não podem estar cancelados ou denegados OBS: A SEFAZ Autorizadora poderá consultar o documento diretamente no Ambiente Nacional através de WebService OBS: Retornar a primeira chave do CT-e anterior com situação inválida Facult. 750 Rej. G91 Se estiver informado o grupo de CT-e multimodal no serviço vinculado: - Verificar se existe alguma chave de acesso de CT-e duplicada na relação de Multimodais. Retornar a chave duplicada Obrig. 714 Rej. G92 Se estiver informado o grupo de CT-e multimodal no serviço vinculado, para cada CT-e informado: <chCTeMultimodal > - Rejeitar Dígito Verificador inválido na Chave de acesso do CT-e Multimodal OBS: Retornar a primeira chave do CT-e Multimodal inválida Obrig. 450 Rej Conhecimento de Transporte eletrônico MOC CT-e 3.00 Pág. 47 / 231 Validação do CT-e – Regras de Negócio Cód. Regras de Validação Aplic. Msg Efeito G93 Se estiver informado o grupo de CT-e multimodal no serviço vinculado, para cada CT-e informado: <chCTeMultimodal > - Rejeitar Chave de acesso de CT-e Multimodal inválida (Ano < 2009 ou Ano maior que Ano corrente) OBS: Retornar a primeira chave do CT-e Multimodal inválida Obrig. 451 Rej. G94 Se estiver informado o grupo de CT-e multimodal no serviço vinculado, para cada CT-e informado: <chCTeMultimodal > - Rejeitar Chave de acesso de CT-e Multimodal inválida (Mês = 0 ou Mês > 12) OBS: Retornar a primeira chave do CT-e Multimodal inválida Obrig. 452 Rej. G95 Se estiver informado o grupo de CT-e multimodal no serviço vinculado, para cada CT-e informado: <chCTeMultimodal > - Rejeitar Chave de acesso de CT-e Multimodal inválida (CNPJ zerado ou digito inválido) OBS: Retornar a primeira chave do CT-e Multimodal inválida Obrig. 453 Rej. G96 Se estiver informado o grupo de CT-e multimodal no serviço vinculado, para cada CT-e informado: <chCTeMultimodal > - Rejeitar Chave de acesso de CT-e Multimodal inválida (modelo difer. 57) OBS: Retornar a primeira chave do CT-e Multimodal inválida Obrig. 454 Rej. G97 Se estiver informado o grupo de CT-e multimodal no serviço vinculado, para cada CT-e informado: <chCTeMultimodal > - Rejeitar Chave de acesso de CT-e Multimodal inválida (número CT = 0) OBS: Retornar a primeira chave do CT-e Multimodal inválida Obrig. 478 Rej. G98 Se estiver informado o grupo de CT-e multimodal no serviço vinculado, para cada CT-e informado: <chCTeMultimodal > - Rejeitar Chave de acesso de CT-e Multimodal inválida (Tipo de emissão inválido) OBS: Retornar a primeira chave do CT-e Multimodal inválida Obrig. 479 Rej. G99 Se estiver informado o grupo de CT-e multimodal no serviço vinculado, para cada CT-e informado: <chCTeMultimodal > - Rejeitar Chave de acesso de CT-e Multimodal inválida (UF inválida) OBS: Retornar a primeira chave do CT-e Multimodal inválida Obrig. 608 Rej. G100 Se Tipo de Serviço = “Serviço Vinculado a Multimodal” - Acessar BD CHAVES CTE (Chave: CNPJ Emit, Modelo, Série, Nro): - Os CT-e Multimodal referenciados (chCTeMultimodal) devem existir OBS: A SEFAZ Autorizadora poderá consultar o documento diretamente no Ambiente Nacional através de WebService OBS: Retornar a primeira chave do CT-e Multimodal inexistente Facult. 690 Rej. G101 Se Tipo de Serviço = “Serviço Vinculado a Multimodal” -Acessar BD CHAVES CTE (Chave: CNPJ Emit, Modelo, Série, Nro): - Os CT-e Multimodal referenciados (chCTeMultimodal) não podem existir com diferença de chave de acesso OBS: A SEFAZ Autorizadora poderá consultar o documento diretamente no Ambiente Nacional através de WebService OBS: Retornar a primeira chave do CT-e Multimodal com chave divergente Facult. 691 Rej. G102 Se Tipo de Serviço = “Serviço Vinculado a Multimodal” -Acessar BD CHAVES CTE (Chave: CNPJ Emit, Modelo, Série, Nro): - Os CT-e Multimodal referenciados (chCTeMultimodal) não podem estar cancelados ou denegados OBS: A SEFAZ Autorizadora poderá consultar o documento diretamente no Ambiente Nacional através de WebService OBS: Retornar a primeira chave do CT-e Multimodal com situação inválida Facult. 692 Rej. G103 Se Tipo de Serviço = “Serviço Vinculado a Multimodal” O CNPJ-Base do Tomador deve ser igual ao CNPJ-Base do Emitente para todos os CT-e Multimodal informados (obter na chave de acesso em chCTeMultimodal) OBS: Retornar a primeira chave de CT-e Multimodal com emitente diferente do tomador do CT-e Obrig. 667 Rej. Conhecimento de Transporte eletrônico MOC CT-e 3.00 Pág. 50 / 231 Validação do CT-e – Regras de Negócio Cód. Regras de Validação Aplic. Msg Efeito G140 Se Tipo do CT-e= 3 (Substituição): - O CT-e substituído não pode ter sido complementado Obrig 659 Rej G141 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 G142 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. G143 Se Tipo do CT-e=3 (Substituição): - O CNPJ/CPF do remetente do CT-e substituto deve ser igual ao informado no CT-e substituído Obrig. 511 Rej. G144 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. G145 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. G146 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. G147 Se Tipo do CT-e=3 (Substituição) e informado toma4: - CNPJ/CPF do tomador do CT-e substituto deve ser igual ao informado no CT-e substituído * O CT-e substituído também deve ter informado o toma4 como tomador Obrig. 552 Rej. G148 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. G149 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. G150 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. G151 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. G152 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. G153 Se Tipo do CT-e=3 (Substituição) e estiver informado toma4: - IE do tomador do CT-e substituto deve ser igual ao informado no CT-e substituído * O CT-e substituído também deve ter informado toma4 como tomador Obrig. 558 Rej. G154 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. G155 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. G156 Se Tipo do CT-e=3 (Substituição): - Todas NF-e transportadas no CT-e substituto devem ser as mesmas informadas no CT-e substituído Obrig. 734 Rej. G157 Se Tipo do CT-e=3 (Substituição): - A autorização do CT-e de substituiçã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 autorização do CT-e objeto substituição Obrig. 563 Rej. Conhecimento de Transporte eletrônico MOC CT-e 3.00 Pág. 51 / 231 Validação do CT-e – Regras de Negócio Cód. Regras de Validação Aplic. Msg Efeito G158 Se Tipo do CT-e= 3 (Substituição) e informado o grupo tomaICMS (tomador é contribuinte do ICMS) com as Notas do tomador - O CT-e a ser substituído (chCTe) não pode ter sido anulado. Obrig 577 Rej G159 Se Tipo do CT-e=3 (Substituição) e informado CT-e de anulação - CT-e de Anulação deve existir Acesso BD CTE (Chave: CNPJ Emit, Modelo, Série, Nro) Obrig 572 Rej G160 Se Tipo do CT-e=3 (Substituição) e informado CT-e de anulação - O CT-e de Anulação não pode existir com diferença de Chave de Acesso: Retornar a chave de acesso já autorizada, o número do protocolo e data de autorização do CT-e [chCTe: 99999999999999999999999999999999999999999999] [nProt:999999999999999][dhAut: AAAA-MM-DDTHH:MM:SS TZD] Obrig 672 Rej G161 Se Tipo do CT-e=3 (Substituição) e informado CT-e de anulação - CT-e informado deve ser do Tipo=2(Anulação) Obrig 573 Rej G162 Se Tipo do CT-e=3 (Substituição) e informado CT-e de anulação - O CT-e anulação deve ter anulado o mesmo CT-e que está sendo substituído. Obrig 578 Rej Validações da Data de Emissão G163 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. OBS: Essa Validação deve considerar o novo formato de datas UTC com indicação do timezone. Obrig. 212 Rej. G164 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) OBS: Essa Validação deve considerar o novo formato de datas UTC com indicação do timezone. Obrig. 228 Rej. Validações do Emitente G165 Validar CNPJ Emitente (dígito controle, zeros ou nulo) Obrig. 207 Rej. G166 IE Emitente deve ser informada (zeros ou nulo) Obrig. 229 Rej. G167 Validar IE Emitente (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. G168 Validar IE do Substituto Tributário, quando esta for informada (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 Ex: A validação dessa IE deverá levar em consideração da UF do tomador do CT-e Obrig. 614 Rej. G169 Acessar Cadastro de Emitentes (CNE, Chave: UF, IE): - IE emitente não cadastrada Facult. 230 Rej. Conhecimento de Transporte eletrônico MOC CT-e 3.00 Pág. 52 / 231 Validação do CT-e – Regras de Negócio Cód. Regras de Validação Aplic. Msg Efeito G170 - IE Emitente deve estar vinculada ao CNPJ (tratar Regime Especial de IE única) Obrig. 231 Rej. G171 - Emitente deve estar habilitado na base de dados para emissão do CT-e Obrig. 203 Rej. G172 - IE emitente deve estar autorizada a emitir CT-e para o modal de transporte informado Obrig. 585 Rej. G173 - 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 ou 205 Den. G174 Município do Emitente 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. 712 Rej G175 Código do Município Emitente inexistente (Tabela Municípios do IBGE) Obrig. 713 Rej. Validações do Remetente G176 Se CNPJ Remetente informado: - Validar CNPJ Remetente (dígito de controle, zeros) Obrig. 415 Rej. G177 Se CPF Remetente informado: - Validar CPF Remetente (dígito de controle, zeros) Obrig. 416 Rej. G178 Se Remetente informado: - Município deve pertencer à 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 G179 Se Remetente informado: - Código do Município deve existir (Tabela Municípios do IBGE) Obrig. 532 Rej. G180 Se Se IE Remetente informada: - Validar IE do Remetente (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. G181 IE Remetente informada: Acessar Cadastro de Contribuinte da UF (Chave: IE Remet.) (*1) - IE deve estar cadastrada Facult. 421 Rej. G182 Se IE e CNPJ Remetente informados: Acessar Cadastro de Contribuinte da UF (Chave: IE Remet.) (*1) - IE deve estar vinculada ao CNPJ Facult. 422 Rej. G183 Se IE Remetente = “ISENTO” ou não informada Acessar Cadastro de Contribuinte da UF (*1) - Remetente possui IE ativa na UF Excessão: A regra não deve ser aplicada quando Tomador informado em toma3 for o Remetente (toma3=0) e indicador de tomador for igual a não contribuinte (indIEToma=9) Facult. 716 Rej. (*1) Validação possível na operação interestadual ou no ambiente da SEFAZ Virtual utilizando o CCC- Cadastro Centralizado de Contribuintes Validações do Destinatário G184 Se CNPJ Destinatário informado: - Validar CNPJ do Destinatário (dígito de controle, zeros) Obrig. 208 Rej. G185 Se CPF Destinatário informado: - Validar CPF do Destinatário (dígito de controle, zeros) Obrig. 237 Rej. Conhecimento de Transporte eletrônico MOC CT-e 3.00 Pág. 55 / 231 Validação do CT-e – Regras de Negócio Cód. Regras de Validação Aplic. Msg Efeito G210 Se CNPJ Tomador informado: - Validar CNPJ do Tomador (dígito de controle, zeros) Obrig. 444 Rej. G211 Se CPF Tomador informado: - Validar CPF do Tomador (dígito de controle, zeros) Obrig. 445 Rej. G212 Se Tomador informado: - Município deve pertencer à 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. G213 Se Tomador informado: - Código do Município deve existir (Tabela Municipios do IBGE) Obrig. 536 Rej. G214 Se IE Tomador informado: - Validar IE do Tomador (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. G215 Se IE Tomador informada: Acessar Cadastro de Contribuinte da UF (Chave: IE Tomador) (*1) - IE deve estar cadastrada Facult. 489 Rej. G216 Se IE e CNPJ Tomador informados: Acessar Cadastro de Contribuinte da UF (Chave: IE Tomador) (*1) - IE deve estar vinculada ao CNPJ Facult. 490 Rej. G217 Se IE Tomador = “ISENTO” ou não informada Acessar Cadastro de Contribuinte da UF (*1) - Tomador possui IE ativa na UF Excessão: A regra não deve ser aplicada quando Tomador informado em toma4 possuir indicador de tomador igual a não contribuinte (indIEToma=9) Facult. 719 Rej. G218 Se informado tomador como toma4: - Verificar se o CNPJ/CPF ou IE do tomador existem declarados em um dos grupos: remetente, destinatário, recebedor ou expedidor Obrig. 799 Rej. (*1) Validação possível na operação interestadual ou no ambiente da SEFAZ Virtual utilizando o CCC- Cadastro Centralizado de Contribuintes Validações Banco de Dados CT-e G219 Acessar BD CTE (Chave: CNPJ Emit, Modelo, Série, Nro): - Verificar 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, o número do protocolo e data de autorização [chCTe: 99999999999999999999999999999999999999999999] [nProt:999999999999999][dhAut: AAAA-MM-DDTHH:MM:SS TZD] Obrig 539 Rej. G220 Acessar BD CTE (Chave: CNPJ Emit, Modelo, Série, Nro): - Verificar Duplicidade de CT-e Retornar Protocolo e data de autorização. [nProt:999999999999999][dhAut: AAAA-MM-DDTHH:MM:SS TZD]. Obrig. 204 Rej. G221 - Verificar se CT-e está Cancelado Retornar Protocolo e data de autorização do evento de cancelamento. [nProt:999999999999999][dhCanc: AAAA-MM-DDTHH:MM:SS TZD] Obrig. 218 Rej. G222 - Verificar se CT-e está Denegado Retornar Protocolo e data de denegação. [nProt:999999999999999][dhDeneg: AAAA-MM-DDTHH:MM:SS TZD] Obrig. 205 Rej. Conhecimento de Transporte eletrônico MOC CT-e 3.00 Pág. 56 / 231 Validação do CT-e – Regras de Negócio Cód. Regras de Validação Aplic. Msg Efeito G223 Se Tipo de Emissão diferente de EPEC (tpEmis<>4): Acessar BD CTE-Inutilização - Número do CT-e não deve estar Inutilizado Obrig. 206 Rej. Validações do CT-e Complementar G224 Se Tipo do CT-e = 1 (CT-e complementar): - Verificar se o Conhecimento complementado foi emitido pelo mesmo CNPJ. Obrig. 269 Rej. G225 Se Tipo do CT-e = 1 (CT-e complementar): - Rejeitar Dígito Verificador inválido na Chave de acesso do CT-e complementado Obrig. 777 Rej G226 Se Tipo do CT-e = 1 (CT-e complementar): - Rejeitar Chave de acesso de CT-e complementado inválida (Ano < 2009 ou Ano maior que Ano corrente) Obrig. 778 Rej. G227 Se Tipo do CT-e = 1 (CT-e complementar): - Rejeitar Chave de acesso de CT-e complementado inválida (Mês = 0 ou Mês > 12) Obrig. 779 Rej. G228 Se Tipo do CT-e = 1 (CT-e complementar): - Rejeitar Chave de acesso de CT-e complementado inválida (CNPJ zerado ou digito inválido) Obrig. 780 Rej. G229 Se Tipo do CT-e = 1 (CT-e complementar): - Rejeitar Chave de acesso de CT-e complementado inválida (modelo diferente de 57) Obrig. 781 Rej. G230 Se Tipo do CT-e = 1 (CT-e complementar): - Rejeitar Chave de acesso de CT-e complementado inválida (número CT = 0). Obrig. 782 Rej. G231 Se Tipo do CT-e = 1 (CT-e complementar): - Rejeitar Chave de acesso de CT-e complementado inválida (Tipo de emissão inválido) Obrig. 783 Rej. G232 Se Tipo do CT-e = 1 (CT-e complementar): - Rejeitar Chave de acesso de CT-e complementado inválida (UF inválida) Obrig. 784 Rej. G233 Se Tipo do CT-e = 1 (CT-e complementar): - Verificar se existe o CT-e complementado. Acesso BD CTE (Chave: CNPJ Emit, Modelo, Série, Nro) Obrig. 267 Rej. G234 Se Tipo do CT-e = 1 (CT-e complementar): Acessar BD CTE (Chave: CNPJ Emit, Modelo, Série, Nro) - Verificar se o CT-e complementado existe com diferença na Chave de Acesso Retornar a chave de acesso já autorizada, o número do protocolo e data de autorização do CT-e [chCTe: 99999999999999999999999999999999999999999999] [[nProt:999999999999999][dhAut: AAAA-MM-DDTHH:MM:SS TZD]. Obrig. 671 Rej. G235 Se Tipo do CT-e = 1 (CT-e complementar): - CT-e complementado deve ser do tipo Normal ou Substituição. Acessar BD CTE (Chave: CNPJ Emit, Modelo, Série, Nro) Obrig; 491 Rej. G236 Se Tipo do CT-e = 1 (CT-e complementar): - Verificar se o CT-e complementado está com Situação: Autorizado o Uso. Acesso BD CTE (Chave: CNPJ Emit, Modelo, Série, Nro) Obrig. 655 Rej. G237 Se Tipo do CT-e= 1 (Complementar): - Verificar se o CT-e complementado foi Anulado. Obrig. 656 Rej. G238 Se Tipo do CT-e= 1 (Complementar): - Verificar se o CT-e complementado foi Substituído. Obrig. 657 Rej. G239 Se Tipo do CT=e 1 (Complementar): - Verificar o número de Complementos que o CT-e complementado já recebeu, não podendo exceder o limite de 10 CT-e complementares para um mesmo CT-e. Obrig. 520 Rej Conhecimento de Transporte eletrônico MOC CT-e 3.00 Pág. 57 / 231 Validação do CT-e – Regras de Negócio Cód. Regras de Validação Aplic. Msg Efeito G240 Se Tipo do CT=e 1 (Complementar): - O CNPJ/CPF do remetente do CT-e complementar deve ser igual ao informado no CT-e complementado Obrig. 800 Rej G241 Se Tipo do CT=e 1 (Complementar): - CNPJ/CPF do destinatário do CT-e complementar deve ser igual ao informado no CT-e complementado Obrig. 801 Rej G242 Se Tipo do CT=e 1 (Complementar): - CNPJ/CPF do expedidor do CT-e complementar deve ser igual ao informado no CT-e complementado Obrig. 802 Rej G243 Se Tipo do CT=e 1 (Complementar): - CNPJ/CPF do recebedor do CT-e complementar deve ser igual ao informado no CT-e complementado Obrig. 803 Rej G244 Se Tipo do CT=e 1 (Complementar) e informado toma4: - CNPJ/CPF do tomador do CT-e complementar deve ser igual ao informado no CT-e complementado * O CT-e complementado também deve ter informado o toma4 como tomador Obrig. 804 Rej G245 Se Tipo do CT=e 1 (Complementar): - IE do emitente do CT-e complementar deve ser igual ao informado no CT- e complementado Obrig. 805 Rej G246 Se Tipo do CT=e 1 (Complementar): - IE do remetente do CT-e complementar deve ser igual ao informado no CT-e complementado Obrig. 806 Rej G247 Se Tipo do CT=e 1 (Complementar): - IE do destinatário do CT-e complementar deve ser igual ao informado no CT-e complementado Obrig. 807 Rej G248 Se Tipo do CT=e 1 (Complementar): - IE do expedidor do CT-e complementar deve ser igual ao informado no CT-e complementado Obrig. 808 Rej G249 Se Tipo do CT=e 1 (Complementar): - IE do recebedor do CT-e complementar deve ser igual ao informado no CT-e complementado Obrig. 809 Rej G250 Se Tipo do CT=e 1 (Complementar) e estiver informado toma4: - IE do tomador do CT-e complementar deve ser igual ao informado no CT-e complementado * O CT-e complementado também deve ter informado toma4 como tomador Obrig. 810 Rej G251 Se Tipo do CT=e 1 (Complementar): - UF de início da prestação do CT-e complementar deve ser igual ao informado no CT-e complementado Obrig. 811 Rej G252 Se Tipo do CT-e=1 (Complementar): - UF de fim da prestação do CT-e Complementar deve ser igual ao informado no CT-e Complementado Obrig. 812 Rej Validações Início e Fim da Prestação G253 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. G254 Código do Município de envio do CT-e inexistente (Tabela Municípios do IBGE) Obrig. 537 Rej. G255 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. G256 Código do Município de início da prestação inexistente (Tabela Municípios do IBGE) Obrig. 541 Rej. Conhecimento de Transporte eletrônico MOC CT-e 3.00 Pág. 60 / 231 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. 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. IMPORTANTE: A orientação para EPEC também se aplica a emissão com FS-DA, ou seja, a numeração também não deve ser inutilizada no ambiente normal e tão pouco autorizada com tipo de emissão Normal. 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 Consequê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. ** Esse evento deverá ser relacionado na consulta do CT-e de numeração 001. Conhecimento de Transporte eletrônico MOC CT-e 3.00 Pág. 61 / 231 4.2 Serviço de Recepção de CT-e Outros Serviços (Modelo 67) O Serviço de Recepção de CT-e para Outros Serviços é 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 Outros Serviços é síncrona sem a formação de lotes. O contribuinte deve transmitir CT-e através do Web Service de recepção de CT-e e receberá o resultado do processamento na mesma conexão. Web Service – CteRecepcaoOS Função: serviço destinado à recepção de mensagens de CT-e (Outros Serviços). Processo: síncrono. Método: cteRecepcaoOS Leiaute Mensagem de Entrada Entrada: Estrutura XML com o conhecimento de transporte outros serviços está definida no Anexo I deste MOC. Leiaute Mensagem de Retorno Retorno: Estrutura XML com a mensagem do resultado da transmissão. Schema XML: retCTeOS_v99.99.xsd # Campo Ele Pai Tipo Ocor. Tam. Dec. Descrição/Observação AR01 retEnviOS 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 6.1) AR06 xMotivo E AR01 C 1-1 1-255 Descrição literal do status da resposta AR07 protCTe G AR01 - 0-1 - Resposta ao processamento do CT-e OS Recepção CT-e OS Ret Emissor CT-e Cliente WS da Fazenda Aplicação Recepção Envio do CT-e OS Retorno cteRecepcaoOS Web Service : CteRecepcaoOS Proc . Conhecimento de Transporte eletrônico MOC CT-e 3.00 Pág. 62 / 231 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/TLS) # Regra de Validação Crítica Msg Efeito A01 Varificar Certificado de Transmissor: - 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 Verificar Validade do Certificado (data início e data fim) Obrig. 281 Rej. A03 Verificar 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 Verificar LCR do Certificado de Transmissor - Falta o endereço da LCR (CRL DistributionPoint) - LCR indisponível - LCR inválida Obrig. 286 Rej. A05 Verificar se Certificado do Transmissor está revogado Obrig. 284 Rej. A06 Verificar se o Certificado Raiz difere da "ICP-Brasil" Obrig. 285 Rej. A07 Verificar falta da 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/TLS e não precisam ser implementadas. A validação A06 também pode ser realizada pelo protocolo, 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 no Web Service # Regra de Validação Aplic. Msg Efeito B01 Tamanho do XML de Dados não pode ser superior a 500 Kbytes Obrig. 214 Rej. B02 Verificar XML de Dados Mal Formado Facult. 243 Rej. B03 Verificar se o Servidor de Processamento está Paralisado Momentaneamente Obrig. 108 Rej. B04 Verificar se o Servidor de Processamento 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 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. Conhecimento de Transporte eletrônico MOC CT-e 3.00 Pág. 65 / 231 d) Validação de Regras de Negócio do CT-e OS Validação do CT-e – Regras de Negócio Cód. Regras de Validação Aplic. Msg Efeito Validações Gerais N01 Verificar se o tipo do ambiente do CT-e difere do ambiente do Web Service Obrig. 252 Rej. N02 A serie informada não deve estar na faixa entre 890-899 (reservada) Obrig. 670 Rej. N03 Código da UF do Emitente difere da UF Autorizadora Obrig. 226 Rej. N04 Sigla da UF do Emitente difere da UF Autorizadora Obrig. 247 Rej. N05 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. N06 Se forma de emissão do CT-e for igual a 5 (FS-DA): dhCont e xJust devem ser informados Obrig. 587 Rej. N07 Se Data de entrada em contingência estiver informada, esta deve ser menor ou igual à data de emissão Obrig 588 Rej. N08 Se Ambiente de Autorização Normal: - Não aceitar tpEmis = 7 (SVC-RS) ou 8 (SVC-SP) Obrig 515 Rej. N09 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. N10 Se ambiente de Autorização SVC: - Não aceitar tipo de CT-e diferente de 0 (Normal) Obrig. 517 Rej. N11 Chave de acesso inválida (modelo diferente de 67) Obrig. 721 Rej. N12 Verificar Campo ID: - Falta literal "CTe" - Chave de Acesso do campo ID difere da concatenação dos campos correspondentes Obrig. 227 Rej. N13 Dígito Verificador inválido da Chave de acesso resultante da concatenação dos campos correspondentes Obrig. 253 Rej. N14 Se Tipo do CT-e= 0 (Normal) ou 3 (Substituição): deve existir o grupo de CT-e Normal Obrig. 458 Rej. N15 Se Tipo do CT-e= 1 (Complemento): deve existir o grupo de CT-e Complementar Obrig. 459 Rej. Validações dos Modais (Apenas para Transporte de Pessoas e Excesso de Bagagem) N16 Se Tipo do CT-e = 0 (Normal) ou 3 (Substituição) e tipo de serviço for igual a Transporte de Pessoas ou Excesso de Bagagem: - O grupo infModal deve estar preenchido Obrig. 798 Rej. N17 Se Tipo do CT-e= 0 (Normal) ou 3 (Substituição) e tipo de serviço for igual a Transporte de Pessoas ou Excesso de Bagagem: - Verificar se a Versão do modal de transporte é suportada Obrig 579 Rej N18 Se Tipo do CT-e= 0 (Normal) ou 3 (Substituição) e tipo de serviço for igual a Transporte de Pessoas ou Excesso de Bagagem: - Verificar Schema XML conforme o modal de transporte (parte específica do modal de transporte) Obrig. 580 Rej. Validações conforme Tipo de Serviço N19 Se tipo de serviço = Transporte de Pessoas - UF de início e UF de fim da prestação devem estar preenchidas Obrig. 751 Rej. N20 Se tipo de serviço = Transporte de Pessoas - Município de início e Município de Fim da prestação devem estar preenchidos Obrig. 752 Rej. N21 Se tipo de serviço = Transporte de Pessoas e modal Rodoviário, o grupo de informações de UF de percurso deverá ser preenchido na ordem Obrig. 753 Rej. Conhecimento de Transporte eletrônico MOC CT-e 3.00 Pág. 66 / 231 Validação do CT-e – Regras de Negócio Cód. Regras de Validação Aplic. Msg Efeito Origem – Destino sempre que existir pelo menos uma UF entre a UF de início e UF de fim da prestação OBS: A regra será aplicada considerando as divisas possíveis na ordem definida para o percurso. OBS2: Caso preenchido percurso para os outros tipos de serviço a ordem deverá ser respeitada da mesma forma N22 Se tipo de serviço = Transporte de Pessoas ou Valores - O grupo de informações do tomador deverá estar informado Obrig. 757 Rej. N23 Se tipo de serviço = Excesso de Bagagem - O grupo de documentos referenciados deve estar informado (infDocRef) Obrig. 754 Rej. N24 Se tipo de serviço = Transporte de Valores - Verificar se existe CT-e OS autorizado há mais de 45 dias para o mesmo CNPJ do emitente sem que exista pelo menos um evento de Informações da GTV vinculado OBS: Retornar a chave de acesso do CT-e OS mais antigo que causou o bloqueio Facult. 758 Rej. Validações de Valores N25 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. N26 - Verificar se Valor do ICMS corresponde ao Valor da base de cálculo X Alíquota. 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. N27 Valor a receber (vRec) deve ser menor ou igual ao Valor da Prestação do Serviço (vtPrest) Obrig. 531 Rej. N28 Valor de INSS deve ser informado quando tomador for pessoa Jurídica (CNPJ informado) e tipo de serviço for igual a Transporte de Pessoas ou Excesso de Bagagem Obrig. 760 Rej. Validações do CFOP N29 - Verificar se o CFOP informado pertence a operação de transporte. OBS: Verificar a relação de CFOP válidos no Anexo IX deste MOC Obrig. 676 Rej. Validações CT-e de Anulação N30 Se Tipo do CT-e= 2 (Anulação): - Deve existir o grupo de CT-e de Anulação Obrig. 496 Rej. N31 Se Tipo do CT-e= 2 (Anulação): - O tipo de emissão dever ser normal Obrig. 499 Rej. N32 Se Tipo do CT-e= 2 (Anulação): - Rejeitar Dígito Verificador inválido na Chave de acesso do CT-e objeto da anulação Obrig. 761 Rej N33 Se Tipo do CT-e= 2 (Anulação): - Rejeitar Chave de acesso de CT-e objeto da anulação inválida (Ano < 2009 ou Ano maior que Ano corrente) Obrig. 762 Rej. N34 Se Tipo do CT-e= 2 (Anulação): - Rejeitar Chave de acesso de CT-e objeto da anulação inválida (Mês = 0 ou Mês > 12) Obrig. 763 Rej. N35 Se Tipo do CT-e= 2 (Anulação): - Rejeitar Chave de acesso de CT-e objeto da anulação inválida (CNPJ zerado ou digito inválido) Obrig. 764 Rej. N36 Se Tipo do CT-e= 2 (Anulação): - Rejeitar Chave de acesso de CT-e objeto da anulação inválida (modelo diferente de 67) Obrig. 615 Rej. Conhecimento de Transporte eletrônico MOC CT-e 3.00 Pág. 67 / 231 Validação do CT-e – Regras de Negócio Cód. Regras de Validação Aplic. Msg Efeito N37 Se Tipo do CT-e= 2 (Anulação): - Rejeitar Chave de acesso de CT-e objeto da anulação inválida (número CT = 0). Obrig. 766 Rej. N38 Se Tipo do CT-e= 2 (Anulação): - Rejeitar Chave de acesso de CT-e objeto da anulação inválida (Tipo de emissão inválido) Obrig. 767 Rej. N39 Se Tipo do CT-e= 2 (Anulação): - Rejeitar Chave de acesso de CT-e objeto da anulação inválida (UF inválida) Obrig. 768 Rej. N40 Se Tipo do CT-e= 2 (Anulação): - O CT-e objeto da Anulação deve existir Acesso BD CTE (Chave: CNPJ Emit, Modelo, Série, Nro) Obrig. 497 Rej. N41 Se Tipo do CT-e= 2 (Anulação): - O CT-e objeto da Anulação não pode existir com diferença na chave de acesso Retornar a chave de acesso já autorizada, o número do protocolo e data de autorização do CT-e [chCTe: 99999999999999999999999999999999999999999999] [nProt:999999999999999][dhAut: AAAA-MM-DDTHH:MM:SS TZD]. Obrig. 674 Rej. N42 Se Tipo do CT-e= 2 (Anulação): - O CT-e objeto da anulação não pode estar cancelado ou denegado Obrig. 498 Rej. N43 Se Tipo do CT-e= 2 (Anulação): - O CT-e original e o de anulação devem possuir o mesmo CNPJ de emitente. Obrig. 565 Rej. N44 Se Tipo do CT-e= 2 (Anulação): - O CT-e objeto de anulação deve ser do Tipo = 0 (Normal) ou 3 (Substituição) Obrig. 500 Rej. N45 Se Tipo do CT-e= 2 (Anulação): - A autorizaçã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 autorização do CT-e objeto de anulação. Obrig. 501 Rej. N46 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. N47 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. N48 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 N49 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. N50 Se Tipo do CT-e= 2 (Anulação): - O CT-e objeto da anulação deve possuir evento de Prestação do Serviço em Desacordo quando o tomador for contribuinte (indIEToma=1) Obrig. 735 Rej. N51 Se Tipo do CT-e= 2 (Anulação): - Rejeitar se existir CT-e de Anulação autorizado há mais de 15 dias com o mesmo emitente sem que exista o CT-e de substituição Retornar a chave de acesso do CT-e de anulação mais antigo Obrig. 736 Rej. Validações do CT-e de Substituição N52 Se Tipo do CT-e= 3 (Substituição): - O tipo de emissão deve ser normal Obrig. 503 Rej. N53 Se Tipo do CT-e= 3 (Substituição): - Deve existir o grupo de informações do CT-e de substituição Obrig. 505 Rej. N54 Se Tipo do CT-e= 3 (Substituição): - Rejeitar Dígito Verificador inválido na Chave de acesso do CT-e Obrig. 769 Rej Conhecimento de Transporte eletrônico MOC CT-e 3.00 Pág. 70 / 231 Validação do CT-e – Regras de Negócio Cód. Regras de Validação Aplic. Msg Efeito N86 Acessar Cadastro de Emitentes (CNE, Chave: UF, IE): - IE emitente não cadastrada Facult. 230 Rej. N87 - IE Emitente deve estar vinculada ao CNPJ (tratar Regime Especial de IE única) Obrig. 231 Rej. N88 - Emitente deve estar habilitado na base de dados para emissão do CT-e Obrig. 203 Rej. N89 - 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 ou 205 Den. N90 Município do Emitente deve pertencer à 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. 712 Rej N91 Código do Município do Emitente deve existir na Tabela Municípios do IBGE Obrig. 713 Rej. Validações do Tomador N92 Se CNPJ Tomador informado: - Validar CNPJ do Tomador (dígito de controle, zeros) Obrig. 444 Rej. N93 Se CPF Tomador informado: - Validar CPF do Tomador (dígito de controle, zeros) Obrig. 445 Rej. N94 Se Tomador informado: - Município deve pertencer à 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. N95 Se Tomador informado: - Código do Município deve existir na Tabela Municípios do IBGE Obrig. 536 Rej. N96 Se indicador de tomador for igual a Contribuinte (indIEToma=1): - Rejeitar se o tomador não possuir informação da IE ou se estiver informado “ISENTO” Obrig, 481 Rej. N97 Se indicador de tomador for igual a Isento de Inscrição (indIEToma=2): - Rejeitar se o tomador não possuir informação de IE ou se estiver informada diferente do literal “ISENTO" Obrig. 482 Rej. N98 Se indicador de tomador for igual a Não Contribuinte (indIEToma=9): - Rejeitar se o tomador possuir a tag IE informada Obrig. 483 Rej. N99 Rejeitar quando informado tomador como Contribuinte Isento de Inscrição Estadual (indIEToma=2) em UF que não permite esta situação, conforme abaixo: - AM, BA, CE, GO, MG, MS, MT, PE, RN, SE, SP Obrig. 617 Rej. N100 Se IE Tomador informado: - Validar IE do Tomador (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. N101 Se IE Tomador informada: Acessar Cadastro de Contribuinte da UF (Chave: IE Tomador) (*1) - IE deve estar cadastrada Facult. 489 Rej. N102 Se IE e CNPJ Tomador informados: Acessar Cadastro de Contribuinte da UF (Chave: IE Tomador) (*1) - IE deve estar vinculada ao CNPJ Facult. 490 Rej. N103 Se IE Tomador = “ISENTO” ou não informada Acessar Cadastro de Contribuinte da UF (*1) - Tomador possui IE ativa na UF Excessão: A regra não deve ser aplicada quando Tomador informado possuir indicador de tomador igual a não contribuinte (indIEToma=9) Facult. 719 Rej. Conhecimento de Transporte eletrônico MOC CT-e 3.00 Pág. 71 / 231 Validação do CT-e – Regras de Negócio Cód. Regras de Validação Aplic. Msg Efeito (*1) Validação possível na operação interestadual ou no ambiente da SEFAZ Virtual utilizando o CCC- Cadastro Centralizado de Contribuintes Validações Banco de Dados CT-e N104 Acessar BD CTE (Chave: CNPJ Emit, Modelo, Série, Nro): - Verificar 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, o número do protocolo e data de autorização [chCTe: 99999999999999999999999999999999999999999999] [nProt:999999999999999][dhAut: AAAA-MM-DDTHH:MM:SS TZD] Obrig 539 Rej. N105 Acessar BD CTE (Chave: CNPJ Emit, Modelo, Série, Nro): - Verificar Duplicidade de CT-e Retornar Protocolo e data de autorização. [nProt:999999999999999][dhAut: AAAA-MM-DDTHH:MM:SS TZD]. Obrig. 204 Rej. N106 - Verificar se CT-e está Cancelado Retornar Protocolo e data de autorização do cancelamento. [nProt:999999999999999][dhCanc: AAAA-MM-DDTHH:MM:SS TZD]. Obrig. 218 Rej. N107 - Verificar se CT-e está Denegado Retornar Protocolo e data de denegação. [nProt:999999999999999][dhDeneg: AAAA-MM-DDTHH:MM:SS TZD]. Obrig. 205 Rej. N108 Acessar BD CTE-Inutilização - Número do CT-e não deve estar Inutilizado Obrig. 206 Rej. Validações do CT-e Complementar N109 Se Tipo do CT-e = 1 (CT-e complementar): - Verificar se o Conhecimento complementado foi emitido pelo mesmo CNPJ. Obrig. 269 Rej. N110 Se Tipo do CT-e = 1 (CT-e complementar): - Rejeitar Dígito Verificador inválido na Chave de acesso do CT-e complementado Obrig. 777 Rej N111 Se Tipo do CT-e = 1 (CT-e complementar): - Rejeitar Chave de acesso de CT-e complementado inválida (Ano < 2009 ou Ano maior que Ano corrente) Obrig. 778 Rej. N112 Se Tipo do CT-e = 1 (CT-e complementar): - Rejeitar Chave de acesso de CT-e complementado inválida (Mês = 0 ou Mês > 12) Obrig. 779 Rej. N113 Se Tipo do CT-e = 1 (CT-e complementar): - Rejeitar Chave de acesso de CT-e complementado inválida (CNPJ zerado ou digito inválido) Obrig. 780 Rej. N114 Se Tipo do CT-e = 1 (CT-e complementar): - Rejeitar Chave de acesso de CT-e complementado inválida (modelo diferente de 67) Obrig. 785 Rej. N115 Se Tipo do CT-e = 1 (CT-e complementar): - Rejeitar Chave de acesso de CT-e complementado inválida (número CT = 0). Obrig. 782 Rej. N116 Se Tipo do CT-e = 1 (CT-e complementar): - Rejeitar Chave de acesso de CT-e complementado inválida (Tipo de emissão inválido) Obrig. 783 Rej. N117 Se Tipo do CT-e = 1 (CT-e complementar): - Rejeitar Chave de acesso de CT-e complementado inválida (UF inválida) Obrig. 784 Rej. N118 Se Tipo do CT-e = 1 (CT-e complementar): - Verificar se existe o CT-e complementado. Acesso BD CTE (Chave: CNPJ Emit, Modelo, Série, Nro) Obrig. 267 Rej. N119 Se Tipo do CT-e = 1 (CT-e complementar): Acessar BD CTE (Chave: CNPJ Emit, Modelo, Série, Nro) - Verificar se o CT-e complementado existe com diferença na Chave de Obrig. 671 Rej. Conhecimento de Transporte eletrônico MOC CT-e 3.00 Pág. 72 / 231 Validação do CT-e – Regras de Negócio Cód. Regras de Validação Aplic. Msg Efeito Acesso Retornar a chave de acesso já autorizada, o número do protocolo e data de autorização do CT-e [chCTe: 99999999999999999999999999999999999999999999] [nProt:999999999999999][dhAut: AAAA-MM-DDTHH:MM:SS TZD] N120 Se Tipo do CT-e = 1 (CT-e complementar): - CT-e complementado deve ser do tipo Normal ou Substituição. Acessar BD CTE (Chave: CNPJ Emit, Modelo, Série, Nro) Obrig; 491 Rej. N121 Se Tipo do CT-e = 1 (CT-e complementar): - Verificar se o CT-e complementado está com Situação: Autorizado o Uso. Acesso BD CTE (Chave: CNPJ Emit, Modelo, Série, Nro) Obrig. 655 Rej. N122 Se Tipo do CT=e 1 (Complementar): - Verificar o número de Complementos que o CT-e complementado já recebeu, não podendo exceder o limite de 10 CT-e complementares para um mesmo CT-e. Obrig. 520 Rej N123 Se Tipo do CT=e 1 (Complementar) e informado Tomador: - CNPJ/CPF do tomador do CT-e complementar deve ser igual ao informado no CT-e complementado Obrig. 804 Rej N124 Se Tipo do CT=e 1 (Complementar): - IE do emitente do CT-e complementar deve ser igual ao informado no CT- e complementado Obrig. 805 Rej N125 Se Tipo do CT=e 1 (Complementar) e estiver informado Tomador: - IE do tomador do CT-e complementar deve ser igual ao informado no CT-e complementado Obrig. 810 Rej N126 Se Tipo do CT=e 1 (Complementar): - UF de início da prestação do CT-e complementar deve ser igual ao informado no CT-e complementado Obrig. 811 Rej N127 Se Tipo do CT-e=1 (Complementar): - UF de fim da prestação do CT-e Complementar deve ser igual ao informado no CT-e Complementado Obrig. 812 Rej Validações Início e Fim da Prestação N128 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. N129 Código do Município de envio do CT-e inexistente (Tabela Municípios do IBGE) Obrig. 537 Rej. N130 Se informado Município de início da prestação: - Verificar se 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. N131 Se informado Município de início da prestação: - Verificar se existe na Tabela Municípios do IBGE Obrig. 541 Rej. N132 Se informado Município de término da prestação: - Verificar se 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. N133 Se informado Município de término da prestação: - Verificar se existe na Tabela Municípios do IBGE Obrig. 542 Rej. Validações Autorizados ao XML do CT-e N134 Se informada autorização download XML com CNPJ: - Validar CNPJ (zeros ou dígito inválido) Obrig. 699 Rej. N135 Se informada autorização download do XML com CPF: - Validar CPF (zeros, nulo, números repetidos (111,222, etc.), ou dígito de controle inválido) Obrig. 700 Rej. Conhecimento de Transporte eletrônico MOC CT-e 3.00 Pág. 75 / 231 BR05 nRec E BR01 N 1-1 15 Número do Recibo consultado (vide item 6.5). BR06 cStat E BR01 N 1-1 3 Código do status da resposta para o Lote (vide item 6.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 TZD Preenchido com data e hora da gravação do CT-e 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 do 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 6.1). PR12 xMotivo E PR03 C 1-1 1-255 Descrição literal do status da resposta para o CT- e. 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”. Conhecimento de Transporte eletrônico MOC CT-e 3.00 Pág. 76 / 231 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/TLS) # Regra de Validação Crítica Msg Efeito A01 Verificar Certificado de Transmissor: - 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 Verificar Validade do Certificado (data de início e data de fim) Obrig. 281 Rej. A03 Verificar 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 Verificar a LCR do Certificado de Transmissor - Falta o endereço da LCR (CRL DistributionPoint) - LCR indisponível - LCR inválida Obrig. 286 Rej. A05 Verificar se o Certificado do Transmissor está revogado Obrig. 284 Rej. A06 Verificar se o Certificado Raiz difere da “ICP-Brasil” Obrig. 285 Rej. A07 Verificar a 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/TLS e não precisam ser implementadas. A validação A06 também pode ser realizada pelo protocolo, 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 Verificar Tamanho do XML de Dados superior a 500 Kbytes Obrig. 214 Rej. B02 Verificar se o XML de Dados é Mal Formado Facult. 243 Rej. B03 Verificar se o Serviço está Paralisado Momentaneamente Obrig. 108 Rej. B04 Verificar 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. Conhecimento de Transporte eletrônico MOC CT-e 3.00 Pág. 77 / 231 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. 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 Informações de Controle da Chamada ao Web Service # Regra de Validação Aplic. Msg Efeito C01 Verificar se o elemento cteCabecMsg inexiste no SOAP Header Facult. 242 Rej. C02 Verificar se o campo cUF inexiste 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 Verificar se o Campo versaoDados inexiste no elemento cteCabecMsg do SOAP Header Obrig. 411 Rej. C06 Verificar se a Versão dos Dados informada é superior à versão vigente Facult. 238 Rej. C07 Verificar se a 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). 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 Validação da Mensagem do Pedido de Consulta de Lote # Regra de Validação Aplic. Msg Efeito D01 Verificar Schema XML da Área de Dados Obrig. 215 Rej. D02 Verificar a existência de qualquer namespace diverso do namespace padrão do CT-e (http://www.portalfiscal.inf.br/cte) Facul. 598 Rej. D03 Verificar a existência de caracteres de edição no início ou fim da mensagem ou entre as tags Facul. 599 Rej. D04 Verificar o uso de prefixo no namespace Obrig. 404 Rej. D05 Verificar se o XML utiliza codificação diferente de UTF-8 Obrig. 402 Rej. Conhecimento de Transporte eletrônico MOC CT-e 3.00 Pág. 80 / 231 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 6.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 de Carga (modelo 57) e Outros Serviços (modelo 67). 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. Conhecimento de Transporte eletrônico MOC CT-e 3.00 Pág. 81 / 231 IMPORTANTE: O sistema da SEFAZ Autorizadora deverá considerar o modelo informado no pedido de inutilização para aplicar as validações sobre a base de dados do CT-e de Carga (57) ou sobre o CT-e de Outros Serviços (67) no caso da SEFAZ ter optado por trabalhar com bases distintas. 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/TLS) # Regra de Validação Crítica Msg Efeito A01 Verificar a Certificado de Transmissor: - 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 Verificar a Validade do Certificado (data de início e data de fim) Obrig. 281 Rej. A03 Verificar 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 Verificar LCR do Certificado de Transmissor - Falta o endereço da LCR (CRL DistributionPoint) - LCR indisponível - LCR inválida Obrig. 286 Rej. A05 Verificar se o Certificado do Transmissor está revogado Obrig. 284 Rej. A06 Verificar se o Certificado Raiz difere da "ICP-Brasil" Obrig. 285 Rej. A07 Verificar se 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/TLS e não precisam ser implementadas. A validação A06 também pode ser realizada pelo protocolo, 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 Verificar o Tamanho do XML de Dados superior a 500 kBytes Obrig. 214 Rej. B02 Verificar se o XML de Dados é Mal Formado Facult. 243 Rej. B03 Verificar se o Serviço está Paralisado Momentaneamente Obrig. 108 Rej. B04 Verificar 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 Conhecimento de Transporte eletrônico MOC CT-e 3.00 Pág. 82 / 231 (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 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. 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 Informações de Controle da Chamada ao Web Service # Regra de Validação Aplic. Msg Efeito C01 Verificar se o elemento cteCabecMsg inexiste no SOAP Header Facult. 242 Rej. C02 Verificar se campo cUF inexiste 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 Verificar se o campo versaoDados inexiste no elemento cteCabecMsg do SOAP Header Obrig. 411 Rej. C06 Verificar se a Versão dos Dados informada é superior à versão vigente Facult. 238 Rej. C07 Verificar se a 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). 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-e. # Regra de Validação Aplic. Msg Efeito D01 Verificar Schema XML da Área de Dados Obrig. 215 Rej. D02 Verificar a existência de qualquer namespace diverso do namespace padrão do CT-e (http://www.portalfiscal.inf.br/cte) Facul. 598 Rej. Conhecimento de Transporte eletrônico MOC CT-e 3.00 Pág. 85 / 231 4.5 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 -eConsulta 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 (modelos 57 e 67) 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 eletrônico MOC CT-e 3.00 Pág. 86 / 231 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 à 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). 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. 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). O processamento da requisição das consultas deste Web Service será limitado no período de consulta para 180 dias da data de emissão do Conhecimento de Transporte. Atualmente as requisições do WebService de Consulta representam aproximadamente 30% das requisições recebidas no ambiente da SEFAZ Autorizadora, sendo que algumas empresas mantêm processos em “loop” consultando Chaves de Acesso inexistentes, mesmo para CT-e autorizadas em anos anteriores. IMPORTANTE: O sistema da SEFAZ Autorizadora deverá considerar o modelo do documento indicado na chave de acesso para aplicar as validações sobre a base de dados de CT-e de Carga (57) ou sobre o CT-e de Outros Serviços (67) no caso da SEFAZ ter optado por trabalhar com bases distintas. 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/TLS) # Regra de Validação Crítica Msg Efeito A01 Verificar Certificado de Transmissor: - 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 Verificar a Validade do Certificado (data de início e data de fim) Obrig. 281 Rej. Conhecimento de Transporte eletrônico MOC CT-e 3.00 Pág. 87 / 231 A03 Verificar 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 Verificar a LCR do Certificado de Transmissor - Falta o endereço da LCR (CRL DistributionPoint) - LCR indisponível - LCR inválida Obrig. 286 Rej. A05 Verificar se o Certificado do Transmissor está revogado Obrig. 284 Rej. A06 Verificar se o Certificado Raiz difere da "ICP-Brasil" Obrig. 285 Rej. A07 Verificar a 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/TLS e não precisam ser implementadas. A validação A06 também pode ser realizada pelo protocolo, 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 Verificar se oTamanho do XML de Dados superior a 500 kBytes Obrig. 214 Rej. B02 Verificar se o XML de Dados é Mal Formado Facult. 243 Rej. B03 Verificar se o Serviço está Paralisado Momentaneamente Obrig. 108 Rej. B04 Verificar 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 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. Restrição: A consulta situação no Ambiente de Autorização SVC somente poderá ser realizada para documentos autorizados nesta forma de contingência nas SVC-[SP/RS]. Conhecimento de Transporte eletrônico MOC CT-e 3.00 Pág. 90 / 231 4.6 Web Service – CteStatusServico Consulta Status do Serviço Ret Contribuinte Client CTe Secretaria de Fazenda Estadual Aplicação CT -e Consulta StatusConsulta Status Retorno cteStatusServicoCT Web Service : CteStatusServico Proc. Função: serviço destinado à consulta do status do serviço prestado pelo Portal da Secretaria de Fazenda Estadual. Processo: síncrono. Método: cteStatusServicoCT Leiaute Mensagem de Entrada Entrada: Estrutura XML para a consulta do status do serviço. Schema XML: consStatServCTe_v99.99.xsd # Campo Ele Pai Tipo Ocor. Tam. Dec. Descrição/Observação FP01 consStatServCte Raiz - - - - TAG raiz FP02 versao A FP01 N 1-1 1-4 2 Versão do leiaute FP03 tpAmb E FP01 N 1-1 1 Identificação do Ambiente: 1 – Produção / 2 - Homologação FP04 xServ E FP01 C 1-1 6 Serviço solicitado ‘STATUS’ Leiaute Mensagem de Retorno Retorno: Estrutura XML contendo a mensagem do resultado da consulta do status do serviço: Schema XML: retConsStatServCTe _v99.99.xsd # Campo Ele Pai Tipo Ocor. Tam. Dec. Descrição/Observação FR01 retConsStatServCte Raiz - - - - TAG raiz da Resposta FR02 versao A FR01 N 1-1 1-4 2 Versão do leiaute FR03 tpAmb E FR01 N 1-1 1 Identificação do Ambiente: 1 – Produção / 2 - Homologação FR04 verAplic E FR01 C 1-1 1-20 Versão do Aplicativo que processou a consulta FR05 cStat E FR01 N 1-1 3 Código do status da resposta Conhecimento de Transporte eletrônico MOC CT-e 3.00 Pág. 91 / 231 FR06 xMotivo E FR01 C 1-1 1-255 Descrição literal do status da resposta FR07 cUF E FR01 N 1-1 2 Código da UF que atendeu a solicitação FR08 dhRecbto E FR01 D 1-1 - Data e hora de recebimento Formato = AAAA-MM-DDTHH:MM:SS TZD Preenchido com data e hora do recebimento do Pedido FR09 tMed E FR01 N 0-1 1-4 Tempo médio de resposta do serviço (em segundos) dos últimos 5 minutos FR10 dhRetorno E FR01 D 0-1 - Preencher com data e hora previstas para o retorno do Web Service, no formato AAA-MM- DDTHH:MM:SS FR11 xObs E FR01 C 0-1 1-255 Informações adicionais para o Contribuinte Descrição do Processo de Web Service Esse método responsabiliza-se por receber as solicitações referentes à consulta do status do serviço do Portal da Secretaria de Fazenda Estadual. O aplicativo do contribuinte envia a solicitação para o Web Service da Secretaria de Fazenda Estadual. Ao receber a solicitação, a aplicação do Portal da Secretaria de Fazenda Estadual processará a solicitação de consulta e retornará mensagem contendo o status do serviço. A empresa que construir aplicativo que se mantenha em permanente "loop" de consulta a este Web Service, deverá aguardar um tempo mínimo de 3 minutos entre uma consulta e outra, evitando sobrecarga desnecessária dos servidores da SEFAZ autorizadora. 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/TLS) # Regra de Validação Crítica Msg Efeito A01 Verificar Certificado de Transmissor: - 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 Verificar a Validade do Certificado (data de início e data de fim) Obrig. 281 Rej. A03 Verificar 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 Verificar a LCR do Certificado de Transmissor - Falta o endereço da LCR (CRL DistributionPoint) - LCR indisponível - LCR inválida Obrig. 286 Rej. A05 Verificar se o Certificado do Transmissor está revogado Obrig. 284 Rej. A06 Verificar se o Certificado Raiz difere da "ICP-Brasil" Obrig. 285 Rej. A07 Verificar a Falta da 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/TLS e não precisam ser implementadas. A validação A06 também pode ser realizada pelo protocolo, mas Conhecimento de Transporte eletrônico MOC CT-e 3.00 Pág. 92 / 231 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 Verificar se o tamanho do XML de Dados é superior a 500 Kbytes Obrig. 214 Rej. B02 Verificar se o XML de Dados é Mal Formado Facult. 243 Rej. B03 Verificar se o Serviço está Paralisado Momentaneamente Obrig. 108 Rej. B04 Verificar 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 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. Validação das Informações de Controle da Chamada ao Web Service Validação das Informações de Controle da Chamada ao Web Service # Regra de Validação Aplic. Msg Efeito C01 Verificar se o elemento cteCabecMsg inexiste no SOAP Header Facult. 242 Rej. C02 Verificar se o campo cUF inexiste 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 Se Ambiente de Autorização SVC: Verificar se SVC está ativa para a UF informada Obrig. 114 Rej. C06 Verificar se o campo versaoDados inexiste no elemento cteCabecMsg do SOAP Header Obrig. 411 Rej. C07 Verificar se a versão dos Dados informada é superior à versão vigente Facult. 238 Rej. C08 Verificar se a 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). Conhecimento de Transporte eletrônico MOC CT-e 3.00 Pág. 95 / 231 Onde Obter as Definições deste Web Service As definições do Web Service de Consulta Cadastro encontram-se centralizadas no manual da Nota Fiscal Eletrônica. Para informações mais detalhadas, consultar o Manual de Orientações do Contribuinte da NF-e, disponível em http://www.nfe.fazenda.gov.br. Onde Obter os Schemas XML deste Web Service Os schemas XML utilizados pelo Web Service de Consulta Cadastro encontram-se disponíveis no endereço http://www.nfe.fazenda.gov.br. Conhecimento de Transporte eletrônico MOC CT-e 3.00 Pág. 96 / 231 4.8 Sistema de Registro de Eventos Função: serviço destinado à recepção de mensagem de Evento do CT-e de Carga (57) e Outros Serviços (67) Processo: síncrono. Método: cteRecepcaoEvento Leiaute Mensagem de Entrada Entrada: Estrutura XML com o Evento (Parte Geral) Schema XML: eventoCTe_v9.99.xsd # Campo Ele Pai Tipo Ocor. Tam. Dec. Descrição/Observação EP01 eventoCTe Raiz - - - - TAG raiz EP02 versao A EP01 N 1-1 1-4 2 Versão do leiaute geral dos eventos EP03 infEvento G EP01 1-1 Grupo de informações do registro do Evento EP04 Id ID EP03 C 1-1 54 Identificador da TAG a ser assinada, a regra de formação do Id é: “ID” + tpEvento+ chave do CT-e+ nSeqEvento EP05 cOrgao E EP03 N 1-1 2 Código do órgão de recepção do Evento. Utilizar a Tabela do IBGE extendida, utilizar 90 para identificar SUFRAMA EP06 tpAmb E EP03 N 1-1 1 Identificação do Ambiente: 1 – Produção 2 – Homologação EP07 CNPJ E EP03 N 1-1 14 Informar o CNPJ do autor do Evento EP08 chCTe E EP03 N 1-1 44 Chave de Acesso do CT-e vinculado ao Evento EP09 dhEvento E EP03 D 1-1 Data e hora do evento no formato AAAA-MM- DDThh:mm:ss TZD EP10 tpEvento E EP03 N 1-1 6 Tipo do Evento EP11 nSeqEvento E EP03 N 1-1 1-2 Sequencial do evento para o mesmo tipo de evento. Para maioria dos eventos será 1, nos casos em que possa existir mais de um evento o autor do evento deve numerar de forma sequencial. EP12 detEvento G EP03 - 1-1 Informações do evento específico. EP13 versaoEvento A EP12 N 1-1 1-4 2 Versão do leiaute específico do evento. EP14 any E EP12 XML 1-1 XML do evento. Insira neste local o XML específico do tipo de evento (cancelamento, Sistema de Registro de Eventos Ret Emissor CT-e Cliente SRE WS da Fazenda Aplicação SRE Recepção Envio de Evento do CT-e Retorno cteRecepcaoEvento Web Service : RecepcaoEvento Proc . Conhecimento de Transporte eletrônico MOC CT-e 3.00 Pág. 97 / 231 EPEC, carta de correção). EP15 Signature G EP01 XML 1-1 Assinatura XML do grupo identificado pelo atributo “Id” Diagrama Simplificado do Schema: eventoCTe_v9.99.xsd Leiaute Mensagem de Retorno Retorno: Estrutura XML contendo a mensagem do resultado do evento: Schema XML: retEventoCTe _v99.99.xsd # Campo Ele Pai Tip o Ocor. Tam. Dec. Descrição/Observação ER01 retEventoCTe Raiz - - - - TAG raiz do Resultado do Envio do Evento ER02 versao A ER01 N 1-1 1-4 2 Versão do leiaute ER03 infEvento G ER01 1-1 Grupo de informações do registro do Evento ER04 Id ID ER03 C 0-1 17 Identificador da TAG a ser assinada, somente deve ser informado se o órgão de registro assinar a resposta. Em caso de assinatura da resposta pelo órgão de registro, preencher com o número do protocolo, precedido pela literal “ID” ER05 tpAmb E ER03 N 1-1 1 Identificação do Ambiente: 1 – Produção / 2 – Homologação ER06 verAplic E ER03 C 1-1 1-20 Versão da aplicação que registrou o Evento, utilizar literal que permita a identificação do órgão, como a sigla da UF ou do órgão.