Valdir Dill
-
Total de ítens
933 -
Registro em
-
Última visita
-
Days Won
5
Tipo de Conteúdo
Blocks
Notes ACBrLibNFe
Fóruns
Downloads
Calendário
Posts postados por Valdir Dill
-
-
8 horas atrás, Juliomar Marchetti disse:
poderia anexar o arquivo para testar?
Bom dia,
Arquivo solicitado, em anexo.
Só alterei o número da conta, por questão de segurança/sigilo.
Obrigado
-
1
-
-
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!
-
3 horas atrás, Juliomar Marchetti disse:
Muitos componentes de terceiros?
no library path deveria estar só com os path dos arquivos compilados *.dcu
e no browsing path é que fica dos fontes dai o delphi consegue gerenciar senão ele fica indexando um monte de path e fontes
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!
-
3 horas atrás, Victor H. Gonzales - Panda disse:
Bom dia,
Nas propriedades do seu projeto, coloque os "paths" das units no searchpath, deve resolver o seu problema
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!
-
44 minutos atrás, Juliana Tamizou disse:
Boa tarde,
Esta propriedade pertence ao titulo..
Titulo[x].Instrucao2
At.
Ah, certo.
Então, no caso do Safra, devo alimentar o código de baixa/devolução diretamente no componente.
Entendi. Obrigado!
-
1
-
-
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!
-
3 horas atrás, Italo Giurizzato Junior disse:
Boa tarde Valdir,
Favor atualizar os fontes, reinstale o ACBr e repita os testes.
Eu cheguei a fazer uma alteração não sei se vai resolver esses problemas.
Boa tarde,
Atualizei neste instante, mas não houve nenhuma mudança.
-
40 minutos atrás, Italo Giurizzato Junior disse:
Bom dia Valdir,
A propriedade de configuração: ImprimeTotalLiquido não foi removida do componente e nem a sua funcionalidade, apenas deixamos ela com o valor padrão "False".
A motivação dessa alteração:
No manual referente ao DANFE deixa bem claro quais são a colunas e a respectiva ordem das mesmas no que se refere aos dados dos itens.
Podemos sim acrescentar mais informações no DANFE que não constam no manual, mas desde que essas informações se encontrem em alguma tag do XML.
Eu aconselho que não ative essa propriedade de configuração uma vez que o Valor Liquido do produto não esta presente no XML e ela realiza a troca, ou seja, deixa de imprimir o Valor Bruto e em seu lugar calcula e imprime o Valor Liquido.
Portanto ela esta infringindo duas vezes o manual.
Existe uma outra propriedade que se ativada deixa de imprimir o Valor do Desconto e calcula e imprime o Desconto em Percentual, essa propriedade também infringe o manual duas vezes.
A inclusão dessas propriedades no componente foi feita por volta de 2015 através uma contribuição que na época da analise acabou não levando em conta que poderia ferir o manual.
Resolvemos manter, pois se retirássemos (que é o correto) alguns desenvolvedores teriam os seus código quebrados.
Por fim, volto a frisar: não ative essas propriedades de configuração.
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 desconto2 - Configurando assim:
ACBrNFeDANFeRL1.ImprimeDescAcrescItem := idaiSempre;
ACBrNFeDANFeRL1.ImprimeTotalLiquido := false
Imprime valor total corretamente. Mas aí, mesmo nenhum item tendo desconto, imprimirá sempre essa coluna3 - 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!
-
21 minutos atrás, antonio.carlos disse:
Olá @Valdir Dill no caso do voucher, alguns cartões são aceitos como débito (cardtype = 02) nos parâmetros da transação, mais o ideal é você transacionar sempre como voucher informando cardtype = 04.
Dessa forma:
ACBrTEFAPI1.EfetuarPagamento( '10', 15, tefmpCartao, [teftcVoucher], tefmfAVista, 0);
Assim não haverá erros na conferência.
Se você informar transação crédito e inserir cartão débito, pode ocorrer "modo inválido", pois o cartão não esta ativo para opção crédito ou vice-versa, voucher também pode ocorrer, se você informar débito ou crédito e inserir o voucher pode ocorrer "modo inválido" também.
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!
7 minutos atrás, Waldir Paim disse:Nessa sua operação 2:
Você não testa o retorno dela no flag voucher?
Não foi esse o propósito dela: pegar o retorno da transação?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!
-
1
-
-
39 minutos atrás, antonio.carlos disse:
Pode atualizar os fontes por favor,
veja se esta tudo certo me avise por gentileza.
Rev. 25933.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!
-
1
-
-
1 hora atrás, antonio.carlos disse:
@Valdir Dill pode anexar unit com as alterações por gentileza.
Em anexo.
-
2
-
1
-
-
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 voucherObrigado!
-
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!
-
18 minutos atrás, Victor H. Gonzales - Panda disse:
Bom dia,
isso para mim não está ligado diretamente ao timeout, o timeout não infere nessa situação...
isso para mim está na forma que é preenchido o addAddress, por exemplo passando algum email inválido, ou algo do gênero.
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 erroExatamente 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!
-
1 hora atrás, Victor H. Gonzales - Panda disse:
Bom dia, faça o mesmo teste pelo programa exemplo por favor.
ACBrMail
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!
-
9 minutos atrás, Victor H. Gonzales - Panda disse:
Bom dia,
Realmente Agencia é BranchID, ajustei o programa exemplo
Ó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!
ACBROFX - Possível Erro
em Dúvidas gerais
Postado
Boa tarde,
Alguma novidade sobre essa questão ou ainda está em análise?
Obrigado!