Ct-e e mdf-e

Concordo em parte, Luiz Medeiros, mas discordo de achar que toda recusa vem de dado da carga. A prova é, ó: no modal rodoviário, a versão do layout do modal que o web service recebe também precisa ser suportada, e um schema fora do esperado derruba o envio sozinho, com dados corretos. Por isso eu leria o código de retorno do MDF-e antes de culpar o cadastro.

Dúvida curta, Gabriel: a checagem prévia também ajuda no MDF-e e no CT-e quando o retorno demora? E aí, o x da questão: num momento posterior ao envio, o recebimento do retorno fica em fila no nosso SAP e a rejeição aparece depois. Vale registrar o retorno por viagem, para ligar a recusa ao CT-e de origem?

E aí, aqui na empresa, na rotina daqui, o MDF-e leva carga de vários municípios, então criamos uma checagem em ABAP, antes do envio, que compara as duas posições iniciais do código do local com a UF. E aí, aqui na casa, quando todos os dados originários das notas vêm de um único estado, a checagem prévia basta; quando misturam estados, deixamos a SEFAZ conferir e só tratamos o retorno no log.

Se o código informado não casar com a UF, o texto devolvido fala de município diferente da UF; se o código simplesmente não existir na tabela, a mensagem é outra. Diego Rodrigues, dito isso, a leitura da mensagem já diz qual dos dois casos você tem. No CT-e e no MDF-e, vale gravar o texto devolvido no log do envio para o suporte comparar depois.

Resultado até agora: o MDF-e continua sem passar. Diego Pinto, tirando a prova, né, no nosso cadastro o código do local sai de uma tabela interna. Como diferenciar o código que não identifica a UF informada de um código inexistente na tabela oficial? O texto da recusa muda?

Hipótese rápida, Gustavo: código do local. Meu ponto, né: os dois dígitos à esquerda do código do local de saída indicam a UF, e a SEFAZ confere se casam com a sigla da UF do MDF-e. Se a rota que volta recusada tem origem em estado diferente do cadastrado, vale checar isso. Não conheço exceção para essa regra.

Roberto, bem, conforme o combinado, queria uma resposta específica: no S/4HANA 1909, o MDF-e de uma rota específica volta recusado e os das outras, não. Você separou o que acontece com envio de teste do que vem da produção; esse corte serve para as regras específicas do MDF-e também, ou só para a de tipo? Já tentei reenviar o mesmo arquivo e a recusa se repete.

Concordo em parte, Ivone: qualquer falha de segurança digital derruba o envio, mas aqui o caso é outro. E aí, sem pressa, quando a SEFAZ diz que o tipo enviado diverge do tipo do recebedor, ela está olhando a configuração do MDF-e. Eu separaria dois tipos de problema: o que ocorre com documentos de teste e o que ocorre em produção, e anotaria o retorno de cada envio para o time fiscal comparar.

Dúvida curta, Matheus: o truque é, viu, saber se o certificado também entra nisso. Aqui no S/4HANA 2023 o certificado já foi trocado, e o conteúdo do XML segue o layout. A recusa continua. Isso ainda é o mesmo caso que você descreveu ou é outro?

Na minha rotina com ECC 6.0 vi isso mais de uma vez. Sim, existe uma regra que compara se o MDF-e foi montado para produção ou homologação com o endereço que o recebeu, e ela recusa quando não bate. Diga-se de passagem, essa regra está logo no começo da lista de regras gerais, então vale conferir antes de mexer em assinatura ou no local de carregamento.