diff --git a/AGENTS.md b/AGENTS.md index be55a9c..5cbe30d 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -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()`. diff --git a/modules/purchase_trade/docs/template-properties.md b/modules/purchase_trade/docs/template-properties.md index 2f51a3c..15168bd 100644 --- a/modules/purchase_trade/docs/template-properties.md +++ b/modules/purchase_trade/docs/template-properties.md @@ -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 diff --git a/modules/purchase_trade/docs/template-rules.md b/modules/purchase_trade/docs/template-rules.md index 0683068..3ddffa6 100644 --- a/modules/purchase_trade/docs/template-rules.md +++ b/modules/purchase_trade/docs/template-rules.md @@ -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.