marcianobandeira

Boa tarde. Isso se aplica ao SITEF... Para impedir que fique exibindo perguntas como: A vista ou parcelado... crédito ou débito... etc... eu uso a OperacaoCRT e as Restrições. Por exemplo, em uma venda que eu quero indicar cartao de crédito parcelado... ACBrTef.CliSitef.OperacaoCRT := 3; // crédito ACBrTef.CliSitef.Restricoes := '16;26;28;36'; No caso das restrições, esses códigos estão no manual do sitef.. mas basicamente estou restringindo: 16 Cartao de Debito a Vista 26 Cartao de Credito a Vista 28 Cartao Parcelado pela Administradora 36 Consulta de Parcelas no Cartao de Credito Caso esteja aparecendo outras opções voce vai restringindo... no final só vai sobrar a opção que voce quer, que no exemplo seria cartao de credito parcelado. Aí para informar o número de parcelas automaticamente no caso do Sitef, você vai usar o evento AcbrTef.TEFCliSiTef.OnObtemCampo mais ou menos dessa forma... procedure TTef.tefObtemCampo(Titulo: String; TamanhoMinimo, TamanhoMaximo, TipoCampo: Integer; Operacao: TACBrTEFDCliSiTefOperacaoCampo; var Resposta: AnsiString; var Digitado, VoltarMenu: Boolean); begin if TipoCampo = 505 then begin Resposta := '10'; // quantidade Digitado := true; VoltarMenu := false; end; end; Agora no caso do PayGo eu consegui fazer também mas naquela modalidade antiga por troca de arquivos, pelo TEFDial... o paygo da forma mais nova eu não cheguei a implementar.

Mesmo problema aqui, imprime apenas dois por página

Boa tarde @Gustavo Totta Estou a alguns dias tentando emitir NFS-e para o novo provedor de santo antonio da platina, efeteu os passos descritos (mudar o ini, compilar o res, reinstalar o acbr, rebuild no projeto), mas não tenho obtido sucesso. Meus fontes estão atualizados, fazendo o debug, o provedor identificado é o IPM mesmo, porém quando executo o método Emitir do componente, fazendo o debug, acabo caindo na classe TACBrNFSeXWebservice e recebendo uma exception de não implementado. O método abaixo para ser mais preciso: function TACBrNFSeXWebservice.RecepcionarSincrono(ACabecalho, AMSG: String): string; begin Result := ''; raise EACBrDFeException.Create(ERR_NAO_IMP); end; Alguma dica? obrigado

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