Pular para o conteúdo
Fiscal ProBiblioteca
NF-e e NFC-e · Produtos e serviços

dVal na NF-e: validade do lote e regra do último dia

<dVal>det › prod › rastro › dVal

Revisão editorial em 26 de set. de 2026. As versões e condições das regras estão indicadas ao longo do artigo.

dVal é a data de validade do lote, dentro da rastreabilidade do produto. Seu caminho é /nfeProc/NFe/infNFe/det/prod/rastro/dVal. É obrigatória quando esse bloco existe e usa o formato AAAA-MM-DD. Deve corresponder ao lote de nLote e à sua identificação/documentação.

Quando a validade não informa o dia

O MOC e a descrição do schema orientam informar o último dia do mês caso a validade não especifique o dia. Assim, uma validade documental de fevereiro de 2028 é representada como 2028-02-29; fevereiro de 2027 termina em 2027-02-28. Não se usa dia 31 em todos os meses. MOC, I84.

Essa orientação resolve apenas a ausência do dia numa validade com mês e ano conhecidos. Não permite inferir a validade inteira a partir da fabricação, do histórico de outra mercadoria ou de um prazo presumido. Se o documento informa uma data completa, preserve o dia real, sem estendê-lo até o fim do mês.

Se existe mais de um lote no item, cada ocorrência deve conservar sua própria validade. Um sistema de estoque pode mostrar a menor validade de todo o produto; esse resumo não substitui as datas de todos os lotes efetivamente informados no XML.

Rejeição 870 compara validade e fabricação

A regra I84-10 rejeita dVal menor que dFab, com código 870. É uma verificação da sequência das datas do lote. Não se deve descrevê-la como rejeição automática de qualquer produto vencido na data da venda, pois a condição publicada compara validade e fabricação. A possibilidade de movimentar ou comercializar um produto vencido depende das normas próprias e da operação; não é decidida pela ausência dessa rejeição. MOC, I84-10.

Uma validade anterior à fabricação pode resultar de troca dos campos, ano errado ou lote diferente. Mudar dVal para uma data futura aleatória remove a evidência e não comprova o dado. Confira a origem antes de modificar o cadastro ou a serialização.

Exemplo de validade por mês e ano

No exercício, o documento identifica fabricação em 15/01/2027 e validade em fevereiro de 2028 sem dia. A representação da validade usa o último dia desse fevereiro bissexto. Os dados são sintéticos e o fragmento não é pronto para transmissão.

<rastro xmlns="http://www.portalfiscal.inf.br/nfe">
  <nLote>EXEMPLO-2027</nLote>
  <qLote>5.000</qLote>
  <dFab>2027-01-15</dFab>
  <dVal>2028-02-29</dVal>
</rastro>

Uma data completa em origem, por exemplo 10/02/2028, teria representação 2028-02-10, não a data do exemplo. O gerador deve aplicar a regra apenas quando a informação original é realmente limitada ao mês e ano.

Conferência de retorno, calendário e lote

Localize o item e o bloco retornado; compare dVal e dFab com a documentação do mesmo lote. Verifique se a leitura brasileira de dia/mês foi convertida corretamente, se o ano foi preservado e se fevereiro foi calculado com calendário correto. Uma data lexicalmente parecida com AAAA-MM-DD pode ainda ser impossível. O TData do pacote aqui lido delimita anos de 2000 a 2099 e contempla fevereiro bissexto; confira o tipo efetivo do emissor. O exemplo de fabricação em 2027 é um cenário futuro: ele não deve ser enviado no corte de 26/09/2026, pois a comparação de fabricação com processamento pertence à regra 877, distinta da validade explicada aqui.

Se o problema é apenas transferência comprovada, corrija a origem ou conversor e confira o XML novo. Se a validade não está documentada, obtenha esse dado específico. Não apague rastro, não iguale todas as validades do produto e não conclua autorização de venda a partir de validação estrutural. Preserve o documento assinado e investigue antes de qualquer ação fiscal.

Fontes oficiais

Leitura relacionada

Referência técnica para integração

XPath completo
/nfeProc/NFe/infNFe/det/prod/rastro/dVal
Namespace
http://www.portalfiscal.inf.br/nfe
Leiaute
4.00 · PL_010e_v1.02
Ocorrências no XSD
1–1 no contexto do elemento pai
Tipo
TData · string
Preenchimento no catálogo
Condicional

A ocorrência vale dentro da estrutura XML: um campo obrigatório em um grupo opcional não torna esse grupo obrigatório. A aplicação fiscal depende da operação e da versão da regra.

pattern
(((20(([02468][048])|([13579][26]))-02-29))|(20[0-9][0-9])-((((0[1-9])|(1[0-2]))-((0[1-9])|(1\d)|(2[0-8])))|((((0[13578])|(1[02]))-31)|(((0[1,3-9])|(1[0-2]))-(29|30)))))
whiteSpace
preserve