Rejeição 763: dados de aquisição de cana no documento errado

Se a autorização retornou 763, peça ao suporte para conferir o grupo de aquisição de cana no XML transmitido. Na NT 2026.002 v1.11, esse grupo é incompatível com NFC-e 65 ou NF-e 55 com DANFE Simplificado Tipo 2 (tpImp=6). A investigação precisa separar uma configuração herdada de uma operação que realmente exige documentação de aquisição de cana.

Não comece alterando o produto ou apagando registros de fornecimento. A mensagem não diz que a mercadoria está proibida, nem resolve o enquadramento fiscal da atividade. Ela aponta uma incompatibilidade entre a estrutura enviada e o documento utilizado. A correção precisa preservar os fatos da operação.

A mensagem oficial e seu contexto

Este artigo trata do cStat 763 em NFeAutorizacao (NT, página 8). Confira cStat e xMotivo no retorno. Na NT 2026.002 v1.11, página 20, regra ZC01-10, a mensagem é “Rejeição: NFC-e ou NF-e com DANFE Simplificado Tipo 2 com dados de aquisição de Cana”. Na página 20, a linha verifica o grupo cana e está marcada como obrigatória, com efeito de rejeição, sem exceção particular. Abrange NFC-e modelo 65 e NF-e modelo 55 com tpImp=6. NT 2026.002 v1.11.

No MOC 7.0, página 128, a mensagem histórica é “Rejeição: NFC-e com dados de aquisição de Cana”, para modelo 65. Na NT atual, o alcance inclui NF-e 55 com tpImp=6; não toda NF-e 55. O DANFE Tipo 2 não muda o modelo para 65.

O índice oficial SVRS consultado em 15/10/2026 apresenta a v1.11 e ressalva possíveis alterações de datas. Na página 3 da NT, ZC01-10 integra o conjunto previsto para testes em 01/07/2026 e produção em 03/08/2026. A página 20 mantém sua linha íntegra, sem exclusão do modelo 55 com Tipo 2.

A v1.11 adia I08-180, BA02-35 e VC02-40 para 14/12/2026; não inclui ZC01-10. Tampouco as exceções das regras de QR Code, na mesma página, permitem informar cana: são verificações de outro grupo. A ZC01-10 não apresenta exceção própria por UF, atividade, direção da emissão ou entrega.

Consulta documental e calendário não comprovam a implantação individual no autorizador da empresa. Registre UF emitente, serviço e ambiente: tpAmb=1 é produção; tpAmb=2, homologação. Examine a resposta no ambiente correto.

O que é o grupo cana

No MOC, páginas 64–65, o grupo reúne safra, período de referência, fornecimentos diários, quantidades acumuladas e valores do fornecimento e das deduções. Ele não é simplesmente a descrição de um produto que contém cana, açúcar ou outro derivado. O nome de uma mercadoria no cadastro não justifica montar essa estrutura automaticamente. O esquema XML 010f também distingue cana como grupo próprio, dentro de infNFe. Sua existência no esquema geral não autoriza seu uso em todos os modelos e formatos.

Uma causa possível é a mesma empresa operar rotinas distintas com um perfil fiscal compartilhado. A configuração usada para registrar fornecimentos pode ser reaproveitada no caixa. Outra hipótese é uma integração criar cana em todos os documentos, porque considera suficiente a existência de dados de safra no cadastro. Também pode haver uma nota copiada com o grupo antigo preservado.

Essas possibilidades são hipóteses técnicas, não conclusões sobre a empresa. O XML da tentativa rejeitada permite verificar se o grupo existe e o que o alimentou. Uma tela sem informações visíveis não garante que o gerador tenha deixado de enviá-lo.

O diagnóstico deve preservar a rastreabilidade

Guarde a resposta original da SEFAZ, o XML enviado, chave, número, série, horário e versão do emissor. Confira mod, tpImp, UF do emitente e ambiente. Identifique o autorizador efetivamente utilizado. Um teste em homologação não confirma o resultado de uma venda em produção.

Peça ao suporte que localize cana dentro de infNFe e relacione o conteúdo com a origem dos dados. Há valores de fornecimento real, dados preenchidos por padrão ou apenas uma estrutura residual? Compare também com a natureza da operação cadastrada e com o documento que a equipe pretendia emitir.

Não edite manualmente o XML já assinado. Ajuste a origem e regenere o arquivo pelo emissor. Se houver dúvida sobre o resultado de um envio anterior, consulte a situação da chave antes de produzir outro documento. Uma rejeição precisa ser conciliada com o histórico para evitar duplicação.

Correção conforme o cenário

Venda de caixa com dados de aquisição herdados

Se a operação está corretamente documentada por NFC-e e não exige o grupo de aquisição, corrija o perfil ou mapeamento que o incluiu. Gere novamente a nota sem cana, preservando produtos, quantidades, valores e demais informações verdadeiras. Confira o arquivo novo, porque limpar apenas safra ou referência pode deixar a estrutura sendo montada e ainda criar erro estrutural. Zerar valores ou reduzir a quantidade também não elimina a presença do grupo.

Ajuste também a origem para os próximos documentos. Se o problema vinha de uma configuração compartilhada, corrigir somente a nota rejeitada deixa a causa disponível para reaparecer. Preserve os registros de aquisição legítimos nas rotinas próprias, sem aplicar uma remoção global do grupo.

A operação é efetivamente aquisição de cana

Não exclua os dados necessários apenas para autorizar um documento incompatível. O responsável fiscal deve conferir natureza da operação, direção da emissão, participante e documento cabível. O tratamento concreto pode envolver exigências da atividade e da UF que a rejeição 763, isoladamente, não esclarece.

A NF-e 55 sem o formato Tipo 2 precisa ser avaliada segundo suas próprias condições e validações. Isso não autoriza prescrever automaticamente uma nota de entrada para todo caso, nem simplesmente trocar tpImp. O grupo e os valores precisam refletir o fornecimento real e o enquadramento confirmado pelo responsável fiscal.

NF-e com tpImp=6

O fato de o operador selecionar NF-e não afasta a regra. Confira se o formato Tipo 2 foi escolhido para aquela operação e se é cabível. Se cana surgiu indevidamente, corrija a geração; se é uma informação fiscal necessária, revise o documento e o formato com o contador antes de retransmitir.

XML e retorno não combinam

Se o arquivo contém NF-e 55 sem tpImp=6, ou não contém cana, compare a chave da resposta e o XML efetivamente enviado. Verifique versões armazenadas e transformações da integração. Não remova o grupo de documentos legítimos com base em um retorno associado à tentativa errada.

Exemplo original e verificação final

Uma empresa fictícia mantém uma rotina para registrar fornecimentos de cana e um pequeno ponto de venda de materiais de consumo. O emissor utiliza um perfil compartilhado e inclui dados de safra e fornecimento no XML de uma NFC-e de R$ 168 referente à venda de materiais. O retorno é 763.

A equipe confirma a operação do caixa, identifica o perfil indevido e separa a geração dos documentos. A NFC-e seguinte não contém cana; os registros verdadeiros de fornecimento permanecem preservados na rotina correspondente. O exemplo ilustra uma configuração reaproveitada indevidamente, sem definir a tributação da aquisição real.

Depois de corrigir, leia o novo resultado do documento. Uma autorização precisa estar ligada à chave e ao XML certos, com protocolo preservado. Outra rejeição exige novo diagnóstico. Confira também se a alteração não prejudicou registros comerciais, financeiros ou de fornecimento.

Acione o suporte se o grupo reaparecer ou se não for possível localizar sua origem. Procure o contador quando houver aquisição real ou dúvida sobre documento e formato. A solução deve tornar o XML coerente com a operação, sem inventar valores, apagar fornecimentos ou prometer aprovação pela SEFAZ.

Fontes

Referências conferidas em 15/10/2026, horário de Brasília. A orientação documental não certifica implantação individual por UF/ambiente nem substitui o enquadramento da operação concreta.

• NT 2026.002 v1.11, páginas 3, 5, 7, 8 e 20: calendário, retorno, formato e regra ZC01-10.

• Documentos da SVRS: disponibilidade da v1.11 e ressalva de datas.

• MOC 7.0, Anexo I, páginas 64, 65 e 128: grupo cana, campos e contexto histórico do modelo 65. As condições do responsável técnico na página 128 pertencem a outro grupo.

• Esquemas XML oficiais, pacote 010f: estrutura do grupo cana, distinta da autorização fiscal para preenchê-lo.

Apoios práticos: Oobj, TecnoSpeed e Webmania. Os três explicam o modelo 65; a extensão ao Tipo 2 vem da NT. A tabela da Oobj mostra 762 nessa linha, divergindo de seu próprio título e da primária, que confirma 763. Fragmentos XML com problemas de sintaxe ou conteúdo não foram usados como exemplos válidos. A ausência de opção no emissor Webmania não comprova o funcionamento do ALRA. A orientação de remover o grupo exige confirmar que sua inclusão era indevida, preservando os fornecimentos reais.