Result — com cStat, xMotivo e o XML de retorno disponíveis para inspeção imediata. Sua aplicação deve tratar cada rejeição de forma deliberada, corrigir os dados e reenviar o documento quando apropriado.
O que é uma rejeição (vs. falha técnica)
É essencial distinguir os dois tipos de resultado negativo no SDK:| Característica | Rejeição esperada | Falha técnica |
|---|---|---|
| Origem | Regra de negócio / validação SEFAZ | Infraestrutura: timeout, HTTP 5xx, rede |
| Retorno no SDK | Result com isRejected() === true | InfrastructureException lançada |
| cStat disponível | Sim | Não |
| Deve retortar? | Somente após corrigir os dados | Pode retentar com RetryPolicy |
| Exemplo | CNPJ inválido, schema com campo faltando | Timeout de 30s, servidor SEFAZ indisponível |
Uma rejeição SEFAZ significa que o webservice foi alcançado e processou a requisição — a resposta é definitiva para aqueles dados. Já uma
InfrastructureException indica que não foi possível sequer obter uma resposta.Códigos cStat comuns
A tabela abaixo lista códigoscStat frequentes no ciclo de autorização de NF-e e CT-e. Consulte o Manual de Orientação do Contribuinte (MOC) da SEFAZ para a relação completa e atualizada.
| cStat | Descrição | Ação recomendada |
|---|---|---|
100 | Autorizado o uso do DF-e | — (sucesso, não é rejeição) |
101 | Cancelamento homologado | — (sucesso de cancelamento) |
104 | Lote recebido com sucesso | Consultar processamento do lote |
110 | Uso Denegado | Verificar situação fiscal do emitente junto à SEFAZ |
204 | Duplicidade de NF-e | Verificar se a chave já foi emitida; recuperar XML autorizado |
217 | NF já existe no sistema SEFAZ | Verificar chave e recuperar o XML autorizado já registrado |
225 | Rejeição: Falha no Schema XML | Verificar campos obrigatórios e estrutura do XML |
252 | Rejeição: Layout inválido | Corrigir versão ou estrutura do layout conforme MOC vigente |
431 | Rejeição: Emissão em contingência | Verificar modo de emissão e regras de contingência aplicáveis |
539 | Rejeição: CNPJ do emitente inválido | Verificar e corrigir CNPJ do emitente |
999 | Rejeição: Erro não catalogado | Analisar xMotivo detalhadamente; acionar suporte se persistir |
Os códigos
100, 101 e 104 indicam sucesso ou processamento intermediário — não são rejeições. O SUOT Fiscal SDK os mapeia corretamente para isSuccess() ou para o estado de lote pendente, conforme o contexto.Tratando rejeições
UseisRejected() para interceptar rejeições e registre sempre cStat e xMotivo antes de tomar qualquer ação:
Reconstruindo o Command corrigido
O SUOT Fiscal SDK adota Commands imutáveis: uma vez construído, um Command não pode ser alterado. Isso garante rastreabilidade e evita mutações acidentais entre tentativas. Para corrigir e reenviar, construa um novo Command com os dados corretos:Rejeições vs. falhas técnicas — resumo
| Rejeição esperada | Falha técnica (InfrastructureException) | |
|---|---|---|
| cStat disponível | ✅ Sim | ❌ Não |
| xMotivo disponível | ✅ Sim | ❌ Não (mensagem de infraestrutura) |
| Ação imediata | Corrigir dados, reconstruir Command | Retente com RetryPolicy ou investigue conectividade |
| Deve fazer retry automático? | ❌ Nunca (mesmo resultado) | ✅ Sim, para falhas transitórias |
| Exemplo de código | $result->isRejected() | catch (InfrastructureException $e) |
Próximos passos
Resultados de operações
Entenda a anatomia do Result e como inspecionar sucesso, rejeição e falha técnica.
Retry Policy
Configure retentativas automáticas para falhas transitórias de infraestrutura.