Rejeição 557: falta justificar a entrada em contingência

A rejeição 557 indica que faltam os dados exigidos para uma emissão em contingência: a justificativa, a data e hora de entrada, ou ambos. Para corrigir, recupere o motivo real da ocorrência e o momento em que a contingência foi iniciada, confira a modalidade utilizada e faça essas informações chegarem aos campos próprios do XML.

Não basta escrever “problema na SEFAZ” nas observações da nota. Também não é seguro preencher o horário atual automaticamente em toda retransmissão. Esses dados descrevem o que aconteceu na emissão; não servem apenas para destravar a fila.

Quais campos precisam estar preenchidos

A regra B28-20 do MOC 7.0, Anexo I, página 78 exige dhCont e xJust nos cenários com tpEmis=2, 4, 5 ou 9. Ela está classificada como obrigatória para os modelos 55 e 65 no serviço de autorização, observadas as modalidades admitidas para cada modelo.

No grupo ide do XML, dhCont informa quando começou a contingência; xJust explica o motivo. Mesmo que a mensagem fale apenas em justificativa, a falta de dhCont também precisa ser investigada. Um campo preenchido na tela pode não ter sido transportado para o arquivo efetivamente enviado.

No leiaute do MOC, xJust admite de 15 a 256 caracteres. O tamanho não torna verdadeira uma explicação inventada. Textos vazios, curtos demais ou malformados podem falhar no esquema XML antes da avaliação da regra 557. Por isso, não espere sempre o mesmo código para toda deficiência desses campos.

Como os tipos de emissão se relacionam com a regra

O conjunto da B28-20 não é uma autorização para usar todas as opções em qualquer nota:

• 2 e 5 correspondem a modalidades com formulário de segurança, sujeitas às condições próprias da NF-e;

• 4 corresponde ao EPEC no leiaute, embora a redação histórica dessa regra ainda mencione DPEC;

• 9 identifica emissão off-line nos cenários em que ela é admitida.

A presença de um nome antigo no manual não reativa um serviço encerrado. SCAN também não deve ser usado: tpEmis=3 passou a identificar o regime especial NFF. Já 6 e 7 identificam as SVC e não integram o conjunto explícito da B28-20. Isso delimita o gatilho dessa rejeição, mas não dispensa os dados na SVC: o MOC, Anexo III, página 11 também prevê xJust e dhCont no procedimento dos tipos 6 e 7.

Para NFC-e, as opções de contingência documentadas são off-line e, a critério da UF, EPEC. Formulários de segurança e SVC não são alternativas gerais para o modelo 65.

O cuidado adicional com o off-line da NF-e

Materiais antigos dizem que tpEmis=9 pertence apenas à NFC-e. A NT 2026.002 v1.11, páginas 3, 7 e 8 passou a contemplar também a NF-e com DANFE Simplificado Tipo 2, tpImp=6, sob as condições previstas.

A mesma NT mantém uma rejeição específica para NF-e off-line fora da operação permitida. Antes de aplicar o procedimento, valide versão do sistema, UF, ambiente e enquadramento da operação. Não trate a data programada no documento técnico como prova de implantação uniforme em todos os autorizadores.

Exemplo: justificativa existe, mas ficou no lugar errado

Uma empresa fictícia adotou uma modalidade de contingência permitida. A equipe registrou o incidente em um chamado interno e colocou a descrição nas informações adicionais da nota. O componente fiscal, porém, enviou o XML sem xJust.

A correção é aproveitar o registro verdadeiro do incidente e informar o campo específico. Se o problema foi a conexão do estabelecimento, não declare indisponibilidade da SEFAZ sem evidência. Registre uma descrição objetiva e suficiente para identificar o motivo técnico. Confira também o horário original de entrada e o fuso correspondente.

As orientações da Oobj e da Dynamicca mostram a importância de conferir as duas tags no XML. Os exemplos desses produtos não substituem a análise da modalidade e do leiaute atual.

Passo a passo para resolver sem perder o histórico

1. Guarde a resposta integral com cStat 557 e identifique nota, modelo, UF e ambiente.

2. Consulte a situação da chave e verifique tentativas anteriores pendentes, protocolos e eventual EPEC relacionado.

3. Confirme que a nota realmente foi emitida em contingência e que tpEmis representa o procedimento adotado.

4. Recupere o motivo e o início da ocorrência nos registros do sistema, da rede ou do atendimento técnico.

5. Preencha dhCont e xJust na origem correta e confira o XML novamente gerado.

6. Valide o arquivo, assine pelo fluxo normal e transmita para o serviço correspondente. Arquive a resposta individual.

Se não houve contingência, não invente uma justificativa para acomodar tpEmis errado. Investigue a classificação indevida antes de alterar o documento. Se a cronologia não puder ser reconstruída com segurança, envolva o responsável fiscal e o suporte do emissor.

Cuidados com parâmetros e retransmissões

A TOTVS descreve o preenchimento nos parâmetros do Protheus/TSS. Essa é uma orientação de produto: nomes de telas, restrições de caracteres e efeitos sobre a próxima transmissão variam entre soluções.

Verifique se o parâmetro vale para uma nota, uma fila inteira ou todas as próximas emissões. A volta ao modo normal deve ser controlada sem apagar os dados de documentos que já nasceram em contingência. Fazer uma correção global às pressas pode resolver o 557 de uma nota e provocar o 556 em outras.

Editar um XML assinado por fora do emissor invalida sua assinatura. Corrija os dados antes da geração e use o certificado e o ambiente corretos. Uma nota de homologação aceita não comprova autorização da venda em produção.

Quando a nota pode ser considerada resolvida

O desaparecimento do 557 significa apenas que essa etapa foi superada. Ainda podem existir validações de datas, modalidade, EPEC ou outros grupos. Não emita uma segunda nota para a mesma operação sem esclarecer o resultado das tentativas anteriores.

Finalize com situação fiscal confirmada, XML e protocolo correspondentes, além do registro do incidente. A melhor prevenção é uma rotina que grave os fatos da contingência no momento da ocorrência e preserve esses dados durante a regularização da fila.

Revisão documental por IA: 9 de outubro de 2026. Escopo: autorização de NF-e e NFC-e, sem extensão a justificativas de eventos.