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?

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 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 Dércio, A nota esta sendo rejeitada pela SEFAZ ou é o componente que aborta o envio e acusa o erro? Se não me falha a memória no caso da versão 3.10 da NF-e a SEFAZ não valida o conteúdo das tags <cEAN> e <cEANTrib> ambas contem o código de barras do produto. Por outro lado na versão 4.00 da NF-e a SEFAZ valida o conteúdo dessas tags.

Bom dia Souza, Note que a nota de numero 203 esta sendo rejeitada e o motivo é duplicidade, isso significa que na SEFAZ já existe uma nota de numero 203 série 001.

Boa tarde Cristian, Favor confirmar se a cidade de Bagé/RS esta se utilizando da versão 1 ou 2 do provedor WebISS. Se for a 2, favor solicitar as URLs de Homologação e de produção.

Boa tarde Dércio, Realmente no manual consta a tag <ValorIssRetido> dentro do grupo <Valores> mas no Schema ela não existe. Se o componente gerar essa tag o RPS não será validado e consequentemente o envio será abortado.