natOp na NF-e: natureza da operação, formato e conferência

natOp é a descrição da natureza da operação em ide: o texto que explica o negócio do qual decorre a entrada ou saída documentada. O campo é obrigatório, aparece uma vez e comporta de 1 a 60 caracteres na NF-e e NFC-e. Ele ajuda a interpretar a nota, mas não substitui seus códigos fiscais. MOC, B04, p. 8

Natureza da operação não é CFOP

O MOC apresenta venda, compra, transferência, devolução, importação, consignação e remessa como exemplos de naturezas. Essa enumeração ilustra o conteúdo descritivo; não é uma tabela de códigos para escolher o tratamento de qualquer operação.

Quatro informações frequentemente confundidas têm funções distintas:

Uma nota pode ter vários itens e cada item tem seu CFOP; há uma única descrição natOp no cabeçalho. Portanto, copiar um CFOP como texto não torna a natureza explicada, e escrever “devolução” não configura sozinho a finalidade nem os códigos por item. MOC, B11, B25 e I08

Se a dúvida for a natureza adequada ao caso, confirme o negócio efetivo, o motivo do movimento, os participantes e os documentos de origem com o responsável fiscal. Depois dessa definição, a integração deve representar os parâmetros confirmados, sem inferir tributação apenas do texto.

Como obter e representar o texto

A descrição deve vir da operação registrada e das configurações que a representam. Não é calculada a partir do valor do imposto. Uma descrição padrão pode ser reutilizada quando corresponde ao negócio, mas precisa ser conferida se o documento deixou de ser uma venda comum, recebeu outra finalidade ou passou a representar outro movimento.

Além do limite de 60 caracteres, o tipo TString exige conteúdo não vazio, sem espaço na primeira ou última posição. Espaços no meio do texto são permitidos. Um campo com somente espaços não satisfaz essa definição. O schema preserva espaços: a integração não deve supor que o validador eliminará as sobras automaticamente. Schema e TString, pacote oficial 010d v1.03 Tipos básicos

Mantenha a acentuação correta na descrição. Ao gerar XML, caracteres especiais da linguagem XML precisam ser escapados pelo serializador: o caractere & no conteúdo é representado por &. Esse escape não é uma mudança no negócio e não deve ser confundido com texto que o operador precisa digitar literalmente.

O limite do campo se refere ao conteúdo textual, não ao tamanho do arquivo inteiro. Evite truncar automaticamente uma descrição que excedeu 60 caracteres: cortar uma palavra ou ressalva pode alterar o sentido. Confira qual descrição objetiva preserva a informação efetiva; detalhes adicionais não devem ser transferidos para outra tag sem confirmar a finalidade dessa informação.

Exemplos de leitura

Os fragmentos são sintéticos e parciais, apenas para explicar a representação. Não contêm uma NF-e completa e não estão prontos para transmissão.

<natOp xmlns="http://www.portalfiscal.inf.br/nfe">Venda de mercadoria</natOp>

Nesse cenário hipotético, a operação já foi identificada como venda. O XML registra a descrição; não informa por si o CFOP dos itens, o destinatário, a incidência ou a alíquota.

Um exemplo somente de serialização:

<natOp xmlns="http://www.portalfiscal.inf.br/nfe">Operação A &amp; B</natOp>

O conteúdo lido por um parser é “Operação A & B”. O & é a forma XML do caractere especial, não uma classificação de operação.

No documento processado, localize /nfeProc/NFe/infNFe/ide/natOp. Em um arquivo com raiz NFe, o caminho começa em /NFe/infNFe. Para XPath, associe um prefixo ao namespace http://www.portalfiscal.inf.br/nfe.

Como conferir um problema

Se houver falha estrutural, examine o valor efetivamente serializado, não apenas o que a tela mostra. Confira tag ausente, duplicada, vazia, tamanho maior que 60, espaços nas bordas, caracteres não aceitos e escape incorreto. Examine também a ordem em que os filhos de ide foram gerados.

Se o XML passa na estrutura, mas a descrição não corresponde ao negócio, compare natOp com o tipo de operação, finalidade, itens e documentos relacionados. Não conclua que a frase está correta só porque coube no campo. Também não atribua a uma divergência textual um código de rejeição que não foi demonstrado pelo retorno.

A correção precisa ocorrer na origem comprovada: texto da operação, configuração ou serialização. Confira novamente o rascunho gerado antes da assinatura. Não altere diretamente XML assinado ou autorizado, nem troque natureza, finalidade ou CFOP verdadeiro para contornar uma rejeição. Sintaxe válida não constitui autorização nem confirmação do tratamento fiscal.