Rejeição 783: NFC-e não pode ser autorizada pela SVC
Revisão editorial em 15 de out. de 2026. Confira as versões e condições das regras nas fontes do artigo.
A Rejeição 783, regra B22-70, estabelece que a SVC não autoriza NFC-e 65. A regra é obrigatória. Escolher 6 para SVC-AN ou 7 para SVC-RS não supera a restrição de modelo: esses tipos atendem a outra verificação, enquanto a 783 trata especificamente da NFC-e recebida pela SVC. MOC 7.0, Anexo I, p. 76-77.
Por que uma NFC-e pode chegar à SVC?
A origem pode ser uma configuração copiada da NF-e, um mecanismo de fallback genérico ou uma seleção incorreta de URL. Essas são hipóteses a demonstrar. Reúna mod do XML, tpEmis, UF, ambiente, endpoint efetivo e o retorno completo da mesma tentativa.
O modelo fiscal não deve ser deduzido da impressão nem do nome do módulo. mod=65 identifica NFC-e e mod=55 identifica NF-e. A NF-e com DANFE Simplificado Tipo 2 continua 55, embora compartilhe algumas condições de emissão com a NFC-e. O documento enviado e seu modelo real são a referência para a 783.
Contingência offline é o mesmo serviço SVC?
Não. Offline 9 é uma modalidade com posterior transmissão ao autorizador pertinente e depende das regras aplicáveis, inclusive da UF. SVC é um serviço virtual de contingência, com tipos 6/7 e condições próprias. Uma indisponibilidade não autoriza transportar automaticamente a NFC-e para qualquer SVC.
A 712 confere aceitação estadual do offline 9; a 714 confere outras modalidades e a ressalva EPEC 4. Esses caminhos não são recomendações de seleção: é preciso confirmar o procedimento realmente cabível e executado. A 783 não escolhe a contingência adequada para o leitor.
Exemplos de fallback e modelo confuso
Exemplo sintético: o integrador perde a resposta do serviço normal de NFC-e e manda a mesma nota à SVC-RS, agora com tipo 7. A 783 impede a autorização do modelo 65 nesse serviço. Antes de qualquer novo envio, consulte o resultado da primeira tentativa, que pode ter sido processada apesar do timeout. Depois revise o fallback que escolheu o destino incompatível.
Em outro caso, a aplicação emite NF-e 55/tpImp=6 e o operador a chama de NFC-e pela aparência. A 783 exige conferir o XML realmente transmitido: se ele é 55, a condição “NFC-e 65 na SVC” não deve ser presumida. Verifique se o retorno pertence a outra nota ou se houve geração diferente da prevista.
O que comprova a resolução do roteamento?
A configuração final deve corresponder ao modelo, UF, ambiente e modalidade reais. Corrija a origem comprovadamente incorreta do endpoint; não mude mod, tpEmis ou UF para manter o destino errado. Se a espécie documental estiver indefinida, confirme-a com os responsáveis usando os documentos da operação.
Preserve o XML e o retorno das tentativas e reconcilie estados incertos antes de reenvio. Avalie a resposta individual do autorizador correto após a ação cabível. XSD válido, conexão TLS ou HTTP 200 não demonstram autorização nem substituem o resultado fiscal.
Os exemplos são cenários sintéticos de diagnóstico. Os valores são apresentados em texto para comparação; não constituem um XML fiscal pronto para transmitir. A conferência operacional exige o XML original e o retorno da mesma tentativa.