Evento de prestação de serviço em desacordo - Rejeição 297: Assinatura difere do calculado

[nolher]

Boa tarde|!

Gostaria de saber se alguém já realizou teste do novo Evento Prestação do Serviço em Desacordo?

E se sim, se tiverem a Rejeição 297:   Assinatura difere do calculado?

Estamos realizando o teste aqui e não consegui entender o motivo desta rejeição,  estamos utilizando o componente ACBrCTe para o envio desde evento.

Seque em anexos os xml que envolve o Evento:

Xml gerado da NF-e no mesmo período: 333170000426982_v03.10-procNFe.xml

Xml gerado do CT-e no mesmo período: 131170001241261_v03.00-procCTe.xml

Xml gerado do Evento Prestação do Serviço em Desacordo: 1-ped-eve.xml1-ped-eve.xml 

Xml de resposta do Webservice: 1-eve.xml

 

Se puderem oferecer alguma dica lhes agradeço.

 

Aproveito a oportunidade para agradecer os apoio que sempre  recebi aqui desde grande grupo, e também para parabenizar  o excelentes trabalho de toda equipe envolvida no projeto.

 

Sem para o momento, 

 

Antecipo agradecimentos,

[Italo Giurizzato Junior]

Bom dia Nilton,

O vento de Prestação de Serviço em Desacordo é um evento emitido pelo tomador e não pelo emitente do CT-e.

O campo observação tem que ter no minimo 15 caracteres.

E o seu evento com relação do ator e o campo observação esta correto, no meu entendimento o problema é na SEFAZ, ou tem alguma coisa haver com as vogais acentuadas na descrição do tipo de evento.

[nolher]

Bom dia, Italo!

Bom, temos o entendimento que o  evento de Prestação de Serviço em Desacordo é um evento emitido pelo tomador e vamos disponibilizar para nossos clientes de NF-e.

Estamos implementando na versão 3.00 do CT-e já que é um serviço dos webservices de CT-e! 

Verifiquei que depois que transferi para a versão 3.00 a carta de correção também está me retornando a mesma rejeição.

Gerei o seguinte CT-e 131170001241328_v03.00-procCTe.xml

Enviei a seguinte carta de correção: 372-ped-eve.xml

E tive a seguinte resposta: 372-eve.xml

A proposito o envio de evento de cancelamento esta normal.

Se poderem me oferecer alguma dica ficarei muito grato.

Desde já antecipo agradecimento,

Atenciosamente, 

 

 

 

 

Editado 13 Outubro, 2017 por nolher

[Italo Giurizzato Junior]

Boa tarde Nilton,

A rotina que assina um evento é exatamente a mesma para todos os eventos.

Alias a rotina que assina é a mesma que assina a NF-e, Eventos da NF-e, CT-e, Eventos do CT-e, MDF-e, Eventos do MDF-e, entre outros.

Sendo assim concluo que o problema é na SEFAZ.

[nolher]

Bom dia, Italo! E bom dia a todos!

Obrigado Italo pela atenção, enviei a dúvida para os Sefaz de Minas e de São Paulo, e estou aguardando um posicionamento.

Vou deixar o tópico aberto e qualquer novidade posto aqui.

 

Mais uma vez muito obrigado pela atenção,

 

Atenciosamente,

[Gilvano Piontkoski]

Boa tarde,

Também estou com problema no evento de prestação de serviço em desacordo, porém a rejeição é a "Assinatura difere do padrao do Projeto Status: 298".

Segue em anexo os arquivos gerados.

11317-ped-eve.xml

11317-ped-eve-soap.xml

[Italo Giurizzato Junior]

Boa noite Gilvano,

A assinatura realizada no evento segue o mesmo padrão utilizado na assinatura do CT-e.

Com certeza é algum erro na SEFAZ.

[luisclaudio_jr]

Aqui da esse problema por causa de qualquer letra acentuada, ex: ç,á,ê... recomendo ver se pode ser isso

[Gilvano Piontkoski]

 

11 horas atrás, luisclaudio_jr disse:

Aqui da esse problema por causa de qualquer letra acentuada, ex: ç,á,ê... recomendo ver se pode ser isso

Realmente o problema é a acentuação na descrição do evento. 

 

15 horas atrás, Italo Jurisato Junior disse:

Boa noite Gilvano,

A assinatura realizada no evento segue o mesmo padrão utilizado na assinatura do CT-e.

Com certeza é algum erro na SEFAZ.

Realmente segue o mesmo padrão, mas nos outros eventos não existe acento na descrição do evento, acabei de fazer um ajuste aqui e o evento foi aceito, simplesmente fiz o seguinte:

FPDadosMsg := StringReplace(FPDadosMsg, 'Prestação do Serviço em Desacordo', 'Prestação do Serviço em Desacordo', []);

Segue o patch da alteração, sei que essa não é a solução definitiva, somente resolveu essa situação especifica. 

evento-desacordo.patch

[Juliomar Marchetti]

8 horas atrás, Gilvano Piontkoski disse:

 

Realmente o problema é a acentuação na descrição do evento. 

 

Realmente segue o mesmo padrão, mas nos outros eventos não existe acento na descrição do evento, acabei de fazer um ajuste aqui e o evento foi aceito, simplesmente fiz o seguinte:

FPDadosMsg := StringReplace(FPDadosMsg, 'Prestação do Serviço em Desacordo', 'Prestação do Serviço em Desacordo', []);

Segue o patch da alteração, sei que essa não é a solução definitiva, somente resolveu essa situação especifica. 

evento-desacordo.patch

Anexe a unit toda.

[Gilvano Piontkoski]

13 horas atrás, Juliomar Marchetti disse:

Anexe a unit toda.

Anexada.

ACBrCTeWebServices.pas

[Italo Giurizzato Junior]

Bom dia a todos,

Estranho as vogais acentuadas ficarem bagunçadas, será que o método AssinarXML esta realizando essa bagunça?

É preciso debugar para descobrir onde esta a origem do problema.

Gilvano, você teria condições de realizar esse debug?

O método AssinarXML recebe o XML a ser assinado através da variável Evento.

E nos retorna o mesmo XML assinado na variável FPDadosMsg.

Se a variável Evento contem a descrição do evento correto e no FPDadosMsg esta bagunçado então o problema é o método AssinarXML, ai é preciso descobrir em que momento ocorre o problema.

[Gilvano Piontkoski]

8 minutos atrás, Italo Jurisato Junior disse:

Bom dia a todos,

Estranho as vogais acentuadas ficarem bagunçadas, será que o método AssinarXML esta realizando essa bagunça?

É preciso debugar para descobrir onde esta a origem do problema.

Gilvano, você teria condições de realizar esse debug?

O método AssinarXML recebe o XML a ser assinado através da variável Evento.

E nos retorna o mesmo XML assinado na variável FPDadosMsg.

Se a variável Evento contem a descrição do evento correto e no FPDadosMsg esta bagunçado então o problema é o método AssinarXML, ai é preciso descobrir em que momento ocorre o problema.

A " bagunça" acontece nessa linha:

Eventos := NativeStringToUTF8( EventoCTe.Gerador.ArquivoFormatoXML );

EventoCTe.Gerador.ArquivoFormatoXML: aqui retorna o xml com a seguinte string "Prestação do Serviço em Desacordo" 

ao passar pelo NativeStringToUTF8 que gera a "bagunça": "Prestação do Serviço em Desacordo"

porém o xml é assinado corretamente, e com o StringReplace o evento é aceito pela receita, tentei fazer esse replace em outros pontos mas sempre dava algum erro, ou o 298 ou outro sobre o enum das descrições dos eventos.

[nolher]

Bom dia!

A título de informação a solução Gilvano solucionou o problema aqui.

Aguardo novas informações se houver soluções específica de nossos Moderadores.

 

Sem mais para o momento, 

 

atenciosamente, 

[Daniel Simoes]

Como reproduzir o problema, no Demo do ACBr ?

[Italo Giurizzato Junior]

Boa tarde Daniel,

Segundo o Gilvano ao executar a linha:

Eventos := NativeStringToUTF8( EventoCTe.Gerador.ArquivoFormatoXML );

As vogais acentuadas e o cedilha são trocados.

[Daniel Simoes]

parece ser um problema em "pcteEventoCTe.pas"

todos os fontes do ACBr, são em ANSI... (CP1252)... então... todo e qualquer String que contiver acentos, deve ser "tratada" com ACBrStr()

Por favor tentem substituir a Unit em anexo...

 

pcteEventoCTe.pas

[Gilvano Piontkoski]

48 minutos atrás, Daniel Simoes disse:

parece ser um problema em "pcteEventoCTe.pas"

todos os fontes do ACBr, são em ANSI... (CP1252)... então... todo e qualquer String que contiver acentos, deve ser "tratada" com ACBrStr()

Por favor tentem substituir a Unit em anexo...

 

pcteEventoCTe.pas

Boa tarde,

testei aqui e continua trocando os caracteres ao passar pelo NativeStringToUTF8, só para constar utilizo o Delphi XE7.

Editado 9 Novembro, 2017 por Gilvano Piontkoski

[Daniel Simoes]

Notei que outras Units estavam erradas, o método ACBrStr() estava sendo invocado duas vezes para a mesma String

Enviei uma possível correção ao SVN... antes de testar, certifique-se de que todas as Units foram corretamente atualizadas... (renomeie as Units em que você fez mudanças locais)

[rafaeldalbosco]

@Daniel Simoes testei sua alteração e não obtive sucesso, somente com a alteração do @Gilvano Piontkoski funcionou.

[Daniel Simoes]

Se deseja sugerir modificações aos fontes, favor anexar as Units modificadas, para analise..