Informations sur la récurrence

Bonjour,

Je suis en train de finaliser un plugin de paiements récurrents par prélèvements SEPA via la nouvelle version de l'API du fournisseur GoCardLess. Malgré l'exemple de celui de paypal_recurring et l'aide de Claude (IA ! ), ce n'est pas un petit morceau !

Le plugin paypal affiche les informations sur la récurrence issues du produit lui même. Panier :

Merci pour ces éléments.
Globalement, on suit ces spécifications :
- features = true
- Vérification de $order->paymentOptions
- Implémentation de createRecurringSuborder()

Mais j'ai toujours des interrogations sur la durée de l'abonnement.
Dans les options de récurrence, l'objet $order contient :
= array(
'duration' => "1m", // période de base
'value' => null, // montant optionnel
'term' => '12m' // durée totale
)

1. Où et comment configurer le paramètre 'term' dans l'interface administrateur ? duration est fourni par l'assocation produit-plan où on définit la durée de base mais pas la durée totale ('term'). Je ne vois pas d'option dans la définition du plan non plus.

2. Si ce paramètre est bien transmis au système de paiement, devons-nous utiliser cette valeur pour limiter la durée totale de l'abonnement côté système de paiement (dans notre cas, GoCardless) ? Sera-t-il exprimé en nombre de "terms" (number of installments) ou est-ce une durée globale (duration: 1m, terms: 24m) ou encore une date calculée (fin de l'abonnement) ?

Merci d'avance pour ces précisions.

Laurent

Bonjour,

Le nombre de prélèvements/paiements est bien prévu dans les api de Paypal et GoCardless. Dommage qu'on ne puisse gérer cela depuis l'association produit/plan. J'ai contourné en ajoutant un champ "custom" dans les produits pour stocker cette information.

J'ai une autre question concernant les constantes de langues utilisées dans les paramètres du plugin en backend. Certaines sont spécifiques à ce plugin. D'après l'exemple du plugin Paypal, on ne peut pas utiliser un fichier de langue dédié dans le corps du plugin lui-même ? Il faut ajouter nos constantes au fichier language/en-GB/en-GB.com_hikaserial.ini (pour l'anglais) lors de l'installation du script. C'est bien cela ?

Merci

Laurent

Bonjour,

C'est vrai pour les plugin agissant dans le front. Mais j'ai vérifié tous les plugins de payment (gratuits) de la market place et aucun ne gère de fichiers de langues. J'ai aussi regardé tous (je crois !) les plugins de payment livrés de base avec HikaBusiness et je n'ai pas été capable de trouver un fichier XML décrivant un fichier de langue externe.
J'ai essayé plein de configuration de nom ou de déclaration dans le XML. Les fichiers sont bien installés (dans administrator/language) mais jamais utilisés. Les constantes ne sont pas traduites. Sauf si je les mets dans le .ini du composant comme pour le paypalrecurring.

J'ai écrit 3 plugins autre que de payment (zoom, SendEthic et gestion de préinscriptions) qui interviennent tous au moment de la commande sans avoir de paramètrages en back office et là, les constantes sont bien traduites (messages, ou contenus).

Si vous pouviez me mettre sur la piste....

Merci.

Laurent

Bonjour,

Merci pour réponse détaillée et vos conseils pertinents.
J'ai développé des plugins pour Joomla. Certains liés à HikaShop, d'autres n'ayant rien à voir avec Hikashop. Tous avec des fichiers de langues. Cela fonctionne sans problème.
Mon soucis est lié à un plugin de type hikashoppayment.

Si on prend votre plugin paiement example disponible ici : www.hikashop.com/component/updateme/ctrl.../plugin-example.html on trouve lignes 18 à 30 la définition des champs de paramètrage du plugin tels qu'ils apparaissent en BO quand on veut ajouter ce mode paiement à la boutique. Certains utilisent une constante de langue qui est définie dans le fichier de langue du composant. Par exemple CANCEL_URL_DEFINE. Cela fonctionne parfaitement et la traduction apparaît en BO.

Si vous remplacez cette ligne qui n'utilise pas de constante de langue :

'payment_url' => array("Payment URL",'input'), // Platform payment's url

'payment_url' => array("EXEMPLE_PAYMENT_URL",'input'), // Platform payment's url

Bonsoir,

Cela n'a pas été simple mais j'ai trouvé. En fait il faut ajouter dans la classe du plugin :

class plgHikashoppaymentExample extends hikashopPaymentPlugin
{
	/**
    * Load the language file on instantiation.
    *
    * @var    boolean
    * @since  3.1
    */
    protected $autoloadLanguage = true;

Bonjour,

J'ai fait des essais sur onBeforeOrderUpdate qui n'ont pas été concluant. Je vais essayer sur onBeforeSubscriptionUpdate qui semble plus approprié. Il n'y a pas d'état "cancelled" sur les souscriptions. J'aimerais éviter de "jouer" avec "active"/"expired"/"closed" parce que cela correspond à des états de la vie normale d'une souscription. Faut-il utiliser "deteted" pour marquer qu'une souscription a été annulée par le client ou par un admin ? Qu'elle action manuelle en admin (ou via le client) permet de dire qu'une souscription est annulée/arrêtée ?

Merci

Bonjour,

Oui il faut drait ajouter la possibilité d'annuler l'auto-renew depuis le backend. Il y a des situations commerciales un peu "tendues" où il est préférable que l'administrateur puisse mettre fin à l'abonnement et donc aux prélèvements.

Le système hikashop se prète bien à la gestion des abonnements avec paiements (et factures) réguliers. Mais vous devriez reconsidérer votre position sur le statut "cancelled". Il correspond à une vraie information quand on consulte la liste des souscriptions. Et à une vraie étape dans son cycle de vie. "expired" correspond à une fin "normale". "Cancelled" correspond à une fin "avortée". D'autant plus que je ne vois comment et où on utilise le statut "deleted" (qui permet au client de renouveller pour autant ?!?)

Ou alors prévoir que l'auto-renew puisse avoir un statut actif/annulé avec un symbole différent en backend quand l'auto-renew a été annulé. D'autant plus que si je m'en refèrre au code de la vue, le symbole auto-renew n'est affiché que si la souscription est "active" :

<td><?php
	echo hikaserial::getDate((int)$row->subscription_end_date);

	if(!empty($row->subscription_auto_renew) && $row->subscription_status == 'active')
		echo ' <i data-toggle="hk-tooltip" data-title="'.JText::_('HIKA_SUBSCRIPTION_AUTO_RENEW', true).'" class="fas fa-sync-alt"></i>';
?></td>

Bonjour,

Merci pour cet échange de qualité. Je comprends vraiment les raisons de la réticence à faire évoluer un schéma qui fonctionne et, effectivement, je vous rejoins sur le statut des commandes et l'importance de ne plus modifier un service effectué, confirmé et facturé.
Je n'ai pas exploré la possibilité d'ajouter des champs dans extra_data. Je suppose qu'il faut ensuite overrider la vue qui affiche la liste des souscriptions pour faire apparaître l'info. C'est une bonne solution.

Nous avons les 3 schémas en oeuvre.

1. La souscription annuelle (membre) qui prévient l'utilisateur quand elle arrive à expiration. Charge à lui de renouveller ou pas. Cela marche impec. Rien à changer.


2. La souscription mensuelle avec factures mensuelles sans terme. On l'utilise pour un abonnement à un service d'IA sur un site s'adressant à des professionnels. La solution du recurring_payment avec le auto_renew (dans notre cas via Gocardless), là aussi, est parfaitement adaptée. Si le client souhaite cesser son abonnement, il passe en close (on notifie l'admin quand même). Pas nécessaire de rajouter quoi que ce soit.


3. La souscription mensuelle avec factures mensuelles "calée" sur une période. En l'occurence pour nous la durée d'une formation (12, 24 ou 36 mois). Il est important de savoir si l'étudiant suspend son abonnement (cancel auto_renew depuis son espace ou demande à arrêter) car il n'a plus accès à certaines informations et cet abonnement fait partie des conditions de sa formation. Dans ce cas, dans la liste des souscriptions, on ne peut pas distinguer le fait qu'une souscription soit "closed" parce qu'arrivée à son terme d'une souscription "avortée" par le client.