Add WR draft management

modules/purchase_trade/docs/business-rules.md

@@ -306,10 +306,35 @@ Owner technique: `a completer`
 - Resultat attendu:
   - pour une ligne `party.execution`, `achieved_percent` =
     `shipments de la zone avec ce controller / shipments controles de la zone`
+  - le denominateur ne compte que les `stock.shipment.in` qui ont deja un
+    `controller`; les shipments encore non affectes ne biaisent donc pas la
+    statistique affichee
   - lors d'un choix automatique de controller, la priorite va a la regle dont
     l'ecart `targeted - achieved` est le plus eleve
   - un controller a `80%` cible et `40%` reel doit donc passer avant un
     controller a `50%` cible et `45%` reel sur la meme zone
+  - l'appartenance a la zone se lit depuis `shipment.to_location.country`, et
+    une region parente couvre aussi ses sous-regions
+- Priorite:
+  - `importante`
+
+### BR-PT-015 - Les weight reports distants par lot partent du weight report global attache au shipment
+
+- Intent: separer la creation du `weight.report` global et l'export detaille
+  par lot vers le systeme distant.
+- Description:
+  - l'automation cree le `weight.report` global et l'attache au
+    `stock.shipment.in`
+  - l'export FastAPI par lot ne part plus directement de l'automation
+  - l'utilisateur ouvre le `weight.report` voulu depuis le shipment et lance
+    l'action d'export depuis ce rapport
+- Resultat attendu:
+  - le rapport choisi sert de base unique pour calculer les payloads par lot
+  - seuls les lots physiques des `incoming_moves` du shipment sont exportes
+  - l'action exige au minimum un `controller` et un `returned_id` sur le
+    shipment
+  - les cles renvoyees par le systeme distant et la date d'envoi sont
+    conservees sur le `weight.report` local
 - Priorite:
   - `importante`
 - Resultat attendu: