msramosdev
-
Total de ítens
15 -
Registro em
-
Última visita
Tipo de Conteúdo
Blocks
Notes ACBrLibNFe
Fóruns
Downloads
Calendário
Posts postados por msramosdev
-
-
Olá Daniel, obrigado por responder.
Vou dar uma analisada nos fontes aqui e dou um feedback assim que concluir.
-
realmente não existe, são somente aqueles 78 passos que o pay&go pede mesmo.
Se alguém tiver interesse em saber o pensamento deles com relação a esta questão, certo dia eu enviei um e-mail para a NTK questionando a respeito disso:
Boa tarde!Estou realizando os procedimentos de testes descritos no roteiro de testes da automação comercial, disponível no kit de homologação do Pay&Go, e verifiquei que não existe nenhum passo de teste referente à pagamento com múltiplos cartões / múltiplas formas de pagamento e nem para operações específicas da rede Cielo.Com isso surgiram as seguintes dúvidas:-
Para
a automação comercial permitir pagamentos com múltiplos cartões / múltiplas formas de pagamento, é necessário algum
processo de homologação diferenciado? Se sim, como é o procedimento?
-
No
roteiro de testes não existe nada específico para operações com a rede Cielo, existe um roteiro
específico para homologar transações através desta rede?
Desde já agradeço e fico no aguardo.E a resposta deles foi a seguinte:
Miguel para o sistema de pagamento não existe múltiplos cartões e sim varias autorizações simples, quem controla o total da compra é a automação comercial.Achei meio estranho, mas certamente se não tem realmente não deve precisar.
-
Para
-
Na verdade quando a impressão do comprovante é iniciada, geralmente a transação já está aprovada.
Se você estiver utilizando o ACBrTEFD, ele faz o cancelamento da transação automaticamente quando você desiste de continuar tentando imprimir.
Dê uma olhada Apesar de ser tratar de falha de impressão Pay&Go, talvez possa te ajudar em alguma coisa.
-
1
-
-
No caso do teste 72, você provoca uma falha na impressão do comprovante, e escolhe não para o repetir, o componente vai então enviar um não confirmação e se programado, cancelar o CCD e o Cupom, apesar que o cancelamento do cupom não é obrigatório.
Nesse teste ao enviar a não confirmação, vai aparecer uma mensagem do pay&go para confirmar, porque a marca de acata desfazimento está desmarcada nas configurações dele, conforme o manual.
Quanto ao controle da automação, depende do que você deseja fazer, você pode deixar o componente cancelar o CCD e o cupom e gerar novamente esse cupom para reiniciar, ou deixar como está, quanto a homologação não importa, desde que envie a não confirmação corretamente.
Beleza, muito obrigado Régys!
Agora realmente deu para esclarecer bem essa questão, e era o que eu imaginava mesmo, pois tecnicamente é impossível solicitar uma nova forma de pagamento sendo que o cupom já foi finalizado. No máximo o que posso fazer é criar um mecanismo para que o usuário não tenha que lançar o cupom todo novamente, mas aí é outro assunto.
-
Régys, poderia me esclarecer melhor ou me dar uma dica a respeito do primeiro post do tópico?
Perdoe minha insistência, mas para mim esta questão não está muito clara.
Desde já agradeço.
-
Você pode marcar a opção Acata desfazimento no Pay&Go Cliente para não receber a mensagem de confirmação o cancelamento. Dessa forma o cancelamento da transação é feito automaticamente.
Ao clicar em Atualizar será solicitada a senha para acatar desfazimento. Informe a senha 14142135.
-
Olá Rafael, obrigado por responder e me desculpe se me expressei mal.
Até a parte de enviar o NCM e exibir a mensagem ao usuário está ok, quando informo que não desejo continuar tentando o ACBrTEF já entende que deve ser gerado um arquivo de cancelamento da transação. Isso está certinho.
O problema vem posteriormente, pois de acordo com o fluxo, a automação comercial deve solicitar uma nova forma de pagamento.
O que fiz para todas as informações ficarem corretas foi o seguinte:
Na abertura do cupom, evento ACBrECFAntesAbreCupom do ACBrECF, se for identificado que houve um estorno do TEF e a venda não foi cancelada na impressora, eu cancelo o cupom anterior. Dessa forma, as informações ficam consistentes no meu sistema, na impressora e no Pay&Go, porém não é isso que o fluxo sugere.
Só espero que isso não interfira na homologação, pois como eu disse na versão antiga do roteiro de testes o tratamento do cupom ficava por conta da automação comercial.
Ao meu ver, este fluxo está incoerente pois até onde sei não é possível informar outras formas de pagamento após finalizar o cupom.
Se tiver alguma outra sugestão será bem vinda!
-
Por hora resolvi cancelando o cupom nos casos de falha na impressão do comprovante, mas não está de acordo com o fluxo.
Alguém conseguiu fazer de forma diferente?
-
Olá pessoal, obrigado por responder.
Por favor anexe o Log para analise...
Daniel, segue anexo o Log gerado esta manhã para análise.
Posso te adiantar que a velocidade da porta, da impressora e do DarumaFramework.xml estão configuradas como 9600.
Boa noite,
Esta impressora esta por usb?, acho que o problema é este.
Carlos Filho, na verdade, inicialmente foi detectado o problema utilizando um cabo conversor Serial para USB. Porém aqui em laboratório fiz os testes usando um cabo Serial e também ocorreu o problema.
Em todo caso, iremos trocar este cabo conversor por um de comunicação USB nativa, pois não há razão para continuar a utilizar o cabo conversor quando a impressora permite comunicação USB nativa. Além disso, pode ser que isso resolva o problema.
Desde já agradeço a todos!
-
Olá pessoal, recentemente tenho enfrentado o seguinte problema com a impressora Daruma FS700:
Estou utilizando o ACBrECf numa aplicação de Frente de Caixa e quando ocorre um erro de comunicação com esta impressora, ela se bloqueia e só volta a funcionar normalmente após desligar e ligar novamente.
Para simular o problema, basta desligar e ligar a impressora rapidamente durante a impressão do cupom (pode ser a qualquer momento, abrir cupom, vender item, finalizar cupom, etc) e depois tentar fazer alguma operação, como por exemplo cancelar o cupom.
Faço este mesmo procedimento com uma impressora Bematech MP-4000 TH FI e o problema não acontece.
Tendo em vista que com a impressora Bematech não ocorre erro, existe algum procedimento específico para tratar este problema de comunicação com a Daruma usando o ACBrECF?
Pesquisei sobre o assunto aqui no fórum e não consegui encontrar nada a respeito.
Desde já agradeço se alguém puder me dar um apoio.
Obs.: Tenho uma outra aplicação que faz a comunicação via DLL e o problema não ocorre, ou seja, ao ligar e desligar a impressora ela termina de imprimir o cupom normalmente.
-
Olá pessoal, estou no passo 72 do roteiro de homologação do TEF Pay&Go da empresa NTK, agradeço muito se alguém puder me dar um auxílio.
O objetivo do passo 72 é provocar uma falha de impressão do comprovante (desligando a impressora por exemplo) e, devido a esta falha, enviar um comando para cancelar a transação se o usuário não desejar continuar tentando imprimir o comprovante.
No caso de falha na impressão, de acordo com o fluxograma em anexo (retirado do documento de interface com a automação comercial da NTK), a automação comercial deve solicitar a forma de pagamento novamente. Pergunto:
Segundo o fluxo eu finalizei o cupom fiscal com uma forma de pagamento TEF, porém não houve sucesso na impressão e o cliente optou por não tentar novamente. Nesse caso vou mandar o NCN, cancelar o cupom fiscal e recriar o mesmo cupom deixando o cupom subtotalizado apenas esperando nova forma de pagamento?
Lembrando que se não cancelar o cupom fiscal e o cliente optar por pagar em Dinheiro por exemplo a descrição da forma de pagamento informado no cupom (já finalizado) será diferente do praticado realmente.
Olhando o fluxo antigo para tef discado da Redecard, ele não trata do assunto cupom fiscal, deixa a cargo da AC. O fluxo vai apenas até o envio do NCM e no caso poderíamos apenas cancelar o cupom fiscal. Mas agora manda solicitar a forma de pagamento novamente, o que gerou essa minha dúvida.
Fico muito grato se alguém puder me dar uma força nessa questão.
-
Neste caso perfeito então.
Não tinha certeza se todas as vias deveriam ser impressas ou não, pois como eu disse, no roteiro a descrição do procedimento de teste está vago.
Só para ficar claro, não é obrigatório imprimir todas as vias no passo 34 e demais passos referente a testes de recibos diferenciados correto?
Obrigado.
-
O ACBr já imprime corretamente como deve, o que é impresso é o correto.
Não tenho dúvida de que o ACBr imprime corretamente, só não compreendi o motivo de estar imprimindo apenas as vias Diferenciadas para o Lojista e Reduzido para o portador do cartão.
Resumindo, quero imprimir as vias solicitadas no passo 34, conforme o conteúdo gerado pelo log do Servidor Pay&Go:
Recibo tipo 0:[ *** DEMONSTRACAO PAY&GO *** ][ COMPROVANTE DE TEF ][ ][ CERTIFICACAO - PASSO 34 ][ ][ ESTABELECIMENTO DE TESTE ][ 823982346832235/03876463 ][ ][ 22/01/2014 08:36:46 ][ REF.FISCAL:008729 ][ DOC:020621 AUTORIZ:019233 ][ REF.HOST:014839028092 ][ ][ TEST CARD ************3012 ][ VENDA CREDITO A VISTA ][ VALOR FINAL: R$ 129,90 ][ ][ ][ ________________________________ ][ JOAO DA SILVA ]Este está sendo impresso (Diferenciado para o lojista)Recibo tipo 4:[ *** DEMONSTRACAO PAY&GO *** ][ COMPROVANTE DE TEF ][ VIA: ESTABELECIMENTO ][ ][ CERTIFICACAO - PASSO 34 ][ ][ ESTABELECIMENTO DE TESTE ][ 823982346832235/03876463 ][ ][ 22/01/2014 08:36:46 ][ REF.FISCAL:008729 ][ DOC:020621 AUTORIZ:019233 ][ REF.HOST:014839028092 ][ ][ TEST CARD ************3012 ][ VENDA CREDITO A VISTA ][ VALOR FINAL: R$ 129,90 ][ ][ ][ ________________________________ ][ JOAO DA SILVA ]Recibo tipo 1:[ *** DEMONSTRACAO PAY&GO *** ][ COMPROVANTE DE TEF ][ VIA: CLIENTE ][ ][ CERTIFICACAO - PASSO 34 ][ ][ ESTABELECIMENTO DE TESTE ][ 823982346832235/03876463 ][ ][ 22/01/2014 08:36:46 ][ REF.FISCAL:008729 ][ DOC:020621 AUTORIZ:019233 ][ REF.HOST:014839028092 ][ ][ TEST CARD ************3012 ][ VENDA CREDITO A VISTA ][ VALOR FINAL: R$ 129,90 ]Este está sendo impresso (Reduzido para o portador do cartão)Recibo tipo 3:[TEST CARD ************3012][POS:03876463 DOC:020621 AUTORIZ:019233][VENDA CREDITO A VISTA ][VALOR FINAL: R$ 129,90 ]Fico grato se puder enviar algum exemplo de como configurar o ACBr para imprimir as demais vias.boa tarde,
este teste 34 eh obrigatorio imprimri todos recibos? ...pois se eu optar sempre impmir o completo (tef discado)
como no teste em "resultados esperados"
"Venda aprovada e confirmada, recibos impressos de acordo com as capacidades e configuração do checkout."
obrigado
Na verdade pra mim esta questão está vaga no roteiro, lá não diz se é obrigatório imprimir todas as vias ou não.
-
Olá pessoal, saudações!
Estou seguindo o roteiro de testes fornecido pela NTK, disponível em http://www.ntk.com.br/download/kit_instalacao_demo_payandgo.zip, e estava ocorrendo tudo bem até chegar no passo 34, onde devem ser gerados os seguintes recibos:
- Completo;
- Diferenciado para o lojista;
- Diferenciado para o portador do cartão;
- Reduzido para o portador do cartão.
Porém, ao finalizar o cupom, são impressos somente os recibos Diferenciado para o lojista e Reduzido para o portador do cartão.
Nos demais passos referentes aos testes de recibos diferenciados, estou tendo problemas similares a este.
Alguém passou por isso ao realizar os testes do roteiro da NTK? Como devo tratar essa questão de recibos diferenciados utilizando o ACBrTEFD?
Desde já agradeço a colaboração de todos!
Restabelecer Comunicação Daruma Fs700
em ACBrSerial
Postado
Analisei o código, alterei algumas rotinas, e estou utilizando os eventos de tratamentos de erros do ACBrECF, porém o problema ainda continua. A impressora só volta a funcionar quando é desligada e ligada.
Fico pensando se existe algum comando que pode ser enviado para que a impressora volte a funcionar sem que seja necessária a intervenção do usuário. O que será que ocorre neste processo de desligar e ligar a impressora que ela volta a imprimir de onde ela parou?
O mais estranho é que com a Bematech não tenho este problema, apenas com a Daruma. Porém se utilizar a dll o problema não ocorre.
Ativei a propriedade ReTentar do ACBrECF, e no evento ACBrECFMsgRetentar, estou fazendo o seguinte:
if (Application.MessageBox(pchar(Mensagem + #13 + #13 + 'Deseja tentar imprimir novamente?'), pchar(Situacao), MB_YESNO + MB_DEFBUTTON1 + MB_ICONQUESTION) = ID_YES) then Result := True;No evento ACBrECFErrorFechaCupom, estou apenas alimentando a variável de referência Tratado com o valor True.
Nunca utilizei estes eventos antes, e não encontrei nenhum exemplo aqui no fórum e no ECFTeste, portanto não sei se está é a maneira correta de manipular estes eventos.
Fico grato se alguém puder enviar algum exemplo.
Daniel, anexo o log da ECF novamente para verificação. Analisando o mesmo verifiquei que o problema com o método AcharPorta foi resolvido, você tem alguma dica do que pode ser feito para tentar restabelecer a comunicação com a Daruma?
ACBrECF.txt