Angelo Gomes

Não, re-leia a segunda postagem que o André fez nesse tópico.

Uso MDI Forms, aquele que os forms filhos abrem dentro do form principal. No menu da tela principal, tenho o item que abre o menu fiscal, ficando assim acessível a todo o momento. Já homologuei e foi aceito dessa forma.

Mais alguém enfrentando o problema da troca do provedor da cidade de Ponta Grossa de fintelISS para Elotech?

Se eu fosse você, corrigiria e faria o teste, muitas vezes vem uma mensagem de erro sem ligação com o real erro, principalmente qdo é um erro de estrutura do XML, como esse caso.

Se vc fala que "eventualmente" ele tenta gravar no C:, quer dizer que eventualmente a propriedade PathSalvar está em branco. Em que momento você informa o caminho para ela? Eu informo logo que crio o componente em tempo de execução e nunca tive esse tipo de problema.

Meus XMLs de retorno sempre são geradas na pasta que especifico. Minhas configs estão assim: ACBrNFe1.Configuracoes.Geral.Salvar := true; ACBrNFe1.Configuracoes.Geral.PathSalvar := 'c:\Temp\';

Pq no teu XML não tem o item 1??

fpCartaoCredito e fpCartaoDebito aceita sim. Qual o erro?

Teste bobo, mas ao rodar o Delphi, já tentou clicar com o direito, Executar como Administrador?

Não sei se em todas as cidades são assim, mas aqui na minha quem controla a numeração da NFS-e é o sistema da prefeitura, depois de enviar, eu pego o número no retorno e guardo no meu banco.

Eu testo o código de retorno (100 Autorizada, 105 Em processamento, etc.. ) e tem funcionado perfeitamente.

Já estamos descutindo esse problema neste tópico: com vc, já é a terceira prefeitura diferente que ocorre o problema. Infelizmente não consegui descobrir aonde acontece o erro, pra tentar arrumar.

No outro tópico que tinha criado antes de ver que aqui já estava sendo discutido o assunto, tem mais um usuário que está com o mesmo problema: Infelizmente me faltou conhecimento pra prosseguir e descobrir em que momento perde a referência para o FIdentificacaoRps.

Qual é a cidade e provedor que vc usa?

continuei a debugar os destroys, e cheguei num ponto que o Akai comentou ali acima. No meu caso, qdo faço uma segunda consulta por RPS, o componente cai duas vezes no TNFSe.Destroy (fonte pnfsNFSe), a primeira vai ok, na segunda, dá o acess violation no FIdentificacaoRps.Free; qdo comenta aquela linha, ele não passa a segunda vez pelo TNFSe.Destroy, mas é uma solução tosca, afinal ele chama mais coisas que podem ser importantes.