Italo Giurizzato Junior

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

Bom dia Niron Me parece que a configuração do Monitor no que diz respeito ao e-Social esta errado, veja: [eSocial] IdEmpregador=27510211000120 IdTransmissor=96452234668 TipoEmpregador=tePessoaFisica O Empregador não seria uma Pessoa Jurídica, uma vez que você informou o CNPJ do mesmo?

Bom dia, Favor checar com o provedor Actcon se a cidade de Ipatinga/MG esta se utilizando do webservice que segue a versão 2 do layout da ABRASF.

Boa tarde Fernando, Muito obrigado pela colaboração, assim que possível vou analisar a sua contribuição.

Boa tarde, Se você se refere a cidade Feliz/RS, ela já consta na nossa lista, veja: No arquivo Cidades.ini temos: [4308102] Nome=Feliz UF=RS Provedor=Pronim Isso significa que essa cidade se utiliza do provedor Pronim. Favor usar o programa exemplo do componente para realizar os testes.

Boa tarde a todos, Estão usando o arquivo infisc.ini que se encontra na pasta: ...\Exemplos\ACBrDFe\ACBrNFSe\ArqINI ?

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

Boa tarde Claudnei, Esse problema esta sendo discutido nesse outro tópico: Vou fechar este para não ficarmos com dois tópicos tratando sobre o mesmo assunto.

Boa tarde Wagner, Se o XML foi gerado, assinado, validado e enviado, me responda qual é a necessidade de gerar novamente o XML caso ocorre algum erro de conexão? Só devemos gerar novamente caso o conhecimento seja rejeitado pela SEFAZ, ai sim, você gera o XML novamente com as devidas correções, caso contrario não. O conhecimento foi enviado, ocorreu erro de timeout por exemplo, qual é o procedimento? 1. Carregar o XML através do LoadFromFile; 2. Executar o método Consultar; Se o conhecimento realmente foi enviado para a SEFAZ e esta processou com sucesso, ao consultar será retornado o protocolo de autorização e o mesmo será incluído no XML, deixando-o completo, ou seja, assinado e protocolado. Agora se ocorreu algum problema, será retornado a rejeição, neste caso conforme já descrito acima, devemos corrigir a informação errada, gerar novamente o XML e enviar. E temos o caso de ao consultar retornar que o conhecimento não existe na base de dados, neste caso, devemos simplesmente enviar novamente.

Boa tarde, Verifica se o componente esta usando tanto o arquivo Cidades.ini e o Actcon disponibilizados na pasta: ...\Exemplos\ACBrDFe\ACBrNFSe\ArqINI Outro detalhe importante os schemas a serem utilizados são os disponibilizados na pasta: ...\Exemplos\ACBrDFe\ACBrNFSe\Schemas\Actcon

Boa tarde a todos, Junior, tem alguma coisa errada e não consegui descobrir analisando os fontes, pois se esta trazendo o numero do maxNSU deveria também trazer o numero do ultNSU.

Boa tarde, Lembre-se que a NFS-e é uma ZORRA com todas as letras, pois tem provedor que é preciso assinar somente o RPS, outros somente o Lote, outros devemos assinar tanto o RPS quanto o Lote e tem aqueles que não precisa assinar nada. Mesmo não precisando assinar nada, temos a questão do acesso ao webservice, com certeza tem provedor que se faz necessário ter o certificado e outros não. Com certeza absoluta é possível emitir NFS-e sem ter certificado digital, desde que seja via SITE e não via webservice.

Bom dia Alex, O DistribuicaoDFePorUltNSU se utiliza do DistribuicaoDFe, logo é para trazer o mesmo resultado. Com relação do retorno do UltNSU, com certeza se trata de alguma modificação que foi feita que não esta pegando o valor. Vamos analisar o problema.

Bom dia, Muito obrigado pela colaboração. Vou aguardar para enviar a implementação completa.

Bom dia Fabio, Mas segundo o Schema de validação do Lote a tag Alíquota é com 4 casas. Você tem os novos Schemas do Pronim? A remoção do Encoding pode ser feita no arquivo Pronim.ini, trocando o valor 1 por zero: [Recepcionar] IncluiEncodingCab=0 IncluiEncodingDados=1 <=== mudar para zero

Daniel, Estou seguindo os Schemas referente a versão 2.00, pelo jeito o webservice não esta aceitando ou as URLs para a versão 2.00 são outras. Você poderia entrar em contato com eles e solicitar as URLs e um XML exemplo de envio para que possamos comparar?

Bom dia Wagner, Se esta ocorrendo o erro de DigestValue não confere isso significa que você o XML foi gerado novamente e provavelmente com data/hora de emissão diferente do primeiro que foi enviado ou outra informação.

Daniel, Favor atualizar os fontes e faça novos testes.

Bom dia Daniel, Se colocar o atributo versão para informar que a versão é 2, ocorre o erro que esse atributo não existe, se retira o webservice entende que o XML é da versão 1 e logo não reconhece a tag uf_favorecido. Esta difícil entrar em um acordo com esse webservice, deve estar faltando mais alguma coisa. Voltando a prancheta.

Bom dia Rodrigo, Antes estava funcionando sem nenhum problema? Se sim, tente comparar o XML de envio que foi aceito com o de agora que esta sendo recusado.

Ricardo, Fico feliz por ter encontrado a solução e ter compartilhado. Sem duvida, é compartilhando que todos crescem.

Bom dia Jose, Quando isso ocorre, ou seja, o XML é enviado e é autorizado mas fica sem o protocolo de autorização, a solução é simples: 1. Carregar o XML assinado através do método LoadFromFile; 2. Executar o método Consultar.

Bom dia Ricardo, Como assim "nossa comunidade é muito egoísta"? Quem você se refere? Ao pessoal do fórum ou aos desenvolvedores de aplicações para transportadoras? Pelo que notei o problema é a SEFAZ-PR, pois ninguém de outra UF esta passando pelo problema que vocês estão. Sendo assim a minha sugestão é que vocês entrem em contato com a SEFAZ-PR e expõe o problema.

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

Bom dia, Eu também tenho esse problema, ao aparecer essa mensagem de erro, favor clicar no botão [No]. Estamos investigando a fonte desse erro.