EMBarbosa

Ele foi desenvolvido para possibilitar a implementação de todos os perfis gerando o arquivo final. O perfil é o que define os registros que serão gerados.

Obrigado johnbh3.

Não ouvi falar de nada disso. Apenas esse tópico, mas é sobre SPED Fiscal, e apenas para o RS.

Se os arquivos são diferentes é normal que um não gere o erro. Você pode comparar os dois arquivos gerados com um programa de diff (Winmerge, por exemplo). Veja o que é diferente. Isso pode dar uma sugestão do que é importante para o Validador.

O ECF Contribuições é o novo nome do Pis/Cofins sim. É que eles adicionaram mais coisas além do Pis/Cofins e resolveram mudar o nome. Sobre o erro em si, acho melhor fazer uma consulta perguntando sobre o erro. Me parece um erro do validador e não do arquivo.

Se houver alguma sugestão para correção, queiram anexar por favor.

O change-log do SVN costuma ser até mais completo que os arquivos. Inclusive é aconselhado você verificar o log do SVN ANTES de fazer o update. Por exemplo, quando há uma quebra de compatibilidade mesmo que pequena, essa atitude pode ajudar você a evitar uma atualização do ACBr sem estar preparado para implementar o que for exigido.

Obrigado Wilson. Corrigido na revisão 3709

dá uma olhada neste tópico:

Sabe se existe alguma informação em algum site do governo estadual ou federal sobre isso?

Beleza. Vou fazer a alteração e um commit logo mais. EDIT: Commit na Revisão 3703.

Tente executar em modo debug e analisar quando é que o erro acontece no seu código.

Favor não duplicar tópicos. Continue em: viewtopic.php?f=6&t=6486 MODERAÇÃO: Tópico trancado.

Olá Pessoal, O comando para ACBrECFBematech.GetDadosUltimaReducaoZ está montando o arquivo INI com o Contador de Operação Não Fiscal Cancelada denominado NFC. Mas por padrão, o ACBrECF usa GNFC, como por exemplo, na função TACBrECFClass.MontaDadosReducaoZ. Gostaria de padronizar para facilitar a leitura desses arquivos independente se forem gerados pelo GetDadosUltimaReducaoZ ou pelo DadosReducaoZ. Acham que haveria algum problema?

Olá pessoal, Estava olhando o código do componente para pegar os dados da última Redução Z, no caso da Sweda. Percebi que o totalizador N3 está repetido em dois lugares no código, uma delas na posição que visualmente seria a do I3. Será que alguém com um ECF Sweda ou experiência nessa parte poderia verificar? Abaixo trecho do código que se inicia na linha 2399 do ACBrECFSwedaSTX.pas para a função GetDadosUltimaReducaoZ: {Verifica se existe não tributado} PosI := Pos('N1 ',RetCMD); if PosI > 0 then begin PosI := PosI + 5 ; {N1 } V := StrToFloatDef(Trim(Copy(RetCMD,PosI,18)),0)/100; end; PosI := Pos('N2 ',RetCMD); if PosI > 0 then begin PosI := PosI + 5 ; {N2 } V := V + StrToFloatDef(Trim(Copy(RetCMD,PosI,18)),0)/100; end; PosI := Pos('N3 ',RetCMD); if PosI > 0 then begin PosI := PosI + 5 ; {N3 } V := V + StrToFloatDef(Trim(Copy(RetCMD,PosI,18)),0)/100; end; Result := Result + 'TotalNaoTributado = '+FormatFloat('#0.00',V)+ sLineBreak; V:= 0; {Isentos} PosI := Pos('I1 ',RetCMD); if PosI > 0 then begin PosI := PosI + 5 ; {N1 } V := StrToFloatDef(Trim(Copy(RetCMD,PosI,18)),0)/100; end; PosI := Pos('I2 ',RetCMD); if PosI > 0 then begin PosI := PosI + 5 ; {N1 } V := V + StrToFloatDef(Trim(Copy(RetCMD,PosI,18)),0)/100; end; PosI := Pos('N3 ',RetCMD); // if PosI > 0 then begin PosI := PosI + 5 ; {N1 } V := V + StrToFloatDef(Trim(Copy(RetCMD,PosI,18)),0)/100; end; Result := Result + 'TotalIsencao = '+FormatFloat('#0.00',V)+ sLineBreak;[/code]

Diga quais são EXATAMENTE os passos para reproduzir o problema no demo.

Pessoal, Favor criar tópicos novos para novas dúvidas. Agora nós temos um subfórum para o ACBrNFSe justamente para evitar esse tipo de comportamento e facilitar a organização.

Eu passei um pente fino na mesma semana que o Regys criou o fórum. Mas acho que tinha ficado alguma coisa pra trás.

EDIT: encontrei o que você quis dizer. Ainda não sei como proceder no caso.

Seria melhor verificar com um contador confiável, ou com a própria receita. A questão é, quais documentos dão "direito à apuração de crédito à pessoa jurídica contratante, na forma da legislação tributária". A diferença apresentada está entre os documentos extemporâneos [01, 03, 07] e denegados e inutilizados [04, 05].

Da mesma forma que você torna o resultado inacessível ué. Não é no sentido que o usuário não consiga acessar. Isso é impossível numa máquina local. Ele é inacessível no sentido de o usuário não conseguir definir onde é o começo e o fim dos dados. Ele não consegue identificar onde fica o número de série, onde fica o GT e onde fica qualquer outra coisa. Num banco de dados, normalmente o cara vai encontrar uma tabela de nome "CONFIG" e campos como "GRANDTOT", "NUMSERIE", etc... É isso que o fisco tem em mente ao desejar um arquivo auxiliar criptografado. Para evitar perder tempo e facilitar a fiscalização eles logo estabeleceram que era um arquivo separado e pronto. Pelo menos foi assim que eu entendi desde o começo.

Verifique se a libeay32.pas que está sendo usada é a da pasta do ACBrComum e se ela está atualizada. Talvez exista outra no seu computador e o Delphi esteja pegando a incorreta?

Se você está falando da exception no seu código, você é quem está criando a exception, então você é responsável pela mensagem. Você viu no exemplo como o ACBrSintegra funciona?

Mensagem de erro que diz...???

Há uma pequenina diferença na implementação dos casos. Em um caso o Arquivo é criptografado e no outro o GT e o Número de Série.