NT 2015.001 — Evento Pedido de Prorrogação

Publicado em 2024-12-06 · Versão 1.30

Sobre

Esta NT especifica o layout e as regras de operacionalização do Evento de Pedido de Prorrogação da suspensão do ICMS em remessas para industrialização (após 180 dias), permitindo que contribuintes substituam petições em papel por arquivos XML assinados. A versão 1.30 inclui um novo tipo de implementação chamado 'solicitação completa' (adotado por Minas Gerais), em que o pedido de prorrogação deve contemplar todos os itens e quantidades da NF-e, além de tornar parametrizáveis a critério da UF as regras de validação sobre a quantidade máxima de pedidos sem resposta do fisco.

O que mudou (v1.20 → v1.30)

A versão 1.30 introduz o conceito de 'solicitação completa' para o Evento de Pedido de Prorrogação, em que o pedido deve contemplar todos os itens e quantidades da NF-e (implementado por Minas Gerais). Além disso, torna parametrizáveis a critério da UF as regras de validação P13-14 (limite de pedidos sem resposta do fisco), atualiza a regra P19 para contemplar novos cenários de deferimento e ajusta mensagens de rejeição e o campo P25 para refletir as particularidades da solicitação completa.

• Inclusão do tipo de implementação 'solicitação completa' (pedido deve incluir todos os itens e quantidades da NF-e)
• Regras de validação P13-14 (códigos 638 e 639) tornadas parametrizáveis por UF (limite pode ser 1 em vez de 20)
• Regra P19 (código 809) ampliada para verificar existência de pedido deferido para o tpEvento informado
• Campo P25 (justStatus) atualizado: motivo '7 - Quantidade inconsistente' explicitado como não aplicável à solicitação completa
• Mensagens de rejeição 638, 639 e 809 atualizadas para refletir parametrização e novos cenários

Apenas cronograma:

• Definição de datas de implantação: homologação em 29/10/2024 e produção em 06/01/2025, ambas somente em Minas Gerais

Datas de Vigência

• homologação: 2024-10-29
• produção: 2025-01-06

Mudanças (14)

• processo [alto] — Inclusão do tipo de implementação 'solicitação completa', em que o pedido de prorrogação deve contemplar obrigatoriamente todos os itens e quantidades da NF-e. Essa modalidade é adotada por Minas Gerais, enquanto São Paulo mantém a 'solicitação parcial'.
• regra_validação [alto] — As regras de validação P13-14 (códigos 638 e 639) passam a ser parametrizáveis a critério da UF: além do limite padrão de 20 pedidos sem resposta do fisco, a UF pode configurar o limite para 1 pedido, exigindo que o contribuinte aguarde a resposta antes de enviar novo pedido.
• regra_validação [médio] — A regra de validação P19 (código 809) foi ampliada: além de verificar se o ID do pedido existe na base de dados, agora também verifica se há um pedido de prorrogação deferido para o tipo de evento informado (tpEvento).
• regra_validação [baixo] — As mensagens de rejeição dos códigos 638 e 639 foram alteradas para remover a referência ao valor fixo de '20 pedidos', tornando a mensagem genérica ('excede o valor limite de Pedidos de Prorrogação autorizados e sem resposta do Fisco') para refletir a parametrização por UF.
• regra_validação [baixo] — A mensagem de rejeição do código 809 foi atualizada para incluir o caso em que não há pedido de prorrogação deferido para o tipo de evento informado: 'Rejeição: ID do Pedido de Prorrogação ou Cancelamento não existe na base de dados ou não há um pedido de prorrogação deferido para o tipo: [tpEvento]'.
• layout_xml [baixo] — O campo P25 (justStatus) foi atualizado para indicar que o motivo '7 - Quantidade inconsistente com a quantidade do item' não se aplica ao tipo de implementação de solicitação completa.
• processo [baixo] — Complementação de textos e adição de exemplos ilustrativos nos itens 1.1, 1.2, 1.3, 1.3.2, 1.3.5 e 2.2 para adequação ao tipo de implementação de solicitação completa.
• processo [médio] — Alteração do texto do item 2.3 para permitir a parametrização das regras de validação P13-14 a critério da UF, de forma que se uma NF-e contiver mais que 1 evento autorizado sem resposta pelo fisco, o WebService de recepção de eventos devolva mensagem de rejeição.
• regra_validação [alto] — Alterações da versão 1.20 (histórico): inclusão de novas validações de data do evento (códigos 577, 578, 579), validação do CNPJ do certificado digital do fisco (código 808), validação do ID do pedido (código 809) e validação de correspondência entre tpEvento do fisco e do pedido (código 810).
• regra_validação [médio] — Alteração da versão 1.20 (histórico): a validação P13-14 do sequencial do evento (código 594) passou a aceitar o último sequencial + 1, em vez de exigir valor fixo igual a 1.
• layout_xml [baixo] — Alteração da versão 1.20 (histórico): correção do campo P14 (nSeqEvento) para documentar que o sequencial pode ser maior que 1 em eventos cumulativos como Pedido de Prorrogação e Cancelamento.
• layout_xml [baixo] — Alteração da versão 1.20 (histórico): correção dos índices dos domínios nos campos P25 e P29 (justStatus), adicionando numeração explícita (1 a 10 para P25; 1 a 5 para P29) às justificativas de resposta do fisco.
• processo [médio] — Alteração da versão 1.20 (histórico): mudança na tabela de distribuição de DFe (NFeDistribuicaoDFe) — os eventos de Pedido de Prorrogação e Cancelamento de Pedido passaram a não ser distribuídos ao emitente (de 'Sim' para 'Não'), mantendo distribuição apenas ao destinatário.
• outro [médio] — Alteração da versão 1.20 (histórico): inclusão do item 6 sobre a relação entre Pedido de Cancelamento da NF-e e Evento de Pedido de Prorrogação de Prazo, e inclusão da mensagem 811 ('Rejeição: Pedido de Prorrogação deferido impede o cancelamento da NF-e').

Histórico de versões

• v1.30 — 2024-12-06 (vigente)