EMBarbosa

Parabéns. Bom trabalho.

Pois é, se houver retorno ou dúvidas a gente pode investigar. Mas não estou lembrado de nada no momento. Penso por alto, me vem duas coisas à mente que poderiam dar problemas: 1) A biblioteca Synapse, para acesso a porta paralela. Que não me lembro se estava bem testada para 64 bits. 2) Algum acesso/alocação/liberação à memória, arquivo ou algum protocolo que seja feito em bloco de bits. Mas como disse, o melhor seira talvez compilar e executar todos os DEMOS e verificar se o retorno de todos é igual ao deles compilados para 32 bits. É trabalhoso, mas não precisa de muito conhecimento técnico dos componentes.

Deixa ver se entendi. Quer dizer que o validador do Linux não conseguiu validar o arquivo mas o do Windows validou o arquivo corretamente?

No momento essa funcionalidade não existe.

Integração com xml não tem nada ainda... O ACBrSintegra apenas é um componente para ajudar a gerar o arquivo no layout correto.

A não ser que seja proposital, memory leaks não são normais.

Ei Gr@ç@, não tivemos nenhum retorno sobre isso ainda. Eu acredito que se houverem os problemas sejam muito poucos. A ideia seria alguém começar compilando os DEMOS e fazer testes neles. Não sei se alguém já fez isso.

Eu ia sugerir você verificar justamente se o arquivo não foi salvo com codificação UNICODE ao invés de ANSI. Isso costuma atrapalhar...

O link não está abrindo aqui.

1. Se você analisar bem, o local específico para informar esses dados é a função "IdentificaPAF". 2. Conforme dito pelo Daniel, "IdentificaPAF" fará todo controle.

Você é quem tem que definir o comportamento do seu aplicativo quando ele inicia e implementar concordemente. Alguns cancelam o cupom, outros recuperam o cupom, outros dão a opção para o usuário escolher. Independentemente da escolha, você precisa fazer a verificação do estado do ECF e do último cupom.

Pelo que vi do Ato COTEPE, eles são obrigatórios caso ocorram (OC). Assim, não é a UF que determinaria, mas sim se seu cliente faz uso desse recurso. Talvez o melhor seja ver com um contador experiente em quais circunstâncias se utilizam esses recursos descritos e daí verificar se será utilizado ou não...

NFG - Nota Fiscal Gaúcha - é, pelo visto, a implantação do projeto Nota Fiscal Paulista lá.

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.