MDFe - XMotivo=Rejeição: Assinatura difere do calculado

[AlexSilva]

Bom dia !

Trabalhávamos com a versão 1.1.0.55 AcbrMonitorPLUS para emissão de MDFe, com esta versão a geração e envio do XML esta funcionando sem problemas. Atualizamos para a versão 1.2.0.11 AcbrMonitorPLUS a partir da atualização notamos algumas diferenças:

1 - Na obtençao do status aparentemente houve alguma alteracao na ordem e quantidade dos campos:

versão 1.2.0.11
===============
[Status]
CStat=107
CUF=31
DhRecbto=04/09/2018 09:47:29
DhRetorno=30/12/1899
Msg=Servico em Operacao
TMed=1
TpAmb=2
VerAplic=RS20170524132035
Versao=3.00
XMotivo=Servico em Operacao
XObs=

versão 1.1.0.55
================
MDFE.StatusServico
OK: Servico em Operacao
[STATUS]
Versao=RS20170524132035
TpAmb=2
VerAplic=RS20170524132035
CStat=107
XMotivo=Servico em Operacao
CUF=31
DhRecbto=04/09/2018 09:46:28
TMed=1
DhRetorno=30/12/1899
XObs=

2 - No envio do XML está voltando uma Rejeição: XMotivo=Rejeição: Assinatura difere do calculado

Procurando por topicos em relação à esta rejeição, encontrei muita coisa referente a espaços e caracteres especiais no xml, contudo... no xml não tem nenhum dos dois casos.... Segue em anexo o xml gerado:

 

31180965235434000116580010000000691000000697-mdfe.xml

[José M. S. Junior]

Bom dia @AlexSilva 

Primeiramente utilize a ultima versão do ACBrMonitor 1.2.0.16 para testes...

A questão da ordem dos campos não interfere na leitura de um arquivo .INI, visto que o nome dos campos e dos grupos continuam os mesmos... Isso ocorre pois foi realizado um refactory nos fontes do ACBrMonitor e o Retorno agora é gerado de forma automatizada...

A rejeição da SEFAZ de Assinatura difere do Calculado, ocorre quando é realizado alguma modificação no XML após a assinatura do mesmo... Você está gerando o XML pelo ACBrMonitor mesmo? verifique se na rotina da sua aplicação não está modificando o XML depois de assinado...

 

 

 

[AlexSilva]

Boa tarde St José M. S. Junior !

Conferimos o código e ao existe nenhuma manipulação no conteúdo do XML entre geração e envio.
A única manipulação que fazemos é com o arquivo xml gerado, onde ele é gerado em uma pasta Ent_Sai e é copiado para uma outra pasta MDFE para para posterior envio.
Esta troca de pasta pode estar gerando a rejeição?

Uma observação: Se envio o XML  pelo Monitor (sem passar pelo nosso sistema)  ele não volta rejeição e é aprovado.

Obs2: Na versao que usavamos antes (1.1.0.55) continua funcionando sem problemas. Ou seja, parece que é devido a alguma alteracao feita no codigo do Monitor. O problema é que náo tenho ideia do que pode ser. Em nossa empresa náo trabalhamos com Pascal entáo complica mais ainda pra nós.

Grato de antemao por qualquer ajuda!

 

Editado 4 Setembro, 2018 por AlexSilva
Completar mais a pergunta

[José M. S. Junior]

Provavelmente está ocorrendo alguma alteração no XML no momento da manipulação... Pode ser um simples "Space" ou a codificação do arquivo em formato diferente no momento que realiza a cópia... Por que não utiliza o próprio XML já gerado e assinado para enviar? O mesmo é gerado com o numero da Chave do MDFe, na pasta Logs do Monitor. Ou envie o XML pelo próprio ACBrMonitor e recupere o XML já autorizado para gravar na base de dados ou extrair informações necessárias...

Como você mesmo mencionou, se não manipular o arquivo e enviar pelo Monitor não tem problemas...

[AlexSilva]

Caro José, Junior, antes de mais nada, obrigado pela atenção.

Vamos lá... testei fazer um envio direto do arquivo gerado pelo monitor: deu a mesma rejeição.

Se por um lado, como você apontou, enviando pelo monitor da certo, por outro eu uso o monitor fazem 9 anos com a mesma forma de trabalhar, e nunca deu esse tipo de problema antes - passou a acontecer à partir das versões que tem o refactoring de vocês. Inclusive, como apontei, se uso a versão anterior, volta a funcionar perfeitamente.

Se eu tivesse facilidade de investigar o código fonte seria fácil de encontrar qual modificação está gerando o problema - mas como apontei, não sou hábil com Pascal.
Portanto, como vocês desenvolvedores principais lidam com esse código diáriamente, acredito que vocês teriam uma perpectiva muito mais propícia para me passar uma 'pista' do que pode estar acontecendo, Do lado do meu sistema, ja testei e procurei tudo possivel - inclusive codificação ao abrir e salvar arquivos - e tudo parece consistente.
Neste exato momento, o fato é que atualizei o monitor e o que estava funcionando parou de funcionar - e pior que não tenho nenhuma idéia do motivo dessa diferença de funcionamento - afinal, se houvesse manipulação no meio dos processos não deveria tambem dar problema na versão antiga?

Continuo dependendo da boa vontade e ajuda de vcs, boa turma do ACbr!!

Muito obrigado por qualquer auxílio!

 

[José M. S. Junior]

As dicas acima é para facilitar o trabalho... Mas se funciona na versão anterior e não está fazendo nada diferente, deve funcionar na atual também... 

Primeiramente anexe para análise o seu arquivo de resposta, onde obtem o XML Gerado e Assinado pelo ACBrMonitor....

[AlexSilva]

Boa tarde José M. S. Junior !

Segue em anexo os XML com a versão: 1.2.0.16

1 - 31180965235434000116580010000000761000000764-mdfe(gerado_pasta_log).xml

2 - 31180965235434000116580010000000761000000764-mdfe(movido da pasta log para pasta MDFe.xml
Retorno após envio pelo nosso sistema: 297-Rejeição: Assinatura difere do calculado
- Obs: foi  feito tentativa de envio pelo sistema usando a pasta Log - voltou a rejeição. Fizemos também da pasta onde normalmente enviamos - tb voltou rejeição.

3 - XML recebido após envio pelo Monitor: 31180965235434000116580010000000761000000764-mdfe(Enviado pelo monitor - Aprovado).xml
- obs: ao testar envio pelo monitor, foi indicado o mesmo arquivo da pasta MDFe que é rejeitado ao ser enviado pelo sistema -
31180965235434000116580010000000761000000764-mdfe(movido da pasta log para pasta MDFe).xml
- obs2: em ambos os casos foi conferido se era feita alguma nova assinatura, mas não é feita nenhuma nova geracao/assinatura - apenas abrimos o arquivo para leitura como textstream com a mesma codificacao em que foi gerado e procedemos com ocomando de envio.

31180965235434000116580010000000761000000764-mdfe(gerado_pasta_log).xml

31180965235434000116580010000000761000000764-mdfe(movido da pasta log para pasta MDFe.xml

31180965235434000116580010000000761000000764-mdfe(Enviado pelo monitor - Aprovado).xml

Editado 4 Setembro, 2018 por AlexSilva

[AlexSilva]

Boa tarde José M. S. Junior !

Afim de fornecer mais informações para um comparativo entre as versoes. Segue os exemplos de XML gerados com a versão 1.1.0.55

1 - 31180965235434000116580010000000771000000770-mdfe(gerado_pasta_Log).xml

2 - 31180965235434000116580010000000771000000770-mdfe(copiado_pasta_Log_para_pasta_MDFe).xml
- com esta versão 1.1.0.55 foi aprovado fazendo o envio pelo nosso sistema.

3 - 31180965235434000116580010000000771000000770-mdfe(Aprovado_Enviado_pelo_Sistema).xml

 

Att,

 

 

31180965235434000116580010000000771000000770-mdfe(gerado_pasta_Log).xml

31180965235434000116580010000000771000000770-mdfe(copiado_pasta_Log_para_pasta_MDFe).xml

31180965235434000116580010000000771000000770-mdfe(Aprovado_Enviado_pelo_Sistema).xml

[José M. S. Junior]

Bom dia @AlexSilva

Não há diferenças entre o XML gerado pelo ACBrMonitor e o XML movido para pasta da sua aplicação... Você pode verificar se o XML foi alterado após a assinatura, utilizando o validador SEFAZ: https://mdfe-portal.sefaz.rs.gov.br/site/ValidadorXml

Copie o xml para o validador e veja que o mesmo é valido... Alguma coisa está modificando o XML no lado da sua aplicação no momento do envio...

Para tirar a dúvida valide o XML que copiou, após o envio pela sua aplicação. Veja se o mesmo ainda estará válido...

[AlexSilva]

Bom dia José Junior!

Fizemos muitos testes aqui, segundo sua instrução.
Os arquivos da pasta LOG e da MDFe (copia) validam sem nenhum problema.

Quando enviamos e acontece a rejeição, não retorna nenhum arquivo que podemos usar para validar.

Conferi o codigo novamente, e não existe nenhuma manipulação, apenas é enviado o comando:  MDFE.ENVIARMDFE("caminho_do_xml",1)

Ou seja, deixamos por conta do AcbrMonitor.

Com o mesmo exato codigo, se rodar fazendo par com a versã0 1.1.0.55 do monitor, aprova sem problemas.
Já se rodar com o monitor versão 1.2.0.11 pra frente, da problema.

Outro exemplo, agora com NFe:

Se rodo nosso sistema com o monitor versão 1.1.0.55 - aprova
Se rodo nosso sistema com o monitor versão 1.2.0.11 - aprova
Se rodo nosso sistema com o monitor versão 1.2.0.16 - não aprova

no citado acima é sempre o mesmo exe do nosso aplicativo, a unica variável é o monitor. Ou seja, tudo leva a crer que alguma alteração do monitor está resultando na 'incompatibilidade'.
Apenas preciso saber qual foi essa alteração para poder adequar nosso sistema de acordo.

Presumo que até a versao 1.2.0.11, tinha sido feito o refactoring da MDFe mas não da NFe.
Na ultima versão, já foram feitos para ambos, e ambos geram problema para aprovar nossos envios.

Agradeço qualquer ajuda possivel sua ou de outros colegas do forum.

Muito obrigado!

 

[José M. S. Junior]

@AlexSilva, eu havia entendido que você estava utilizando a sua aplicação para envio do MDFe, se você está utilizando o método MDFE.ENVIARMDFE("caminho_do_xml",1) e informar o caminho do XML exatamente onde é gerado pelo ACBrMonitor, mesmo assim apresenta a rejeição? Por favor, para melhor entendimento anexe o log.txt do ACBrMonitor e o XML gerado na pasta configurada no ACBrMonitor... 

[AlexSilva]

Bom dia José Junior!

Segue os arquivos solicitados:

Versão usada 1.2.0.16

1 - LOG.TXT

2 - 31180965235434000116580010000000791000000790-mdfe(Pasta_log).xml

Apenas para maiores esclarecimentos:
-  Quando dizemos enviar pelo sistema - MDFE.ENVIARMDFE("caminho_do_xml",1) estamos querendo dizer que usamos o sistema pra mandar o comando pro monitor- NÃO APROVA.

- E quando dizemos enviar direto pelo monitor, é usando o monitor em testes (enviar XML MDFe) e apontando o arquivo xml  - APROVA. 

- Como dito em posts anteriores: com a  versão 1.1.0.55 foi aprovado fazendo o envio pelo nosso sistema - SEM PROBLEMAS

LOG.TXT

31180965235434000116580010000000791000000790-mdfe(Pasta_log).xml

[José M. S. Junior]

@AlexSilva, este log está incompleto... Não consta o comando de envio nem o retorno com a rejeição...

Por favor realize o processo completo de envio com o log ativado, anexe o log completo para compreendermos o problema, visto que o XML gerado é valido no site: https://mdfe-portal.sefaz.rs.gov.br/site/validadorxml

[AlexSilva]

Boa tarde José Junior!

Segue em anexo o log completo:
Geração, Envio e retorno.

 

Att,

LOG.TXTLOG.TXT

[José M. S. Junior]

Realmente estranho essa rejeição... nos testes realizados aqui, alterando apenas o emitente mas utilizando os mesmos métodos, é autorizado sem problemas...

Experimente passar o método de envio sem o parâmetro para assinar o XML ex:

MDFE.EnviarMDFE( "C:\Program Files\VSEmissFiscal_Sys\vsnfe\entr_sai\MDFe\31180965235434000116580010000000791000000790-mdfe.xml","79")

[AlexSilva]

Boa noite José Junior!

Acabei de fazer o teste forçando 0 no argumento da assinatura. Nada feito: continua o mesmo erro.
Acabei não testando omitir o argumento, mas pela lógica (e pelas instrucoes dos Helps) passar 0 ali no argumento seria ate mais indicado.

De qualquer forma, ainda testarei por via das dúvidas.

Segue anexo o log completo.

Muito obrigado pela atenção e paciência. Contamos com sua ajuda porque a semana toda dando erro, estamos apertados com os clientes no nosso pé (e com razão).

Bom feriado e fim de semana!

 

Log do teste forcando argumento 0 (assinatura).txt

[AlexSilva]

adendo ao post anterior:

só por via das dúvidas acabei de testar sem passar argumento nenhum de assinatura, e não alterou nada. Persiste a mesma rejeicao.

Segue o log em anexo.

log - teste sem argumento de assinatura.txt

[José M. S. Junior]

@AlexSilva conforme relatado acima não estamos conseguindo simular esse problema, nos testes autoriza o MDFe sem problemas. 

Experimente realizar um teste utilizando apenas o método MDFe.CriarEnviarMDFe(.ini), pode ser a solução se o arquivo estiver sendo alterado em algum momento despercebido...

Se possível anexe o log das duas versões para comparação... A atual e a que está enviando.

[José M. S. Junior]

Outro erro pode estar ocorrendo no seu arquivo de geração em relação ao campo RNTRC, na versão 3.0 este campo não deve ser informado no grupo [Rodo], informe apenas em [infANTT]...

Se não existir RNTRC remova o grupo do arquivo... ficando da seguinte forma:

[Rodo]

[veicTracao]
placa = OMB9653

...

[AlexSilva]

Boa tarde José Junior!

Segue os arquivos solicitados:

1 - LOG-Aprovado.TXT  - com o método = MDFe.CriarEnviarMDFe(.ini)   -   Com este método foi Aprovado.

2 - LOG-Não_Aprovado.TXT - Feito como sempre foi feito pelo nosso sistema. Usando separadamente:  Gerar, validar e Assinar e depois Enviar.
10/09/2018 12:34:33 - OK: C:\Program Files\VSEmissFiscal_Sys\vsnfe\entr_sai\31180965235434000116580010000000801000000805-mdfe.xml
10/09/2018 12:34:40 - MDFE.ImprimirDAMDFE( "C:\Program Files\VSEmissFiscal_Sys\vsnfe\entr_sai\NFe\31180965235434000116580010000000801000000805-mdfe.xml" , , , ,1)
10/09/2018 12:34:43 - OK: DAMDFe Impresso com sucesso
10/09/2018 12:34:49 - MDFE.EnviarMDFE( "C:\Program Files\VSEmissFiscal_Sys\vsnfe\entr_sai\MDFe\31180965235434000116580010000000801000000805-mdfe.xml",80, 1 )

 

LOG-Aprovado.TXT

LOG-Não_Aprovado.TXT

[AlexSilva]

Em complemento ao post anterior, gostaria de apontar o seguinte:

a) Como aprova com versões anteriores, certamente teve aguma alteracao no monitor
b) como você mesmo comprovou, não existe manipulação do arquivo da nossa parte (eles são identicos)
c) Embora o método 'CriarEnviar' tenha funcionado e pode ser usado, nunca antes usamos o metodo  MDFe.CriarEnviarMDFe (mesma coisa com NFe) pois os clientes mostraram preferir mais controle nos estágios.
Portanto gostaríamos de resolver o problema usando os métodos separados para evitar impacto na forma como os clientes interagem com nosso sistema, até porque muitas funcionalidades ficariam perdidas caso fossemos obrigados a abandonar esses métodos.
d) Agradecemos sua indicação referente ao campo RNTRC , e vamos acertar de acordo, mas certamente não é isso que está implicando problema, visto que aprova tanto na versão anterior, quanto usando o 'CriarEnviar'.

Agradecemos e contamos com sua ajuda para resolver esse problema.

Editado 10 Setembro, 2018 por AlexSilva

[José M. S. Junior]

Vou verificar uma possível correção na geração do XML na questão do campo RNTRC... Aparentemente este campo está causando o erro ao utilizar o Método CriarMDFe... Note que esta tag no seu XML não é iniciada <RNTRC>...

Como dito, será avaliado uma correção na leitura deste campo, mas para que funcione da forma que está,  remova este campo caso não seja informado... Se possível, realize este teste com o método CriarMDFe.

[AlexSilva]

Prezado José Junior, vou fazer como indicado. Irei realizar a correção deste campo e procederei com os testes.
Todavia gostaria de apontar que estamos testando com o MDFe para simplificar, porém a mesma rejeição acontece com a NFe. Imagino que uma vez descoberto o problema o que passou a gerar rejeição no MDFe, a correção será similar para NFe.

Lembrando:

com NFe:

Se rodo nosso sistema com o monitor versão 1.1.0.55 - aprova
Se rodo nosso sistema com o monitor versão 1.2.0.11 - aprova
Se rodo nosso sistema com o monitor versão 1.2.0.16 - não aprova

Grato mais uma vez.

[AlexSilva]

Feita a correcao do campo indicado, e novo teste.

Segue a mesma rejeicao - log anexado abaixo

LOG - correcao RNTRC - Rejeicao.txt

Editado 10 Setembro, 2018 por AlexSilva

[José M. S. Junior]

O problema está no campo RNTRC... deve ser numérico.

Se não for informado o número RNTRC retire esse grupo do arquivo ou deixe em branco...

Remova esses campos do arquivo:

[infANTT]
RNTRC = NA