Wesley Lamb

Boa tarde pessoal. Um tempo atrás, através do Discord eu havia entrado em contato com o ACBr referente a alguns problemas na geração de juros dos boletos do C6 Bank pelo Webservice. Dentre eles, um dos problemas discutidos era referente ao cálculo dos percentuais de juro. Em primeira comunicação com o C6 Bank, eles haviam repassado a informação de que todo juro, sendo valor ou percentual, deveria ser informado na API como cálculo diário. A API pede apenas 3 informações no JSON: Type, sendo "P"ou "V", value e dead_line: "interest": { "type": "P", "value": 0.03, "dead_line": 0 }, No caso, o componente ACBr pegava um valor, por ex 1% a.m e dividia por 30, resultando em 1/30 = 0,03% a.d. Porém, em conversas recentes com o pessoal do C6 Bank e testes em produção, o correto é informar os percentuais calculados para o mês, ou seja, deve-se manter o 1% a.m. no Json e multiplicar 1% a.d. por 30 caso seja juro diário. Na linha 234 do arquivo ACBrBancoC6.pas, deve-se inserir uma multiplicação por 30. Na linha 236, deve se tirar a divisão por 30. Obs.: A alteração é apenas para percentuais, o valor permanece o mesmo. Em anexo eu realizei um boleto de testes de 20 reais com 4% de juro a.m., fiz direto sem utilizar o componente impressao_api.pdf

Bom dia, pelo que identificamos houve alteração no padrão do XML de retorno de consulta. Estou trabalhando na resolução do problema, mas se alguém já tiver ajustado se possível nos dar uma ajuda, ficaremos grato

Bom dia pessoal. Fui fazer uma consulta de rotina referente a transmissão de alguns clientes que já emitiam desde o mês passado, e do nada apareceram outros 4 clientes (3 ativos e 1 não-usuário do nosso sistema) na listagem de clientes com pendência de transmissão. O curioso é que todos os novos clientes constavam 1 pendência de transmissão apenas, mas consultando o CNAE dos mesmos através do Sintegra, os mesmos possuem um dos CNAEs de setembro ainda, resultando em mais de 20 pendências se levar em consideração as reduções Z emitidas. Mais alguém identificou novos clientes no S@T referente ao Bloco X?

Olá pessoal, Eu consegui sanar o problema de rateio do Bloco X ajustando na extração dos dados. o SQL me retorna exatamente o valor rateado. O cálculo para calcular o ValorDesconto é: Item.valordesc + ((Venda.totalbruto - Venda.totalliquido) * (Item.totalliquido / Venda.totalbruto)) Para calcular o ValorTotalLiquido: Item.totalliquido - (Venda.totalbruto - Venda.totalliquido) * (Item.totalliquido / Venda.totalbruto) Montei uma tabela explicando todo o procedimento Rateio desconto acresc.ods

Encontrei uma maneira de contornar o problema. Criei um ClientDataSet e alimentei com todos os campos e valores que eu tinha, depois só apontei ao relatório o DataSource. Segue o código caso alguém quiser seguir meus passos: cdsTeste.Close; cdsTeste.FieldDefs.Clear; for I := 0 to Pred(ADQGeradorRelatorio.FieldCount) do begin case ADQGeradorRelatorio.Fields[I].DataType of ftBCD, ftFloat, ftCurrency, ftSingle, ftFMTBcd, ftExtended: begin cdsTeste.FieldDefs.Add(ADQGeradorRelatorio.Fields[I].FieldName, ftBCD, 0, false); end; else begin cdsTeste.FieldDefs.Add(ADQGeradorRelatorio.Fields[I].FieldName, ADQGeradorRelatorio.Fields[I].DataType, ADQGeradorRelatorio.Fields[I].Size, false); end; end; end; cdsTeste.CreateDataSet; Basicamente, o que ele vai fazer é tornar ftBCD todos os campos do tipo decimal. Como trabalho com apenas 4 casas decimais não tive problemas com perda de dados.

Correção, o problema ocorre apenas com ftFMTBcd. O ftSingle faltou adicionar ao Case rsrs

Estou criando um relatório em tempo de execução que irá verificar o DataType de um column de um grid e, caso seja um equivalente a ponto flutuante (ftFloat, ftExtended, ftBCD, ftCurrency, ftFMTBcd e ftSingle) irá gerar um RLDBResult com este campo. O problema é que campos no tipo (ftFMTBcd e ftSingle) o RLDBResult não calcula os valores, permanece valor 0, vide print: http://prntscr.com/o3vkjr. Alguém por ventura teria enfrentado este problema e conseguiu uma solução?