Conciliação EPEC em ambiente Homologação (Sefaz MT) - “402 - Rejeicao : XML da area de dados com codificacao diferente de UTF-8.”

[Leandro Araújo]

Boa tarde.

Estou tentando conciliar um CT-e emitido via EPEC, no ambiente de Homologação da Sefaz MT, só que sempre está retornando a rejeição a seguir:
“402 - Rejeicao : XML da area de dados com codificacao diferente de UTF-8.”

Já verifiquei o XML, inclusive no Validador de Mensagens do Projeto CT-e, e não acusa erro.

- Ao tentar emitir um documento com os mesmos dados, mas forma de emissão 1 – Normal, é autorizado normalmente.
- Ao tentar emitir um evento EPEC, o mesmo é criado normalmente.
- Ao tentar conciliar o CT-e (com tpEmiss = 4) referente a EPEC anterior, sempre é retornada a rejeição 402.

Entrei em contato com o atendimento da Sefaz MT, mas não responderam mais.

Expliquei a situação, pedindo para verificarem também se poderia ser algo relacionado ao ambiente, conforme e-mail abaixo:

Citar

Em relação à rejeição 402, fiz um teste removendo o parâmetro sign da URL do QrCode, parou de dar a rejeição 402 e foi retornada a rejeição abaixo:
“853 - Rejeicao : ParAmetro sign nao informado no QR Code para emissao em contingencia”.

O que me leva a entender que possa ser algo ou no ambiente ou na geração do XML que está interpretando o valor nessa tag erroneamente,
quando presente o parâmetro sign, já que ele pode possuir caracteres como +/= conforme a tabela da Base64.

Mas claro, de acordo com o MOC 4.0 pág.: 84 do CT-e, para os documentos emitidos em contingência EPEC (tpEmiss = 4) o parâmetro sign deve estar presente na URL.

Se for possível verificar essa questão, se o ambiente não está aceitando os caracteres do sign presente na área de dados do QrCode.
Obrigado!

 

Analisei até o código-fonte (\Fontes\ACBrDFe\ACBrCTe\ACBrCTe.pas linha 338 em diante) e não percebi nada diferente:

// Passo 2 calcular o SHA-1 da string idCTe se o Tipo de Emissão for EPEC ou FSDA
  if TipoEmissao in [teDPEC, teFSDA] then
  begin
    // Tipo de Emissão em Contingência
    SSL.CarregarCertificadoSeNecessario;
    sign := SSL.CalcHash(idCTe, dgstSHA1, outBase64, True);
    Passo2 := '&sign=' + sign;

    sEntrada := sEntrada + Passo2;
  end;

  Result := urlUF + sEntrada;

 

Em anexo XMLs:

CT-e com emissão Normal: 51240706137422000190570010000000311680036048-cte-normal.xml

Evento EPEC: 11011351240706137422000190570010000000254289813233001-procEventoCTe.xml

CT-e com tipo de emissão EPEC: 51240706137422000190570010000000254289813233-cte-epec.xml

Envio do lote: 25-env-lot.xml e 25-env-lot-decodado.xml

Rejeição retornada: 25-pro-lot.xml

Caso alguém tenha passado por essa situação e possa contribuir com algo, fico grato,
mas acredito não ter algo a ver com o ACBr, já que utilizamos a emissão e conciliação de EPEC normalmente em ambiente de Produção, pelo menos até o momento.