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

dFab na NF-e: data de fabricação e rejeição 877

<dFab>det › prod › rastro › dFab

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

dFab registra a data de fabricação ou produção no grupo de rastreabilidade do produto. Fica em /nfeProc/NFe/infNFe/det/prod/rastro/dFab. É obrigatória em cada ocorrência de rastro, com data completa no formato AAAA-MM-DD. Não é a data de emissão da nota, a de entrada no estoque ou a data de validade.

A data pertence ao lote identificado

Leia dFab junto a nLote, qLote e dVal da mesma ocorrência. Duas partidas do mesmo produto podem ter datas diferentes; copiar a data do cadastro geral para todos os lotes perde essa correspondência. O dado precisa vir da identificação do lote e de sua documentação, não do dia em que o sistema criou a linha do pedido.

Uma NF-e com dois lotes exige conferir os dois blocos. A data de fabricação de um lote não passa a valer para o outro porque os itens têm mesmo NCM ou nome comercial. Quando a fonte não informa dia, mês e ano suficientes para fabricação, não há aqui uma regra que autorize inventar o primeiro ou último dia do mês. A orientação específica de último dia pertence a dVal quando a validade não especifica o dia.

Data de fabricação futura: regra I83-10

O MOC define I83-10, rejeição 877, quando dFab é maior que a data de processamento. A comparação publicada não é simplesmente dFab contra a data de emissão. Uma nota retroativa, um envio posterior ou a exibição de datas em fusos diferentes pode tornar essas referências distintas; preserve data da fabricação e momento real do processamento no diagnóstico. MOC, I83-10.

Não use a data atual como substituta para remover a rejeição. Primeiro confira se houve inversão de dia e mês, erro no ano, importação de validade em fabricação ou uso de informação de outro lote. O retorno indica uma comparação que falhou; não informa a data verdadeira do produto.

Representação e duas comparações distintas

Neste exercício, um lote foi fabricado em 01/08/2026 e tem validade em 31/08/2027. Se processado em 26/09/2026, a fabricação não é posterior ao processamento. Se o sistema serializasse por engano fabricação em 01/08/2027, o dado seria futuro nesse cenário e também poderia ficar incompatível com outros controles.

Fragmento sintético e parcial, sem identidade real e sem os demais campos da nota. Não é pronto para transmissão.

<rastro xmlns="http://www.portalfiscal.inf.br/nfe">
  <nLote>EXEMPLO-01</nLote>
  <qLote>10.000</qLote>
  <dFab>2026-08-01</dFab>
  <dVal>2027-08-31</dVal>
</rastro>

O XML usa hífens e não inclui horário ou máscara brasileira. Uma data impossível, como 31 de fevereiro, não se torna válida apenas por seguir o desenho de dez caracteres. Confira calendário e o tipo de data do schema usado pelo emissor. No TData do pacote aqui lido, o padrão delimita anos de 2000 a 2099 e contempla fevereiro bissexto; uma máscara de apresentação não substitui essa conferência estrutural.

Como investigar antes de corrigir

Localize o item e a ocorrência de rastro, preserve XML e retorno, e compare dFab à identificação/documentação desse lote. Verifique a data e ambiente do processamento. Se o problema foi a conversão da data brasileira para XML, corrija o conversor e confira a saída; se a data de origem é desconhecida, obtenha-a de fonte correspondente.

Confira também dVal: a regra I84-10/870 trata validade anterior à fabricação. Essa é outra comparação, com causa própria. Corrigir dFab deve preservar a verdade documental e a relação com dVal, sem apagar rastreabilidade para contornar a validação. Não edite documento assinado nem estime a fabricação por prazo de validade presumido.

Fontes oficiais

Leitura relacionada

Referência técnica para integração

XPath completo
/nfeProc/NFe/infNFe/det/prod/rastro/dFab
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