Rejeição 734: unidade comercial da NFC-e e limite de implantação

A Rejeição 734 é descrita no MOC como NFC-e com unidade de comercialização inválida, regra I09-10: o conteúdo de prod/uCom não consta de tabela específica. O mesmo manual registra que a I09-10 tinha previsão de implementação futura e não estava em produção na sua publicação. Essa ressalva é essencial: a existência do código no catálogo não prova ativação atual em uma UF.

uCom representa a unidade em que o item é comercializado

uCom fica dentro de det/prod, ao lado de qCom e vUnCom. A quantidade comercial qCom e o preço unitário comercial vUnCom precisam ter sentido nessa unidade. uTrib, por sua vez, é a unidade tributável e possui campo e verificações distintos. Não copie uma unidade de um campo para outro sem conferir a relação física entre elas.

O schema consultado define uCom como texto com 1 a 6 caracteres. Essa limitação estrutural não publica uma lista universal de abreviaturas aceitas pela I09-10. A tabela de unidades de comércio exterior também não deve ser aplicada à NFC-e por analogia; ela sustenta outra regra e outro contexto.

Se o emissor mostrar 734, como confirmar a origem

Guarde o XML e a resposta de autorização. Verifique se 734 veio efetivamente da SEFAZ ou de um validador local. Identifique ambiente, UF/autorizadora, data, modelo 65, número do item e valor de uCom. Solicite a identificação da tabela e da versão que o validador utilizou, além da evidência de ativação dessa regra no serviço correspondente.

Cenário sintético: o cadastro comercial possui uma abreviatura curta coerente com a operação, mas uma integração envia a descrição por extenso com mais de seis caracteres. Há problema estrutural verificável pelo schema, independentemente da ativação da 734. Em outro caso, a string atende ao XSD e um validador próprio a rejeita por uma lista interna. É necessário confirmar a origem da lista; não há base para inventar uma abreviatura substituta.

O que pode ser corrigido sem presumir a tabela

Compare a unidade da operação, a unidade cadastrada e o valor serializado, mantendo a relação com quantidade e preço. Se houve truncamento, campo trocado ou descrição indevida na integração, corrija a origem comprovada e confira o novo arquivo. Se o problema alegado é a tabela específica, obtenha sua publicação e aplicabilidade antes de mudar a representação.

Sem tabela vigente de ativação comprovada e sem unidade real do item, um XML com unidade arbitrária sugeriria uma correção não sustentada; por isso a demonstração é textual. Até essa confirmação, é possível diagnosticar formato e coerência, mas não afirmar qual abreviatura elimina a I09-10 nem que a regra esteja ativa universalmente.

Fontes oficiais

• MOC — Anexo I, Leiaute e Regras de Validação — 7.0: pp.93–94, I09-10 e observação de implementação futura.
• Leiaute da NF-e e protocolo — PL_010f_v1.04 / leiauteNFe_v4.00.xsd: linhas 1037–1046, det/prod/uCom.