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.

Akai e Italo, no meus testes com o Demo, consegui eliminar o erro na segunda Consulta por RPS e o erro de ponteiro inválido qdo fechava o programa comentando a seguinte linha: FCompNfse.Free; na procedure TListaNfse.Destroy, no fonte pnfsConsNfseporRpsResposta. Agora não sei o que isso pode influenciar no resto do componente. Consegue fazer esse teste ai Akai, pra ver se resolve pra vc tbem?

Akai e Italo, eu estou com problema parecido, em um luga diferente, até tinha aberto um tópico, mas depois li as mensagens aqui: Assim como no problema que o Akai relatou, é na hora de dar o Free tbem.

Olá pessoal. Estou com um problema, tanto no meu software como no Demo. Ao consultar uma NFSe por RPS pelo segunda vez, ocorre um acess violation nas linhas: if Assigned(NFSeRetorno) then NFSeRetorno.Free; na função TNFSeConsultarNfseRPS.Executar, linha 3274. Trabalho com a prefeitura de Ponta Grossa, provedor FintelISS. Obrigado.

Ok obrigado Régys.

Então... nesse caso do meu exemplo, no R04 iria cupons com data 01/02 e 02/02, para a redução Z com data de movimento = 01/02... confere?

Olá Régys, concordo que é uma boa solução, faço de forma parecida pra Redução Z, mas não para o cupom. Só que dai me surge a dúvida, no campo 08 do registro R04 está assim "Data de início da emissão do documento impressa no cabeçalho do documento". Nesse cupons impressos no período de tolerância, a data impressa é a data de emissão, não a de movimento né? ou estou errado?

Sim, o problema acontece nos totalizadores, pois os totais contêm os valores daqueles cupons emitidos entre a meia noite e duas da madrugada do dia seguinte (periodo de tolerância). Em teoria, teria que aparecer tbem os cupons emitidos nesse período. No SPED Fiscal, está explicito isso no texto do manual, na legislação do PAF não achei, por isso queria ver como alguém resolveu isso.

Olá pessoal, tenho uma dúvida: Estou emitindo cupom no dia 01/02 por exemplo, e passa da meia noite e continuo emitindo cupons até aquele periodo de tolerância de duas horas. Quando eu for montar o arquivo do Registro R, devo selecionar tanto os cupons com data do dia 01/02 como também os cupons com data de 02/02 que foram emitidos dentro do periodo de tolerância? A minha lógica me diz que seria o procedimento correto, mas não achei nada especificado na legislação No caso de afirmativo, claro q não usaria mais as datas mas sim a informação de coo inicial e final. Obrigado.

Elton, no ato cotepe a ordenação do R07 está: Nº de fabricação, Modelo, Nº do usuário, COO, GNF ou CCF e Meio de Pagamento. (link: http://www.fazenda.gov.br/confaz/confaz/atos/atos_cotepe/2008/ac006_08.htm) Pra mim o COO está vindo fora de ordem tbém, e foi questionado na nossa pré homolagação. Não consegui baixar os fontes que foram postados nesse tópico, para ver se resolviam o problema.

Verifique se vc esta passando corretamente o caminho para tua pastas de Schemas, e se os Schemas estão atualizados com os arquivos para manifestação de destinatário.