• Resolved Ricardo

    (@maverickws)


    Boa tarde,

    Na sequência de contacto relativamente a erro com ref. MB, verificámos o seguinte:

    Cliente cria uma nova encomenda e finaliza a mesma.
    Cliente vai a “Minha Conta” > “Encomendas” e selecciona a opção “Pagar”
    Cliente não realiza qualquer alteração.
    A informação apresentada neste ecrã consiste em:
    3 colunas (produto, qtd, total)
    subtotal
    método de pagamento (multibanco)
    total

    em baixo tem dois métodos de pagamento disponíveis, MB e MBWAY
    Multibanco encontra-se seleccionado por defeito. Mas neste ecrã não é apresentada qualquer informação sobre referencia e entidade (apesar destas já terem sido previamente geradas)
    Cliente não altera nada, simplesmente selecciona que aceita os termos e condições e faz “Pagar encomenda”

    É gerada uma nova referência. Não é gerado qualquer email com a nova referência.

    Não existindo qualquer alteração nem no método de pagamento nem na encomenda, sugerimos que ou os dados de pagamento sejam logo apresentados quando o cliente vai a “Minha Conta” > “Encomendas” e selecciona a opção “Pagar”, ou impedir que seja gerada nova referência ao carregar no “Pagar encomenda”.

    Esta situação está a gerar que os clientes se apresentem em loja com indicação que realizaram pagamentos de encomendas, quando no nosso sistema e backoffice não temos conhecimento deste pagamento.

Viewing 15 replies - 1 through 15 (of 25 total)
  • Boa tarde,

    Cliente vai a “Minha Conta” > “Encomendas” e selecciona a opção “Pagar”

    Se o cliente faz esse caminho, alguma coisa não está bem no workflow, porque esse não é um comportamento normal quando depois de fazer o checkout lhe são apresentados os dados (ent/ref/valor) no ecrã e lhe é enviado um email com a mesma informação.
    Porque é que o cliente ignora os dados que lhe aparecem no ecrã e depois no email?

    É gerada uma nova referência.

    Isso só acontece para clientes com ent/ref configuradas para serem sequenciais e expiração de prazo de pagamento. Temos mesmo de forçar uma nova referência porque a única razão válida para o cliente ir a este ecrã é ter expirado o prazo (ou querer mudar de método de pagamento).

    Não é gerado qualquer email com a nova referência.

    No primeiro contacto que fizeram reportaram um bug, entretanto corrigido, de que nesta situação o cliente recebia o novo email com a referência antiga. Não está de certeza a enviar email? Têm estados de encomenda ou emails customizados?
    Validem esta informação para que possamos verificar.

    Não existindo qualquer alteração nem no método de pagamento nem na encomenda, sugerimos que ou os dados de pagamento sejam logo apresentados quando o cliente vai a “Minha Conta” > “Encomendas” e selecciona a opção “Pagar”, ou impedir que seja gerada nova referência ao carregar no “Pagar encomenda”.

    Esse não é o comportamento que uma gateway de pagamentos do WooCommerce deve ter.

    Esta situação está a gerar que os clientes se apresentem em loja com indicação que realizaram pagamentos de encomendas, quando no nosso sistema e backoffice não temos conhecimento deste pagamento.

    Porque pagaram a primeira que receberam no email, certo?
    É por isto que acho que existe algo estranho no workflow.
    O cliente faz o checkout, ignora a informação na página thank you, ignora a informação recebida no email, depois vai à “minha conta” fazer pagar e é gerada uma nova referência que lhe aparece no ecrã e que ele ignora e depois vai ao email original (inicialmente ignorado) e paga essa referência (que entretanto foi removida da encomenda, porque foi gerada uma nova)?
    Há aqui um comportamento estranho.

    Thread Starter Ricardo

    (@maverickws)

    Olá Marco obrigado pelo feedback.

    Relativamente ao primeiro ponto, o workflow depende um bocado do comportamento do cliente. E como sabemos, os clientes são imprevisíveis, e conseguem sempre fazer o impensável.
    Então aqui é um pouco complicado porque nós não nos podemos responsabilizar por estes comportamentos, temos é a situação de chegar o cliente à loja e não ter nenhuma encomenda para ele devido a esta situação, no entanto o cliente já pagou, com antecedência (4 dias mínimo prévio) e ainda alguém lhe dizer que não pagou, a insatisfação do cliente, preparar encomendas que são produtos com massas que tem que levedar e ser preparadas com antecedência, etc. – uma verdadeira dor de cabeça, com a situação que ocorreu hoje, para garantir a satisfação daquele cliente e evitar criticas online, tive que se parar um forno e estragou-se material na ordem dos €300. Que a gerência, apesar de tudo prefere, a ter criticas online.
    Como o plugin também não guarda histórico de referencias para que se possa encontrar uma referencia antiga, isto já criou agora duas situações de atrito, que podem resultar em maus feedbacks, o que procuramos a todo o custo evitar.

    > Esse não é o comportamento que uma gateway de pagamentos do WooCommerce deve ter.

    Não compreendemos totalmente este comentário. A gateway pagamentos em pagamentos com cartões encaminha para introduzir os dados de cartão/paypal ou outros. Não a geração de uma nova referência, que é o que ocorre aqui.

    > O cliente faz o checkout, ignora a informação na página thank you, ignora a informação recebida no email, depois vai à “minha conta” fazer pagar e é gerada uma nova referência que lhe aparece no ecrã e que ele ignora e depois vai ao email original (inicialmente ignorado) e paga essa referência (que entretanto foi removida da encomenda, porque foi gerada uma nova)?
    Há aqui um comportamento estranho.

    Pois há, o cliente até pode fazer isso porque gosta de carregar em botões, é novo no site e quer ver o que acontece. Honestamente ultrapassa-nos, mas consideramos que há uma necessidade de proteger a nossa loja deste comportamento.

    Quanto ao email, realizei vários testes, com diferentes intervalos de tempo entre a criação da encomenda original e fazer o procedimento”Pagar” referido, nenhuma delas gera qualquer email.

    Na situação anterior que havia sido anteriormente reportada, identificou-se um bug, que requer a alteração do meio de pagamento. Esta alteração gera um novo email, e o bug anterior de enviar a referencia incorrecta está corrigido sim. Eu na altura quando estava ao telefone com a IfThenPay mencionei que (apesar de se identificar aquele bug) não tinha novos emails, e quando testei a alteração do método de pagamento havia a geração de novos emails. Mas tivemos a esperança que fosse isso, e que a correcção resolvesse.

    Mas nesta situação confirmamos que não há qualquer alteração. E nos vários testes não são gerados emails seguindo este flow.

    Pois há, o cliente até pode fazer isso porque gosta de carregar em botões, é novo no site e quer ver o que acontece. Honestamente ultrapassa-nos, mas consideramos que há uma necessidade de proteger a nossa loja deste comportamento.

    O que eu digo é que nunca vimos este comportamento/workflow de clientes em nenhum site, o que é estranho, tendo em conta que temos mais de 4000 utilizadores.

    Quero que compreenda que não estamos a tentar descartar o problema. Apenas alertamos que provavelmente existe alguma coisa no site que faz com que os clientes sigam um caminho que não é habitual.

    Como o plugin também não guarda histórico de referencias para que se possa encontrar uma referencia antiga, isto já criou agora duas situações de atrito, que podem resultar em maus feedbacks, o que procuramos a todo o custo evitar.

    Isto são casos excepcionais e têm de ser tratados dessa forma, o que implica sempre trabalho manual. Nenhuma peça de software consegue tratar todos os casos excepcionais.
    Quando o cliente paga uma referência que não está em nenhuma encomenda, apesar do site não conseguir identificar a encomenda, o dono da loja não deixa de receber o email directo da ifthenpay a notificar do pagamento. Se ao mesmo tempo não recebe o da loja, já sabe que algo está mal. Pode fazer uma pesquisa da referência indicado no email da ifthenpay no seu histórico de emails e encontrar o email original que recebeu quando o cliente inseriu a encomenda (e que tem essa referência original).
    Se ativarem o debug e também o debug para email, recebem também um email quando o site recebe um callback e não consegue identificar a encomenda.

    Mesmo que guardássemos um histórico das referências, por exemplo nas notas da encomenda, seria sempre um trabalho manual de pesquisa.
    Reitero:
    O cliente viu a referência original em dois sítios e ignorou. Decidiu clicar de novo em pagar e apareceu uma nova referência que ignorou e decidiu pagar a antiga. Não temos como resolver.

    Não compreendemos totalmente este comentário. A gateway pagamentos em pagamentos com cartões encaminha para introduzir os dados de cartão/paypal ou outros. Não a geração de uma nova referência, que é o que ocorre aqui.

    Encaminhar para introduzir os dados do cartão ou ir ao Paypal é precisamente gerar uma nova transacção, tal como emitir uma nova referência.

    Podemos fazer aparecer a entidade e referência no ecrã de “pagamento” dentro da área de cliente, se esses dados já existirem, para demover o cliente de entrar num novo processo de pagamento, mas isso seria sempre um desenvolvimento à medida. Não é algo que faça sentido inserir no core do plugin.
    E mesmo nesse caso não podemos garantir que o cliente não clique de novo em “pagar encomenda”, gere uma nova referência e a seguir vá pagar a antiga.

    Mas nesta situação confirmamos que não há qualquer alteração. E nos vários testes não são gerados emails seguindo este flow.

    Vamos verificar esta situação e se detectarmos um problema vamos resolver já na próxima versão, mas se o cliente ignora o que aparece no ecrã e vai pagar a antiga, não temos como garantir que vê o novo email. NOTA: alguns clientes de email (como o gmail) agrupam os emails com o mesmo assunto.

    Thread Starter Ricardo

    (@maverickws)

    Marco,

    Quando o cliente paga uma referência que não está em nenhuma encomenda, apesar do site não conseguir identificar a encomenda, o dono da loja não deixa de receber o email directo da ifthenpay a notificar do pagamento. Se ao mesmo tempo não recebe o da loja, já sabe que algo está mal. Pode fazer uma pesquisa da referência indicado no email da ifthenpay no seu histórico de emails e encontrar o email original que recebeu quando o cliente inseriu a encomenda (e que tem essa referência original).
    Se ativarem o debug e também o debug para email, recebem também um email quando o site recebe um callback e não consegue identificar a encomenda.

    Estamos a falar de pastelarias em quatro localizações geográficas. Os gerentes trabalham na fábrica, literalmente com a mão na massa. Eu dou suporte informático apenas, não trabalho para a empresa, não faço gestão de caixas de correio tão-pouco. Os funcionários de loja não tem acesso aos emails para onde vão as encomendas, os pagamentos do IfthenPay, e por aí fora.
    Esta situação é possível, noutras realidades. Não num negócio que é presencial, e que está agora a dar os primeiros passos no digital.

    Aquilo que se verifica é, conforme referi, comportamentos imprevisíveis – que já ocorreram 2x na ultima semana. Não sei se os outros 4000 vossos clientes tem o público mais brilhante, se calhar temos azar.

    Podemos fazer aparecer a entidade e referência no ecrã de “pagamento” dentro da área de cliente, se esses dados já existirem, para demover o cliente de entrar num novo processo de pagamento, mas isso seria sempre um desenvolvimento à medida. Não é algo que faça sentido inserir no core do plugin.
    E mesmo nesse caso não podemos garantir que o cliente não clique de novo em “pagar encomenda”, gere uma nova referência e a seguir vá pagar a antiga.

    Na nossa opinião se isto nos acontece, e com frequência elevada, poderá acontecer a outros, talvez entidades com mais funcionários informatizados ou a trabalhar ao computador que possam fazer todas as pesquisas e identificar essas situações. Não é o caso.

    O email não é gmail, os testes foram feitos com o meu email profissional, e garanto que não foi gerado nem recepcionado qualquer email.

    O email não é gmail, os testes foram feitos com o meu email profissional, e garanto que não foi gerado nem recepcionado qualquer email

    Quando refiro que alguns clientes de email agrupam as mensagens não foi para dizer que o email era enviado e vocês não notaram. Aliás, indicámos que vamos verificar o problema. O que quis dizer é que mesmo que e email saia, têm de ter isso em consideração e o cliente pode na mesma pagar a referência antiga e é impossível que seja o plugin responsável por esse comportamento do cliente.

    Estamos a falar de pastelarias em quatro localizações geográficas. Os gerentes trabalham na fábrica, literalmente com a mão na massa. Eu dou suporte informático apenas, não trabalho para a empresa, não faço gestão de caixas de correio tão-pouco. Os funcionários de loja não tem acesso aos emails para onde vão as encomendas, os pagamentos do IfthenPay, e por aí fora.
    Esta situação é possível, noutras realidades. Não num negócio que é presencial, e que está agora a dar os primeiros passos no digital.

    Eu compreendo tudo isso, mas como referi são casos excepcionais e têm de ser tratados de alguma forma. Não se pode responsabilizar o plugin por um comportamento errante de um cliente ou por a estrutura do negócio não ter características que permitam gerir o backoffice do negócio.

    Como referi:

    1) Vamos verificar porque é que o email não sai quando o cliente muda o pagamento de Multibanco para Multibanco e se detectarmos o erro, certamente o vamos corrigir.

    2) A alteração do comportamento no ecrã de pagamento dentro da área de cliente só será efectuada com um desenvolvimento à medida, devidamente orçamentado, pois não é uma necessidade geral mas específica.

    Thread Starter Ricardo

    (@maverickws)

    Marco,

    O cliente não muda de multibanco para multibanco.
    O cliente não muda nada.

    A encomenda é a mesma, o valor é o mesmo, o meio de pagamento é o mesmo.
    Deverá existir uma protecção que permita impedir que seja gerada outra referência, e apenas apresente a já existente.

    A existir um orçamento seria para a situação referida acima, nunca para a referida na situação dois.

    No entanto consideramos isto uma protecção geral para todos os clientes existentes e futuros do plugin, como tal necessária.

    @maverickws

    Nas referências sem validade é isso que acontece: aparece a mesma porque não é sequencial, não tem prazo, e podemos re-aproveitar referências, o que não acontece nas sequencias. Nota: as referências sequenciais não estão disponíveis por omissão, apenas a pedido, precisamente porque têm um funcionamento muito mais complexo.

    Nas referências sequenciais, com validade, é sempre gerada uma nova.
    Não existem planos para que funcione de outra forma, porque se o cliente pediu de novo para pagar, devemos renovar o prazo da referência através da emissão de uma nova. Se o cliente paga a antiga, é um problema que tem de ser resolvido através de mecanismos de controlo manual e reconciliação que são normais em qualquer negócio.

    Vamos verificar a questão do email quando pede novo pagamento e corrigir se confirmarmos o problema.

    Quanto às restantes questões sobre o que faz sentido ou não ser orçamentado, penso que não faz sentido entrar em loop de argumentos.

    Thread Starter Ricardo

    (@maverickws)

    Boa tarde,

    A nossa loja cancela as encomendas automaticamente quando a referencia multibanco expira. Não pretendemos que o cliente renove referencia nenhuma, mas sim que, caso deixe expirar a existente, faça nova encomenda.
    Isto é necessário pois é um requerimento do próprio negócio. As encomendas requerem preparação prévia, que vai desde a preparação da massa, o processo de levedura, preparação pré-cozedura, e cozedura. Logo, a encomenda tem que ser paga com uma antecedência de quatro dias para que nos 3 dias a seguir se assegure que todas as encomendas serão satisfeitas.

    A própria inexistencia de feedback na plataforma de que a encomenda foi paga faz com que o cliente chegue à loja para levantar os produtos e não exista nada para ele.

    Só temos a lamentar que o Marco se queira sobrepor e tente, de forma totalmente inoportuna, impor o seu pensamento de “mecanismos de controlo manual e reconciliações” que serão sem dúvida algo sem complexidade para quem trabalha atrás de um computador no seu dia a dia, e com facilidade de operação nos meios informáticos, mas uma situação totalmente irreal na área de negócio desta empresa., e dos seus responsáveis, que trabalham numa área totalmente distinta. Por isso mesmo existe um backoffice no WooCommerce que informa o estado das encomendas.

    Mais informo que nos resta informar a IfThenPay que a nossa empresa se vê assim obrigada a procurar outra entidade que ofereça uma solução com maiores garantias para que estes problemas não se verifiquem, pois não é de todo admissível, nem o descartar de encontrar uma resolução par ao problema existente – que passaria por criar uma protecção para não gerar novas referências quando já existem referências válidas, verificando a encomenda X, o valor, o meio de pagamento seleccionado, e caso as condições se verifiquem, retorna a referencia existente em vez de uma nova – nem pela tentativa de imposição das suas ideias ao negócio de outros.

    Cumprimentos

    • This reply was modified 3 years, 11 months ago by Ricardo.

    Olá de novo,

    Efectivamente quando o cliente pede de novo para pagar, e emitimos novos dados (para referências sequenciais), o novo email não sai porque a encomenda muda de “on-hold” para “on-hold” e não há mudança de estado a forçar o email.

    Na próxima versão do plugin vai sair essa correcção.
    Se quiserem desde já ficar com a correcção do vosso lado (desde que tenham já a versão 4.4.9), devem substituir o ficheiro class-wc-multibanco-ifthen-webdados.php por este: https://we.tl/t-hEt0RiUFeJ

    Queiram testar fazer encomenda com MB, ir à área de cliente pedir de novo para pagar de novo com MB, e verificar que receberam o email com os mesmos (novos) dados de pagamento apresentados no ecrã.

    NOTA: acabámos de corrigir o link no comentário anterior. Por favor usem este link: https://we.tl/t-hEt0RiUFeJ

    @maverickws

    Como bem indicou tem um requerimento específico deste negócio e tudo o que são requerimentos específicos têm de ser tratados com soluções específicas, à medida.

    Quanto aos restantes comentários sobre uma suposta sobreposição da minha parte, considero que são inoportunos e não vou manter uma discussão sobre este assunto.

    Aguardo feedback sobre a correcção do erro reportado para que possa encerrar este ticket:

    É gerada uma nova referência. Não é gerado qualquer email com a nova referência.

    Thread Starter Ricardo

    (@maverickws)

    Conforme indiquei, o problema é: não existindo qualquer alteração à encomenda, aos produtos, ao meio de pagamento, não deverá ser gerada nova referência.
    Caso a correcção não vise este problema, não nos é, de forma alguma, relevante.

    Amanhã daremos seguimento junto da IfThenPay.

    Cumprimentos.

    Thread Starter Ricardo

    (@maverickws)

    Aproveitamos para informar que se verificou MAIS UMA destas situações em encomendas realizadas no passado dia 23 Fevereiro (anterior à activação da depuração de logs).
    Desta forma, passam para 3 situações identificadas no espaço de 2 semanas.
    Face à inexistência destas situações anteriormente, e não havendo ainda 100% confirmação de qual a origem, sendo a sequenciação da referencia anterior à da próxima encomenda, começamos a crer que se trata de um bug na geração de referencias que foi introduzido numa recente actualização, e nem sequer relacionado com a suposta origem especulada anteriormente.

    Boa noite @maverickws,

    Qualquer referência gerada quando se está em modo sequencial / com expiração é posterior à referência gerada anteriormente, independentemente de ser a mesma encomenda ou não.

    sendo a sequenciação da referencia anterior à da próxima encomenda

    Não entendi esta questão, mas é perfeitamente possível, por exemplo:
    – Cliente faz a encomenda 8888 e gera a referência com sequência 8
    – Esse mesmo cliente pede outra referência indo ao ecrã “Pagar2 e gera a referência com sequência 9
    – Outro cliente faz a encomenda 9999 e gera referência com sequência 10 e paga essa referência
    – Já depois o cliente anterior paga a referência 8 ou 9

    A referência com sequência 8 ou 9 é anterior à da encomenda seguinte apesar de er sido paga depois.

    Se não percebi bem, por favor tente expor a questão de outra forma.

    Infelizmente não temos como confirmar o eventual bug sem logs, portanto temos mesmo que aguardar que se repita, com o os logs activados, para podermos analisar, já que não conseguimos replicar o problema.

    Thread Starter Ricardo

    (@maverickws)

    Olá Marco,

    O que eu quis dizer foi que a segunda referência é gerada antes da próxima encomenda com método MB, em todas as situações que se verificou.

    Estamos com a depuração de logs activa e aguardamos um caso cuja encomenda tenha sido colocada após a activação dos logs extra.

Viewing 15 replies - 1 through 15 (of 25 total)
  • The topic ‘Erro ref. MB’ is closed to new replies.