Add note for bot

This commit is contained in:
2026-04-08 17:15:11 +02:00
parent c90b14fcc1
commit 5ae8af84fb
2 changed files with 65 additions and 0 deletions

View File

@@ -52,6 +52,20 @@ Guide rapide pour les agents qui codent dans ce repository.
- Pour les templates shipment, ne pas supposer qu'une variable locale comme `shipment` sera definie partout dans Genshi, surtout dans les headers/footers; preferer `records[0]....` ou des placeholders alignes sur le scope reel du report. - Pour les templates shipment, ne pas supposer qu'une variable locale comme `shipment` sera definie partout dans Genshi, surtout dans les headers/footers; preferer `records[0]....` ou des placeholders alignes sur le scope reel du report.
- Dans `purchase_trade`, pour remonter d'une facture vers shipment, pro forma, freight ou autres donnees logistiques, privilegier le lot physique comme pont entre `purchase.line`, `sale.line` et shipment. - Dans `purchase_trade`, pour remonter d'une facture vers shipment, pro forma, freight ou autres donnees logistiques, privilegier le lot physique comme pont entre `purchase.line`, `sale.line` et shipment.
- Pour `FREIGHT VALUE`, ne pas lire un champ direct sur la facture: retrouver le fee de shipment (`shipment_in`) dont le produit est `Maritime freight`, puis utiliser `fee.get_amount()`. - Pour `FREIGHT VALUE`, ne pas lire un champ direct sur la facture: retrouver le fee de shipment (`shipment_in`) dont le produit est `Maritime freight`, puis utiliser `fee.get_amount()`.
- Rappels session templates (2026-04-08):
- `insurance.fodt`: le texte "insured for account of" doit afficher la compagnie courante (shipment.company.party), pas le client.
- `insurance.fodt`: exposer des proprietes Python `report_*` sur `stock.shipment.in` pour les montants (incoming moves) et les zones client-specifiques.
- `insurance.fodt`: "Amount insured" suit la regle metier 110% du montant incoming (base calculee via lot -> purchase.line.unit_price * quantite courante convertie).
- `insurance.fodt`: zone "Contact the following surveyor" alimentee par une propriete dediee, avec champ `surveyor` (party.party) cote shipment.
- `packing_list.fodt`: date en haut a droite = date du jour; unites Net/Gross = unite de `purchase.line`.
- `bill.fodt` (sale): la 2eme date doit etre une vraie maturity date (depuis `invoice.lines_to_pay.maturity_date`), pas `payment_term.rec_name`.
- `bill.fodt` (sale): le montant en lettres doit provenir du montant du bill (facture/total), pas du `unit_price` de ligne.
- Quand un template affiche les placeholders en brut, verifier que les champs sont bien des placeholders Relatorio dans le XML (pas du texte litteral).
- Eviter les apostrophes echappees style `\'` dans placeholders; preferer `"` et `'`.
## 4.bis) Memo templates de session
- Voir aussi `notes/template_business_rules.md` pour le recap detaille (business rules + decisions templates de la session).
## 5) Workflow de modification (obligatoire) ## 5) Workflow de modification (obligatoire)

View File

@@ -0,0 +1,51 @@
# Template Business Rules - Session Memo
Date: 2026-04-08
Scope: templates Relatorio + ponts `report_*` Python.
## 1) Regles metier confirmees
- `insurance.fodt`:
- "This is to certify that we have insured for account of" doit afficher la compagnie courante (`shipment.company.party`), pas le client.
- "Amount insured" suit la regle 110% de la valeur incoming.
- Base incoming: montant des incoming moves lies au shipment, derive des lots et de la source achat (`purchase.line.unit_price * current_quantity_converted`).
- `sale bill`:
- La 2eme date attendue est une maturity date (echeance), pas le libelle de condition de paiement.
- Le montant en toutes lettres doit correspondre au montant du bill (montant facture/total), pas au prix unitaire d'une ligne.
## 2) Pratiques templates Relatorio
- Preferer des proprietes Python `report_*` stables sur le modele plutot que des expressions Genshi complexes.
- Pour `stock.shipment.in`, privilegier `records[0].report_*` dans le template.
- Si un placeholder s'affiche en brut dans le PDF:
- verifier que c'est un vrai `text:placeholder` ODF et pas du texte simple.
- verifier le scope de variable (`records[0]` vs variable locale non definie).
- Dans les placeholders XML:
- utiliser `"` et `'` dans les expressions XML.
- eviter les echappements de type `\'`.
## 3) Decisions de conception appliquees
- `insurance.fodt`:
- ajout d'un champ shipment `surveyor` (party.party) via onglet "Surveyor".
- ajout d'une propriete `report_insurance_contact_surveyor` pour la zone "Contact the following surveyor".
- `payment_order.fodt`:
- migration des tags `<...>` legacy vers la syntaxe template habituelle du projet.
- ajout de la section de config template, et exposition depuis `account.invoice` comme pour CN/DN/Invoice/Prepayment.
- `packing_list.fodt`:
- date en haut droite basee sur la date du jour.
- unites Net/Gross alignees sur l'unite de `purchase.line`.
- `bill.fodt`:
- suppression du report `sale_final.fodt` du menu sale.
- ajout de ponts Python cote sale pour:
- montant bill numerique,
- montant bill en lettres,
- maturity date issue de `invoice.lines_to_pay.maturity_date` (avec fallback metier).
## 4) Check-list rapide avant validation d'un template
- Les placeholders sont-ils tous resolus (aucun `<records[...]...>` brut)?
- Le scope est-il correct (`records[0]` / `sale` / `invoice`) partout, y compris header/footer?
- La source metier est-elle correcte (compagnie vs client, total vs unit_price, maturity date vs payment term)?
- Les formats sont-ils conformes (date, devise, montant en lettres)?
- Le template est-il bien expose dans la config + menu d'impression de la forme cible?