CTe 2024: Novas Regras de Validação, FS-DA e Benefício Fiscal

A Nota Técnica 2024.001 do Projeto Conhecimento de Transporte Eletrônico (CTe), versão 1.04, traz ajustes nas regras de validação para o CTe, CTe Outros Serviços (CTe OS) e Guia de Transporte de Valores Eletrônica (GTVe). Essas modificações visam aprimorar a qualidade do sistema de autorização e adequá-lo à legislação fiscal vigente, com implantação em homologação e produção a partir de 28/10/2024, conforme detalhado na Nota Técnica 2024.001.

Alterações na Rejeição de Emissor Não Habilitado

A mensagem de rejeição 203, que identifica um emitente de CTe sem a devida habilitação, foi atualizada. Anteriormente, a mensagem era genérica para "emissor não habilitado".

Agora, ao tentar emitir um CTe com um emitente nesta situação, o sistema retornará a mensagem específica: "Emitente não habilitado ou em situação irregular para emissão do CTe". Esta clareza na comunicação do erro permite que os contribuintes identifiquem rapidamente a natureza da irregularidade cadastral.

Inclusão do Benefício Fiscal em CTe e CTe OS

Foram criadas novas tags para inclusão de informações sobre benefício fiscal nos esquemas XML do CTe e CTe OS. São elas: Valor de ICMS de Desoneração (vICMSDeson) e Código do Benefício Fiscal (cBenef).

Ambas as tags são opcionais e devem ser utilizadas nos grupos de tributação de ICMS específicos, conforme a modalidade do documento fiscal eletrônico:

Para o CTe (modelo 57):

• ICMS20
• ICMS45
• ICMS60
• ICMS90
• ICMSOutraUF

Para o CTe OS (modelo 67):

• ICMS20
• ICMS45
• ICMS90
• ICMSOutraUF

A inclusão desses campos permite a correta discriminação dos valores de ICMS desonerados e a identificação do benefício fiscal utilizado, fornecendo maior transparência e aderência às normativas tributárias.

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

O tipo de emissão FS-DA (Formulário de Segurança para Impressão de Documento Auxiliar), identificado pela tag tpEmis com valor 5, agora é vedado para a maioria dos emissores de CTe e CTe OS. Esta restrição segue o estabelecido em Ajuste SINIEF.

A única exceção a essa regra é para a emissão de documentos destinados à Secretaria de Estado de Fazenda de Minas Gerais (SEFAZ MG). Para os demais casos, a utilização do FS-DA resultará na rejeição do documento.

As regras de validação associadas à vedação do FS-DA são detalhadas para CTe e CTe OS, com as seguintes especificações:

Regras de Validação para CTe:

• Regra G008a: Rejeita CTe com tipo de emissão FS-DA (tpEmis=5) com a mensagem "Rejeição: Tipo de emissão FS-DA não é permitido", exceto para SEFAZ MG.
• Regra G008b: Se o tipo de emissão for normal (tpEmis=1), os campos Data e Hora da Contingência (dhCont) e Justificativa da Contingência (xJust) não devem ser informados. A rejeição será "Campos da justificativa de entrada em contingência não podem ser informados para emissão normal".
• Regra G008: Se a forma de emissão for diferente de FS-DA (tpEmis=5), os campos Data e Hora da Contingência e Justificativa da Contingência não devem ser informados. A rejeição será "Data e Justificativa de entrada em contingência não devem ser informadas para tipo de emissão diferente de FS-DA". Esta regra é mantida apenas para SEFAZ MG.
• Regra G009: Se a forma de emissão for FS-DA (tpEmis=5), os campos Data e Hora da Contingência e Justificativa da Contingência devem ser informados. A rejeição será "Data e Justificativa de entrada em contingência devem ser informadas". Esta regra é mantida apenas para SEFAZ MG.
• Regra G103: Para tipos de emissão diferentes de FS-DA (tpEmis=5) e EPEC (tpEmis=4), a Data de Emissão (dhEmi) 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 mantém a redação apenas para SEFAZ MG.
• Regra G215: Se o tipo de emissão for FS-DA (tpEmis=5) ou EPEC (tpEmis=4), o parâmetro sign deve ser informado no QR Code para emissão em contingência. A falta dele gera a rejeição "Parâmetro não informado no QR Code para emissão em contingência". Esta regra mantém a redação apenas para SEFAZ MG.
• Regra G217: Se o tipo de emissão for FS-DA (tpEmis=5) ou EPEC (tpEmis=4), o valor da assinatura (sign) do QR Code deve coincidir com o valor calculado. Discrepância resulta na rejeição "Assinatura do QR-Code difere do calculado". Esta regra mantém a redação apenas para SEFAZ MG.

Regras de Validação para CTe OS:

• Regra H004a: Rejeita CTe OS com tipo de emissão FS-DA (tpEmis=5) com a mensagem "Rejeição: Tipo de emissão FS-DA não é permitido", exceto para SEFAZ MG.
• Regra H004b: Se o tipo de emissão for normal (tpEmis=1), os campos Data e Hora da Contingência (dhCont) e Justificativa da Contingência (xJust) não devem ser informados. A rejeição será "Campos da justificativa de entrada em contingência não podem ser informados para emissão normal".
• Regra H004: Se a forma de emissão for diferente de FS-DA (tpEmis=5), os campos Data e Justificativa de entrada em contingência não devem ser informadas. A rejeição será "Data e Justificativa de entrada em contingência não devem ser informadas para tipo de emissão diferente de FS-DA". Esta regra é mantida apenas para SEFAZ MG.
• Regra H005: Se a forma de emissão for FS-DA (tpEmis=5), os campos Data e Hora da Contingência e Justificativa da Contingência devem ser informados. A rejeição será "Data e Justificativa de entrada em contingência devem ser informadas". Esta regra é mantida apenas para SEFAZ MG.
• Regra H077: Para tipo de emissão diferente de FS-DA (tpEmis=5), a Data de Emissão não pode ter atraso superior a 168 horas. Caso contrário, ocorre a rejeição "Data de Emissão muito atrasada". Esta regra mantém a redação apenas para SEFAZ MG.
• Regra H131: Se o tipo de emissão for FS-DA (tpEmis=5), o parâmetro sign deve ser informado no QR Code para emissão em contingência. A falta dele gera a rejeição "Parâmetro sign não informado no QR Code para emissão em contingência". Esta regra mantém a redação apenas para SEFAZ MG.
• Regra H133: Se o tipo de emissão for FS-DA (tpEmis=5), o valor da assinatura (sign) do QR Code deve coincidir com o valor calculado. Discrepância resulta na rejeição "Assinatura do QR-Code difere do calculado". Esta regra mantém a redação apenas para SEFAZ MG.

Essas regras visam garantir a correta aplicação das modalidades de emissão, especialmente em cenários de contingência, e reforçam a vedação do FS-DA para a maioria dos contribuintes.

Limite de Tempo para Chaves de Acesso Referenciadas

O sistema de autorização de CTe agora impõe um limite de tempo para as chaves de acesso de documentos fiscais eletrônicos referenciados. Esta medida visa qualificar o sistema de autorização, considerando o volume de eventos gerados automaticamente no trânsito de mercadorias.

Para CTe de Transporte de Cargas (Normal ou Substituição):

• NFe relacionadas: As chaves de acesso de NFes (chNFe) referenciadas não podem ter Ano/Mês de emissão anteriores a 6 meses da Data de Autorização do CTe. Caso contrário, o CTe será rejeitado com a mensagem "Rejeição: Chave de acesso da NFe transportada muito antiga".
• CTe Anteriores: As chaves de acesso de CTe anteriores (chCTe) referenciadas não podem ter Ano/Mês de emissão anteriores a 6 meses da Data de Autorização do CTe. A rejeição será "Rejeição: Chave de acesso do CTe anterior muito antiga".
• CTe Multimodais Vinculados: As chaves de acesso de CTe multimodais (chCTeMultimodal) referenciadas não podem ter Ano/Mês de emissão anteriores a 6 meses da Data de Autorização do CTe. A rejeição será "Rejeição: Chave de acesso do CTe multimodal muito antiga".

Para CTe Complementar:

• CTe Complementado: As chaves de acesso de CTe complementados (chCTe) não podem ter Ano/Mês de emissão anteriores a 12 meses da Data de Autorização do CTe. A rejeição será "Rejeição: Chave de acesso do CTe complementado muito antiga".
• Exceção para Modal Ferroviário ou Aquaviário: Para CTe Complementar emitidos para modal ferroviário ou aquaviário, o limite é estendido para 24 meses da Data de Autorização do CTe. Essa exceção reflete particularidades logísticas desses modais, alinhando-se a ajustes anteriores, como os previstos na Nota Técnica 2009/001 referente ao modal ferroviário.

Para CTe Outros Serviços (CTe OS):

• BP-e Referenciado (Excesso de Bagagem): Chaves de BP-e (chBPe) referenciadas em CTe OS de serviço de Excesso de Bagagem não podem ter Ano/Mês de emissão anteriores a 6 meses da Data de Autorização do CTe OS. Rejeição: "Chave de acesso do BPe referenciado muito antiga".
• CTe Cancelado Referenciado (Normal ou Substituição): Chaves de CTe cancelado (refCTeCanc) referenciadas não podem ter Ano/Mês de emissão anteriores a 6 meses da Data de Autorização do CTe OS. Rejeição: "Chave de acesso do CTe referenciado muito antiga".
• GTVe Referenciada (Transporte de Valores): Chaves de GTVe (chCTe) informadas em CTe OS de serviço de Transporte de Valores não podem ter Ano/Mês de emissão anteriores a 6 meses da Data de Autorização do CTe OS. Rejeição: "Chave de acesso da GTVe muito antiga".
• CTe Complementado: Chaves de CTe complementados (chCTe) não podem ter Ano/Mês de emissão anteriores a 12 meses da Data de Autorização do CTe OS. Rejeição: "Chave de acesso do CTe complementado muito antiga".

As novas regras de validação, incluindo o limite de tempo para chaves, a vedação do FS-DA e as alterações de mensagens de rejeição, são importantes para a conformidade fiscal dos contribuintes. Essas atualizações do CTe visam aprimorar a qualidade dos documentos fiscais e garantir a aderência à legislação em vigor. A atenção a estas mudanças é necessária para evitar rejeições e manter a regularidade na emissão dos documentos de transporte eletrônicos.