EMBarbosa

Notei que você cita NF-e de Devolução, mas a mensagem de erro é sobre "nota complementar". Por favor, como o Juliomar pediu acima, anexe o xml e a mensagem de erro específica.

Boa tarde. Já estou verificando...

Acho que vai complicar o design. Não podemos esquecer que o funcionamento por meio de Thread é apenas um dos modos de receber retorno do pagamento do status do pagamento. Também esse método não é o mais recomendado. Isso poderia ser feito por meio da aplicação, não seria necessário outra propriedade. Assim que terminar a verificação das alterações do @Ederson Selvati acima, eu retorno sobre esse assunto.

Isso aconteceu porque o tempo de retorno estava passível de race condition. Se depois de enviar um pedido, por algum motivo a aplicação alterasse o TempoRetorno, isso alteraria o comportamento da Thread. O componente não tinha como se proteger e poderia até mesmo travar a aplicação inteira. Note que ao usar o seu código, o tempo de retorno vai reduzir até 1 ou zero. Daí ao fazer o próximo envio, o tempo de retorno vai ter alterado. Você teria que ficar regulando o tempo de retorno a cada envio. Além disso, se houver uma alteração nesse tempoRetorno por sua aplicação, a thread vai sobrescrever o valor. O melhor seria a thread retornar esse valor em outro lugar. O que eu pensei foi usar o evento WaitingPayment mesmo. Mas pra fazer isso, teria que alterar o evento atual do WaitingPayment. Posso fazer isso, o que acham? Vou verificar e retorno. Obrigado pelas sugestões...

Antes de salvar o XML, você está chamando o método GerarXML? É necessário fazer isso visto que o arquivo foi carregado e alterado depois. Senão o componente vai apenas salvar o XML Original mesmo.

Então a variável fsEhVenda não deve estar sendo recuperada após a queda de energia. Vou verificar... Fiz a implementação baseada no seu feedback. Subi as alterações para o SVN na Revisão 20046. Pelo que vi está tudo certo. Mas queira por favor atualizar, testar e reportar qualquer problema.

Poderia verificar se está sendo executado o código em TACBrECFVirtualSATClass.AbreDocumentoVirtual depois da queda de energia? Veja se ao ser executado, o estado de venda (fpEstado = estVenda).

Bom dia Marcelo, Acabei de enviar ao SVN na revisão 20043 alterações no ACBrPicPay que devem corrigir o problema relatado aqui. Veja o log: -- ACBrPicPay -- [+] Adicionado tipo retorno trNenhum para quando a aplicação for fazer o controle de forma separada; [-] Thread de retorno não estava funcionando para mais de uma consulta (veja correções mais abaixo); [*] nomes das constantes alteradas pra ficar mais semelhante a documentação do PicPay; [*] Remoção de comentários desnecessários; [*] Propriedade CancelarAguardoRetorno agora é apenas um método. Afinal, você só precisa cancelar; [-] Remoção de With [*] melhoria no tratamento de SetDocumento [+] Adicionado código para leitura do QRCode no FPC/Lazarus [*] Layout do código melhorado -- TACBrPicPayThread [+] Adicionada propriedade Pausado para controlar o funcionamento da thread; [-] Thread agora usa fUltimoTempoAguardo para contar o tempo, evitando "race conditions" nessa propriedade; [-] É necessário usar Synchronize sempre que executar um código na Thread principal; [-] É melhor não haver Exceptions no Create; [-] A Thread não tinha verificações de estar sendo terminada; Se você puder testar e reportar qualquer problema ficaria agradecido. bom trabalho por aí

Relacionado:

Tente verificar o Visualizador de Eventos do Windows. Talvez encontre alguma informação. Talvez tenha algum requisito faltando (uma dll por exemplo) ou talvez seja uma incompatibilidade com essa versão do Windows. É muito difícil diagnóstico se nem mesmo o suporte deles consegue ajudar. Eu não faço ideia de onde esse aplicativo tira os dados, senão talvez tivesse alguma pista.

Com certeza seus fontes não estão totalmente atualizados. Você pode ver que essa função existe no código atual conforme a imagem abaixo do arquivo ACBrNFeWebServices.pas:

foi exatamente o que eu alterei.

Boa tarde. Acabei de enviar uma possível correção para isso na revisão 20015. Poderia testar e reportar qualquer problema por favor? Nota: para definir o caminho do pdf, não é necessário atribuir a propriedade NomeDocumento. Mas se o fizer, confira o valor que ficar na propriedade PathPDF esteja correto.

Olá Carlos. Se eu entendi a sua dúvida direito, a questão é que não existe uma maneira de o usuário nunca experimentar algum erro. Você pode tratar as possibilidades de erros conhecidos e esperados. Daí você mostra mensagens mais didáticas, indicando que o erro pode acontecer e o que o usuário pode fazer. Mas sempre vai ter uma possibilidade de um erro não previsto "explodir bem na cara" aparecer na frente do usuário...

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Você precisa verificar se o manual e a legislação tem especificações sobre o DABPe. O que estiver especificado deve ser seguido. O resto, de modo geral, não tem problema ser diferente.

Tente executar como administrador. Caso não funcione, você talvez tenha que entrar em contato com o suporte deles.

Boa tarde Michel. Poderia descrever de forma resumida que tipo de validação foi adicionada? Isso facilita a verificação.

Oi Edmar. Só pra adiantar, na documentação atual do Delphi10.4, eles não recomendam você instalar na mesma máquina que tem o Delphi 10.3. Acredito que eles estejam fazendo ajustes ainda antes do lançamento.

Certo. Já confirmei aqui com a equipe e devo mexer nisso nos próximos dias. Assim que estiver pronto pra testes te retorno nesse mesmo tópico.

Certo, me parece que o funcionamento por threads vai precisar alguns ajustes mesmo. Deixa eu verificar com a equipe aqui e te dou um retorno. Mas eu sinceramente aconselho o não implementar utilizando threads. Seu sistema vai ficar tentando contato a toda hora com o PicPay, congestionando o tráfico e tal... O melhor é implementar utilizando um servidor que aguarda a notificação do PicPay.

Se não houve erro, não há porque ocorrer cancelamento, certo? Não quis dizer o contrário?

Se está simplesmente caindo no exception sem mensagem de erro, é provável que o erro já está sendo tratado pelo componente. No modo debug ele para no exception, porque é pra isso que o modo debug serve. Mas não indica que é um erro. Tem alguma outra mensagem ou situação fora esse exception?

Oi Marcelo. Notei que o componente talvez precise de alguns ajustes no funcionamento da thread. Me diz uma coisa, o primeiro pagamento foi efetuado gerando o status 'paid'? Acho que não é bem a questão de um método "Clean"... me parece que seria a thread mesmo que talvez precise de ajustes para ser reutilizada depois de finalizar...

Até onde me lembro, o componente não cancela automaticamente nenhuma venda. Tudo é feito pelos eventos. Então você pode começar verificando os eventos dos componentes. Talvez com a ajuda dos logs, é possível identificar em que momento o cancelamento está ocorrendo.