Problema ao averbar MDF-e após começar a gerar a TAG qrCodMDFe

[nickolasdeluca]

Boa tarde pessoal,

Seguindo as orientações, atualizamos a suite do ACBr e configuramos a propriedade GerarInfMDFeSupl como fgtSempre, isso resolveu o problema da obrigatoriedade do QRCode.

Porém, ao averbar o manifesto com o pessoal da ATM começou a dar erro. Entramos em contato com o pessoal do suporte deles e nos foi comunicado que o problema era a tag:

<qrCodMDFe><![CDATA[https://dfe-portal.svrs.rs.gov.br/mdfe/qrCode?chMDFe=42190704910644000178580010000072001000919014&tpAmb=1]]></qrCodMDFe>

Segundo o pessoal do suporte deles, o link não deveria estar entre a TAG ![CDATA] e é isso que está causando o problema, removemos então a tag manualmente do XML e tentamos fazer o envio da averbação, funcionou perfeitamente.

Após a modificação do XML:

<qrCodMDFe><https://dfe-portal.svrs.rs.gov.br/mdfe/qrCode?chMDFe=42190704910644000178580010000072001000919014&tpAmb=1></qrCodMDFe>

A minha duvida é, a solução do problema é por parte de vocês ou eu devo insistir que o problema é da ATM e que eles que tem que solucionar essa questão?

Estou anexando os arquivos de request e response da comunicação com o servidor deles, talvez ajude a em algo.

Response Request

Editado 19 Julho, 2019 por nickolas.deluca
tag errada

[BigWings]

1 hora atrás, nickolas.deluca disse:

A minha duvida é, a solução do problema é por parte de vocês ou eu devo insistir que o problema é da ATM e que eles que tem que solucionar essa questão?

Certamente é problema na ATM.

Eles não podem recusar nem pedir pra alterar um XML autorizado.

[Italo Giurizzato Junior]

Boa tarde Nickolas,

Faça o seguinte teste: Gere o XML do MDF-e sem o ![CDATA], assina, valida e envia para a SEFAZ.

Depois nos conta se a SEFAZ autorizou ou não o MDF-e.

[Ricardo Rohde]

fiz um mdfe de teste agora e autorizou sem erro com qrcode

[Italo Giurizzato Junior]

Boa tarde Ricardo,

Favor anexar o XML que foi gerado e autorizado pela SEFAZ.

[Ricardo Rohde]

segue

41190722917635000190580010000000251996386300-mdfe.xml

[Italo Giurizzato Junior]

Ricardo,

Acho que você não entendeu o problema no nosso amigo Nickolas.

No XML a tag <qrCodMDFe> o seu conteúdo esta entre: <![CDATA[   ....   ]]>

O motivo de ter o CDATA é por causa do caractere "&" que aparece antes do campo tpAmb.

O CDATA tem a função de indicar que o texto dentro dele é um texto comum e não pode ser interpretado como parte da marcação do XML.

E ao enviar o XML do MDF-e para a seguradora fazer a averbação o recusa.

Para removermos o CDATA do XML do MDF-e a SEFAZ teria que trocar o caractere "&" por "|" como fez na NF-e.

Enquanto isso não ocorre, a seguradora vai ter que ajustar o seu sistema para aceitar o XML do MDF-e com o CDATA.

[nickolasdeluca]

1 hora atrás, Italo Jurisato Junior disse:

Boa tarde Nickolas,

Faça o seguinte teste: Gere o XML do MDF-e sem o ![CDATA], assina, valida e envia para a SEFAZ.

Depois nos conta se a SEFAZ autorizou ou não o MDF-e.

Farei este teste segunda feira, ai volto aqui a posto o resultado, até!

[nickolasdeluca]

Em 19/07/2019 at 18:03, nickolas.deluca disse:

Farei este teste segunda feira, ai volto aqui a posto o resultado, até!

Bom dia, após fazer o teste de envio sem a tag ![CDATA] verificamos que realmente deu problema na validação dos dados do XML.

Utilizei o link da propria SEFAZ do RS e da erro na validação dos dados da linha 99, que é justamente a tag do qrCodMDFe, voltamos a aplicar a TAG CDATA e funciona perfeitamente.

Vamos continuar o contato com o pessoal da ATM, se obtivermos retorno volto a postar aqui.

Valeu pessoal!

[Italo Giurizzato Junior]

Bom dia Nickolas,

Tanto o MDF-e quanto o CT-e (a partir de hoje em homologação e 26/08/2019 em produção) devemos informar a string do QR-Code na tag qrCodMDFe (para o MDF-e) e qrCodCTe (para o CT-e).

Nessa string temos o caractere "&", sendo assim se faz necessário o uso do CDATA, para que a validação do XML ocorra sem nenhum problema.

A remoção do CDATA do XML apesar de não tornar o XML invalido, uma vez que este é assinado antes da inclusão da tag qrCodMDFe / qrCodCTe, não faz sentido.

A ATM por sua vez tem que fazer os ajustes necessários para que o XML do CT-e ou MDF-e sejam aceitos conforme o manual, ou seja, com o CDATA.

[Gr@c@]

A averbação do CT-e pela AT&M está sendo feita sem problemas com o CDATA. Não uso a declaração de MDF-e.

[nickolasdeluca]

21 minutos atrás, Gr@c@ disse:

A averbação do CT-e pela AT&M está sendo feita sem problemas com o CDATA. Não uso a declaração de MDF-e.

Ótima notícia, porém agora fiquei mais confuso ainda sobre o por que o MDFe não declara com a TAG e o CTe averba normalmente...

Talvez a ATM já esteja providenciando as devidas alterações?

Estamos aguardando a resposta deles, em contato por telefone eles já afirmaram que a nossa solicitação não foi a única...

Qualquer coisa, volto a postar aqui.

[Italo Giurizzato Junior]

Boa tarde Nickolas,

Esta ocorrendo uma confusão.

Ao enviar o XML do CT-e para ser averbado este deve ser colocando dentro do CDATA, a averbação ocorreu com sucesso, pois o CT-e só a partir de 26/08/2019 será obrigado a ter em seu XML a string do QR-Code em ambiente de Produção.

Para quem deseja testar em homologação a data prevista é hoje.

Implantada versão 3.00a e Comprovante de Entrega em HMLE na SVRS

 

Foi implantada em homologação na SVRS a versão 3.00a do CT-e e CT-e OS na data de hoje (22/07).

A versão contempla alterações nas regras de validação de chave de acesso relacionadas, introdução do QR Code no schema XML e a criação dos eventos de comprovante de entrega e cancelamento do comprovante de entrega do CT-e.

[nickolasdeluca]

57 minutos atrás, Italo Jurisato Junior disse:

Boa tarde Nickolas,

Esta ocorrendo uma confusão.

Ao enviar o XML do CT-e para ser averbado este deve ser colocando dentro do CDATA, a averbação ocorreu com sucesso, pois o CT-e só a partir de 26/08/2019 será obrigado a ter em seu XML a string do QR-Code em ambiente de Produção.

Para quem deseja testar em homologação a data prevista é hoje.

Implantada versão 3.00a e Comprovante de Entrega em HMLE na SVRS

 

Foi implantada em homologação na SVRS a versão 3.00a do CT-e e CT-e OS na data de hoje (22/07).

A versão contempla alterações nas regras de validação de chave de acesso relacionadas, introdução do QR Code no schema XML e a criação dos eventos de comprovante de entrega e cancelamento do comprovante de entrega do CT-e.

Agora faz sentido.

Por precaução, vou manter a geração do QR Code apenas em homologação até que a ATM nos dê uma solução.

[nickolasdeluca]

Citar

Prezados, Bom Dia!

Gostaríamos apenas de informá-los sobre uma observação referente ao novo Layout do MDF-e 3.00a.

Verificamos que em alguns casos onde é emitido o MDF-e nesse novo Layout, na tag "<qrCodMDFe>" está sendo preenchida com o campo "<![CDATA[]]>" ao inserir o link do QR Code.

Acontece que o campo "CDATA" é utilizado no consumo Webservice via envelope SOAP para transformar o XML que será enviado em Texto, portanto ao inseri-la na estrutura uma segunda vez ocasionará recusa informando o erro "912 - Estrutura inválida para utilização nesse Webserver" ou "905 - Erro ao ler XML", uma vez que ao fechar a segunda tag CDATA o Webservice entenderá que o fim do XML/SOAP esta sendo ao encerramento da segunda CDATA, ignorando o restante da estrutura.

Para que não ocorra esse tipo de problema, orientamos a tratar a tag "CDATA" informada dentro da tag "<qrCodeMDFe>", removendo-a da estrutura antes de efetuar o consumo em nosso Webservice.

Boa tarde,

Apenas acrescentando a discussão, essa foi a resposta que o pessoal da ATM nos passou por email... respondemos o email e deixamos claro que não podemos fazer alteração em documento de XML já autorizado... até agora eles não nos responderam e pelo que eu entendi essa é a resposta final deles.

Alguém tem alguma sugestão de como devemos proceder?

[Italo Giurizzato Junior]

Boa tarde Nickolas,

A string do QR-Code presente agora no MDF-e e apartir de agosto no CT-e, é colocada dentro do CDATA por conta da existência do caractere "&" na string.

O grupo infMDFeSupl que contem o elemento qrCodMDFe que por sua vez tem o tal do CDATA é gerado e incluído no XML depois que o XML é assinado.

Resumindo:

1. O XML do MDF-e é gerado;

2. Depois ele é assinado;

3. Por fim recebe o grupo infMDFeSupl.

Sendo assim, se removermos esse grupo do XML antes de enviar para a AT&M não vamos tornar o XML invalido.

Por favor faça um teste com a seguinte Unit: 

ACBrANeDocumentos.pas

[nickolasdeluca]

Em 29/07/2019 at 15:11, Italo Jurisato Junior disse:

Boa tarde Nickolas,

A string do QR-Code presente agora no MDF-e e apartir de agosto no CT-e, é colocada dentro do CDATA por conta da existência do caractere "&" na string.

O grupo infMDFeSupl que contem o elemento qrCodMDFe que por sua vez tem o tal do CDATA é gerado e incluído no XML depois que o XML é assinado.

Resumindo:

1. O XML do MDF-e é gerado;

2. Depois ele é assinado;

3. Por fim recebe o grupo infMDFeSupl.

Sendo assim, se removermos esse grupo do XML antes de enviar para a AT&M não vamos tornar o XML invalido.

Por favor faça um teste com a seguinte Unit: 

ACBrANeDocumentos.pas 17 kB · 4 downloads

Boa tarde Italo, desculpa a demora pra responder.

Fiz os testes, Infelizmente ainda deu erro no envio.

Este foi o retorno do componente: 500 - Inativo ou Inoperante tente novamente.

Notei que alguns arquivos foram gerados pelo ACBr e decidi investiga-los.

O primeiro arquivo gerado foi o 20190730152717-ANe.xml e este arquivo realmente foi gerado sem o grupo do qrCodMDFe.

Notei que o ACBr gerou outro arquivo logo em seguida, 20190730152717-ped-ANe.xml e dentro deste arquivo ainda existe a tag qrCodMDFe.

Fiz então a simulação pelo SoapUI com os 2 arquivos, com o primeiro (20190730152717-ANe.xml) o webservice nos retorna o código de declaração, tudo certinho.

Já quando eu faço o envio do segundo arquivo (20190730152717-ped-ANe.xml) o webservice retorna esse erro: 

<faultstring xsi:type="xsd:string">error in msg parsing: XML error parsing SOAP payload on line 8: Mismatched tag</faultstring>

Por que o ACBr gerou esse segundo arquivo? imagino que seja ele que o ACBr esteja enviando e por isso gera o erro...

Inclui os 2 arquivos gerados pelo componente, obviamente, alterei os dados de acesso na ATM, fora isso está exatamente como foi enviado e feito os testes.

Alguma ideia de como resolver essa situação?

[Italo Giurizzato Junior]

Boa tarde Nickolas,

Favor atualizar os fontes, reinstale a suíte ACBr e faça novos testes.

[nickolasdeluca]

15 horas atrás, Italo Jurisato Junior disse:

Boa tarde Nickolas,

Favor atualizar os fontes, reinstale a suíte ACBr e faça novos testes.

Apenas pra finalizar o assunto, funcionou perfeitamente Italo.

Muito obrigado!

[Juliana Tamizou]

Obrigado por reportar.

Fechando. Para novas dúvidas, criar um novo tópico.