Écrans du back-office

Le back-office (/manage) expose sept surfaces autour du stock et du réappro fournisseur. Chacune lit les mêmes tables (Product.stockLedger, StockAction, SupplierOrder), mais elles n'écrivent pas toutes — et quand elles écrivent, chaque mouvement passe par les chemins d'écriture canoniques (recordPhysicalMovement, manageStock vérifié, StockAction émise dans la même transaction). Cette page dit quel écran ouvrir pour quel besoin, et ce que chaque bouton fait réellement en base.

Quel écran ouvrir ?

flowchart TD
  Q0{"Que voulez-vous faire ?"}
  Q0 --> A["Corriger un stock"]
  Q0 --> B["Comprendre un stock"]
  Q0 --> C["Piloter le réappro"]
  A --> A1{"Ampleur ?"}
  A1 -->|"Quelques produits"| S1["vendors/stocks<br/>édition inline"]
  A1 -->|"Comptage entrepôt"| S2["inventory/counts<br/>inventaire physique"]
  B --> B1{"Quel angle ?"}
  B1 -->|"Journal ligne à ligne"| S3["inventory/stock-actions"]
  B1 -->|"Chronologie + KPIs"| S4["inventory/stock-ledger"]
  C --> C1{"Quoi ?"}
  C1 -->|"Qu'est-ce qui va manquer ?"| S5["inventory/mon-stock"]
  C1 -->|"Relire les emails fournisseurs"| S6["vendors/orders/email-review"]
  C1 -->|"Stock gonflé suspect"| S7["vendors/orders/phantom-stock"]

Et si la question est « est-ce que tout va bien ? » : /manage/inventory/health (tableau de bord en lecture seule) et la puce cron-5 de l'écran stock-ledger.

Vue d'ensemble

Stocks fournisseurs — /manage/ecommerce/vendors/stocks

La grille de travail : tous les produits avec leur fournisseur par défaut, le stock courant, les quantités en commande et en brouillon. C'est l'écran de correction ponctuelle.

Lit : vendors.getVendorsStocks (filtre par fournisseur via autocomplete). La requête déclenche aussi la valorisation du stock (#2796) côté serveur — valeur totale en euros au prix de gros, avec le compteur missingPriceCount des produits en stock sans prix d'achat renseigné (donc non valorisés).

Écrit :

L'export (dialog dédié) produit un fichier CSV/XLSX de l'état courant ; l'import le réinjecte. Les snapshots (#2796) gardent un historique daté de la valorisation, avec un détail par fournisseur dérivé des items figés — utile pour la comptabilité de fin de mois.

État de stock — /manage/ecommerce/inventory/stock-ledger

L'écran le plus dense : la vérité du ledger rendue lisible. Quatre zones :

1. Cartes KPI — Stock physique (avec sous-titre précommande quand le ledger signé est négatif), Réservé, Disponible, Sorties en attente (commandes non livrées).
2. Tableau d'aperçu (stockActions.getProductStockOverview) — un produit par ligne, filtres URL persistants : catégorie, fournisseur, critiques seuls, santé, divergences seules (stock ≠ stockLedger), produits non suivis inclus/exclus, tri, fenêtre de dates (défaut aujourd'hui → +14 jours).
3. Chronologie produit (stockActions.getStockLedger) — le film ligne à ligne des entrées/sorties d'un produit sélectionné, avec les modales de détail commande client et bon fournisseur.
4. Puce santé cron-5 — sépare liveness et activité. Son titre est la liveness (« le cron a-t-il tourné ? »), lue sur le heartbeat que la tâche estampille dans bext-KV à la fin de chaque run (health:auto-validate:{tenantId}:{siteId}, TTL 7 jours) : ≤ 5 h vert, ≤ 12 h ambre, > 12 h rouge — au regard de la cadence attendue (12:01 canonique + balayage toutes les 2 h via /etc/cron.d). L'horodatage de la dernière auto-validation (côté réceptions fournisseurs ⇣ et livraisons clients ⇡) est rétrogradé en info secondaire, « dernière activité » : un jour calme ne produit légitimement aucune ligne, donc l'âge du dernier scellé seul ne signifie jamais que le cron est mort. Si bext est injoignable, la puce retombe sur le statut par âge d'activité et le signale dans le popover. Voir Filets de sécurité.

Écrit (trois modales en stock:write — sauf l'aperçu de réconciliation previewLedgerReconciliation, qui est en stock:read ; seul son apply applyLedgerReconciliation écrit) :

Mon stock — /manage/ecommerce/inventory/mon-stock

La vue marchand du quotidien : « Qu'est-ce qui va manquer, et qu'est-ce qui arrive ? ». Projection à 30 jours glissants de la même source que l'aperçu ledger (stockActions.getProductStockOverview), présentée en cartes produit avec :

• le panneau demande non couverte (commandes clients sans bon fournisseur en face) ;
• le groupage par fournisseur (?group=true, deep-linkable) ;
• la création de commande fournisseur ad-hoc depuis la carte (modales pilotées par l'URL : ?newOrder=1 pour un composeur vierge, ?orderVendor=<id> + ?orderSlot=yyyy-MM-dd pour cibler un fournisseur/créneau, #2832).

Écrit très peu : la suppression d'un brouillon fournisseur (vendors.deleteSupplierOrder) depuis le panneau de demande, et la création de commandes via la modale — qui passe par la même chaîne gardée que le réappro événementiel. Aucun mouvement de stock direct.

C'est l'écran à donner à un opérateur non technique : il lit la projection, il ne touche pas au ledger.

Inventaires physiques — /manage/ecommerce/inventory/counts

Le flux de comptage entrepôt en trois temps :

inventoryCount.cancel abandonne une session non finalisée sans trace au stock.

Actions de stock — /manage/ecommerce/inventory/stock-actions

Le journal. Chaque ligne est une StockAction : type (INCREMENT/DECREMENT/ADJUSTMENT), source (MANUAL, ORDER_UPDATE, SUPPLIER_DELIVERY, INVENTORY_ADJUSTMENT…), statut (PENDING/COMPLETED/CANCELLED), quantités avant/delta/après, auteur, raison. Lecture via stockActions.getAll (stock:read), filtres et détail par ligne.

Écrit — uniquement de la suppression, et c'est le point délicat :

• Suppression bidirectionnelle (stockActions.deleteWithOptionalStockEffect, stock:write) : le dialogue demande explicitement si Product.stock/stockLedger doivent être réajustés en retour (le mouvement est annulé physiquement) ou si on supprime seulement la ligne de journal (le stock reste tel quel). Il n'y a pas de confirmation générique — ce choix est la confirmation.
• Suppression en masse (stockActions.bulkDelete) : un seul aller-retour serveur qui traite les ids dans l'ordre, côté serveur — deux suppressions avec effet stock sur le même produit ne doivent jamais se courser.

Commandes fournisseurs — /manage/ecommerce/vendors/orders

Le hub du réappro. Onglets : commandes, historique, vue par site, par fournisseur, et calendrier (VendorOrderCalendarView, avec glisser-déposer des bons entre créneaux). Stats de tête via vendors.getSupplierOrdersStats.

File de relecture email — /manage/ecommerce/vendors/orders/email-review

La garantie « ce qui est relu est ce qui part » du pipeline stage → review → send. Liste vendors.listStagedSupplierOrders (filtres fournisseur, dates, aujourd'hui seulement, reportés, modifiés, groupage par fournisseur) ; chaque ligne montre les valeurs effectives (override fusionné) et une puce de dérive quand les items ont changé depuis le stage.

Stock fantôme — /manage/ecommerce/vendors/orders/phantom-stock

Chasse au stock gonflé (typiquement du stock fictif hérité de la boutique en ligne — voir Synchronisation PrestaShop). Lecture vendors.getStockCoveragePage (products:read) avec recherche côté serveur (debounce 350 ms) et filtre « suspects seulement » ; la colonne trusted montre ce que le moteur de réappro utilisera réellement — plafonné par les 8 semaines de couverture quand le stock brut paraît fantôme.

Deux actions de confiance (stock:write) :

• vendors.setProductStock — corriger le chiffre (mouvement physique, SA émise) ;
• vendors.setProductStockTrusted — basculer le drapeau de confiance sans toucher au chiffre (le moteur ignore ou réutilise le stock brut).

À traiter avant d'activer une commande davantage pilotée par le stock : chaque suspect non résolu se traduit en sous-commande.

Santé de l'inventaire — /manage/inventory/health

Tableau de bord en lecture seule (inventory.getDashboardData) : alertes de stock, indicateurs agrégés. Aucune action d'écriture — c'est le complément visuel des filets de sécurité (audit stock-ledger-audit, sonde quotidienne 06:30, puce cron-5 de l'écran ledger).

Permissions

Toutes les procédures sont protégées par RBAC (permissionProtectedProcedure) :

Un profil « opérateur du quotidien » en lecture vit très bien avec stock:read + vendors:read + l'accès à mon-stock et à la file email ; les actions d'écriture de mon-stock (supprimer un brouillon fournisseur, créer une commande ad hoc) exigent toutefois vendors:write. Réservez stock:write aux personnes qui comprennent la différence entre supprimer une ligne de journal avec et sans effet stock.

Voir aussi

• Vue d'ensemble — le modèle complet en une page
• Le ledger de stock — autorité signée, miroir bridé, invariants
• Chemins d'écriture — le contrat que chaque bouton d'écriture respecte
• Commandes fournisseurs — réappro événementiel, créneaux, verrou
• La journée type — crons 06:00 / 06:30 / 07:15 / 12:01
• Filets de sécurité — audit, sonde, tests épinglés
• Configuration — les gates (STOCK_LEDGER_ALLOW_BACKORDER, STOCK_TRUST_MAX_COVER_WEEKS…)