EMBarbosa

O certo seria você mostrar pra eles a regra do PAF-ECF e perguntar a eles onde está a informação que você pode fazer diferente. Se eles não puderem ou não quiserem lhe informar, peça um documento assinado por eles assumindo a responsabilidade pela implementação.

Visto que não temos os direitos de distribuição sobre o livro, não seria correto fazer isso aqui no fórum. Favor atentar no nosso fórum: 5.1 - Respeite os direitos autorais - Não há objeção de se postar algum trecho de algo para desenvolver o seu post. No entanto, em vez de publicar em sua totalidade um texto de outra pessoa, coloque um link para o conteúdo. A não ser, é claro, que você seja o detentor ou tenha a permissão do detentor dos direitos autorais. 5.2 - Nada de pirataria - É proibido fornecer ou pedir informações sobre como obter ou fornecer ilegalmente qualquer coisa como software ("warez", "Crackz"), música, etc.

Ah, obrigado. Mas o problema que você citou já foi corrigido juntamente com outros problemas semelhantes conforme os posts acima e no tópico que eu mencionei antes. Se tiver outros casos no BD que não estejam sendo resolvidos pelo código atual, cujo commit foi feito hoje, aí sim eu gostaria de ver os valores. Mas não precisa do BD. Só dos valores mesmo. Ah, e obrigado por ter reportado o erro.

Não achei a documentação deste Fetch Rows, mas acho que tanto ele quanto o packed record não é o exatamente o que você está pensando. Não é um limite de quantidade de registros. mas quantidade de registros por vez... Quando eu disse query, eu não quero dizer TQuery ou algum componente semelhante, mas a consulta ao banco de dados composta do Select e seus parâmetros. Então a ideia seria um where para limitar a quantidade de registros que devem ser retornados já que você possui o FK.

Veja o que é recomendado a se fazer com o FireDAC. Desde que você apenas carregue poucos registros por vez, você não vai ter muitos problemas.

No contexto apresentado, não foi detectado nenhum problema. Você tem algum exemplo em que pode gerar problema?

Esse assunto foi resolvido e enviado ao SVN hoje utilizando outro método. Mais informações sobre a correção desse problema no seguinte tópico: Estou fechando esse tópico para não haver duplicação de informações. Por favor, continuem no tópico acima.

Para não poluir mais esse tópico com o assunto de arredondamento, postei uma explicação para eu não mexer em nada sobre isso neste

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.

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?