MDFe: Mudanças no leiaute para CTe Simplificado e PAA

A Nota Técnica 2024.002 implementa ajustes no Manifesto Eletrônico de Documentos Fiscais (MDFe). O objetivo é adequar o leiaute e as regras de validação para incorporar as especificidades do Conhecimento de Transporte Eletrônico Simplificado (CTe Simplificado), além de refinar as regras do Provedor de Assinatura e Autorização (PAA).

Esta atualização da Nota Técnica 2024.002, na versão 1.01, foi publicada em agosto de 2024, trazendo importantes modificações que impactam diretamente a emissão desses documentos fiscais. As mudanças abordam a inclusão da entrega parcial do CTe Simplificado e aprimoram as validações para emissores que utilizam o PAA.

Cronograma de Implantação da NT 2024.002

A implementação das alterações da Nota Técnica seguiu um cronograma específico. A versão 1 trouxe a inclusão da entrega parcial do CTe Simplificado e suas regras de validação associadas. A versão 1.01 ajustou o prazo da Nota Técnica e as regras do PAA.

O período de homologação para testes começou em 16 de setembro de 2024, com a implantação em ambiente de produção prevista para 21 de outubro de 2024. Essas datas são essenciais para que as empresas e sistemas se preparem para as novas exigências.

Alterações no Leiaute do MDFe para CTe Simplificado

Para refletir as hipóteses de CTe Simplificado, o MDFe sofreu inclusões de campos opcionais no grupo de documentos originários do tipo Conhecimento de Transporte Eletrônico (grupo infCTe). Estas alterações permitem a comunicação de informações sobre entregas parciais.

Os novos campos são:

• indPrestacaoParcial: Indica que a prestação de serviço é parcial. Este campo é obrigatório (1-1) e deve ser informado com valor fixo 1 para sinalizar uma prestação parcial.
• infNFePresParcial: Um grupo de informações sobre as Notas Fiscais Eletrônicas (NFe) que foram entregues na prestação parcial do CTe. Este grupo é informado sempre que o campo indPrestacaoParcial estiver presente. A sua ocorrência é de 1 a N, permitindo várias NFes por prestação parcial.
• chNFe: Chave de acesso da NFe específica que foi entregue na prestação parcial do CTe relacionado. Este campo é parte do grupo infNFePresParcial e sua ocorrência é obrigatória (1-1) dentro do grupo.

Esses campos visam detalhar no MDFe quais NFes foram entregues em operações de CTe Simplificado que envolvem prestações parciais.

Novas Regras de Validação para CTe Simplificado no MDFe

A Nota Técnica 2024.002 introduz novas regras de validação para o MDFe, focando na integridade das informações relacionadas ao CTe Simplificado e suas entregas parciais. Essas regras buscam garantir a conformidade dos dados e evitar inconsistências.

As principais regras são:

• Regra 524 – Prestação parcial e tipo de CTe: Se o indicador de prestação parcial (indPrestacaoParcial=1) estiver informado no grupo do CTe, o sistema verifica se o CTe correspondente é do tipo CTe Simplificado. Caso contrário, a rejeição será "Prestação parcial só pode ser informado para CTe Simplificado".
• Regra 525 – Vigência da NFe na prestação parcial: Para cada NFe informada no grupo de prestação parcial (infNFePresParcial/chNFe), o Ano/Mês da chave de acesso da NFe não pode ser anterior a 6 meses da Data de Autorização do MDFe.
• Regra 526 – Chave de acesso de NFe duplicada: Se houver NFe de prestação parcial informadas, o sistema verifica a existência de chaves de acesso duplicadas nesse grupo. Se encontrada uma duplicidade, a chave duplicada é retornada na rejeição.
• Regra 527 – Chave de acesso de NFe inválida: As chaves de acesso das NFes informadas na prestação parcial (infNFePresParcial/chNFe) passam por validação. Rejeições ocorrem se o CNPJ/CPF for zerado ou inválido, o ano for anterior a 2006 ou maior que o ano atual, o mês for inválido (0 ou > 12), o Modelo for diferente de 55, ou o Número for zerado. O motivo da rejeição é especificado.
• Regras 528/529 – Existência da NFe: O sistema consulta a base de dados da Sefaz autorizadora para verificar a existência da NFe correspondente à chave informada (chNFe). Se a NFe não existir ou apresentar diferença na chave de acesso, haverá rejeição. Uma exceção é aplicada para NFes em contingência, que são dispensadas dessa validação.
• Regra 530 – Situação da NFe: A NFe informada na prestação parcial não pode estar cancelada ou denegada na base da Sefaz. NFes em contingência também são dispensadas dessa validação.

Alinhamento das Regras para o Provedor de Assinatura e Autorização (PAA)

A Nota Técnica 2024.002 também ajusta as regras de validação para o Provedor de Assinatura e Autorização (PAA). Inicialmente, o PAA foi previsto na versão 3.00b do MDFe para o Microempreendedor Individual (MEI) com conexão direta aos ambientes de autorização.

Posteriormente, o conceito do PAA foi expandido para incluir outros contribuintes representados por provedores de emissão, como Transportadores Autônomos de Cargas. Isso se relaciona com a Nota Fiscal Fácil (NFF) e a Plataforma de Emissão Simplificada (PES), que facilitam a geração de pedidos de emissão com dados comerciais. O XML do MDFe pode ser provido pelo ambiente da Plataforma de Emissão.

Dessa forma, o PAA pode tanto submeter um XML completo de documento fiscal diretamente ao ambiente autorizador quanto enviar apenas dados comerciais para que o fisco, via Plataforma de Emissão, gere o XML. Neste último cenário, o pedido assinado pelo contribuinte e pelo PAA é inserido no campo xSolic do grupo de informações da NFF, conforme o Manual de Orientações do Provedor de Assinatura e Autorização.

As regras de validação para o grupo infPAA (informações do Provedor de Assinatura e Autorização) são:

• PAA 01 – Validade do CNPJ do PAA: Se o grupo infPAA estiver preenchido, o CNPJ do PAA deve ser válido. A rejeição ocorre se o "CNPJ do PAA inválido".
• PAA 02 – Existência do PAA na SEFAZ: Se o grupo infPAA estiver preenchido, o CNPJ do PAA (CNPJPAA) deve existir na relação de Provedores de Autorização e Assinatura homologados pelo ENCAT. Caso contrário, a rejeição será "Provedor de Assinatura e Autorização não existe na base da SEFAZ".
• PAA 03 – Vínculo do emitente com o PAA: Se o grupo infPAA estiver preenchido, o emitente (CNPJ/CPF do grupo emit) deve possuir vínculo ativo com o PAA. A falta de vínculo resulta na rejeição "Emitente não associado ao PAA".
• PAA 04 – Tipo de emissão via PAA (SVRS): Se o grupo infPAA estiver preenchido e o CNPJ do certificado de assinatura for da SVRS, o tipo de emissão do MDFe (tpEmis) deve ser "Regime Especial da Nota Fiscal Fácil" (código 3). Se diferente, haverá a rejeição "Emissão por PAA deve ser do tipo e emissão Nota Fiscal Fácil quando gerado pela Plataforma de Emissão".
• PAA 05 – Assinatura pelo CNPJ do PAA: Se o grupo infPAA estiver preenchido e o CNPJ do certificado de assinatura for diferente da SVRS, o CNPJ do certificado deve ser igual ao CNPJ do PAA. Caso contrário, a rejeição será "Emissão por PAA deve ser assinada pelo CNPJ do Provedor de Assinatura".
• PAA 06 – Validade da assinatura RSA: Se o grupo infPAA estiver preenchido, a assinatura RSA deve ser válida. A rejeição indica "Assinatura RSA inválida".

Alterações em Regras de Eventos do MDFe

A Nota Técnica revoga as regras F76a e F76b da Autorização do MDFe e altera as regras para diversos eventos do documento. A regra geral K02 e K05, que exige que o emitente esteja habilitado para emissão do MDFe, passa a ter exceções para operações envolvendo o PAA ou a Nota Fiscal Fácil.

• Evento de Cancelamento (K02): O emitente deve estar habilitado para emitir MDFe. Contudo, essa regra não se aplica quando a forma de emissão do MDFe (tpEmis) for "Regime Especial da Nota Fiscal Fácil" (código 3). Adicionalmente, se o evento for gerado por um PAA (grupo infPAA), a verificação da habilitação do emitente é substituída pela checagem se o CNPJ do emitente está em situação ativa no cadastro do CNPJ MEI da Receita Federal do Brasil (RFB).
• Evento de Encerramento (K05): Similarmente, a exigência de emitente habilitado para emissão do MDFe não será aplicada quando o MDFe for gerado por um PAA.
• Evento de Inclusão de Condutor (K02): A regra de habilitação do emitente para emissão de MDFe é mantida, mas se o evento for gerado por PAA (grupo infPAA), verifica-se se o CNPJ do emitente está em situação ativa no cadastro do CNPJ MEI da RFB.
• Evento de Inclusão de DFe (K02): Para este evento, aplica-se a mesma exceção e observação dos eventos de cancelamento e inclusão de condutor, verificando o CNPJ do emitente no cadastro MEI da RFB se o evento for gerado por PAA.
• Evento de Pagamento da Operação de Transporte (K02): A regra de habilitação do emitente segue o mesmo padrão dos eventos anteriores, com a validação alternativa para emissores via PAA, que exige a verificação da situação ativa do CNPJ do emitente no cadastro do CNPJ MEI da RFB.

Essas alterações nos eventos de MDFe facilitam a operação para MEIs e Transportadores Autônomos de Cargas que utilizam o PAA, ao flexibilizar a regra de habilitação do emitente conforme sua modalidade de atuação.

Conclusão

A Nota Técnica 2024.002 do Projeto Manifesto Eletrônico de Documentos Fiscais é uma atualização fundamental para as operações de transporte de carga. As mudanças no leiaute do MDFe permitem a comunicação eficiente de dados de CTe Simplificado com prestação parcial, enquanto as novas regras de validação garantem a conformidade fiscal e a integridade das informações.

O alinhamento das regras do Provedor de Assinatura e Autorização (PAA) e as exceções para o Regime Especial da Nota Fiscal Fácil em diversos eventos simplificam os processos para um grupo ampliado de contribuintes, incluindo Microempreendedores Individuais e Transportadores Autônomos de Cargas. Empresas e contadores devem se atentar aos prazos de implantação em homologação (16 de setembro de 2024) e produção (21 de outubro de 2024) para garantir a adaptação de seus sistemas e a correta emissão do MDFe.