Italo Giurizzato Junior

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?

Junior, Por favor, vamos seguir as regras do fórum. Vou fechar esta postagem, pois já respondi a sua outra que trata do mesmo problema.

Boa tarde Junior, Você configurou o componente para salvar os arquivos de envio e de retorno? Configuracoes.Geral.Salvar := True e / ou Configuracoes.WebServices.Salvar := True

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.

Bom dia Davidson, Você esta usando o ACBrMonitor correto? Esta tentando emitir NF-e ou NFC-e? Em qual versão (3.10 ou 4.00)? Quais são os valores dos campos de configuração: SSLLib, CrypLib, HttpLib, XMLSignLib e SSLType ? Certificado A1 ou A3?

É 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 Marcio, Afinal de constas qual é o código IBGE correto da cidade em questão? Pois no arquivo Cidades você colocou: [4322509] Nome=Vacaria UF=RS Provedor=Pronim Por outro lado no arquivo Pronim esta desta forma: Produção ; Vacaria/RS RecepcaoLoteRPS_4308201=http://200.240.233.10:8082/NFSe.Portal.integracao.Teste/services.svc Homologação ; Vacaria/RS RecepcaoLoteRPS_4308201= http://200.240.233.10:8082/NFSe.Portal.integracao.Teste/services.svc As URLs de homologação e produção são as mesmas? Favor checar tudo isso.

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.

Bom dia Igor, Por favor não post como parte do texto o conteúdo de XML, procure sempre anexa-los. Pois da forma que esta, fica difícil de analisar o problema.

Dércio, De uma olhada na Nota Técnica 2017/001 versão 1.20 que encontra-se disponível no Portal Nacional da NF-e. Nela diz que se o produto não possuir o código de barras devemos atribuir "SEM GTIN" as tags <cEAN> e <cEANTrib>

Rodrigo, A mensagem da SEFAZ esta clara, você informou um CFOP de operação Interestadual, mas o idDest é diferente de 2, ou seja, para uma Operação Interestadual o valor de idDest tem que ser 2. Se você abrir o XML que você anexou na sua primeira postagem, vai ver que o valor informado é 1. Te aconselho a acessar o Portal Nacional da NF-e e baixar a versão 6.00 do Manual da NF-e, pois com o Manual fica mais fácil descobrir o que esta errado.

Gustavo, Eu promovi um Refactoring no componente ACBrReinf e testei a geração, assinatura, validação e envio de cada um dos eventos. Com exceção do evento 2070 se não me falha a memória, pois não temos o Schema correto, os demais funcionaram 100%. Além de baixar os fontes do ACBr, você reinstalou os componentes usando o ACBrInstall_Trunk2?

Bom dia, Pode ser algum problema no Ambiente Nacional, pois este é o responsável por recepcionar os eventos de Manifestação do Destinatário. Ao alimentar o componente, tentou em vez de passar o valor 91, passar o código IBGE da UF da nota que se pretende manifestar?

Bom dia Gustavo, Você esta com todos os fontes atualizados? Você esta usando o programa exemplo do ACBrReinf? Se sim, ele esta configurado corretamente?

Bom dia Rodrigo, Porque você esta preenchendo a tag <IEST>?

Bom dia Marcio, Exclua o seu arquivo Pronim.ini da pasta ...\ArqINI e baixa todos os fontes de todas as pastas novamente. Depois abra o arquivo Pronim.ini e inclua a URL de produção e de homologação da respectiva cidade. Feito isso faça um novo teste usando o programa exemplo. Estando tudo em ordem favor anexar novamente os arquivos para que possamos analisar e se tudo OK enviaremos para o repositório. Desde já muito obrigado pela colaboração.

Bom dia, O problema é que no XML não consta o CNPJ do Prestador de Serviço. Quanto a Discriminação é preciso fazer um ajuste pois a principio o componente busca pela tag <Discriminacao> e não pela tag <DiscriminacaoServico>