Règles de gestion — Engagements & modules d'abonnement client

À quoi ça sert

Cette documentation décrit les règles métier qui régissent les engagements contractuels des clients ISI-APP lorsqu'ils souscrivent ou résilient des modules. L'objectif est de garantir que :

• Le module ISI Basic (le module maître) reflète correctement la durée d'engagement la plus longue du client.
• Une fois un engagement pris, il ne peut jamais reculer dans le temps (principe du cliquet).
• Les modules secondaires gèrent leurs propres engagements indépendamment.

Ces règles s'appliquent à toute opération de gestion commerciale : ajout d'un module, changement de remise, résiliation.

Concepts clés

ISI Basic — Le module maître

• Module principal et obligatoire de tout abonnement.
• Sa date de fin d'engagement sert de référence globale au client.
• Sans ISI Basic actif et validé, aucun autre module ne peut fonctionner.
• Sa date d'engagement ne recule JAMAIS (principe du cliquet).
• Il ne peut pas être supprimé tant qu'un module secondaire est actif.

Modules secondaires

• Tout module autre qu'ISI Basic.
• Chaque module a sa propre date d'engagement indépendante.
• Peut avoir un engagement plus long que le restant d'ISI Basic — auquel cas ISI Basic est repoussé.

Durée d'engagement issue de la remise

La durée d'engagement est déduite automatiquement de la remise sélectionnée (champ nupercent_less de customer_fac) :

À retenir : seules les remises Isi-APP (9991, 9992, 9997, 9999) portent un engagement. Les remises spéciales et l'absence de remise n'engagent pas le client.

Les 3 règles fondamentales

1. Principe du cliquet sur ISI Basic

La date de fin d'engagement d'ISI Basic ne peut qu'avancer ou rester identique. Elle ne recule jamais, quoi qu'il arrive (résiliation, changement de remise, etc.).

2. Recalcul à chaque ajout de module

Quand un module secondaire avec engagement est ajouté :

• On calcule sa date de fin = date de validation du module + durée d'engagement.
• Si cette date dépasse celle d'ISI Basic → ISI Basic est repoussé à cette nouvelle date.
• Sinon → ISI Basic reste inchangé.

Important : la date de référence pour le calcul est la date de validation/souscription du module, pas la date du jour ni la fin d'ISI Basic actuelle.

3. Pas de recalcul à la résiliation

La résiliation d'un module secondaire n'a aucun impact sur ISI Basic. On ne « cherche » pas le module restant le plus engageant pour redescendre la date.

Matrice des scénarios

Cas particuliers

• ISI Basic expiré au moment d'un nouvel ajout : la nouvelle date est forcément dans le futur, donc ISI Basic est systématiquement repoussé.
• Date de validation rétroactive (régularisation) : le calcul se fait à partir de cette date passée. Si le résultat reste antérieur à ISI Basic → aucun changement.
• Changement de formule de remise en cours d'engagement : recalcul à partir de la date de validation originale du module avec la nouvelle durée.
• Plusieurs modules le même jour : traités séquentiellement, chacun pouvant repousser ISI Basic à son tour.

Contrôles obligatoires

À chaque opération :

1. Vérifier qu'ISI Basic est actif et validé sur le client.
2. Vérifier que la date de validation du nouveau module est renseignée.
3. Vérifier que la remise est cohérente avec le statut du client (ex : remise Association réservée aux associations).
4. Logger chaque changement de date d'engagement ISI Basic (utilisateur, date, ancienne valeur, nouvelle valeur).

Interdictions

• Réduire manuellement la date d'engagement d'ISI Basic — interdit, même par un admin.
• Supprimer ISI Basic tant qu'un module secondaire est actif.
• Souscrire un module secondaire sans ISI Basic validé.
• Modifier une date d'engagement sans tracer l'opération.

Qui l'utilise

• L'équipe commerciale lors des souscriptions et changements d'offre.
• L'équipe administration / facturation pour les régularisations et résiliations.
• Les scripts automatisés de souscription doivent intégrer ces règles.

Doc technique : .claude/technical-docs/platform/module-management-rules.md