Ir para conteúdo
  • Cadastre-se

Valdir Dill

Membros Pro
  • Total de ítens

    924
  • Registro em

  • Última visita

  • Days Won

    4

Tudo que Valdir Dill postou

  1. Bom dia, Beleza @Italo Giurizzato Juniorvamos peleando até acharmos a causa, hehe! Só para constar: aqui é Windows 11 Home 22H2. Delphi 10.4 Architect, ou seja, tanto Windows, como Delphi, são diferentes do seu aí, o que sugere que a causa não está nesses dois. Outro detalhe: fiz um teste acionando a URL (https://sefin.nfse.gov.br/sefinnacional/nfse/31056082203424804000106000000000000523093065840035) diretamente no browser e usando o certificado do emitente dessa nota. Em 10 tentativas consegui receber o retorno com sucesso 2 vezes. Nas demais tentativas deu um erro no browser pela demora do WS responder. Mas, após tentar pelo browser, tanto nas tentativas que houve sucesso, como nas que não houve, fui na nossa aplicação e fiz a consulta e não deu o famigerado erro, ou seja, logo na primeira tentativa - na nossa aplicação -, já retornou com o XML da consulta. Então, minha dedução inicial permanece, ou seja, é alguma coisa que é liberada no WS quando se tenta a primeira requisição, mas essa "liberação" só ocorre após o pedido, o que viabiliza a próxima tentativa e esta retorna com sucesso. Meio maluco isso, rs, mas é o que está parecendo. Obrigado!
  2. Sim, como eu disse, usamos as dlls OpenSSl versão 1.1.1.10, que é justamente o que ele recomendou. Olha o que tentei agora: - Atualizei os fontes Acbr; - Usei somente o demo do Acbr e, na pasta do .exe (\Acbr\Exemplos\ACBrDFe\ACBrNFSeX\Delphi\), ficaram somente as dll libssl-1_1.dll, libcrypto-1_1.dll, ambas copiadas de \Acbr\DLLs\OpenSSL\1.1.1.10\X86\ - Compilei o demo e o problema acontece no mesmo padrão. Primeira tentativa dá erro e segunda não dá. Sim, libssl-1_1.dll libcrypto-1_1.dll, ambas copiadas de \Acbr\DLLs\OpenSSL\1.1.1.10\X86\ para dentro da pasta da aplicação.
  3. As configurações usadas são: - ACBrNFSeX1.Configuracoes.Geral.SSLLib := libOpenSSL - ACBrNFSeX1.SSL.SSLType := LT_TLSv1_2 As dll usamos openSSL da versão 1.1.1.10.
  4. Boa tarde, Alguém mais com ocorrência desse erro -> "network subsystem is unusable"? Obs.: padrão nacional. Ocorre toda primeira tentativa de fazer qualquer requisição (envio de nota, cancelamento, consulta). Na segunda tentativa em diante, não ocorre, ou seja, o processo conclui com êxito normalmente. Após a primeira tentativa, posso inclusive fechar a aplicação e retornar a ela que não vai dar erro. Testamos em nossa aplicação com 6 usuários diferentes, em cidades diferentes. e sempre ocorre esse padrão, ou seja, primeira tentativa dá erro e depois vai. Testamos também no demo Acbr. Se enviar uma nota e aguardar uns 5 minutos (mais ou menos) e tentar de novo, aí vai voltar a ocorrer o problema. Tudo indica que é alguma instabilidade no WS, mas é estranho, pois é um padrão rigoroso, sempre igual. Parece que a primeira tentativa ocorre uma espécie de liberação de permissão no WS. Aí, quando entra a segunda tentativa, isso está liberado. Já vi relatos de outros colegas que usam Acbr sobre esse erro no Discord, mas até o momento não encontramos nenhum indicativo de solução. Obrigado!
  5. Boa tarde @Italo Giurizzato Junior, acabei de atualizar os fontes e testei os ajustes no DANFSe em Fortes. Ficou show. Agora com a chave e qrCode. Muito 10. Obrigado!
  6. Conhecemos esse método. Mas, ele tem algumas desvantagens. Por isso preferimos imprimir o DANFSe através da nossa aplicação, utilizando o ACBrNFSeXDANFSeRL. Estávamos inclusive utilizando dessa forma, tudo certinho. Pergunto: o ACBrNFSeXDANFSeRL não deve mais ser usado então? Não será mais atualizado?
  7. Bom dia, Ok, XML em anexo. Mas é o mesmo XML que usamos ontem e estava imprimindo normal. Obrigado! Nota Serviço Nr 5.xml
  8. Bom dia, Atualizei os fontes neste instante. O DANFSe (Fortes) não está trazendo os valores da nota. Print a nexo.] Obrigado
  9. Bom dia, Estávamos com esse erro desde sexta passada, que foi quando iniciou a obrigatoriedade das MEIs usarem o novo serviço. Mas, de ontem para cá, está melhorando gradativamente. Às vezes precisa fazer 2 ou 3 tentativas e ocorre esse erro, mas depois vai. É instabilidade no WS mesmo. Abs.
  10. Bom dia Fizemos o seguinte: o usuário é obrigado a cadastrar a operadora no sistema, entre outros dados, informa o nome da adquirente conforme está na lista PayGo e também o CNPJ. Nas operações de TEF, quando não houver retorno do CNPJ, o sistema lê o valor de ACBrTEFAPI1.UltimaRespostaTEF.Rede e busca o CNPJ no banco de dados da nossa aplicação. Se não encontrar o cadastro, a operação não finaliza. Dessa forma, o próprio usuário pode atualizar os cadastros sempre que houver uma operadora nova e, o principal: fica sob responsabilidade dele informar o CNPJ da adquirente. Obrigado pela ajuda!
  11. Bom dia @Daniel Simoes Pelo que entendi, devo ler esse arquivo RedesPayGo.txt para verificar o CNPJ da operadora. Para isso, utilizarei o valor de ACBrTEFAPI1.UltimaRespostaTEF.Rede para varrer o arquivo, certo? Até aí tudo certo, mas ao aplicar essa rotina, verifiquei que o valor - "PAGSEGURO" - retornado em ACBrTEFAPI1.UltimaRespostaTEF.Rede, não é exatamente àquele apresentado no arquivo -> "PAGSEG". Nesse caso deve fazer uma rotina para tentar deduzir que PAGSEGURO refere-se a PAGSEG, é isso? Obrigado!
  12. Valdir Dill

    TEF CNPJ da Adquirente

    Bom dia, Estamos com uma dúvida/dificuldade aqui em relação ao TEF.. Usamos PayGoWeb. A dúvida é em relação ao CNPJ da adquirente que retorna (ou deveria retornar) pelo TEF em ACBrTEFAPI1.UltimaRespostaTEF.NFCeSAT.CNPJCredenciadora. Na maioria das operações, esse CNPJ retorna certinho. Porém, em alguns casos, essa propriedade vem em branco. É o caso de Pag Seguro e C6Bank. A questão é que esse CNPJ, pelo menos em nossa aplicação, é usado para gravar no banco de dados para se emitir a nota fiscal onde é preciso informar esse dado nos pagamentos e também é utilizado depois para geração do arquivo SPED Fiscal, onde também é necessário se informar o CNPJ da adquirente. Muito bem, entendido isso, vamos ao problema que precisamos tentar resolver aqui. Se o TEF não está retornando esse dado, entendo então que isso não é obrigatório ser retornado pela adquirente na transação, certo? Então, se não vem temos como pegar esse CNPJ na operação, como fazer para guardar esse dado em cada operação TEF? Perguntar ao usuário para ele informar? Acho que seria inviável. Se possível, gostaria de receber sugestões dos colegas de como isso é feito na aplicação de vocês. Qualquer sugestão serve, rs... Obrigado!
  13. Boa tarde Obrigado @Juliomar Marchetti, eu tinha analisado esse tópico umas 3 vezes, mas em todas passei batido, rs. ACBrPixCD1.PSP.epPix.Pix.valor; ACBrPixCD1.PSP.epPix.Pix.endToEndId; Obrigado!
  14. Bom dia, Estamos implementando PIX dinâmico do banco Inter. A inclusão do PIX e geração do qrCode está tudo certo e funcional. Mas estamos com uma dúvida de como capturar dados retornado em uma consulta de um PIX. Estamos fazendo assim: ACBrPixCD1.PSP.epCob.ConsultarCobrancaImediata(txtId) //para pegar o status do PIX - ACBrPixCD1.PSP.epCob.CobCompleta.status; //isto funciona beleza A dúvida é como pegar (qual objeto/propriedades do componente) eu consigo pegar o valor pago e também o endToEndId? Obrigado!
  15. Bom dia, Ok, fontes atualizados e testados. Tudo certo agora. Obrigado!
  16. Boa noite, Descobrimos a causa. Parece que há uma rotina errada no próprio Acbr que não está usando a máscara correta para formatar a data. Abri um novo post, específico para esse problema -> Obrigado!
  17. 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!
  18. 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!
  19. 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!
  20. 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
  21. 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
  22. 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!
  23. 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
  24. 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!
  25. Problema de driver desatualizado não é, pois estou usando esse mesmo desse link, i8, versão 7.17.
×
×
  • Criar Novo...

Informação Importante

Colocamos cookies em seu dispositivo para ajudar a tornar este site melhor. Você pode ajustar suas configurações de cookies, caso contrário, assumiremos que você está bem para continuar.