EMBarbosa

Ué, no "Perfil C" vários dos registros do bloco C não devem ser informados mesmo...

Você também pode pesquisar no fórum antes. Visto que muitas das dúvidas inicias são as mesmas, isso vai lhe poupar as perguntas.

Então sugiro que envie um report para o pessoal da receita corrigir o erro. Veja o link Fale Conosco no site do SPED.

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.

Depois de apagar, se ainda não funcionar, lembre-se de fazer um Build no pacote Synapse.

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

pode. Pode usar até um componente para leitura do código de barras. Veja