EMBarbosa

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.

Acabei de descobrir: parece existir uma app para isso. Mas é limitado por acesso com certificado digital. Não tive tempo de procurar a documentação, mas o link é visível no site do SPED pelo menu SERVICOS -> ATUALIZAÇÃO DE TABELAS. https://www1.sped.fazenda.gov.br/AppManutencaoTabelas

Só precisa de gerar arquivo quando o roteiro falar especificamente de arquivo. Ou quando menciona-se Relatório Gerencial, correto? Muito obrigado! Até onde sei, não. Relatório Gerencial é impresso no ECF. Não em arquivo. Um requisito pode pedir Relatório Gerencial independente de arquivo, vice-versa ou pode pedir ambos. Mas uma coisa é uma coisa, outra coisa é outra coisa.

Só precisa de gerar arquivo quando o roteiro falar especificamente de arquivo.

Sim. A versão 2.0 do PVA está programada para ser lançada só em abril de 2012. Você provavelmente vai precisar fazer um Build nos componentes. Antes, verifique no Explorer se não está marcando algum dos arquivos como modificado ou como conflito. Se for o caso, é aconselhado fazer um checkout novamente... Por último, favor fazer o teste no DEMO.

Registro 60A sem registro 60M correspondente! Procure o motivo de você ter lançado registros 60A e não ter lançado o 60M do mesmo dia. É algum erro no lançamento/geração dos dados e não na montagem do arquivo.

O único algorítimo de validação que eu conheço de inscrição estadual de alagoas é o do site de sintegra: http://www.sintegra.gov.br/CAD_Estados/cad_AL.html Talvez você possa explicar o que seria a empresa tipo 2, visto que ela não se encaixa no seguinte: X – Tipo de empresa (0-Normal, 3-Produtor Rural, 5-Substituta, 7- Micro-Empresa Ambulante, 8-Micro-Empresa)

http://www.fazenda.mg.gov.br/noticias/U ... darios.htm

A propósito, se você tentar validar algum arquivo com 5 campos no PVA atual, mesmo que COD_INC_TRIB = codEscrOpIncCumulativo, ele vai falar que o arquivo está em formato errado e não vai nem importar para o PVA. Será necessário a versão 2.0 do PVA para poder validar os arquivos nesse modelo. Pensando nisso, fiz uma alteração no código só pra deixar isso mais claro. Espero que sane as dúvidas a este respeito.