EMBarbosa

Não está exatamente igual. Faça, por favor, o teste alterando a chamada do registro M600 do seguinte modo: Altere de: with RegistroM600New do begin Para: with RegistroM600 do begin Que é como está no DEMO.

Não estou usando esses registros, então não tive esse problema. Mas gostaria de ajudar. Favor postar o modo como você está tentando fazer. Se possível, use o programa de demonstração para implementar o registro como você está fazendo no seu programa. EDIT: Atualizei o DEMO do ACBrSPEDPISCofins hoje com um exemplo de como se deve preencher os registros M600 e M610. Talvez você possa olhar e tentar colocar os valores que está usando pra ver se vai dar certo.

Corrigi hoje para os registros G110, G125 e G126. Revisão 3189. Acho que não há mais erros deste tipo.

Foi sim. Veja: http://www.djsystem.com.br/acbr/mantis/view.php?id=1130

Alguém mais tem alguma consideração sobre isso? Estou disposto a fazê-lo.

Acho que entendi. Esse seu M600 tem Código de Contribuição Social e/ou Alíquota informado. Então precisa de um M610. Mas no M610 ele está reclamando que o Código de Contribuição Social e/ou Alíquota não foram informados. No caso, seu registro M610 está com valor de alíquota 0,00 e parece que pra esse Código de Contribuição Social deveria ser 7,6. Você precisa conferir esses valores...

Obrigado. Provavelmente outros registros em outros blocos devem ter o mesmo problema...

Você deve estar informando um registro M610 pra alguma contribuição com CST entre 01 a 05. Isso não pode. Não entendi, porque você não conseguiu resolver.

Acho que seus códigos estavam desatualizados. Esses campos está string já faz um tempo, a saber, desde a revisão 2701 (5/9/2011) e foi alterado para string pelo Isaque. Eu vou subir as outras alterações, peço que você atualize sua versão, se possível fazendo revert ou apagando os arquivos locais. EDIT: Subi na revisão 3185. EDIT2: Muito obrigado! (que coisa feia, tinha esquecido de agradecer... )

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