CT-e: Alterações em validação e Fundo de Combate à Pobreza

A Nota Técnica 2015/004 do Conhecimento de Transporte Eletrônico introduziu novas regras de validação e incluiu campos específicos para o Fundo de Combate à Pobreza (FCP) no CT-e. Essas mudanças complementam as alterações trazidas pela Emenda Constitucional 87 (EC 87), impactando transportadoras e embarcadores. O objetivo é garantir a conformidade dos documentos fiscais eletrônicos com a legislação tributária vigente.

Nota Técnica 2015/004 e suas atualizações

A Nota Técnica 2015/004 divulgou diretrizes para o Conhecimento de Transporte Eletrônico, com foco em novas validações e na integração de informações relativas ao Fundo de Combate à Pobreza. As alterações foram publicadas em fevereiro de 2016 e revisadas em março do mesmo ano, com a suspensão de algumas validações e modificação de outras.

Resumo das mudanças

O documento estabelece que o CT-e deve se adequar às exigências fiscais para operações interestaduais destinadas a consumidores finais não contribuintes do ICMS. Para isso, novas regras de validação foram implementadas, e o schema do CT-e foi atualizado para contemplar os valores do FCP. A inclusão destas tags permite a correta discriminação e apuração do fundo, conforme a EC 87.

Cronograma de disponibilização

As novas regras e o schema atualizado foram disponibilizados em fases, seguindo ambientes de homologação e produção para permitir a adaptação dos sistemas.

As datas para as regras de validação seguiram o seguinte cronograma:

• Homologação: 01/01/2016 a 01/03/2016
• Produção: 01/02/2016 a 04/04/2016

Os schemas com as tags do Fundo de Combate à Pobreza tiveram as seguintes datas de liberação:

• Homologação: 01/12/2015
• Produção: 15/12/2015

Novas regras de validação do CT-e (WebService - Recepcão)

A Nota Técnica 2015/004 introduziu um conjunto de regras de validação que são aplicadas no WebService de recepção do CT-e. O objetivo é garantir a integridade e a conformidade das informações prestadas, evitando inconsistências fiscais.

Validação de documentos eletrônicos anteriores

Ao informar documentos eletrônicos anteriores (grupo idDocAntEle), o CT-e está sujeito a validações específicas:

• Tipo de serviço Normal (Rejeição 747): A autoridade fiscal rejeita o CT-e se forem informados documentos eletrônicos anteriores e o tipo de serviço do CT-e for Normal (código 0). Esta validação garante que referências a documentos anteriores sejam feitas em tipos de serviço específicos, como complementares ou de substituição, e não em operações de transporte comum.
• Divergência de CNPJ do emitente (Rejeição 733): O CT-e é rejeitado se o CNPJ do emitente de qualquer CT-e referenciado for diferente do CNPJ do emissor indicado no grupo emiDocAnt/CNPJ, ou se for informado um CPF. A regra assegura que a rastreabilidade e a correlação entre os documentos fiscais anteriores e o CT-e atual sejam consistentes, evitando fraudes ou erros de identificação.
• CNPJ base do tomador diferente do CNPJ base do emitente (Rejeição 745): O sistema rejeita o CT-e se o CNPJ base do tomador de serviço divergir do CNPJ base do emissor indicado no grupo emiDocAnt. Esta validação mantém a integridade dos dados fiscais e a correta identificação das partes envolvidas na operação de transporte.
• Tomador emitente de CT-e (Rejeição 746): O documento será rejeitado se o tomador do serviço for um emitente de CT-e (verificado pelo Cadastro Nacional de Emitentes - CNE) e o CNPJ Base deste tomador for diferente do CNPJ Base do Remetente ou Destinatário. Esta regra foi posteriormente suspensa até a versão 3.00 do CT-e e alterada, indicando sua sensibilidade e revisão.
• CT-e referenciado inexistente (Rejeição 748): Ocorre rejeição se os CT-e informados no grupo DocAnt (através da chave de acesso chCTe) não existirem na base de dados da Sefaz. Esta validação, de aplicação facultativa, garante a autenticidade dos documentos referenciados.
• CT-e referenciado com diferença de chave de acesso (Rejeição 749): O CT-e é rejeitado se os documentos anteriores informados existirem, mas com uma chave de acesso diferente da registrada. Esta regra, também facultativa, assegura a unicidade e a correção das chaves de acesso.
• CT-e referenciado cancelado ou denegado (Rejeição 750): Ocorre rejeição se o CT-e referenciado em documentos anteriores estiver cancelado ou denegado. Essa validação impede que documentos com status fiscal irregular sejam utilizados como referência.

Validação de dados do emitente

Aspectos geográficos e cadastrais do emitente são validados para garantir a conformidade:

• Divergência UF do município (Rejeição 712): Ocorre rejeição se o código do município do emitente divergir da sigla da UF informada. Os dois primeiros dígitos do código de município devem ser compatíveis com o código da UF.
• Código de município inexistente (Rejeição 713): O CT-e é rejeitado se o código do município do emitente não constar na Tabela de Municípios do IBGE.

Regras para CT-e Complementar

Um CT-e complementar (tipo 1) deve seguir regras específicas de validação:

• CT-e complementado diferente de Normal ou Substituição (Rejeição 491): O documento será rejeitado se o CT-e que está sendo complementado não for do tipo Normal ou Substituição. Isso garante a correta aplicação do CT-e complementar, que se destina a ajustar valores de documentos fiscais válidos.
• Chave de acesso inválida (Rejeições 777 a 784): Ocorre rejeição se o dígito verificador da chave de acesso do CT-e complementado for inválido, ou se a chave de acesso apresentar ano ou mês inválidos, CNPJ zerado ou com dígito inválido, modelo diferente de 57, número de CT igual a zero, tipo de emissão inválido ou UF inválida.

Regras para CT-e EPEC

O CT-e emitido em contingência por EPEC (Evento Prévio de Emissão em Contingência) também possui validações:

• Tipo de CT-e diferente de Normal (Rejeição 720): O sistema rejeita o CT-e se a forma de emissão for EPEC (código 4) e o tipo de CT-e for diferente de Normal. A emissão por EPEC é prevista para contingências de documentos normais.
• Data de emissão da EPEC (Rejeição 697): A data de emissão do CT-e deve ser menor ou igual à data de autorização do evento prévio da EPEC. Esta regra assegura a cronologia correta dos eventos fiscais.

Validação de autorização de download XML

• Duplicidade de CPF/CNPJ (Rejeição 715): Se houver informação para autorização de download do XML, é verificada a duplicidade de CPF/CNPJ informado no CT-e. A rejeição ocorre se houver repetição, visando a unicidade dos dados.

Regras para CT-e de Anulação

Para um CT-e de Anulação (tipo 2), a chave de acesso do CT-e original é rigorosamente validada:

• Dígito verificador inválido (Rejeição 761): O CT-e é rejeitado se o dígito verificador da chave de acesso do CT-e a ser anulado for inválido.
• Chave de acesso inválida (Rejeições 762 a 768): A anulação é rejeitada se a chave de acesso do CT-e objeto da anulação for inválida, seja por ano (< 2009 ou > ano corrente), mês (0 ou > 12), CNPJ (zerado ou dígito inválido), modelo (diferente de 57), número (igual a 0), tipo de emissão ou UF inválida. Estas validações garantem que apenas documentos válidos possam ser anulados.

Regras para CT-e de Substituição

Similarmente, para um CT-e de Substituição (tipo 3), a chave de acesso do CT-e substituído passa por validações:

• Dígito verificador inválido (Rejeição 769): O CT-e é rejeitado se o dígito verificador da chave de acesso do CT-e substituído for inválido.
• Chave de acesso inválida (Rejeições 770 a 776): A substituição é rejeitada se a chave de acesso do CT-e substituído for inválida por ano (< 2009 ou > ano corrente), mês (0 ou > 12), CNPJ (zerado ou dígito inválido), modelo (diferente de 57), número (igual a 0), tipo de emissão ou UF inválida.

Alterações em regras existentes (WebService - Recepcão)

Além das novas regras, a Nota Técnica 2015/004 também alterou validações para serviços específicos.

Serviço vinculado a multimodal

A regra G057 (Rejeição 667) foi alterada para o Tipo de Serviço "Serviço Vinculado a Multimodal". Neste caso, o CNPJ Base do Tomador do serviço deve ser idêntico ao CNPJ Base do Emitente do CT-e referenciado, que deve ser obtido a partir da chave de acesso (refCTe). Esta validação impede que o tomador do serviço multimodal seja uma entidade diferente da que emitiu o CT-e original, garantindo a correta vinculação da operação.

Regras para consulta de protocolo (WebService - Consulta Protocolo)

A consulta a protocolos de CT-e também teve uma nova regra implementada para evitar consultas a documentos muito antigos.

• Atraso na chave de acesso (Rejeição 731): O sistema rejeita a consulta se o Ano-Mês da Chave de Acesso do CT-e estiver com atraso superior a 6 meses em relação ao Ano-Mês atual. Esta regra visa otimizar os recursos do WebService, focando em consultas de documentos mais recentes.

Resposta de eventos (WebService - Recepcão Eventos)

Na ocorrência de duplicidade de eventos, o sistema de autorização da Sefaz foi aprimorado para fornecer mais detalhes na mensagem de rejeição.

• Duplicidade de evento (Rejeição 631): Quando um evento é rejeitado por duplicidade, a mensagem de retorno agora inclui o número do protocolo (nProt) e a data de autorização (dhRegEvento) do evento já registrado no sistema. Isso facilita a identificação do evento duplicado e agiliza a correção por parte do emitente.

Alterações de esquema e Fundo de Combate à Pobreza (FCP)

Uma das mudanças centrais da Nota Técnica 2015/004 foi a inclusão de novas tags no esquema XML do CT-e para o tratamento do Fundo de Combate à Pobreza (FCP). Estas tags são essenciais para as operações interestaduais destinadas a consumidor final não contribuinte do ICMS, conforme estabelecido pela Emenda Constitucional 87.

As tags foram criadas dentro do grupo ICMSUFFim, que representa as informações do ICMS de partilha com a Unidade da Federação de término do serviço de transporte. Este grupo é informado para consumidor final não contribuinte do ICMS.

As novas tags e seus significados são:

• vBCUFFim (Valor da Base de Cálculo do ICMS na UF de término da prestação do serviço de transporte): Um campo numérico de 15 posições, com 13 inteiras e 2 decimais, que registra a base de cálculo para o ICMS na UF de destino.
• pFCPUFFim (Percentual de ICMS correspondente ao Fundo de Combate à Pobreza na UF de término da prestação): Campo numérico de 5 posições, com 3 inteiras e 2 decimais, que indica a alíquota percentual do FCP aplicável na UF de destino.
• pICMSUFFim (Alíquota interna da UF de término da prestação do serviço de transporte): Campo numérico de 5 posições, com 3 inteiras e 2 decimais, para registrar a alíquota interna do ICMS adotada nas operações internas na UF do destinatário.
• pICMSInter (Alíquota interestadual das UF envolvidas): Campo numérico de 5 posições, com 3 inteiras e 2 decimais, que informa a alíquota interestadual do ICMS aplicada na operação.
• pICMSInterPart (Percentual provisório de partilha entre os estados): Campo numérico de 5 posições, com 3 inteiras e 2 decimais, que indica o percentual de partilha do ICMS para a UF do destinatário. A nota técnica detalha a progressão desse percentual:
  • 40% em 2016
  • 60% em 2017
  • 80% em 2018
  • 100% a partir de 2019
• vFCPUFFim (Valor de ICMS correspondente ao Fundo de Combate à Pobreza na UF de término da prestação): Campo numérico de 15 posições, com 13 inteiras e 2 decimais, que registra o valor total do FCP devido à UF de destino.
• vICMSUFFim (Valor do ICMS de partilha para a UF de término da prestação do serviço de transporte): Campo numérico de 15 posições, com 13 inteiras e 2 decimais, que indica o valor do ICMS a ser partilhado com a UF de término da prestação.
• vICMSUFIni (Valor do ICMS de partilha para a UF de início da prestação do serviço de transporte): Campo numérico de 15 posições, com 13 inteiras e 2 decimais, que registra o valor do ICMS a ser partilhado com a UF de início da prestação.

Essas tags garantem que as informações detalhadas sobre a partilha do ICMS e o FCP sejam corretamente discriminadas no CT-e, facilitando a fiscalização e a arrecadação dos tributos pelas Secretarias da Fazenda.

Mensagens de validação e rejeição

A Nota Técnica 2015/004 detalha as mensagens de rejeição para cada regra de validação, oferecendo clareza sobre os motivos de não atendimento das solicitações de autorização do CT-e. A compreensão desses códigos é fundamental para a correção de erros.

Alguns dos códigos de rejeição incluem:

• 667: CNPJ-Base do Tomador deve ser igual ao CNPJ-Base do Emitente do CT-e Multimodal.
• 697: Data de emissão do CT-e deve ser menor ou igual à data de autorização da EPEC.
• 747: Documentos anteriores eletrônicos informados para Tipo de Serviço Normal.
• 733: CNPJ do documento anterior deve ser o mesmo indicado no grupo emiDocAnt.
• 745: CNPJ base do tomador deve ser igual ao CNPJ base indicado no grupo emiDocAnt.
• 746: Tipo de Serviço inválido para o tomador informado (suspensa até a versão 3.00).
• 748: CT-e referenciado em documentos anteriores inexistente na base de dados da Sefaz.
• 749: CT-e referenciado em documentos anteriores existe com diferença de chave de acesso.
• 750: CT-e referenciado em documentos anteriores não pode estar cancelado ou denegado.
• 712: Código de Município diverge da UF de localização do emitente.
• 713: Município do Emitente inexistente.
• 491: CT-e complementado diferente de Normal ou Substituição.
• 720: CT-e EPEC deve ser do tipo Normal.
• 715: Documento autorizado ao XML duplicado no CT-e.
• 731: Consulta a uma Chave de Acesso muito antiga.
• 761-768: Diversas rejeições relacionadas a chaves de acesso inválidas para CT-e de Anulação (dígito, ano, mês, CNPJ, modelo, número, tipo de emissão, UF).
• 769-776: Diversas rejeições relacionadas a chaves de acesso inválidas para CT-e de Substituição (dígito, ano, mês, CNPJ, modelo, número, tipo de emissão, UF).
• 777-784: Diversas rejeições relacionadas a chaves de acesso inválidas para CT-e Complementar (dígito, ano, mês, CNPJ, modelo, número, tipo de emissão, UF).

Estas mensagens detalhadas fornecem um feedback preciso aos contribuintes, permitindo a correção pontual dos erros de preenchimento ou validação e a subsequente autorização do CT-e.

Conclusão

A Nota Técnica 2015/004 trouxe atualizações importantes para o Conhecimento de Transporte Eletrônico, com a implementação de novas regras de validação e a inclusão das tags para o Fundo de Combate à Pobreza. Essas mudanças são essenciais para a conformidade fiscal das operações de transporte, especialmente aquelas que envolvem a partilha de ICMS em prestações interestaduais para consumidores finais não contribuintes. A atenção às datas de disponibilização e a compreensão detalhada das regras de validação e dos motivos de rejeição são cruciais para que transportadoras e embarcadores mantenham seus processos de emissão de CT-e em dia com a legislação.