Check From To + pricing component domain filter
This commit is contained in:
112
notes/business_rules.md
Normal file
112
notes/business_rules.md
Normal file
@@ -0,0 +1,112 @@
|
||||
# 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:
|
||||
|
||||
- `modules/purchase_trade/docs/business-rules.md`
|
||||
- `modules/purchase_trade/docs/padding-invoice-accounting.md`
|
||||
|
||||
## Session 2026-04-28 - Devises, TVA, padding et lots
|
||||
|
||||
### `account.move.line` / saisie manuelle en seconde devise
|
||||
|
||||
- `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.
|
||||
|
||||
### Causes racines des bugs devises
|
||||
|
||||
- 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)`.
|
||||
|
||||
### `account.invoice` / taux et devise
|
||||
|
||||
- `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`.
|
||||
|
||||
### TVA
|
||||
|
||||
- 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.
|
||||
|
||||
### Padding
|
||||
|
||||
- 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.
|
||||
|
||||
### Payment term
|
||||
|
||||
- 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.
|
||||
|
||||
### Periodes comptables
|
||||
|
||||
- `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.
|
||||
|
||||
### `lot.qt` / validation sale et purchase
|
||||
|
||||
- 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`.
|
||||
|
||||
### Valuation / PNL achat
|
||||
|
||||
- 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.
|
||||
Reference in New Issue
Block a user