Juliana Tamizou

Bom dia. Qual versão do ACBrMonitor você está utilizando? realizei testes com seus arquivos e os boletos foram impressos normalmente. Att.

Bom dia. Correção disponível no svn. Att.

Boa tarde. Não tem nenhum regra especifica Santander...qual foi o Nosso Número e o DV informados no arquivo e quais valores seriam os corretos de acordo com o banco? Att.

Boa tarde Sandro. Acredito que o ideal é o componente conseguir identificar esse tipo de boleto e neste caso a função FormataNossoNumero não efetuar nenhuma modificação no mesmo... Você teria um exemplo de como fica o NossoNumero gerado pelo banco? Att.

Boa tarde. Em outro trecho do manual tem a seguinte instrução: "Código numérico correspondente ao tipo de cobrança: “1” – Com Registro “3 – Sem Registro”." Sendo assim a comparação atual está correta. Att.

Bom dia. As alterações estão no svn. Att.

Bom dia. De acordo com as informações que vc disponibilizou, vc não está informado o campo CodigoCedente que é o campo que contém o Código do Cedente. Att.

Bom dia. A impressão irá para a impressora definida como Default no windows Att.

Bom dia. Modificações disponíveis no svn. Att.

Bom dia. Infelizmente como disse no inicio, alguns bancos são mais rigorosos e uma alteração assim com certeza invalidaria a homologação dos boletos, outro fato é que normalmente o desconto é concedido com algumas regras, como por exemplo desconto por dia de antecipação ou desconto por pagamento até determinada data, por isso acredito que o ideal seja manter como está. Att.

Bom dia Francisco. Este não é um arquivo de retorno padrão CNAB, você deve verificar junto ao banco como obter o arquivo correto. Att.

Bom dia. Por favor anexe aqui a unit alterada para facilitar o merge. Att.

Boa tarde GIlberto. Qual é o conteúdo do seu ent.txt? Att

Bom dia. As especificações da disposição das informações do boleto vem dos próprios bancos, se for feita uma mudança deste tipo os bancos não homologariam os boletos. Att.

Bom dia. Se possível anexe o arquivo aqui, mas aparentemente este não seria o arquivo de retorno no layout dos manuais fornecidos pelo banco. Att.

Bom dia. Ainda não foi possível, mas acredito que nesta semana será. Att.

Boa tarde. Quais parâmetros e quais valores foram informados ao componente ? Att.

Bom dia. Você tem razão..irei aplicar a correção Att.

Testando pelo demo ocorre o mesmo problema ? Att

Boa tarde. A modificação foi feita para garantir que fossem sempre copiados os 7 últimos dígitos do NossoNumero, uma vez que devido a haver locais onde o campo fica maior na implementação anterior poderia ocorrer de não serem copiados exatamente os últimos dígitos. Att.

Correção final para arquivo remessa CNAB400 disponibilizada no svn, na próxima compilação do executável do ACBrMonitor a mesma estará disponível. Att.

Boa tarde. Quanto ao problema de quebrar os boletos com comprovante de entrega em 2 partes, estará resolvido na próxima versão do instalador do ACBrMonitor, para driblar o problema basta que você utilize o layout padrão. Quanto a remessa está sendo analisado. Att.

Bom dia. Para que possamos analisar anexe aqui a unit alterada. Att.

Bom dia. Apesar de existir um layout pré-determinado pela Febraban, cada banco acabou fazendo suas adaptações... no caso do Banco do Brasil existem pelo menos 3 layouts diferentes, porém o ACBrBoleto é capaz de processar a maioria deles. Att.

Bom dia. É possível capturar o nosso número calculado pelo componente e gravar em seu banco de dados, dessa forma nos casos que existe a formatação exigida pelo banco você consegue localizar mesmo assim. Nos casos em que a emissão do boleto é feita pelo banco e eles mesmos geram o NossoNumero, imagino que sempre deverá existir o arquivo remessa, caso contrário, como o banco saberia informações como Valor, Vencimento e os demais dados específicos de cada boleto? Att.