Jump to content

Dev Telluria

Membros Pro
  • Posts

    78
  • Joined

  • Last visited

Everything posted by Dev Telluria

  1. Obrigado @José M. S. Junior! Agora está correto!
  2. Boa noite @José M. S. Junior! Essa versão funcionou! Gerou o arquivo corretamente! Iremos utilizar essa versão provisória até voces resolverem a questão da disponibilização da lib. Vou deixar este tópico aberto até esteja tudo normalizado! Muito obrigado pela atenção!
  3. Boa tarde @José M. S. Junior. Estamos utilizando a versão ST. Realizamos o teste com essa versão que vc disponilizou e agora está dando erro na inicialização da biblioteca: Segue em anexo o arquivo ini de configuração e o log. Outra coisa que verifiquei é que esse build que vc gerou está com o número da versão 0.2.0.157 (que é bem anterior a essas que estávamos testando) ACBrLib.ini ACBrLibBoleto-20220520.log
  4. Bom dia. Certo. Realmente, achei aqui o commit do José Junior de 2 dias atrás que deveria ter resolvido o problema: Peço desculpas pela minha insistencia, mas é que realmente estamos com muita urgencia nesse caso... E já estamos atrasados com nosso cliente, pois informamos um prazo mais curto pensando que o Daycoval já estaria 100% homologado no ACBr. Peço por favor que, se possível, seja priorizado a resolução desse problema de disponibilização da lib com a correção.
  5. Boa noite! Verifiquei no projeto de vocês no GitHub, na master, no arquivo https://github.com/ProjetoACBr/ACBr/blob/master/Fontes/ACBrBoleto/ACBrBancoDaycoval.pas (linhas 483 e 509), o seguinte trecho da procedure "TACBrBancoDaycoval.GerarRegistroTransacao400": Verifiquei que função DefineTIpoInscricao retorna apenas um caractere. Acredito que não possa alterar o retorno dela pois tbm é usada pra outros bancos. Então fiz uma alteração na linha 483 acrescentando um zero à esquerda, como vi que já era feito em outros bancos, ficando assim: Peço por favor que, se possível, analisem o pull request que enviei e disponibilizem uma nova versão com a correção para que possamos testar novamente.
  6. Boa tarde! Alguma posição referente ao meu último questionamento? Verificamos que vcs disponibilizaram a versão 0.2.0.179, baixamos e tentamos utilizar ela, mas continua com o mesmo comportamento errado.
  7. Está bem! Obrigado! Aguardamos seu retorno. Caso seu teste continue gerando correto, é possível olhar no código fonte se há alguma configuração que talvez estejamos passando errado que possa gerar essa posição com um caractere e não dois? (Não faz muito sentido), mas é estranho pq na versão anterior que gerava o valor errado estava formatando corretamente.
  8. Dessa vez a versão da lib está correta, eu conferi no log gerado: E mesmo nessa versão está gerando o arquivo assim: Segue em anexo o log e o arquivo de remessa gerado. 4VV18051.TXT ACBrLibBoleto-20220518.log
  9. Boa tarde! Favor desconsiderar a mensagem anterior.... Havia 2 arquivos da DLL com versões diferentes na máquina de testes e estava pegando a versão errada. Porém, o problema agora é outro: Ele está colocando essa posição como "2" em vez de "02", o que está fazendo com que todas as posições após essa comecem um caractere antes, aí a linah fica com 399 posições em vez de 400. (Acontece dessa forma tanto na versão "0.2.0.177" quando na "0.2.0.178")
  10. Acabamos de testar na versão "0.2.0.178" e continua gerando a posição com o valor errado. Vcs testaram gerar o arquivo com os INI que enviei? Verificaram o conteúdo do arquivo gerado? No caso está ficando errado na LINHA 4 do arquivo (referente ao título 2), na posição 2 a 3.
  11. Bom dia! Referente ao registro de NFe, realizamos o teste gerando o arquivo INI conforme a nova documentação e o erro de "Out of Memory" parou de ocorrer. Obrigado! Enviamos o registro gerado para honologação junto ao banco e estamos aguardando o retorno. Quanto à questão do tipo de inscrição que continua gerando errado, tem alguma posição?
  12. Segue log em anexo. ACBrLibBoleto-20220517.log
  13. SIm, estamos passando o Cedente.TipoPessoa=1 , conforme arquivo INI do cedente que enviei em anexo em uma das respostas anteriores. (Continuo usando o mesmo arquivo INI para o cedente) Estou anexando outro arquivo INI de títulos (com mais registros) onde em um deles o tipo de inscrição do Sacado é Pessoa Física. No caso, apenas o registro onde o sacado é pessoa física está ficando a posição 2. Cedente.ini Titulos.ini
  14. Boa tarde, utilizando a versão "0.2.0.177" da DLL realizamos o teste e continua gerando errado a posição 2 a 3 do registro de título. Conforme eu disse inicialmente, a lib está considerando a informação do Tipo de inscrição do sacado, em vez de considerar o tipo de inscrição do cedente para gerar essa posição.... acredito que deve estar sendo usado a mesma variável que é utilizado na posição 219 a 220 (essa posição está correta, nessa sim deve ser utilizado o tipo de inscrição do sacado). Referente a essa mudança na montagem da seção referente à NFe ainda vamos realizar as alterações e testar e retornamos. Mas de qualquer forma já peço que seja verificado a questão do tipo de inscrição que permanece errado.
  15. Ok! Estamos aguardando! Obrigado! Ps.: Lembrando que esse erro só ocorre quando adicionamos a seção da NFe, carregando o INI dos títulos sem essa seção gera o arquivo normalmente.
  16. Estamos utilizando a versão da DLL ACBrBoleto32.dll = 0.2.0.168 (Creio que esteja bem atualizada). Segue em anexo arquivos INI utilizados (ACBr.ini, Cedente.ini, Titulos.ini) onde ocorre o erro "Out of memory" ao chamar a rotina de geração do arquivo de remessa. Tbm anexei o log do ACBr para análise. ACBrLib.ini ACBrLibBoleto-20220516.log Cedente.ini Titulos.ini
  17. Vamos verificar qual o valor tenho que informar para esse campo "Operacao" no cedente e tentar gerar novamente. E depois envio os arquivos INI com as informaões corretas.
  18. Não, é a LibBoleto mesmo. Na geração de remessa de cobrança bancaria há uma seção para acrescentar informações de NFe, conforme citado acima. Porém na documentação há um comentário que isso seria específico para o banco Pine, e no caso o banco que está pedindo essa informação como obrigatória é o Daycoval... E quando preenchemos essa informação na geração do arquivo ocorre um erro, conforme eu expliquei no meu comentário anterior.
  19. Outra questão também é sobre a NFe, que na documentação do INI do título diz que essa seção é apenas para o banco Pine, e quando tentamos preencher essas informações, na geração do arquivo fica travado por algum tempo e depois retorna um erro de "out of memory" (estamos utilizando o código do projeto demo VB6 que vocês disponibilizam)
  20. Boa noite! Obrigado pelo retorno! O campo "Cedente.Operacao" que você citou não consta na documentação referente ao .ini do cedente: https://acbr.sourceforge.io/ACBrLib/ModeloCedenteINI.html Essa documentação está desatualizada? E sobre a posição 2, há uma previsão de quando a correção será liberada?
  21. Boa tarde. Estamos tentando homologar a remessa CNAB 400 para o banco Daycoval, porém o banco retornou algumas inconsistencias no arquivo: >LAYOUT -> ACERTO NO DETALHE Posicao 002 a 003 Campo tem que ser = '02' (Verificamos que nessa posição a LibBoleto está montando com a informação referente ao tipo de inscrição do sacado, e não do cedente, a informação de tipo de inscrição do sacado deve ser apenas na posição 219 a 220) -> REGISTRO DE NFE OBRIGATÓRIO NO ARQUIVO! VERIFICAR INSTRUÇÕES EM NOSSO LAYOUT PARA DESENVOLVIMENTO DO REGISTRO DA NOTA FISCAL ELETRONICA. >ACERTO NA LINHA DIGITAVEL -> SEU BOLETO / ERRADO - 7079000118 21008458016 0604 5 90120000002000 -> VALIDADO / CORRETO - 7079000118 21184870406 08458010603 7 90120000002000 >ACERTO NO CODIGO DE BARRAS -> SEU BOLETO / ERRADO - CÓDIGO DE BARRAS COM ERRO NA LEITURA -> VALIDADO / CORRETO - 70797901200000020000001121184870400845801060 Alguém pode nos ajudar? Estamos com urgencia na homologação deste banco junto a um cliente.
  22. Bom dia! Desculpa a demora, estamos validando essa opção do TimeOutPorThread. Muito obrigado!
  23. Boa tarde! Conforme mostra a imagem a seguir o XML está sendo gerado no tempo exato do log. Sobre realizar o mesmo teste com o aplicativo de demonstração, é complicado pois o problema acontece em produção e não acontece em todos os clientes, além disso apesar da frequência com que o problema ocorre, não é possível prever quando ele irá ocorrer. Sobre o problema ser no método Ultimo_Retorno do lado da aplicação, em nossa solução não comunicamos diretamente com a DLL, nós importamos os projetos ACBrLib.Core e ACBrLib.Core do exemplo de demonstração e em nossa solução e utilizamos a classe ACBrNFe para realizar a chamada dos métodos da DLL. Sobre
  24. Entendi. Vou verificar o que me recomendou. Muito obrigado!
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.