EMBarbosa

Pelo visto o PVA está reclamando. http://www.djsystem.com.br/acbr/mantis/view.php?id=1132

O que acontece é que o PVA que você testou não está pronto para receber esse layout. O quinto campo deve ser enviado sim, mas será vazio, ou seja, ||.

Vamos lá. IAT é o Indicador de Arredondamento Truncamento. A ideia é justamente fugir desses problemas causados pelo truncamento ou arredondamento dos preços dos produtos. Ele entra no cadastro do produto. Assim como você define qual unidade vai trabalhar com o produto (Kg, Litros, UN, Pacote, etc...) você define também se ele vai ter valores truncados ou arredondados. Nos ECFs mais novos existe um parâmetro de arredondamento ou truncamento por item vendido. Que deve ser configurado de acordo com o seu modo de trabalho. Provavelmente na sua balança também. O ACBrECF tem as propriedades ArredondaPorQtd e ArredondaItemMFD. Também a procedure ArredondarPorQtd( var Qtd: Double; const ValorUnitario: Double; const Precisao : Integer = -2 ). Mas agora não sei ao certo quais desses você vai precisar mudar. Quais os valores gerados pela balança e quais os gerados pelo ACBr?

Pelo seu report descobri que o bug se estendia também aos registros E113, E240 e E250. Fiz uma correção um pouco diferente da sua nesses registros. Você pode testar por favor? Revisão 3184

por que você mudou os campos de NUM_DOC_INI para string no registro 1710?

Olá Cilleni, Se quiser anexar as suas alterações aqui, elas podem ser analisadas e enviadas ao SVN.

Olá pessoal, Espero que não tenham interpretado mal a minha pergunta. Diniz disse que o tipo o correto para CFOP é tipo NUMERICO. Mas não disse o motivo. A questão é que ele colocou como se único tipo correto fosse integer porque o campo é definido como NUMERICO e, se vocês observarem bem, não faz diferença se o tipo é string ou integer na hora de formatar o registro. Não tenho nada contra a padronização, pelo contrário. Concordo plenamente com ela. Mas será que perceberam que na maior parte dos outros registros, principalmente no SPED Fiscal que é mais antigo e estabilizado, o campo CFOP é string?

Já existem alguns tópicos sobre o assunto. Tente pesquisar, por exemplo, sobre o requisito. viewtopic.php?f=12&t=379

A correção pode gerar uma incompatibilidade com dados salvos anteriormente, caso se utilize uma conversão direta de inteiro para um dos dois tipos desses campos. Exemplo: (... Código ....) with RegistroC500New do // Inicio Adicionar os Itens: begin (... Código ....) COD_GRUPO_TENSAO := TACBrGrupoTensao(tblRegistros500COD_GRUPO_TENSAO.asInteger); (... Código ....) [/code] Peço que os usuários desse registro fiquem atentos. EDIT: Em vista disso, antes de enviar para o SVN, eu vou anexar aqui as alterações para que alguém mais possa testar. ACBrEFDBloco_C_Class.pas ACBrEFDBlocos.pas

Realmente, no caso de registros C500 cancelados, os outros campos não devem ser preenchidos. Vou fazer uma alteração como sugerido.

Obrigado. Foi atualizado no SVN. Revisão 3176

Wilson, Você pode anexar aqui mesmo no fórum os arquivos que você alterou.

É que, embora exista esse requisito especificado, não existe teste para ele. Então, creio que poucos o implementam, e quando o fazem, como nós aqui procuramos fazer, talvez nem dão tanta atenção ao teste, já que não foi especificado como deve ser feito. Ainda assim, acho que poderíamos incluir o evento.

Pessoal, Estava aqui estudando o uso do componente ACBrAAC para implementar o REQUISITO XXII do PAF-ECF quando o arquivo está corrompido (item 8). O problema primário foi detectarmos que quando o arquivo está corrompido o ACBrECF não consegue ser ativado. Assim não conseguimos pegar os dados do ECF para recriar o arquivo auxiliar criptografado. Achei que seria uma boa ideia se o componente possuísse um evento para os casos onde gera a exceção de arquivo inválido (EACBrAAC_ArquivoInvalido). Assim, o programador teria a opção de tratar esse acontecimento assim como tem para tratar no evento "VerificarRecomporValorGT". O componente poderia levantar a exceção caso o método não esteja definido, o que não alteraria o código de quem está usando o componente até hoje. O que acham?

Foram também alterados: Requisitos: XXXVI item 1 letras a e b XLII item 1 letras a8, c35, e35 e foi adicionado o requisito XLIV sobre PAF-ECF PARA POSTO DE PEDÁGIO

Nem a nova versão disponibilizada hoje está. Disponibilizada a versão 1.0.5 do PVA da EFD-PIS/Cofins Veja: http://www1.receita.fazenda.gov.br/noticias/2012/janeiro/noticia-04012012.htm

Por quê?

Por favor, coloque a mensagem completa do erro e/ou o log do ACBrECF. Tente a execução por fora do Delphi. EDIT: Talvez possa ser, mas analisando a mensagem de retorno do ECF a gente pode ter mais certeza.

Então, veja se não é esse problema: viewtopic.php?f=10&t=2522

Você está executando por fora do Delphi ou em modo Debug?

Atualize seus fontes: Veja Revisão 3020 * D110 gerava valores incorretos veja: http://www.djsystem.com.br/acbr/mantis/view.php?id=1094

Pesquisar no fórum http://www.djsystem.com.br/acbr/forum/search.php

Já subi pro SVN. Favor testar.

Já subi pro SVN. Favor testar.

Vou olhar agora a tarde. EDIT: relacionado... link