Ir para conteúdo
  • Cadastre-se

Valdir Dill

Membros Pro
  • Total de ítens

    933
  • Registro em

  • Última visita

  • Days Won

    5

Posts postados por Valdir Dill

  1. 4 horas atrás, Valdir Dill disse:

    Boa tarde,

    Não sei se estou fazendo algo errado, mas aqui não está salvando os XML dos eventos na pasta que indico para salvamento. Salva esses 2 arquivos abaixo, mas .json. Isso na consulta de evento usando apenas a chave.

    - 31056082203424804000106000000000000623099306124149-eve.json
    - 31056082203424804000106000000000000623099306124149-con-eve.json

    Já na consulta de eventos usando a chave e o código de evento (e101101), dá erro -> Expected "{" but found invalid symbol (1,2) 

     

    Sim Italo eu li seu post. Na verdade li, reli e reli de novo, rs. Justamente para não postar algo errado aqui, rs.

    Mas acho que você não viu meu post direito (ou então estou ficando doido, rs).

    Veja aí no primeiro parágrafo que eu falo da consulta do evento usando apenas a chave.  Essa consulta, naquele seu post, diz que está funcionando tudo ok, mas aqui não está.

    Essa última linha que coloquei dizendo que dá esse erro é uma outra consulta que só relatei pois nessa o componente gera o xml, mas dá o erro. Só incluí esse relato para demonstrar que estou fazendo pelo demo do acbr e que setei corretamente a pasta de salvamento.

    Mas vamos esquecer essa consulta que dá erro então. Vamos nos ater apenas a primeira parte desta minha resposta anterior, ou seja, da consulta de evento apenas com a chave (sem código de evento e sem a sequência). Nessa consulta, o sistema salva apenas esses 2 arquivos .json que mencionei. Nenhum XML é salvo, entende?  

  2. 4 minutos atrás, Italo Giurizzato Junior disse:

    Boa tarde Valdir,

    Isso na sua aplicação e no programa exemplo?

    No demo.

    O 31056082203424804000106000000000000623099306124149-eve.xml anexo é o que é gerado na pasta quando se consulta pela chave + código do evento. Também ocorre o erro do arquivo ErroChaveCodEvento.png anexo. Também gera o 31056082203424804000106000000000000623099306124149-con-eve.json (anexo).

    ErroChaveCodEvento.png

    31056082203424804000106000000000000623099306124149-con-eve.json 31056082203424804000106000000000000623099306124149-eve.xml

  3. 3 horas atrás, Italo Giurizzato Junior disse:

    Bom dia Valdir,

    O programa exemplo salva os arquivos temp1.xml e temp2.xml independente dessa propriedade de configuração.

    Eu já lhe disse que o retorno da API da NFS-e Padrão Nacional retorna um json.

    O programa exemplo não esta preparado para mostrar na aba de Retorno o conteúdo do json.

    Isso explica esse erro.

    Como você consultou um evento, favor procurar na pasta que você configurou para salvar os XML.

    Ele deve ter criado uma pasta chamada: Eventos e salvo o XML do evento que foi retornado dentro dessa pasta.

    Boa tarde,

    Não sei se estou fazendo algo errado, mas aqui não está salvando os XML dos eventos na pasta que indico para salvamento. Salva esses 2 arquivos abaixo, mas .json. Isso na consulta de evento usando apenas a chave.

    - 31056082203424804000106000000000000623099306124149-eve.json
    - 31056082203424804000106000000000000623099306124149-con-eve.json

    Já na consulta de eventos usando a chave e o código de evento (e101101), dá erro -> Expected "{" but found invalid symbol (1,2) 

     

  4. 6 horas atrás, Italo Giurizzato Junior disse:

    Valdir,

    Mas nesse arquivo não tem nada mesmo.

    O Padrão Nacional retorna um Json, com meia dúzia de objetos, sendo que um deles é o XML do evento que pela documentação é para estar compactado e decodificado em base 64.

    Se você quer ver esse XML, precisa configurar o componente para salvar os arquivos em disco.

    Configuracoes.Arquivos.Salvar := True.

    Sim, está habilitado. (Configuracoes.Arquivos.Salvar := True) É justamente por isso que o demo gera esse temp2.xml. Veja no print o que o demo mostra na aba "XML de REtorno". image.thumb.png.20e59ad67bedfbea673a59ea75ea4c62.png

  5. 34 minutos atrás, Italo Giurizzato Junior disse:

    Bom dia Valdir,

    O problema é o seguinte:

    O Consultar Evento existem 3 formas diferentes de realizar essa consulta.

    1. Consultar informando somente a chave da NFS-e, esta consulta esta funcionando sem nenhum problema, retorna e salva o XML do evento.

    2. Consultar informando a chave e o código do evento desejado, esta consulta não é realizada retornando um erro 404.

    3. Consultar informando a chave, o código e o numero sequencial do evento, esta consulta esta funcionando em partes, pois quando o componente tenta descompactar o XML após ter sido decodificado em base 64 ocorre o erro de Data Error.

    Descobrimos que o XML foi codificado em base 64 duas vezes, note que existe uma linha comentada que chama a função DecodeBase64 duas vez, se você comentar a linha acima e descomentar a outra, vai ver que vai funcionar.

    Mas lembre-se que se fizer essa alteração a primeira forma de consulta vai parar de funcionar.

    Já reportei o problema para o pessoal que cuida da API, agora é aguardar eles fazerem as devidas correções.

    Bom dia,

    Entendi. Mas, na verdade, nenhuma das 3 consultas está funcionando aqui.

    Se consulto com chave + código de evento + sequencial, dá esse erro ("data error") que reportei inicialmente.

    Se consulto somente com a chave + código do evento (sem o sequencial), ocorre o erro do print que estou anexando agora.

    Se consulto somente com a chave, aí não da erro de processamento, ou seja "Sucesso" vem true, mas o XML (temp2.xml)  traz apenas isto { "message": "The requested resource does not support http method 'GET'."}. no seu conteúdo. 

     

    consultaChaveECodigoEento.png

  6. 26 minutos atrás, Valdir Dill disse:

    Boa tarde,

    Estamos tendo o erro "data error", print em anexo. Também anexo o XML retornado.

    Ocorre ao executar o método ACBrNFSeX1.ConsultarEvento(. Debugando verifiquei que a consulta é processada normalmente e retorna um XML, mas no TACBrNFSeProviderPadraoNacional.TratarRetornoConsultarEvento(, linha 869 da PadraoNacional.Provider.pas, ou seja, ao executar ArquivoXml := DeCompress(DecodeBase64(ArquivoXml)), acontece o erro.

    Aí não sei se pode ser alguma falha no componente ou se o XML está retornando com dados corrompidos.

    Obrigado! 

    temp2.xml 8.8 kB · 0 downloads temp2.xml 8.8 kB · 0 downloads

    Desculpem, anexei duas vezes o XML e não anexei o erro, rs.

    Agora vai o print do erro.

    acbr.png

  7. Boa tarde,

    Estamos tendo o erro "data error", print em anexo. Também anexo o XML retornado.

    Ocorre ao executar o método ACBrNFSeX1.ConsultarEvento(. Debugando verifiquei que a consulta é processada normalmente e retorna um XML, mas no TACBrNFSeProviderPadraoNacional.TratarRetornoConsultarEvento(, linha 869 da PadraoNacional.Provider.pas, ou seja, ao executar ArquivoXml := DeCompress(DecodeBase64(ArquivoXml)), acontece o erro.

    Aí não sei se pode ser alguma falha no componente ou se o XML está retornando com dados corrompidos.

    Obrigado! 

    temp2.xml temp2.xml

  8. 11 minutos atrás, Italo Giurizzato Junior disse:

    Bom dia Valdir,

    Eu também tive o mesmo erro nos meus testes.

    Não sei se é versão do Windows, ou a API ou a versão do Delphi.

    Estou usando o Windows 10 Home Single Language versão 22H2, com todas as atualizações.

    O Delphi é o RAD Studio 11.3 Enterprise.

    Configuração do componente:

    SSLLib = libOpenSSL

    SSLType = LT_TLSv1_2

    Pelo que me recordo, esse erro começou recentemente, não sei se foi alguma atualização do Windows ou se foi quando eu atualizei o Delphi de 11.1 para 11.3

    Outra informação importante no meu caso é que a maquina não tem firewall, nem antivírus e muito menos proxy.

    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!  

    • Curtir 2
  9. 32 minutos atrás, Alexandre de Paula disse:

    Chegou a realizar as operações recomendadas no topico que o Rubinho colocou acima?

     

    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á.  

    33 minutos atrás, Italo Giurizzato Junior disse:

    Boa tarde Valdir,

    As DLLs do OpenSSL foram copiadas para dentro da pasta que esta o EXE da sua aplicação?

    Se sim, dentro dessa pasta não tem versão antiga dessas DLLs?

    Caso tenha exclua.

    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.

  10. 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!     

  11. 57 minutos atrás, Alexandre de Paula disse:

    Essa sua nota é do Padrão Nacional correto?

    ObterDANFSE -> através desse novo método é possível obter o PDF da DANFSE informando a chave da NFS-e.

    Tente utilizar esse método, ele já traz o PDF da NFSe

    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?

  12. 2 minutos atrás, adilsonpazzini disse:

    Pior que ta dando HTTP500 agora .. 

     

     

    Deve estar fora do Ar

    image.png.38eda2fb701d35bbbfe90eac616486ce.png

    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.

    • Curtir 4
  13. 8 minutos atrás, Daniel Simoes disse:

    @Valdir,

    No caso das classes de TEF da PayGo, no ACBr, elas fazem uso desse arquivo, que é adicionado ao componente como Resource, para tentar fazer uma relação da String da Adquirente com o CNPJ... pois o TEF da PayGo não retorna o CNPJ das adquirentes...

    Entretanto, como você pode ver no arquivo, não temos os CNPJs de várias adquirentes dos possíveis retornos da PayGo

    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! 

  14. 22 horas atrás, Daniel Simoes disse:

    Na Verdade a TEF House não tem essa responsabilidade...
     

    Isso também não é uma obrigação da Adquirente...

    Compreendo que o CNPJ da Adquirente deve ser preenchido nos documentos fiscais... mas quando a SEFAZ cria essas leis, ela não consulta todas as partes envolvidas...

     

    No ACBr fizemos uma tabela cruzada, mas que precisa ser revista...

    http://svn.code.sf.net/p/acbr/code/trunk2/Fontes/ACBrTEFD/RedesPayGo.txt

    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!

  15. 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!


  16. 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!
     

  17. 3 horas atrás, Valdir Dill disse:

    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!

    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!

     

    • Curtir 2
×
×
  • 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.