Contrats

Les contrats définissent les conditions dans lesquelles une organisation peut acheter, vendre, être facturée ou bénéficier de droits particuliers.

À quoi sert un contrat ?

Cycle de vie fonctionnel

flowchart TD
  draft["Contrat préparé"] --> review["Contrôle interne"]
  review --> active{"Validé ?"}
  active -->|Oui| actif["Contrat actif"]
  active -->|Non| correction["Correction ou rejet"]
  actif --> usage["Droits appliqués aux ventes, achats, factures"]
  usage --> archive["Archivage ou remplacement"]

Actions possibles

Règles de gestion

• Les droits d'une session peuvent dépendre des contrats actifs.
• Une mise en vente self-service peut exiger un contrat actif. Voir Éligibilité au self-service.
• Certaines conditions financières doivent être présentes pour générer les factures.
• Un contrat template ne doit pas être confondu avec un contrat appliqué à une organisation. Voir Contrat modèle vs contrat non modèle.
• Une organisation parent peut transmettre certains droits seulement si cette transmission est prévue, via le transfert de contrat activé sur le contrat parent (meta.childTransfer). Concrètement, la vérification d'appartenance organisation-contrat est alors contournée : n'importe quelle organisation de la hiérarchie visible (l'organisation courante et ses ancêtres) peut sélectionner ce contrat pour créer une annonce, pas seulement les organisations filles directes.
• Les accès ouverts par un contrat se cochent dans son onglet « Accès », regroupés par thème; ils plafonnent ce que les utilisateurs de l'organisation peuvent obtenir. Voir Calcul des droits d'accès.
• Un « niveau d'accès » de contrat (meta.accessLevel : Admin, Client, Partenaire, Vendeur) est distinct de l'arbre des clés d'accès. Le niveau Admin n'est sélectionnable que si l'organisation du contrat est l'organisation propriétaire du shop.

Contrat modèle vs contrat non modèle

Un contrat non modèle peut garder une référence vers le modèle dont il est issu (meta.sourceTemplateShortId), utilisée notamment pour retrouver le libellé du modèle d'origine.

Éligibilité d'un lot au self-service

Un contrat n'est proposable pour créer/rattacher une annonce en self-service que si toutes ces conditions sont vraies :

Si le contrat sélectionné porte meta.self = true, l'annonce est marquée self-service (indexedMeta.saleInformation.selfService) et suit le workflow self-service (soumission directe possible en statut « à modifier », pas de validation de vente préalable côté back-office). Si meta.self est absent ou false, l'annonce suit le circuit de validation classique.

Exception : en mode impersonation (un admin agit pour le compte d'un vendeur), le self-service est toujours forcé à false, quelle que soit la valeur meta.self du contrat — un admin ne publie jamais en self-service au nom d'un tiers.

Restriction tarifaire par catégorie

Chaque bloc de tarification d'un contrat (meta.pricing[]) porte un champ categoryShortIds permettant, dans le formulaire d'édition, de restreindre visuellement ce bloc à certaines catégories de produits. Le calcul du frais standard appliqué à un lot (sélection du bloc de tarification, sélection de la ligne de palier), côté front, ne filtre pas par catégorie — seul le type du bloc (commission vendeur, frais acheteur, etc.) est utilisé pour retrouver le bloc à appliquer.

categoryShortIds est en revanche bien exploité côté backend, mais pour un calcul différent: le service de facturation (auctelia/book-keeper, buildCancellationInvoiceLines) l'utilise pour choisir le bloc de tarification à appliquer lors du calcul des frais d'annulation d'un lot — le bloc dont categoryShortIds contient la catégorie du lot est retenu; un bloc sans categoryShortIds (liste vide) s'applique à toutes les catégories, en repli. Ce filtre par catégorie ne s'applique donc pas au tarif de vente normal, seulement au calcul du frais d'annulation.

Tarification portée par le contrat (taux, commission, TVA)

Chaque bloc de tarification (meta.pricing[]) définit :

Calcul d'une ligne applicable pour un montant d'enchère donné : les lignes sont triées par seuil start décroissant, et la première dont le seuil est inférieur ou égal au montant est retenue (à défaut, la première ligne du bloc sert de repli). Le montant du frais est alors : pourcentage du montant si percent > 0, sinon montant fixe (fix), puis le résultat est borné par min et max de la ligne si définis.

Si la TVA vendeur (meta.sellerVat) est absente sur un contrat non modèle, TARS calcule une TVA par défaut à partir du pays de l'organisation, uniquement si celle-ci est une société assujettie à la TVA (type: COMPANY et subjectToVat: true) ; sinon la TVA par défaut est 0. Le taux appliqué provient d'une table de taux standard par pays (ex. FR 20 %, DE 19 %, BE 21 %, LU 17 %…), recalculée automatiquement quand l'organisation change sur le formulaire.

Effets des changements de statut (désactivation, expiration, réactivation)

Effet immédiat le plus important : dès qu'un contrat quitte le statut Actif, il disparaît immédiatement de la liste des contrats sélectionnables pour créer ou rattacher une nouvelle annonce (le filtrage par statut Actif est une des conditions d'éligibilité, voir plus haut) — un vendeur ne peut donc plus créer de nouveau lot avec ce contrat tant qu'il n'est pas réactivé. En revanche, cet effet n'est pas rétroactif : la tarification et les modes (facturation, paiement, reversement) sont recopiés dans les métadonnées de chaque annonce/lot au moment de sa création (indexedMeta.contractInformation) ; désactiver ou expirer le contrat ne modifie donc pas les lots déjà créés ni les commissions déjà appliquées sur des ventes en cours.

Ce qui est implémenté

• Un contrat non modèle est rattaché à une organisation et reçoit une référence générée.
• Les contrats modèles automatiques sont contrôlés pour éviter les doublons sur type, shop, année et type client.
• Les conditions tarifaires sont validé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.
• 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.
• La fiche détail admin d'un contrat regroupe accès, empreinte bancaire, contacts, informations, libellés, tarification et paramètres, avec un arbre des clés d'accès accordées.
• Les listes de contrats proposent des filtres rapides : « à échéance sous 90 jours » (indexedMeta.expirationDate), et « à moi » qui restreint aux contrats des organisations dont l'utilisateur connecté est account manager (champ accountManagers de l'organisation). Ambiguïté : le filtre « à valider » mentionné précédemment n'a pas été retrouvé dans le code des filtres de liste de contrats consulté.
• La case d'engagement vendeur sur les conditions tarifaires affiche désormais explicitement le prix minimal réellement engagé (prix de réserve si défini, sinon prix de départ), pas un texte générique.
• Les contrats utilisables pour créer une annonce sont restreints à ceux de l'organisation elle-même et de ses ancêtres, pas ceux de ses organisations filles.
• Activer le rôle acheteur d'une organisation pour un shop, depuis sa fiche admin, déclenche automatiquement l'activation du contrat acheteur correspondant; en cas d'échec, l'enregistrement de la fiche n'est pas bloqué mais un message d'erreur dédié est affiché.

Actions par statut implémentées

Impacts