Ir para conteúdo
  • Cadastre-se

WINDEL

Membros Pro
  • Total de ítens

    320
  • Registro em

  • Última visita

  • Days Won

    1

Tudo que WINDEL postou

  1. Baixei os fontes, instalei novamente e com alguns testes que fiz rodando em modo Debug não ocorreu mais aquela exceção do componente. Foi realizado algum ajuste para tratar a exceção? Continuo usando o timeout de 20000
  2. Sim, por isso que estou achando estranho essas exceções que estão sendo geradas. No caso configurei o timeout para o dobro do default. Tentei colocar o valor de 20000 (dobro) e mesmo assim está ocorrendo isso.
  3. Segue as imagens das exceções que ocorrem. No memo está logando essa exceção como EACBrAbecsPinPadTimeout: Timeout reading Response Essas exceções "controladas" não podem resultar em algum crash se forem disparadas muitas vezes?
  4. Quero apenas reforçar que para ver a exceção ocorrendo, é necessário rodar em modo debug, conforme o vídeo demonstra. Inclusive no memo foi logado que ocorreu a exceção. Pode ser que se rodar em modo normal sem ser por debug, a exceção não ocorra, mas porque ela esteja sendo mascarada. Meu receio quanto a isso é se depois de muitas vezes que rode o processo, o programa ir acumulando exceções mascaradas e assim possa acontecer de estourar e a aplicação se fechar sozinha devido a esse motivo.
  5. Segue em anexo o vídeo e log. É necessário rodar em modo debug para visualizar a exceção levantada. Como o tamanho máximo para upload é de 2mb, compartilhei o vídeo no google drive. Segue o link para verificar o vídeo de simulação Vídeo: https://drive.google.com/file/d/1FWKW7mR4eHvlVqSEtm28QZDNJtPVNqiu/view?usp=sharing Log.txt
  6. Isso marcelo, entendi o seu exemplo que a intenção era mostrar que dessa forma liberava o pin pad para utilização de outros comandos. Mas para produção não é possível utilizar dessa forma. vou primeiramente atualizar a nova versão do tef PGWebLib que o Daniel comentou acima para ver se dessa forma possa resolver esse problema de acesso negado por motivo da porta continuar em uso.
  7. Sim, eu consegui simular com o Demo Pin Pad Test mesmo realizando os seguintes passos - Abrir o Aplicativo Teste ABECS Pin Pad - Clicar no Botão "Ativar" - Ir na Aba Multimedia e clicar no botão "Send to PinPad" - Ir na Aba Display e clicar no botão "Clear Display". - Voltar para a Aba Config e clicar no botão "Desativar" - Fechar a aplicação Repetir algumas vezes esse processo em modo debug para poder verificar a exceção levantada.
  8. Estou utilizando o padrão TACBrAbecsPinPad.TimeOut = 10000. Vou aumentar para 20000 para verificar se pode ser esse o problema. Sei que para nesse momento porque no debug interrompe no comando " FACBrAbecsPinPad.DSI('QRCODPIX')" e capturo as seguintes mensagens de exceção (imagens em anexo). Estou constantemente usando esses comandos para ir enviando múltiplas vezes o QRCode. FACBrAbecsPinPad.LoadMedia('QRCODPIX', ms, mtPNG); FACBrAbecsPinPad.DSI('QRCODPIX'); Não preciso excluir a imagem antes de enviar novamente? Posso simplesmente sempre enviar direto o DSI pro pinpad?
  9. Estou realizando esses testes de utilizar a comunicação com o TEF juntamente com o componente TACBrAbecsPinPad e para mim também está aparecendo essa mensagem do acesso negado no momento que tento ativar a comunicação com o componente TACBrAbecsPinPad, através do comando "ACBrAbecsPinPad1.IsEnabled := true". Essa parte de utilizar transações tef e pix simultâneas é muito comum. Por isso tentei fazer o teste de antes mesmo de criar o componente TACBrAbecsPinPad na minha aplicação, utilizar o comando TEFPayGoAPI.DesInicializar para tentar liberar a utilização do pin pad, mas mesmo assim ocorre a mensagem de "acesso negado". Fiz o teste utilizando esses comandos acima: tefapi.EfetuarAdministrativa(tefopTesteComunicacao, ''); // dar um tempo para operação administrativa terminar tefapi.DesInicializar; TACBrAbecsPinPad.IsEnabled := true; No caso funcionou, mas infelizmente não é viável a cada transação de tef fazer uma operação administrativa de teste de comunicação com tef (demora em torno de 10 segundos cada vez que chama essa operação) e chamando o comando "tefapi.DesInicializar" vai apagar todos os comprovantes de resposta que foram emitidos. Daniel, caso tiver alguma novidade sobre a Setis, pode nos avisar?
  10. Estou utilizando o componente ACBrAbecsPinPad para enviar a imagem do QRCode para o PIN PAD. Notei que esse erro ocorre aleatoriamente, em alguns momentos funciona o envio da imagem sem erros e em outras causas o erro aparece. O erro ocorre quando aciono o comando "ACBrAbecsPinPad1.DSI" para enviar imagem ao PIN PAD. Para simular o erro segui os seguintes passos utilizando o aplicativo demo PinPadTest. - Abrir o aplicativo e clicar no botão "Activate" - Ir na aba Multimedia e clicar no botão "Send To PinPad". A imagem aparecerá no visor do Pin Pad, porém ocorrerá um erro de timeout e isso impossibilita a execução dos próximos comandos. Estou utilizando para testes o PIN PAD PPC-930 versão 2.12 e estou com os drivers do fabricante instalados e atualizados. Pode fazer alguns testes com esse equipamento? LogArqPinPad.txt
  11. Não é pra enviar na cAut o código do pix. No outro tópico referente ao assunto, está sendo falado sobre a forma "correta" de envio.
  12. Na verdade, acredito que estamos com as units desatualizadas. Vamos atualizar e testar. Se já existe o add aí para vocês, já deve funcionar normalmente.
  13. Obrigado por contribuir, @Nícolas Dörr. Entendo que então devemos informar esses campos pertencentes ao Grupo Z. Informações Adicionais da NF-e, concordam? A tag ObsCont, que é de uso livre do contribuinte, possui ocorrência 0-10 e pelo que olhei por cima, o componente hoje está limitado a somente 1 ocorrência. Talvez seja necessário o ajuste no componente do ACBr, para que caso alguém pague com mais de 1 pix, consigamos enviar a informação referente aos 2 pagamentos efetuados.
  14. Na live, comentaram sobre como proceder quando o pagamento envolvesse PIX. Alguém sabe se já foi disponibilizado algum documento que regulamente a operação que apresentaram?
  15. Concordo 100% com seus apontamentos. Faz um certo tempo que já desacreditei da AFRAC. Ao invés de se posicionarem defendendo as SW e os consumidores, ficou bem claro que estão puxando é pro lado da receita...
  16. Acredito que eles vão querer comparar as informações com os dados bancários das empresas sim. Não concordo com essa prerrogativa de que o software deva gerar um código de transação, anexar no documento fiscal e armazenar o registro dessa informação, com a vinculação do pagamento real, que foi para o banco. É uma responsabilidade que não é nossa. O correto aí, seria que modificassem o layout da nota, para que a tag aceite mais caracteres e então somente informemos os códigos de autorização que são gerados pelas instituições de pagamento, que aí sim tem alguma validade. É muita responsabilidade ter essa informação local, no banco de dados do cliente. Sabemos que muitos não tem o mínimo cuidado com os dados e ocasionalmente, acabam perdendo tudo. Aí nesses casos, seriam perdidos todos registros e rastreamento com as operações que o estabelecimento tenha realizado, referente aos pagamentos. De momento, integramos o TEF a nossa aplicação e iremos trabalhar informando na tag somente quando forem operações envolvendo cartões, utilizando o próprio código que vem lá da autorizadora (um código real).
  17. Sim, você pode criar qualquer bobagem lá na cAut, que vai aprovar, agora, não vá pensando que mais pra frente não vai ser fiscalizado isso. De alguma forma, eles vão querer rastrear sim a sua movimentação de número 1300 e ela vai ter que estar vinculada de alguma forma com o pagamento que foi recebido lá pelo banco. Vejo que alguns colegas estão criando numerações fictícias e ficando por assim mesmo, porém, de que adianta gerar um número aleatório, sem ter o registro da transação original vinculada? Tem algum sentido pra você? Imagine a fiscalização no estabelecimento, olhando que tem o codigo 1 na nfc-e, mas no teu sistema, não está ligando a nada...
  18. Pelo que vejo aqui, todos estamos no mesmo barco. Todos com dúvidas sobre qual o procedimento correto e enquanto isso, o decreto em vigor. Realmente, uma piada. O que eu acho mais engraçado é que na live ali que teve, tudo parece lindo e maravilhoso, claríssimo, porém, chegamos aqui no tópico e percebemos que existem diversas dúvidas e todas praticamente são as mesmas. Não existe uma possibilidade de a tal AFRAC reunir essas dúvidas apresentadas aqui, que são dúvidas REAIS de softwarehouses e contabilidades e levar isso para a receita, para tentar esclarecer o assunto? Ou até melhor, tentar abordar o assunto da criação de um evento de pagamento em vez desse papo furado de o software emissor criar um código qualquer e informar nos documentos?
  19. Não seria muito mais fácil criar um evento de vinculação de pagamento, aonde as próprias maquininha POS poderiam se responsabilizar por realizar este vínculo? Desta forma, um pouco da responsabilidade também é transferidas para as maquininhas e não somente em cima do software emissor. A minha maior dúvida ainda é referente aos equipamentos POS. Hoje, não existe uma integração entre ERP e maquininha POS. As possíveis soluções que todo mundo fala é que é possível desenvolver a sua aplicação para android e blah blah, só que quem trabalha com delphi, sabe que não é bem assim. Além das inúmeras versões que precisarão ser instaladas para compilar para todos os tipos de android que rodam nas POS, ainda tem o fato de que terá que estar sempre investindo em licenças novas anualmente. Outro ponto que até chegou a ser comentado ali no debate da AFRAC, foi a questão da contingência. Informaram que neste caso, a NFC-e poderia ser emitida em contingência e o pagamento, realizado na POS, e aí isso deveria criar o vínculo com a NFC-e que foi emitida em contigência. Como assim? Se você está com problemas de conexão, como é que vamos comunicar com o WS da POS para capturar os dados de pagamento?
  20. Em resumo, até agora: os decretos e incisos nos dizem uma coisa, os manuais da NFC-e, dizem outra, os auditores fiscais da receita nos respondem de forma contraditória e a AFRAC realiza reuniões fechadas com o fisco e repassam outra informação. Chega ser um descaso.
  21. A própria normativa informa que é possível utilizar equipamento POS, desde que esteja vinculado ao CNPJ do estabelecimento, além de termos respostas aqui neste tópico aonde o auditor da receita informa que pode ser usado, desde que vinculado ao documento através da cAut. Agora com esse comentário, voltamos novamente a estaca 0, aonde é obrigatório a utilização de TEF, assunto que também foi respondido pelo auditor da receita, informando que estamos errados ao afirmar isso. Não faz muito sentido, o fisco vai fazer o que daí? Passar em todos os estabelecimentos do estado recolhendo as POS? E quando não houver conexão de internet no estabelecimento, uma POS poderia muito bem ser utilizada como dispositivo de contingência, visto que o TEF não irá funcionar, aí neste caso se faz o que?
  22. O que pode ser feito, na verdade, é aprovar a transação na POS antes de efetuar a emissão da NFC-e, aí o emissor insere o número da transação gerado pela POS no seu sistema. O sistema então, informa o número de autorização, bandeira, etc, digitados nas tags respectivas as informações de cartão da NFC-e e envia o documento para aprovação. Este processo funcionaria muito bem nos casos em que a transação é efetuada antes ou durante a emissão do documento, porém pelo que entendi, eles estão tentando estudar uma maneira de vincular as transações que são efetuadas após a emissão da nfc-e. Desta forma, o software do emissor geraria um hash lá responsável por criar o vínculo da transação efetuada e a emissão da nota de consumidor. A dúvida que resta é como que essas informações seriam cruzadas. Seria criado alguma exportação? Seriam criados novos campos no sped? Como é que isso seria fiscalizado? Atualmente, podemos inserir qualquer bobagem lá na tag cAut e isso seria considerado o código de interligação entre o documento e o comprovante, porém de que forma eles iriam cruzar esses dados. Pense que podemos informar lá na cAut a string receitafederal e isso passaria a ser considerado como um código de autorização. No meu ponto de vista, não faz sentido. Se a ideia é criar códigos, deveria seguir um padrão com chave de acesso de um documento, entre outras formas, resumindo, um código único para cada documento. Pense quantos códigos 123 irão existir nas NFC-e e como que essas informações serão fiscalizadas. Não faz sentido.
  23. Ótimo apontamento. O problema é argumentar essa solução com a receita. Mal estão respondendo os questionamentos, quem dirá aceitar novas sugestões. Você chegou a enviar essa sua colocação lá no fale conosco da receita, para ver o que o auditor responderia?
  24. A hora que forem fiscalizar, certamente eles vão querer rastrear o código aprovado pela operadora e não o fictício criado pelo seu sistema. Você tem que vincular o gerado pela operadora com o seu código gerado internamente, senão, de nada serve esse código que você está gerando. Em casos de bater os dados do pagamento com o recebido no banco pelo cliente, você nunca terá o NSU real das trasações...
×
×
  • 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.