EMBarbosa

Veja o campo 9 do registro 70 que é um registro relacionado: Fonte: http://www.fazenda.mg.gov.br/empresas/legislacao_tributaria/ricms_2002_seco/anexovii2002_6.htm

O que você acha de fazer justamente o contrário: Use a IdentificaPAF e não passe o MD5 para informações complementares?

Sim. Realmente usei mal as palavras e não é um memory leak propriamente dito. O que acontece é alocação de memória que não vai ser utilizada. Isso não causa impacto pois um TRegistro0111 é bem pequeno. Peguei o componente pra olhar, mas aí surgiram alguns problemas aqui, que vou ter que verificar antes...

O Alexandre mencionou que o ACBrSPED fazia apenas o teste de if Assigned(Reg0110.Registro0111) e disse que assim vai gerar sempre. Então me parece que está errado. Se o usuário não criou o registro0111 o ACBrSPED não deve criá-lo sozinho já que não é um registro obrigatório. Vou verificar e dou um retorno.

Sobre o I/O ERROR 32 Tradução: O processo não pode acessar o arquivo porque ele está sendo usado por outro processo. fonte:http://msdn.microsoft.com/en-us/library/windows/desktop/ms681382%28v=vs.85%29.aspx

Olá Ivan, Anexe os arquivos alterados para ficar mais fácil para o Daniel analisar e fazer o merge.

Acho que o CST tem mesmo que ser STRING, conforme proposto nesse seguinte tópico

Se o componente está gerando um Registro 0111 sempre e ele pode não ser obrigatório, então temos um vazamento de memória indesejado (memory leak).

Olá Ezequiel, Estive relendo essa parte do guia prático. Aliás, a versão disponível o site do SPED é a 1.0.9 e não 1.0.10... Enfim, relendo a parte do A100, não ficou claro que notas de terceiros canceladas deveriam ter os dados do terceiro informados como você sugeriu. Veja novamente: Essa regra não parece se limitar a notas próprias, mas sim sobre todos os documentos cancelados. Já a segunda parte que você citou fala sobre como detectar dois registros repetidos e não afirma nada sobre registros cancelados. Então acho que, a menos que o PVA valide sua alteração, você não deveria fazê-la. Você corre o risco de transformar um arquivo válido em inválido ao enviar para o fisco. Finalmente, admito que também tive a mesma impressão a princípio que você. Se esses campos são considerados "formadores da chave de registro" eles deveriam ser obrigatórios sempre que se aplica. Mas a situação parece apontar justamente para o outro ponto de vista.

Ronaldo, o Régys quis dizer que ele já enviou pro SVN.

Você fez um SubtotalizaCupom antes de lançar os pagamentos?

Sim. Seria possível. Exigiria uma refatoração total do código. Poderia se usar classes abstratas ou interfaces também. Só não sei se seria viável levando em conta o número reduzido de usuários do ACBr que participam fazendo o desenvolvimento.

Exatamente por causa dessas diferenças deixar em código separado facilita na hora de dar manutenção do código. Se a receita levasse os dois projetos como um projeto apenas, juntar os códigos seria muito bom. Mas ela trata o SPED Fiscal, PIS/COFINS e etc, cada um como um projeto separado. Cada um tem seu Guia Prático, e cada um tem seu próprio validador. Cada um tem uma legislação pertinente e as vezes os mesmos registros tem formatos diferentes pra cada projeto como você mesmo constatou. Já aconteceu deles mudarem um registro em um e só meses depois mudar no outro, isso quando mudam. Assim, não dá pra tratar o código como o mesmo, quando na prática, os registros não são tratados como os mesmos.

Não possui no momento.

Não, provavelmente eu é que não me fiz entender corretamente. "Testar com o DEMO" não quer dizer abrir o DEMO e apertar um botão esperando que o arquivo será gerado de forma a ser validado de acordo com as últimas regras de validação e exigências do fisco. Significa que você deve conseguir reproduzir a mesma situação usando o código do DEMO ou fazendo as alterações nele, visto que ele é o que temos em comum. A não ser que você queira enviar o código fonte do seu aplicativo e seu banco de dados para terceiros para que consigamos reproduzir o erro e debugar seu aplicativo.

ou do guia prático...

Até onde eu me lembro, só é permitido se você trabalhar com múltiplos cartões. Mas normalmente isso fica bem claro no guia.

Se quiser alterar o código e anexar aqui no fórum a gente pode analisar.

Se não me engano, o inicializaGeração deveria limpar os registros. Você consegue reproduzir o problema com o Demo? Você está usando o SaveFileTXT no final da geração?

Se você conseguir descobrir o motivo do problema você consegue mudar. Mas eu aconselharia você atualizar seu PAF-ECF para a versão 7 do Delphi. Isso seria muito menos trabalhoso que mudar para o Delphi XE, e lhe garantiria a compatibilidade de praticamente todos os componentes que você usa atualmente, especialmente o ACBr.

Aplicativos Farmácia Popular não precisam passar por homologação PAF-ECF. Existem requisitos que se contradizem.

Olá Allan, esse tipo problema já foi discutido aqui algumas vezes. Não é preciso ter mais de um bpl para acontecer o erro, mas é que a versão da bpl que um Delphi acessou foi compilado por outra versão do Delphi. Assim toda vez que um funciona, o outro para de funcionar. Se procurar aqui no fórum por "Não foi possível localizar o ponto de entrada do procedimento" vai encontrar um bom número de posts.

E o que deveria ser feito?

De onde você leu isso?

Voltaram a colocar o link no site.