tradon/notes/template_business_rules.md

# 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?

## 5) Session 2026-04-09 - Rappels metier purchase_trade / account_invoice

- Factures trade:
  - `NET` et `GROSS` viennent de `lot.qt.hist` du lot retenu, pas de `invoice.line.quantity`.
  - priorite lots: `physic` d'abord, sinon lot `virtual` unique.
  - l'unite affichee vient de `lot.lot_unit_line`.
  - les infos shipment doivent dependre des lots reels des lignes facture.
  - le label `S/I` doit afficher `shipment.reference`.
  - `invoice_ict_final.fodt`: si `NB BALES = 0`, afficher `Unchanged`.
  - les quantites de `invoice_ict` et `invoice_ict_final` sont uniformisees a `2` decimales.
  - la conversion vers `LBS` doit passer par `product.uom.compute_qty`, pas un facteur fixe.
  - si plusieurs lignes reutilisent le meme lot, les lignes detaillees utilisent la quantite facturee convertie, mais le `GROSS` global doit continuer a refleter le vrai delta historique du lot.
- CN / DN:
  - cote `sale` / `out`: montant negatif => `Credit Note`, montant positif => `Debit Note`.
  - cote `purchase` / `in`: logique inverse conservee.
- Report sale:
  - meme priorite lots que facture.
  - les quantites en lettres suivent l'unite reelle (`MT`, `KILOGRAM`, `LBS`).
  - le total convertit les lignes vers une unite commune.
  - l'unite commune est celle du lot virtuel seulement s'il y a un seul lot virtuel sur tout le report.
- Lots:
  - `lot.report.r_del_period` affiche `sale.line.del_period` pour `lot_s` sans `lot_p`, sinon `purchase.line.del_period`.
  - dans `Do weighing`, `lot_qt` doit etre editable et ecraser directement `lot.lot_qt`.
- Factures client / fournisseur:
  - `Validate` cree aussi le `account.move` pour les factures client.
  - `Validate` attribue aussi le `number` pour les factures client; la numerotation ne doit plus attendre `Post` cote `out`.
  - `Post` ne doit plus forcer une fresh session / demande de mot de passe sur ce flux.
- Pricing:
  - `pricing.pricing` peut etre saisi manuellement meme sans composant.
  - en manuel, l'utilisateur saisit seulement `quantity` et `settl_price`.
  - `fixed_qt`, `fixed_qt_price`, `unfixed_qt`, `unfixed_qt_price` sont derives automatiquement et restent non editables.
  - `fixed_qt` = cumul des `quantity` du groupe.
  - `fixed_qt_price` = moyenne ponderee cumulee des `settl_price`.
  - `unfixed_qt` = quantite de base restante a fixer.
  - `unfixed_qt_price` = `settl_price` de la ligne.
  - `eod_price` reste non editable et suit le prix moyen pondere.
  - le mode auto suit la meme formule.
  - `last` est gere par groupe metier (`line + component`), avec un seul `last=True` par groupe.
  - la ligne `last=True` est celle de `pricing_date` la plus grande; `id` ne sert qu'en tie-break.
- Divers:
  - `trader` filtre sur `TRADER`.
  - `operator` filtre sur `OPERATOR`.
  - les quotas/pricings doivent fallback sur `quantity` si `quantity_theorical` est vide.
- `sale.line` / `purchase.line`: en mode `basis`, si aucun `price_component` n'est defini, le prix et la progression doivent remonter depuis la ligne `Summary` / `pricing.summary` sans component.