Mécanisme pour le renouvellement d'une souscription

-- HikaShop version -- : 3.2.2
-- HikaSerial version -- : 2.0.2
-- Joomla version -- : 3.8.3
-- PHP version -- : 5.6.33

Bonjour,

Nous utilisons HikaShop et Hikaserial pour vendre des clefs de licences d'un logiciel. Nous avons écrit un générateur pour HikaSerial qui interroge l'API de LIMElm pour générer des clefs que les clients récupèrent une fois qu'ils ont payé. Tout ceci fonctionne très bien. Merci Hika !

Ces achats concernent un abonnement pour un an. Actuellement, passée une année, leur logiciel n'est plus actif et nos clients doivent acheter une nouvelle licence.

Nous souhaitons mettre en place un mécanisme de renouvellement avec la possibilité d'inciter les clients à le faire avant le terme de leur abonnement. Nous avons acheté HikaSubscription qui semble bien adapté à cet objectif.

Que se passe-t-il quand le client reçoit le mail l'incitant à renouveler son abonnement avant son terme ? Est-il renvoyé vers l'achat d'un produit spécifique ? Du même produit avec une variante "renouvellement" ? Faut-il associer le "plan" de la souscription au produit de l'achat initial ou au produit correspondant au renouvellement ? Comment faire pour que le client qui renouvelle avant le terme de son abonnement bénéficie d'un prix remisé par rapport à ce qu'il devra payer s'il laisse passer la date (il faut qu'il achète une nouvelle clef) ? Comment faire pour que les clients qui n'ont pas d'abonnement en cours ne puisse pas choisir d'acheter le renouvellement (même si l'achat échoue in fine, ce serait mieux qu'ils ne puissent pas du tout y avoir accès) ?

Par ailleurs, au moment où le client paye son renouvellement, je dois déclencher une mise à jour de la date correspondant à la clef générée par HikaSerial lors de l'achat initial sur les serveurs de LIMELm. Etant donné que j'ai un plugin générateur spécifique qui interroge l'API LIMElm pour récupérer cette clef, comment je fais pour différencier l'appel initial (génération d'une clef qui fonctionne actuellement) de l'appel pour renouvellement (passage de la clef en paramètre et modification de la date d'expiration). Existe-il un "hook" spécifique pour accrocher ma fonction ? Genre onRenewSub.... ?

Comment fait le client ? Il consulte ses "serials" et clique sur un bouton "renouveler" qui l'envoie vers un produit ? après s'être connecté ? via un lien de connexion automatique dans le mail ? Il paye et si ok cela déclenche mon trigger pour que je mette à jour sa clef ? Je n'ai pas trouvé de réponses dans la doc disponible. Sauf erreur.

Enfin, nous avons plusieurs centaines de clients ayant acheté un abonnement. Comment fait-on pour "raccrocher" ces achats existants au plan mis en place de façon à ce qu'ils reçoivent un mail au bon moment et qu'ils puissent renouveler via le nouveau mécanisme ?

Merci d'éclairer ma lanterne ! .

Laurent

Merci pour ces éléments de réponse. Je vais faire des essais et reviendrez éventuellement sur le forum si j'ai des questions plus précises.
Est que le trigger de renouvellement invoque la classe définie dans le plugin "Generator Serial" que nous avons créé pour les clefs ou est-ce qu'il faut créer un plugin spécifique ?
Et pour le dernier point (rattachement des clients existants) ?

J'avance....
Tel que livré, le plugin subscription génère une "subscription data" qui est soumise à une validité. Si j'associe le produit à un hikaserial, je n'ai pas de liaison entre les deux. Le hikaserial me fournit un "numéro" et le hikasub un autre qui sont relatifs à la même commande. Ce n'est pas très confortable pour le client. Quand ils consulte ses serials, rien ne l'informe sur la validité restante et la possibilité de renouveler. Et quand il consulte ses abonnements, rien ne lui rappelle son serial. Le numéro affiché n'a rien à voir. Il faut qu'il passe par le numéro de la commande pour faire le rapprochement "à la main" (cf. les copies écran).

Dans notre cas, acheter un produit revient à récupérer une clef. Clef qui est fournie par l'appel d'une API externe. Cette clef ayant une durée de vie limitée nous sommes très intéressés par le mécanisme de renouvellement de hikaSub. Donc, finalement, ne suffit-il pas d'utiliser simplement hikaSub et de générer la "vraie clef" comme étant la "subscription data" ? Et on se passe d'associer le produit à un serial puisqu'on n'utilise pas les mécanismes utilisation/consommation. Un achat = une clef spécifique pour une période donnée.Qu'est-ce qu'on perd ?

Où se trouve l'appel du onBeforeSubscriptionCreate ? quels sont les paramètres ?

Merci,

Bonjour,

Merci pour le point 1. Ce qui me manquait c'était l'emplacement de la classe (administrator/components/com_hikaserial/classes/subscription.php). Je cherchais cela dans un répertoire "model" sous components (front)....

Ok pour le point 2. Que des subs. donc. Du coup, n'est-il pas préférable d'écrire un plugin spécifique au même niveau que Acymailing Subscriber ou GroupSubscriber dans "plan actions" du plan ? Sinon le plugin "serial" ne sera pas déclenché si mon produit n'a qu'une "sub" et pas de serial ? Il risque de ne pas trouver les functions correspondant aux triggers ?

Autre point. Lorsque la commande est créée et pas encore confirmée, la souscription a le statut "clôturée". Ce n'est pas gênant dans le cas d'un paiement par CB car le client voit tout de suite que sa souscription est "active". Mais dans le cas d'un paiement par virement bancaire par exemple, le client qui consulte ses souscriptions dans son espace la voit mentionnée "clôturée" alors qu'elle n'a jamais été "ouverte". Il faudrait plutôt qu'elle soit indiquée commet "en attente" ou "créée". D'un point de vue logique, c'est vrai que si elle n'est ni "active", ni "expirée", elle est "clôturée". Mais d'un point de vue client, ce serait plus normal d'avoir un état de "non activation" avant la première activation/expiration/annulation...

Merci.

Bonjour,

Je reprends ce sujet après un long moment. Merci pour votre dernière réponse.

Je suis en train de mettre au point notre propre plugin "subscriber". Il doit aller chercher une clef api lors de l'activation et synchroniser la fin de cette clef avec la fin de la souscription. Si renouvellement, il doit prolonger cette même clef via l'API.

1/ petit bug qui "m'énervait" car mon plugin ne voulait pas être du bon type : ligne 119 du fichier administrator/components/com_hikaserial/views/plugins/tmpl/listing.php (le elseif qui est sur le type "subscriber"), la deuxième variable du "substr" devrait être -10 et non pas -8 (copier-coller du précédent).

2/ j'ai créé un champ "input" dans la configuration de façon à ce qu'il apparaisse dans les actions du pack (numéro de version du logiciel souscrit dans notre cas). Mais la valeur n'était jamais ré-affichée à l'édition du plan. J'ai corrigé le fichier administrator/components/com_hikaserial/views/plan/view.html.php autour de la ligne 280 :

switch ($value[1]) {
				case 'input':
				case 'int':
				case 'float':
// vide ....		$v = @$this->element->$paramsType->$key;
					$v = @$this->plan->pack_params->{$section}[$key];
					if(empty($v) && !empty($value[2]))
						$v = $value[2];
					if($value[1] == 'int') $v = (int)$v;
					if($value[1] == 'float') $v = (float)hikaserial::toFloat($v);

Bonjour,

Tests en cours. Les mécanismes généraux ont l'air de bien fonctionner. J'avais juste oublié d'activer le CRON. Peut-être à mettre en "gros" au début de la documentation ?...

Le réglage qui permet de déterminer si un client peut renouveler avant/après la date d'expiration et sur quel délai est fixé au niveau général. Il me semble que dans le cadre d'une évolution de votre produit, il faudrait le ramener au niveau de l'abonnement. Ou plus exactement, avoir ce réglage aussi au niveau de l'abonnement pour altérer le fonctionnement par défaut positionné au niveau général. Par exemple, nous commercialisons des licences logicielles et du support. Pour le premier, il est important que le client ne puisse pas renouveler avant la "fenêtre" choisie, proche de la date d'expiration. Et il peut tout à fait renouveller après la date d'expiration. Par contre, pour le support, il n'y a aucune raison de l'empêcher de renouveler quand il veut avant la date d'expiration mais on ne doit pas le laisser faire, une fois cette date passée. Ces deux abonnements ne devraient pas avoir le même comportement sur ce plan.

Quel est le rôle de la dernière ligne de la fonction onSubscriptionActivation du plugin groupsubscriber qui affecte vraisemblablement la valeur true/false à la variable "$ret" ? Cette variable ne semble pas accessible à cet endroit ? N'est ce pas plutôt :

return $this->updateGroups($user_cms_id, $check);

Bonjour Jérôme,

Quelle patience !

Merci pour ces explications. Tout commence à bien s'articuler. Reste un dernier point (pour l'instant !), concernant les 4 rattachements produit-plan.

Pour le Create : c'est limpide. Le produit apparaît en front. Le client achète autant de souscriptions différentes qu'il indique de quantité.
Pour le Renew : limpide aussi. Le produit DOIT être caché sur le front. Il n'est sollicité que par le bouton "renouveler" qui apparaît dans la liste des souscriptions. Il est dédié au renouvellement.

Pour les deux autres... c'est moins clair. La doc dit

and can be use for renewal

• En création (boutique) avec les quantités qui s'appliquent aux nombre des souscriptions différentes
• En création avec les quantités qui s'appliquent à la durée (x fois la durée de base) pour une seule souscription
• En renouvellement (liste des souscriptions actives), souscription par souscription. Les durées de renouvellement étant gérées via les variantes.

Bonjour,

Ok. Bien reçu.
Ceci dit, dès que j'associe un produit à un abonnement pour autre chose que "create" ou "renew", c'est à dire soit "create_renew", soit "renew_create", il refuse d'associer un moyen de paiement au produit. Le panier n'est donc pas utilisable (paiement impossible) lors du premier achat de souscription. Nos moyens de paiements actifs sont le virement, la CB (AtosSips) et PayPal (non récurrent).

Laurent

Bonjour,

Tout est à peu près fonctionnel. Les premiers tests se passent bien.

J'aurais besoin d'un "coup de main" de plus :

On permet à nos clients qui ont acheté une clef (activation d'un logiciel qui tourne sur Windows/Mac) via le mécanisme "Serials" d'HikaSerial, de renouveler cette clef (la clef elle-même est fournie par une API externe). Ce renouvellement est en fait l'achat "normal" d'une souscription spécifique via un lien dans le listing "Serials" qui peuple un champ spécifique que je récupère à la création de la souscription. Ainsi, au lieu de générer une nouvelle clef on réutilise l'existante en calant sa fin de vie sur l'expiration de la souscription.

Ainsi les nouveaux clients n'achètent plus que des "souscriptions" et les anciens migrent doucement au fur et à mesure qu'ils "renouvellent" leur ancien "serial". A terme, ils pourront tous bénéficier des mécanismes de renouvellement et d'alertes propres aux souscriptions.

Dans le cas du renouvellement d'un ancien serial, j'aurais voulu changer le statut du serial (à "delete" par exemple) de façon à ce qu'il disparaisse du tableau de bord de l'utilisateur (listing des serials qu'il a achété).
Il faudrait que cela se passe au moment de l'activation de la souscription "onSubscriptionActivation" ou "onAfterSubscriptionUpdate". Dans le premier cas, j'ai bien un objet "user" mais il ne contient pas d'info sur ses serials.

Sachant que je connais le "serial->data" concerné (stocké dans la souscription), comment je peux le retrouver et changer son statut à l'intérieur d'un trigger "subscription" ? Récupérer l'objet "serial" et le mettre à jour ? Methode du genre updateSerialStatus ?

Merci.

Bonjour,

Parfait, merci. En m'inspirant de votre code et en jetant un oeil à la classe, je commence par chercher le serial basé sur sa donnée et je la "supprime".... Ci dessous le code pour le cas où cela peut intéresser un autre utilisateur :

$serialClass = hikaserial::get('class.serial');
$serial = $serialClass->find($key);
if (count($serial) != 1)	{
	$this->LimeLMsublog("Erreur : il y a plus qu'un serial avec ce numéro de clef !");					
} else {
	if(isset($serial[0]->serial_user_id) && $serial[0]->serial_user_id != $user->user_id) {
		$this->LimeLMsublog("Erreur : le serial trouvé ne correspond pas au user !");	
	} else {
		$serial[0]->serial_status = 'deleted';
		$op = $serialClass->save($serial[0]);			
		if ($op != $serial[0]->serial_id) {
			$this->LimeLMsublog("Erreur : la suppression de l'ancien Serial n'a probablement pas eu lieu !");							
		}
	}
}

Bonjour,

Les mécanismes semblent bien fonctionner.
Mais je n'arrive pas à récupérer le mail de l'utilisateur "onBeforeUpdate" lorsque l'utilisateur vient de s'enregistrer.
En effet, s'il passe commande en tant que nouveau client, l'objet "user" de Joomla n'est pas renseigné au moment du "onBeforeUpdate" où on détecte le passage de "closed" à "active" pour déclencher la génération d'une clef via notre API externe.

Peut-on récupérer un objet "$user" comme dans "onActivation" et sera-t-il renseigné (adresse email) dans le onBeforeUpdate qui fait passer la subscription de "close" à "active" quand le client enchaîne les opérations directement (enregistrement-->creation de la commande-->paiement) ?

Merci.

Laurent