Erro arquivo XML consulta DFe MG (NFCe cancelada)

[charles.libano]

Boa tarde a todos.

Estou com um erro que vou tentar explicar abaixo:

Emito uma NFCe normalmente.

Se eu cancelo esta NFCe, para pegar o arquivo dela com o protocolo de cancelamento anexado, utilizo a função ACBrNFe.Consultar

Funciona perfeitamente para RJ.

Porém, para MG, o arquivo não abre como um XML válido.

Estou com os fontes do ACBr atualizados neste instante.

Seguem 2 respostas de consulta, uma correta do RJ e a outra inválida de MG.

Acontece tanto em homologação quanto em produção.

Alguém tem ideia de que erro é esse?

Obrigado

Charles

33191108900996000101650010000142791774105611-nfe-canc.xml 31191118991455000181650010000003251228813241-nfe-canc.xml

[BigWings]

1 hora atrás, charles.libano disse:

Alguém tem ideia de que erro é esse?

Se você tem a propriedade AtualizarXMLCancelado ativada, o ACBr vai alterar o XML da nota inserindo o protocolo de cancelamento.

O problema é que a SEFAZ-MG está retornando indevidamente prefixos ns0: para as tags do XML no retorno da consulta.

Isso faz com que o XML final montado pelo XML fique inválido.

[charles.libano]

16 horas atrás, BigWings disse:

Se você tem a propriedade AtualizarXMLCancelado ativada, o ACBr vai alterar o XML da nota inserindo o protocolo de cancelamento.

O problema é que a SEFAZ-MG está retornando indevidamente prefixos ns0: para as tags do XML no retorno da consulta.

Isso faz com que o XML final montado pelo XML fique inválido.

@BigWings

Usei o comando:

  ACBrNFE1.Configuracoes.Geral.AtualizarXMLCancelado := True;

Porém, não está sendo respeitado, não grava nada no xml final. Testei em RJ e MG.

Alguma sugestão?

Obrigado.

Charles

[BigWings]

5 minutos atrás, charles.libano disse:

  ACBrNFE1.Configuracoes.Geral.AtualizarXMLCancelado := True;

Porém, não está sendo respeitado, não grava nada no xml final. Testei em RJ e MG.

Não entendi. O XML que você anexou está modificado.

O correto na verdade é deixar essa propriedade como False, ela existe apenas por compatibilidade com versões antigas da NFe onde ainda não existia o cancelamento por eventos.

O correto é manter o XML original inalterado, apenas armazenar também o XML do evento de cancelamento.

[charles.libano]

3 minutos atrás, BigWings disse:

Não entendi. O XML que você anexou está modificado.

O correto na verdade é deixar essa propriedade como False, ela existe apenas por compatibilidade com versões antigas da NFe onde ainda não existia o cancelamento por eventos.

O correto é manter o XML original inalterado, apenas armazenar também o XML do evento de cancelamento.

@BigWings

O XML que anexei foi feito com a propriedade False, ou seja, mantinha o original e o do cancelamento.

Porém, quero o arquivo xml completo, ou seja, faço uma consulta ao DFe e ele me retorna a NFe autorizada, acrescida abaixo do protocolo do cancelamento. (Em MG isto não está funcionando)

Entendi que colocando a propriedade True, isto aconteceria automaticamente, ou seja, o ACBr pegaria a NFe original e colocaria abaixo dela o protocolo do cancelamento, ficando exatamente igual ao anexo que enviei do RJ.

Mas isso não aconteceu.

Como em MG tudo ainda é novo, os contadores se confundem com 2 xml, sendo um deles da NFe transmitida e outro do cancelamento da mesma. Não há como manter 2 arquivos por enquanto.

Alguma sugestão?

Obrigado.

Charles

[BigWings]

16 minutos atrás, charles.libano disse:

O XML que anexei foi feito com a propriedade False, ou seja, mantinha o original e o do cancelamento.

Porém, quero o arquivo xml completo, ou seja, faço uma consulta ao DFe e ele me retorna a NFe autorizada, acrescida abaixo do protocolo do cancelamento. (Em MG isto não está funcionando)

Analisando melhor, o XML que você anexou não é o XML da NFe e sim o XML NFeDFe que agrupa o XML da NFe e a lista de eventos do mesmo:

Ele é gerado com a extensão *-NFeDFe.xml. Você deve ter também um XML *-nfe.xml que é o XML da NFe com o protocolo de autorização apenas.

18 minutos atrás, charles.libano disse:

Entendi que colocando a propriedade True, isto aconteceria automaticamente, ou seja, o ACBr pegaria a NFe original e colocaria abaixo dela o protocolo do cancelamento, ficando exatamente igual ao anexo que enviei do RJ.

Mas isso não aconteceu.

O ACBr está montando normalmente o arquivo para os dois estados, mas como o retorno de MG vem fora do padrão (contendo os prefixos ns0:) acaba tornando o XML inválido.

20 minutos atrás, charles.libano disse:

Alguma sugestão?

Fazer uma reclamação na SEFAZ-MG a respeito dos prefixos, ou retirar manualmente os mesmos.

[charles.libano]

16 minutos atrás, BigWings disse:

37 minutos atrás, charles.libano disse:

O XML que anexei foi feito com a propriedade False, ou seja, mantinha o original e o do cancelamento.

Porém, quero o arquivo xml completo, ou seja, faço uma consulta ao DFe e ele me retorna a NFe autorizada, acrescida abaixo do protocolo do cancelamento. (Em MG isto não está funcionando)

Analisando melhor, o XML que você anexou não é o XML da NFe e sim o XML NFeDFe que agrupa o XML da NFe e a lista de eventos do mesmo:

Ele é gerado com a extensão *-NFeDFe.xml. Você deve ter também um XML *-nfe.xml que é o XML da NFe com o protocolo de autorização apenas.

Eu uso realmente como arquivo final o -NFeDFe.xml, renomeando-o. Ele terá NFe + eventos protocolados, ou seja, é um arquivo válido.

17 minutos atrás, BigWings disse:

38 minutos atrás, charles.libano disse:

Entendi que colocando a propriedade True, isto aconteceria automaticamente, ou seja, o ACBr pegaria a NFe original e colocaria abaixo dela o protocolo do cancelamento, ficando exatamente igual ao anexo que enviei do RJ.

Mas isso não aconteceu.

O ACBr está montando normalmente o arquivo para os dois estados, mas como o retorno de MG vem fora do padrão (contendo os prefixos ns0:) acaba tornando o XML inválido.

Há 2 meses, tivemos uma atualização do ACBr que removia os NameSpaces de MG no retorno da transmissão, devido aos retornos estarem vindo fora do padrão.

Há possibilidade de atualizar os componentes para estender esta funcionalidade de "corrigir" os erros da SEF/MG e então retornar -NFeDFe.xml corretamente através do ACBr?

19 minutos atrás, BigWings disse:

39 minutos atrás, charles.libano disse:

Alguma sugestão?

Fazer uma reclamação na SEFAZ-MG a respeito dos prefixos, ou retirar manualmente os mesmos.

Estou tentando telefonar diretamente para o Coordenador da NFCe de MG, para solicitar a correção deste erro através da STI.

 

Obrigado pela ajuda.

Charles

[charles.libano]

1 hora atrás, charles.libano disse:

Estou tentando telefonar diretamente para o Coordenador da NFCe de MG, para solicitar a correção deste erro através da STI.

Amigos,

O Coordenador da NFCe de MG está de férias. Retorna somente no próximo mês.

Assim sendo, não há outra alternativa a não ser removermos manualmente os name spaces errados.

Há possibilidade de atualizar os componentes para estender esta funcionalidade de "corrigir" os erros da SEF/MG e então retornar -NFeDFe.xml corretamente através do ACBr?

Não sei fazer isso...

Obrigado.

Charles

[charles.libano]

Em 12/11/2019 at 11:46, charles.libano disse:

Amigos,

O Coordenador da NFCe de MG está de férias. Retorna somente no próximo mês.

Assim sendo, não há outra alternativa a não ser removermos manualmente os name spaces errados.

Há possibilidade de atualizar os componentes para estender esta funcionalidade de "corrigir" os erros da SEF/MG e então retornar -NFeDFe.xml corretamente através do ACBr?

Não sei fazer isso...

Obrigado.

Charles

Bom dia a todos.

Fiz um teste agora e em MG o cancelamento ainda está retornando com ns0 fora do padrão.

Alguém pode me ajudar a resolver este problema?

Acho que seria bom colocarmos no ACBr esta "correção do erro de MG". Quando consultamos no DFe uma NFCe de MG que foi cancelada, o retorno deveria vir o XML da transmissão com o protocolo do evento de cancelamento abaixo.

Porém, pelo erro da SEF/MG, este retorno não vem, o que invalida o xml -NFeDFe.xml

Se não for possível colocar nos fontes do ACBr, alguém pode me instruir como colocar nos meus fontes locais, pois a abstração é tamanha que nem sei onde mexer no ACBr nesta parte...

Obrigado e desculpe a insistência, mas é crucial para meu sistema se manter correto sem grandes alterações, já que a equipe sou eu. rsrsrsrs.

Charles

[Italo Giurizzato Junior]

Bom dia Charles,

Faça o seguinte:

1. Abra a unit ACBrNFeWebServices;

2. procure pela function: TNFeConsulta.TratarResposta: Boolean;

3. inclua a linha indicada abaixo:

    FPRetWS := SeparaDadosArray(['NfeConsultaNF2Result',
                                 'NfeConsultaNFResult',
                                 'nfeResultMsg'], FPRetornoWS);

    VerificarSemResposta;

    // a linha abaixo remove o prefixo que foi incluido pela SEFAZ de forma indevida. 
    FPRetWS := StringReplace(FPRetWS, 'ns0:', '', [rfReplaceAll, rfIgnoreCase]);

    NFeRetorno.Leitor.Arquivo := ParseText(FPRetWS);
    NFeRetorno.LerXML;

4. Faça novos testes.

[charles.libano]

1 hora atrás, Italo Jurisato Junior disse:

Bom dia Charles,

Faça o seguinte:

1. Abra a unit ACBrNFeWebServices;

2. procure pela function: TNFeConsulta.TratarResposta: Boolean;

3. inclua a linha indicada abaixo:

    FPRetWS := SeparaDadosArray(['NfeConsultaNF2Result',
                                 'NfeConsultaNFResult',
                                 'nfeResultMsg'], FPRetornoWS);

    VerificarSemResposta;

    // a linha abaixo remove o prefixo que foi incluido pela SEFAZ de forma indevida. 
    FPRetWS := StringReplace(FPRetWS, 'ns0:', '', [rfReplaceAll, rfIgnoreCase]);

    NFeRetorno.Leitor.Arquivo := ParseText(FPRetWS);
    NFeRetorno.LerXML;

4. Faça novos testes.

Ítalo,

Boa tarde.

Fiz a alteração, reinstalei o ACBr e funcionou perfeitamente.

Acho que esta alteração poderia subir para os fontes, já que não prejudica outras funcionalidades e corrige o erro da SEFAZ.

Obrigado pela ajuda.

Charles

[EMBarbosa]

2 horas atrás, charles.libano disse:

Ítalo,

Boa tarde.

Fiz a alteração, reinstalei o ACBr e funcionou perfeitamente.

Acho que esta alteração poderia subir para os fontes, já que não prejudica outras funcionalidades e corrige o erro da SEFAZ.

Obrigado pela ajuda.

Charles

Olá Charles e todos os que estiverem passando por esse mesmo problema.

   Queremos incentivar a todos vocês a entrar em contato pelo Fale Conosco mencionando o problema. Por favor, façam isso. Quanto maior o volume de pessoas fazendo isso, mais urgente eles vão considerar o problema.

[ALA]

Estou com um problema parecido. A contabilidade esta reclamando que os xmls cancelados não contem o evento de cancelamento. Dessa forma eles não conseguem saber se o xml foi cancelado ou não...

[EMBarbosa]

Em 20/11/2019 at 17:38, ALA disse:

Estou com um problema parecido. A contabilidade esta reclamando que os xmls cancelados não contem o evento de cancelamento. Dessa forma eles não conseguem saber se o xml foi cancelado ou não...

Por favor, verifique se o problema é o mesmo relatado acima, a saber, que as respostas da SEFAZ estão vindo com prefixos "ns0:" nas tags.

Se esse for o caso, queria por favor, entrar em contato pelo Fale Conosco da SEFAZ de MG mencionando o problema. Se seus contadores fizerem o mesmo o volume será maior e eles vão corrigir o problema mais rapidamente.

[Italo Giurizzato Junior]

Bom dia a todos,

Alguém pode me informar se a SEFAZ-MG desfez a lambança de colocar o prefixo ns0: no retorno da consulta?

[Italo Giurizzato Junior]

Boa tarde a todos,

Como ninguém me retornou sobre o problema da SEFAZ-MG ter resolvido o problema de gerar de forma indevida o prefixo ns0: no retorno da consulta e também mais ninguém veio relatar o problema, concluo que o problema foi sanado.

Sendo assim vou dar como encerrado esse assunto.