José M. S. Junior

Bom dia, se possível anexe o log da lib...

Bom dia, O formato que está sendo passado no .ini não está fora do padrão DD/MM/YYYY veja: no ini está 8/17/2020 Precisa gerar o .ini assim Vencimento=17/08/2020

Bom dia, sim... Se o e-mail do sacado já estiver informado em cada título, não será necessário informar novamente em cada método, mas o envio em si precisa ser realizado título a título. Estes métodos de Geração de boletos e envio de forma individual são recentes, precisa atualizar a versão.

Boa tarde Para envio com destinatários diversos utilizando uma mesma lista, precisa utilizar o método abaixo, percorrendo a lista passando o indice do título que deseja enviar https://acbr.sourceforge.io/ACBrMonitor/BOLETOEnviarEmailBoleto.html

Boa tarde Certifique se realmente está sendo passado ValorMoraJuros, os demais campos só serão preenchidos se esse campo for maior que 0.

Para o Banco do Brasil é enviado um XML, seria esse arquivo Registro_Boleto.xml que voce anexou acima... Mas pelo erro reportado o problema agora está no cadastro do Beneficiário junto ao banco.

Ok Kelvin, a sua aplicação passa o valor do documento sempre já arredondado com duas casas decimais para o componente Boleto?

Este problema realmente parece ser algo muito específico no ambiente, até mesmo por ser aleatório... Caso contrário teria muitos relatos sobre isso... Note que o campo "ValorDocumento" tem um SET setValorDocumento, onde sempre ANTES de chegar na geração do código de barras ou na remessa, passa por essa função e já realiza o arredondamento de duas casas seguindo padrão ABNT. Quando chega na função MontarCodigoBarras, o "round" apenas utiliza o valor inteiro (já multiplicado por 100). Certifique se realmente não está chegando o valor com 3 casas decimais na procedure "setValorDocumento". Por exemplo 381,406, nesse caso sim arredondaria com 0,01 centavo. Poderíamos alterar conforme sugerido, mas note que todas os campos de valores e todas as classes de Bancos utilizam o round, nesse caso afetaria todos os demais valores também... e o ideal seria revisar todo o componente Boleto se fosse o caso.

Correto... Essa funcionalidade é recente, está nas novas versões.

Pelo que entendi no outro post você utiliza o ACBrMonitor... Se sim, pode utilizar esses dois métodos: https://acbr.sourceforge.io/ACBrMonitor/CNPJConsultarCaptcha.html https://acbr.sourceforge.io/ACBrMonitor/CNPJConsultar.html

Bom dia, conseguiu identificar o problema na autenticação? Se possível compartilhe a solução, assim podemos investigar melhor o código genérico do erro... Quanto ao retorno, o nome dos campos são outros mesmo... Note que o problema é código do Beneficiário e não do Pagador, provavelmente é alguma inconsistência do cadastro do Beneficiário no Banco, precisa passar esse erro para eles analisarem.

Sim, mas a pasta Enviados são apenas os XMLs Criados pelo componente, note que são apenas as tags passadas pela aplicação comercial. A pasta Vendas que contem os XMLs autorizados e assinados pelo aparelho SAT, esse sim é retornado pelo SAT...

Precisa realizar um debug mesmo... tente identificar se o está tendo algum retorno na autenticação. Essa função fica na classe ACBrBoletoWS

Se está funcionando com os dados em homologação no demo era para funcionar com seus dados... Precisa tentar depurar para ver exatamente onde está ocorrendo esse erro. Quando a requisição do BB é XML mesmo... segue a documentação. Apenas a autenticação OAuth retorna um JSON, note que isso é tratado internamente no componente. Pode capturar esse retorno na função: ProcessarRespostaOAuth

Bom dia, verifique se todos os fontes do Boleto estão atualizados conforme está no SVN, se você utiliza classes do ACBr no seu projeto, precisa declarar a uses: ACBrBoletoConversao Dê uma olhada nesse tópico:

Bom dia, note que agora não é mais erro de comunicação com Serviço de Autenticação e sim erro na validação de credenciais. KeyUser é a chave padrão: J1234567 até onde eu sei está sendo utilizada essa chave também em produção, mas precisa confirmar com o Banco. Este IDClient já está liberado para integração em Homologação e Produção?

Esse erro é o retorno do próprio aparelho, infelizmente não é especifico qual é o erro... Normalmente é erro de dados no xml. Para validar o xml de venda pode utilizar uma ferramenta da Tanca o "InteliSat", esse aplicativo voce pode carregar o xml de venda e validar os dados http://www.tanca.com.br/drivers.php?cat=24&sub=43

Esse arquivo não pode ser salvo como XML. Deve ser um arquivo .INI (extensão .ini)

Boa tarde, CFe.ini seria o arquivo .ini com os dados do seu cupom. deve seguir o exemplo do manual para preenchimento das tags. Lembrando que pode passar o conteúdo desse arquivo .ini direto no parâmetro, vai funcionar da mesma forma, desde que as tags estejam devidamente preenchidas Precisa preencher apenas campos obrigatórios do SAT, veja esse arquivo simplificado: https://acbr.sourceforge.io/ACBrMonitor/ModeloCFeINISimplificadovalido.html

Boa tarde, no diretório do Demo ACBrBoleto tem um arquivo .txt (configWebService.txt) com os campos obrigatórios para Integração com BB. Se estiver utilizando a configuração HTTPLib com OpenSSL, precisa ter as dlls da openSSL no diretório do executável.

Bom dia, você tem o manual atualizado com essas especificações? Se possível anexe o mesmo aqui para validação.

Bom dia Seguindo o padrão Febraban do boleto impresso e também dos demais bancos implementados, quando o valor é por dia, o mesmo já é calculado baseado no percentual e informado o valor diário em R$ na impressão ... Aparentemente o pessoal utiliza assim para o Sicred. Outra opção é desmarcar a propriedade "ImprimirMensagemPadrão" e informar a própria mensagem com percentual em dias.

Bom dia O campo "MultaValorFixo" define se é Valor ou percentual, informe "1" para Valor e "0" para percentual.

Neste retorno não tem registros com os segmentos... Aparentemente está apenas as duas linhas do header e duas linhas do trailler.

Boa tarde. Isso é estranho, pois tem muita gente já utilizando este boleto, se fosse um problema genérico teríamos relatos... Na verdade o padrão para gerar o código de barras é único para todos os bancos, o que muda é a sequencia numérica. Chegou a ver se não é problema com a impressão, ex: imprimir de outra impressora...