Gestion des abonnements/souscriptions + import souscriptions?

  • Posts: 11
  • Thank you received: 1
  • Hikaserial Subscription Hikashop Essential
5 days 6 hours ago #371738

-- url of the page with the problem -- : nwd4.cloudaccess.host/librairie/product/...ement-resonance.html
-- HikaShop version -- : 6.4.1
-- HikaSerial version -- : 6.1.0
-- Joomla version -- : 6.1.0
-- PHP version -- : 8.3

Bonjour,

Nous démarrons sur la mise en place des souscriptions.

<1> Paramétrage produit abonnement : Nous gérons depuis des années des commandes d'abonnements (1 an uniquement, 1 seule formule d'abonnement, on ne peut pas faire plus simple). L'objectif est de pouvoir générer un rappel automatique avant échéance.
Compte-tenu de cet objectif nous avons choisi le "Type de relation" "Création puis renouvellement". Est-ce le bon choix, sachant que nous n'avons pas compris la différence avec le type "Renouvellement ou création".
Je joins une image.

Nous avons créé une commande de notre produit actuel d'abonnement et 2 questions apparaissent en premier lieu:
<2> la souscription est associé à un statut "Cloturé" alors que la commande est simplement créée et pas encore payée. Qu'est-ce que cela signifie et où se paramètrent les statuts

<3> les dates de début et de fin de souscription ne sont pas renseignées, y-a-t-il un paramétrage à activer?
Je joins une image.

<4> Import de souscriptions ?
Est-il possible d'exporter les commandes d'abonnements en cours et de les importer au niveau des souscriptions? Avez-vous une procédure?
Par ailleurs, la question se pose en terme de début de souscription, doit-on prendre en compte la date de la commande?
Et également comment alimenter la clé de souscription?

Merci d'avance pour vos réponses.

Attachments:

Please Log in or Create an account to join the conversation.

  • Posts: 26349
  • Thank you received: 4066
  • MODERATOR
3 days 2 hours ago #371765

Bonjour,

1 - La notion entre "création puis renouvellement" et "renouvellement ou création" est effectivement assez spéciale.
Il y a une explication dans la page de tutorial : www.hikashop.com/support/documentation/4...iption-tutorial.html

* Creation then Renewal will create subscription and can be use for renewal (manually or recurring).
Buying multiple products in the same order will create multiple subscriptions.
* Renewal or Creation will create subscription and can be use for renewal (manually or recurring).
Buying multiple products in the same order will create one single subscription and extend its duration.

La différence est donc surtout quand un utilisateur va acheter plusieurs produits en même temps.

2 - Le workflow de changement d'état d'une souscription est assez précis.
Afin d'éviter qu'une personne n'ai une souscription "non valide" mais dans un état lui permettant de faire un renouvellement (potentiellement moins chère) ; lors de sa création la souscription est dans un état "cloturé" qui est un état dit "final".
Seule la commande qui a créée cette souscription est capable de l'activer lors de son paiement (sa confirmation...).
Nous aurions pu effectivement ajouter un nouvel état pour ce cas d'activation ; mais j'ai préféré limiter le nombre d'états possibles.

3 - La date de démarrage est de fin est initialisée lors de l'activation de la souscription ; donc quand la commande sera confirmée.

4 - Nous avons un système d'import de serial ; mais l'import de souscription est plus compliqué à mettre en oeuvre.
Le problème majeur est le fait qu'une souscription peut aller modifier l'utilisateur Joomla pour lui affecter un groupe.
Alors qu'un import "massif" est principalement de l'écriture en base de données ; cette interaction avec Joomla ne peux pas se faire en même temps.
Donc, il serait possible de faire un import de souscription massif en base de données mais sans que les utilisateurs n'aient l'affectation d'un groupe Joomla.

Au niveau de la clé de souscription, il s'agit principalement d'un contenu aléatoire (et unique) qui est généré par le composant.
Il s'agit d'un choix "historique" puisque HikaSubscription est l'évolution d'HikaSerial et nous avons utilisé le système de génération aléatoire de numéro de série pour avoir notre générateur de "numéro de souscription".
Effectivement, en cas d'import massif ; il est préférable de passer par du code d'HikaSerial pour créer massivement des codes (vérifiés uniques).

Cordialement,


Jerome - Obsidev.com
HikaMarket & HikaSerial developer / HikaShop core dev team.

Also helping the HikaShop support team when having some time or couldn't sleep.
By the way, do not send me private message, use the "contact us" form instead.
Last edit: 3 days 2 hours ago by Jerome.

Please Log in or Create an account to join the conversation.

  • Posts: 11
  • Thank you received: 1
  • Hikaserial Subscription Hikashop Essential
1 day 8 hours ago #371777

Bonjour Jérôme,

Merci pour vos réponses.
Nous n'avons pas de notion de groupe client.

Démarrer les souscriptions pour de nouveaux abonnements nous semble désormais possible, bien que certains sujets nous semblent obscurs (par exemple où sont gérés les textes des emails de notification avant / après la date de fin de souscription - mais pour ne pas tous mélanger nous créeons un ticket spécifique).

Notre problématique principale est l'initialisation des souscriptions à partir des commandes existantes d'abonnements. Nous avons une centaine de commandes d'abonnement d'1 an (donc de souscriptions). L'objectif est de déclencher les notifications de renouvellement.
Nous avons fait un test d'import de 2 souscriptions via PHPMyadmin dans la table XXX_hikaserial_subscription.
Je joins 2 images, à partir desquelles nous avons 3 questions:
1- Est-ce qu'un import dans cette table uniquement (sans jointure avec les autres tables, les commandes notamment), permettra de déclencher les notifications de renouvellement?
2- Devons-nous obligatoirement alimenter le champ "Clé de souscription" et si oui comment?
3- Dans le cas où l'import évoqué ci-dessus n'est pas recommandé, comment générer manuellement les souscriptions? Nous sommes allés en modification de commande, mais sans comprendre où, ni comment, modifier pour déclencher la souscription correspondant (cf image jointe).

Merci d'avance pour vos réponses.

Salutations.

Attachments:

Please Log in or Create an account to join the conversation.

  • Posts: 26349
  • Thank you received: 4066
  • MODERATOR
21 hours 55 minutes ago #371789

Bonjour,

Le liens avec une commande n'est pas nécessaire ; cela n'est requis que pour le renouvellement automatique puisque la commande va être en récurrence.
Si votre client a effectivement payé pour son abonnement ; vous pouvez ajouter l'identifiant de la commande dans l'import dans la table "hikaserial_order_subscription" ; mais cela va vous demander différentes informations assez complexe si vous n'êtes pas en train de traiter une commande HikaShop avec un produit lié à une souscription.

1 - Seul le "date de fin" permet d'autoriser le renouvellement et de déclencher les emails de renouvellement.
2 - Oui ; il s'agit d'un texte qui est aléatoire et qui doit être unique ; Il vous est possible de construire ce champs à partir d'éléments tels que la date, l'identifiant de l'utilisateur, etc.
3 - Il n'est pas possible d'ajouter une souscription à une commande comme peut le faire HikaSerial ; vous pouvez créer manuellement une souscription et son "serial" sera généré automatiquement. Car la commande est optionnelle pour le fonctionnement.

Cordialement,


Jerome - Obsidev.com
HikaMarket & HikaSerial developer / HikaShop core dev team.

Also helping the HikaShop support team when having some time or couldn't sleep.
By the way, do not send me private message, use the "contact us" form instead.

Please Log in or Create an account to join the conversation.

Moderators: Obsidev
Time to create page: 0.068 seconds
Powered by Kunena Forum