José M. S. Junior

Realmente, Sicredi não vai permitir 1. Veja o que diz manual:

Bom dia, informe assim: CodigoGeracao=1

Boa tarde, por padrão define que o cliente emite... Preencha o campo "CodigoGeracao" do título como "1"

Boa tarde, por padrão define que o cliente emite... Preencha o campo "CodigoGeracao" do título = "1"

Boa tarde, por favor atualize os fontes do componente Boleto e do ACBrMonitor e Recompile o projeto para testes...

Correto, mas me refiro também ao modelo do boleto no manual pela maioria dos Bancos e FEBRABAN . Se a mensagem de Juros de Mora é em "%" o padrão é Mensal. Pelo que verifiquei para CNAB400 a maioria dos outros bancos utilizam apenas valor por dia... Por isso a mensagem da forma que estava não havia sido identificada ainda. Mas para Bancoob, realmente causa problema da forma que está... Vamos verificar para atutualizar no SVN. Obrigado!

Boa tarde, Compreendi o problema... Mas o erro parece estar na Unit do banco BANCOOB em não validar o CodigoMora... para verificar se é por dia ou mensal antes de realizar esse cálculo... Da forma que estava a mensagem no boleto estava errada... Veja especificação padrão FEBRABAN:

Boa tarde, Faltou mais um parâmetro como "0" ... Você informou 0 para o número de cópias: https://acbr.sourceforge.io/ACBrMonitor/NFEImprimirEvento.html

É para ser o número do convênio do cliente. Pode configurar esse campo em dados do cedente...

Bom dia Obrigado, será corrigido... Se encontrar outras divergências, por favor poste aqui os fontes alterados, assim podemos atualizar no SVN...

Bom dia. Conforme mencionado, não se trata de travamento... quando utiliza o Preview, obrigatoriamente o Monitor fica preso até que a tela do preview seja fechado. Isso pode dar a sensação de travamento se sua aplicação continuar enviando comandos... Não vai obter resposta até que o preview seja fechado...

Bom dia. Repare que a função FormataNossoNumero() gera o nosso numero baseado nas regras do banco, verificando a carteira e o convênio... O que a função NossoNumeroSemFormatacaoLerRetorno() faz é o contrário... Apenas separar os campos que foram concatenados, baseando-se na mesma regra...

O método ImprimirEvento tem um parâmetro para mostrar ou não o preview, passe "0", para não mostrar preview. Utilizando o preview deverá fechar a tela antes de passar o próximo comando...

Boa tarde, precisa do relatório detalhado gerado pelo banco, para saber qual campo não está sendo informado...

Boa tarde, Por padrão sempre utiliza a impressora padrão configurada no ACBrMonitor, quando não é informado via parâmetro. Porém, a mesma deve estar acessível e com o mesmo nome definido no Windows. Esse problema é aleatório? Se necessário, anexe o log do ACBrMonitor para verificação...

Bom dia. Não compreendi o que precisa... Se é o banco que gera o boleto, por que necessita gerar novamente? Outro detalhe é que o componente também utiliza Modulo 11 para calcular o dígito (conforme especificação do manual) se tratando do mesmo número o dígito deveria ser o mesmo...

Me refiro a verificar se o campo ValorAbatimento que é preenchido está sendo passado na função que gera a remessa conforme CNAB que utiliza.... Ou verifique na remessa gerada se está sendo preenchido o campo na posição correspondente, baseado no manual do banco. Caso esteja informado na remessa, contate o banco para saber se é necessário passar mais alguma informação...

Bom dia É necessário analisar o código de geração de remessa acompanhando o manual para identificar onde pode estar gerando com tamanho menor que esperado. Provavelmente quem utiliza este banco não identificou esse problema.

Bom dia, chegou a validar nos fontes? verifique se está sendo passado os valores na Geração da remessa...

Bom dia. Fontes adicionados no SVN, favor atualizar e realizar os testes. Obrigado!

Boa tarde, atualize os fontes do ACBr e recompile o projeto. Isso já foi ajustado recentemente...

Bom dia @estinque, existem muitas inconsistências entre o seu fonte e o fonte disponível no SVN. Não há como compatibilizar fazendo uma simples comparação... Se possível, baixe os fontes do SVN e aplique as suas correções baseado no fonte do SVN, assim poderemos atualizar com estes e outros possíveis ajustes... Obrigado.

Bom dia, Aparentemente a posição 103 trata-se da ocorrência original enviado na remessa. Veja que a ocorrência de retorno é lida no campo "CodOcorrencia" já está utilizando a posição 109.

Bom dia, essa alteração não foi disponibilizada a principio, pois causará quebra de compatibilidade para todos que já utilizam esse banco... Comparando com outros bancos cada um utiliza um campo diferente nessa posição (Cedente, convenio, Transmissão) parece ser uma questão de interpretação... Note também que quebraria a compatibilidade na função para LerRetorno, que está sendo tratado também como codigoCedente.

Correções disponibilizadas no SVN...