-
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
-
-
Boa tarde,
Sim, já fizemos muitos testes.
Cabe esclarecer que, conforme constatamos até agora, no caso de operação a prazo no cartão de débito, há dois tipos de operações:
a) O preDatado: é venda no débito em 1 parcela e com X (máximo 30) dias de prazo. Esse prazo é definido pelo comprador, no momento da operação;
b) O parcelado: é venda no débito que pode rá ser pago em N parcelas. Os vencimento serão sempre de 30 em 30 dias.O que estamos testando até agora é o preDatado.
Acredito que estejamos quase lá, rs.Estamos agora com uma dificuldade. Veja se podes nos ajudar.
Fazemos assim:
VVctoPreDatado := Now + 10 -> 10/06/2023
ACBrTEFAPI1.EfetuarPagamento(10, 6,00, tefmpCartao, teftcDebito, tefmfPredatado, 1, VVctoPreDatado);Isso está gerando um erro: DATA VENCIMENTO INVALIDA.
Acredito que ocorra porque VVctoPreDatado está indo no formato 'dd/mm/yyyy', mas oTEF precisa que vá 'dd/mm/yy'.
Como poderia fazer isso, ou seja, transformar uma variável do tipo TDate no formato ano 4 dígitos para ano 2 dígitos?Teria que ser algo como StrToDate(FormatDateTime('dd/mm/yy', VVctoParcelado)), mas isso não dá certo, pois VVctoParcelado fica igual com 4 dígitos no ano.
Obrigado!
- 1
-
Bom dia,
Estamos implementando opção para recebimento TEF Paygo no cartão de débito com parcelamento.
Mas, ao que me parece, as informações sobre o assunto são bem escassas. Quase inexistem. Ou então não estou sabendo procurar, rs.E, para piorar, não funciona em homologação.
Então precisamos fazer todos os testes no usuário final em produção, ou seja, com o "barco andando", o que é um transtorno.Tentei ajuda pelo Discord e recebi orientações de que, por exemplo, no caso da modalidade deve ser informada a tefmfPredatado e não tefmfParceladoEmissor, mas nas análises (por dedução) constatamos que tem tanto a opção pré-datado, que é um pagamento à vista, mas com prazo (1 só parcela) e também a opção de parcelamento (mais de 1 parcela).
Isso é mais um indicativo de essa opção do débito a prazo é bem pouco utilizada/difundida, o que faz com que as informações de pesquisa sobre o assunto também sejam poucas.Por isso estou registrando a questão aqui no fórum para que fique registrado e, além de me ajudar agora, também possa ajudar a outrem no futuro.
Enfim, a pergunta é: o Acbr e/ou a PayGo tem algum manual com o passo a passo do q se deve informar em cada tipo de operação, em especial, no caso dessa operação com recebimento no cartão de débito a prazo?
Obs.: no demo do Acbr já procurei não encontrei.Obrigado!
-
Bom dia,
Sim, eu havia verificado que esses dois parâmetros podem ser alimentados no componente.
Porém, temos essa cobrança Sicoob há anos no sistema e nunca deu rejeição, mesmo sem alimentar manualmente. Por isso estanhamos.
Mas vamos providenciar o ajuste no sistema para permitir que o usuário possa setar esses dados.
Obrigado
-
Bom dia,
Estamos tendo rejeição do arquivo remessa Sicoob, por conta dos campos:
- Versão do layout do Header, linha 1, colunas 164 a 166 do arquivos remessa
- Versão do layout do Header do lote, linha 2, colunas 14 a 16 do arquivos remessaNo primeiro item, o componente seta a versão como 81 e no manual está 87.
Já no segundo, o componente seta a versão como 40, sendo que no manual está 45.Nos prints anexos traz essa questão de forma ilustrada para melhor compreensão.
Isso poder ser algum erro no componente ou tem alguma configuração que devemos fazer no componente para que isso vá correto?
Obrigado
-
Depois de uma semana o banco teimando que era nosso que estava formando o remessa errado, descobriu-se que era o funcionário do banco que passou o código da agência errado para o cliente.
Como é cooperativa (ou pelo menos nessa cooperativa), parece que o código da agência tem que ser da matriz e não o código onde o cliente tem conta. Estranho isso, mas...
Mas enfim, resolvido.
Obrigado!
-
Bom dia,
Estamos tendo rejeição pelo banco ao enviar no arquivo remessa, banco 133-Cresol.
O erro é: "Convênio Cresol inválido (Agência=1620, Conta=33925, Código da Empresa33925) (linha=2)"... (print anexo).
Arquivo remessa também em anexo.No componente estamos alimentando os dados assim:
ACBrBoleto1.Cedente.Convenio := 39325
ACBrBoleto1.Cedente.Agencia := 1620
ACBrBoleto1.Cedente.Conta := 39325;
ACBrBoleto1.Cedente.ContaDigito := 3;Alguma sugestão de onde podemos estar errando?
Obrigado
-
Bom dia,
Gostaria de uma ajuda. Na verdade é mais uma opinião/sugestão dos colegas de como que vocês fazem no seu sistema em relação à questão abaixo detalhada.
Seria mais uma dica/sugestão em relação à regra de negócio.É o seguinte:
1) Fatos:
a) No sistema, usamos o TEF Paygo, onde entre outros recebimentos, há a opção de recebimento por PIX;
b) O TEF não retorna o CNPJ da intermediadora do recebimento PIX;
c) A partir de janeiro/2023, é necessário que todo recebimento de PIX seja informado no registro 1601 do SPED Fiscal. Entre outros dados, precisa informar o CNPJ da instituição que intermediou o recebimento desse PIX.2) De forma simples, a dúvida é: como saber (e registrar no sistema) quem (CNPJ) da instituição intermediadora do recebimento (PIX), no momento que um PIX via TEF recebido para depois informar isso no SPED?
Obrigado!
-
3 minutos atrás, Daniel InfoCotidiano disse:
Aqui estou usando uma i9, pode ser que driver influencie sim, tem algum mais novo?
https://github.com/ElginDeveloperCommunity/Impressoras/tree/master/Impressoras Não FiscaisProblema de driver desatualizado não é, pois estou usando esse mesmo desse link, i8, versão 7.17.
-
34 minutos atrás, Daniel InfoCotidiano disse:
Boa tarde @Valdir Dill
Pode fazer um novo teste por favor;
Selecione o codigo de barras, no object inspector
Verifique se oBoa tarde,
Sim, as 3 propriedades estão com esses valores que você menciona.
Veja o print anexo e note aquilo que mencionei antes, ou seja, em design, o código de barras está ultrapassando o quadro da direita. Já na impressão, esse código de barras diminui. É como se a propriedade autosize mudasse para true na hora de imprimir. Mas olhei no código fonte e lá também está lTertxtCodBarras.AutoSize := false.
8 minutos atrás, Victor H. Gonzales - Panda disse:Estranho isso. Será que pode ser o driver da impressora que interfere em algo?
-
Em 08/03/2023 at 11:29, Victor H. Gonzales - Panda disse:
Por favor atualize seus fontes, pelo SVN do ACBr...
Já subimos para o nosso repositório de fontes, modificações que podem corrigir algum dos itens referentes a esse tópico...
Por favor atualize seus fontes, faça testes, e se possível comente em uma nova resposta, se o problema foi resolvido...
Dúvidas, sobre o uso do SVN ? Clique aqui e veja um vídeo
Bom dia,
Atualizei os fontes e reinstalei novamente hoje (10/03). Não mudou absolutamente nada aqui.
Veja o print que estou enviando em anexo. Quando eu imprimo, o código de barras tem um tamanho. Já no print postado aqui outro dia pelo @Daniel InfoCotidianoo código é bem maior e aí sim as linhas ficam mais espaçadas e acredito que isso possa ter algum efeito quando da leitura do código de barras pelo app.
Eu até fiz um teste mudando o código fonte (ACBrBoletoFCFortesFr.pas) e alterando a linha -lTertxtCodBarras.Width := 641 para -lTertxtCodBarras.Width := 841. Em seguida reinstalei o componente, executei a aplicação debugando para ver se estava passando ali nessa linha e passa, tudo certo. Mas mesmo com lTertxtCodBarras.Width = 841, nada muda na impressão, isso tanto no preview como no papel.
Não sei, mas me parece que precisa alterar algo mais no código para que essa mudança do tamanho do código de barras surta o efeito desejado na hora da impressão.
Obrigado!
-
43 minutos atrás, Daniel InfoCotidiano disse:
@Valdir Dill
bom dia !
Qual a versão do seu delphi por favor?
outra pergunta, escala de exibição esta em 100%
Boa tarde,
Delphi 10.4.
Sim, 100%.
-
24 minutos atrás, Daniel InfoCotidiano disse:
ACBrBoletoFCFortesFr
(modo design)
lTertxtCodBarras
-Module= 2
-Ratio = 2
-width = 641(code)
RLBand7BeforePrint
-lTertxtCodBarras.Width := 641;É, está atualizado. Esses parâmetros são os que estão lá nos fontes.
Notei que, nessa tentativas, você está definindo, tanto no componente, como dinamicamente, que lTertxtCodBarras.Width será 641. Em design, esse width faz com que o código de barras ultrapasse uns 1,5 cm aquele quadro (lá onde tem o label "Autent.Mecânica - Ficha de Compensação") do boleto à direita. No print que você postou impresso aí, isso também acontece.
Porém, quando eu executo a impressão, esse código de barras "encurta" e, seu final, fica a uns 1,5 cm desse quadro, ou seja, o código de barras quando a impressão ocorre, fica uns 3 cm menor do que em design. Então, essa mudança de alterar o tamanho para 641, me parece, que não está surtindo efeito.
Obs.: essa diminuição do código de barras na impressão, ocorre tanto no preview, como na impressão de fato.
Obrigado!
-
10 minutos atrás, Daniel InfoCotidiano disse:
Boa tarde !
Fizemos mais uma alteração, pode atualizar e rodar o instalador por favor
Boa tarde,
Mesmo resultado. Não mudou nada na impressão.
Pode me passar detalhes da alteração que foi feita? Só para eu conferir aqui nos fontes e ver se estão realmente atualizados.
Obrigado
-
4 horas atrás, Daniel InfoCotidiano disse:
Pode mandar um print como ficou após atualização ?
Bom dia,
Boleto em anexo.
-
Em 03/03/2023 at 13:32, Daniel InfoCotidiano disse:
Boa tarde,
As barras até que estão espaçadas, mas a altura das barras é pequena. Não é igual a esse modelo que você enviou.
O procedimento fiz exatamente conforme orientado, ou seja, descompactei esses 2 arquivos na pasta e depois reinstalei o Acbr. Só depois fiz o teste novamente.
Obrigadgo.
-
Em 01/03/2023 at 17:09, Daniel InfoCotidiano disse:
@Valdir Dill
Boa tarde !
Fizemos uma alteração no boleto para impressão na impressora térmica, vou mandar os arquivos compactado
Por favor, salve os arquivos (descompactados) dentro de ACBr\Fontes\ACBrBoleto\FC\Fortes e rode o instalador
Faça os teste por favor.
Aguardo um feedbackBom dia,
Fiz o processo todo de atualização, mas não surtiu efeito. Continua sem ler.
Obrigado!
-
5 minutos atrás, Juliana Tamizou disse:
Bom dia,
Ai vc lê diretamente na tela ou imprime a partir do preview?
At.
Bom dia
Tanto faz se imprimo direto para impressora ou a partir do preview, a impressão será a mesma e o celular não lê.
Já se gerar o preview e apontar o celular para a tela do computador, aí lê normal.
Em resumo, o código de barras está sendo gerado corretamente. O problema está na leitura do código impresso em papel. O leitor não reconhece.
Imagino que isso seja um problema das impressoras térmicas ou não? Em pesquisas na net vi vários relatos que térmicas têm dificuldade de imprimir código de barras legíveis.
Obrigado!
-
51 minutos atrás, Daniel InfoCotidiano disse:
Bom dia !
Anexe uma foto do impresso por favor para que possamos analisarEm anexo. Esse boleto é da nossa aplicação, mas testamos também pelo demo Acbr e acontece a mesma coisa.
Obrigado!
-
Boa tarde,
Estou com dificuldades em ler código de barras impresso em impressora térmica.
Usei o demo Acbr no layout lTermica80mm, impressora Elgin i8.
A impressão ocorre tudo certo. Porém, não consigo fazer a leitura através de app de bancos.
Gerando a mesma impressão em vídeo, aí consigo ler código de barras.
Acredito que possa ter relação com a qualidade na impressão, pois notei que ela sai um pouco borrada.
Alguma sugestão para resolver isso ou realmente térmicas não são indicadas para essa função?
Obrigado!
-
1 hora atrás, Daniel Simoes disse:
Oi @Valdir Dill.. acabei de mudar uma configuração no sistema do fórum, e lhe enviei um teste... por favor confirme se recebeu...
Boa tarde,
Sim, recebi!
- 1
-
Boa tarde,
Estou sem receber notificações por email já faz algumas semanas. Não sei exatamente quando, mas faz mais de 15 dias.
Verifiquei minhas configurações de notificação (print anexo) e, aparentemente está tudo certo, ou seja, para que avisos sejam enviados no email. Mas como dá para verificar no print anexo, estão indo para a notificação no fórum (no sininho).
Obrigado!
-
Boa noite,
Sei que esse assunto já está para lá de batido por aqui, mas fiz várias pesquisas nas postagens anteriores e não consegui uma luz sobre erro de consumo indevido que está ocorrendo em um cliente.
Antes de mais nada, gostaria de informar que, com absoluta certeza, não há outra pessoa ou sistema fazendo buscas no CNPJ do cliente.
Fiz os seguintes procedimentos hoje e obtivemos os seguintes resultados:
Método: AcbrNFe1.DistribuicaoDFePorUltNSU(UFCod, CNPJ, VUltimoNSU);
Tentativa 1 - Consulta por último VUltimoNSU = 711
- Data: 08/10/2022
- Hora: 11:24
- Resultado: rejeição 656 - Deve ser aguardado 1 hora para efetuar nova solicitacao caso nao existam mais documentos a serem pesquisados. Tente apos 1 hora
Tags retornadas:
<ultNSU>000000000000711</ultNSU>
<maxNSU>000000000000000</maxNSU>
Obs.: a consulta anterior havia sido feita há mais de 2 horasTentativa 2 - Consulta por último VUltimoNSU = 0
- Data: 08/10/2022
- Hora: 14:31
- Resultado: rejeição 656 - Deve ser utilizado o ultNSU nas solicitacoes subsequentes
Tags retornadas:
<ultNSU>000000000000711</ultNSU>
<maxNSU>000000000000000</maxNSU>
Tentativa 3 - Consulta por último VUltimoNSU = 712, ou seja, número superior ao ultNSU
- Data: 08/10/2022
- Hora: 16:03
- Resultado: rejeição 589 - Numero do NSU informado superior ao maior NSU da base de dados do Ambiente Nacional
<ultNSU>000000000000000</ultNSU>
<maxNSU>000000000000000</maxNSU>A única explicação que consigo imaginar que poderia ser possível para ocorrer essa situação é que não exista NSU superior ao 711, mas com certeza tem.
Mas ainda assim, a primeira consulta após 1 hora com o ultNSU = 711 teria que retornar cstat 137 e não rejeição de consumo indevido, não é?Alguma sugestão? Sei que é a SEFAZ que retorna essa rejeição, mas o usuário sempre quer uma explicação, coisa que nesse caso não estamos conseguindo ,rs..
Estou anexando os arquivos de consulta/retorno das, caso seja necessário.
Obrigado
20221008112442-con-dist-dfe-soap.xml 20221008112444-dist-dfe-soap.xml 20221008143130-con-dist-dfe-soap.xml 20221008143131-dist-dfe-soap.xml
-
Bom dia,
Fontes atualizados, testados e aprovados, rs..
Obrigado!
- 1
-
Em 20/09/2022 at 09:12, Juliomar Marchetti disse:
Bom dia. sim. estava no meu notebook e não havia subido. vou subir hoje logo posto aqui avisando. Valdir
Bom dia.
Desculpe insistência @Juliomar Marchetti, mas nossos clientes estão nos cobrando. Se puder fazer o upload que você mencionou, agradeço...
Até não entendo como ninguém mais se manifestou sobre isso, pois, com certeza, há muitas empresas que utilizam essa conciliação do Banco do Brasil.
Obrigado!
Possível Erro nas Rotinas do TEF PayGo
em TEF
Postado
Boa noite,
Acredito que tenhamos encontrado um erro na ACBrTEFAPIPayGoWeb.pas.
Nas linhas 484/485 está assim:
if (DataPreDatado <> 0) then
PA.ValueInfo[PWINFO_INSTALLMDATE] := FormatDateTime('ddmmaa', DataPreDatado);
O resultado de FormatDateTime('ddmmaa', DataPreDatado) é uma string assim: '3105aa', que obviamente está errada.
Acredito que correto seria:
if (DataPreDatado <> 0) then
PA.ValueInfo[PWINFO_INSTALLMDATE] := FormatDateTime('ddmmyy', DataPreDatado);
O resultado de FormatDateTime('ddmmyy', DataPreDatado) será uma string assim: '310523'
Podem verificar, por gentileza?
Obrigado!