Waldir Paim

Removi os anexos anteriores e removi a sobrecarga na função TruncTo como descrito. Anexei as units novamente com mais alguns ajustes e com mais testes que os valores não correspondiam com o resultado esperado. Se alguém puder baixar e rodar o teste para ver se a função atual do repositório está realmente com problemas em alguns valores. Segue units. acbrutiltest.pas ACBrUtil.pas

Fazendo mais testes no FreePascal concluímos que a função TruncTo deve receber sobrecarga e ter uma para cada tipo; Fiz uma alteração e inclui as novas variações da mesma função. Inclui nos testes o teste para o tipo Single. Isso permite ao compilar escolher o melhor tipo para a conversão. Segue units alteradas. ACBrUtil.pas acbrutiltest.pas

@PoliDados Desenvolvimento Hoje a tarde vou tentar simular e tentar identificar o ponto. Estou usando o Delphi Berlin 10.1 e não notei nenhum problema com esse tipo de arredondamento. A ideia de isolar o problema do @RicardoVoigt ajuda muito e ainda serve de testes para outros usuários conseguir simular.

Nesse caso, você deve seguir o debug até o ponto da print e identificar onde ele arredonda para duas casas.

Perfeito, isso mostra que a função realmente está correta. Eliminando essa possibilidade fica até mais fácil de você encontrar a solução. Boa sorte!, com seus testes.

Num outro tópico onde o usuário estava passando por uma situação onde passava um valor e o resultado obtido é diferente do esperado coincidiu com um problema que passei recentemente e por isso resolvi fazer os testes que não existia para esse caso. Segue anexo a unit do teste e a correção da situação que peguei na função TruncTo. acbrutiltest.pas ACBrUtil.pas

@PoliDados Desenvolvimento Você realmente está engano, não trata-se de passar o valor certo e sim de como está parametrizado sua função de arredondamento. Foque nesse trecho : Veja que dentro do case {CasasDecimais.Formato} que ele decide qual valor vai retorna na saída dela. Esse paramentro por padrão define com duas casas decimais e pode estar ai o seu problema, se você não passar 3 casas ele sempre vai te retornar o valor diferente do esperado. Fiz umas melhorias no teste e vou criar outro tópico para incluir eles nos fontes.

@PoliDados Desenvolvimento Eu vi seu dilema e resolvi testar para ver se realmente tem algum problema na função abaixo: Veja o case na função, ele determina qual atitude a função vai tomar para formatar sua informação. Aproveitei e inclui no TesteCase que você pode encontrar na pasta "..\Testes\Dunit\ACBrComum\ACBrComumTestCases.dpr". Nele tem os testes que mostra que a função está certa. Observe o Teste abaixo : Essa linha em destaque você não vai encontrar mas vou anexar a unit aqui com o teste que usei os valores que você reporta. Observe ali que se informar 0,266 com duas casas decimais o valor é arredondado para 0,27 conforme você descreve. Agora se informar o valor com 3 cadas decimais o valor formata corretamente como demostra o teste. Aproveitei e inclui mais um teste para a função TruncTo e o teste apresentou um bug nela. Vou anexar aqui também a correção para que possa ser avaliada e se possível incluída no repositório. Meu conselho, verifica onde você configura as casas decimais no seu código e boa sorte. ACBrUtil.pas A unit acbrutiltest.pas do teste deve ser salva na pasta "..\Testes\FPCUnit\ACBrComum". acbrutiltest.pas

Legal, Poe as dll na pasta onde a IDE enxerga. Uma das alternativas é a pasta Lib do seu Delphi ou na pasta %systemroot%\System32 para Windows 32 e %systemroot%\SysWOW64 para Windows 64 Dessa forma sua IDE encontra as dlls e resolve essa bronca.

@potew Estamos em plena olimpíadas, se desistir não vai ganhar sua medalhinha de ouro. Mas para ajudar no seu gás, cola aqui o log de erro apresentado por sua IDE. Com ele consigo te dar uma forcinha e concluir a maratona. Sobre as dlls poe elas na pasta do seu executável.

Segue algumas units da pasta ACBrBoleto com remoção dos warnings. ACBrBancoCaixaSICOB.pas ACBrBancoSantander.pas

Segue algumas units da past ACBrDFe\ACBrNFe\PCNNFe com remoção dos warnings. pcnInutNFe.pas Segue algumas units da past ACBrDFe\ACBrNFe\DANFE\NFe\Fortes com remoção dos warnings. ACBrNFeDANFeRLPaisagem.pas

Segue algumas units da past ACBrTEFD com remoção dos warnings. Fiz um ajuste que requer uma atenção especial na unit ACBrTEFDCliDTEF while not Parar do begin if ItemSelecionado = 30 then begin Result := -1; //verificar isso aqui. Exit; end; ACBrTEFDClass.pas ACBrTEFDCliSiTef.pas ACBrTEFDCliDTEF.pas ACBrTEFDTicketCar.pas Segue algumas units da past ACBrSerial com remoção dos warnings. Fiz um ajuste que requer uma atenção especial na classe TACBrPosPrinter TACBrPosPrinter = class(TACBrComponent) private ... protected FPosPrinterClass: TACBrPosPrinterClass; mudei para protected (acredito não causar problemas) ... end; ACBrECFClass.pas ACBrECFEscECF.pas ACBrDISGertecTEC65lib.pas ACBrPosPrinter.pas Segue algumas units da past ACBrOpenSSL com remoção dos warnings. ACBrEAD.pas Segue algumas units da past ACBrComum com remoção dos warnings. ACBrAAC.pas

Tenho que concordar com ambos, mas deixar como está é que não pode! Qual a possibilidade de remoção disso? O que ambos sugerem que seja feito? Se fosse tão maléfico assim não seria usado nos fontes do principal framework usado pelo ACBr. Será que eles são tão inconsequentes assim? Erro é deixar como está e não ver os verdadeiro warnings prejudicais ao projeto e aos aplicativos dos usuários.

Cada um tem seu ponto de vista, mas eu não fui muito longe para chegar nessa conclusão. veja: Faz um pesquisa ai nos fontes, vai encontrar alguns exemplo de uso. Muito provavelmente esse pessoal tem seus motivos para usar.

@EMBarbosa No meu ponto de vista deixar eles ali só complica mais do que ajuda, hora visto que os voluntários não se manifestam e não se pronunciam para sanar o problema. Desligando eles a gente corrige inúmeros outros que não estão visíveis, eu mesmo estou preparando um pacote de unit com outras correções que consigo ver sem eles nos log.

@Daniel Simoes Não se trata de erro de compilação e sim erro no código mesmo; Veja na unit ACBrECFNaoFiscal o códido atual é esse : Total := CalcTotalItem( Qtd * ValorUnitario,-2); Mas o correto seria esse : Total := CalcTotalItem( Qtd, ValorUnitario); Da uma verificada ai por favor.

@EMBarbosa Eu resolvi boa parte dos warnings remanescentes aplicado essa correção no ACBr.inc. {$IFDEF DELPHI12_UP} {$DEFINE HAS_CHARINSET} {$ENDIF} {$IFDEF DELPHI15_UP} {$DEFINE HAS_FORMATSETTINGS} {$DEFINE HAS_REGEXPR} {$WARN IMPLICIT_STRING_CAST OFF} {$WARN IMPLICIT_STRING_CAST_LOSS OFF} {$WARN SYMBOL_DEPRECATED OFF} {$ENDIF} Desativei com o bloco acima as três ultimas definições que mais me causavam transtornos. Vou adicionar o arquivo aqui caso tenha interesse de incluir no repositório e também resolver para os outros colegas da mesma forma. ACBr.inc

@Daniel Simoes Foi aplicado a correção correção abaixo na unit? Para funcionar corretamente ajustei para Total := CalcTotalItem( Qtd, ValorUnitario). Se puder dar uma conferida , acredito que deve ter escapado esse detalhe.

@Rafael jorge Esse erro 1325 está na tabela dos erros da NF-e? Pelo retorno me parece se tratar de uma venda interestadual! Veja se assim não resolveria: Só um chute! pois com as suas informações fica difícil de ajudar. Se possível poste o xml.

@Rafael jorge Qual o código do erro da rejeição? Qual o regime de tributação do emitente? Se o código da rejeição for 508, use um CST diferente de 90 para lucro presumido e real ou se for simples nacional acredito que um CSOSN 400 deve passar.

@hleorj Me animei. Manda os fontes pra mim testar também! Te ajudo aplicar essas alterações para os outros DANFes do Fortes.

Seu teste de impressão ficou muito bom, me parece que não afetou a paginação. Você pode incluir algumas observações nos itens, alguns na primeira pagina e outros nas paginas seguintes? Precisamos também testar se ele não pulou itens da lista.

@hleorj Veja: A impressão ou a logica não não me preocupa, o que me gera um grande receio é o controle da pagina como destaquei acima. Já vi problemas com esse tipo de aplicação aqui mesmo no DANFe do NFCe usando fortes pois os controle dos itens são dinâmicos e mudam de tamanho conforme o gosto do programador e você precisará de uma logica muito apurada para resolver isso. Então mexer em algo estável em busca de remover uma dependência pode gerar efeitos colaterais indesejados com a paginação.

@hleorj Minha sugestão é criarmos uma nova versão da DANFe sem os Dataset e manter o funcionamento perfeito da versão atual.