AngeloMique

Bom dia. Como não conseguimos achar a possível falha, não tomaremos mais o tempo de ninguém aqui. Como o componente retorna o XML correto, muito embora não o exiba nas situações acima, vamos utilizá-lo mesmo assim lendo o XML que ele retorna correto manualmente, nos ambientes com proxy. Senhor moderador, favor encerrar o tópico. Agradeço a todos pela ajuda, pela atenção e pelo esforço. Angelo.

Bom dia Victor. Obrigado pelo retorno. Percebi que vc debugou em uma versão 10 ou superior do Delphi. Em qual Windows vc efetuou a depuração? Conforme apontamos, o problema parece acontecer nos Windows inferiores ao 10 22H2. O problema ocorre com as versões do Windows inferiores ao 10 22H2, com proxy habilitado. Toda essa depuração que vc fez nós fizemos, só que no Windows 10 22H2, tanto com o D2010 qto com o D11. Também não detectamos qualquer problema em cima dessa versão do Windows, com ou sem proxy habilitado. Já usamos também um PAServer. Sem sucesso. Testamos atrás de um servidor proxy Linux do cliente conforme acima já mencionado. Sem sucesso. No Windows 10 22H2, o componente se comporta perfeitamente, com proxy ou sem, nestes ambientes. A situação acima relatada acontece desde o Windows 7 32 até o Windows 10 versão 1809, com proxy habilitado. Sem proxy, vai de boa. Não temos Delphi instalado em versões inferiores ao Windows 10 22H2, por isso não tivemos condições de debugar nestes ambientes. Lembrando que a aplicação que testamos é o demo que vem nos fontes do ACBR, sem mudar uma única linha de código. Angelo.

Boa tarde Diego. Obrigado pelo retorno. O problema é que nosso ambiente de desenvolvimento está todo em Windows 10 2H22. Mas debugamos mesmo assim e não levanta nenhum AV e nenhuma Exception, tanto sem quanto com proxy. Tudo roda normal no D2010 e no D11. Pelo visto vamos ter de debugar com o D2010 num Windows 7... Aiiii... Angelo.

Boa tarde Diego. Esses arquivos foram gerados em uma máquina com proxy: GTIN_COM_PROXY.zip Estes arquivos foram gerados numa máquina sem proxy: GTIN_SEMPROXY.zip Nosso ambiente de testes: 1 - Compilamos a aplicação demo no Delphi 2010 com todos os patches de atualização e a última versão do ACBR trunk 2, baixado via SVN. 2 - Compilamos também a aplicação demo no Delphi 11 Alexandria com os patches instalados e a última versão do ACBR trunk 2 via SVN. 3 - Os schemas que utilizamos em todos os testes são os que vem junto com o ACBR trunk 2, baixados do SVN. 3 - Levamos 2 PCs de desenvolvimento para o ambiente de um cliente com Proxy. Instalamos nelas, do zero, o Windows 10, versão 22H2 64 bits com todas as atualizações; instalamos o certificado digital do cliente e o nosso (todos e-CNPJ A1, 1 da Certisign e outro do Serasa); instalamos todas as cadeias de certificados; 4 - Instalamos em cada uma dessas máquinas físicas 3 VMS para teste: a) 1 Windows 7 32 bits com todas as atualizações e updates possíveis; b) 1 Windows 8.1 64 bits com todas as atualizações e updates possíveis e c) 1 Windows Server 2012R2 64 bits com todas as atualizações e updates possíveis. Instalamos em todas elas também os certificados acima mencionados e as cadeias. 5 - Importante: Tais VMS já são utilizadas no nosso ambiente para testes dos nossos softwares, com NF-e, NFC-e e NFS-e. Em todas essas VMS, nossas aplicações consultam, emitem, cancelam entre outras coisas os documentos fiscais mencionados sem nenhum problema, seja com o proxy habilitado, ou seja sem ele. Porém, no ACBR GTIN, com o proxy, elas apresentam o erro : 6 - Conforme já mencionei, nas VMS acima os arquivos XML de consulta são retornados corretamente na pasta indicada no aplicativo de exemplo, mas com o proxy habilitado, o componente não mostra o retorno. No ambiente sem proxy, sim, mostra todas as informações. 7 - Agora o mais bizarro: Nas máquinas físicas com o Windows 10 22H2, sem mesmo configurar o proxy nas opções da aplicação demo, ele faz e apresenta todas as consultas normalmente, seja com proxy, seja sem. E mesmo habilitando e informando o parâmetro do proxy no aplicativo demo, no Windows 10 22H2, o aplicativo demo retorna e apresenta normalmente a consulta. 8 - Não satisfeitos, levamos a aplicação demo a uma máquina do cliente, com o Windows 10, mas a versão 1809, obviamente com o proxy habilitado. Deu o mesmo erro que acima, como nas VMS. 9 - Lembrando que em todos os casos, rodamos as aplicações compiladas no D2010 e no D11. Sempre os mesmos resultados, nos executáveis 2 aplicações demo. 10 - Instalamos numa VM , do zero, o Windows 10 2H22. Mesmo procedimento de instalação e configuração das máquinas físicas. Nesta máquina, com e sem proxy habilitado, o ACBR GTIN retorna e apresenta corretamente os dados. 11 - Instalamos numa VM , do zero, o Windows 11 2H22. Mesmo procedimento de instalação e configuração das máquinas físicas. Nesta máquina, com e sem proxy habilitado, o ACBR GTIN também retorna e apresenta corretamente os dados. 11 - Na nossa humilde opinião, parece que o componente, em ambientes mais antigos, tem dificuldade de carregar as informações do XML retornado pelo WebService de consulta da SEFAZ/RS. Mais alguma sugestão? Estamos quase ao ponto de nestes clientes com proxy, ler na unha o XML retornado pelo demo. Agradeço desde já a atenção e desculpem o texto muito longo. Angelo.

Oi Diego. Deu certo. Amanhã retomaremos os testes. Obrigado.

Bom dia Diego. Desculpe a demora. Desde ontem à tarde, venho recebendo esses erros ao tentar consultar o GTIN, em ambiente sem proxy: Pela manhã estava consultando tudo normal. Por isso não tive condições de gerar o acima. Será que são problemas na SEFAZ/RS? Hoje de manhã tentei novamente e mesmo erro. Certificado OK, emitindo NF-e e NFC-e nesta máquina e em outras máquinas de desenvolvimento em ambiente de homologação do PR. Seguem as telas de configuração da aplicação demo do ACBR:

Ok Diego. Farei isso.

Bom dia Rubinho. Não chega a nem 5 segundos, mesmo aumentando para 1 minuto. Parece que o componente não está lendo vários parâmetros com o proxy habilitado. Aliás, consulteis o log do proxy fornecido e está passando de boa. O problema é que aparentemente no retorno, o componente não está lendo os arquivos de retorno com o proxy habilitado.

Boa tarde Rubinho. Obrigado pelo retorno. Todos os testes estão sendo feitos com a aplicação de exemplo e o campo proxy preenchido corretamente. Aumentei o TimeOut para 30000 e parece que também não lê este parâmetro. É como se simplesmente o WebService não lesse nenhum parâmetro envolvendo o Proxy, inclusive o timeout. Muito esquisito. Além disso, numa máquina com proxy, mesmo retirando os parâmetros de proxy e porta, gravando as alterações, saindo da aplicação e voltando e testando, ele continua aparentemente tentando passar pelo proxy e retornado a tela com dados vazios, como se o webservice continuasse na memória parametrizado ou algo assim. Muito esquisito. Vou ver se consigo um proxy e tento debugar a aplicação atrás dele. Muito obrigado desde já.

Boa tarde Diego. Estou usando o aplicativo exemplo do ACBR ainda. Existe uma rotina nele chamada ConfiguraComponente, que é chamada em outra rotina chamada LerConfiguracao, executada no OnCreate do Form Principal, onde há os comandos: with ACBrGTIN1.Configuracoes.WebServices do begin UF := cbUF.Text; Ambiente := StrToTpAmb(Ok, IntToStr(rgTipoAmb.ItemIndex+1)); Visualizar := cbxVisualizar.Checked; Salvar := cbxSalvarSOAP.Checked; TimeOut := seTimeOut.Value; ProxyHost := edtProxyHost.Text; ProxyPort := edtProxyPorta.Text; ProxyUser := edtProxyUser.Text; ProxyPass := edtProxySenha.Text; end; Acredito que ele está passando correto, pois se não configuro o endereço e porta do Proxy na aplicação de exemplo, na máquina dá erro de timeout ao tentar consultar o WebService. Alguma outra ideia?

Bom dia Diego. Obrigado pelo retorno. Numa máquina com o Proxy ativo, marquei a opção que você me orientou e retornou os 4 XMLS anexos: 7890176052858-cons-gtin.xml7890176052858-gtin-soap.xml7890176052858-gtin.xml7890176052858-cons-gtin-soap.xml Aparentemente o serviço está respondendo OK, só o componente não retorna os dados dos XMLs de consulta quando informado o proxy. Lembrando que em máquinas sem proxy ele retorna e exibe normalmente os dados dos XMLs retornados. Obrigado desde já, Angelo.

Corrigindo: A URL acessada pelas máquinas via proxy acima citada é https://dfe-servico.svrs.rs.gov.br/ws/ccgConsGTIN/ccgConsGTIN.asmx Angelo.

Boa tarde a todos. Estou implementando o ACBRGTIN em um projeto. Certificado, Schemas, etc... tudo configurado. Em máquinas sem um proxy, a consulta vai de boa e o WebServices retorna todas as informações corretamente. Porém, quando configuramos um proxy, o componente retorna como se o Webservice não tivesse sido consultado, ou seja resulta vazio em todas as informações. A URL do WebService utilizado para a cosnulta (https://dfe-servico.svrs.rs.gov.br/ws/cgConsGTIN/ccgConsGTIN.asmx) abre no browser nas máquinas com proxy normalmente. Mas no componente, retorna nulo. Imagens anexas. Alguém poderia dar uma luz? Sem proxy: Com Proxy:

Já resolvi como Fortes Report. Grato a Todos.

Grato pelo retorno. No trunk2 existe este exemplo?

Olá pessoal! Alguém poderia me indicar qual o exemplo que emite o DANFE da NFC-e utilizando o QuickReport? O exemplo do ESC/POS eu já achei. Utilizo o Delphi 7 com o Trunk 1 ainda. Grato, Angelo.