xDed em cana: descrição que identifica cada dedução

xDed é a descrição de uma dedução em cana/deduc. Sua função é permitir reconhecer o lançamento acompanhado por vDed. Uma descrição vaga ou truncada pode deixar o XML formalmente aceitável e ainda impedir a conciliação com o demonstrativo da aquisição.

Caminho desta página: /nfeProc/NFe/infNFe/cana/deduc/xDed. O prefixo nfeProc identifica a nota processada; a informação estudada pertence ao conteúdo da NF-e, dentro de NFe/infNFe.

O que escrever e de onde vem a descrição

Use a identificação verdadeira do lançamento constante no demonstrativo ou documento de liquidação. A descrição deve distinguir a dedução para que o leitor consiga compará-la com o valor correspondente. A tag não impõe, por si, uma cobrança específica nem serve para criar fundamento contratual ou legal que não exista.

O XSD restringe xDed ao tipo textual com tamanho de 1 a 60 caracteres. O campo é obrigatório em cada ocorrência de deduc e precede vDed. Não substitua a descrição por uma tag vazia, uma lista de valores ou apenas espaços; não trunque automaticamente a parte do texto que distingue lançamentos. MOC 7.0, ZC11, p. 65 e XSD PL 010f.

Exemplo e caracteres especiais

Descrição sintética de um lançamento hipotético já documentado:

<xDed xmlns="http://www.portalfiscal.inf.br/nfe">Taxa contratual demonstrativa</xDed>

É um fragmento parcial do campo, sem XML completo da NF-e. Na ocorrência completa, o valor correspondente viria em vDed. A redação do exemplo não recomenda cobrar a taxa.

Quando a descrição real contém &, o serializador precisa representar o caractere como & no XML. O mesmo cuidado se aplica aos delimitadores de marcação. Essa codificação preserva o texto; não muda a natureza da dedução. Não concatene descrições e valores manualmente em um bloco XML, pois isso pode produzir marcação inválida.

Descrição, valor e informações complementares

xDed responde qual dedução; vDed, quanto foi deduzido. vTotDed é o total monetário das deduções, não uma descrição global que substitui os pares. Copiar todas as deduções para infCpl não cria os grupos estruturados que cana requer.

O nome xDed não é uma referência legal obrigatória genérica nem um campo para enquadrar tributação. Se o tratamento contábil depender da natureza da cobrança, leve o contrato, demonstrativo e documentos pertinentes ao responsável fiscal. A descrição deve retratar o lançamento real, sem afirmar isenção ou benefício por inferência.

Diagnóstico de texto perdido ou sem identificação

Compare a descrição original e o texto efetivamente serializado. Se uma importação deixa todas as linhas como “Outros”, verifique se o mapeamento recebeu a coluna correta e se descartou a identificação útil. Se há erro de schema, conte caracteres do conteúdo, confira campo não vazio e codificação do XML. Se o texto aparece cortado, procure limite aplicado indevidamente antes do serializador.

Confira descrição e valor juntos: trocar descrições entre duas deduções mantém a soma, mas altera o significado dos lançamentos. Após corrigir a origem comprovada, regenere o XML e confirme o par completo. A regra de modelo também permanece: cana em NFC-e 65 se relaciona à rejeição 763, que não é resolvida encurtando o texto. MOC, p. 128.

Fontes oficiais

• Leiaute NF-e/NFC-e — PL_010f_v1.04: cana/deduc/xDed l6443–6451; TString
• Tipos básicos NF-e/NFC-e — PL_010f_v1.04: TString, linhas 519–528: restrição textual usada pela declaração do campo.
• MOC 7.0 — Anexo I — 7.00, novembro/2020: Grupo ZC, p. 64–65; regra ZC01-10 e rejeição 763, p. 128