Italo Giurizzato Junior

Boa tarde, Neste caso sugiro que você entre em contato com o provedor e questione sobre o erro.

Beto, Você baixar os fontes através do Tortoise, garante que os fontes estão atualizados. Mas devemos sempre reinstalar a suíte ACBr utilizando o ACBrInstall_Trunk2. Desta forma garantimos que ao compilar a nossa aplicação ela vai estar usando tudo o que foi alterado nos componentes.

Boa tarde Beto, Você esta com todos os fontes de todas as pastas atualizados? Se sim, reinstalou a suíte ACBr? No seu cliente você copiou os arquivos Cidades.ini e SimplISSv2.ini ?

Boa tarde João, Muito obrigado pela colaboração, ainda hoje vou enviar para o repositório. Atenção: os seus fontes estão desatualizados.

Boa tarde Adriano, A mensagem de erro ocorre ao enviar o lote, veja o final da URL .../recepcionarLoteRps?wsdl Essa URL se refere ao envio do lote cujo serviço se chama recepcionarLoteRps. O problema não esta na consulta e sim no envio ou no retorno que contem o numero do protocolo que atesta que o lote foi recebido pelo webservice. Se em outros clientes esta funcionando, podemos descartar o provedor e a sua aplicação, logo o problema é local. Se ao executar a aplicação no cliente em uma maquina que não tem antivírus o problema pode ser a conexão de internet que ele tem que pode estar barrando o retorno do webservice. Como é feita a conexão com a internet? Como é distribuída a conexão da internet para as estações de trabalho?

Olá Pessoal, Para o provedor ISSNet é utilizado um série especifica para cada cidade. É necessário solicitar uma faixa de numeração de RPS (por exemplo: 1-1000) antes de começar a emitir as notas. Quando terminar de usar a faixa solicitada se faz necessário solicitar outra faixa (por exemplo: 1001 - 2000). Para liberação dos documentos de Recibo Provisório de Serviços (RPS) é necessário acessar o Sistema ISS.Net Online de seu município e solicitar através do menu Solicitação de Documentos Fiscais --> Solicitação. Essa liberação é feita diretamente pela Prefeitura. Aqui tem mais detalhes sobre o erro e a solução também: https://basepro.com.br/wfenix//index.php?title=E004:_Esse_RPS_não_foi_enviado_para_a_nossa_base_de_dados._Número_do_RPS_em_que_ocorreu_o_erro:_1001

Boa tarde Thiago, O erro 403, pelo que me recordo, significa que não foi possível consumir o webservice, geralmente é devido ao certificado. Você esta usando o programa exemplo? Qual é a configuração no que diz respeito ao SSLLib e demais campos abaixo?

Boa tarde Felipe, Muito obrigado pela colaboração, já vou enviar para o repositório.

Bom dia Gabriel, Você esta usando o programa exemplo do componente para realizar esses testes?

Em produção, tente o código IBGE que é 5208707.

No arquivo Cidades.ini temos a cidade de Goiânia/GO incluída 2x. Uma com o código IBGE 5208707 e outra com o código 2530000. Não me recordo se esse código 2530000 devemos utilizar para envio em ambiente de homologação e o outro para o de produção. Fiz um teste agora, para ambos os códigos estou recebendo timeout tanto no ambiente de homologação quanto de produção. Já aumentei o timeout para 10 mil, mas não resolveu. Se enviar com o código 2530000 ou 0025300 ocorre o mesmo erro? Para qual ambiente você esta enviando?

Bom dia, Chegou a comparar o XML do RPS gerado antes da atualização com o gerado após a atualização? Fazendo essa comparação, você vai descobrir o que foi alterado e com isso podemos verificar o que ocorreu.

Bom dia Valdir, O bloco de código abaixo: // Somente o provedor SimplISS permite infomar mais de 1 serviço with Servico.ItemServico.Add do begin codLCServ := '123'; Descricao := 'SERVICO 1'; Quantidade := 1; ValorUnitario := 15.00; ValorServicos := Quantidade * ValorUnitario; end; Não deve ser utilizado pelos provedores que seguem "a risca" o layout da ABRASF. Porque coloque a risca entre aspas, simples, todos os provedores que seguem o layout da ABRASF seja a versão 1 ou 2 sempre fazem alguma alteração. A alteração mais profunda (vamos dizer assim) é a permissão de incluir mais de um item de serviço. Por via de regra você deve alimentar os campos referente ao grupo serviço e utilizar esse somente para os provedores que permitem informar mais de 1 serviço como é o caso do provedor SimpISS que por sinal "segue" a versão 1 do layout da ABRASF. Por outro lado esse provedor possui um outro webservice que chamamos de SimplISSv2 pelo fato de seguir a versão 2 do layout da ABRASF e nesse devemos informar somente 1 serviço. Quando configuramos o componente com o código IBGE do emitente o componente faz das tripas o coração para poder gerar o XML do RPS conforme deve ser gerado. Não é a toa que o ACBrNFSe possui centenas de IF e CASE espalhados pelos seus fontes.

Bom dia Rene, Infelizmente o manual da ABRASF é pobre em informações. A minha sugestão é que você emita a nota via site e depois baixe o XML da mesma quem sabe você encontra alguma coisa que possa lhe ajudar. Lembre-se que o XML do RPS não é exatamente igual ao XML da NFS-e, mas como disse acima, pode ser que você encontre algo que possa resolver o problema. Dentro do grupo <Serviços> temos as tags <CodigoMunicipio> e <MunicipioIncidencia> em ambos você informou o código IBGE da cidade do tomador que é onde o serviço vai ser realizado. Você já tentou informar em <CodigoMunicipio> o código IBGE do Emitente e em <MunicipioIncidencia> o do Tomador? Se sim, tente informar de forma invertida.

Bom dia Cesar, Temos um novo grupo no MDF-e chamado <infPag> que se refere as informações do pagamento do Frete, como o schema permite "N" ocorrências isso significa que esse grupo poderá aparecer mais de uma vez no XML. No meu entendimento só devemos informar esse grupo mais de uma vez quando parte do pagamento for realizado por um responsável e parte por outro. Temos também um evento para registrarmos as informações sobre o pagamento do Frete e como consta na NT, isso significa que o pagamento será realizado de forma tardia. Entendo que primeiro o transporte será realizado para depois realizar o pagamento. Quando incluímos as informações sobre o pagamento do Frete no MDF-e, isso significa que o pagamento do mesmo vai ocorrer antes do transporte. Como o NT não deixa muito claro, foram essas as minhas conclusões.

Paralisação dos ambiente de Homologação e Produção da NFC-e Produção Prezados contribuintes, Em função de manutenção necessária no ambiente de processamento do NFC-e, o ambiente de produção ficará indisponível no período de 18/02/2020 23:59h até 19/02/2020 01:00h. Homologação O ambiente de homologação ficará indisponível no período de 19/02/2020 17:00h até 20/02/2020 08:00h. http://www.sped.fazenda.mg.gov.br

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

Boa noite, Já enviei a correção para o repositório.

Boa noite Edmar, Primeiramente desculpa pela demora, mas analisamos e esta tudo ok, já foi enviado para o repositório.

Boa tarde Melissa, Por favor leia essa noticia:

Olá Pessoal, Ocorreu uma alteração no salvamento dos arquivos de envio e de retorno dos eventos e da inutilização. O motivo dessa alteração foi que esses arquivos estavam sendo salvos em dois lugares distintos. No caso dos eventos eles estavam sendo salvos na pasta configurada em PathEvento e em PathSalvar. Já os de inutilização estavam sendo salvos na pasta configurada em PathInu e em PathSalvar. Com a alteração os arquivos de envio e de retorno passam a ser salvos somente na pasta configurada em PathSalvar. Por outro lado, o resultado final do processamento dos eventos bem como da inutilização, ou seja, os arquivos *-procEventoNFe.xml (no caso da NF-e) e o *-procInutNFe.xml (no caso da NF-e) vão continuar sendo salvos nas pastas configuradas em PathEvento e PathInu respectivamente. Desta forma fica fácil para o desenvolvedor pegar por exemplo todos os XMLs referente aos cancelamentos (pasta ...\Evento\Cancelamento) compactar e enviar para a contabilidade. Antes era preciso excluir os arquivos de envio e de retorno para que estes não fossem incluídos no arquivo compactado. Quero lembrar a todos que essa alteração foi realizada nos componentes: ACBrBPe (Bilhete de Passagem Eletrônico), ACBrNF3e (Nota Fiscal de Energia Elétrica Eletrônica), ACBrCTe (Conhecimento de Transporte Eletrônico), ACBrMDFe (Manifesto de Documentos Fiscais Eletrônicos) e ACBrNFe (Nota Fiscal Eletrônica).

Bom dia, Vou verificar. Comente a linha que contem o "break;" dentro do loop que salva o XML da guia. E faça novos testes.

Bom dia Leandro, Muito obrigado pela colaboração, já foi enviada para o repositório. Favor atualizar os fontes e faça novos testes.

Bom dia Rodrigo, Muito obrigado pela colaboração, já enviei para o repositório. Favor atualizar os fontes e faça novos testes.