Fiches des engagements et accords
/operations/commitments et /operations/agreements couvrent deux niveaux. L’engagement est un passeport dérivé en lecture seule de ce qui doit être livré; l’accord gère conditions, parties, dates et transitions.
Registre des accords
Sur /operations/agreements, un membre du personnel ayant accès à la section voit le registre partagé; le client est un filtre supplémentaire, pas la seule limite. La barre d’état filtre draft, review, awaiting_signature, active, suspended, expiring, expired, terminated et superseded. Le compteur couvre tout le résultat disponible pour le filtre choisi, pas seulement les lignes déjà chargées. Tableau/Cartes change la vue des mêmes résultats et une ligne ouvre le passeport de l’accord.
Chaque ligne affiche la direction (Client, Fournisseur ou Interne) à côté du titre. La durée combine dates de début et de fin; sans date de fin, elle est indiquée sans fin. Parcourez la liste jusqu’au résultat recherché: une page partielle ne constitue pas tout le registre.
Passeport de l’engagement
Le passeport affiche aussi Créé et Mis à jour comme métadonnées d’audit ; l’engagement dérivé reste en lecture seule.
Une fiche d’engagement dans /operations/commitments, ou un passeport précis via /operations/commitments/:commitmentId, affiche le type, la quantité/unité promise, la date de prise d’effet lorsqu’elle est fournie, l’état d’exécution, l’étape, la base des conditions et la commande source. L’échéance actuelle de livraison peut manquer dans le passeport : n’inférez pas un retard à partir de champs absents ni du groupe Ouverts ; vérifiez la date de livraison et le délai dans la commande et le contrat source.
L’engagement vient de la commande et ne se modifie pas ici. Changez la quantité, l’échéance ou les conditions dans la commande source après vérification des droits et de l’historique. Erreur, état vide et enrichissement absent sont distincts.
Passeport de l’accord
Une fiche d’accord dans /operations/agreements affiche direction, état, dates, parties légales, version courante, nombre de lignes et exigence d’un document signé. Les noms viennent du contexte, jamais d’identifiants techniques.
Le bloc de prépaiement affiche un compte rattaché à l’accord, à une révision précise des conditions et à la devise de règlement ; ce n’est pas un portefeuille client. Aucun montant n’est saisi : sélectionnez un paiement confirmé, non affecté et dans la même devise. L’ouverture et l’alimentation exigent les droits requis et peuvent relever de la séparation des fonctions : la personne qui a enregistré le paiement ne le confirme pas à nouveau. Chargement, liste vide, erreur de lecture, conflit de version et opération en attente sont distincts ; vide ou indisponible ne signifie pas solde nul. Le bloc ne dépense pas, ne crée ou ne libère pas de réserve sur une ligne de facture et n’effectue pas de remboursement ; il ouvre le compte, permet de choisir un paiement et affiche son état. Si le paiement est lié mais pas encore crédité, la fiche conserve ce même paiement sélectionné et vous demande de choisir à nouveau Alimenter ; n’en sélectionnez pas un autre. pending_funding ou une écriture en attente signifie qu’il faut patienter puis relire la fiche, et non conclure que le solde est nul.
Le nombre principal de la carte est Disponible : Disponible = versé − retenu − consommé ; un montant non nul de Remboursé est affiché séparément. La carte affiche aussi la révision actuelle des conditions et la devise de règlement : une nouvelle révision des conditions ouvre un circuit de réserve distinct ; le solde de la révision remplacée n’est pas transféré. « Consommé » indique le lien avec une ligne de facture émise, pas une fonction de dépense dans ce bloc : aucune action n’y permet de dépenser, créer/libérer une réserve ou rembourser.
Dans l’état awaiting_signature, le contrat attend la confirmation de la signature hors du portail : le portail enregistre cette décision sans la prendre lui-même. Il n’y a donc pas de bouton Activer distinct ici ; vérifiez le processus de signature externe et la copie du document lié. L’étape pratique suivante consiste à obtenir l’exemplaire signé puis à choisir Ajouter dans la section des documents ci-dessous ; il n’apparaîtra pas automatiquement.
Sous les conditions se trouve une section distincte de documents liés avec Ajouter et Tout afficher. Elle peut être vide tant que la copie signée est attendue ; ce n’est pas une erreur d’accès. Créé et Mis à jour fournissent un contexte d’audit supplémentaire.
Tout afficher ouvre le registre des documents dans le contexte de cet accord : /documents?sourceType=agreement&sourceId=<agreementId>. Seuls les documents de cet accord doivent apparaître, avec un titre, une puce de contexte et un état vide localisés et compréhensibles ; un identifiant technique ou un fichier d’un autre accord ne valide pas le filtre.
Une transition exige l’état approprié et la version courante de la fiche pour ne pas écraser une modification concurrente. Saisissez une raison obligatoire: elle est conservée dans l’historique de l’accord.
Vous pouvez créer un accord sur /operations/agreements/new si vous avez le droit d’écrire. Le formulaire crée un brouillon ; pour un accord en draft ou review, ouvrez la modification des conditions sur /operations/agreements/:agreementId/terms, qui remplace les conditions actuelles. Si la fiche a changé ou si un conflit apparaît, relisez-la et réessayez. L’interface ne propose pas de retour séparé vers une ancienne version ; le passage de review à draft fait partie de la modification des conditions.
Après avoir choisi le client et la première offre/prix, le portail propose un nom du type « offre — client ». Tant que vous ne le modifiez pas, un changement de sélection actualise la proposition ; après une modification manuelle, votre texte est conservé. Le nom d’un accord est obligatoire : utilisez des informations claires plutôt que des données inventées ; la modification d’un accord existant ne remplace pas son nom.
Dans le sélecteur de prépaiement actuel, la date du paiement peut apparaître en ISO brut YYYY-MM-DD au lieu du format de la locale active. Il s’agit d’un blocage source : ne le prenez pas pour une preuve de date localisée et ne promouvez pas de capture avec montant sans currency.expected/currency.observed et vérification de la date sur un build correspondant.
Transitions
draft→review: Envoyer en revue;review→awaiting_signature: Envoyer à la signature;activeouexpiring→suspended: Suspendre;suspended→active: Reprendre;- tout état modifiable →
terminated: Terminer, irréversible.
L’activation n’est pas un bouton ici: active vient après la signature juridique ou d’un système documentaire externe. L’expiration et le remplacement sont traités par le système.
Après changement de version ou refus de transition, rechargez la fiche et utilisez les données actuelles; ne répétez pas une ancienne action.
Sécurité
Vérifiez la version, le document signé, l’entité légale, le client, les dates et l’accès. Utilisez des contrats et montants fictifs dans les exemples; n’exposez ni données bancaires, ni clients, ni identifiants techniques.
Pages associées