EMBarbosa

O Daniel postou uma correção para esse problema hoje. E pelos meus testes está tudo OK. Eu na correção do Daniel. Mas após analisar melhor, achei por bem deixar as modificações dele, inclusive nas units de teste. Abaixo a explicação: Hmm... entendi o que acontece para retornar apenas a string com o delimitador, mesmo o valor não sendo zero. O fato é que o número de decimais passado por parâmetro ao método LFill é 6. Neste caso, o TruncFix será calculado de 0,00000001 * 100000 (= 0,001) e retornará 0. Daí, na chamada do próximo LFill será passado para o parâmetro Nulo como True. Embora o valor inicial tenha sido diferente de 0, o atual vai ser e isso resultará na string só com o delimitador. Isso poderia ser alterado passando "(Nulo) and (Value = 0)" como parâmetro ao invés de apenas a variável nulo, como abaixo: if (strCurMascara <> '#') and (strCurMascara <> '') then Result := FDelimitador + FormatCurr(strCurMascara, Value) else begin AInt := TruncFix(Value * intP); Result := LFill(AInt, Size, ((Nulo) and (Value = 0)), Caracter); //<- Considerar a situação inicial e não apenas a variável Nulo end; end; Só que eu imagino que isso talvez não seja o esperado. Então preferi não fazer essa alteração. Então estou deixando isso documentado aqui no fórum para futura referência.

Mas aí o teste passa quando o valor não é nulo. Estes dois testes específicos não poderiam retornar uma string só com o delimitador mesmo marcando o LFill para nulo, pois "0.000000001 <> 0". Vou tentar verificar onde pode estar o problema...

Vai depender do problema que é apresentado no log. Houve uma atualização do ACBrInstall hoje. Queira tentar com essa versão mais nova.

Não utilizo o Append e muito menos o FireDAC. Mas, se não me engano, o método append implicitamente faz com que o TDataset use o método Last. O método last faz pular para o último registro, e para que se consiga isso é necessário carregar todos os registros da tabela. Então, tente utilizar o método Insert ao invés disso, ou procure outra alternativa no FireDAC.

Estou compatibilizando os testes atuais com o DUnit. Acredito que isso possa facilitar para que aqueles que não quiserem se aventurar no Lazarus possam ajudar neste sentido. Seguindo as sugestões nessa resposta no StackOverflow, fiz as modificações e parece que no momento está tudo ok. A maior diferença são alguns IFDEFs que precisam ser adicionados e ao invés de se utilizar AssertTrue, AsserEquals, etc... é preciso utilizar CheckTrue, CheckEquals, etc... Isso torna os códigos compatíveis. A resposta no StackOverflow acima citada, em seus comentários, sugere uma criação de uma classe "wrapper" para facilitar a escrita para os dois testes sem ficar fazendo um monte de IFDEFs no código. Sugestões são bem vindas.

Sem mais informações fica difícil ajudar. Dá uma olhada neste post sobre

Respondendo minha própria pergunta. Este caso está relacionado com o caso do LFill apresentado no outro tópico. Adicionei hoje testes unitários expondo todos esses problemas. Só faltou o link pra esses tópicos... Até semana que vem vou poder resolver esse problema, espero que definitivamente. EDIT: Para reproduzir, não é necessário outro Banco de dados. Basta apenas modificar no programa de exemplo do ACBrPAF a linha no uFormPrincipal.pas do método btn.RegistrosPAFClick conforme abaixo: for j := 1 to 2 do begin with RegistroD3.New do begin DT_INCLUSAO := DATE; NUM_ITEM := i; COD_ITEM := '10'; DESC_ITEM := 'descricao do item'; QTDE_ITEM := 10.00; UNI_ITEM := 'UN'; VL_UNIT := 1.00; VL_DESCTO := 0.00; VL_ACRES := 0.00; VL_TOTAL := 4.20; //<---- Erro no arredondamento na hora que gera o arquivo. SIT_TRIB := 'T'; // T, S, I, N, F ALIQ := 7.00; // SOMENTE QUANDO T E S IND_CANC := 'N'; DEC_QTDE_ITEM := 2; DEC_VL_UNIT := 2;

Quem quiser um passo a passo simples, pode ver o seguinte link. Se houver necessidade de um passo a passo em português com exemplos do ACBr, fiquem a vontade em se pronunciar. Daí eu posso providenciar.

E está quase vencendo a data!

Possibilidades: ou pode ser um problema no validador, ou pode ser um problema no Guia Prático, ou talvez você tenha mesmo que gerar o 0145. Você pode anexar exatamente a mensagem de erro que indica que você deve incluir o bloco P mesmo sem registros?

Obrigado pelo retorno.

Olá Clayton, Não temos feito tags visto que a gama de componentes é muito grande e eles estão seguindo no momento numeração de verões independentes. Como desenvolvedores procuramos tomar muito cuidado com isso. Principalmente pois somos os principais usuários dos componentes units e classes. Infelizmente, devido a sermos imperfeitos, pode realmente passar um commit que vá com algum erro. Mas normalmente quando alguém faz isso, logo em seguida ou a mesma pessoa ou outro desenvolvedor vê o erro e corrige. O maior tempo que eu vi um erro ficar no trunk foi 24 horas. Ainda assim, nós sugerimos que os usuários do ACBr sempre acompanhem os arquivos changelog e o log do SVN para entenderem as modificações que estão sendo feitas. Os componentes são bem dinâmicos e os desenvolvedores muito ativos, assim sempre temos algo novo. Isso é muito bom, mas pode ter um efeito indesejado em algumas situações. Por exemplo, talvez uma modificação para atender uma legislação nova pode quebrar a compatibilidade com uma funcionalidade antiga que você ainda esteja utilizando nos clientes no momento e não pode alterar. Aqui na empresa nós adotamos o costume de trabalhar com uma revisão específica pra facilitar. Daí, de forma quase diária, analisamos as revisões novas antes de atualizar o repositório local.

Acho que não há informações suficientes para lhe ajudar... Você está utilizando o monitor? Você chegou a tentar com o programa de exemplo?

Ontem eu atualizei o exemplo do ACBrSPEDPISCOFINS para gerar como exemplo o bloco P e o arquivo é importado corretamente. Só que ele gera apenas com os registros básicos.

Aqui está funcionando normalmente.

Acabei de testar aqui com o Delphi XE e está funcionando. Clique no link para "Atualizar captcha" pra verificar se o captcha está atualizado.

Acho que não. Você poderia postar o log completo da redução Z? Se possível testar com o ECFTeste seria bom. E os outros casos você chegou a procurar pelos eventos do ACBrECF ou algum lugar no seu aplicativo que trata/corrige o estado do ECF?

Eu cliquei no link da mensagem e abriu normalmente... Você pode tentar novamente e em outra máquina?

1) No log não parece estar sendo chamado o comando da Redução Z. Se estiver, o timeout pode estar muito baixo. Tente aumentar ele. Aqui no fórum tem algumas dicas para isso. 2) O comando de fechar relatório foi chamado. Muito difícil ele não estar em algum lugar do código. Tente verificar os eventos do ACBrECF. Ou talvez algum comando para corrigir o estado do ECF, já que o comando anterior parece fazer referência a isso. 3) Mesmo caso anterior. Sugiro pegar o aplicativo de exemplo (ECFTeste) e testar com ele a impressão da Redução Z. Só por desencargo de consciência.

Beleza... na verdade foi falha minha. Eu achei que os fontes estavam no anexo, mas está claro pelo que escreveu que era só o executável. A minha ideia era colocar no programa exemplo pra facilitar para os novos. Mas se não encontrar, ainda é possível de implementar olhando as mensagens do Daniel e minhas espalhadas pelo fórum. (:

Depende do problema que está tendo.

Ou você não testou a geração corretamente ou já percebeu mas não voltou pra colocar o resultado. Para que outros usuários não venham fazer a mesma pergunta novamente vou explicar o que foi implementado. O que o componente faz no método TBloco_C.WriteRegistroC100 (unit ACBrEPCBloco_C_Class.pas) é avaliar a data do registro C100. Se for antes de 01/07/2012, ele gera no formato antigo, colocando 9 no arquivo SPED. Se for após 01/07/2012, o tipo tpSemPagamento é gerado como 2. Assim mesmo quem utiliza o componente antes não precisa se preocupar. Adicionarei ainda hoje um comentário no TACBrIndPagto sobre isso.

svn://svn.code.sf.net/p/acbr/code Mais informações sobre o acesso ao SVN

E hoje quando eu fui analisar o código pra ver se enviava ao SVN é que percebir que os fontes não estavam lá no anexo... fon fon fonnnnnn

Verdade. Pelo menos dois deles estão mencionados nos links que postei acima.