CTe e CTe OS: Regras de Validação e Benefício Fiscal 2024

A Nota Técnica 2024.001 promove ajustes no Conhecimento de Transporte Eletrônico (CTe), CTe para Outros Serviços (CTe OS) e Guia de Transporte de Valores Eletrônica (GTVe). As mudanças visam aprimorar o sistema de autorização e alinhá-lo à legislação vigente, com foco na qualidade das informações fiscais. A implantação no ambiente de homologação ocorreu até 18 de março de 2024, e no ambiente de produção está prevista para 08 de abril de 2024, conforme a Nota Técnica 2024.001.

Histórico de Alterações e Cronograma

A evolução do Projeto Conhecimento de Transporte Eletrônico é contínua, com atualizações periódicas para atender às demandas fiscais. A versão 1 da Nota Técnica 2024.001 introduziu campos de benefício fiscal no CTe e CTe OS, limitou o período de validade das chaves de acesso de documentos originários e atualizou o texto da rejeição 203. A versão 1.02 incluiu campos vedados para a Carta de Correção e ajustou regras de validação para CTe Complementar antigo.

Historicamente, o projeto CTe tem passado por diversas atualizações de versões, indicando uma evolução constante da ferramenta fiscal. Por exemplo, a Nota Técnica 2012/001 divulgou o fim da vigência da versão 1.03 em maio de 2012, e a Nota Técnica 2010/001 informou o término da versão 1.02 em maio de 2010. Essas atualizações garantem a adaptação às necessidades fiscais e operacionais ao longo do tempo.

A versão 1.03 da Nota Técnica 2024.001, implementada em 18 de março de 2024 em homologação e com previsão para 08 de abril de 2024 em produção, excluiu uma coluna da tabela de campos vedados pela Carta de Correção. Essa padronização deve ser observada por todos os autorizadores.

Nova Mensagem de Rejeição 203

A rejeição 203, que ocorre quando o emissor não está habilitado para emitir CTe, terá uma mensagem mais detalhada. Antes, retornava apenas "Emitente não habilitado para emissão de CTe". Com a atualização, a mensagem será: "Emitente não habilitado ou em situação irregular para emissão do CTe". Essa alteração proporciona uma informação mais precisa ao contribuinte, auxiliando na identificação da causa da rejeição.

Inclusão de Benefício Fiscal no CTe e CTe OS

Uma das novidades da Nota Técnica 2024.001 é a criação de campos opcionais para informar benefícios fiscais nos schemas do CTe e CTe OS. Foram incluídas as tags vICMSDeson (Valor de ICMS de Desoneração) e cBenef (Código do Benefício Fiscal).

Esses campos visam possibilitar o registro transparente de desonerações e benefícios fiscais de ICMS concedidos por legislações estaduais. As tags foram adicionadas nos seguintes grupos de tributação de ICMS:

Para CTe (modelo 57):
- ICMS20
- ICMS45
- ICMS60
- ICMS90
- ICMSOutraUF
Para CTe OS (modelo 67):
- ICMS20
- ICMS45
- ICMS90
- ICMSOutraUF

A utilização dessas tags é opcional, mas se informadas, devem seguir a estrutura definida. Essa inclusão permite que as empresas declarem adequadamente os valores de ICMS desonerados, garantindo conformidade fiscal e transparência na apuração do imposto.

Eliminação do Tipo de Emissão FS-DA

A Nota Técnica 2024.001 estabelece a vedação do tipo de emissão Formulário de Segurança para Impressão de Documentos Auxiliares (FS-DA), representado pela tag tpEmis igual a 5. A regra geral é que o FS-DA não é mais permitido para a emissão de CTe e CTe OS.

Existe uma exceção: o uso do FS-DA continua permitido para CTe e CTe OS emitidos pela Secretaria de Estado de Fazenda de Minas Gerais (SEFAZ MG).

As regras de validação impactadas pela eliminação do FS-DA são detalhadas para CTe e CTe OS:

Regras de Validação para CTe

Rejeição do FS-DA (G008a): Se o tipo de emissão (tpEmis) for igual a 5 (FS-DA), o CTe será rejeitado com a mensagem "Rejeição: Tipo de emissão FS-DA não é permitido", exceto para emissões da SEFAZ MG.
Campos de Contingência em Emissão Normal (G008b): Para tipo de emissão 1 (Normal), os campos dhCont (Data e Hora da Contingência) e xJust (Justificativa da Contingência) não devem ser informados. A rejeição será "Rejeição: Campos da justificativa de entrada em contingência não podem ser informados para emissão normal".
Campos de Contingência para Emissão Diferente de FS-DA (G008): Se o tipo de emissão do CTe for diferente de 5 (FS-DA), os campos dhCont e xJust não devem ser informados. A rejeição será "Rejeição: Data e Justificativa de entrada em contingência não devem ser informadas para tipo de emissão diferente de FS-DA". Essa regra é mantida apenas para SEFAZ MG.
Campos de Contingência para Emissão FS-DA (G009): Se o tipo de emissão do CTe for igual a 5 (FS-DA), os campos dhCont e xJust devem ser informados. A rejeição será "Rejeição: Data e Justificativa de entrada em contingência devem ser informadas". Essa regra é mantida apenas para SEFAZ MG.
Data de Emissão Atrasada (G103): Para tipos de emissão diferentes de FS-DA (5) e EPEC (4), a Data-Hora de Emissão não pode ter atraso superior a 168 horas em relação ao horário de recepção na SEFAZ Autorizadora. Caso contrário, ocorre a rejeição "Data de Emissão muito atrasada". Esta regra se mantém para SEFAZ MG.
Parâmetro sign no QR Code (G215): Para tipos de emissão iguais a FS-DA (5) ou EPEC (4), o parâmetro sign deve ser informado no QR Code. A rejeição 853 indica "Rejeição: Parâmetro sign não informado no QR Code para emissão em contingência". Esta regra é mantida para SEFAZ MG.
Assinatura do QR Code (G217): Se o tipo de emissão for FS-DA (5) ou EPEC (4), e o valor da assinatura (sign) do QR Code diferir do valor calculado, a rejeição 855 ocorre com a mensagem "Rejeição: Assinatura do QR-Code difere do calculado". Esta regra é mantida para SEFAZ MG.

Regras de Validação para CTe OS

As regras de validação para CTe OS seguem a mesma lógica do CTe, com códigos de rejeição específicos:

Rejeição do FS-DA (H004a): Se o tipo de emissão (tpEmis) for igual a 5 (FS-DA), o CTe OS será rejeitado com a mensagem "Rejeição: Tipo de emissão FS-DA não é permitido", exceto para emissões da SEFAZ MG.
Campos de Contingência em Emissão Normal (H004b): Para tipo de emissão 1 (Normal), os campos dhCont e xJust não devem ser informados. A rejeição é "Rejeição: Campos da justificativa de entrada em contingência não podem ser informados para emissão normal".
Campos de Contingência para Emissão Diferente de FS-DA (H004): Se o tipo de emissão do CTe OS for diferente de 5 (FS-DA), os campos dhCont e xJust não devem ser informados. A rejeição é "Rejeição: Data e Justificativa de entrada em contingência não devem ser informadas para tipo de emissão diferente de FS-DA". Essa regra é mantida apenas para SEFAZ MG.
Campos de Contingência para Emissão FS-DA (H005): Se o tipo de emissão do CTe OS for igual a 5 (FS-DA), os campos dhCont e xJust devem ser informados. A rejeição é "Rejeição: Data e Justificativa de entrada em contingência devem ser informadas". Essa regra é mantida apenas para SEFAZ MG.
Data de Emissão Atrasada (H077): Para tipos de emissão diferentes de FS-DA (5), a Data-Hora de Emissão com atraso superior a 168 horas em relação ao horário de recepção na SEFAZ Autorizadora será rejeitada como "Data de Emissão muito atrasada". Esta regra se mantém para SEFAZ MG.
Assinatura do QR Code (H133): Se o tipo de emissão for igual a FS-DA (5), e o valor da assinatura (sign) do QR Code diferir do valor calculado, a rejeição 855 ocorre com a mensagem "Rejeição: Assinatura do QR-Code difere do calculado". Esta regra é mantida para SEFAZ MG.

A decisão de permitir o FS-DA apenas para SEFAZ Minas Gerais impacta diretamente a rotina de transportadoras e prestadores de serviços de transporte em outros estados, que precisarão adequar seus processos de emissão.

Limitação de Tempo para Chaves de Acesso Relacionadas

Com o objetivo de qualificar o sistema de autorização e gerenciar os eventos de marcação gerados no trânsito de mercadorias, a Nota Técnica 2024.001 estabelece limites de tempo para as chaves de acesso de documentos associados ao CTe e CTe OS.

As chaves de acesso relacionadas não podem ser muito antigas em relação à Data de Autorização do CTe, com os seguintes prazos:

6 meses anteriores à Data de Autorização do CTe:
- Chave de acesso de Notas Fiscais Eletrônicas (NFe) transportadas (G040a - rejeição 930: "Chave de acesso da NFe transportada muito antiga").
- Chave de acesso de CTe anterior em documentos anteriores eletrônicos (G065a - rejeição 931: "Chave de acesso do CTe anterior muito antiga").
- Chave de acesso de CTe multimodal vinculado (G071a - rejeição 932: "Chave de acesso do CTe multimodal muito antiga").
- Chave de acesso de BP-e referenciado (CTe OS H029a - rejeição 934: "Chave de acesso do BPe referenciado muito antiga").
- Chave de acesso de CTe referenciado (CTe OS H038a - rejeição 935: "Chave de acesso do CTe referenciado muito antiga").
- Chave de acesso de GTVe referenciada em CTe OS (CTe OS H046a - rejeição 936: "Chave de acesso da GTVe muito antiga").
- Chave de acesso de CTe cancelado referenciado em CTe OS (CTe OS H038a - rejeição 935: "Chave de acesso do CTe referenciado muito antiga").
12 meses anteriores à Data de Autorização do CTe:
- Chave de acesso do CTe complementado (G161a para CTe e H102a para CTe OS - rejeição 933: "Chave de acesso do CTe complementado muito antiga").
Exceção para Modal Ferroviário: Para o CTe Complementar, em caso de modal ferroviário, o limite é estendido para até 24 meses anteriores à Data de Autorização do CTe (CTe OS H102a). É importante notar que alterações no schema do modal ferroviário já foram divulgadas anteriormente, como na Nota Técnica 2009/001, evidenciando a atenção específica a esse modal.

Esses limites temporais exigem que as empresas revisem seus processos de vinculação de documentos, garantindo que as chaves de acesso informadas estejam dentro do período de validade estabelecido.

Atualização da Tabela de Campos Vedados para Alteração por Carta de Correção

A Nota Técnica 2024.001 também atualiza a lista de campos que não podem ser alterados por meio de Carta de Correção Eletrônica (CCe), tanto para CTe de Transporte de Cargas (modelo 57) quanto para CTe Outros Serviços (modelo 67). A exclusão da coluna "implementação SEFAZ" na tabela reforça que a vedação deve ser universal.

A CCe não pode retificar informações que alterem:

Identificação do Documento: Versão, ID, UF, código do CTe, modelo, série, número do CTe, tipo de emissão, código verificador, tipo de ambiente, data e hora da emissão, modal, CFOP, município de início da prestação.
Dados do Tomador: Tipo de tomador, CNPJ/CPF, Inscrição Estadual e UF do endereço.
Dados do Emitente, Remetente, Destinatário, Recebedor e Expedidor: CNPJ/CPF, Inscrição Estadual e UF do endereço.
Valores da Prestação: Valor Total da Prestação, Valor dos Componentes da Prestação.
Chaves de Documentos Fiscais: Chave de acesso de NFe.
Informações de ICMS:
- Para ICMS00: CST, Valor da Base de Cálculo (vBC), Alíquota do ICMS (pICMS), Valor do ICMS (vICMS).
- Para ICMS20: CST, Percentual de Redução da Base de Cálculo (pRedBC), vBC, pICMS, vICMS, Código do Benefício Fiscal (cBenef).
- Para ICMS45: CST, cBenef.
- Para ICMS60: CST, Valor da Base de Cálculo do ICMS ST Retido (vBCSTRet), Valor do ICMS ST Retido (vICMSSTRet), Alíquota do ICMS ST Retido (pICMSSTRet), Valor do Crédito Outorgado/Presumido (vCred), cBenef.
- Para ICMS90: CST, pRedBC, vBC, pICMS, vICMS, vCred, cBenef.
- Para ICMSOutraUF: CST, Percentual de Redução da Base de Cálculo para Outra UF (pRedBCOutraUF), vBCOutraUF, pICMSOutraUF, vICMSOutraUF, cBenef.
- Para ICMSSN: Indicador de Simples Nacional (indSN), CST.

Essa atualização reafirma a necessidade de cautela na emissão original do CTe e CTe OS, pois campos essenciais não poderão ser corrigidos posteriormente por Carta de Correção. A atenção à legislação e aos dados antes da autorização do documento é fundamental.

Conclusão

A Nota Técnica 2024.001 representa uma etapa na evolução dos documentos fiscais eletrônicos de transporte. As mudanças na mensagem de rejeição 203, a inclusão de campos para benefício fiscal, a vedação do FS-DA (com exceção para Minas Gerais), a limitação temporal para chaves de acesso relacionadas e a atualização dos campos vedados para Carta de Correção impactam diretamente a rotina de transportadoras e prestadores de serviços de transporte.

É necessário que contadores e empresas ajustem seus sistemas e processos de emissão de CTe e CTe OS para garantir a conformidade com as novas regras de validação. A atenção aos detalhes na emissão e a revisão dos dados antes da autorização são essenciais para evitar rejeições e assegurar a regularidade fiscal das operações de transporte.

Tributos.io

Rejeicao

CTe e CTe OS: Regras de Validação e Benefício Fiscal 2024

NFC-e: Emissão por CPF, Fim da Denegação e Novas Regras