Valdir Dill

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!

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!

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 remessa No 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 cb010501.rem

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 cb140401.rem

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!

Problema de driver desatualizado não é, pois estou usando esse mesmo desse link, i8, versão 7.17.

Boa 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. Estranho isso. Será que pode ser o driver da impressora que interfere em algo?

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!

Boa tarde, Delphi 10.4. Sim, 100%.

É, 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!

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

Bom dia, Boleto em anexo. Boleto.pdf

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.

Bom dia, Fiz o processo todo de atualização, mas não surtiu efeito. Continua sem ler. Obrigado!

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!

Em anexo. Esse boleto é da nossa aplicação, mas testamos também pelo demo Acbr e acontece a mesma coisa. Obrigado! BoletoBobina.pdf

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!

Boa tarde, Sim, recebi!

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 horas Tentativa 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!

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!