02.04.26

modules/purchase_trade/AGENTS.md

@@ -59,6 +59,11 @@ de negoce physique:
 - Pour remonter d'une facture vers shipment / BL / controller / fret:
   - privilegier le lot physique
   - ne pas multiplier des chemins d'acces concurrents
+- Pour les champs de colis (`NB BALES`) dans les templates facture:
+  - la source de verite est `line.lot.lot_qt`
+  - sur une facture, sommer les `lot_qt` des lignes de facture
+  - tenir compte du signe de la ligne de facture pour les notes finales
+  - ne pas proratiser depuis le poids (`net` / `gross`)
 - Le `FREIGHT VALUE` d'un template facture vient du `fee.fee` du shipment
   dont le produit est `Maritime freight`.
 - Le wizard `Create contracts` en mode `matched` peut maintenant partir de
@@ -86,6 +91,8 @@ de negoce physique:
   - le `unit_price` doit rester un prix de base, hors `premium`
   - le `premium` doit impacter le prix total economique et donc le `amount`,
     aussi bien en `priced` qu'en `basis`
+  - pour les documents commerciaux / facture, une ligne `basis` affiche le
+    `premium` comme prix visible, pas le prix economique total
   - si `linked currency` est active, le `premium` est saisi dans la devise /
     unite liee (ex: `USC/LB`) puis converti vers le repere de la ligne pour le
     calcul du `amount`
@@ -118,6 +125,9 @@ de negoce physique:
    `docs/template-rules.md`.
 6. Pour les vues XML Tryton de ce module, utiliser `editable="1"` sur les
    `<tree>` editables; ne pas utiliser `editable="bottom"`.
+7. Si une regle de texte par defaut durable est demandee sur achat/vente,
+   preferer un singleton de configuration expose dans un menu fonctionnel
+   existant plutot qu'un menu technique `purchase_trade`.
 
 ## 6) Pieges connus
 
@@ -128,6 +138,9 @@ de negoce physique:
 - Pour les donnees achat/vente partagees, ne pas supposer qu'une facture de
   vente doit lire directement sur la `sale.line`: souvent, la verite metier
   passe par le lot physique et/ou la `account.invoice.line`.
+- Les templates `invoice_ict*` peuvent partager les memes proprietes Python;
+  si une regle doit valoir pour provisional et final, la mettre dans
+  `modules/purchase_trade/invoice.py` plutot que dupliquer dans les `.fodt`.
 - Dans les ecrans PnL, le label `Sale price` correspond au type stocke
   `sale priced`; idem pour `Pur. price` / `pur. priced`.
 - Une ligne `basis` sans resume de pricing peut sinon disparaitre de la

modules/purchase_trade/configuration.xml

@@ -20,7 +20,7 @@
             name="Configuration"
             parent="price.menu_price"
             action="act_purchase_trade_configuration_form"
-            sequence="1600"
+            sequence="10"
             id="menu_purchase_trade_configuration"
             icon="tryton-settings"/>
     </data>

modules/purchase_trade/docs/business-rules.md

@@ -1,8 +1,8 @@
 # Business Rules - Purchase Trade
 
 Statut: `draft`
-Version: `v0.3`
-Derniere mise a jour: `2026-04-01`
+Version: `v0.4`
+Derniere mise a jour: `2026-04-02`
 Owner metier: `a completer`
 Owner technique: `a completer`
 
@@ -258,6 +258,39 @@ Owner technique: `a completer`
     `virtual`.
   - Si aucun `lot.qt` ne relie ce lot a une `purchase.line`, il faut tout de
     meme generer la valuation cote sale.
+
+### BR-PT-012 - Le wizard Create contracts peut creer un seul achat matche a plusieurs open sales
+
+- Intent: permettre la creation d'un contrat achat unique a partir de plusieurs
+  `lot.qt` de vente selectionnes.
+- Description:
+  - En mode `matched`, le wizard `Create contracts` peut recevoir plusieurs
+    `lot.qt` selectionnes.
+  - Il doit creer un seul contrat, avec une ligne par lot source selectionne.
+  - Chaque ligne doit conserver son lot d'origine pour le matching.
+- Resultat attendu:
+  - le wizard agrege les quantites de la selection
+  - il refuse une quantite saisie differente du total selectionne
+  - il conserve `created_by_code = True` sur les lignes creees pour ne pas
+    declencher les creations automatiques parasites lors des validations
+- Priorite:
+  - `importante`
+
+### BR-PT-013 - Le texte par defaut de pricing_rule est configure globalement
+
+- Intent: centraliser un texte metier recurrent reutilise a la creation des
+  lignes achat et vente.
+- Description:
+  - Le module expose un singleton `purchase_trade.configuration` avec un champ
+    texte `pricing_rule`.
+  - Toute nouvelle `purchase.line` et `sale.line` doit prendre ce texte comme
+    valeur par defaut de `pricing_rule`.
+- Resultat attendu:
+  - la configuration est accessible depuis le menu `Prices`
+  - la valeur sert de defaut a la creation des lignes
+  - les lignes existantes ne sont pas modifiees retroactivement
+- Priorite:
+  - `importante`
 - Resultat attendu:
   - apres creation du lot virtuel, si aucun matching purchase n'existe:
     - appeler `Valuation.generate_from_sale_line(line)`

modules/purchase_trade/docs/template-rules.md

@@ -1,8 +1,8 @@
 # Template Rules - Purchase Trade
 
 Statut: `draft`
-Version: `v0.2`
-Derniere mise a jour: `2026-03-27`
+Version: `v0.3`
+Derniere mise a jour: `2026-04-02`
 
 ## 1) Scope
 
@@ -149,6 +149,21 @@ Derniere mise a jour: `2026-03-27`
 - Le texte de curve / pricing (`ON ICE ...`) reste affiche a cote, mais la
   valeur numerique et sa version en lettres doivent representer le premium.
 
+### TR-011 - Pour `NB BALES` sur une facture, sommer les `lot_qt` des lignes facture
+
+- Pour `invoice_ict.fodt` et `invoice_ict_final.fodt`, la source de verite du
+  nombre de bales n'est pas le poids (`report_net`, `report_gross`) mais
+  `line.lot.lot_qt`.
+- La regle attendue est:
+  - lire les lignes de facture
+  - recuperer leur `lot`
+  - sommer `lot.lot_qt`
+  - sur une note finale, tenir compte du signe de la ligne de facture pour que
+    les lignes positives et negatives se compensent
+- Ne pas recalculer le nombre de bales a partir du poids:
+  - les poids peuvent varier (humidite, poids net/gross)
+  - le nombre de bales peut rester stable
+
 ## 4) Workflow recommande pour corriger un template en erreur
 
 1. Identifier le placeholder exact qui provoque l'erreur Relatorio.