Rejeição 828: tipo de autorização informado por autor que não pode preenchê-lo

A rejeição 828, com a mensagem “Não permitido informar o campo tipo de autorização”, pertence ao evento Ator Interessado na NF-e. Ela ocorre quando o campo tpAutorizacao é informado por um autor que não é o emitente nem o destinatário da nota. Antes de remover dados, confirme o serviço e a mensagem completa: outros documentos utilizam o mesmo número com significado diferente.

O objetivo do evento é permitir o acesso do transportador ao XML, nas condições documentadas. A informação rejeitada não é o tipo de emissão da NF-e, nem uma autorização genérica para o contador. Alterar a nota autorizada ou excluir pessoas do seu XML original não é a correção indicada pela regra desse evento.

Quem pode informar o campo

A NT 2020.007 v1.40 apresenta a P26-20, na página 10. A condição é expressa pelo papel do autor: quando ele não for o emitente ou o destinatário, o preenchimento de tpAutorizacao não é permitido. A linha aparece como obrigatória. No leiaute do evento, tpAutor identifica emitente, destinatário ou transportador contratado.

Emitente e destinatário possuem outra condição, a P26-10, que exige o campo e pode produzir 827. Portanto, retirar tpAutorizacao de todos os eventos não é uma solução geral. A integração precisa montar a mensagem conforme o autor verdadeiro e sua participação na operação, sem mudar a identificação apenas para tornar um campo aceitável.

O indicador admite os valores 0 e 1. Seu significado é permitir ou não que o transportador autorizado pelo emitente ou destinatário autorize outros transportadores a acessar o XML. Isso é diferente de conceder o próprio acesso ao transportador indicado no evento. Um valor zero continua sendo preenchimento: ele não equivale à ausência da tag quando a P26-20 exige que ela não seja informada.

Separe autor e pessoa autorizada

O evento 110150 possui a identificação de quem o produz e, no grupo autXML, a identificação de quem será autorizado a acessar o arquivo. Esses papéis não são intercambiáveis. Uma integração pode ter copiado o indicador usado pelo emitente para uma mensagem produzida pelo transportador, provocando a inconsistência que precisa ser investigada.

Confira o XML efetivamente transmitido, a chave, o ambiente e o retorno. Identifique o autor por seus dados e pelo papel declarado. Depois, confira o transportador indicado e a origem da permissão recebida. Uma configuração mostrada em tela ou um cadastro com nome semelhante não comprova a identidade levada ao serviço.

Se o transportador contratado estiver produzindo o evento, a ausência de tpAutorizacao não basta para provar que ele pode indicar outro transportador. Existem verificações próprias sobre a autorização anterior e a situação do participante. Remover o campo indevido corrige essa condição específica; não cria uma permissão que ainda não exista.

Exemplo de montagem incorreta

Considere um transportador contratado que, dentro de uma operação real de subcontratação, prepare um evento para indicar outro transportador. A integração reaproveitou uma estrutura usada pelo emitente e incluiu tpAutorizacao=0. Embora zero signifique que não há permissão de nova delegação nesse indicador, a tag continua presente na mensagem.

A equipe deve conferir o autor e a autorização de origem. Se o cenário for legítimo e o preenchimento indevido estiver confirmado, precisa ajustar a montagem para não gerar aquele campo nesse papel. Não deve trocar o autor para emitente, usar outro certificado ou simular uma autorização concedida por uma empresa diferente.

O exemplo não certifica a elegibilidade de um transportador, nem fornece uma mensagem fiscal pronta para envio. Ele demonstra por que trocar 1 por 0 pode manter a rejeição: o problema é a presença do campo para aquele autor, não apenas o valor escolhido.

Corrija a origem e regenere o evento

Revise a rotina que decide quais campos incluir para cada papel. Se houver erro de configuração, corrija a origem e gere novamente o evento pelo fluxo adequado, preservando a assinatura e os registros anteriores. Não edite um XML já assinado nem altere a NF-e autorizada para acomodar uma regra que pertence ao registro posterior de acesso.

Confira também xCondUso, a condição de uso. As regras 829 e 830 tratam sua presença conforme tpAutorizacao. Não acrescente uma declaração indiscriminadamente para eliminar uma mensagem diferente. A geração dos campos precisa representar a permissão real e seguir o leiaute aplicável, sem copiar um conjunto fixo de tags para qualquer autor.

Na documentação consultada, o evento é recebido pelo serviço de eventos do Ambiente Nacional. Confirme o endpoint e o ambiente da integração atual. A NF-e e a NFC-e aparecem na validação geral de chave, que admite os modelos 55 e 65; a antiga linha de exclusividade do modelo 55 está riscada. Isso não dispensa a conferência das demais condições do evento e do documento concreto.

Conclusão do atendimento

O calendário da versão 1.40 trata da alteração da 4P24-10, relativa ao cadastro do transportador. Não o transforme em uma data nova de implantação da P26-20. O índice nacional consultado identifica a versão 1.40, mas essa publicação não demonstra o funcionamento de uma instalação específica do ALRA ou de cada tentativa em produção.

Após a correção, confira a resposta individual, a chave, o tipo, o sequencial e o protocolo. O código 128 informa processamento do lote; não garante que o evento foi registrado. O retorno de registro deve ser interpretado conforme sua vinculação e mensagem. A autorização do evento também não comprova, sozinha, que o download foi concluído pela aplicação.

Se a rejeição persistir, encaminhe ao suporte a mensagem completa, o papel do autor e os trechos necessários do envio e retorno. Preserve a NF-e original e as permissões legítimas. Não publique certificado, senha ou dados particulares dos participantes para demonstrar o erro em um chamado aberto.

Fontes

Conferência em 16/10/2026: NT 2020.007 v1.40, páginas 3–6 e 8–13, com leitura textual selecionada e análise vetorial das exclusões nas páginas 9–11. PDF HTTP200 capturado hoje; numeração interna conserva “/12”, embora o arquivo possua 13 páginas. Sem novo render ou teste de evento.

Três apoios confrontados: FlexDocs, parâmetros do evento, com limites próprios de DLL; Focus NFe, panorama das versões; Berga, 828, corpo específico que mistura o grupo de autorizados da nota com o evento e foi usado criticamente. As primárias definem papel, campo e contexto. Sem transmissão, concessão real de acesso, consulta individual, XSD ou teste ALRA.