CT-e 2015: Novas Regras de Validação e Schema Fiscal Detalhados

O Projeto Conhecimento de Transporte Eletrônico (CT-e) passa por atualizações frequentes para garantir a integridade dos dados e a conformidade fiscal. Em abril de 2015, a Nota Técnica 2015/001 foi divulgada, detalhando alterações nas regras de validação, nos schemas e no layout do Documento Auxiliar do Conhecimento de Transporte Eletrônico (DACTE). O objetivo é aprimorar o controle sobre a emissão do documento fiscal e suas informações relacionadas.

Cronograma de Implementação

A implementação das novas regras de validação e schemas do CT-e ocorreu em etapas distintas, visando uma transição organizada para os contribuintes.

Regras de Validação

As novas regras de validação foram disponibilizadas primeiramente para ambiente de homologação e, posteriormente, para produção.

• Homologação: De 1º de maio de 2015 a 1º de junho de 2015.
• Produção: De 1º de junho de 2015 a 1º de agosto de 2015.

Schemas

Os schemas do CT-e, que definem a estrutura dos arquivos XML, também seguiram um cronograma específico para sua liberação.

• Homologação: 1º de maio de 2015.
• Produção: 1º de junho de 2015.

Novas Regras de Validação para WebService – Receção

A Nota Técnica 2015/001 introduziu uma série de regras de validação no WebService de Receção de CT-e, aplicáveis a diferentes cenários de emissão, como CT-e Normal, de Substituição e Complementar. O descumprimento dessas regras resulta na rejeição do documento.

Duplicidade de Chaves de Acesso

A emissão de um CT-e requer que as chaves de acesso de documentos referenciados sejam únicas dentro do próprio CT-e ou em documentos anteriores.

• NF-e duplicada no CT-e (G035a): Se um CT-e do tipo Normal ou de Substituição informar o grupo de Informações de Documentos (infDoc) e o grupo de NF-e (infNFe), o sistema verificará se há alguma chave de acesso de NF-e duplicada. A duplicidade levará à rejeição (código 527), indicando a chave duplicada.
• CT-e anterior duplicado (G053b): No caso de CT-e que informa documentos eletrônicos anteriores (idDocAntEle), o sistema rejeitará (código 543) o documento se detectar chaves de acesso de CT-e duplicadas entre esses documentos anteriores.

Chaves de Acesso Inválidas (NF-e e CT-e Anteriores)

A validade das chaves de acesso das NF-e e CT-e anteriores ou referenciados é verificada de forma rigorosa, abrangendo diversos aspectos do formato da chave.

• Tipo de emissão inválido (G041a, G053i, G054g): Chaves de acesso de NF-e (código 508) ou CT-e anteriores (código 480) ou referenciados (código 479) com tipo de emissão inválido resultarão em rejeição do CT-e.
• UF inválida (G041b, G053j, G054h): Uma NF-e (código 504), CT-e anterior (código 538) ou CT-e referenciado (código 608) com a Unidade da Federação (UF) inválida na chave de acesso provocará a rejeição.
• Ano e mês inválidos (G053d, G053e, G054b, G054c): A chave de acesso de um CT-e anterior será rejeitada se o ano for anterior a 2009 ou maior que o ano corrente (código 545), ou se o mês for igual a zero ou maior que 12 (código 546). Similarmente, para um CT-e referenciado, as chaves com ano fora do período (código 451) ou mês inválido (código 452) serão rejeitadas.
• CNPJ zerado ou inválido (G053f, G054d): Chaves de acesso de CT-e anterior (código 547) ou referenciado (código 453) com o CNPJ do emitente zerado ou com dígito verificador inválido não serão aceitas.
• Modelo diferente de 57 (G053g, G054e): O modelo do documento fiscal referenciado na chave de acesso deve ser o 57, que corresponde ao CT-e. Se for diferente, o CT-e anterior (código 548) ou referenciado (código 454) terá sua chave rejeitada.
• Número do CT-e igual a zero (G053h, G054f): Chaves de acesso de CT-e anterior (código 549) ou referenciado (código 478) com o número do CT-e igual a zero serão rejeitadas.
• Dígito Verificador inválido (G053c, G054a): A existência de um dígito verificador inválido na chave de acesso de um CT-e anterior (código 544) ou referenciado (código 450) resultará na rejeição do CT-e principal.

CFOP Inválido

A regra G048b estabelece que, para CT-e do tipo Normal, Complementar ou Substituição, se a UF do emitente for diferente da UF de início da prestação e esta, por sua vez, for diferente de "EX" (Exterior), o Código Fiscal de Operações e Prestações (CFOP) deve ser obrigatoriamente 5932 (Prestação de serviço de transporte iniciada em UF diversa daquela onde foi efetuado o serviço) ou 6932 (Prestação de serviço de transporte iniciada em UF diversa daquela onde foi efetuado o serviço). Qualquer outro CFOP resultará em rejeição (código 524).

Municípios Inexistentes (IBGE)

A validação dos códigos de municípios informados no CT-e agora se baseia na Tabela de Municípios do Instituto Brasileiro de Geografia e Estatística (IBGE), garantindo a precisão dos endereços.

• Remetente, Destinatário, Expedidor, Recebedor, Tomador (G113a, G121a, G129a, G137a, G145a): Se o código do município de qualquer um desses participantes (Remetente, Destinatário, Expedidor, Recebedor, Tomador) não existir na tabela IBGE, o CT-e será rejeitado (códigos 532, 533, 534, 535, 536, respectivamente).
• Municípios de envio, início e término da prestação (G166a, G168a, G170a): Similarmente, a inexistência do código do município de envio do CT-e (código 537), do município de início da prestação (código 541) ou do município de término da prestação (código 542) na tabela IBGE causará a rejeição do documento.

Validação de Valores

A regra G181 impõe que o Valor a Receber (vRec) deve ser menor ou igual ao Valor da Prestação do Serviço (vtPrest). Caso contrário, o CT-e será rejeitado (código 531). Essa validação garante a consistência financeira da prestação.

Validações em WebService – Consulta Protocolo

No WebService de Consulta Protocolo, foram implementadas validações para as chaves de acesso.

• Chave de acesso inválida (J08a, J08b): Uma chave de acesso com tipo de emissão inválido (código 507) ou UF inválida (código 610) será rejeitada durante a consulta.

Validações em WebService – Eventos

As regras de validação para eventos do CT-e também foram atualizadas, com foco em ambientes de autorização e em cenários específicos de cancelamento.

Eventos Gerais

• Ambiente de Autorização SVC (L07a): Se o ambiente de autorização for o Sistema de Contingência Virtual (SVC), o tipo de evento deve ser obrigatoriamente EPEC (Evento Prévio de Emissão em Contingência, código 110113) ou Cancelamento (código 110111). Eventos diferentes desses serão rejeitados (código 530).

Cancelamento de CT-e

O cancelamento de um CT-e possui restrições adicionais para garantir a integridade dos processos fiscais relacionados.

• CT-e com MDF-e autorizado (M17): É vedado o cancelamento de um CT-e se existir um Manifesto Eletrônico de Documentos Fiscais (MDF-e) Autorizado que referencie esse CT-e. Para que o CT-e possa ser cancelado, o MDF-e correspondente também deve ser cancelado, e deve existir um evento de Cancelamento do MDF-e. A tentativa de cancelar nesses casos será rejeitada (código 528).
• CT-e Multimodal com CT-e Vinculado (M18): Se o CT-e for do tipo Multimodal, o cancelamento será vedado caso exista um evento de CT-e Vinculado a Multimodal em situação autorizado referenciando o CT-e Multimodal. A rejeição ocorrerá (código 529) para preservar a cadeia de transporte multimodal.

Ajustes nos Schemas do CT-e

A Nota Técnica 2015/001 promoveu alterações estruturais nos schemas XML do CT-e, impactando a forma como os dados são preenchidos e validados.

• Tags de texto: A expressão regular para as tags xNome (Nome ou Razão Social), xFant (Nome Fantasia), xBairro (Bairro), xLgr (Logradouro), xMun (Município) e xPais (País) foi alterada de 1-60 para 2-60 caracteres. Isso significa que esses campos devem ter no mínimo 2 caracteres.
• Tag nroItem (CC-e): Foi criada uma expressão regular para a tag nroItem no evento Carta de Correção Eletrônica (CC-e), permitindo valores de 1 a 99.
• Tag forPag (Forma de Pagamento): A tag forPag (Forma de Pagamento) passou a ser opcional no schema. A recomendação é que não seja mais preenchida, pois será removida em versões futuras.
• Grupos de localização: Os grupos opcionais de local da entrega (dest\locEnt) e local da coleta (rem\locColeta) foram removidos do schema.
• Tags de quantidade: A expressão regular das tags qtdRat nos grupos de Unidade de Carga e Unidade de Transporte foi alterada para aceitar formatos numéricos de 3 inteiros e 2 decimais (3,2) ou 3 inteiros e 3 decimais (3,3).
• Tag unidRat: A expressão regular da tag unidRat do modal Aquaviário também foi alterada para aceitar 3 inteiros e 2 decimais (3,2) ou 3 inteiros e 3 decimais (3,3).

Mensagens de Rejeição Adicionais

A Nota Técnica 2015/001 introduziu novas mensagens de rejeição para cobrir os cenários das regras de validação atualizadas, fornecendo feedback mais específico sobre o motivo da falha. Algumas das novas mensagens incluem:

• 450: Rejeição: Dígito Verificador inválido na Chave de acesso de CT-e referenciado.
• 451: Rejeição: Chave de acesso de CT-e referenciado inválida (Ano < 2009 ou Ano maior que Ano corrente).
• 452: Rejeição: Chave de acesso de CT-e referenciado inválida (Mês = 0 ou Mês > 12).
• 453: Rejeição: Chave de acesso de CT-e referenciado inválida (CNPJ zerado ou dígito inválido).
• 454: Rejeição: Chave de acesso de CT-e referenciado inválida (modelo diferente de 57).
• 478: Rejeição: Chave de acesso de CT-e referenciado inválida (número CT = 0).
• 479: Rejeição: Chave de acesso de CT-e referenciado inválida (Tipo de emissão inválido).
• 480: Rejeição: Chave de Acesso de CT-e anterior inválida (Tipo de emissão inválido).
• 504: Rejeição: Chave de acesso de NF-e inválida (UF inválida).
• 507: Rejeição: Chave de Acesso inválida (Tipo de emissão inválido).
• 508: Rejeição: Chave de Acesso de NF-e inválida (Tipo de emissão inválido).
• 524: Rejeição: CFOP inválido, informar 5932 ou 6932.
• 527: Rejeição: NF-e duplicada no CT-e.
• 528: Rejeição: Vedado cancelamento se existir MDF-e autorizado para o CT-e.
• 529: Rejeição: Vedado cancelamento do CT-e Multimodal se existir CT-e de serviço vinculado autorizado referenciando o Multimodal.
• 530: Rejeição: Se ambiente SVC, rejeitar eventos diferentes de EPEC e Cancelamento.
• 531: Rejeição: Valor a receber deve ser menor ou igual Valor da Prestação.
• 532-537, 541, 542: Rejeição: Município do Remetente/Destinatário/Expedidor/Recebedor/Tomador/Envio/Início da prestação/Término da prestação inexistente.
• 538: Rejeição: Chave de acesso de CT-e anterior inválida (UF inválida).
• 543: Rejeição: Chave de CT-e duplicada em documentos anteriores.
• 544-549: Rejeição: Dígito Verificador inválido na Chave de acesso de CT-e anterior, ou Chave de acesso de CT-e anterior inválida (Ano, Mês, CNPJ, modelo, número CT = 0).
• 608: Rejeição: Chave de acesso de CT-e referenciado inválida (UF inválida).
• 610: Rejeição: Chave de acesso inválida (UF inválida).

Correlação de Campos XML, CT-e e DACTE

A Nota Técnica 2015/001 também trouxe uma correção na correlação entre os campos do XML do CT-e, os campos do CT-e propriamente dito e o DACTE, para garantir a representação correta das informações tributárias.

Quadro do DACTE	Campo do DACTE	Tag XML do CT-e
Informações Relativas ao imposto	Situação Tributária	CST (Código de Situação Tributária)
Informações Relativas ao imposto	Base de Cálculo	vBC (Valor da Base de Cálculo), vBCSTRet (Valor da Base de Cálculo do ICMS de Substituição Tributária Retido), ou vBCOutraUF (Valor da Base de Cálculo de Outra UF)
Informações Relativas ao imposto	Alíquota ICMS	pICMS (Percentual do ICMS), pICMSSTRet (Percentual do ICMS de Substituição Tributária Retido), ou pICMSOutraUF (Percentual do ICMS de Outra UF)
Informações Relativas ao imposto	Valor ICMS	vICMS (Valor do ICMS), vICMSSTRet (Valor do ICMS de Substituição Tributária Retido), ou vICMSOutraUF (Valor do ICMS de Outra UF)
Informações Relativas ao imposto	% Redução BC. Cálc.	pRedBC (Percentual de Redução da Base de Cálculo) ou pRedBCOutraUF (Percentual de Redução da Base de Cálculo de Outra UF)

Esta tabela corrige a forma como as informações de imposto, como Situação Tributária, Base de Cálculo, Alíquota e Valor do ICMS, além do Percentual de Redução da Base de Cálculo, são mapeadas entre os dados digitais do XML e a representação visual no DACTE.

Conclusão

As alterações trazidas pela Nota Técnica 2015/001 para o Conhecimento de Transporte Eletrônico visam aprimorar a qualidade dos dados e a conformidade fiscal. Contribuintes e desenvolvedores devem ajustar seus sistemas para atender às novas regras de validação, modificações nos schemas e entender as novas mensagens de rejeição. A atenção aos detalhes nas chaves de acesso, códigos de municípios e valores é fundamental para evitar rejeições e garantir a emissão correta do CT-e.