Valdir Dill

Boa tarde, Alguma novidade sobre essa questão ou ainda está em análise? Obrigado!

Bom dia, Arquivo solicitado, em anexo. Só alterei o número da conta, por questão de segurança/sigilo. Obrigado Extrato123456 -BB.ofx

Boa noite, Pelo que consegui entender na análise do método ACBrOFX1.Import, o componente trata os lançamentos cujo valor de TRNTYPE seja igual a XFER, todos como débito (print anexo). Porém, em um arquivo .txt de que um usuário nosso enviou (print anexo), é uma transferência recebida, ou seja, um crédito. Obs.: o arquivo é do Banco do Brasil. Seria isso um erro a ser corrigido ou como proceder? Obrigado!

Boa tarde, Fiz uma consulta pelo último NSU, e este era o NSU 10 -> ACBrNFe1.DistribuicaoDFePorUltNSU(VUF, VCNPJ, 10). Agora, se eu fosse fazer uma nova consulta, deveria usar: ACBrNFe1.DistribuicaoDFePorUltNSU(VUF, VCNJ, 11), correto? Muito bem: suponhamos que, ao invés dessa consulta a partir do NSU 11 acima, eu faça uma consulta pela chave -> ACBrNFe1.DistribuicaoDFePorChaveNFe(VUF, VCNPJ, VChave). Esta consulta pela chave vai retornar um NSU também, correto? Digamos que esse NSU dessa chave consultada é o 20. Pelo que eu entendi, e constatei isso em testes práticos, sempre que se for fazer uma consulta com ACBrNFe1.DistribuicaoDFePorUltNSU, deve ser usado o último NSU consultado para aquele CNPJ, independentemente de como foi feita essa consulta, ou então recebemos a rejeição de "consumo indevido". Se tudo isso está correto, então, na situação acima relatada, eu não poderei mais consultar os NSUs de 11 a 19, já que a última consulta, apesar dela ter sido feita pela chave, (ACBrNFe1.DistribuicaoDFePorChaveNFe(), foi do NSU 20. É assim mesmo que funciona? Obrigado!

Boa tarde, Pela quantidade de componentes acredito que não seja a causa. Temos 5 componentes de terceiros, além é claro dos componentes Acbr. De toda forma, vamos tentar implementar sua sugestão sobre os paths (fontes e .dcus) assim que possível. Obrigado!

Boa tarde, Agradeço pela sugestão, mas não é a solução. Já havia tentado isso. Coincidência ou não isso acontece desde que instalamos o Delphi 10.4. Mas tranquilo, vamos tocando assim mesmo, rs. Obrigado!

Bom dia, Estou com uma dúvida/dificuldade não relacionada diretamente ao Acbr e sim ao Delphi... É assim: em uma classe declarada em uma unit qualquer, quando se clica com o mouse sobre o nome da classe e se estando com o ctrl pressionado, deveria abrir aquela unit onde eh criada aquela classe, certo? Ou então quando se posiciona o mouse sobre a classe, deveria aparecer um "popup" com o nome da unit onde aquela classe está declarada, correto? O problema é que aqui, isso ocorre, às vezes sim e, às vezes não... Nos faz falta isso, pois é algo bastante usado... No print anexo, peguei como exemplo a AcbrJSON.pas, mas poderia ser qualquer outra unit/classe, pois acontece em várias outras. O problema também não é a unit em si e sim a classe. Note que no segundo print, temos outra classe na mesma unit e nesta classe funciona direitinho, ou seja, mostra a unit onde a classe é criada. Alguma sugestão?] Obrigado!

Bom dia, Por motivos que não se faz necessário explicar aqui, nem sempre conseguimos atualizar o ACBrNFeServicos.ini em atualizações da nossa aplicação. Aí, pode ocorrer da versão da aplicação estar atualizada, mas o ACBrNFeServicos.ini não estar. Ele pode existir na pasta, mas desatualizado. Ocorrendo essa situação, nos surge a seguinte duvida: se o arquivo ACBrNFeServicos.ini estiver na pasta da aplicação, o Acbr vai sempre obrigatoriamente ler os endereços de WS do arquivo ou isso dependerá de DMDocEletr.ACBrNFe1.Configuracoes.Arquivos.IniServicos estar setado com "ACBrNFeServicos.ini"? Por exemplo, se DMDocEletr.ACBrNFe1.Configuracoes.Arquivos.IniServicos = '', mas ACBrNFeServicos.ini existir na pasta da aplicação, o que vai acontecer? O componente vai usar o arquivo mesmo assim ou vai buscar as URLs no .res que vai empacotado na aplicação? Obrigado!

Ah, certo. Então, no caso do Safra, devo alimentar o código de baixa/devolução diretamente no componente. Entendi. Obrigado!

Boa tarde, Estamos tentando homologar o arquivo remessa cnab 240 do banco Safra e está dando erro da coluna da instrução de baixa/devolução, posição 224 do segmento P. Segundo o manual, essa coluna precisa ir com valor 1 ou 2. Vide resultado da homologação, print anexo. Na função TACBrBancoSafra.GerarRegistroTransacao240, linha 788 (vide anexo), é alimentada a coluna 224 a 224 do segmento P. Para alimentar essa coluna é utilizado o valor da propriedade ACBrTitulo.Instrucao2. Porém o valor dessa propriedade está em branco, fazendo com que a coluna fique sem valor no arquivo. Procurei em todo código fonte, mas não encontrei onde Instrucao2 esteja sendo alimentada. Poderiam me orientar, por gentileza? Obrigado!

Boa tarde, Atualizei neste instante, mas não houve nenhuma mudança.

Certo, entendi. Mas ainda estou um pouco confuso. Não sei, mas parece haver algum erro no componente. As propriedades ImprimeDescAcrescItem e ImprimeTotalLiquido parecem conflitar e não seguem sempre o que lhes é setado. Veja só: 1 - Configurando assim: ACBrNFeDANFeRL1.ImprimeDescAcrescItem := idaiComValor; ACBrNFeDANFeRL1.ImprimeTotalLiquido := false O valor total imprime corretamente, mas não imprime a coluna do desconto no item, mesmo existindo desconto 2 - Configurando assim: ACBrNFeDANFeRL1.ImprimeDescAcrescItem := idaiSempre; ACBrNFeDANFeRL1.ImprimeTotalLiquido := false Imprime valor total corretamente. Mas aí, mesmo nenhum item tendo desconto, imprimirá sempre essa coluna 3 - Configurando assim: ACBrNFeDANFeRL1.ImprimeDescAcrescItem := idaiComValor; ACBrNFeDANFeRL1.ImprimeTotalLiquido := true; Essa configuração bagunça de vez o coreto, rs...Imprime uma coluna com valor líquido, mas no título da coluna fica "DESCONTO" e o valor do desconto não é impresso. Na opção 2 acima, mesmo não sendo 100% correta, já resolve nosso caso. Mas entendo que se, ImprimeDescAcrescItem tem a opção de idaiComValor, então, ao setar esse valor, deveria imprimir essa coluna apenas se algum dos itens realmente tiver valor, ou não? Obrigado!

Sim sim @antonio.carlos, em relação ao primeiro exemplo que citei, ou seja, da inversão de cartão crédito/débito, isso está claro. O TEF faz o processo e retorno tudo corretamente, ou seja, se envio débito e lá no pinPad o cliente coloca um cartão que só aceita crédito ou vice-versa, a operação é negada. É assim mesmo que tem que ser. Só citei essa operação para exemplificar como fazemos a regra de negócio aqui. O problema está no caso do voucher, onde o TEF, erroneamente, aceita o cartão invertido, ou seja, a aplicação envia débito, o cliente passa um voucher e o TEF aceita. Mas entendi sua explicação, o problema está mesmo na .dll (ou outro) que aceita isso. Não tem relação com o componente Acbr ou alguma coisa que pudesse ser feita na aplicação para contornar. Está respondido. Obrigado! Sim, exatamente é isso que é feito na aplicação. É justamente por isso que dá erro. Quando eu disse "erro na aplicação", acho que não fui muito claro. Eu quis dizer que a aplicação gera um erro para o operador dizendo para ele que a operação o pagamento não poderá ser registrado (na aplicação). Mas no cartão do cliente o débito ocorreu, porque o TEF aceitou a operação, etende? Obrigado!

Bom dia, Na nossa aplicação, enviamos os dados para o TEF e, "na volta" conferimos se o retorno do TEF está trazendo as mesmas informações. No caso do cartão tipo voucher está ocorrendo uma situação que, não sei se é falta de informação da aplicação ou é mesmo uma inconsistência do componente Acbr ou então na .dll. É assim: duas operações: 1 - ACBrTEFAPI1.EfetuarPagamento('10', 15, tefmpCartao, [teftcCredito], tefmfAVista, 0); Se a aplicação acionar este método e enviar estas variáveis, porém, na hora de passar o cartão, o cliente utilizar um cartão de débito, vai dar erro e a operação não é autorizada. Tudo certo. 2 - ACBrTEFAPI1.EfetuarPagamento( '10', 15, tefmpCartao, [teftcDebito], tefmfAVista, 0); Já nesta operação, se o cliente passar um cartão de alimentação (voucher), a operação será autorizada pelo TEF e não deveria ser. Por conseguinte, na nossa aplicação isso vai dar erro na conferência, pois enviamos um teftcDebito e voltou um teftcVoucher. Como contornar isso? Obrigado!

Atualizei os fontes. Na parte de compilação parece tudo certo. Só não tenho como testar completo, pois na homologação não aceita. Mas estou passando a atualização para o cliente fazer o teste assim que possível. Obrigado!

Em anexo. ACBrTEFComum.pas ACBrTEFPayGoComum.pas

Bom dia, Na análise que fazemos na nossa aplicação, da resposta de uma operação de TEF, precisamos saber o tipo de cartão retornado. Para obter a informação, quando a operação é realizada via cartão de débito ou crédito, o Acbr já traz essa informação em ACBrTEFAPI1.UltimaRespostaTEF. Porém, no caso do cartão do tipo voucher, é necessário executar uma rotina adicional (vide abaixo). Nada difícil de se fazer. Mas acredito que a sugestão que deixo aqui possa contribuir para padronizar a captura do retorno e deixá-la igual, sendo o cartão débito, crédito ou voucher. A rotina que utilizamos: Var VTipoCartaoRet : TACBrTEFTiposCartao; if ACBrTEFAPI1.UltimaRespostaTEF.Debito then VTipoCartaoRet := teftcDebito else if ACBrTEFAPI1.UltimaRespostaTEF.Credito then VTipoCartaoRet := teftcCredito else //se não é crédito, nem débito, o acbr não traz a informação em uma propriedade. Aí tem que ler. begin case TACBrInformacao(ACBrTEFAPI1.UltimaRespostaTEF.LeInformacao(PWINFO_CARDTYPE)).AsInteger of 4 : VTipoCartaoRet := teftcVoucher; end; end; A sugestão para mudança 1) Na ACBrTEFPayGoComum.pas, mudar (linha 495 em diante) PWINFO_CARDTYPE: begin // 1: crédito, 2: débito, 4: voucher/PAT, 8: private label, 16: frota, 128: outros AInt := Linha.Informacao.AsInteger; Credito := (AInt = 1); Debito := (AInt = 2); Voucher := (Aint = 4); //implementação sugerida end; 2) Na ACBrTEFComum.pas, linha 356, inserir fpVoucher: Boolean; // Se True, foi usado Cartão voucher Obrigado!

Bom dia, Foi exatamente isso que fiz também, rs. Utilizo a tag do próprio componente. Beleza! Obrigado.

Boa tarde, Estamos tendo erro na impressão de DANFE com ACBrNFeDANFeRL1. Não está imprimindo subtotal do item. Print anexo. A propriedade ACBrNFeDANFeRL1.ImprimeTotalLiquido está igual a true. Por outro lado, mesmo a propriedade ACBrNFeDANFeRL1.ImprimeDescAcrescItem = idaiNunca, o campo DESCONTO do item, é impresso. Setando ACBrNFeDANFeRL1.ImprimeTotalLiquido para false, aí a impressão é feita corretamente, ou seja, imprime o total do item e não imprime o desconto. Acredito que a propriedade ImprimeTotalLiquido esteja sendo lida de forma invertida. Obrigado!

Boa tarde, - Para gravar uma imagem na impressora uso: ACBrPosPrinter1.GravarLogoStream(VStream,.... - Para apagar a imagem na impressora uso: ACBrPosPrinter1.ApagarLogo(... Gostaria de implementar uma rotina para que, antes de gravar uma imagem, verificar se já não existe uma imagem gravada. É possível? Como? Qual seria a propriedade ou método a utilizar? Obrigado!

Desculpe, mas tenho que discordar, rs Veja bem, porque discordo: na nossa aplicação, não mudamos absolutamente nenhuma vírgula, a não ser time out. Com timeOut = 0, nenhum erro Com timeOutr = 3000, ocorre erro Exatamente a mesma situação acontece no demo Acbr. Se mudo apenas o timeOut de 0 para 3000, dá erro. TimeOutro = 0, não dá erro. Obs.: lembrando que isso só ocorre se houver um anexo sendo enviado. Obrigado!

Bom dia Realmente no demo não ocorreu. Fazendo as comparações, descobri que o problema está no time out que eu estava setando para 3000. Essa propriedade tem um valor ideal ou recomendado? Ou depende de cada smtp? Obrigado!

Boa noite, Estamos tendo um erro no envio de email pelo componente AcbrMail. Servidor Gmail. A exceção ocorre no ao executar ACBrMail1.Send. Só ocorre se no email houver anexo. ACBrMail1.AddAttachment('C:\Teste\Notas.rar', '', adAttachment). Enviando o mesmo email, mas sem anexo, aí não dá erro. O tamanho do arquivo não creio ser o problema, pois é pequeno (1,5 MB). O estranho é que o email chega ao destinatário, inclusive com anexo. Alguma sugestão de como evitar ocorrer esse exception? Obrigado!

Ótimo! Fontes atualizados e tudo certo agora. Obrigado!

Bom dia, No demo do componente AcbrOfx, temos: Memo1.Lines.Add('Banco: ' + ACBrOFX1.BankName + #13#10 + 'Ag: ' + ACBrOFX1.BankID + ' - CC: ' + ACBrOFX1.AccountID + #13#10 + 'Data Inicial: ' + ACBrOFX1.DateStart + ' Data Final: ' + ACBrOFX1.DateEnd); Acredito que o correto seria Memo1.Lines.Add('Banco: ' + ACBrOFX1.BankName + #13#10 + 'Ag: ' + ACBrOFX1ACBrOFX1.BranchID + ' - CC: ' + ACBrOFX1.AccountID + #13#10 + 'Data Inicial: ' + ACBrOFX1.DateStart + ' Data Final: ' + ACBrOFX1.DateEnd); E daria para incluir 'Banco: ' + ACBrOFX1.BankID Obrigado!