dFab na NF-e: data de fabricação e rejeição 877
<dFab>det › prod › rastro › dFabRevisã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
- MOC 7.0 — Anexo I — 7.00; p.21 I83; p.96 I83-10/I84-10.
- Schemas NF-e/NFC-e — PL_010c_NT2022_002v1.30; rastro/dFab TData.
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