-
Total de ítens
26 -
Registro em
-
Última visita
Últimos Visitantes
O bloco dos últimos visitantes está desativado e não está sendo visualizado por outros usuários.
Norixam's Achievements
-
Norixam changed their profile photo
-
Boa noite pessoal, Esses são os logs da aplicação, logando inclusive o INI passado ao ACBR: Consegui evoluir, formatar e passar a data correta para o componente, porém, o PDF continua saindo com a data atual. Data salva no PostgreSQL Se eu faço logs em algum outro local da aplicação da data, em todas as camadas ela fica correta.
-
Olá José, mas é justamente esse o problema que estou tentando solucionar. Mesmo formatando da forma correta, por algum motivo chega na lib o padrão incorreto. Se a forma de formatação estivesse incorreta, não funcionaria no outro servidor onde roda atualmente. Outros pontos da aplicação como o PostgreSQL, salva a data corretamente, mas por algum motivo o ACBR pega a data errônea. Como comentei, acredito que seja alguma configuração no ambiente de execução (Windows) onde está rodando.
-
Sim, mas para garantir acabei de baixar ela novamente e colocar no projeto. Ainda sem efeito. Parece estar ocorrendo alguma exceção ao gerar o boleto e fica sempre com a data atual.
-
-
Boa tarde pessoal, Estamos utilizando a algum tempo a lib para gerar boletos e processar arquivos de retorno. Tudo estava em pleno funcionamento até decidirmos mudar a hospedagem. Recentemente optamos por contratar um servidor na UOL Cloud Hosting, com Windows Server. A aplicação foi construída em C#, com dotnet core. Inicialmente percebemos que o servidor estava com a língua e com o padrão de data e hora americanos, conseguimos alterar para deixa-lo em padrão brasileiro: O problema é que ao mandarmos gerar os boletos, o mesmo é gerado sempre com a data atual, ignorando o valor que passamos. Isso ocorre também nos arquivos de retorno importados: Acreditamos que o problema em si não seja na passagem de dados do C# para o componente, visto que no servidor anterior isso funciona. No banco de dados PosgreSQL local do servidor, a data fica correta também. Utilizamos a formatação da seguinte forma: Também tentamos da seguinte forma: Nenhum dos casos surtiram efeitos positivos. Aparentemente o problema parece ser em algum locale do Windows, visto que no servidor que funciona, a linguagem padrão é a PT-BR. Alguém já passou por isso ou tem alguma ideia?
-
Estamos usando aqui de forma Web também, como uma API, para contornar isso, usamos a seguinte estratégia: 1 - Boleto é gerado, salvo em uma pasta; 2 - A API pega esse arquivo gerado e envia para o S3; 3 - Pegamos o arquivo diretamente no app que vai demonstrar e exibimos como um Iframe PDF; Também é possível ao invés de enviar para o S3, abrir o arquivo converter em Base64 e devolver para que seja exibido.
-
Ok, obrigado.
-
Bom dia pessoal, Estou com a seguinte duvida, gostaria de saber como posso fazer para personalizar a mensagem de juros. Atualmente a mensagem é: Gostaria de ter o valor em reais junto e não somente o percentual. Por exemplo: Como posso fazer esse ajuste na lib?
-
Testado com nova versão da Lib. Tudo certo agora. Obrigado.
-
Refiz o teste com CodigoMoraJuros e também não funcionou, só que agora até o boleto fica com o valor errado.
-
Já estou passando o campo CodigoMora = 2 Conforme manual https://acbr.sourceforge.io/ACBrLib/ModeloTituloINI.html e https://acbr.sourceforge.io/ACBrLib/IndicedeCodigosTituloINI.html Estou usando a Lib com C#.
-
Bom dia, Estou com o seguinte problema na minha integração com o banco AILOS. Gerei um boleto com juros de 1% ao mês No boleto aparece tudo certo, porém na remessa ele manda o codigo 1: Pesquisando na documentação da Ailos: Para taxa mensal o valor na remessa deveria ser 2. Entrou anexando a remessa abaixo. Poderiam me auxiliar? 20200609061152507-10906202018115200015508700000.rem
-
Bom dia, Realizei um teste com o lock e mais algumas alterações no meu projeto e funcionou. Apesar disso gostaria de ressaltar a importância de termos a lib funcionando com multithread. Por mais que tenha funcionado, acabou limitando a utilização da API que estava construindo e prejudicando a performance. Creio que essa seja uma evolução muito importante para a lib, tanto tecnicamente quando em questão de negócios. Aguardo novidades. Obrigado
-
Muito obrigado. E sobre a questão: Tem alguma previsão/planejamento para que isso ocorra?
-
No meu caso o LimparLista não resolveu, pois as requisições são simultaneas, quando limpa a lista da primeira a segunda esta processando;. Tem alguma previsão/planejamento para que isso ocorra? Tem como eu acessar o código da lib pra ver como ela está implementada?