Rodrigo Coelho

Sim, eu fiz a correção usando o Trunk2

Sim, também resolve. Obrigado.

Outra coisa que tive que fazer, porém não sei se fiz corretamente. Os registros 1102 e 1502 só devem ser gerados caso a CST_PIS/COFINS estiverem entre estas: 53,54,55,56,63,64,65,66 Caso os registros 1101 e 1501 tiverem CSTs diferente dessas, não deverá ser gerado o registro 1102 e 1502. Porém verifiquei que estes já são criados no método Create do 1101 e 1501, fazendo com que os métodos Write... gerem esses registros. Tentei fazer na minha rotina de leitura para destruir o Registro1102 e Registro1502, caso não atendesse as CSTs, porém na hora de gerar o arquivo estava dando erro (Null pointer exception). Então fiz a alteração no código ACBr, e funcionou. Como disse não sei se fiz da forma correta. Então peço que analisem minha sugestão em anexo. ACBrEPCBloco_1_Class.pas

Desculpe. Foi erro meu. A classe de geração do bloco C já trata isso. Eu é que não estava informando a DT_INI e DT_FIN para o componente.

Fiz uma correção na leitura do registro P200 que não estava lendo um último campo do registro. Veja o anexo. ACBrEPCBloco_P_Importar.pas

Tive que fazer uma alteração de tipos desses dois blocos. Alterei para variant, pois na documentação diz que os valores só devem ser informados conforme a regra seguinte: Campo 02 - Preenchimento: informar o valor da parcela do crédito de PIS/Pasep, informado no campo 17 - VL_PIS, vinculada à receita tributada no mercado interno. Validação: este campo só deverá ser preenchido se o campo 05 - COD_CRED do registro 1100 iniciar com “1” (crédito vinculado à receita tributada no mercado interno). Campo 03 - Preenchimento: informar o valor da parcela do crédito de PIS/Pasep, informado no campo 17 - VL_PIS, vinculada à receita não tributada no mercado interno. Validação: este campo só deverá ser preenchido se o campo 05 - COD_CRED do registro 1100 iniciar com “2” (crédito vinculado à receita não tributada no mercado interno). Campo 04 - Preenchimento: informar o valor da parcela do crédito de PIS/Pasep, informado no campo 17 - VL_PIS, vinculada à receita de exportação. Validação: este campo só deverá ser preenchido se o campo 05 - COD_CRED do registro 1100 iniciar com “3” (crédito vinculado à receita de exportação). E se coloco "0,00" o validador da erro. Estou anexando as alterações. ACBrEPCBloco_1.pas ACBrEPCBloco_1_Class.pas

Na tabela C100, por exemplo temos o campo IND_PGTO que aceita os valores abaixo: Indicador do tipo de pagamento: 0- À vista; 1- A prazo; 9- Sem pagamento. Obs.: A partir de 01/07/2012 passará a ser: Indicador do tipo de pagamento: 0- À vista; 1- A prazo; 2 - Outros Veja que a partir de 01/07/2012 o campo 9 não será mais aceito. E a função StrToIndPgto está fazendo a conversão para 9 sem analisar a data do documento. function StrToIndPgto(AValue: string): TACBrIndPgto; begin if AValue = '9' then Result := tpSemPagamento else if AValue = '' then Result := tpNenhum else Result := TACBrIndPgto( StrToIntDef( AValue, 9) ); end; Estou fazendo a reimportação de arquivos SPED antigos, de 2010 até hoje. Então em alguns casos o valor será 9 e outros será 2. Está função precisa analisar a data do documento que está sendo gerado para saber qual valor gravar no arquivo txt. Rodrigo.

Corrigindo. O CST_PIS ainda está tentando converter em data.

Resolveu, obrigado.

Fiz as alterações e consegui gerar os extemporâneos, porém parece que algo de errado com o componente na hora de gerar as informações. Veja um exemplo de linha gerada |1101|09471704000117|||1||02011900|01092010||5280,00|04041904|02||31121899|5280,000|1,6500|87,12|33211||ESTEIRA NOVA 3200 X 23450MM|092010|75370437000116| Os campos em negrito estão sendo gerados como data, porém o primeiro em negrito é NUM_DOC (no caso 3), o segundo é CFOP e o terceiro é IND_ORIG_CRED. Quando eu acesso a rotina TBloco_1.WriteRegistro1101 e passo o mouse o LFill dos campos indicados, mostra que o método sobrecarregado a ser executado é com DateTime. Não sei porque ele está fazendo isso. Pode dar uma olhada? Grato.

Veja a imagem em anexo.

Retomando. No bloco 1101 há um campo NUM_DOC que está configurado como INTEGER no ACBr. Pelo que vi na documentação ele é pra ser um campo numérico mesmo, porém tenho notas para inserir nesse bloco com o código "3A", por exemplo. Sendo assim isso vai gerar um erro de conversão. Será que não seria o caso de mudar esse tipo para String no ACBr? Grato.

Sim Juliomar, Eu havia corrigido e reinstalado. Obrigado.

Está dando erro no instalador C:\ACBr\Fontes\ACBrTXT\ACBrSPED\ACBrSPEDPisCofinsImportar\ACBrEPCBloco_1_Importar.pas(198) Error: E2010 Incompatible types: 'string' and 'Integer' C:\ACBr\Fontes\ACBrTXT\ACBrSPED\ACBrSPEDPisCofinsImportar\ACBrEPCBloco_1_Importar.pas(319) Error: E2010 Incompatible types: 'string' and 'Integer' C:\ACBr\Fontes\ACBrTXT\ACBrSPED\ACBrSPEDPisCofinsImportar\ACBrEPCImportar.pas(54) Fatal: F2063 Could not compile used unit 'ACBrEPCBloco_1_Importar.pas'

Ok, mas o componente de importação também já está no Trunk2? Estou utilizando ele.

Já fiz isso, mas nenhum arquivo foi baixado.

Ah, Ok. Aguardo a alteração do campo chave então. Agradecido.

Grato. E quanto ao ORIG_CRED? É o mesmo caso.

Na definição do SPED o registro 1100 e 1500 possuem o campo PER_APU_CRED. Este deve ser informado com o formato MM/AAAA (ignorando a barra) Ou seja, para o mês 07/2013 deveria ficar gravado "072013", porém na definição do componente este campo é um Integer. Assim sendo, quando gravado ele vai ignorar o "0" na frente do "7" e vai ficar somente "72013" A questão é. Isso não vai dar problema no validador? O mesmo acontece com o campo ORIG_CRED que está definido com um Integer no componente, mas no SPED é um numérico de dois digitos obrigatórios. Que são: "01" ou "02", ou seja, também será ignorado o "0" ao setar a variável no componente. E que provavelmente irá dar problema no validador. O campo CHV_NFE nos registros 1101 e 1501 também é um Integer, mas vai ter como gravar um Integer com este tamanho "42140814992260000103550010000014591704000000", e as vezes não chave de NFE e campo precisará ficar "vazio" e não com "0" Tem como alguém verificar se essa informação está correta no componente? Agradeço.

Testado e tudo funcionando. A ideia de criar uma propriedade é legal, mas do jeito que está já resolve. Fica a seu critério Agradeço.

Respondendo ao seu questionamento EMBarbosa, eu faço o seguinte. Vou escrever um pequeno portugol para cada arquivo SPED escolhido faça inicio limpar possíveis registros já importados; importar o arquivo usando o importador; salvar o conteúdo de cada bloco nas respectivas tabelas no banco de dados; fim Cada arquivo SPED importado gera um ID diferente (com base no CNPJ e data ini e fim) dentro do meu banco de dados. Vamos supor que meu banco seja o seguinte: CREATE TABLE SPED ( ID_SPED INTEGER NOT NULL, -- PK CNPJ VARCHAR(14) NOT NULL, DT_INI DATE, DT_FIM DATE, CONSTRAINT PK_SPED PRIMARY KEY (ID_SPED) ); CREATE TABLE REG_0140 ( ID_SPED INTEGER NOT NULL, -- PK e FK ID_0140 INTEGER NOT NULL, -- PK NOME VARCHAR(100), CNPJ VARCHAR(14), CONSTRAINT PK_REG_0140 PRIMARY KEY (ID_SPED, ID_0140) ) Lendo e gravando o primeiro arquivo SPED no banco, o ID_SPED será igual a 1 na tabela SPED Depois vou ler os blocos na sequência e gravar cada um em sua respectiva tabela. Por exemplo, ao ler o bloco 0140 ele tem somente um registro no meu caso (para cada arquivo). Ou seja, será gravado um registro na tabela REG_0140 da seguinte forma: ID_SPED | ID_0140 | NOME | CNPJ 1 | 1 | <nome> | <cnpj> Agora quando eu leio o segundo arquivo e vou gravar no banco vai acontecer o seguinte: ID_SPED | ID_0140 | NOME | CNPJ 1 | 1 | <nome> | <cnpj> 2 | 1 | <nome> | <cnpj> 2 | 2 | <nome> | <cnpj> Veja que ele vai gerar dois registro para o bloco 0140. Isso por que o primeiro registro é do arquivo anterior e o segundo do arquivo atual. Ou seja, ele acumula as importações, caso eu não limpe antes. Assim sendo, para cada arquivo importado eu preciso, antes de tudo, garantir que o ACBrPisCofins esteja vazio. Por isso a necessidade de tornar o método público. Não sei consegui ser claro, espero que sim. Rodrigo.

Bem então apenas torne o método "LimparRegistros" público, para que eu possa chamar ele quando quiser na minha aplicação.

Tive que implementar mais alguns métodos de conversão de tipos que não encontrei no fonte original. Utilizei eles para ler do SPED carregado e inserir em um banco de dados que tenho. Segue em anexo. Peço que analisem e façam as alterações necessárias para subir no SVN. ACBrEPCBlocos.pas

Outra sugestão de melhoria é tornar o método "LimparRegistros" público, para que possa ser acessado do componente de importação. Antes de importar um arquivo SPED o componente de importação deve limpar os registros que já possam existir de uma importação anterior. Para exemplificar, eu leio vários arquivos SPED ao mesmo tempo dentro de um laço "for", mas atualmente para cada importação o componente está acumulando as informações lidas anteriormente, fazendo com que alguns blocos que são únicos se repitam. Em anexo as units alteradas. ACBrSpedPisCofins.pas ACBrEPCImportar.pas

Esqueci de mencionar que tive que criar a função IndTpOperacaoReceitaToStr na unit ACBrEPCBlocos.pas. Foi necessário para ler o registro F100. Em anexo a unit. Favor subir a alteração. ACBrEPCBlocos.pas