Voltar para o blog

Rejeições fiscais

Rejeição 829: condição de uso ausente no evento Ator Interessado

A rejeição 829 indica que o evento Ator Interessado foi enviado com tpAutorizacao=1, mas sem a condição de uso exigida em xCondUso. O indicador permite que o transportador autorizado pelo emitente ou destinatário autorize outros transportadores a acessar o XML. A declaração acompanha essa permissão e não deve ser…

Blog ALRA
Capa ilustrada da ALRA: Rejeição 829: condição de uso ausente no evento Ator Interessado.

A rejeição 829 indica que o evento Ator Interessado foi enviado com tpAutorizacao=1, mas sem a condição de uso exigida em xCondUso. O indicador permite que o transportador autorizado pelo emitente ou destinatário autorize outros transportadores a acessar o XML. A declaração acompanha essa permissão e não deve ser preenchida sem que seu alcance corresponda à decisão real do responsável.

Antes de corrigir, confira o retorno completo e o evento transmitido. Essa mensagem não informa que a NF-e original perdeu sua autorização, nem representa uma autorização de transporte ou uma declaração genérica sobre qualquer uso do sistema. O contexto é o acesso ao XML por participantes da operação de transporte.

A regra e os campos envolvidos

A NT 2020.007 v1.40 apresenta a P27-10, página 10: quando tpAutorizacao é igual a 1, deve ser informado xCondUso, declarando ciência da permissão concedida ao transportador. A linha aparece como obrigatória. O leiaute da página 6 descreve a condição relativa à possibilidade de autorizar transportadores subcontratados ou responsáveis pelo redespacho a acessar o arquivo.

O fato de xCondUso aparecer com ocorrência opcional no quadro do leiaute não elimina essa obrigação condicional. Uma integração não pode decidir pela omissão apenas porque o campo não é exigido em todos os cenários. O valor de outro campo, nesse caso o indicador de permissão, é o que determina sua necessidade.

Há também a P27-20, código 830: se o tipo informado for diferente de 1, a condição de uso não é permitida. Portanto, acrescentar a declaração a todos os eventos pode produzir outro erro. O conjunto deve ser montado conforme o papel do autor, a permissão escolhida e as informações verdadeiras da operação.

A permissão não deve ser alterada por conveniência

No leiaute, o indicador 0 significa que não se permite aquela delegação a outros transportadores; o valor 1 permite. Não se trata simplesmente de “cancelar” ou “autorizar” a própria NF-e. Também não se deve concluir que 0 elimina o acesso do transportador originalmente indicado ao XML: o campo trata de uma permissão específica de extensão desse acesso.

Se o responsável realmente deseja conceder a delegação prevista e ela é cabível, a integração precisa gerar a condição de uso correspondente. Se o valor 1 foi lançado por engano, a equipe deve rever a decisão com quem tem legitimidade para tomá-la. Trocar para 0 somente porque isso elimina a exigência de texto mudaria o conteúdo da autorização.

O autor do evento e o transportador autorizado são participantes diferentes. As regras 827 e 828 determinam quando tpAutorizacao é exigido ou vedado conforme o autor. Um transportador contratado não pode fingir ser emitente ou destinatário para preencher o indicador e declarar uma permissão em nome deles.

Onde procurar a falha

Guarde o XML transmitido, a resposta, a chave da nota e o ambiente. Confira se o envio corresponde ao evento 110150 e se o indicador realmente ficou igual a 1. Depois, verifique a presença e o conteúdo de xCondUso no arquivo que chegou à transmissão, sem depender apenas de uma opção assinalada na tela.

Examine a origem da montagem: configuração do emissor, integração, regra de preenchimento e eventual transformação de dados. Uma rotina pode ter incluído o indicador sem gerar a declaração ou perdido o campo entre a preparação e a assinatura. Essas são hipóteses para investigar nos registros; a rejeição isolada não demonstra qual etapa falhou.

A declaração deve seguir o leiaute e o schema adotados pela integração. Não substitua seu conteúdo por uma observação comercial, por texto sobre pagamento ou por uma frase livre de concordância. Este artigo não fornece um fragmento XML pronto nem afirma ter validado um texto particular contra o schema do ambiente.

Exemplo de correção coerente

Uma empresa emitente indica o transportador de uma operação e confirma que deseja permitir a indicação de subcontratados ou responsáveis pelo redespacho. O sistema gera tpAutorizacao=1, mas a integração omite xCondUso. O evento recebe 829.

Nesse exemplo didático, a equipe deve verificar a decisão legítima, corrigir a geração da declaração e conferir o novo arquivo. Não precisa modificar os dados fiscais da nota autorizada nem substituir sua chave. Também não deve retirar a delegação desejada apenas para escapar do preenchimento exigido.

Se o responsável não havia concedido essa permissão, a investigação segue outro caminho: descobrir por que o indicador foi criado com valor 1 e corrigir a origem da decisão. O exemplo demonstra a relação entre os campos; não garante que qualquer transportador ou evento será aceito após esse ajuste.

Regeneração e conferência do resultado

Faça a correção pelo fluxo adequado da integração, com nova geração e assinatura quando aplicável. Preserve a tentativa rejeitada e a resposta para comparação. Editar manualmente um XML assinado pode romper sua integridade e não constitui uma forma confiável de corrigir os dados de origem.

O evento é descrito para o serviço de eventos do Ambiente Nacional. Confirme endpoint e ambiente atuais. A validação geral de chave admite modelos 55 e 65 na versão examinada; a antiga linha que limitava o modelo a 55 está riscada. Isso não dispensa as outras condições do serviço nem comprova a disponibilidade de recursos em uma instalação específica do ALRA.

O calendário da versão 1.40 se refere à mudança da 4P24-10, relativa ao cadastro do transportador. Não o use como nova data de implantação da P27-10. O índice nacional confirma a publicação da versão consultada, mas não demonstra o processamento de uma requisição concreta em homologação ou produção.

Após reenviar, confira o resultado individual, a vinculação, a chave, o tipo, o sequencial e o protocolo. O código 128 informa que o lote foi processado, sem garantir o sucesso de cada evento. A confirmação de registro também não substitui a verificação de que o acesso pretendido foi exercido corretamente pela aplicação. Se houver outra mensagem, trate sua condição própria com o suporte.

Fontes

Conferência em 16/10/2026: NT 2020.007 v1.40, páginas 3–6 e 8–13. PDF HTTP200 capturado hoje, reutilizado por hash; leitura textual e análise vetorial selecionadas, sem novo render. A versão possui 13 páginas físicas, apesar de conservar “/12” em sua numeração interna.

Apoios confrontados: FlexDocs, parâmetros do evento e limitações de produto; Focus NFe, panorama com códigos 827–831; Berga, 829, guia específico. Foram descartadas a equivalência de 0 com cancelamento, a transposição de menus ao ALRA, alegações de frequência sem evidência e a extensão irrestrita a modelos ou operações. Não houve transmissão, concessão real de acesso, teste XSD ou teste ALRA.

Pronto para dar o próximo passo?

Pronto para organizar sua empresa e ganhar mais tempo?

Teste grátis por 15 dias e descubra como a Alra pode transformar a gestão do seu negócio.