Business rules

Memo racine pour les regles metier transverses ou multi-modules.

Pour les regles propres a un module, preferer la documentation locale quand elle existe, par exemple:

Session 2026-04-28 - Devises, TVA, padding et lots

rate est un vrai champ stocke et editable, plus seulement un champ de visualisation.
Le sens du taux suit l'usage Tryton: taux devise seconde / devise societe. Donc, avec une devise societe a 1, le montant societe se calcule par amount_second_currency / rate.
Une ligne est consideree comme manuelle si elle n'a ni origin, ni move_origin, ni move.origin.
En manuel, si l'utilisateur saisit d'abord amount_second_currency, le systeme reprend le dernier taux disponible pour la devise seconde a la date de la ligne, puis calcule debit ou credit.
Si l'utilisateur veut forcer le taux, il efface d'abord debit / credit, saisit rate, et le montant societe est recalcule depuis le montant en devise seconde.
Si le montant societe et le montant devise seconde sont deja presents, le taux implicite est abs(amount_second_currency) / abs(base_amount).
Les lignes generees automatiquement depuis facture doivent aussi renseigner rate quand amount_second_currency existe.
Un fallback central sur account.move.line.create calcule le taux manquant depuis les montants pour eviter les chemins oublies.
Comme rate devient stocke, une mise a jour du module est necessaire; les anciennes lignes doivent etre regenerees ou backfillees si on veut afficher le taux historique.

Deux on_change_amount_second_currency existaient; le second ecrasait la logique de conversion.
La branche negative testait deux fois > 0, donc un montant devise seconde negatif ne generait pas correctement le credit.
Le taux initial etait calcule a l'envers par rapport au standard Tryton attendu.
Les records transitoires Tryton peuvent ne pas exposer un champ non assigne; les chemins generiques doivent utiliser getattr(record, field, None).

on_change_with_rate depend explicitement de currency, company, invoice_date, selection_rate, rate_date et lines.
Ne pas declarer lines.amount dans @fields.depends: ce champ relationnel n'existe pas cote definition de vue et provoque un KeyError.
Les move lines de facture, lignes produit, lignes stock/drop et lignes TVA doivent renseigner rate des qu'elles portent amount_second_currency.

Les taxes sur invoice.lines[].taxes alimentent les taxes calculees de la facture via les lignes taxables.
Les taxes globales de facture (invoice.taxes) peuvent etre automatiques ou manuelles.
Les taxes manuelles sont preservees par update_taxes; les taxes automatiques sont synchronisees, supprimees ou recreees selon les lignes.
Une ligne facture genere des account.tax.line de type base.
Une ligne de taxe facture genere une move line comptable avec account.tax.line de type tax; si la taxe est manuelle, une ligne base complementaire peut etre ajoutee.
La seconde devise est portee par account.move.line (second_currency / amount_second_currency), pas par account.tax.line qui suit la devise comptable de la move line.

Les chemins padding doivent verifier que lot existe avant de lire sale_invoice_line_prov ou sale_invoice_line.
Le bug observe n'etait pas la logique padding elle-meme mais un acces direct a un lot absent sur certaines lignes de facture.

Le calcul des echeances doit fonctionner meme si la premiere ligne facture n'a pas d'origin.
term_lines doit etre calcule hors de la branche qui depend du modele d'origine, avec une ligne metier optionnelle.

Period.find utilise un cache par societe/date/etat.
Une periode creee ou ouverte peut continuer a etre vue comme absente par un worker tant que le cache ou le serveur n'a pas ete rafraichi.

Cote sale.line, la creation de la ligne cree deja le lot virtuel et sa quantite.
Le passage initial de quantity_theorical de None a la quantite de la ligne ne doit pas etre traite comme un delta physique; sinon lot.qt est double.
Le correctif sale ignore le delta quand l'ancienne valeur theorique est None; les modifications suivantes restent bien appliquees en delta.
Cote purchase.line, la logique etait deja protegee par une baseline sur la quantite courante du lot virtuel quand l'ancienne valeur est None.

Une purchase line peut ne pas produire de valorisation si elle est finie, sans lot, filtree par valuation_type, sans lot_price pour les modes priced / efp, sans fees relies a des lots, ou sans derivatives.
En mode basis, sans composant, le fallback metier continue de passer par la ligne summary quand elle existe.

Le calcul du montant d'un fee en mode rate est aligne entre purchase et sale.
Il ne depend pas du payment_term.
La date de fin vient de l'onglet Estimated date de la ligne metier: chercher trigger = bldate, prendre estimated_date, puis ajouter fin_int_delta.
La formule reste en interet simple ACT/360: amount = rate_factor * unit_price * quantity, avec rate_factor = (price / 100) * jours / 360.
Si aucune Estimated Date bldate n'est renseignee, le fee % rate ne calcule pas de montant.

Tant que les lots physiques ne sont pas crees, une purchase et une sale peuvent etre matchees uniquement via lot.qt: lot_p purchase ouvert -> lot_s sale ouvert.
Dans ce cas, les lignes PnL purchase-side (Pur. price, Pur. fee) doivent aussi renseigner sale et sale_line pour apparaitre dans l'onglet PnL de la sale matchee.
Quand le lot physique existe, lot.sale_line reste le chemin prioritaire.
Si un lot purchase ouvert est matche a plusieurs sales differentes, ne pas attacher arbitrairement une seule sale aux lignes purchase-side.
Mark as finished ne veut pas dire "ne plus calculer le PnL": il ignore seulement le reliquat ouvert/virtuel; les lots physiques, fees physiques et derivatives continuent d'etre valorises.