EMBarbosa

Opa o André foi mais rápido, mas posso acrescentar... O seguinte tópico tem links para iniciantes. Para entender melhor a lógica de comunicação do TEF você vai precisar ler a documentação provida pela certificadora da bandeira que você escolher. Entre em contato com eles como o André mencionou. Se você for paciente, eles tem muito desejo de ajudar.

Você consegue delinear os passos para repetir o problema no DEMO do ACBrTEFD?

André, é mais fácil você explicar o que está acontecendo. Esse registro que está dando problema, por que você colocou ele no registro C100, e por que o valor do Cod_Modelo é 57?

Não é estranho não. Quando você usa o comando TACBrSPEDFiscal.IniciaGeracao ele passa a informação da propriedade Path e NomedoArquivo para os blocos internos do componente. Isso é muito importante para que, caso aconteça alguma mudança nessas propriedades durante a geração do arquivo, não se mude o caminho do arquivo que será gerado, principalmente se estiver fazendo uma geração concomitante.

Se você se cadastrou tem uma opção de confirmação do usuário no qual depois de se cadastrar você recebe um e-mail. Se não recebeu esse e-mail. Me mande uma MP dizendo com qual o nome de usuário você se cadastrou, que eu vou verificar o que aconteceu. Para contribuir existem diversas opções. Uma delas é no wiki, onde queremos criar uma documentação mais completa sobre o projeto. O site é: http://www.djsystem.com.br/acbr/wiki. Outras formas são: [*:2cj9a35e]Participar ativamente do fórum tirando dúvidas dos usuários iniciantes [*:2cj9a35e]Fazer relatórios de Bugs [*:2cj9a35e]Contribuir com correções nos códigos [*:2cj9a35e]Se tornar usuário do SAC [*:2cj9a35e]Fazer doações [*:2cj9a35e]Doar equipamentos Veja também nesse link http://www.djsystem.com.br/acbr/wiki/index.php?title=Como_contribuir (que ainda está em construção...)

Talvez pernambuco não tenha ainda muitos usuários do ACBr. Mas assim que você postar o exemplo eu me esforçar para analisar o código, e sugerir a inclusão do componente. EDIT: Aí! Não é que apareceu um usuário.

então. Seu código está desatualizado. Veja como está o código atualmente: {24} LFill( VL_IPI,0,2 ) + {25} LFill( strCST_PIS ) + {26} LFill( VL_BC_PIS,0,2 ) + {27} DFill( ALIQ_PIS_PERC, 4, True ) + {28} DFill( QUANT_BC_PIS, 3, True ) + {29} DFill( ALIQ_PIS_R, 4, True ) + {30} LFill( VL_PIS,0,2 ) + {31} LFill( strCST_COFINS ) + {32} LFill( VL_BC_COFINS,0,2 ) + {33} DFill( ALIQ_COFINS_PERC, 4, True ) + {34} DFill( QUANT_BC_COFINS,3, True )+ {35} DFill( ALIQ_COFINS_R, 4, True ) + {36} LFill( VL_COFINS,0,2 ) + {37} LFill( COD_CTA ) ) ;[/code] Note, só como exemplo, que para preencher ALIQ_PIS_PERC é usado o método DFill e não LFill como está no seu código.

Então seu código estava desatualizado. Isso já foi corrigido. Favor atualizar.

Tem o exemplo, (muitas vezes chamado DEMO). Veja a pasta trunk\Exemplos\ACBrSPED\Delphi\PisCofins

O registro 0175, até onde eu me lembro, não é necessário para o Vendas do Período. EDIT: Puxa acho que me enganei. Deixa explicar então: DT_ALT - Data alteração é quando o cadastro do participante foi alterado. NR_CAMPO - é qual o campo do cadastro foi alterado. Exemplo foi alterado o NOME do cliente, qual é o número desse campo? CONT_ANT - é Conteúdo anterior do campo. Ou seja o valor antes de ser alterado. Exemplo: o nome de uma cliente era: Maria da Costa Silva, mas ela se casou e agora mudou o cadastro dela para Maria da Costa Souza. Então o valor desse campo é "Maria da Costa Silva", mas se você for no registro 170, o nome vai estar "Maria da Costa Souza"

Tenho que concordar com o Régys: Ruby é excelente. As ideias e a forma de programação são muito elogiáveis. Mas o problema de Ruby é famoso do mesmo modo: Ruby não escala. Delphi/Lazarus é minha escolha básica pra qualquer projeto, sem medo de ser feliz. Mas se você quer mesmo desenvolver para web, então é melhor analisar direito os requisitos.

Qual foi o erro?

Na verdade, se você pudesse corrigir e anexar o arquivo alterado aqui para que eu possa analisar seria de grande ajuda. É que estou meio apertado esses dias.

Você declarou o tipo TACBrCodFinalidade na Unit U_PROCESSOS?

Daniel, não sei se percebeu, mas o que o Guilherme está dizendo é que o código está assim: if FPG = nil then raise Exception.Create(Format(ACBrStr(cACBrECFAchaFPGIndiceException), [ CodFormaPagto ])) ;[/code] Mas na verdade, poderia estar assim: [code]if FPG = nil then raise EACBrECFErro.Create(Format(ACBrStr(cACBrECFAchaFPGIndiceException), [ CodFormaPagto ])) ; Ou seja, criando uma exception típica da classe TACBrECF. Acho que não tem nenhum problema, pelo contrário. Conforme o Nick Hodges disse há algumas semanas, é bom que a classe tenha sua própria exception. Isso também facilita saber onde foi gerado o erro.

Blz. Qualquer coisa você posta aí.

Você declarou o tipo TACBrCodFinalidade na Unit U_PROCESSOS?

Baixei e fiz algumas alterações para ficar com o código atual. Mas não subi pro SVN pois o PVA 1.0.7 não está validando para o guia prático 1.0.5 onde mencionam os novos registros. Deve-se levar em conta que o Bloco P não precisa nem ser informado caso a empresa não gere pelo menos um registro 0145 no Bloco 0. Isso mesmo, nem mesmo os registros de abertura e fechamento devem ser gerados. Então vamos precisar fazer um tratamento sobre isso, conforme trecho abaixo extraído do Guia Prático 1.0.5, página 248, parágrafo 3: Ainda falta alguma coisa, em especial os métodos WriteRegistroPXXX, mas anexo os arquivos já parcialmente modificados... ACBrSPEDPisCofins_BlocoP.rar

Isso. Esse é só um dos tópicos sobre esse assunto. Devem ter uns quatro. exemplo:

você tentou vendas do período?

malk182, vou corrigir hoje isso. É que a ideia era usar um método que seria um tipo de conversor para isso, mas não estou tendo tempo de testar tudo esses dias. Vou colocar um aviso no Changelog no entanto avisando sobre esse problema de compatibilidade.

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

Isso é um texto normal, como uma conversa normal. MAS PRESTE ATENÇÃO PORQUE ISSO AQUI É COMO SE ESTIVESSEM GRITANDO!!!!!!

Veja o exemplo (demo SPEDFiscal) como é feito com o registro C400. Ele possui o mesmo nível de um C500 e foi implementado corretamente. Acho que vai resolver seu problema.

hehe. Então, é que o PVA 1.0.7 não está pronto para validar registros pro Lucro Presumido (regime cumulativo) Olhe esse meu comentário com o link para o site do SPED http://www.djsystem.com.br/acbr/forum/viewtopic.php?p=23835#p23835. Daí a gente precisa esperar sair a versão 2.0 do PVA...