WINDEL
-
Total de ítens
324 -
Registro em
-
Última visita
-
Days Won
1
Tipo de Conteúdo
Blocks
Notes ACBrLibNFe
Fóruns
Downloads
Calendário
Posts postados por WINDEL
-
-
Olá Daniel,
Tem alguma notícia sobre essa informação do TEF não apagar as respostas quando é desativado a comunicação com a dll?
-
Obrigado pelo retorno Daniel.
Acredito que isso seria a única pendência que falta para que funcione o TEF junto com o Abecs. Fico no aguardo.
-
Olá Daniel,
Fiz alguns testes com a nova dll e utilizando os comandos acima de DesInicializar e Inicializar e não ocorreu mais o erro de "Acesso Negado". Porém, quando utilizo mais de uma transação tef, apenas imprime a última transação. Segue os passos que simulei e o log do componente ACBR em anexo.
- Realizei uma transação de tef de 1,00 (comprovante aparece no log)
- Acionei o comando de DesInicializar.
- Mostrei o QRCode no visor do Pin Pad (sem utilizar o tef).
- Acionei o comando de Inicializar.
- Realizei mais uma transação de crédito de 0,50 (comprovante aparece no log)
- Utilizei o comando "ImprimirTodosComprovantes" e percebi que o array "RespostasTEF" contém apenas 1 resposta (a última). A anterior foi desprezada e assim consigo imprimir apenas o último comprovante.
Seria possível ter uma forma de não apagar a resposta anterior?
-
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
-
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.
-
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?
-
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.
-
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
-
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.
-
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çãoRepetir algumas vezes esse processo em modo debug para poder verificar a exceção levantada.
-
1
-
-
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?
-
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 terminartefapi.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?
-
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?
-
16 horas atrás, Suporte Octec disse:
Olá! Publicaram um ebook com várias informações, inclusive uma resposta para essa sua pergunta, vou citá-la aqui:
"9. Nas operações com pré-pago para casas noturnas, onde o consumo ocorre depois do crédito de comandas, como devem ser registrados os produtos vendidos?
Emitir uma NFC-e com o CFOP 5.949 na entrada. Na saída, no consumo efetivo, emitir uma NFC-e com o tipo de pagamento <tPag> “05 - crédito em loja”; e, se necessário, complementar com outro tipo de pagamento utilizado de fato (ex.: 01-dinheiro, 03-cartão de crédito etc.)."
Segue link do ebook gratuito (que também foi publicado nos canais do Discord do ACBr):
https://drive.google.com/file/d/13bN_jgobp_v91izH4-9qrONhDgzjhQuZ/view?pli=1Bom dia. De onde veio esse e-book?
-
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.
-
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.
-
18 horas atrás, Nícolas Dörr disse:
Boa tarde Windel, estava com a mesma dúvida.
Encontrei essa explicação disponível naquela página de orientação sobre o decreto, segue link: https://atendimento.receita.rs.gov.br/integracao-entre-nfce-e-meios-de-pagamento-eletronicos
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.
-
3
-
-
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?
-
1
-
-
15 minutos atrás, Vinicius L. Azevedo disse:
Sobre o evento, é triste de ver o quanto eles se perdem quando confrontados com a realidade do comércio brasileiro. Faltam respostas, inventam gambiarras pra tapar buracos e geram novos buracos. "Vamos ter que pensar" foi a principal resposta, e ainda assim o prazo pra implantação está estourado e os clientes das software houses estão preocupados. A cara de pau é maior quando eles dizem que não querem atrapalhar o mercado, quando na verdade qualquer um sabe que é basicamente a única função do governo. Claramente percebe-se que estes burocratas não entendem da realidade brasileira e ainda recebem a bênção da AFRAC.
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...
-
1
-
-
Em 07/06/2023 at 15:17, jcaset disse:
Eu entendi, lendo outras respostas vindas da SEFAZ, que este "código do sistema" não necessariamente deve estar no comprovante do cartão, mas que deveríamos criar um novo comprovante, a ser impresso junto a NFCe, onde conste este código do sistema. Ou seja, o cliente receberia: NFCe + comprovante do sistema com este código + comprovante do cartão (que é mais ou menos o que é entregue qnd o cliente tem TEF).
Nesta resposta que o Fabio colocou acima, pra mim fica entendível que, numa eventual fiscalização, solicitariam para que o contribuinte mostrasse as informações registradas tão somente no sistema, sem que haja necessariamente uma ligação entre o código que o sistema gerou e o pagamento realizado.
Agora volto naquela questão que o Windel levantou... Hoje dizem que pode ser o código gerado pelo sistema e que não precisaria ter uma ligação com o pagamento, mas é algo que não me parece ter muita lógica.
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).
-
Em 01/06/2023 at 08:38, jcaset disse:
Bom dia, pessoal!
Li todo o tópico até aqui e queria ver se vocês acham que a ideia abaixo atenderia.
Pelo que pude entender até então, a normativa diz que não necessariamente o código NSU é o que deve constar no cAut da NFCe. Ou seja, o software pode gerar qualquer código desde que este conste na NFCe (o que pra mim, como para muitos, é estranho).
No meu caso, ao realizar um pagamento eu gero um código de movimentação financeira (ex.: 1300) e penso que seria possível usar este código na tag cAut, pois atenderia esta vínculo solicitado pela SEFAZ. Aí faltaria somente gerar mais um recibo para o cliente com este código.
Neste caso, o registro da informação é automático como sugere a normativa.
Esta minha forma de pensar está errada?
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...
-
1
-
-
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?
-
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?
-
3
-
-
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.
-
1
-
TACBrAbecsPinPad
em ACBrSerial
Postado
Ok! Sim, isso realmente está acontecendo mesmo. Quando utilizo a função de obter dados do pin pad para capturar o valor do cpf/cnpj que o cliente digitou, ocorre uma mensagem de erro no visor com o conteúdo "Processando.." ou dependendo da ocasião até trava o sistema e tem que finalizar pelo gerenciador de tarefas.
Certo, vou aguardar primeiramente essa solução que é mais importante e urgente.