Italo Giurizzato Junior

Bom dia Riquena, Muito obrigado pela colaboração, ainda hoje estarei enviando para o repositório.

Bom dia Geraldo, O erro ocorre em qual momento? Ao realizar a assinatura ou essa mensagem vem no retorno do envio?

Bom dia a todos, Favor atualizar os fontes e refaçam os testes. Notem que fiz alterações no arquivo INI do provedor ELv2.

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

Elias, Você tem os arquivos soap? *-env-lot-soap.xml de ambos, ou seja, dos que esta sendo aceito pelo provedor e do que não esta sendo aceito. Pois não achei nada que pudesse justificar o erro que esta ocorrendo.

Boa tarde Rodrigo, Se o emitente for uma transportadora, você não pode relacionar no MDF-e as NF-e e sim os CT-e, mesmo que seja apenas UM.

Boa tarde Tiago, Infelizmente não vou poder aceitar a sua contribuição, por dois motivos: 1. O seus fontes estão desatualizados; 2. Você não pode comentar linhas sem saber se isso não vai gerar um efeito colateral em outros provedores. Outra coisa, veja a sua implementação em : if Leitor.rExtrai(3, 'ValoresNfse') <> '' then As linhas que você adicionou elas já existem mais abaixo, não seria interessante colocar o provedor em questão em: if (FProvedor = proCoplan) then alterar para: if (FProvedor in [proCoplan, <acrescentar aqui o provedor>]) then Favor atualizar os fontes e repense a sua implementação.

Boa tarde Darlana, Qual é o motivo de emitir um MDF-e sem relacionar nenhum documento? Pelo que eu saiba tem que ter pelo menos UM documento informado.

Boa tarde José, Acredito que o problema seja esse: <CPFCNPJRemetente>00000000000000</CPFCNPJRemetente>

Boa tarde Elias Favor anexar o XML de envio de lote de um cliente que esta funcionando, para que possamos comparar com esse que você anexou.

Boa tarde Moreira, Fiz um teste atribuindo o valor libWinCrypt a SSLLib e o valor xsMsXml a XMLSignLib não ocorreu nenhum erro. O RPS foi assinado e o Lote também, o envio ocorreu sem nenhum problema. Como utilizei um certificado de uma empresa que não é de BH, logo ocorreu a rejeição informando que não foi possível realizar a autenticação.

Boa tarde Rodrigo, Você poderia implementar e anexar a unit alterada?

Boa tarde Tiago, Favor anexar a unit alterada para que possamos analisar as alterações.

Boa tarde a todos, Favor atualizar todos os fontes e façam novos testes.

Boa tarde Sergio, Favor entrar com a prefeitura ou com o provedor, pois pode variar a formatação dessa informação de um provedor para outro.

Boa tarde Joceandro, Muito obrigado pela colaboração, assim que possível vou enviar para o repositório.

Boa tarde Renato, Muito obrigado pela colaboração, assim que eu finalizar a implementação de leitura de arquivo INI no evento S1200, envio para o repositório a minha implementação e a sua alteração.

Elias, Favor entrar em contato com o provedor pois ante onde sei esse provedor estava funcionando 100% Quais são os endereços que você se refere que estão diferentes?

Tiago, Favor atualizar todos os fontes de todas as pastas. Note que fiz uma correção no arquivo ini do provedor bem como no schema. Refaça os testes.

Bom dia Renato, Será que esse enum a mais não se refere a nova versão ou a versão vigente do eSocial?

Bom dia Paulo, A cidade de Contagem/MG se utiliza do provedor Pronim, conforme consta no arquivo Cidades.ini Favor utilizar o programa exemplo para realizar os testes.

Tiago, Sendo assim, é preciso verificar se o problema é na leitura do XML da NFS-e ou na impressão do DANFSE.

Níssius, Onde foi feito essa alteração? Favor anexar a unit alterada.

Bom dia Elias, Muito obrigado pelo retorno, ainda hoje estarei enviando as devidas correções para o repositório.

Tiago, Chegou a abrir o fonte do DANFSE feito em Fast Report para ver o que esta errado?