Modulo TPV Redsys no registra conversión en Google Analytics

[gika]

Buenos días,

Me dirijo a ustedes como medida de desesperación ya que no encuentro solución al siguiente problema:

 

Al parecer cuando se realiza un pedido y se paga mediante Tarjeta, por el módulo de TPV Redsys de pago que adquirimos aquí, en algunas ocasiones se registra en Google Analytics la conversión correctamente y en otras ocasiones no se registra.

 

No entendemos a que se puede deber, es muy extraño.  Nos hemos puesto en contacto con el desarrollador del módulo, que se puede ver aquí: http://addons.prestashop.com/es/pagos-prestashop-modulos/6492-pago-con-tarjeta-tpv-virtual-redsys-servired-sermepa.html

y después de realizar numerosas pruebas y abonarle la cantidad de 72€ para que lo revisara "a éxito", no lo ha solucionado.

Nos ha actualizado el módulo a una versión superior y seguimos con el mismo problema.

 

Ya no se que más probar, es una desesperación e impotencia tremenda.

 

¿Me podeis ayudar?

 

Gracias,

 

[idnovate.com]

Buenos días,

 

somos los desarrolladores del módulo.

 

Vamos a aclarar la situación, la intervención se cobró a éxito porqué 2 años después de adquirir el módulo (sin actualizaciones), Redsys os hizo una modificación personalizada en el comportamiento de vuestro TPV Virtual y nos pedisteis ayuda para que funcionase correctamente.

Ese comportamiento hacía que la URL de redirección a la tienda no fuese la correcta y os hicimos un presupuesto para adaptarlo.

Además de eso, os instalamos la última versión del módulo, por lo que no solo se solucionó el problema si no que os actualizamos la versión 2 años después.

 

El tema de Analytics, a parte de tratarse de un módulo ajeno al nuestro, ya os comentamos en el último mensaje en Addons esto:

 

Con el tema de analytics no podemos hacer nada más. El módulo funciona correctamente, si no registra la venta en Analytics debe ser por lo que hemos comentado del Navegador (haced pruebas con el AdBlock de Chrome instalado con los otros métodos de pago también).

 

Desde entonces no sabemos nada más de vosotros. Lo siguiente que nos encontramos es un Post en el Foro exponiendo una situación que para nada se corresponde con la realidad.

 

Saludos,

David

[gika]

Hola David,

Me alegro que respondas en el foro, aunque no estás en lo cierto cuando dices "que no se corresponde con la realidad", eso no es cierto.  No he vuelto a contactarte porque os contraté "a exito" y el problema no está resuelto, y ya no se que más hacer.

 

Seguimos teniendo problemas en el registro de conversiones, pero no solo en Google Analytics, también hemos usado Clicky y tampoco se registran muchas de las conversiones que se producen.

 

Entiendo que esto no es debido a temas ni de Google Analytics ni de Clicky, ya que con el resto de opciones de pago que tenemos puestas no hay problemas(Contrareembolso, Paypal, Transferencia Bancaria), quizás alguna operación no se registre pero eso es normal (por el tema de Adblock de Chrome que comentas).

 

El módulo se compro hace 1 año y dos meses, concretamente el 26/09/13, por lo que 2 años no han pasado como puedes ver.

 

Independientemente de eso, lo único que podemos decir es que el problema no está solucionado, seguimos teniendo el mismo problema inicial después de pagaros "a éxito".

 

Y ojo, estoy diciendo que intentasteis arreglarlo, no me cabe duda, y de hecho estoy seguro que le dedicasteis tiempo, además de actualizarme la versión del módulo, pero los resultados son los que son, y por desgracia para mi seguimos igual.

 

Es por eso que escribo aquí, para ver si hay alguien que haya tenido el mismo problema y lo hayan podido solucionar, lo único que trato de exponer es la evolución.

 

He ningún momento he intentado ofender ni nada por el estilo David.

[idnovate.com]

Buenas,

 

lo que se presupuestó y se facturó "a éxito" fué la redirección a la URL correcta después de la modificación que os hicieron desde Redsys cuando vosotros mismos lo solicitasteis (modificar el TPV Virtual para que no mostrara la pantalla intermedia de Pago Correcto). En ningún momento se habló de Analyitics, tenemos el hilo de la conversación en Addons.

 

El tema de Analyitics surgió a posteriori y queréis asociar el error en la redirección con que no se os registren los pedidos en Analytics, cosa que no es así porqué con las pruebas que hicimos quedó claro que funcionaba correctamente.

 

Los mismos pedidos que se os pierden con Paypal y los demás métodos de Pago se perderán con nuestro módulo si la gente utiliza extensiones de bloqueo de Tracking.

 

El módulo funciona y la incidencia se solucionó correctamente.

 

Saludos,

David

[gika]

Exacto, se pidió "a exito" que cuando realizaran el pago fuera a la url correcta de confirmación de pago, y eso al parecer unas veces ocurre y otras veces no ocurre, es decir, va directamente a la página de historial en lugar de pasar por la página de confirmación.

 

Esto sucede en algunas ocasiones y no en todas, pero no encontramos el patrón común de porque sucede esto en algunas ocasiones y no en otras.

 

El problema de Analytics siempre ha estado presente, de echo, es el problema fundamental y por el cual os contactamos.  Pero como ya te he comentado no es solo problema de Analytics, sino también de Clicky y entiendo que el resto de programas.  Sino pasa por la página de confirmación, que es lo que supuestamente está ocurriendo, es imposible que lo registre ningún programa.

 

Por supuesto, si tu quieres dar en tu empresa el problema como solucionado, lo puedes hacer, sin duda, pero el problema tal y como te vuelvo a repetir no está solucionado.

 

Saludos,

Luis

[idnovate.com]

Hola Luis,

 

te pedimos por favor que dejes de contradecirte en tus conclusiones.

El error no se ha podido reproducir desde que os lo arreglamos, ni con vuestras pruebas ni con las nuestras por lo que ese tema está zanjado, en ningún caso redirecciona a la página del historial, siempre pasa por el order-confirmation (que es donde se añade el código del módulo de Analytics)

 

Tu mismo estás diciendo que el error de analytics lo habéis tenido siempre, y que os pasa también con otros métodos de pago por lo que te agradeceríamos que dejes de sacar conclusiones erróneas respecto a nuestro módulo.

 

Faltas a la verdad al decir que contactaste con nosotros por el tema de Analytics y eso no te lo vamos a permitir, este fue tu mensaje en Addons:

 

Hola,
Tengo un problema en mi tienda online a la hora de que, cuando realicen el pago por TPV, redirija a mi web a la url correcta. Actualmente está redirigiendo a la url del historial de pedidos cuando debería redirigir a la de confirmación del pedido, ¿como se puede cambiar esto?
He llamado a mi soporte del TPV Virtual y me han dicho que sois vosotros los que debeis modificar eso.
Gracias,
Saludos

 

Y más adelante, nos dijiste esto:

 

Hace 3 días llamamos al Servicio de Soporte del TPV Virtual para comentarles este problema y nos dijeron que nos lo cambiaban para que directamente cuando realizaran el pago, le redirigiera a nuestra web.

Lo han cambiado, si, pero ahora el problema es que cuando realizan el pago, redirigen a nuestra web, pero no a la página de confirmación, como debería, redirige a la url de historial de pedidos, donde se ve que se ha realizado correctamente el pedido.

 

Eso fué lo que te valoramos y arreglamos. El error de Analytics es por otro motivo, igual que pasa con Paypal, etc... y está en la parte del cliente.

 

Saludos,

David

[gika]

Hola David,

No consiento que me digas que falto a la verdad, faltaría más que a un cliente le tratarais de esta manera como lo estas haciendo conmigo. No me contradigo en ningún momento, cuando hicimos las últimas pruebas con vosotros, iba a la dirección de confirmación correcta, pero como ya te dije en un principio no en todos los pedidos se produce.  

 

En algunos pedidos va a la dirección de confirmación, y en otros casos, y como te vuelvo a repetir no se en cuales, va a la de historial, entiendo que va a la de historial porque no se registra la conversión ni en Analytics ni en Clicky.

Este error se da con una porcentaje mucho más alto, es decir, más o menos el 50% de los pedidos que se pagan por TPV no se registran.

 

Nosotros decimos la verdad, como puedes ver en los emails que has pegado.

 

Saludos,

[idnovate.com]

Luis,

 

puedes entender que si no se registran pedidos del resto de métodos de Pago, te pasa lo mismo con el nuestro y siempre te ha pasado?

 

Puedes demostrar que en algunos casos no redirecciona bien? Tienes pruebas que lo confirman? Has podido reproducirlo?

 

Hiciste la prueba de compra en tu tienda con Paypal a ver si te registra o no primero con AdBlock activado y luego desactivado como te pedimos en nuestro último mensaje?

Has hecho la misma prueba con el nuestro viendo si te redirecciona bien y te registra el pedido en Analytics?

 

Cuando hayas podido reproducir el error nos avisáis.

 

Saludos,

David

[gika]

Mira David, te pongo el porcentaje de registro de Google Analytics de los últimos pedidos, según el método de pago elegido:

 

- TPV: De los últimos 10 pedidos pagados por TPV, 6 Pedidos se registraron correctamente, 4 pedidos no se registraron (Todos estos pedidos se han realizado después de ponernos la última versión de vuestro módulo)

 

- Contrareembolso: De los últimos 10 pedidos pagados por Contrareembolso, 9 pedidos se registraron correctamente, 1 pedido no se registro.

 

- Transferencia Bancaria: Las 4 últimas transacciones se realizaron correctamente

 

- Paypal: Tendría que ver fechas anteriores ya que a lo largo de esta semana, por obligación de Paypal hemos tenido que actualizar el módulo y este ha dado fallos no solo a mi, sino a muchas otras tiendas.

 

El problema del TPV entiendo que siempre lo hemos tenido, pero no lo sabemos porque antes no se median las conversiones por Analytics.

 

Lógicamente no puedo demostrar que algunos casos no redirecciona bien, pero los datos son los que son, y entiendo que sino se registra ese pedido es porque no ha pasado por la dirección correcta, ¿no crees?

 

Si es necesario hago las pruebas que me dices pero entiendo que no debe ser ese el problema, ¿necesitas que haga las pruebas de compra con Paypal y TPV con y sin Adblock, y te diga si se han registrado?

 

Saludos,

Luis

[idnovate.com]

Buenas Luís,

 

lo que nosotros necesitamos para analizar una incidencia es poder reproducirla.

 

Es muy sencillo, activa AdBlock en tu navegador, haz la compra con nuestro módulo y mira si se registra en Analytics. Desactiva AdBlock y vuelve a hacer la compra, si se registra está claro cual es el problema.

Haz la prueba en varios ordenadores y en varios dispositivos y si consigues reproducir el error de que no te redirige a la página correcta lo miraremos y revisaremos para solucionarlo, hasta entonces los pedidos que no se registran en Analytics son producidos por el navegador no por fallo de nuestro módulo.

 

Lo que resulta curioso a estas alturas Luis es que aún sigas diciendo que todos los pedidos pagados con nuestro módulo y que no se registran en Analytics es porqué no ha pasado por la dirección correcta (fallo del módulo) y los demás métodos de pago es por el navegador.

 

Saludos,

David

[Enrique Gómez]

Si sirve de algo encuentro que el tema de registrar los pedidos en analytics por tpv es una pesadilla.

 

Aunque en principio se trataría de poner la url de pago confirmado (bueno usar una expresión regular, p.ej empieza por http://tudominio/es/confirmacion-pedido) del módlo TPV en lar reglas de analytics, estas expuesto a que el cliente tenga una extensión que bloquee las peticiones a analytics.

 

Lo idea sería usar la API PHP de google en el momento en que quede registrado el pedido en la base de datos.

[Enrique Gómez]

 

Exacto, se pidió "a exito" que cuando realizaran el pago fuera a la url correcta de confirmación de pago, y eso al parecer unas veces ocurre y otras veces no ocurre, es decir, va directamente a la página de historial en lugar de pasar por la página de confirmación.

 

Eso de la página de historial me suena...

 

El problema es que pasa a veces sí y otras no..

 

Quizas sirva de algo pero en PS1.5 en la clase controllers/front/OrderConfirmationController.php al principio en el init si no se cumple unos criterios acaba redirigiendo a history.Si los pasa, en principio acaba mostrando la plantilla order-confirmation.tpl donde se incluye la plantilla que haya implementado el método del módulo de pago...

 

Por lo que parece que esta forma de protección (que sirve entre otras cosas me imagino para evitar que al darle a refrescar pasen cosas raras) puede estar dando problemas en algunos pagos (y no siempre.. lo que es raro).

 

 

 

[gika]

Entonces Enrique, ¿crees que modificando controllers/front/OrderConfirmationController.php  y que no redirigiera a historial podría corregirse? ¿porque casi siempre ocurre en el pago por TPV y no en los otros métodos de pago?

[idnovate.com]

Buenos días,

 

en la prueba que hicimos anoche en vuestra tienda pudimos llegar a la conclusión del problema, los pedidos realizados como invitado sin registro previo te redireccionan al Historial de Pedidos una vez finalizada la compra.

 

Hemos probado en nuestras tiendas de pruebas con versiones 1.5 y 1.6 y no pasa nunca. Aquí tenéis nuestra demo con la misma versión del módulo para que podáis comprobar como funciona correctamente siempre:

http://addons.prestashop.com/demo/FO4919.html

 

Lo que está claro es que el módulo redirecciona correctamente al order-confirmation y es el controlador de Prestashop nativo del core el que os envía al historial, creando correctamente el pedido pero haciendo que el módulo de Analytics no registre la venta para los pedidos realizados como Invitado.

 

Cuando nos pedisteis ayuda, el problema que teníais es que SIEMPRE os llevaba al historial, tema que ha quedado solucionado correctamente.

 

Si queréis aislar el problema, hay que poner trazas en el controlador de Prestashop (OrderConfirmationController.php) y ver cual es el motivo de porqué vuestra tienda con pedidos Invitados va al Historial de Pedidos.

 

Saludos,

David

[Enrique Gómez]

Si queréis aislar el problema, hay que poner trazas en el controlador de Prestashop (OrderConfirmationController.php) y ver cual es el motivo de porqué vuestra tienda con pedidos Invitados va al Historial de Pedidos.

 

Según esto que comentais del Pedido express (como invitado) y teniendo en cuenta que Prestashop duplica cuentas en estos casos

http://www.prestashop.com/forums/topic/303041-multiple-customer-id-with-same-email-id/?p=1535261

 

Es posible que la linea marcada en rojo en caso de pedido express sea la causante de entrar en el if.

 

Esta claro que es un bug de Prestashop...Lo ideal es poner trazas para confirmar esta hipótesis.

 

 

Aunque como solución "temporal" se puede forzar dentro del if($is_guest) para que no se cumpla esa condición y pueda seguir adelante y no acabar redireccionado al history

          if ($is_guest)
		{
			$customer = new Customer((int)$order->id_customer);
			$redirectLink .= '&id_order='.$order->reference.'&email='.urlencode($customer->email);
			$order->id_customer = $this->context->customer->id;
		}

Edited December 4, 2014 by Enrique Gómez (see edit history)

[gika]

Muchas gracias por vuestras respuestas, tanto a Enrique como a David, parece que poco a poco vamos llegando a una posible "solución".

 

La verdad es que por desgracia la terminología que usais es un poco "compleja" para mi y no entiendo muy bien lo que decis cuando os referis a "poner trazas"

 

¿Podríais detallarme que es lo que tengo que modificar exactamente paga que todo funcione correctamente?

 

Gracias,

Edited December 4, 2014 by gika (see edit history)

[Enrique Gómez]

Lo de poner trazas es escribir a un fichero información de que esta pasando.

 

P.ej pones el valor de la orden, customer->id ..etc y  por decir un ejemplo, deduces que el identificador de cliente del pedido no es el mismo que el del "contexto" prestashop... En fin es hacer de detective...

 

 

El problema de estos "bugs" es que hacer pruebas es una pesadilla, no hay nada peor que un bug que no se sabe como reproducir..

 

Una posible solución sería que Prestashop no duplicase clientes en caso de pedido express.. pero habría que habrir la incidencia y esperar a que lo arreglen.

 

Una solución temporal aceptable (en caso de que mi hipótesis sea cierta) sería añadir la linea

$order->id_customer = $this->context->customer->id; 

al final del bloque if, sobre la linea 64 del fichero OrderConfirmationController (en un prestashop 1.5.6.2) de forma que te queda

 if ($is_guest)
		{
			$customer = new Customer((int)$order->id_customer);
			$redirectLink .= '&id_order='.$order->reference.'&email='.urlencode($customer->email);
			$order->id_customer = $this->context->customer->id;
		}

Edited December 4, 2014 by Enrique Gómez (see edit history)

[idnovate.com]

Buenas,

 

Luis, envíanos los datos de acceso FTP por un mensaje en Addons y pondremos nosotros las trazas.

 

Saludos,

David

[gika]

Gracias por tu respuesta Enrique........

 

Muchas gracias a ti también David....... te envio los datos de acceso en privado.........

 

Os iré contando en este post como van las cosas después del cambio, esperemos que se solucionen y no afecte a otros módulos de la tienda 

Edited December 4, 2014 by gika (see edit history)

[idnovate.com]

Buenas,

 

ya hemos localizado el problema de vuestra tienda. El OneStepCheckout, con pedidos realizados por Invitados sin registro crea un usuario "dummy" con estos datos:

 

    [lastname] => OPC Not Delete
    [firstname] => OPC Not Delete
    => [email protected]

 

este usuario tiene una secure_key (que se calcula y se envía a Redsys para la redirección a la tienda) que no coincide con la que se compara en el OrderConfirmationController.php una vez se vuelve a la tienda (la secure_key del usuario real una vez creado no es la misma), por ese motivo, con los pedidos hechos por usuarios no registrados previamente en el OneStepCheckout está haciendo la redirección al Historial de Pedidos.

 

Para solucionarlo, hay que eliminar la comprobación de la secure_key en el OrderConfirmationController.php o seguirá yendo al historial con el OneStepCheckout instalado y usuarios no registrado préviamente.

Con el Checkout estándar de Prestashop no pasa.

Queda claro que el problema no estaba en el módulo, el cual redirecciona correctamente siempre, si no en la forma de calcular la secure_key del usuario invitado por parte del OneStepCheckout.

 

Los demás métodos de pago, al no tener exactamente el mismo proceso de pago no se da la misma casuística (aquí interviene un formulario previo con campos que hay que calcular para enviar a Redsys).

 

Saludos,

David

[gika]

Hola David,

Entonces parece que, según lo que habeis podido ver, el problema es del módulo One Page Checkout de Presteamshop y solo cuando se usa con el módulo de TPV y previamente si el cliente no está registrado.

 

Es decir, que para los clientes registrados previamente que realicen el pago por TPV, se realizará correctamente?

 

He analizado los 4 últimos clientes que no registro Google Analytics y pagaron por TPV y son clientes nuevos que no estaban registrados previamente.

 

Por lo tanto hay algo que no me acaba de cuadrar...... ¿es posible que haya entendido mal tu respuesta?

 

Saludos,

[Enrique Gómez]

Buenas,

 

ya hemos localizado el problema de vuestra tienda. El OneStepCheckout, con pedidos realizados por Invitados sin registro crea un usuario "dummy" con estos datos:

 

    [lastname] => OPC Not Delete

    [firstname] => OPC Not Delete

    => [email protected]

 

este usuario tiene una secure_key (que se calcula y se envía a Redsys para la redirección a la tienda) que no coincide con la que se compara en el OrderConfirmationController.php una vez se vuelve a la tienda (la secure_key del usuario real una vez creado no es la misma), por ese motivo, con los pedidos hechos por usuarios no registrados previamente en el OneStepCheckout está haciendo la redirección al Historial de Pedidos.

 

Para solucionarlo, hay que eliminar la comprobación de la secure_key en el OrderConfirmationController.php o seguirá yendo al historial con el OneStepCheckout instalado y usuarios no registrado préviamente.

Con el Checkout estándar de Prestashop no pasa.

Queda claro que el problema no estaba en el módulo, el cual redirecciona correctamente siempre, si no en la forma de calcular la secure_key del usuario invitado por parte del OneStepCheckout.

 

Los demás métodos de pago, al no tener exactamente el mismo proceso de pago no se da la misma casuística (aquí interviene un formulario previo con campos que hay que calcular para enviar a Redsys).

 

Saludos,

David

 

Se agradece el esfuerzo en investigación para algo que no es culpa vuestra.

 

Gika, seguramente si le comentas al autor del módulo OPC  (tiene un hilo muyyy largo en el foro http://www.prestashop.com/forums/topic/206053-modulo-one-page-checkout-ps-f%C3%A1cil-y-r%C3%A1pida-compra-en-una-sola-pagina/) el problema os dará una solución ya que el es el primer interesado en solventar este tipo de bugs.

 

En teoría serviría una solución "temporal"  homóloga  (un parche) a la de antes pero en este caso metiendo

 

$order->secure_key=$this->secure_key para evitar la redirección posterior

 if ($is_guest)
		{
			$customer = new Customer((int)$order->id_customer);
			$redirectLink .= '&id_order='.$order->reference.'&email='.urlencode($customer->email);
			$order->secure_key=$this->secure_key
		}

Pero estoy seguro que http://www.prestashop.com/forums/user/177112-presteamshopcom/ lo resolverá

Edited December 4, 2014 by Enrique Gómez (see edit history)

[gika]

De acuerdo, voy a hablar con Jehyson, el desarrollador del módulo opc y a ver que comenta.............

 

Gracias.....

[idnovate.com]

Hola Luis,

 

ok.

 

Lo que comentas en tu anterior mensaje, es correcto y de hecho encaja con lo que dices de que los últimos 4 pedidos no contemplados en Analytics son de personas que no se habían registrado previamente (no tenían cuenta de usuario), ese es justo el caso que vemos que redirecciona al Historial con el OneStepCheckout, por lo tanto no se registra el pedido en Analytics.

 

Aclarado entonces verdad?

 

Saludos,

David

[gika]

Hola Luis,

 

ok.

 

Lo que comentas en tu anterior mensaje, es correcto y de hecho encaja con lo que dices de que los últimos 4 pedidos no contemplados en Analytics son de personas que no se habían registrado previamente (no tenían cuenta de usuario), ese es justo el caso que vemos que redirecciona al Historial con el OneStepCheckout, por lo tanto no se registra el pedido en Analytics.

 

Aclarado entonces verdad?

 

Saludos,

David

Ahora si me queda claro lo que quieres decirme.

[PresTeamShop]

Hola a todos,

 

El usuario "gika" nos ha contactado por este problema, que en principio pensamos que era por una mala configuracion del analytics, pero ya viendo esto y lo que comenta "idnovate.com" es totalmente cierto, es un problema de nuestro modulo "One Page Checkout PS"

 

El problema es que el OPC usado por "gika" es la version V1.2.5 liberada el (03/05/2013), la cual es muy antigua. En la version V1.3.7 (09/02/2014) se implementa una mejora en el modulo para generar una mayor compatibilidad con algunos metodos de pago. Dicha mejora soluciona el problema mencionado en este hilo.

 

Siempre recomendamos tener nuestro modulo actualizado a su ultima version, pues sacamos versiones muy a menudo solucionando problemas que se nos son reportados.

 

Con esto podemos dar como resuelto este hilo.

 

Saludos cordiales.

Edited December 4, 2014 by PresTeamShop.com (see edit history)

[gika]

Hola,

Ya he comprado el módulo actualizado de OPC. 

Os iré contando los resultados obtenidos.

 

Saludos,

[gika]

Hola,

Después de 10 días creo que ya puedo dar los resultados.............  Parece que ya se ha arreglado 

 

Hay algunas conversiones que no se han registrado, pero esto es lógico, teniendo en cuenta, como dijo David, que algunos utilizan bloqueadores.

 

Quiero agradecer tanto a David, desarrollador del módulo del TPV Redsys, cuyo módulo no tenía nada que ver con el problema sino que había un problema de "incompatibilidad" con el módulo one page checkout.

También quería agradecer el gran trabajo de personalización de Jehyson de Presteamshop, y por último la ayuda en el foro de Enrique Gomez.

 

Saludos,

[idnovate.com]

Buenos días,

 

ok Luís. 

 

Cualquier cosa nos avisáis.

 

Saludos,

David

[personnumberone]

Buenas noches,

 

Pues lo primero que voy a decir es. ¡Al fin! ¡Me cago mi puta vida! Perdon por la expresión pero he sufrido mucho con esto. He tirado a la basura centenares de euros por este problema y no he podido hacer un correcto seguimiento de la Analytica de mi tienda on line.

Por casualidad yo instale el One Page Check Out casi a la vez que el pago por TPV y nunca pude imaginar que esto tuviera que ver.

Ahora por puntos: Idnovate.es, yo os compre el modulo de TPV con la misma condición de solucionar ese problema y me dijisteis lo mismo que a Gika, el modulo funciona correctamente con lo cual ahi se acabo el soporte. Me parece fatal que si os compro un modulo a condición de que se solucione el problema y no se solucione no me devolvais el dinero:
 

Al contratar:

 

YO:

Buenas tardes,

 

I funciona correctamente con el modulo por defecto de Analytics de Prestashop? Dan asistencia a la configuración para que queden debidamente registradas las ventas en Analytics a través del TPV?

 

Saludos,

 

Ustedes:

 

Buenas tardes,

 

en efecto, funcionaría correctamente con el módulo Analytics de Prestashop. Ofrecemos soporte gratuito en la instalación y configuración de todos nuestros módulos.

 

Saludos,

 

Al no solucionarse el problema:

 

Ustedes:

Hola xxx,

Solo devolvemos el dinero en el caso que módulo no funcionase por lo que agradeceriamos que primero se asegurara que el problema con el tracking de Google Analytics es a causa del módulo TPV que tiene actualmente ya que si viene provocado por otro módulo no solucionará el problema instalando nuestro módulo.

Un saludo.

Cada uno que juzgue el caso como le convenga. Esto es lo que sucedió.

Por otro lado a presteamshop (Jehyson).

 

Tendríais que haber enviado email avisando de un error tan grave, ¿lo hicisteis?
Os estoy escribiendo a vuestra web por el zopim pero no estais. Os he enviado un mail solicitando que me proporcioneis la actualización gratuitamente para compensar todo el dinero malgastado (bastante) y problemas causados (muchos). Espero vuestra respuesta.

A Enrique, con quien trabajo, agradecerle su profesionalidad conmigo y altruismo en los foros.

Y por ultimo a Gika, felicidades y gracias, compañero de sufrimiento, yo ya lo habia practicamente dejado por imposible de arreglar hasta una actualización de mi Prestashop a gran escala.

Saludos y buenas noches

Edited December 18, 2014 by personnumberone (see edit history)

[idnovate.com]

Buenos días,

 

no se si habrás leído el hilo completo pero queda claro que en ningún caso el problema del tracking de Analytics era de nuestro módulo. Se trataba de un problema con otro módulo (en este caso One Page Checkout) y como bien te especificamos en la respuesta que has publicado en tu Post, si el problema no es de nuestro módulo no realizamos la devolución del dinero.

 

Saludos,

David

[personnumberone]

Buenas tardes,

A idnovate: Si, me he leido todo hilo. Yo solo he puesto un resumen de lo que sucedio, cada uno puede sacar su propia opinion.

A Presteamshop: Agradecer que me han facilitado la nueva versión del módulo de forma gratuita.

 

Saludos

[Santori]

Buenas, he caído aquí por casualidad buscando una solución al problema de conversiones no registradas y me parece muy aclaratorio todo esto:

 

Como usuario de prestashop entiendo la frustación del usuario.

Como desarrollador entiendo a id_innovate, que ademas les he comprado modulos y van muy bien., son profesionales, la verdad.

 

Mirando una solución posible a todos los que tengamos este problema con cualquier modulo de One page Checkout se me ocurre:

 

Los usuarios invitados solo pueden visitar su historial una vez parece ser, que es cuando hacen el pedido...

Propongo en la plantilla de historial de pedidos incrustar el condicional:

 

if guest -> codigo de pixel de conversion

 

No esta probado, pero se supone que debe ser correcto.

[idnovate.com]

Buenas, he caído aquí por casualidad buscando una solución al problema de conversiones no registradas y me parece muy aclaratorio todo esto:

 

Como usuario de prestashop entiendo la frustación del usuario.

Como desarrollador entiendo a id_innovate, que ademas les he comprado modulos y van muy bien., son profesionales, la verdad.

 

Mirando una solución posible a todos los que tengamos este problema con cualquier modulo de One page Checkout se me ocurre:

 

Los usuarios invitados solo pueden visitar su historial una vez parece ser, que es cuando hacen el pedido...

Propongo en la plantilla de historial de pedidos incrustar el condicional:

 

if guest -> codigo de pixel de conversion

 

No esta probado, pero se supone que debe ser correcto.

 

Hola!

 

Al final el problema era un bug con el módulo OPC que @PresTeamShop.com ya había solucionado, lo que pasa que la versión que tenía instalada el cliente era un poco antigua

 

Jose.