-
Total de ítens
422 -
Registro em
-
Última visita
-
Days Won
1
Tudo que WINDEL postou
-
Dúvida ao resgatar uma propriedade NSU BERGS para a adquirente VERO
WINDEL replied to WINDEL's tópico in Dúvidas sobre TEF
comms_240607.log Segue um exemplo de log: VERO - MASTERCARD VENDA CREDITO A VISTA CONFEITARIA CNPJ: 91.814.558/0001-66 CAXIAS DO SUL 041135200600000 00650348 DATA: 07/06/2024 HORA: 08:04:18 NSU BERGS:00092453 NSU BANDEIRA:040051 CARTAO: 8196 VALOR: 64,94 Esse retorno está vindo da PAYGO. -
Dúvida ao resgatar uma propriedade NSU BERGS para a adquirente VERO
um tópico no fórum postou WINDEL Dúvidas sobre TEF
Estou verificando uma situação em que o código da autorização às vezes não é preenchido quando faço transações com a rede VERO. O suporte entrou em contato com a ACBR e foi informado para utilizar o campo "NSU BERGS" ao invés do Código de Autorização. Porém, estou verificando os campos da resposta tef e não existe esse campo para que salvar a informação no meu banco de dados. Qual seria o campo correspondente do "RespostaTEF.CodigoAutorizacaoTransacao" que estou utilizando atualmente? Estou puxando esses dados no evento "ACBrTEFAPIQuandoFinalizarTransacao". Temos a propriedade "RespostaTEF.ImagemComprovante1aVia" que mostra todo o comprovante em uma Stringlist, porém terei que percorrer a lista e utilizar o comando copy e pos, o que não seria algo muito interessante para fazer. Existe alguma solução mais correta para esse caso? Segue na sequência o conteúdo do campo que preciso puxar a informação: 083-000 = ------------ 1 via - loja -----------\x0D\x0A\x0D\x0AVERO - ELO \x0D\x0AVENDA CREDITO A VISTA\x0D\x0A\x0D\x0ACONFEITARIA \x0D\x0ACNPJ: 91.814.558/0001-66\x0D\x0ACAXIAS DO SUL\x0D\x0A\x0D\x0A041135200600000 00650348\x0D\x0A\x0D\x0ADATA: 07/06/2024 HORA: 14:19:25\x0D\x0ANSU BERGS:00950720 NSU BANDEIRA:692633\x0D\x0ACARTAO: 7103 VALOR: 88,40\x0D\x0A\x0D\x0A\x0D\x0ACREDITO\x0D\x0A02-0009-77B53AB3B38046B9\x0D\x0AA000000494101001 \x0D\x0A\x0D\x0A--------------------------------------\x0D\x0A6037097 EC:0000730637 REF:0000005338 084-000 = ----------- 2 via - Cliente ---------\x0D\x0A\x0D\x0AVERO - ELO \x0D\x0AVENDA CREDITO A VISTA\x0D\x0A\x0D\x0ACONFEITARIA \x0D\x0ACNPJ: 91.814.558/0001-66\x0D\x0ACAXIAS DO SUL\x0D\x0A\x0D\x0A041135200600000 00650348\x0D\x0A\x0D\x0ADATA: 07/06/2024 HORA: 14:19:25\x0D\x0ANSU BERGS:00950720 NSU BANDEIRA:692633\x0D\x0ACARTAO: 7103 VALOR: 88,40\x0D\x0A\x0D\x0ACREDITO\x0D\x0A02-0009-77B53AB3B38046B9\x0D\x0AA000000494101001 \x0D\x0A\x0D\x0A--------------------------------------\x0D\x0A6037097 EC:0000730637 REF:0000005338 -
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.
-
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? log.txt
-
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.
-
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?
-
DECRETO Nº 56.670 - Estado do Rio Grande do Sul
WINDEL replied to WINDEL's tópico in NFC-e - Nota Fiscal do Consumidor Eletrônica
Bom dia. De onde veio esse e-book? -
DECRETO Nº 56.670 - Estado do Rio Grande do Sul
WINDEL replied to WINDEL's tópico in NFC-e - Nota Fiscal do Consumidor Eletrônica
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. -
DECRETO Nº 56.670 - Estado do Rio Grande do Sul
WINDEL replied to WINDEL's tópico in NFC-e - Nota Fiscal do Consumidor Eletrônica
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. -
DECRETO Nº 56.670 - Estado do Rio Grande do Sul
WINDEL replied to WINDEL's tópico in NFC-e - Nota Fiscal do Consumidor Eletrônica
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? -
DECRETO Nº 56.670 - Estado do Rio Grande do Sul
WINDEL replied to WINDEL's tópico in NFC-e - Nota Fiscal do Consumidor Eletrônica
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... -
DECRETO Nº 56.670 - Estado do Rio Grande do Sul
WINDEL replied to WINDEL's tópico in NFC-e - Nota Fiscal do Consumidor Eletrônica
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). -
DECRETO Nº 56.670 - Estado do Rio Grande do Sul
WINDEL replied to WINDEL's tópico in NFC-e - Nota Fiscal do Consumidor Eletrônica
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... -
DECRETO Nº 56.670 - Estado do Rio Grande do Sul
WINDEL replied to WINDEL's tópico in NFC-e - Nota Fiscal do Consumidor Eletrônica
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? -
DECRETO Nº 56.670 - Estado do Rio Grande do Sul
WINDEL replied to WINDEL's tópico in NFC-e - Nota Fiscal do Consumidor Eletrônica
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? -
DECRETO Nº 56.670 - Estado do Rio Grande do Sul
WINDEL replied to WINDEL's tópico in NFC-e - Nota Fiscal do Consumidor Eletrônica
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. -
DECRETO Nº 56.670 - Estado do Rio Grande do Sul
WINDEL replied to WINDEL's tópico in NFC-e - Nota Fiscal do Consumidor Eletrônica
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? -
DECRETO Nº 56.670 - Estado do Rio Grande do Sul
WINDEL replied to WINDEL's tópico in NFC-e - Nota Fiscal do Consumidor Eletrônica
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. -
DECRETO Nº 56.670 - Estado do Rio Grande do Sul
WINDEL replied to WINDEL's tópico in NFC-e - Nota Fiscal do Consumidor Eletrônica
Ó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? -
DECRETO Nº 56.670 - Estado do Rio Grande do Sul
WINDEL replied to WINDEL's tópico in NFC-e - Nota Fiscal do Consumidor Eletrônica
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... -
DECRETO Nº 56.670 - Estado do Rio Grande do Sul
WINDEL replied to WINDEL's tópico in NFC-e - Nota Fiscal do Consumidor Eletrônica
Mas e se o seu cliente fosse receber um pix via QRCode estático, aí não seria utilizado a integração com o TEF. Como você faria nesse caso? -
DECRETO Nº 56.670 - Estado do Rio Grande do Sul
WINDEL replied to WINDEL's tópico in NFC-e - Nota Fiscal do Consumidor Eletrônica
Sim, mas, você está criando um código qualquer e inserindo na NFC-e. Como é que você está vinculando esse código que você está criando para o pix com a autorização real que veio lá do banco? Exemplo: A autorização real gerou o código 321651313212132132145465. Sua aplicação, informou o código 1 na NFC-e. De que forma você está vinculando o seu código 1 com o 321651313212132132145465 gerado pelo banco?