EMBarbosa

Também não entendi. Qual o objetivo de alterar o Path para C:\ ao invés da pasta do programa?

Obrigado Régys!

Olá Régys, Percebi que o comando FechaCupom faz um InfoRodapeCupom.Clear no seu final. Isso apaga os dados do MinasLegal. Duas perguntas: Porque isso é necessário? Qual seria a melhor hora então para "reabastecer" o InfoRodapeCupom com os dados?

O melhor método é você limitar o tamanho dos campos antes de passar ao componente. Isso impede que ele utilize mais memória do que o necessário ao criar os registros e você não terá esse problema.

Por favor tente reproduzir o problema usando o código do DEMO.

Que bom que resolveu!

Ebnezer, Não seria o contrário? RegistroValido:=true quando for 0: não alterado?

Então, para o suprimento você deve usar o comando de Suprimento. Para Leitura X, LeituraX. Mas, até então, o ACBr não tem esse método de geração de Registros Tipo60 do Sintegra. Mesmo porque, esse tipo de método utilizando o ECF não é aceito pelo fisco para homologação PAF. Você deve ser capaz de gerar esses arquivos do seu banco de dados.

Beleza então. Olhando por alto, não consegui detectar nenhum problema diretamente no seu código. Então, sugiro colocar um breakpoint na execução do seu código para verificar se não estão sendo criados duas vezes o mesmo registro. Coloque o breakpoint por exemplo na linha que cria o registro 0140 ou na próxima depois dela (COD_EST := IntToStr(int0140)). Quando parar ali você pode verificar o quantas vezes ele está gerando o registro.

Sim, teria que fazer a procura por string, mas o uso de RTTI resolveria todo esse problema para você (ou pra mim...) Agora acho que você não entendeu o problema que eu citei. Vou tentar dar um exemplo: Hoje, o cst icms para Outros é 090. Se a legislação mudar por algum motivo obscuro para 099 todo o seu banco de dados vai estar errado. Não vai mais conseguir gerar os arquivos corretamente. Acha isso estranho? Eu também acho. Impossível? Não mesmo. Veja o caso do campo IND_PGTO do registro C100 no SPED Fiscal ou o campo IND_FRT no registro C100 do SPED PisCofins. Além disso, veja o caso desse tópico viewtopic.php?f=22&t=4448 Como mencionei antes, concordo que não é fácil alterar isso depois do projeto já em execução. Talvez pareça deselegante também. Eu mesmo admiti que não tenho feito assim. Mas parece ser o melhor método de resolver os problemas citados sem dores de cabeça futuras.

Você pode usar o Delphi 7 ou superior. Ou o Lazarus.

O que esse comando faz, você sabe?

Se você usa só um estabelecimento você deve remover o for ... do que cria os registros 0140. Usar um loop para criar apenas um registro é anti-pattern. Verifique se isso resolve. Observe também se os dados não estão sendo duplicados na sua Query ou se não está sendo executada a função que cria os registros duas vezes.

No DEMO funciona? Qual o seu código? Você observou que o código do DEMO é gerado para empresas com 2 estabelecimentos?

Não precisaria de função alguma. O Delphi já faz isso por meio da RTTI. Com respeito ao banco, acredito que não seja uma perda tão grande como parece. Pelo menos nos BD que eu utilizei, não vi perda tão significativa. Qualquer outra solução esbarra nos problemas que apresentei no post anterior. EDIT: A propósito, exceto se você for utilizar RTTI, tipos enumerados não precisam ter nomes pequenos. Não faz diferença pois internamente o compilador trata eles como valor inteiro que é, em geral, de no máximo 256 valores (SmallInt). O que o Isaque fez foi diminuir o tamanho dos tipos com o objetivo principal de facilitar aos novos usuários do ACBr detectarem qual é o tipo específico para o campo que eles estão procurando.

A melhor saída mesmo seria armazenar um string com o tipo enumerado ao invés do valor do tipo ou do valor da ordenação. Por Exemplo: armazenar para o campo CST_PIS do registro C170 'stpisOutrasOperacoesSaida' ao invés de '49' ou '10'. Isso porque infelizmente a legislação já alterou antes os valores de campos e nada pode garantir que não venha a fazer isso outra vez; além disso, os tipos podem sofrer alterações devido a alguma necessidade (incluir uma enumeração nova por exemplo). Mas eu concordo que é a maneira mais difícil de implementar. Eu mesmo não a estou utilizando no momento, pois não achamos que passaríamos por esses tipos de problemas no início do projeto.

Depende do arquivo. O requisito XXV que você mesmo citou menciona como nomear o arquivo gerado naquele requisito. O item 9 do Requisito VII também tem especificação. E assim por diante. Os que não forem especificados você pode assumir qualquer jeito de nomear os arquivos. Veja no ROTEIRO DE ANÁLISE FUNCIONAL DE PROGRAMA APLICATIVO FISCAL - EMISSOR DE CUPOM FISCAL (RAFPAF-ECF) a pergunta 15 nas últimas páginas seção PERGUNTAS E RESPOSTAS.

Eu não entendi sua pergunta.

Realmente. O CancelarNaoFiscal não cancela CCD. (pelo menos nos ECF da Bematech)

O Isaque está trabalhando em algo assim, mas ainda não existe esse tipo de função no ACBrSPEDPisCofins. Acho que será útil se você entender o objetivo dessa função que você estava tentando usar. Veja esse tópico:

Acho que o que você deseja é o ACBrECF.CancelaNaoFiscal. Isso mesmo?

Verifique o que o Régys mencionou. Se não resolver, reinstale os componentes, fazendo Build em todos os pacotes

Verdade. É exatamente o que eu penso. É preciso fazer, mas não dá pra fazer de uma hora para outra pois já existem algumas coisas que precisamos verificar. A não ser que encontrássemos mais voluntários para ajudar nessa tarefa específica.

Corrigi na revisão 3315

Não se pode simplesmente ignorar esses warnings. Essa diferença entre Ansi e UTF8 é fonte de várias incompatibilidades. Na verdade, o fonte do ACBr está como AnsiString em vários locais justamente por dar problemas nas novas versões do Delphi, e não por dar problemas no Delphi 7. Na minha opinião, é melhor levar em conta e investigar como o Daniel mencionou.