Italo Giurizzato Junior

Boa tarde Ernesto, Depois vou analisar o que você alterou. Desde já muito obrigado pela colaboração de todos que estão empenhados em que a coisa funcione.

Daniel, O envio do evento já esta implementado e você pode realizar os testes. Quando ao impressão do DAEvento já não sei lhe informar se já esta pronto. Mas não custa nada testar.

Tai o que eu disse, eles não tem competência para fazer a correção no webservice novo, pegaram o antigo (ABRASF versão 1.00) que esta funcionando e vão colocar no lugar. Quem sabe daqui umas 10 semanas santa eles conseguem descobrir a kaka que fizeram nesse novo.

Boa tarde a todos, Edu, com certeza esse aplicativo em C# realiza a assinatura de forma idêntica a que o ACBrNFSe realiza. O problema não esta em realizar a assinatura. Repito mais uma vez, a rotina que realiza a assinatura é exatamente a mesma que é utilizada pelos componentes: ACBrNFe, ACBrCTe, ACBrMDFe, ACBrBPe, ACBreSocial, ACBrReinf e ACBrNFSe. E se tratando o ACBrNFSe, hoje temos um rol de aproximadamente 100 provedores. O XYZ da questão é a validação realizada por esse provedor de fundo de quintal, que não foram capazes de comparar a rotina de validação do webservice SimplISS que segue a versão 1 da ABRASF com esse novo que segue a versão 2. E se chegaram a comparar são tão nó cegos que não viram ainda a kaka que eles fizeram. Se todas as SEFAZ-Autorizadoras validam a assinatura realizada pela ACBr, quem são eles em dizer que a assinatura não é valida. Pedem para sair e chama logo o segundo colocado na Licitação. Se o prefeito não fizer isso, com certeza a comissão dele foi bem gorda.

Henrique, Faça mais esse ajuste no arquivo ACBrNFeServicos.ini [NFe_BA_P] NfeRecepcao_2.00=https://nfe.sefaz.ba.gov.br/webservices/nfenw/NfeRecepcao2.asmx (...) NFeRetAutorizacao_4.00=https://nfe.sefaz.ba.gov.br/webservices/NFeRetAutorizacao4/NFeRetAutorizacao4.asmx SoapAction=SOAP_V4_BA <====== incluir esta linha [NFe_BA_H] NfeRecepcao_2.00=https://hnfe.sefaz.ba.gov.br/webservices/nfenw/NfeRecepcao2.asmx (...) NfeConsultaCadastro_4.00=https://hnfe.sefaz.ba.gov.br/webservices/CadConsultaCadastro4/CadConsultaCadastro4.asmx SoapAction=SOAP_V4_BA <====== incluir esta linha E faça novos testes.

Boa tarde Rafa, Você esta usando o ACBrMonitor ou o componente ACBrMDFe? Se é o componente, favor estudar o programa exemplo do mesmo, pois este possui um botão que faz o encerramento.

Boa tarde Daniel, Quais funcionalidades você se refere?

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.

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 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 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.