Campos Acessorios

O que são campos acessórios na Nota Fiscal eletrônica

Campos acessórios são os campos opcionais do layout da NF-e que servem para acrescentar informações complementares à operação. Eles não substituem os campos obrigatórios, mas completam o documento quando a situação exige. A principal tag responsável por isso é a INFOADIC, que divide o conteúdo em partes como observações do contribuinte, dados de frete, referência a documentos e informações adicionais de interesse da UF. Eu preencho campos acessórios todos os dias. O padrão do contribuinte (obsCont) é o mais usado. Ele permite até 2 mil caracteres para você colocar um justificativo, uma referência interna, o nome do cliente ou qualquer coisa que o sistema da sua empresa exija. A UF pode ter a própria seção (obsFISCO) com regras específicas — alguns estados exigem que você repita determinada informação lá também, caso contrário a SEFAZ rejeita a nota. O campo de dados do frete (nFM) merece atenção separada. Ele serve para informar se o frete é por conta do remeterente, do destinatário ou próprio, além do valor do frete. Muita gente coloca isso errado e depois passa horas tentando entender por que o CTe vinculado não casa com a NF-e.

Como preencher campos acessorios corretamente

Primeiro você precisa saber o fluxo. Quando a NF-e é transmitida, a SEFAZ valida o XML inteiro. Campos acessórios passam pela mesma validação dos campos obrigatórios quanto a tamanho máximo, caracteres especiais e codificação. Um acento mal colocado ou um "&" sem escape já quebra a assinatura XML e o documento nem sai do seu computador. Dentro de obsCont, use a estrutura padrão descrita no manual de orientações. Cada linha pode ter no máximo 60 caracteres e você tem espaço para várias linhas. Eu costumo adotar o seguinte padrão: • Linha 1: referência do pedido ou EMPLACA quando for transporte
• Linha 2: observação interna da operação
• Linha 3: informação fiscal quando houver diferença de alíquota

Esse método evita confusão na hora da conferência e ainda deixa o campo legível para quem vai receber a NF-e. Não invente formato. A SEFAZ não lê estrutura, ela só valida tamanho e codificação. Para obsFISCO, o problema é diferente. Cada estado define suas próprias regras. Em São Paulo, por exemplo, o campo X OBS é frequentemente exigido para informar o número do processo administrativo em caso de recuperação judicial. No Rio de Janeiro, há situações em que se pede a informação do CFOP completo quando o produto enquadra em determinação específica. Se você não consultar o manual da UF correspondente antes de montar o XML, vai levar rejeição 935 ou similar na hora da transmissão.

Um problema real que eu enfrentei

Há alguns meses, uma empresa enviou NF-e com mais de 2 mil caracteres em obsCont. O manual diz claramente que o limite é 2 mil, mas eles tinham colocado tudo junto em um único bloco de texto, sem respeitar a divisão por linhas de 60 caracteres. A SEFAZ SP aceitou o XML, mas quando o destinatário tentou consultar os dados pela API de consulta, parte da informação vinha truncada. A nota estava tecnicamente válida, mas inutilizável para o cliente. A solução foi simples: dividi o texto em linhas de 60 caracteres usando uma função de quebra de string no código e redistribuí o conteúdo respeitando o limite. Depois disso, tanto a transmissão quanto a consulta funcionaram perfeitamente. Nunca subestime a diferença entre "a SEFAZ aceitou" e "o campo funciona na prática".

Pegadinhas comuns que iniciantes cometem

O campo nProc é outro ponto de falha frequente. Ele serve para indicar que a operação decorre de processo judicial ou administrativo. Muitos colocam apenas o número do processo. O correto é informar o tipo (1 para judicial, 2 para administrativo) e o ano de ajuizamento. Sem esses dois detalhes, a informação não tem valor fiscal e acaba sendo ignorada pelo fisco. Outro erro crônico é confundir infoAdic com os campos de identificação do produto. Cam pos acessórios não servem para corrigir omissões de campos obrigatórios. Se você esqueceu o NCM de um item, colocar o código na observação não resolve. A SEFAZ rejeita por inconsistência e ainda marca a nota como irregular. Existe ainda o problema da codificação. O XML da NF-e deve ser salvo em UTF-8. Se o seu sistema exporta em ISO-8859-1 ou Windows-1252, os campos acessórios com acentos vão gerar erros de parsing. Eu já vi isso acontecer com sistemas legados que usavam a biblioteca de geração de XML configurada para ASCII. A correção exigiu alterar o charset em três arquivos diferentes do pacote de exportação.

Limitações que ninguém avisa

Campos acessorios não são bala de prata. Eles têm restrições sérias. O tamanho máximo de obsCont é 2 mil caracteres. Se você precisa registrar mais informações do que isso, o caminho certo é usar o campo nDocAcomp ou vincular um documento complementar via URL, não tentar empurrar texto adicional pela observação. O segundo problema é a variabilidade por UF. O mesmo estado pode mudar o que exige em obsFISCO a qualquer momento, sem aviso prévio. A melhor prática é consultar o manual de orientações da SEFAZ da sua UF toda vez que houver atualização do layout, não apenas quando algo dar errado. O site da SEFAZSP, por exemplo, publica atualizações trimestrais que alteram os campos obrigatórios de.obsFISCO. Se o seu volume de NF-e for alto, manter a consistência dos campos acessorios manualmente é inviável. Automate a preenchimento com base em regras de negócio armazenadas no banco. Se a nota tiver CFOP 5.949, insira automaticamente a referência do processo na linha 1 de obsCont. Se o frete for próprio, preencha nFM com os valores corretos. Quanto mais regra automatizada, menos chance de erro humano.

Por onde começar

Baixe o manual de orientações do contribuinte no site da SEFAZ da sua UF. Leia a seção sobre INFOADIC. Depois, abra um XML de nota que já tenha sido aceita e examine como os campos acessorios estão preenchidos. Compare com o manual. Esse exercício leva cerca de trinta minutos e elimina a maior parte dos erros de preenchimento. Se você desenvolve software, valide o XML com o esquema XSD oficial antes de transmitir. A validação contra o schema captura a maioria dos erros de formato. O que ela não captura são as regras de negócio específicas de cada estado, então mantenha a verificação manual para obsFISCO pelo menos nas primeiras implantações.