EMBarbosa

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

Até onde eu sei, quase tudo já está implementado... Qual versão você possui? Se você disser exatamente o quê você procura, talvez possa dar uma resposta mais específica.

No site da SEFAZ-MG foi atualizado para a versão 1.10. http://www.fazenda.mg.gov.br/empresas/ecf/_manuais.htm

Sei que foi disponibilizada para download a versão PVA_EFD 2.0.23. Acho que ele valida a partir de janeiro, não? Chegou a ver no site do SPED?

Outra coisa que vai complicar é que os registros desse layout da contmatic usam vários campos que não estão definidos no SPED Fiscal. Exemplo o registro 0200 tem um campo CST_COFINS_ENTRADA e outro CST_COFINS_SAIDA.

Qual o erro?

Exato. Que bom que resolveu. Ainda assim vou adicionar no Mantis uma sugestão no sentido de quando não for criado um certo bloco, ele ser gerado sem dados por padrão, caso seja obrigatório. Daí poderá ser implementado quando houver tempo hábil. EDIT: Adicionado como caso 1127

Pasta \trunk\Exemplos\ACBrSPED\Delphi\PisCofins Acho que é o caso do Bloco 1...

O seu pedido faz sentido. Mas notou que o exemplo do componente trata isso?

Obrigado Isaque. Vou tentar pegar um exemplo que caia nessa situação com o PVA assim que possível. Eu posto aqui se achar mais alguma informação.

Olá pessoal, Estou com uma dúvida aqui. No registro C170, os campos VL_BC_PIS, ALIQ_PIS, VL_BC_COFINS e ALIQ_COFINS (26, 27, 32 e 33), podem não ser informados em alguns casos. Isso fica claro pela observação 3 deste registro tanto no Guia Prático 1.0.3 como no leiaute do arquivo, que eu transcrevi abaixo com grifo meu. O componente atualmente não permite isso. Apenas atualizando o parâmetro Nulo da função LFill resolveria o problema. Mas será que satisfaria os outros casos desse registro. Será que não daria conflito em nenhum outro caso onde fosse necessário informar |0| ou |0,00| para algum desses campos?

Já está no SVN. Obrigado.

Não... O que desejava ter perguntado era a finalidade desse arquivo, para o que serve. E o porquê do ACBr dever gerá-lo. Agora que fiz o download vi sobre o que era. É sobre a importação do G5 Phoenix da contmatic. Já existe um tópico sobre isso. veja:

O que vem a ser esse arquivo? Sobre o quê?

Olá, Poderia testar o seguinte? procedure TBloco_C.WriteRegistroC395(RegC010: TRegistroC010); var intFor: integer; begin if Assigned(RegC010.RegistroC395) then begin for intFor := 0 to RegC010.RegistroC395.Count - 1 do begin with RegC010.RegistroC395.Items[intFor] do begin Add( LFill('C395') + LFill(COD_MOD) + LFill(COD_PART) + LFill(SER) + LFill(SUB_SER) + LFill(NUM_DOC) + LFill(DT_DOC, 'ddmmyyyy') + LFill(VL_DOC,0,2) ); end; // Registros FILHOS WriteRegistroC396( RegC010.RegistroC395.Items[intFor] ); // RegistroC990.QTD_LIN_C := RegistroC990.QTD_LIN_C + 1; end; // Variavél para armazenar a quantidade de registro do tipo. FRegistroC395Count := FRegistroC395Count + RegC010.RegistroC395.Count; end; end;[/code] Estranho pois, teoricamente, não devia haver muita diferença em nenhuma das execuções...

Nunca vi esse erro. Você não conseguiu descobrir exatamente onde acontece o erro? Ou o motivo dele?

Vide o outro post já citado aqui. Lá você encontra a instrução normativa que saiu no DOU (Diário Oficial da União) do dia 22 de Dezembro na página 53.