elton.barbosa

Não tem uma regra no Discado dizendo que o cartão sempre deve ser a última forma de pagamento?

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

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.

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.