Juliana Tamizou

Bom dia. Obrigada pela dica, iremos corrigir e postar no svn. Att.

Bom dia. Atualmente o ACBrBoleto não tem suporte a esse tipo de boleto. Seria algo como as faturas e cartão de crédito? Att.

Bom dia. Problema 1 O ideal seria verificar com o banco se o retorno sempre virá no padrão SICOOB, se sim basta configurar o componente para este banco antes de ler o retorno. Problema 2 Antes de dar continuidade é necessário descobrir qual o problema que está ocorrendo, o suporte do banco com toda certeza poderá explicar. Att.

Bom dia. Data de Processamento - Citada no post anterior. EspécieDoc - Está correto no gerador que temos usado (qual é o gerador que vc detectou esse problema?) EspécieMod - Qual a necessidade de imprimir algo diferente de "R$"? Att.

Bom dia. A Data do Processamento se refere a quando o título foi processado pelo banco, por isso não é impressa no boleto, uma vez que é uma informação constante no arquivo de retorno. Quanto ao layout da Febraban, seria muito pouco provável o desenvolvimento de uma rotina única para qualquer banco, uma vez que todos eles fizeram adaptações no layout tornando-o incompatíveis entre si. Acredito que falta colocar no ACBrMonitor um comando ou algo assim para que a lista de títulos lida no comando LeRertorno seja copiada para um arquivo ini ou algo assim.

Bom dia. Se você mandar imprimir sem visualizar o boleto antes, o problema tb ocorre? Att.

Bom dia. Você deve enviar um remessa com o tipo de ocorrência toCancelar. Att.

Bom dia. Você precisa ter as informações referentes a conta e carteira de cobrança do cliente disponíveis em seu sistema. A remessa serve para que você registre os boletos emitidos junto ao banco, e o retorno para que você possa dar baixas considerando as informações deste arquivo, para tanto é necessário que informações como Nosso Número, Valor, Vencimento, Cliente e etc...estejam armazenadas em seu banco de dados. Att.

Bom dia. Seus fontes estão em sincronia com o svn? Observe que no dia 20/02 foi enviada uma correção para este problema. Att.

Bom dia. Vai sim . Att

Boa noite. A alteração postada neste tópico resolveu o problema ? Att.

Boa noite. Você tentou efetuar a leitura pelo caixa eletrônico? Att

Boa noite. Você validou novamente os boletos junto ao banco? Att.

Boa noite. Correção disponível no svn. Att.

Boa noite. Realmente estava errado o campo utilizado na função CalcularDigitoVerificador, se possível anexe aqui o fonte alterado a pós a validação do banco. Att.

Boa noite. No demo do componente você encontra exemplos de como efetuar os procedimentos. Qual é o exato problema que você está tendo? os boletos não estão sendo gerados ou não estão sendo lidos pelos leitores? Att.

Boa noite. Correção disponível no svn. Att

Boa noite. Correção disponível no svn. Att.

Boa noite. Faixa N. Número (02) (Obrigatório) , este campo é variável por conta ou cliente do banco ? ou o valor 02 é fixo para todos os clientes? Com base em como foi implementada esta classe acredito que seja uma informação variável, se possível verifique junto ao banco para que a correção possa ser aplicada corretamente. Att.

Boa tarde. Qual componente para impressão dos boletos vc está utilizando? Att.

Bom dia. Se o problema continua ocorrendo, informe aqui os valores passados ao componente para a geração do boleto no qual o DV ficou errado. Att.

Bom dia. O campo 29 é o dígito d agência? Oque vc quis dizer com a agência não sai? já pelo tamanho do campo que está incorreto só poderia ser o dígito faltando. Att.

Bom dia. O svn está atualizado sim, porém não exatamente igual aos arquivos anexos, porém o arquivo já pode ser gerado. Att.

Bom dia. Provavelmente você não informou algum campo que é necessário para que a linha digitável seja calculada corretamente... Att.

Bom dia. Você de usar o tipo de cobrança cobBancoob para este banco. Att.