Add session notes

This commit is contained in:
2026-04-06 18:52:15 +02:00
parent 7722292482
commit 1f350e6207
3 changed files with 70 additions and 0 deletions

View File

@@ -46,8 +46,10 @@ Guide rapide pour les agents qui codent dans ce repository.
- Preferer des proprietes Python simples exposees par le modele plutot que des expressions Genshi complexes dans le template.
- Dans les placeholders XML, utiliser `"` et `'` plutot que des antislashs type `\'`.
- Si un document facture depend fortement d'une vente/achat, ajouter au besoin un petit pont Python pour exposer des `report_*` stables au template.
- Pour les templates `stock.shipment.in`, preferer aussi des proprietes `report_*` sur le shipment plutot que des contextes ad hoc (`si_*`) quand le document devient metier ou client-specifique.
- Si plusieurs actions de report pointent vers `report_name = 'account.invoice'`, verifier aussi le cache `invoice_report_cache` dans `modules/account_invoice/invoice.py`: un mauvais cache peut faire croire que plusieurs actions utilisent le meme `.fodt`.
- Avant de conclure qu'un template ou une action est faux, verifier si le report alternatif doit bypasser le cache standard.
- 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.
- 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()`.

View File

@@ -64,6 +64,10 @@ Source code: `modules/purchase_trade/invoice.py`
- Usage: description produit principale
- Source de verite: premiere ligne metier liee a la facture
- `report_product_name`
- Usage: nom produit principal
- Source de verite: premiere ligne metier liee a la facture
- `report_description_upper`
- Usage: description de ligne en majuscules
- Source de verite: premiere `account.invoice.line`
@@ -265,6 +269,8 @@ Source code: `modules/purchase_trade/sale.py`
- `report_payment_date`
- `report_shipment`
- `report_shipment_periods`
- `report_product_name`
- `report_product_description`
Usage typique:
- base de travail pour les templates de type `sale_ict.fodt`
@@ -312,6 +318,7 @@ Source code: `modules/purchase_trade/stock.py`
Usage typique:
- templates shipment relies a l'assurance
- templates qui lisent le fee `Insurance` d'un `stock.shipment.in`
- base de travail pour un certificat d'assurance lie a un shipment
## 10) Recommandations

View File

@@ -102,6 +102,67 @@ Derniere mise a jour: `2026-04-02`
stocke le nom du template par action (`Invoice`, `CN/DN`, `Prepayment`)
plutot qu'une modification manuelle de `ir_action_report.report`
### TR-012 - Centraliser les templates client dans `Document Templates`
- Pour les templates client-specifiques, ne pas modifier `ir_action_report.report`
en base a la main selon l'environnement ou le client.
- Preferer la configuration singleton `purchase_trade.configuration`,
exposee dans `Documents > Configuration > Document Templates`.
- Sections actuellement attendues:
- `Sale`
- `Invoice`
- `Purchase`
- `Shipment`
- Regle:
- si le champ de template correspondant est vide, le report doit echouer
explicitement avec `No template found`
- ne pas masquer dynamiquement l'action d'impression si ce n'est pas
necessaire
### TR-013 - `sale_melya.fodt` et `invoice_melya.fodt` doivent afficher nom + description produit
- Dans les templates client Melya, le bloc produit doit prevoir:
- une ligne pour le nom produit
- une ligne pour la description produit
- Ne pas dereferencer directement `line.product.name` / `line.product.description`
dans les `.fodt`.
- Preferer:
- `sale.report_product_name`
- `sale.report_product_description`
- `invoice.report_product_name`
- `invoice.report_product_description`
### TR-014 - `invoice_melya.fodt` doit afficher `Invoice` et `Reference` sur les bons champs
- Pour `modules/account_invoice/invoice_melya.fodt`:
- `Invoice` doit afficher `invoice.number`
- `Reference` doit afficher `invoice.report_contract_number`
- Ne pas reutiliser `invoice.reference` pour ce label dans ce template client
sans demande explicite
### TR-015 - Le template `stock/insurance.fodt` doit lire sur `stock.shipment.in`
- Le template `modules/stock/insurance.fodt` est pilote par le report
`stock.shipment.in.insurance`.
- Toutes les croix rouges / placeholders metier doivent etre remplacees par
des proprietes `report_*` exposees sur `stock.shipment.in`.
- Pour ce template, ne pas compter sur une variable Genshi locale `shipment`
dans tout le document; preferer `records[0]....` dans le `.fodt`.
- Source de verite du montant assure:
- le `fee.fee` du shipment dont le produit contient `Insurance`
- montant via `fee.get_amount()`
### TR-016 - Hypotheses actuelles pour le certificat d'assurance shipment
- Tant qu'une source metier plus precise n'est pas fournie:
- numero du certificat: `shipment.bl_number`, sinon `shipment.number`
- `insured for account of`: client de la premiere ligne metier retrouvee via
lot physique, sinon `shipment.supplier`
- `surveyor`: `shipment.controller`, sinon fournisseur du fee `Insurance`
- lieu/date d'emission: ville de la societe + date du jour
- Si une source differente est decidee plus tard, corriger la propriete Python
plutot que complexifier `insurance.fodt`
### TR-007 - Pour une facture trade, privilegier le lot physique comme chemin de navigation
- Pour remonter d'une facture vers des donnees logistiques ou metier, ne pas dupliquer de chemins differents selon achat/vente.