Statuts et transitions

Les statuts décrivent l'état d'un objet. Les transitions indiquent comment il peut évoluer.

Sauf mention contraire, les règles ci-dessous sont vérifiées côté interface (bouton visible seulement si la condition est remplie) et rejouées côté serveur à l'exécution — un utilisateur ne peut donc pas déclencher une transition simplement en forçant l'appel.

Lot et vente

Actions de lot observées

Un profil super-admin disposant du droit dédié SUPER.ITEM.STATUS_MANAGE peut, en dehors du workflow standard, forcer manuellement un lot vers un statut aval (validé, ouvert, fermé, assigné, facturé, non attribué, invendu, payé, non payé, confirmé, remboursé, commissionné, soumis, soldé) — hors statuts amont (brouillon, à contrôler, refusé). Cette transition exceptionnelle reste tracée comme toute action sensible et n'est pas disponible sur un lot legacy.

Un vendeur peut aussi traiter en masse (jusqu'à 50 lots) l'acceptation ou le refus de l'attribution des lots en « vente à valider » ayant reçu au moins une enchère.

Offre à prix fixe

Demande d'autorisation (accès à un lot ou une vente)

Compte utilisateur (personne)

Le statut d'une personne n'est pas géré par le service de workflow des lots mais par le service « personnes » et l'API. Le parcours nominal de vérification enchaîne quatre étapes en auto-service :

Statuts particuliers, hors parcours nominal :

Règles de gestion

• Connexion : un compte « à valider » ou « bloqué » ne peut pas se connecter ; un compte valide ne peut pas non plus se connecter si son organisation est bloquée.
• Invitation : une personne créée via une invitation acceptée naît directement « email confirmé » et hérite des rôles portés par l'invitation.
• Changement d'email : repasse le compte « à valider » (nouvelle confirmation exigée).
• Blocage : manuel par un administrateur disposant de ORGANISATION.USER.MANAGE, ou automatique (abus d'envoi de SMS, ou email / mobile / téléphone figurant sur liste noire). Le blocage ajoute les coordonnées à la liste noire et ferme la session.
• Cascade organisation → personnes : bloquer une organisation bloque tous ses membres ; la débloquer les débloque. Par ailleurs, faire passer une organisation « validée » fait passer ses personnes « compte complet » ; une organisation « désactivée » désactive ses personnes.
• Déblocage : un compte débloqué revient à « mobile confirmé » (ou « email confirmé » s'il n'avait jamais validé son mobile) — jamais directement « compte complet » : il doit re-finaliser son profil.
• Forçage : il n'existe pas de garde de transition stricte côté back-end. Un administrateur disposant de ORGANISATION.USER.MANAGE (ou l'utilisateur sur lui-même) peut faire écrire un statut aval directement, sans repasser par les étapes intermédiaires.
• KYC / SCA : ne sont pas portés par le statut de la personne — ils relèvent du niveau organisation (voir KYB ci-dessous et Documents et conformité).

Document

Indépendamment de ce cycle, un utilisateur disposant du droit ORGANISATION.DOCUMENT.MANAGE peut forcer directement un document vers n'importe quel statut aval (validé, refusé, expiré, archivé, supprimé) via un changement de statut manuel, quel que soit le statut de départ — ce mécanisme sert notamment à corriger une erreur de traitement sans repasser par le circuit standard.

Facture

Deux statuts d'attente relèvent d'un contrôle Finance au-dessus d'un seuil : « en attente d'avance de TVA » (bordereau commissaire-priseur) et « en attente d'ajustement de paiement » (encaissement entrant). Ils suspendent la facture jusqu'à confirmation par la Finance.

Chaque action est déclenchée manuellement (bouton visible seulement si le statut le permet) et exige un droit métier précis, dérivé du type de facture — par exemple facturer une facture de vente exige un droit distinct de facturer une facture de commission. Les actions de rejeu en masse (« Facturer en masse », « Confirmer en masse ») sont réservées aux profils administrateur.

Actions de facture observées

Les actions « Facturer en masse » et « Confirmer en masse » ne s'appliquent respectivement qu'à des factures toutes au statut « à valider » ou toutes au statut « payée », et à des factures d'un même shop.

Types de facture et cycle associé

Le cycle exact dépend du type de document (le référentiel a migré des anciennes « catégories » vers des « types de document ») :

En courtage à facturation double, la vente et les frais acheteur sont deux factures distinctes émises ensemble. Les statuts « annuler / marquer non payé / rembourser » s'appliquent selon le type (les frais acheteur suivent la vente, la commission et le bordereau n'ont pas d'étape de paiement acheteur).

Contrôles de paiement MangoPay (les « gates »)

Certaines transitions sont bloquées tant que le paiement en ligne n'est pas prêt — le back-office affiche alors un message explicite plutôt que d'exécuter l'action :

• Émettre une facture (à valider → facturée) est bloqué si le compte de paiement de l'acheteur n'est pas prêt (compte payeur manquant, IBAN virtuel manquant, encaissements non actifs).
• Confirmer (payée → confirmée) est bloqué tant que le portefeuille / bénéficiaire du vendeur (courtage) ou son KYB interne n'est pas prêt / validé.
• Payer (facturée → payée) : un ajustement de paiement au-dessus d'un seuil met la facture « en attente d'ajustement » (validation Finance) au lieu de la passer payée ; un bordereau CP au-dessus du seuil d'avance de TVA passe « en attente d'avance de TVA ».

Quand une de ces gates bloque la facturation automatique à l'attribution d'un lot, la facture reste « à valider » pour traitement manuel — il n'y a pas de nouvelle tentative automatique.

Facturation automatique

Selon les paramètres du contrat de vente :

• à l'attribution d'un lot, si l'attribution automatique et la facturation automatique sont activées, la facture de vente est créée et émise automatiquement (sous réserve des gates ci-dessus) ;
• un paramètre d'auto-impayé pose une date d'expiration : un traitement quotidien passe alors les ventes échues « non payées » ;
• la commission peut être générée automatiquement à la confirmation, et son mouvement bancaire soumis automatiquement, selon les paramètres du contrat (sinon la commission reste « à valider » pour validation manuelle).

Ces paramètres sont relus sur le contrat à chaque décision : les modifier change le comportement des factures concernées.

Non-paiement, annulation et avoirs

• Passer une vente « non payée » (manuellement ou par le traitement automatique) désactive la facture, remet les lots liés en « non payé », et bloque l'organisation acheteuse pour non-paiement.
• Si le shop l'active, un avoir d'annulation est alors créé automatiquement : ses frais d'annulation sont plafonnés par le montant de la caution MangoPay active (sans caution active, pas d'avoir) ; la caution est capturée et l'avoir soldé.
• Un avoir de frais acheteur (note de crédit) peut être émis sur une vente déjà facturée : les frais sont recalculés au prorata, et l'avoir est soldé en cascade avec la facture parente.
• « Annuler » et « Rembourser » acceptent un motif (facultatif côté back-end) ; un remboursement ne peut pas dépasser le montant payé, et un remboursement partiel ne change pas le statut de la facture.

Lien facture → statut du lot

Le statut du lot suit celui de sa facture : facturée → lot facturé, payée → payé, non payée → non payé, confirmée → confirmé, commissionnée → commissionné, remboursée → remboursé, exécutée → exécuté, soldée → soldé. Annuler une facture remet les lots liés « fermés » et efface l'enchère gagnante.

Relances de paiement (automatique)

Un traitement quotidien envoie aux acheteurs des relances de paiement échelonnées pour les ventes facturées non payées, selon le calendrier de relances du shop (chaque étape n'est envoyée qu'une fois).

Contrat

Actions de contrat observées

Un contrat actif (non modèle) peut aussi déclencher des actions de rattrapage technique réservées aux administrateurs (userStore.isAdmin) : relancer la configuration de paiement du commissaire-priseur, resoumettre le bénéficiaire commissaire-priseur, ou relancer l'onboarding acheteur. Ces actions exigent en plus que le contrat ait un shop et, selon le cas, une organisation associée ou un type de client acheteur.

Organisation

Effets des transitions

• Valider (TO_VALIDATE → VALIDATED) : le workflow ne vérifie aucune condition métier supplémentaire (ni motif, ni IBAN, ni compte de reversement). En revanche, la validation fait passer toutes les personnes de l'organisation en « compte complet » et, si l'onboarding paiement est activé, crée le compte MangoPay de l'organisation (uniquement à la première bascule vers « validée »).
• Bloquer (TO_VALIDATE/VALIDATED → BLOCKED) : bloque en cascade toutes les personnes de l'organisation, enregistre l'auteur et le motif (motifs : non-paiement, non-retrait, à la demande du client, autre) et peut créer un commentaire. Le blocage figure aussi les coordonnées sur liste noire.
• Débloquer (BLOCKED → VALIDATED) : débloque l'organisation et toutes ses personnes.
• Fusionner (depuis en attente, validée ou bloquée) : réaffecte de l'organisation absorbée vers l'organisation conservée l'ensemble de l'historique et des rattachements (enchères, adresses, personnes, contrats, documents, demandes d'autorisation, validations de vente, watchlists, lots, séances, rendez-vous, recherches sauvegardées, factures et mouvements bancaires, commentaires). Les contrats automatiques et documents déjà présents en doublon sur l'organisation conservée sont archivés plutôt que transférés ; les invitations en attente sont transférées (pas celles déjà traitées). La fusion ferme le compte MangoPay de l'organisation absorbée et échoue si son portefeuille MangoPay n'est pas vide. En cas d'échec partiel, aucun archivage n'a lieu (rejeu possible). À la fin, l'organisation absorbée passe « archivée » avec un journal de fusion.

Indépendamment du statut global de l'organisation, une vérification KYB (justificatifs bancaires, informations légales, IBAN/BIC) est suivie séparément (statuts : manquant, à valider, validé, refusé) et n'entraîne, dans le back-end de workflow, que l'envoi de notifications par email aux personnes habilitées (droit de gestion des documents d'organisation) ; elle ne modifie pas automatiquement le statut principal de l'organisation. La décision KYB elle-même (validation / refus des justificatifs) est portée par l'API de conformité, pas par le workflow d'organisation.