Italo Giurizzato Junior

Bom dia Edmar, Primeiramente, peço que não poste fragmento de códigos longo como texto da postagem, procure colocar em um arquivo texto e anexar. Qual é o erro que ocorre?

A URL tem 95 caracteres sendo o tamanho máximo é de 85. Notei que a URL usada tanto na tag qrCode quanto na urlChave estão diferentes das que constam no arquivo ACBrNFeServicos.ini Favor atualizar os seus fontes e refaça os testes.

Allan, O seu chefe pode querer o que ele bem entender. Se você abrir o arquivo Betha.ini vai encontrar os seguintes campos: [Geral] VersaoSoap=1.1 (...) ; 0 = False / 1 = True UseCertificado=1 ; 0 = False / 1 = True (se True então assina) [Assinar] RPS=1 Lote=1 (...) Como você pode ver no caso do provedor Betha devemos assinar o XML do RPS, assinar o Lote que contem o RPS previamente assinado e para poder consumir o webservice é preciso usar o Certificado. Se você alterar esse arquivo com o objetivo de não assinar o RPS e o Lote o que vai ocorrer: primeiro que o Lote não vai ser validado e o envio será abortado. Se você alterar esse arquivo para que o lote não seja validado não vai conseguir enviar pela falta do certificado e se mesmo assim você conseguir enviar, o lote será rejeitado pelo provedor pois tanto o RPS quanto o Lote não estão assinados. Acredito que ficou claro.

Bom dia a todos, O layout do XML dos evento não foram alterados, permanecendo os mesmos, logo não tem o que se preocupar. Se tivesse alguma alteração, com certeza já tínhamos feito a alteração no componente. Outra coisa, basta configurar o componente para a versão 4.00 e fazer os devidos testes em ambiente de homologação.

Bom dia, Gere o XML e salve em disco, depois anexa ele no fórum para podermos analisar. A tag urlChave tem um tamanho mínimo de 21 e máximo de 85 caracteres.

Bom dia Antônio, Qual foi a ultima vez que você atualizou tudo e reinstalou os componentes ACBr?

Bom dia Allan, Mesmo configurando o componente para enviar para o ambiente de homologação, será necessário o certificado digital. O certificado digital é utilizado para assinar o RPS e ou Lote bem como estabelecer uma conexão com o servidor (webservice) do provedor.

Bom dia Cristian, É preciso "debugar" para descobrir onde o AV ocorre.

Bom dia Ricardo, Você esta tentando enviar para o ambiente de homologação, correto? Se sim, entre em contato com o provedor pois para o ambiente de homologação é preciso informar um usuário e senha especifico.

Boa noite Alice, Neste caso é preciso comparar um fonte com o outro para descobrir o que esta motivando esse problema.

Boa tarde, Nas configurações do componente no grupo webservice não tem uma propriedade chamada Visualizar? Chegou a atribuir o valor False a ela para ver o que acontece?

Boa tarde Rino, Muito obrigado pela colaboração, já esta no repositório.

Boa tarde Edmar, Segundo o manual do eSocial versão 2.4.02 o grupo infoComplCont fica dentro do grupo dmDev, visto que o ideDmDev é um elemento que também fica dentro do grupo dmDev. No manual consta a seguinte observação referente ao grupo infoComplCont: Registro preenchido exclusivamente quando o evento de remuneração se referir a trabalhador cuja categoria não estiver obrigada ao evento de início de TSVE e se não houver evento S-2300 correspondente (CPF + categoria).

Boa tarde emarcolongo, O XML foi gerado pelo componente ACBreSocial? Ou você esta usando o componente apenas para assinar o XML gerado por uma rotina própria sua?

Abra o XML através de uma navegar por exemplo e veja o código da UF que consta no grupo <cteCabecMsg>. Você esta fazendo alguma coisa errada.

Bom dia Cristian, Muito obrigado pela colaboração, favor atualizar os fontes e faça os testes.

É preciso "debugar" para saber o que esta provocando esse erro.

Allan, Estou me referindo ao arquivo INI de configuração do componente e não o arquivo INI do provedor e nem o arquivo INI das cidades.

Você tem o arquivo soap de envio do evento? *-ped-eve-soap.xml Se sim, favor anexar.

Bom dia Allan, Dentro da pasta existe o arquivo INI de configuração? Se sim, ele contem as informações de configuração?

Bom dia Fernando, O provedor WebISS segue a versão 1 do layout da ABRASF. Sendo assim após o envio devemos executar o método ConsultarSituacao e não ConsultarLoteRPS. O método ConsultarSituacao vai nos informar a situação do lote enviado que pode ser: 1 - Lote não recebido, isso significa que passamos o numero do lote errado. 2 - Lote em processamento, isso significa que devemos aguardar mais alguns segundos e tentar novamente, ou seja fazer uma nova consulta. 3 - Lote processado com falha, isso significa que o lote foi processado mas existem informações erradas, logo o RPS não foi aceito. 4 - Lote processado com sucesso, isso significa que o lote foi processado e o RPS foi convertido em NFS-e. Sendo assim só devemos executar o método ConsultarLoteRps se a situação for 3 ou 4, pois se for 3 teremos como resposta a lista de erros, que deveremos corrigir e enviar o RPS novamente, por outro lado se foi 4 teremos como resposta o XML da NFS-e, XML este que será salvo separadamente em disco e é este XML que devemos carregar para poder imprimir o DANFSE.

Bom dia Alice, Não existe nenhum problema em você aumentar o valor de Timeout. Se você configura o Timeout com o valor 5000 (5 segundos) isso faz com que o componente aguarde por no máximo 5 segundos por um retorno do Webservices. Por outro lado se você aumentar esse tempo para 30 segundos, eu entendo que isso vai ajudar em vez de atrapalhar, pois se o provedor esta passando por uma lentidão e não consegue responder em 5 segundos e sim em 8 segundos, se você deixar um timeout de 5 segundos terás problemas, por outro lado se aumentar vai obter o retorno. Lembre-se o timeout não faz com que a aplicação fique parada todo esse tempo, na verdade estamos atribuindo um limite máximo de espera. Se a resposta for obtida em 2 segundos a aplicação vai dar continuidade ao processo. É diferente de você atribuir o valor 10000 a propriedade AguardarConsultaRet, pois neste caso após o envio e obter o numero do protocolo, o componente vai aguardar o tempo definido em AguardarConsultaRet, que neste exemplo ficaria parado durante 10 segundos antes de prosseguir. Tentativas se você colocar 10, também não tem problema algum, pois se a resposta vier logo na segunda o componente sai do loop de tentativas pois já obteve a resposta esperada. IntervaloTentavias que a principio vale 1000 se alterarmos para 5000, o componente vai fazer uma pausa de 5 segundos entre uma tentativa e outra. Então podemos concluir que os valores de AguardarConsultaRet e IntervaloTentativas quanto maiores forem mais tempo vai levar entre o envio do RPS e a impressão do DANFSE. Por outro lado os valores de Tentativas e Timeout não prejudica o desempenho da aplicação no que diz a tempo. É obvio que um provedor que esteja passando por uma lentidão ou é lento mesmo, o tempo entre o envio e a impressão do DANFSE vai ser maior que de outro. Valores maiores para as propriedades Tentativas e Timeout tem como objetivo evitar que a aplicação seja interrompida pelo fato de não ter conseguido um retorno do provedor. Não sei se ficou claro.

Bom dia, Pelo retorno noto que a versão do aplicativo da SEFAZ que processou o evento inicia com "RS" o motivo disso é que a UF RO se utiliza da SEFAZ-Virtual do Rio Grande do Sul. O estranho é o valor 35 que indica UF SP aparecer no campo cOrgao no retorno. Ao configurar o componente você atribui a UF RO a propriedade: Configurações.WebServices.UF e qual é o valor atribuído a propriedade Configuracoes.Geral.FormaEmissao?

Bom dia Gustavo, Os Schemas que você baixou do Site são diferentes dos que estão na pasta: ...\Exemplos\ACBrDFe\Schemas\Reinf ?

Bom dia, Muito estranho esse erro relacionado ao tpEmis, uma vez que se trata do envio de eventos e não envio de CT-e.