Passer au contenu principal
Les deux actions de construction de plan créent (ou réutilisent) un plan, puis le remplissent. Les deux autres actions — webhook et e-mail — se trouvent sur la page Intégrations.

​
CREATE_OR_GET_PLAN

Crée un plan, ou en réutilise un correspondant, pour l’exécution. Champs communs : name et description (les deux interpolés). Le reste dépend de planType. 
{
  "actionType": "CREATE_OR_GET_PLAN",
  "planType": "RESTOCK",
  "brandSource": { "kind": "static", "brandId": "<uuid>" },
  "collectionSource": { "kind": "static", "collectionId": "<uuid>" },
  "deadline": { "kind": "relative", "offsetDays": 30 }
}
brandSource et collectionSource sont chacun { kind: "static", … } ou { kind: "fromTrigger" } (résoudre à partir de l’entité déclencheur). deadline est un décalage de date.
{
  "planType": "REBALANCE",
  "outgoingShopId": "<uuid>",
  "ingoingShopId": "<uuid>",
  "collectionSource": { "kind": "fromTrigger" },
  "deadline": { "kind": "relative", "offsetDays": 14 }
}
outgoingShopId / ingoingShopId (source / destination) sont requis.
{
  "planType": "MARKDOWN",
  "season": "SS26",
  "startDate": { "kind": "relative", "offsetDays": 0 },
  "endDate": { "kind": "relative", "offsetDays": 30 },
  "collectionSource": { "kind": "fromTrigger" }
}
season, startDate, endDate sont optionnels.
{ "planType": "SUPPLIER_RETURN", "supplierId": "<uuid>", "sourceShopId": "<uuid>", "deadline": { "kind": "relative", "offsetDays": 21 } }
supplierId est le discriminateur requis pour chercher-ou-créer ; sourceShopId est optionnel.
{ "planType": "SUPPLIER_EXCHANGE", "supplierId": "<uuid>", "sourceShopId": "<uuid>", "destinationShopId": "<uuid>", "deadline": { "kind": "relative", "offsetDays": 21 } }
supplierId requis ; sourceShopId (côté RETOUR) et destinationShopId (côté RECEVOIR) optionnels.
Sortie : planId, planType, planName, isNew — disponibles en aval sous {{steps.<nodeId>.output.planId}} etc.

​
ADD_ITEMS_TO_PLAN

Ajoute des articles au plan créé par un nœud CREATE_OR_GET_PLAN. Champs communs :
ChampSignification
sourcePlanNodeIdL’id du nœud créer-plan que celui-ci remplit.
planTypeDoit correspondre au plan source.
entityFiltersOptionnel { includeTags, excludeTags } pour restreindre quelles entités deviennent des articles.
maxItemsCap facultatif d’articlesquis nombre d’articles ajoutés.

​
Périmètres

  • Périmètre magasin (shopScope): { kind: "all" }, { kind: "specific", shopIds: [...] }, ou { kind: "fromTrigger" }. (Non utilisé pour rééquilibrage — les magasins viennent de l’en-tête du plan.)
  • Périmètre taille (sizeScope): { kind: "all" } ou { kind: "belowStockThreshold", threshold: <n> }.

​
Stratégies

{ "kind": "fixed", "quantity": 10 }
{ "kind": "fillToTarget", "target": 50 }
{ "kind": "scoreDriven" }
  • fixed — ajouter une quantité littérale par article.
  • fillToTarget — compléter chaque article jusqu’à target (seul le delta est ajouté).
  • scoreDriven — le résolveur de la plateforme données lit le vecteur de décision pour définir la quantité (aucun paramètre côté app).
{ "kind": "fixed" }
{ "kind": "scoreDriven" }
scoreDriven achemine vers le résolveur de correspondance de rééquilibrage (scores de surplus/déficit/urgence de transfert → appariement bipartite des magasins source aux magasins destination).
{ "kind": "fixed", "percent": 30 }
{ "kind": "scoreDriven" }
{ "kind": "recommended", "fallbackPercent": 15, "maxDiscountPct": 70, "marginFloorPct": 0 }
  • fixed — appliquer un percent littéral (0–100).
  • scoreDriven — le résolveur de remise recommandée de la couche décision.
  • recommended — remise de couche décision avec trois boutons limités ; valeurs par défaut affichées (fallbackPercent 15, maxDiscountPct 70, marginFloorPct 0).

​
Champs par type de plan

Type de planConfig d’article
RESTOCKquantityStrategy, shopScope, sizeScope
REBALANCEquantityStrategy, sizeScope, matchingStrategy (pas de périmètre magasin)
MARKDOWNdiscountStrategy, shopScope, sizeScope
SUPPLIER_RETURNquantityStrategy, reasonCode (appliqué à chaque article)
SUPPLIER_EXCHANGEside (RETURN/RECEIVE), quantityStrategy
Sortie : addedCount, skippedCount — disponibles sous {{steps.<nodeId>.output.addedCount}}.
Les articles ajoutés par un workflow portent leur attribution au vecteur de décision dans le journal d’activité du plan, et les mêmes règles métier s’appliquent que pour les modifications manuelles.