Workflow contrats

Le workflow contrat détermine les droits et conditions applicables à une organisation.

flowchart TD
  besoin["Besoin commercial ou opérationnel"] --> creation["Création du contrat"]
  creation --> conditions["Saisie conditions et droits"]
  conditions --> verification["Vérification interne"]
  verification --> decision{"Contrat validé ?"}
  decision -->|Oui| actif["Contrat actif"]
  decision -->|Non| correction["Correction"]
  correction --> verification
  actif --> application["Droits appliqués aux parcours"]
  application --> suivi["Suivi, modification ou archivage"]

Points contrôlés

Effets d'un contrat actif

• Ouvre ou confirme des droits.
• Peut autoriser la mise en vente.
• Peut porter des conditions de facturation.
• Peut porter dépôt, limite ou conditions particulières.
• Peut influencer les droits transmis dans une hiérarchie d'organisations.

Règles observées

• Un contrat non modèle est rattaché à une organisation et reçoit une référence générée. Il est créé directement au statut Actif : il n'existe pas d'étape « activation » distincte de la création.
• Les contrats modèles automatiques sont dédoublonnés par type, shop, année et type client.
• Les conditions tarifaires sont contrôlées à la création et à la mise à jour.
• Si la TVA vendeur manque sur un contrat non modèle, TARS détermine une TVA par défaut depuis l'organisation (uniquement pour une société assujettie à la TVA ; sinon 0), à partir d'une table de taux standard par pays.
• Un contrat automatique peut faire avancer l'onboarding de l'organisation.
• Une mise à jour de contrat peut propager des flags aux organisations enfants et réindexer l'organisation.
• Un contrat n'est proposable pour une mise en vente que s'il réunit toutes les conditions suivantes : shop du contrat = shop courant, statut Actif, rôle vendeur (pas acheteur), au moins un bloc de tarification de type Vente, et organisation du contrat = organisation du vendeur (sauf transfert de contrat meta.childTransfer activé, qui lève cette dernière condition).
• Le caractère self-service d'une annonce (indexedMeta.saleInformation.selfService) est recopié depuis meta.self du contrat sélectionné au moment de la création du lot — sauf en mode impersonation, où il est toujours forcé à false, quel que soit le contrat.
• La tarification, le mode de vente, le mode de facturation et les modes de paiement/reversement sont recopiés (« figés ») dans les métadonnées de chaque annonce au moment de sa création. Une désactivation ou expiration ultérieure du contrat ne modifie donc pas rétroactivement les lots déjà créés.
• Le champ categoryShortIds d'un bloc de tarification n'intervient pas dans le calcul du frais de vente standard (seul le type de frais compte), mais il restreint bien, côté backend (book-keeper), le bloc utilisé pour calculer les frais d'annulation d'un lot selon sa catégorie — voir Contrats.

Cas de blocage

• Contrat absent.
• Contrat inactif (Désactivé, Expiré ou Archivé) : disparaît immédiatement des contrats sélectionnables pour une nouvelle annonce.
• Conditions obligatoires manquantes (type de client, informations de vente, mode de vente, shop, date de début pour un contrat non modèle).
• Organisation non rattachée au contrat, et transfert de contrat (meta.childTransfer) non activé.
• Shop de l'annonce non couvert par le contrat (shopShortIds).
• Contrat acheteur utilisé pour une opération vendeur (ou inversement).
• Aucun bloc de tarification de type Vente sur le contrat : aucune ligne de prix disponible.
• Statut incompatible avec la demande (ex. tenter de désactiver un contrat déjà archivé — action non proposée pour ce statut).