Mateus Brunelli

Bom dia. Estou com um problema na impressão de boletos usando o Fortes Report. Este problema ocorre em alguns marcas de impressora, por exemplo Brother. Já tentei mudar várias configurações na impressora mas nenhuma delas resolveu. O maior problema, como podem ver na primeira imagem, é a margem do lado esquerdo do boleto, que é onde fica o código de barras. A impressora não consegue imprimir o inicio do código de barras, aí quando o cliente vai tentar pagar usando o leitor de código de barras não consegue ler o código. Mas a linha digitável também sai um pouco cortada mas só um pequeno pedaço do último dígito da linha digitável (imagem 2 anexo). Até se verificarem na margem esquerda teria a informação no nome do sistema que está configurado para imprimir ali, mas também está cortando. Algumas impressoras conseguem imprimir esse nome do sistema, mas outras imprime cortado pois o nome do sistema fica bem na borda da página. E no caso se eu salvar o boleto em PDF e imprimir do PDF na impressora sai tudo corretamente. Mas imprimindo diretamente do relatório para a impressora sai com as margens cortadas. Verifiquei que já existe um tópico aberto sobre essa questão. É um tópico um pouco antigo, até eu questionei lá se tiverem alguma solução mas não obtive retorno aí estou abrindo este com o mesmo intuito. Saber se alguém passou pelo mesmo problema ou se conseguiu contornar de alguma forma e puder colaborar. Desde já agradeço.

Boa tarde, alguém conseguiu alguma solução para o problema deste tópico? Com relação ao corte da impressão dos boletos usando Fortes Report? Pois estou com os fontes atualizados e estou tendo este problema principalmente utilizando impressoras Brother. O cliente acaba não conseguindo pagar pois o código de barras fica cortado no inicio.

Bom dia, tentou mudar a forma de impressão do componente da DANFE para paisagem? Creio que resolva seu problema.

Deu certo, instalei os pacotes mencionados e não apresentou mais o erro. Obrigado

Boa tarde, tive um problema semelhante em máquinas com windows mais antigos Ex: Windows XP, e Windows Server 2008. Quando coloco as DLLs do OpenSSL na versão 1.1.1.4 na pasta do sistema, nestas versões mais antigas do Windows está dando a seguinte mensagem: "This application has failed to start because VCRUNTIME140.dll was not found. Re-installing the application may fix this problem". Aí nestas máquinas tive que voltar a utilizar a versão antiga do OpenSSL com as DLLs antigas.

Bom dia @DSilva, pelo que compartilhe aqui a solução encontrada quando tiver, pois tenho a mesma necessidade. Abraço

A SENFF possui bandeira própria de cartões. Você diz de alterar o arquivo clisitef32.ini em tempo de execução? Pois só devo bloquear a transação com outros tipos de cartão quando o cliente informar que está usando o cartão fidelidade.

O Sistema procede da seguinte forma. Quando inicio o pagamento em cartão (TEF) o sistema pergunta ao operador se utilizará cartão fidelidade ou não. No cartão fidelidade que no meu caso é o cartão SENFF, o cliente terá promoção em alguns itens. E quando o operador informar que utilizará cartão fidelidade o sistema aplica os descontos em alguns itens conforme configuração de promoção. Porém precisaria garantir que o cliente utilize o cartão preestabelecido na promoção quando for respondido "sim" na pergunta se vai pagar com o cartão fidelidade. Ou seja se o cliente disse que vai usar cartão fidelidade então ele recebeu descontos, então quando ele inserir o cartão, antes de confirmar as transações, se for um cartão diferente do pre-estabelecido na promoção o sistema abortaria o pagamento. Seria desta forma, não sei se teria alguma maneira de preestabelecer no CRT que aceite somente cartão SENFF no caso ou se consigo ter acesso ao BIN do cartão antes de confirmar a transação para que essa transação possa ser interrompida.

Boa tarde, @DSilva descobriu alguma forma de obter o BIN do cartão antes de confirmar as transações? Pois estou com a mesma necessidade aqui, consegui somente depois de confirmar as transações com o evento OnDepoisConfirmarTransacoes, mas isso não me serve pois precisaria ser antes de confirmar, para que caso o cliente coloque um cartão diferente do preestabelecido no desconto aborte o processo.

Já ativou na conta do Gmail o acesso a aplicativos menos seguros? Verifique se está ativado pelo link https://myaccount.google.com/lesssecureapps Outra coisa que pode ser é o antivírus bloqueando, já tive casos que o antivírus bloqueava o envio de e-mails. Abraço

Bom dia, também tive este problema em clientes com Kaspersky, porém desativando o antivírus voltou a salvar o XML normalmente.

Bom dia, testado e tudo ok. Obrigado

Atualizei os fontes, tudo ok. De minha parte poderia ser encerrado o tópico. Obrigado

Boa tarde. Precisei atualizar os fontes do ACBR hoje, aí atualizei também o arquivo ACBrBancoSicredi.pas e o arquivo ACBrBoleto.pas para ficarem corrigidos conforme as últimas atualizações do ACBr e também já apliquei as alterações informadas no tópico acima com relação a negativação, por isso se possível seria bom analisar estas alterações se poderão ir para o repositório do ACBr para que não seja necessário a cada atualização dos fontes modificar novamente os arquivos. Segue em anexo os arquivos atualizados Agradeço desde já. ACBrBoleto.pas ACBrBancoSicredi.pas

Boa tarde. Precisei atualizar os fontes do ACBR hoje, aí atualizei também o arquivo ACBrBancoBanrisul.pas para ficar corrigido conforme as ultimas atualizações do ACBr e também já apliquei a correção informada no tópico acima, por isso se possível seria bom analisar estas alterações se poderão ir para o repositório do ACBr para que não seja necessário a cada atualização dos fontes modificar novamente o arquivo. Segue abaixo o arquivo atualizado Agradeço desde já. ACBrBancoBanrisul.pas

Bom dia, recentemente (Maio/2019) o Sicredi alterou seu layoute de cobrança CNAB400 para atender já no registro de títulos a opção de Negativação. Desta forma torna-se possível enviar já na remessa de cadastro de título a informação da Negativação. A utilização desta funcionalidade de negativação ficou muito semelhante ao já existente procedimento de protesto. Sendo assim alterei os fontes do ACBr para atender tal alteração. Porém só fiz a alteração para o layoute CNAB400. O manual atualizado da cobrança Sicredi CNAB400 onde possui agora os campos para informação da negativação está no link https://www.sicredi.com.br/html/para-sua-empresa/recebimentos/cobranca/arquivos/manual-cnab-400.pdf (Pág. 36 do manual, posição 193-194 e 195-196 do registro detalhe do arquivo de remessa). Também envio em anexo os fontes do ACBr alterados para atender essa opção de negativação. Peço que analisem os fontes abaixo para uma possível submissão para o repositório de fontes no SVN. ACBrBoleto.pas ACBrBancoSicredi.pas

Bom dia pessoal, estou com o mesmo problema, e verifiquei o seguinte. Para emissão do boleto e do arquivo de remessa para o Banrisul segundo o layoute do banco na página 5. Com relação ao Código do Beneficiário informa o seguinte: Ou Seja, o banco exige que na remessa tenha sempre 4 dígitos na agencia. Mesmo quando o número da agência tem apenas 3 dígitos. Porém no retorno que vem do banco conforme informa o Manual do banco na página 17 (print abaixo), se a agencia tiver apenas 3 dígitos, o arquivo de retorno virá com apenas estes 3 dígitos, sem o zero na frente da agencia. Ou seja mudará as posições onde tem a agencia e código do beneficiário no header do arquivo de retorno. Sendo assim na leitura do arquivo de retorno quando pegar a informação da agencia e beneficiário no header do arquivo de retorno as posições destes campo vai variar dependendo se a agencia tem 3 ou 4 dígitos. Ex: Caso a agencia tenha 3 dígitos o código do beneficiário começará na posição 30 e caso a agencia tenha 4 dígitos o código do beneficiário começará na posição 31. Por isso está dando problema na validação da agencia/conta do arquivo de retorno. Para contornar isso fiz uma alteração no arquivo ACBrBancoBanrisul.pas onde verifico quantos dígitos existem nas posições 27 a 39 se tiver 12 dígitos então é porque a agencia está com 3 dígitos apenas, sendo assim tem que pegar apenas os 3 caracteres (27, 28 e 29 do header do arquivo) e pegar o beneficiário a partir da posição 30. Já se tiver 13 dígitos é porque a agencia possui 4 dígitos, sendo assim tem que pegar 4 caracteres (27, 28, 29 e 30 do header do arquivo) e pegar o beneficiário a partir da posição 31. Visto que quando tiver apenas 3 dígitos na agencia, então o último caractere do intervalo 27 a 39 (que será o caractere 39 do header do arquivo) será branco pois começou o beneficiário 1 caractere antes. A alteração que fiz está no arquivo em anexo. Peço que validem e se acharem pertinente disponibilizem no repositório de fontes do SVN. ACBrBancoBanrisul.pas

Boa tarde @José M. S. Junior ficou ótimo a alteração. Atualizei os fontes, testei e está funcionando corretamente com as novas propriedades criadas. Obrigado

Atualizei os fontes, testado e funcionando ok.

Atualizei os fontes, testado e funcionando ok.

Atualizei os fontes, testado e funcionando ok.

Boa tarde Pessoal, creio que já existem 2 tópicos sobre este assunto, são eles: Creio que o pessoal está analisando a correção para ser submetida ao repositório de fontes do SVN

Boa tarde @marcianobandeira, esse problema já identifiquei e sugeri uma correção. Está sendo tratado isso no tópico abaixo Estou aguardando analisarem a correção e enviarem para o repositório de fontes do ACBR .

Obrigado Daniel, atualizei e testei... tudo certo.

Eu acredito que somente quando acontece o TipoCampo=1 é que seja confirmada a transação aí seria o momento certo de gravar no temporário. Pelo menos é o que dá a entender na descrição do manual do Sitef para o TipoCampo=1. Eu deixaria da seguinte forma: 1, 133, 952: