Rejeição 450: NFC-e enviada ao autorizador de NF-e

A Rejeição 450, regra B06-30, ocorre quando a SEFAZ mantém ambientes de autorização separados por modelo e uma NFC-e é enviada ao serviço destinado à NF-e. A mensagem “Modelo da NF-e diferente de 55” deve ser lida nesse contexto de recepção: o serviço esperava modelo 55 e recebeu modelo 65. A regra é facultativa, pois depende dessa separação adotada pela SEFAZ. MOC 7.0, Anexo I, p. 75.

O que conferir no XML e no serviço acessado?

Leia infNFe/ide/mod no XML realmente transmitido e compare com o endereço do Web Service usado pela integração. mod=65 identifica a NFC-e; mod=55 identifica a NF-e. A URL escolhida depende do autorizador da UF, do serviço, do modelo e do ambiente de produção ou homologação. Não deduza o destino apenas pelo nome comercial do provider ou por uma opção visível na tela.

A confirmação exige o endpoint efetivo da tentativa: aplicações podem ter configurações distintas para NFC-e e NF-e e reutilizar por engano o cliente de comunicação de um deles. A chave, o XML e o retorno devem pertencer à mesma tentativa e empresa. MOC 7.0, Anexo I, p. 75.

“Ambientes separados” significa produção e homologação?

Nesta regra, a separação é entre os serviços de autorização de NF-e e NFC-e. Produção e homologação são outra dimensão. Uma NFC-e pode ter tpAmb correto e ainda chegar ao serviço do modelo errado. Inversamente, o modelo pode estar certo e o ambiente errado; a divergência tpAmb versus serviço é a condição da 252/B24-10.

A 775/B06-40 é o sentido inverso da 450: NF-e recebida pelo serviço de NFC-e. A 765 trata a composição de modelos do lote. Identificar a direção evita corrigir o endpoint errado ou modificar notas cuja configuração já estava correta.

Exemplos de configuração que levam à 450

Exemplo sintético: uma venda já documentada como NFC-e gera mod=65 e tpAmb=2. O emissor seleciona por engano o endereço de homologação da NF-e modelo 55 na UF que separa os serviços. A comparação mostra ambiente de teste consistente, mas modelo incompatível com aquele serviço. A correção comprovada está no roteamento da NFC-e para o serviço pertinente.

Em outro cenário, o operador acredita emitir uma NF-e, mas o XML tem mod=65. Trocar somente o endpoint não comprova que a espécie documental foi corretamente definida. É preciso localizar a origem dessa escolha e confirmar, com os documentos e responsáveis, qual modelo deve representar a operação. Não se altera mod apenas para eliminar a mensagem.

Como corrigir e validar o roteamento?

Compare a tabela/configuração oficial de serviços da UF com a URL efetiva, o ambiente e o XML da tentativa rejeitada. Corrija a seleção ou a configuração somente quando a divergência estiver demonstrada. Valide em ambiente de desenvolvimento/homologação com documentos de teste; uma URL que responde HTTP 200 não comprova autorização fiscal.

Se a transmissão anterior terminou sem resposta conclusiva, consulte seu estado antes de novo envio. Após uma tentativa cabível, confira o retorno individual com cStat e xMotivo e a identidade da nota. Preserve o histórico; não mude o modelo de XML autorizado nem reutilize uma chave de outra empresa.

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.