Italo Giurizzato Junior

Boa tarde Diego, Vamos verificar o que esta ocorrendo. Caso queria contribuir fazendo as devidas correções fique a vontade.

Boa tarde Ricardo, Então o problema é no App que você esta utilizando e não na geração da string do QR-Code realizada pelo componente.

Boa tarde Felipe, Desde já muito obrigado pela colaboração, vamos analisar o que você fez e estando tudo OK vamos enviar para o repositório.

Boa tarde Marcelo, Esse retorno se refere a consulta a situação do lote de RPS que foi enviado. Não esta previsto um campo que contenha esse XML para que você possa armazena-lo no Banco de Dados. Só esta previsto a leitura das TAGs que compõe esse XML. O conteúdo dessas TAGs você pode ler e armazenar os valores lidos em campos no seu Banco de Dados. Por exemplo: with ACBrNFSe1.WebServices.ConsSitLoteRPS.RetSitLote do begin for i := 0 to InfSit.MsgRetorno.Count -1 do begin xCodigo := InfSit.MsgRetorno[i].Codigo; xMensagem := InfSit.MsgRetorno[i].Mensagem; xCorrecao := InfSit.MsgRetorno[i].Correcao; end; end; Espero ter ajudado.

Henrique, A alteração no arquivo INI esta correta. Você executou o Compila_RES? Talvez seja necessário reinstalar os componentes para que ele assume a alteração feita no arquivo INI.

Olá Pessoal, A SEFAZ-MG esta gerando de forma indiscriminada namespace em todas as TAGs de retorno. Sendo que, segundo o Manual versão 7.02 (visão Geral da NF-e/NFC-e) item 3.2.1.2 que se refere a declaração namespace, deixa bem claro que o documento XML deverá ter uma única declaração de namespace no elemento raiz do documento. O retorno da SEFAZ-MG esta fugindo dessa regra e colocando o namespace e todas as TAGs do XML. Peço a todos que atualizem todos os fontes de todas as pastas e reinstale a suíte ACBr, pois enviamos para o repositório uma possível correção para o problema. Será disponibilizado uma nova versão do ACBrMonitor para que os usuários do mesmo tenham também o problema resolvido. Exemplo de como a SEFAZ-MG esta gerando o XML de retorno: Como deveria ser gerado, portanto o correto:

Henrique, Faça o seguinte teste: 1. Desfaça a sua alteração na unit; 2. Abra o arquivo ACBrNFeServicos.ini vá até o final dele, você vai encontrar: [SOAP_V4_SP] NFeAutorizacao_4.00=http://www.portalfiscal.inf.br/nfe/wsdl/NfeAutorizacao4/nfeAutorizacaoLote NFeRetAutorizacao_4.00=http://www.portalfiscal.inf.br/nfe/wsdl/NfeRetAutorizacao4/nfeRetAutorizacaoLote (...) Replica essa seção, mas mude o nome dela para [SOAP_V4_BA] ficando da seguinte forma: [SOAP_V4_SP] NFeAutorizacao_4.00=http://www.portalfiscal.inf.br/nfe/wsdl/NfeAutorizacao4/nfeAutorizacaoLote NFeRetAutorizacao_4.00=http://www.portalfiscal.inf.br/nfe/wsdl/NfeRetAutorizacao4/nfeRetAutorizacaoLote (...) [SOAP_V4_BA] NFeAutorizacao_4.00=http://www.portalfiscal.inf.br/nfe/wsdl/NfeAutorizacao4/nfeAutorizacaoLote NFeRetAutorizacao_4.00=http://www.portalfiscal.inf.br/nfe/wsdl/NfeRetAutorizacao4/nfeRetAutorizacaoLote (...) Salve o arquivo e depois execute o Compila_RES, feito isso compile a sua aplicação com a opção Build. Faça um novo teste.

Bom dia Davidson, Favor testar a sua aplicação que utiliza o ACBrNFe com a unit em anexo. ACBrNFeWebServices.pas

Bom dia Henrique, Essa alteração na montagem da URL do SoapAction não vai gerar um efeito colateral para as demais UF?

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

Bom dia Giovanne, O que ocorre quando se envia com o numero da porta ":80" e sem?

Bom dia Ricardo, Você utiliza o ACBrCTe? Se sim, a URL do QR-Code se encontra no arquivo ACBrCTeServicos.ini Em uma breve checagem não detectei esse erro. Pelo que entendi o componente esta removendo o ":" que esta entre o http e a "/". Você poderia anexar o XML do CT-e que foi gerado com esse problema?

Diego, Favor realizar testes com a unit em anexo. ACBrCTe.pas

Boa tarde Diego, Você poderia anexar dois XML um enviando direto para a SEFAZ-MG e outro para o SVC-SP?

Boa tarde Paulo, O componente assina o RPS exatamente igual para todos os provedores. É esse provedor que esta com essa frescura de fazer diferente. São eles que tem que seguir o padrão.

Boa tarde Leandro, Não fiz testes, por não ter clientes em MG, mas pela minha analise o XML final da NF-e não vai conter os namespace incluídos pela SEFAZ-MG de forma indevida.

Boa tarde a todos, Favor testarem com a unit em anexo. ACBrNFeWebServices.pas

@navegador_1000, O problema é que colocando no rCampo essa checagem será realizada em todas as tags do XML, imagina ao carregar o XML de uma NFC-e com uns 200 itens. Acredito que a leitura de um XML desse vai passar a ser muito demorada. Um quebra galho até que a SEFAZ-MG abaixa a crista e reconheça a porcaria que fez na geração dos XMLs de retornos, segue em anexo. ACBrNFeWebServices.pas A alteração feita nessa unit faz com que seja removido todos os namespace do XML antes da sua leitura, acredito que desta forma o tempo de leitura do mesmo não vai ser comprometida.

Bom dia a todos, Esse provedor esta fazendo a checagem de fora errada. Devemos gerar o XML do RPS, assinar e depois colocar dentro do grupo GerarNfseEnvio. A ideia é a mesma da NF-e, onde devemos gerar o XML da NF-e, assinar e depois colocar dentro do grupo enviNFe. Mas sabe como é, os caras querem ser diferentes, são os bam bam bam dos documentos fiscais eletrônicos. Mas como dizia o meu pai, eles são novos, daqui umas 10 semanas santa eles aprendem. Com a reforma tributaria que se Deus quiser vai sair, a nota fiscal de serviço vai ser unificada a nota fiscal de venda de produtos. Isso significa que vamos utilizar a NF-e para emitir as notas fiscais de serviço em todo o território nacional. Vai demorar um pouco, mas existe uma luz no fundo do túnel. E quando isso ocorrer vou ter o prazer de diz Bye Bye provedores.

Bom dia Paulo, Neste caso seria interessante entrar em contato com o provedor e questionar se essa mudança na URL de homologação é para todas as cidades atendidas por eles.

Bom dia Ricardo, Favor anexar a unit alterada para que possamos analisar.

Bom dia Ronie, Você esta usando o componente ACBrCTe, para gerar o XML e o enviar para a SEFAZ?

Bom dia Osmar, Lembre-se, uma coisa é a configuração e outra coisa é a alimentação do componente com os dados do documento que será enviando. Se o Emitente do documento for da UF MS, você deve configurar o componente para a UF de MS, não pode ser outra caso contrario vai ocorrer erros.

Bom dia NecBrasil, Você esta enviando o CT-e para qual SEFAZ?

Bom dia a todos, Não concordo com essa alteração, pois essa rotina é utilizada para ler o XML de todos os DF-e: NF-e, CT-e, MDF-e, BP-e, NFS-e, e-Social e Reinf. E cada DF-e possui um namespace diferente. O correto é entrar em contato com a SEFAZ e apontar o problema.