Italo Giurizzato Junior

Boa tarde Douglas, Favor anexar os arquivos que foram alterados para que possamos analisar.

Boa tarde Duarde, ABRASF não é um provedor, esta errado o que você fez. Os arquivos ABRASFv1.ini e ABRASFv2.ini são modelos a serem utilizados por provedores que seguem essas versões de layouts. Nas pastas de mesmo nome que se encontram dentro da pasta Schemas, temos os schemas padrões utilizados pelas respectivas versões. É preciso saber se realmente o provedor Ábaco desativou o seu webservice que recepciona RPS segundo a versão 1 do layout da ABRASF e consequentemente esta disponibilizando um novo que segue a versão 2, ou se possui dois webservices um de cada versão.

Bom dia Fábio, Até onde sei a cidade de Arapiraca/AL se utiliza do provedor Ábaco e este segue a versão 1 do layout da ABRASF e não a versão 2. A versão que aparece no cabeçalho do XML do envio é 201001, mas como dito antes o provedor segue a versão 1 do layout da ABRASF. Quais são os problemas que você esta enfrentando?

Bom dia, Fiz uma alteração que vou enviar ainda hoje para o repositório. Tente obter o valor do campo Situação da seguinte forma: Situacao := ACBrNFSe1.WebServices.ConsLote.Situacao;

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

Bom dia Leo, O que esta ocorrendo é que o componente esta assinado somente o Lote. Favor entrar em contato com o provedor e questionar eles. O que tem que ser assinado (é só o RPS, é só o Lote ou ambos)?

Bom dia Edson, Esse é o grande problema da falta de padronização. O provedor de campinas esta apenas retornado a titulo de nota um resumo e não o XML completo da nota como ocorre com os provedores que seguem o layout da ABRASF.

Bom dia Walfrido, O provedor Ginfes segue a versão 1 do layout da ABRASF, sendo assim em seu webservice só existe o serviço EnviarLoteRps que a principio permite recepcionar um lote contendo de 1 até 50 RPS. Se ao enviar um lote com 2 ou mais RPS o provedor apresenta problemas, como exemplo o que você apontou (Timeout), isso significa que o webservice não esta conseguindo dar conta do recado. Favor alterar o valor da propriedade de configuração do componente chamada Timeout. Quem sabe resolve o problema, pois aumentar o valor de Timeout faz com que o componente de um tempo maior para que o webservice possa responder.

Bom dia Vanderson, Fiz uma alteração em outra unit que acredito que vai resolver o problema se alterar o arquivo INI e a unit que você alterou. Ainda hoje estarei enviando para o repositório.

Bom dia Rhuan Nos seus testes antes dessa alteração, chegou a usar os novos arquivos INI que foram disponibilizados e que se encontram na pasta: ...\Exemplos\ACBrDFe\ACBrNFSe\ArqINI ?

Bom dia, Pelo PDF que você anexou da entender que o provedor SigCorp se utiliza da versão 2 do layout da ABRASF. Sendo assim, basta você criar um novo arquivo INI para esse provedor (SigCorp.ini aos moldes de outro provedor que também segue a versão 2) e nos fontes do componente, mas precisamente em pnfsConversao, criar um novo enumerador para esse provedor (proSigCorp) e acrescentar ele em todas as funções dessa unit onde aparece um outro provedor que também segue a versão 2 (por exemplo Fiorilli). Feito isso, mudar no Cidades.ini o provedor para a cidade de Avaré/SP, por fim iniciar os testes com o programa exemplo. Talvez seja necessário fazer ajustes no arquivo ini do provedor e em outras units do componente por conta da falta de padronização entre os provedores.

Bom dia Josenildo, Que eu saiba ainda ninguém colocou a mão na massa para fazer as devidas alterações. Se alguém puder nos ajudar ficaremos gratos por colaborarem.

Bom dia Carlos, Muito obrigado pela colaboração, já enviei para o repositório.

Boa tarde Joata, Você tem essa unit declarada no uses do seu Form? Essa unit não existe mais, ocorreu uma padronização de units comuns, a equivalente se chama: pcnRetDistDFeInt

Boa tarde Rômulo, Muito obrigado pela colaboração, ainda hoje estarei enviando para o repositório.

Boa tarde Rogério, O que tudo indica o problema é na SEFAZ-MG.

Daniel, O ideal é realizar testes com o componente e ver o que precisa ser alterado nele para funcionar.

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

Bom dia Daniel, Você utilizou o componente ACBrCIOT que se encontra no Branches? Se sim, foi necessário fazer algum ajuste? Se sim, poderia anexar aqui as units que você alterou para poder realizar o envio para o Webservices do e-Frete?

Boa tarde a todos, Vocês devem ter notado que os componentes mencionados ao configurar para o ambiente de teste devemos atribuir o valor taHomologacao a propriedade de configuração: Ambiente. Mas ao alimentar qualquer evento o valor atribuído ao campo tpAmb tem que ser taProducaoRestrita que nada mais é do que um ambiente de teste, ou seja, homologação. Não me perguntem porque os responsáveis pelo e-Social e Reinf resolveram chamar o ambiente de teste de Produção Restrita em vez de Homologação. É sabido que o tipo de ambiente informado na configuração tem que ser o mesmo ao alimentar os dados do evento, para facilitar a vida resolvi remover o campo tpAmb. Isso vai fazer com que ao compilar a sua aplicação após a atualização dos fontes da suíte ACBr vai ocorrer erros de compilação, apontando para o campo tpAmb e acusando o mesmo de não existir. Como proceder? Simples, remova a linha da sua aplicação que contem o campo tpAmb nas rotinas que alimentam os eventos. A geração da tag <tpAmb> vai conter o valor atribuído ao configurar o componente. Se o valor de Ambiente = taProducao a tag receberá o valor 1, por outro lado se for igual a taHomologacao receberá o valor 2 que é o mesmo valor de taProducaoRestrita. Com essa alteração nos componentes ACBreSocial e ACBrReinf nunca mais vai ocorrer de um evento ser rejeitado pelo fato do tipo de ambiente informado no XML ser diferente do ambiente para o qual foi enviado. O envio dessa alteração para o repositório ocorra amanhã (29/03/2019).

Bom dia Alysson, Acredito que esse problema foi sanada com a mudança da versão e com as alterações que foram feitas e enviadas hoje pela manhã para o repositório.

Bom dia Joffas, Ao compilar o programa exemplo do e-Social ocorre o mesmo erro?

Bom dia Paulo, Pelo seu arquivo INI, noto que os seus fontes estão desatualizados. Por favor atualize todos os fontes de todas as pastas, reinstale os componentes usando o ACBrInstall_Trunk2 com a opção: apagar arquivos antigos marcada. Faça novos testes usando os arquivos INI da pasta: ...\Exemplos\ACBrDFe\ACBrNFSe\ArqINI note que o arquivo INI do provedor Ginfes já tem o campo DocElemento na sessão Cancelar.

Boa tarde Augusto, Estanho, o código de verificação é uma string, e ao meu ver o tipo de alinhamento não era para causar esse problema. Muito obrigado pela colaboração, já esta no repositório.

Boa tarde Douglas, Usando o programa exemplo do componente ACBrNFSe fiz um teste com a cidade em questão. Consegui estabelecer conexão e obter um retorno usando o método Gerar.