96 lines
3.3 KiB
Markdown
96 lines
3.3 KiB
Markdown
# Fees - regles de synchronisation PnL
|
|
|
|
## PnL apres ajout ou modification d'un fee
|
|
|
|
Un changement sur un `fee.fee` doit relancer le PnL des lignes commerciales
|
|
impactees, limite aux types de valuation fees:
|
|
|
|
- `pur. fee`
|
|
- `sale fee`
|
|
- `shipment fee`
|
|
- `line fee`
|
|
|
|
Le recalcul utilise `valuation_type = 'fees'` pour ne pas reecrire les lignes de
|
|
prix, derives ou MTM.
|
|
|
|
## Lignes impactees
|
|
|
|
Les lignes a recalculer sont retrouvees depuis les lots lies au fee:
|
|
|
|
- `lot.line` pour la `purchase.line`
|
|
- `lot.sale_line` pour la `sale.line`
|
|
|
|
Pour un fee de `stock.shipment.in`, si le lien direct par `fee.lots` ne suffit
|
|
pas, le shipment sert de fallback:
|
|
|
|
- `shipment.incoming_moves[].lot`
|
|
- `shipment.lotqt[].lot_p`
|
|
- `shipment.lotqt[].lot_s`
|
|
|
|
Ce fallback couvre les shipments encore ouverts ou le fee est pose sur des
|
|
`lot.qt` avant creation de lots physiques.
|
|
|
|
## Lots effectifs du fee
|
|
|
|
Le PnL des fees suit la regle BR-PT-021:
|
|
|
|
- tant qu'il n'existe que des lots virtuels, le fee valorise l'ouvert;
|
|
- des qu'un lot physique est lie au fee, les lots physiques deviennent la base
|
|
effective;
|
|
- le lien virtuel peut rester present comme fallback.
|
|
|
|
## Points de declenchement
|
|
|
|
Le recalcul est declenche apres:
|
|
|
|
- creation, modification ou suppression d'un `fee.fee`;
|
|
- creation, modification ou suppression d'un lien `fee.lots`.
|
|
|
|
`stock.shipment.in.validate()` recalcule deja le PnL depuis les lots du
|
|
shipment, mais ce workflow ne couvre pas les changements de fee saisis apres
|
|
coup dans l'onglet Fees.
|
|
|
|
## Fee Report
|
|
|
|
La colonne `Purchase` du Fee Report vient exclusivement du lot lie au fee
|
|
(`fee.lots -> lot.line -> purchase.line.purchase`). Le purchase technique
|
|
stocke sur `fee.fee.purchase`, cree pour facturer le service, ne doit jamais
|
|
etre presente comme le contrat d'achat metier.
|
|
|
|
Les statuts d'invoicing et de paiement des lots suivent les lots effectifs du
|
|
fee. Le statut de paiement du fee distingue `Invoice paid`, `DN/CN paid`,
|
|
`All paid` et `Not paid` selon le paiement complet de sa facture et de son
|
|
eventuelle DN/CN.
|
|
|
|
## Facturation depuis Invoice physical lots
|
|
|
|
Le dialogue affiche les fees `ordered` des lignes correspondant au cote actif:
|
|
|
|
- `Purchase`: fees des `purchase.line` des lots selectionnes;
|
|
- `Sale`: fees des `sale.line` des lots selectionnes.
|
|
|
|
Seuls les fees coches `To invoice` sont traites. En provisoire, un fee sans
|
|
facture est facture normalement et un fee deja facture est ignore. En finale,
|
|
un fee sans facture suit la facturation standard; un fee deja facture suit le
|
|
flux DN/CN existant de `fee.fee.invoice`.
|
|
|
|
## Padding de facture vente dans les commissions broker
|
|
|
|
Le champ `lot.sale_invoice_padding` augmente la quantite facturee au client sans
|
|
modifier le poids physique du lot. Pour les fees, `fee.quantity` reste donc la
|
|
quantite reelle des lots effectifs.
|
|
|
|
Si un fee est coche `Add padding`, le calcul de facturation utilise une quantite
|
|
dediee:
|
|
|
|
`quantite des lots effectifs du fee + padding vente des memes lots`
|
|
|
|
Cette quantite supplementaire s'applique uniquement aux modes:
|
|
|
|
- `Per qt`: montant = quantite avec padding * prix du fee;
|
|
- `% price`: montant = quantite avec padding * prix unitaire de la ligne * %.
|
|
|
|
La purchase technique du fee et la ligne de facture service utilisent la meme
|
|
base. Ainsi, une modification du padding apres une premiere facture est detectee
|
|
par le flux DN/CN existant comme un changement de quantite ou de montant.
|