Prioriser l'allocation et l'exécution des commandes en attente (Backorders)

MasonHub alloue généralement l’inventaire aux commandes et les expédie selon la méthode du premier entré, premier sorti (FIFO), à moins que votre compte ne soit configuré pour suivre la date d’expiration — auquel cas nous utilisons la méthode du premier expiré, premier sorti (FEFO). Cependant, vous pouvez ajuster manuellement la priorité selon laquelle les commandes en attente (backorders) sont allouées et exécutées.

NOTE IMPORTANTE : Cela s’applique uniquement aux commandes en attente. Vous ne pouvez pas ajuster la priorité des commandes qui ont déjà été allouées ou qui sont actuellement en cours de traitement.

La logique d’allocation des stocks de MasonHub prend en compte deux facteurs clés : (1) la priorité de la commande, et (2) la date de soumission (submitted at). 

​

Priorité de la commande

Par défaut, toutes les commandes se voient attribuer une priorité de 100. Pour reprioriser l’exécution d’une commande en attente, vous pouvez ajuster sa Priorité entre 1 et 10 000 :

• Priorité la plus élevée : 1
• Priorité par défaut : 100
• Priorité la plus basse : 10 000

Si vous définissez la priorité d’une commande lors de sa création manuelle dans l’OMS de MasonHub, la priorité sera ignorée s’il y a du stock disponible. S’il y a suffisamment de stock pour exécuter la commande, elle sera allouée immédiatement et expédiée selon la méthode FIFO.

​

Date de soumission (Submitted At)

Plusieurs commandes peuvent partager la même priorité (c’est le cas de la plupart d’entre elles, car la valeur par défaut est 100). Dans ce cas, la date submitted_at détermine quelle commande est honorée en premier : plus la date est ancienne, plus la priorité est élevée.

BONNE PRATIQUE : Pour vous assurer que la bonne commande est allouée et expédiée en premier, confirmez qu’aucune autre commande en attente ne partage la même priorité que celle que vous ajustez.

INFORMATIONS COMPLÉMENTAIRES : Dans certains cas, par exemple lorsque des commandes ont été bloquées pour suspicion de fraude ou créées via une application tierce, la date submitted_at peut différer de la date created_at. · - submitted_at est la date à laquelle la commande a été créée dans votre système de commerce. · - created_at est la date à laquelle la commande a été créée dans l’OMS de MasonHub. · La logique d’allocation des stocks de MasonHub utilise la date submitted_at pour s’assurer que nous appliquons la priorité FIFO la plus précise.

​

Autres considérations

Logique d’allocation complète pour les commandes en attente - (Note importante)

Lorsque du stock devient disponible, la logique d’allocation des commandes en attente de MasonHub va d’abord tenter d’allouer entièrement le stock à toute commande en attente qui peut être complètement exécutée.

Ce n’est qu’après avoir identifié toutes les commandes pouvant être entièrement allouées que le système applique les règles standard de priorité des commandes en attente (valeur de priorité → date submitted_at).

Cela garantit une utilisation efficace des stocks et évite les allocations partielles lorsqu’une exécution complète est possible pour une autre commande.

Allocation des commandes en attente multi-sites (Logique d’emplacement virtuel)

Lorsque votre compte utilise plusieurs centres de distribution, MasonHub gère les commandes en attente via un emplacement d’inventaire virtuel. Cela signifie que tous les articles en attente sont regroupés logiquement, quel que soit le site physique qui les expédiera finalement.

Cependant, lorsque le stock devient disponible, le système respecte toujours les règles d’acheminement partielles :

• Les commandes avec un site suggéré de Wilkes ne s’alloueront que partiellement à partir du stock de Wilkes.
• Les commandes avec un site suggéré de Fontana ne s’alloueront que partiellement à partir du stock de Fontana.

Cela permet à nos systèmes d’attendre le stock au cas où une partie arriverait sur le site suggéré.

Article sur le routage multi-sites ici