Italo Giurizzato Junior

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

Beto, A mensagem de erro significa que o código do município apresentado não consta no arquivo Cidades.ini Verifique se esse arquivo não contem uma bolinha vermelha em seu ícone. Se tiver significa que ele foi alterado e portanto pode não ter sido atualizado pelo Tortoise.

Boa tarde Gabriel, Se você configurar o componente com o certificado digital, não se faz necessário o uso dos serviços de Login e Logout. Agora se não configurar o componente com o certificado, será necessário usar realizar o Login antes dos demais e por fim executar o Logout.

Boa tarde Orlando, Boa pergunta, mas lendo a NT temos o seguinte: Geração automática do CIOT, pelo Sistema MDF-e, tanto para as modalidades TACIndependente como TAC-Agreg No meu entendimento não vai ser necessário informar o CIOT no XML, pois ao enviar o MDF-e o CIOT vai ser gerado automaticamente par aquele MDF-e e vinculado ao mesmo, como uma espécie de evento gerado pelo próprio Fisco.

Boa tarde, Deixe a IE do remetente em branco em vez de colocar a palavra "ISENTO".

Boa tarde Reinaldo, Vamos verificar o que esta ocorrendo e a correção com certeza vai estar na próximo versão do ACBrMonitor.

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.