marcianobandeira

Bom dia Senhores(as), Estou homologando o layout do banco sofisa (correspondente santander), desenvolvimento por @Grupo IN4 , discutido no topico Na geração da linha do registro da remessa CNAB400, está utilizando o percentual da multa, porém, formatando com apenas duas casas decimais. No proprio manual anexado no referido topico, tem-se a observação acerca da necessidade de utilizar 4 casas decimais quando utiliza-se o percentual. Segue print do manual e unit alterada. Grato. ACBrBancoSofisaSantander.pas

Boa tarde, atualizei meus fontes e esta tudo ok. obrigado.

Boa tarde Obrigado pela diga dos anexos, agora tenho 2mb de espaco hehe Consegui os manuais da remessa cresol, estou enviando anexo. Att.Manual-Cobrança-Integrada-Cooperado 240.pdfintegrada-remessa-cnab400-cresol 133.pdfBoleto exemplo.pdf

Boa tarde companheiro, nao tenho manual. Tamém não consigo anexar prints aqui com essa limitação de 2kb de tamanho total do arquivo. Inicialmente eles queriam que fosse removido o dígito na impressao: "Segue abaixo ajuste necessário, após ajuste favor enviar novos boletos e remessa para validação. Boleto Código Banco: remover o código 2, informando somente 133" O dígito 2 realmente está errado, pois ele é referente ao bradesco, conforme explicado na primeira mensagem do topico. Analisando os fontes da impressão do boleto em Fortes Report, percebi que não há configuração que permita imprimir ou não o dígito. Desse modo, para não ter meus fontes divergentes do SVN, já que tem todo um tramite para conseguir subir alterações, busquei a alteração menos traumática, qual seja, corrigir o dígito do banco, alterando-o para 3. Após alteração recebi a seguinte mensagem por email: "Em verificação juntamente a compe foi repassado que pode ser utilizado o código 133-3 conforme informado pelo seu e-mail anterior." Assim sendo, caso não seja possível subir a alteração para o SVN, peço que desconsiderem então.

opa boa tarde, com essa alteração conseguimos realizar a homologação com sucesso junto ao banco. O arquivo de remessa já estava ok, apenas barraram a impressão do boleto, após ajuste, aceitaram.

Bom dia, Estou fazendo homologação de um cliente para o banco cresol 133, utilizando a classe TACBrBancoCresol que por sua vez, herda de TACBrBancoCresolSCRS. O pessoal do banco questionou quanto ao digito que saia na impressão do boleto, 133-2. Analisando aqui, percebi que isso está vindo da classe base, que usa os dados do bradesco, que por sua vez possui o dígito 2. Utilizando o cálculo com Modulo 11 cheguei ao digito 3 para cresol, ou seja, 133-3, o pessoal do banco aceitou a impressão desta forma. Então estou enviando o ajuste na classe para que possam avaliar e incorporar ao SVN. Grato. ACBrBancoCresol.rar

Seria uma classe mesmo, por exemplo: instancio o objeto TACBrBoleto, em sua propriedade Banco.Cobranca eu indico cobDaycoval. Apos isso, na propriedade Banco.BancoClass eu atribuo minha classe customizada. Isso eliminaria a necessidade de alterar o fonte original do ACBr (o que sempre me deixa de cabelo em pé porque depois tenho que analizar todas as vezes que faço um update no svn). e elimina a necessidade do código passar por moderação, afinal a classe só vai estar no meu código.

Boa tarde, Existe a possibilidade de deixarmos um write publico para a propriedade BancoClass da classe TACBrBanco? Os motivos seriam simples, existem varios "bancos de atacado", como belamente explicado pelo nosso amigo @windsoft "Daycoval, Industrial e Safra, são bancos de atacado. Bancos que atendem à médias e grandes corporações, estes bancos não possuem ou possuem pouquíssimas agências, portanto é inviável pra eles e para os clientes fazerem cobrança diretamente por eles, visto que, ainda hoje, o boleto vencido só pode ser pago no próprio banco. Desta forma, estes bancos utilizam-se de bancos correspondentes, (Itaú/Bradesco). Então os arquivos de remessa que são enviados para os bancos possuem o código do próprio banco, porém a emissão dos boletos seguem os padrões estabelecidos pelos bancos correspondentes (Itaú/Bradesco). Por isso a "confusão" com os números dos bancos e a necessidade de se criar os layouts mistos, tipo SafraBradesco, IndustrialItau, etc." De modo que, a classe TACBrBancoDaycoval por exemplo, não atende todas as necessidades. Há casos em que o banco daycoval utiliza o Itau como banco corresponde. Sendo assim, no exemplo acima, a impressão do título sai com o layout do itau, mas a remessa sai com layout próprio do banco daycoval. O amigo @windsoft disponibilizou em outro post alguns fontes, dentre eles a classe TACBrBancoDaycovalItau, que atenderia a situação exemplificada acima, porem o post é de 2017 e acabou não sendo incorporado ao projeto. Entao gostaria de sugerir um meio termo, que poderia ser feito de varias maneiras, mas uma solução simples, seria colocar um metodo write para a propriedade BancoClass da classe TACBrBanco. Sendo assim, cada desenvolvedor que se deparar com uma situação como essa, pode criar uma Custom Class para atender sua necessidade, sem que seja necessário mexer nos fontes do ACBr, o que por vezes acaba gerando incompatibilidade futura e conflitos de código. Obrigado.

show de bola @walfrido

Bom dia Senhores, Estou realizando a homologação do boleto junto ao banco abc brasil, e percebi um problema ao calcular o digito verificador do nosso numero. Atualmente está sendo utilizado o campo modalidade: Modulo.Documento := ACBrTitulo.ACBrBoleto.Cedente.Agencia + ACBrTitulo.ACBrBoleto.Cedente.Modalidade + ACBrTitulo.NossoNumero; Contudo, é necessário alterar para o campo carteira: Modulo.Documento := ACBrTitulo.ACBrBoleto.Cedente.Agencia + ACBrTitulo.Carteira + ACBrTitulo.NossoNumero; Segue a planilha de cálculo fornecida pelo banco. PS: Só tenho permissão para upload de até 10KB portanto não foi possível anexar a Unit alterada. DV Nosso Número ABC.rar

Boa tarde, Meu problema era no mesmo sentido do colega @valdirdill Ocorria ao gravar o nosso numero completo e depois ter problema ao preencher o nosso numero no componente. Contudo, agora ficou mais claro, acho que dessa forma como esta agora é melhor, já que antes o próprio componente fazia os tratamentos pegando apenas os 5 digitos deixando uma falsa sensação ao desenvolvedor de estar tudo ok. Com a nova abordagem fica mais claro ao desenvolvedor. Obrigado.

Boa tarde Senhores, Passei a ter alguns problemas com a emissão de boletos do sicredi. Ao analisar as últimas alterações no SVN notei que no dia 09/03/2020 houve uma mudança em relação ao tamanho máximo do nosso numero. Antes da revisão do SVN era: fpTamanhoMaximoNossoNum := 8; Após a revisão passou a ser: fpTamanhoMaximoNossoNum := 5; Não sei se mais alguém passou a ter problemas com isso, também não consegui encontrar o tópico que motivou essa alteração. Segue os dados da revisão em questão: Revision: 19353 Author: juniorsantos Date: segunda-feira, 9 de março de 2020 14:42:10 Message: -- ACBrBancoSicred -- [-] Ajuste na Validação da função CalcularTamanhoMaxNossoNumero. ---- Modified : /trunk2/Fontes/ACBrBoleto/ACBrBancoSicredi.pas Modified : /trunk2/Fontes/ACBrBoleto/ACBrBoleto-change-log.txt Grato

Boa tarde, Alterei a classe do bancoob para trabalhar com a negativação. Utilizei os mesmos moldes da classe do banco do brasil discutido no topico Negativação BB Segue em anexo a unit alterada, e print do manual na parte em que se refere à negativação. Não consegui enviar o manual devido a limitação do tamanho dos anexos. Negativacao Bancoob.zip

Bom dia, O manual atualizado do banco do brasil (Manual_CNAB_240_-_PARTICULARIDADES_BANCO_DO_BRASIL_2019.pdf) disponível em https://www.bb.com.br/docs/pub/emp/empl/dwn/CNAB240SegPQRSTY.pdf Contempla o Código 8 - Negativação sem protesto na pagina 11, conforme imagem em anexo. Att,

Bom dia, conversei com um contador experiente aqui, chegamos na conclusão que o melhor a ser feito é criar um campo para informar a aliquota de icms desonerado, de modo a poder informar o valor que seria a tributação do produto caso não houvesse a desoneração/isenção. Vou partir por essa linha.