EMBarbosa

Edmar, já é liberado pra todos dos DEV. E nós moramos centenas de km de distância uns dos outros. O SVN que usamos se encarrega de fazer o merge. Também tem a possibilidade de fazer branches e merges que o Jedi VCS não tem. A única vantagem do JVCS é "conhecer" pascal, mesmo assim não sei até que ponto novos recursos da linguagem são compreendidos. Mas fora isso, qualquer controle de versão mais moderno é superior ao JVCS. Se vocês forem uma empresa pequena, talvez seja mais simples trabalhar com o SVN. Caso resolvam migrar para o GIT, vocês vão encontrar relatos bem detalhados sobre como fazer: https://www.davidghoyle.co.uk/WordPress/?p=1969 https://github.com/DGH2112/JEDIVCSToGit

Oi RobertoRP. Acho que não entendi muito bem sua dúvida. É normal sim. São colunas diferentes os valores não necessariamente precisam bater. Por exemplo, você não questionou que "Base Cálculo" está diferente do "Valor total".

Oi ALA, Para esclarecer, não é assim que encaramos o termo "assunto". Se fosse assim, todo o fórum poderia ficar em apenas um tópico "automação comercial". Veja que a regra fala sobre "dúvida diferente". A dúvida que abriu o tópico é sobre o ACBrTEF estar preparado para receber pagamento QRCode, a última que você postou é sobre um equipamento específico. As respostas não tem uma relação. Então pedimos que abra um novo tópico. Agradecemos sua compreensão.

Deixa eu detalhar melhor essa parte. Eu sugiro uma abordagem similar a essa Inicializa uma variável de subtotal como zero abre o cupom Vende item Caso tenha sucesso some a variável subtotal Caso dê erro compare a variável subtotal com o Subtotal do ECF Proceda conforme o resultado Faça outras vendas (volte ao passo 3) ou feche o cupom Vantagem: Você pode fazer esse tipo de tratamento para quase todas as variáveis que precisa ler do ECF. Assim, você diminui a quantidade de consulta a fazer ao ECF durante a venda.

Se estiver usando impressora USB com porta virtual, talvez valha a pena aumentar e fazer o teste. Eu tive muitos problemas que foram resolvidos assim. Você já deve ter feito mas não custa relembrar: Verificar se há atualizações para o Firmware do ECF Verificar se trocando algum componente da comunicação o comportamento muda (cabo, placa serial, etc...) Verificar se há atualizações pro Driver do ECF (caso esteja usando USB) Por que você não consulta o subtotal? Se ele estiver diferente (maior) de antes da venda do item, quer dizer que o item foi vendido.

Se você está começando a trabalhar com o Lazarus, sugiro usar o Lazarus 32 bits. Você pode instalar o Cross compiling pra 64 Bits da mesma maneira.

Vocês verificaram pelo Visualizador de Eventos do Windows? Porque em alguns casos a restauração é feita sem intervenção do usuário.

Eu não tenho experiência com Asp Net, mas encontrei essa resposta: https://stackoverflow.com/a/7080555/460775 Em parte ela diz que uma dll nativa não pode ser usada diretamente pelo ASP .Net, mas você pode usar o DLLImport para ter acesso.

Bom dia Rogerio. Que tipo de problema está tendo? Poderia mencionar as mensagens de erro ou dificuldades? Descreva também um passo a passo do que está tentando e o objetivo.

Sugiro verificar se os arquivos de configuração (.ini) estão sendo atualizados e salvos corretamente. Pode ser algum sistema de proteção (antivírus) que esteja reestabelecendo os arquivos anteriores. Já vi isso acontecer muitas vezes. Você pode também verificar o Visualizador de Eventos do Windows para confirmar que não está havendo uma restauração do sistema ou alguma outra coisa estranha.

O seu Lazarus está muito defasado. Por favor, instale a versão 2.0.8.

O Dialect do BD está 3?

Bom dia. Nem todos os registros foram implementados. Esse componente de importar só está realmente funcionando com a ajuda da comunidade. Você pode verificar o código fonte e implementar os registros que você necessita. Daí anexar aqui para que seja analisado e enviado ao SVN. Não é tão complicado quanto parece.

Bom dia Maico. Não sei se chegou a ler, mas essa portaria está na verdade alterando uma outra, a Portaria RFB nº 2.189 de 6 de junho de 2017. Essa portaria 2189 especifica no Art. 1 que ela funciona nos termos da Portaria MF nº 457, de 8 de dezembro de 2016. Por fim, a portaria MF 457, diz: O grifo é meu marcando quem disponibiliza (SERPRO) e o objetivo (políticas públicas). Essa portaria também diz: Então é um serviço pago. Não gratuitamente disponibilizado. Além disso, ao ler os artigos dessas portarias, não vi nenhuma menção aos Webservices ou sistemas que cada Sefaz disponibiliza. Apenas aos serviços da SERPRO. Assim, acredito que serviços de terceiros que existem por aí pra baixar XML sem certificado que se utilizem do sistema da SERPRO deixem de funcionar. Mas isso nada deve alterar o funcionamento atual da NFe como por exemplo a tag autXML.

Oi Sidnei_alves. Agradecemos a sua sugestão. Mas se o tempo for aumentado, isso significa que o retorno ao componente vai ter uma demora crescendo geometricamente. Se você quer aguardar mais tempo ou ter um controle mais fino, o ideal é ao invés de usar o tipo de retorno por thread implementar uma das opções abaixo: Retorno por Callback. O PicPay chama a URL de CallBack e daí você processa a resposta fazendo uma nova consulta. Esse é o método recomendado. Você pode ver o funcionamento no vídeo do Thulio Bittencourt. Fazer o controle na sua aplicação, consultando quando achar que é melhor.

OBS.: as mensagens do usuário Luis Ricardo, estavam relacionadas com outro problema e por isso foram movidas para o seguinte tópico:

É uma tentativa. Mas se passar, isso seria muito estranho, porque o manual dizia pra ser UTF-8.

Oi Marcelo, Isso não resolveria porque você estaria destruindo o Stream antes mesmo de ser utilizado. Fiz uma possível correção na revisão 20090. Por favor, queira atualizar, testar e reportar qualquer problema.

Bom dia Pedro, você já tem uma sugestão de correção? Em caso positivo, poderia nos enviar?

Acabei de enviar uma possível correção ao SVN Revisão 20082. Poderia testar?

Estou reproduzindo parcialmente aqui embaixo para indexação pelo Google:

Pra usar o FullDebug mode, você precisa da versão completa do FastMM. Mas agora relendo sua mensagem, eu notei que você não usa ele. Então não precisa se preocupar por enquanto. Vamos tentar outra maneira... Ok. Me parece que o leak está acontecendo ao ler o QRCode. A questão é que a propriedade QRCode vai retornar um TStringStream que não é destruído automaticamente. Você precisa destruir ele.

tem como você ativar o FullDebug e anexar o log?

Muito obrigado pela contribuição. Fiz a implementação baseada nela. Com as seguintes alterações que explico o motivo: O evento onWaitingPayment não é levantado caso seja levantado o onWaitingTimeOut. Não tem sentido você estar esperando se o tempo já acabou. Assim como não tem porque estar esperando se o pagamento já foi feito. Por isso o componente levanta um ou outro, mas não os dois. Alterei o nome do segundo parâmetro de on WaitingPayment para TempoRestante para não confundir com outro tipo de TimeOut. Os parâmetros de on WaitingPayment foram alterados para const. A thread não faz tratamentos caso a aplicação altere esses valores, então deixar como estavam poderia gerar problemas. Não subi a o novo evento onShowQRCode. Não é necessário esse evento no fluxo do PicPay. Se o envio do pedido foi feito com sucesso, você recebe o QRCode sempre. Por isso logo após o envio, salvo o tratamento para erros de envio, você já pode colocar na sua aplicação para mostrar o QRCode. Incluí uma correção para um warning levantado no Delphi XE7 e superiores. Ainda vou ajustar os demos conforme as alterações acima, mas subi as alterações para o SVN na revisão 20058. Assim vocês já podem ir testando e me dando um retorno. Pelo que vi está tudo certo. Queira por favor atualizar, testar e reportar qualquer problema. Mais uma vez obrigado. Marcelo, depois de reinstalar o componente você vai notar que há uma diferença no evento onWaitingPayment. O Ederson fez justamente o que eu tinha pensado acima. O parâmetro é o novo TempoRestante que você vai poder usar para mostrar na tela.

Boa tarde! Até onde eu sei essa é a orientação mesmo. Vamos deixar o tópico aberto pra até verificarmos se há mais alguma outra opção.