admin/tradon
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Shipment fees allocation

Browse Source
This commit is contained in:
AzureAD\SylvainDUVERNAY
2026-05-10 16:16:09 +02:00
parent 9e33a577e8
commit 452e9e2632
6 changed files with 782 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

9
Connections/ITSA_Tradon_Prod.md Normal file
View File

@@ -0,0 +1,9 @@
# ITSA_Tradon_Prod
## PostgreSQL Database
- Server: `72.61.163.139`
- Port: `5433`
- User name: `postgres`
- Password: `dsproject`
- Database name: `tradon`

448
modules/purchase_trade/docs/business rules/shipment_fee_allocation.md Normal file
View File

@@ -0,0 +1,448 @@
# BR-PT-005 - Shipment Fee Allocation
## Intent
Allocate shipment costs by combining shipment-level fees and contract-level budgeted fees, while avoiding double counting and keeping fee detail rows available for BI analysis.
## Scope
- Domain: `purchase_trade`
- Target: SQL view/query for shipment fee allocation
- Source tables:
- `lot_lot`
- `lot_qt`
- `lot_qt_hist`
- `fee_fee`
- `product_product`
- `party_party`
- `currency_currency`
- `product_uom`
- Fee sources:
- shipment fees linked with `fee_fee.shipment_in`
- purchase contract fees linked with `fee_fee.line`
- sale contract fees linked with `fee_fee.sale_line`
## Business Context
Every purchase contract line has a virtual lot by default. The virtual lot represents the remaining quantity of the contract line.
When physical lots are created, their quantity reduces the virtual lot quantity. Physical lots represent confirmed physical quantities, typically once the Bill of Lading quantity is known.
Before the vessel is sailing or before the exact Bill of Lading quantity is known, costs can already be ordered or scheduled at shipment level. In that case, virtual shipment quantities must still be included as forecast quantities.
## Quantity Source Rules
Shipment quantity is built directly from lot and shipment tables.
Quantity priority:
1. Use physical lots linked to the shipment when they exist.
2. Use virtual lot shipment quantities only when no physical lot exists yet for the same shipment and contract pair.
This prevents double counting:
- physical lots represent confirmed shipment quantities
- virtual lots represent forecast/open quantities until physical lots exist
## Fee Selection Rules
For each `shipment_id + product_id + supplier_id` pair:
1. Use shipment-level fees of type `ordered` first.
2. If shipment quantity remains uncovered, use shipment-level fees of type `scheduled`.
3. If shipment quantity still remains uncovered, use contract-level fees of type `budgeted`.
Contract-level fallback fees:
- purchase contract fees are eligible
- sale contract fees are eligible
- only `type = 'budgeted'` is eligible
- budgeted contract fees are applied to the remaining uncovered shipment quantity
Shipment-level fees:
- only `type IN ('ordered', 'scheduled')` are eligible
- null fee quantity is treated as `0` and does not allocate quantity
- allocated shipment fee quantity is capped to the shipment quantity
If multiple fees exist for the same product/supplier pair at the selected level, keep multiple rows. The view must preserve details for analysis.
## Sign Rules
Use the same sign logic as the existing fee utility views.
Shipment fees:
- `rec` = `+1`
- any other `p_r` value = `-1`
Purchase contract budgeted fees:
- `rec` = `-1`
- any other `p_r` value = `+1`
Sale contract budgeted fees:
- `rec` = `+1`
- any other `p_r` value = `-1`
## Expected Behavior
Example:
- Shipment quantity: `1000 Mt`
- Shipment ordered freight: `800 Mt` at `60 USD/Mt`
- Contract budgeted freight: `50 USD/Mt`
Expected output:
- `800 Mt` at `60 USD/Mt` from shipment ordered fee
- `200 Mt` at `50 USD/Mt` from contract budgeted fee
If a scheduled fee also exists:
- Shipment quantity: `1000 Mt`
- Ordered freight: `800 Mt` at `60 USD/Mt`
- Scheduled freight: `150 Mt` at `55 USD/Mt`
- Contract budgeted freight: `50 USD/Mt`
Expected output:
- `800 Mt` at `60 USD/Mt` from shipment ordered fee
- `150 Mt` at `55 USD/Mt` from shipment scheduled fee
- `50 Mt` at `50 USD/Mt` from contract budgeted fee
## Query Draft
```sql
WITH physical_shipment_lots AS (
SELECT
l.lot_shipment_in AS shipment_id,
l.id AS lot_id,
l.lot_type,
l.line AS purchase_line_id,
l.sale_line AS sale_line_id,
qh.quantity AS shipment_quantity,
l.lot_unit_line AS shipment_unit_id
FROM lot_lot l
LEFT JOIN lot_qt_hist qh
ON qh.lot = l.id
AND qh.quantity_type = l.lot_state
WHERE l.lot_type = 'physic'
AND l.lot_shipment_in IS NOT NULL
),
virtual_shipment_lots AS (
SELECT
q.lot_shipment_in AS shipment_id,
vp.id AS lot_id,
vp.lot_type,
vp.line AS purchase_line_id,
COALESCE(vp.sale_line, ps.sale_line) AS sale_line_id,
q.lot_quantity AS shipment_quantity,
q.lot_unit AS shipment_unit_id
FROM lot_qt q
JOIN lot_lot vp
ON vp.id = q.lot_p
AND vp.lot_type = 'virtual'
LEFT JOIN lot_lot ps
ON ps.id = q.lot_s
WHERE q.lot_shipment_in IS NOT NULL
AND NOT EXISTS (
SELECT 1
FROM physical_shipment_lots pl
WHERE pl.shipment_id = q.lot_shipment_in
AND pl.purchase_line_id = vp.line
AND (
pl.sale_line_id = COALESCE(vp.sale_line, ps.sale_line)
OR COALESCE(vp.sale_line, ps.sale_line) IS NULL
)
)
),
shipment_lots AS (
SELECT * FROM physical_shipment_lots
UNION ALL
SELECT * FROM virtual_shipment_lots
),
shipment_context AS (
SELECT
shipment_id,
purchase_line_id,
sale_line_id,
shipment_unit_id,
SUM(COALESCE(shipment_quantity, 0)) AS shipment_quantity
FROM shipment_lots
WHERE shipment_id IS NOT NULL
GROUP BY
shipment_id,
purchase_line_id,
sale_line_id,
shipment_unit_id
),
shipment_base AS (
SELECT
shipment_id,
SUM(shipment_quantity) AS shipment_quantity
FROM shipment_context
GROUP BY shipment_id
),
shipment_fee_candidates AS (
SELECT
f.id AS fee_id,
'Shipment' AS fee_source,
f.type AS fee_type,
CASE
WHEN f.type = 'ordered' THEN 1
WHEN f.type = 'scheduled' THEN 2
END AS priority,
sb.shipment_id,
NULL::integer AS purchase_line_id,
NULL::integer AS sale_line_id,
f.product AS product_id,
f.supplier AS supplier_id,
f.mode AS packaging,
f.p_r AS pay_or_rec,
f.state,
f.weight_type,
COALESCE(f.quantity, 0) AS requested_quantity,
sb.shipment_quantity,
f.price AS fee_price,
f.currency AS currency_id,
f.unit AS unit_id,
CASE
WHEN upper(f.p_r::text) = 'REC' THEN 1
ELSE -1
END AS sign_multiplier
FROM shipment_base sb
JOIN fee_fee f
ON f.shipment_in = sb.shipment_id
WHERE f.type IN ('ordered', 'scheduled')
),
shipment_fee_allocated AS (
SELECT
c.*,
LEAST(
c.requested_quantity,
GREATEST(
c.shipment_quantity
- COALESCE(
SUM(c.requested_quantity) OVER (
PARTITION BY c.shipment_id, c.product_id, c.supplier_id
ORDER BY c.priority, c.fee_id
ROWS BETWEEN UNBOUNDED PRECEDING AND 1 PRECEDING
),
0
),
0
)
) AS allocated_quantity
FROM shipment_fee_candidates c
),
shipment_fee_coverage AS (
SELECT
shipment_id,
product_id,
supplier_id,
MAX(shipment_quantity) AS shipment_quantity,
SUM(allocated_quantity) AS allocated_quantity
FROM shipment_fee_allocated
GROUP BY shipment_id, product_id, supplier_id
),
contract_budgeted_fee_candidates AS (
SELECT
f.id AS fee_id,
'Purchase Contract' AS fee_source,
f.type AS fee_type,
3 AS priority,
sc.shipment_id,
sc.purchase_line_id,
NULL::integer AS sale_line_id,
f.product AS product_id,
f.supplier AS supplier_id,
f.mode AS packaging,
f.p_r AS pay_or_rec,
f.state,
f.weight_type,
sc.shipment_quantity,
f.price AS fee_price,
f.currency AS currency_id,
COALESCE(f.unit, sc.shipment_unit_id) AS unit_id,
CASE
WHEN upper(f.p_r::text) = 'REC' THEN -1
ELSE 1
END AS sign_multiplier
FROM shipment_context sc
JOIN fee_fee f
ON f.line = sc.purchase_line_id
WHERE f.type = 'budgeted'
AND sc.purchase_line_id IS NOT NULL
UNION ALL
SELECT
f.id AS fee_id,
'Sale Contract' AS fee_source,
f.type AS fee_type,
3 AS priority,
sc.shipment_id,
NULL::integer AS purchase_line_id,
sc.sale_line_id,
f.product AS product_id,
f.supplier AS supplier_id,
f.mode AS packaging,
f.p_r AS pay_or_rec,
f.state,
f.weight_type,
sc.shipment_quantity,
f.price AS fee_price,
f.currency AS currency_id,
COALESCE(f.unit, sc.shipment_unit_id) AS unit_id,
CASE
WHEN upper(f.p_r::text) = 'REC' THEN 1
ELSE -1
END AS sign_multiplier
FROM shipment_context sc
JOIN fee_fee f
ON f.sale_line = sc.sale_line_id
WHERE f.type = 'budgeted'
AND sc.sale_line_id IS NOT NULL
),
contract_budgeted_allocated AS (
SELECT
c.*,
GREATEST(
c.shipment_quantity - COALESCE(fc.allocated_quantity, 0),
0
) AS allocated_quantity
FROM contract_budgeted_fee_candidates c
LEFT JOIN shipment_fee_coverage fc
ON fc.shipment_id = c.shipment_id
AND fc.product_id = c.product_id
AND fc.supplier_id = c.supplier_id
),
final_fees AS (
SELECT
fee_id,
fee_source,
fee_type,
priority,
shipment_id,
purchase_line_id,
sale_line_id,
product_id,
supplier_id,
packaging,
pay_or_rec,
state,
weight_type,
allocated_quantity AS fee_quantity,
fee_price,
currency_id,
unit_id,
sign_multiplier
FROM shipment_fee_allocated
WHERE allocated_quantity > 0
UNION ALL
SELECT
fee_id,
fee_source,
fee_type,
priority,
shipment_id,
purchase_line_id,
sale_line_id,
product_id,
supplier_id,
packaging,
pay_or_rec,
state,
weight_type,
allocated_quantity AS fee_quantity,
fee_price,
currency_id,
unit_id,
sign_multiplier
FROM contract_budgeted_allocated
WHERE allocated_quantity > 0
)
SELECT
f.shipment_id AS "intShipmentId",
f.fee_id AS "intFeeId",
f.fee_source AS "Fee Source",
f.fee_type AS "Fee Type",
f.priority AS "Priority",
f.purchase_line_id AS "intPurchaseLineId",
f.sale_line_id AS "intSaleLineId",
f.product_id AS "intProductId",
p.code AS "Fee",
f.supplier_id AS "intSupplierId",
sup.name AS "Supplier",
f.packaging AS "Packaging",
f.pay_or_rec AS "Pay or Rec",
f.state AS "State",
CASE
WHEN upper(f.weight_type::text) = 'BRUT' THEN 'Gross'
ELSE 'Net'
END AS "Weighing Type",
f.fee_quantity AS "Quantity",
f.fee_price * f.sign_multiplier AS "Price",
cur.name AS "Currency",
COALESCE(uom.name, 'Mt') AS "Unit",
f.fee_quantity * f.fee_price * f.sign_multiplier AS "Amount",
CASE
WHEN upper(p.code::text) LIKE '%FREIGHT%' THEN 'Freight'
WHEN upper(p.code::text) LIKE '%PROFIT SHARING%' THEN 'Profit Sharing'
ELSE 'Other Costs'
END AS "Cost Group"
FROM final_fees f
JOIN product_product p
ON p.id = f.product_id
JOIN party_party sup
ON sup.id = f.supplier_id
LEFT JOIN currency_currency cur
ON cur.id = f.currency_id
LEFT JOIN product_uom uom
ON uom.id = f.unit_id
ORDER BY
f.shipment_id,
f.product_id,
f.supplier_id,
f.priority,
f.fee_id;
```
## Impacted Files
Expected SQL/view impact:
- BI SQL view or migration file that will materialize the shipment fee allocation query
- Existing related views for comparison:
- `vw_utility_contract_fees`
- `vw_utility_shipment_fees`
- `vw_bi_itsa_fct_contract_fees`
- `vw_bi_itsa_fct_shipment_fees`
No Python code impact is expected unless the view is generated by module migration code.
## Tests
Recommended tests:
- shipment with no ordered/scheduled fee uses full budgeted contract fee quantity
- shipment with ordered fee covering full quantity does not use budgeted fallback
- shipment with ordered fee partially covering quantity uses budgeted fallback for remaining quantity
- shipment with ordered and scheduled fees uses ordered first, scheduled second, budgeted third
- shipment fee quantity above shipment quantity is capped
- null shipment fee quantity does not allocate quantity
- multiple fees at the same priority are kept as multiple detail rows
- physical lot quantity replaces virtual forecast quantity for the same shipment/contract pair
- virtual lot quantity is used when no physical lot exists yet
## Open Questions
- Q: Should this query become a permanent PostgreSQL view?
- Q: What should the final view name be?
- Q: Should the output include both allocated quantity and original fee quantity for auditability?

1
modules/purchase_trade/docs/business-rules.md
View File

@@ -34,6 +34,7 @@ Owner technique: `Open Squared`
| BR-PT-002 | Le lot physique est le pont metier entre purchase, sale et shipment | Lot / Navigation | [business rules/lot-navigation.md](business%20rules/lot-navigation.md) |
| BR-PT-003 | Le freight amount des templates facture vient du fee de shipment | Invoice / Freight | [business rules/invoice-freight.md](business%20rules/invoice-freight.md) |
| BR-PT-004 | Market Price Import | Pricing | [business rules/market-price-import.md](business%20rules/market-price-import.md) |
| BR-PT-005 | Shipment Fee Allocation | Shipment / Fees | [business rules/shipment_fee_allocation.md](business%20rules/shipment_fee_allocation.md) |
## 4) Convention pour les nouvelles regles

2
modules/purchase_trade/docs/documentation-management.md
View File

@@ -41,6 +41,8 @@ Example:
- Comment: current code allows empty `price_value`. Implementing this answer requires a code change.
```
## Backlog From Documentation
- When answered questions imply code changes, create a dedicated backlog file for the feature or rule.

322
modules/purchase_trade/docs/documentation-structure-summary.html Normal file
View File

@@ -0,0 +1,322 @@
<!doctype html>
<html lang="fr">
<head>
<meta charset="utf-8">
<title>Structure documentaire Markdown - purchase_trade</title>
<style>
@page {
size: A4;
margin: 18mm 16mm;
}
body {
color: #172033;
font-family: "Segoe UI", Arial, sans-serif;
font-size: 11px;
line-height: 1.42;
margin: 0;
}
h1 {
color: #0f2742;
font-size: 25px;
line-height: 1.1;
margin: 0 0 6px;
}
h2 {
border-bottom: 2px solid #d8e2ef;
color: #18466f;
font-size: 16px;
margin: 22px 0 8px;
padding-bottom: 4px;
}
h3 {
color: #1f5c8f;
font-size: 13px;
margin: 13px 0 4px;
}
p {
margin: 5px 0;
}
code {
background: #eef3f8;
border-radius: 3px;
color: #0f3a5f;
font-family: Consolas, monospace;
font-size: 10px;
padding: 1px 3px;
}
table {
border-collapse: collapse;
margin: 8px 0 12px;
width: 100%;
}
th, td {
border: 1px solid #d4dde8;
padding: 6px 7px;
text-align: left;
vertical-align: top;
}
th {
background: #eaf2fb;
color: #14395a;
font-weight: 650;
}
ul {
margin: 5px 0 10px 18px;
padding: 0;
}
li {
margin: 3px 0;
}
.subtitle {
color: #5b6b7f;
font-size: 12px;
margin-bottom: 16px;
}
.callout {
background: #f4f8fc;
border-left: 4px solid #2d78b7;
margin: 9px 0 12px;
padding: 8px 10px;
}
.warning {
background: #fff7e8;
border-left-color: #d98718;
}
.ok {
background: #edf8f0;
border-left-color: #329c50;
}
.tree {
background: #f7f9fb;
border: 1px solid #dce5ee;
border-radius: 4px;
font-family: Consolas, monospace;
font-size: 10px;
padding: 9px 11px;
white-space: pre-wrap;
}
.page-break {
break-before: page;
}
.small {
color: #5b6b7f;
font-size: 10px;
}
</style>
</head>
<body>
<h1>Structure documentaire Markdown - purchase_trade</h1>
<p class="subtitle">Document recapitulatif de la structure mise en place pour les regles metier, bugs, backlogs et gestion documentaire.</p>
<div class="callout">
<strong>Objectif general.</strong>
La documentation est organisee pour separer les regles metier, les bugs, les backlogs d'implementation et les conventions de gestion. L'objectif est de garder un contexte lisible pour les humains et chargeable a la demande pour les agents.
</div>
<h2>1. Arborescence Markdown</h2>
<div class="tree">modules/purchase_trade/docs/
business-rules.md
documentation-management.md
bugs.md
template-rules.md
business rules/
lot-quantity.md
lot-navigation.md
invoice-freight.md
market-price-import.md
backlog/
market-price-import-backlog.md</div>
<h2>2. Role et description des fichiers</h2>
<table>
<thead>
<tr>
<th>Fichier</th>
<th>Role</th>
<th>Description</th>
</tr>
</thead>
<tbody>
<tr>
<td><code>business-rules.md</code></td>
<td>Catalogue des regles metier</td>
<td>Point d'entree des regles <code>purchase_trade</code>. Contient le scope, le glossaire, le catalogue des IDs <code>BR-PT-xxx</code> et les liens vers les fiches detaillees.</td>
</tr>
<tr>
<td><code>documentation-management.md</code></td>
<td>Regles de gestion documentaire</td>
<td>Decrit le workflow: creation de regles, questions ouvertes <code>Q:</code>/<code>A:</code>, backlogs, bugs, statuts, commits de reference et discipline de scope.</td>
</tr>
<tr>
<td><code>bugs.md</code></td>
<td>Registre des bugs</td>
<td>Lieu d'enregistrement initial des bugs avec ID stable <code>BUG-PT-xxx</code>. Chaque bug doit etre relie a une entree backlog.</td>
</tr>
<tr>
<td><code>template-rules.md</code></td>
<td>Regles specifiques aux templates</td>
<td>Guide de correction et d'analyse des templates Relatorio/FODT, notamment les ponts Python, les placeholders XML et le cache des reports facture.</td>
</tr>
<tr>
<td><code>business rules/lot-quantity.md</code></td>
<td>Regle detaillee BR-PT-001</td>
<td>Specifie l'ajustement de <code>quantity_theorical</code>, la synchronisation du lot virtuel et des quantites ouvertes <code>lot.qt</code>.</td>
</tr>
<tr>
<td><code>business rules/lot-navigation.md</code></td>
<td>Regle detaillee BR-PT-002</td>
<td>Documente le lot physique comme pont stable entre purchase, sale, shipment et facture.</td>
</tr>
<tr>
<td><code>business rules/invoice-freight.md</code></td>
<td>Regle detaillee BR-PT-003</td>
<td>Definit que le <code>FREIGHT VALUE</code> des factures vient du fee de shipment <code>Maritime freight</code>, via le lot physique.</td>
</tr>
<tr>
<td><code>business rules/market-price-import.md</code></td>
<td>Regle detaillee BR-PT-004</td>
<td>Specifie l'import de prix marche depuis Excel: colonnes attendues, parsing, creation d'index, resultats, edge cases et questions tranchees.</td>
</tr>
<tr>
<td><code>backlog/market-price-import-backlog.md</code></td>
<td>Backlog feature Market Price Import</td>
<td>Liste les travaux issus de BR-PT-004 et des bugs associes, avec statut, priorite, source, impact code, tests attendus et commit d'implementation si applicable.</td>
</tr>
</tbody>
</table>
<h2>3. Workflow recommande</h2>
<h3>Nouvelle regle metier</h3>
<ul>
<li>Ajouter une ligne dans <code>business-rules.md</code>.</li>
<li>Creer une fiche dediee dans <code>business rules/</code> si la regle a des impacts code, tests, edge cases ou questions.</li>
<li>Utiliser des questions <code>Q:</code> et reponses <code>A:</code>; ajouter <code>Comment:</code> si la decision implique un changement code.</li>
</ul>
<h3>Nouveau bug</h3>
<ul>
<li>Creer une entree dans <code>bugs.md</code> avec un ID stable <code>BUG-PT-xxx</code>.</li>
<li>Creer une entree backlog correspondante, soit dans un backlog existant, soit dans un nouveau fichier sous <code>backlog/</code>.</li>
<li>Lier le bug au backlog et le backlog au bug.</li>
</ul>
<h3>Implementation</h3>
<ul>
<li>Passer le backlog de <code>open</code> a <code>in-progress</code>, puis <code>to-be-tested</code> apres implementation.</li>
<li>Documenter le travail realise et le statut de validation.</li>
<li>Apres commit, enregistrer le hash du commit dans l'entree backlog.</li>
</ul>
<h2>4. Avantages</h2>
<ul>
<li><strong>Tra&ccedil;abilite.</strong> Les decisions metier, bugs, backlogs, tests et commits sont relies.</li>
<li><strong>Scope clair.</strong> Un agent peut charger seulement le fichier pertinent au lieu de tout lire.</li>
<li><strong>Meilleure maintenance.</strong> Les regles lourdes vivent dans des fiches dediees; le catalogue reste court.</li>
<li><strong>Priorisation explicite.</strong> Le backlog garde statut, priorite, tests attendus et validation.</li>
<li><strong>Historique de decision.</strong> Les sections <code>Open Questions</code> gardent les arbitrages <code>Q:</code>/<code>A:</code>.</li>
<li><strong>Support bug propre.</strong> Chaque bug a un ID stable et une entree backlog obligatoire.</li>
</ul>
<h2>5. Inconvenients / points de vigilance</h2>
<ul>
<li><strong>Discipline necessaire.</strong> Il faut maintenir les liens et les statuts, sinon la structure perd de sa valeur.</li>
<li><strong>Risque de fragmentation.</strong> Trop de petits fichiers peuvent ralentir la comprehension si le catalogue n'est pas tenu a jour.</li>
<li><strong>Noms avec espaces.</strong> Le dossier <code>business rules/</code> est lisible, mais les liens Markdown doivent utiliser <code>business%20rules</code> dans les URLs.</li>
<li><strong>Backlog a synchroniser.</strong> Une correction code doit etre reportee dans le backlog, notamment le statut et le commit.</li>
<li><strong>Duplication possible.</strong> Certaines informations peuvent apparaitre dans regle, bug et backlog; il faut garder chaque fichier dans son role.</li>
</ul>
<div class="page-break"></div>
<h2>6. Estimation de consommation tokens</h2>
<p>Estimation basee sur la regle pratique de l'image fournie: <strong>1 KB &asymp; 200 tokens</strong>.</p>
<table>
<thead>
<tr>
<th>Fichier</th>
<th>Taille approx.</th>
<th>Tokens approx.</th>
<th>Usage conseille</th>
</tr>
</thead>
<tbody>
<tr>
<td><code>backlog/market-price-import-backlog.md</code></td>
<td>4.70 KB</td>
<td>~939</td>
<td>Charger pour prioriser ou coder un item Market Price Import.</td>
</tr>
<tr>
<td><code>bugs.md</code></td>
<td>1.67 KB</td>
<td>~333</td>
<td>Charger au moment de declarer ou suivre un bug.</td>
</tr>
<tr>
<td><code>business rules/invoice-freight.md</code></td>
<td>1.49 KB</td>
<td>~298</td>
<td>Charger pour les sujets freight/facture.</td>
</tr>
<tr>
<td><code>business rules/lot-navigation.md</code></td>
<td>1.84 KB</td>
<td>~369</td>
<td>Charger pour les chemins achat/vente/shipment.</td>
</tr>
<tr>
<td><code>business rules/lot-quantity.md</code></td>
<td>2.87 KB</td>
<td>~574</td>
<td>Charger pour les changements de quantite theorique.</td>
</tr>
<tr>
<td><code>business rules/market-price-import.md</code></td>
<td>6.21 KB</td>
<td>~1 242</td>
<td>Charger pour comprendre la specification complete de l'import.</td>
</tr>
<tr>
<td><code>business-rules.md</code></td>
<td>2.21 KB</td>
<td>~441</td>
<td>Charger comme index de depart.</td>
</tr>
<tr>
<td><code>documentation-management.md</code></td>
<td>4.47 KB</td>
<td>~893</td>
<td>Charger quand on gere docs, bugs, statuts ou backlog.</td>
</tr>
<tr>
<td><code>template-rules.md</code></td>
<td>6.14 KB</td>
<td>~1 227</td>
<td>Charger uniquement pour les sujets templates/reporting.</td>
</tr>
<tr>
<th>Total des 9 fichiers</th>
<th>31.58 KB</th>
<th>~6 316</th>
<th>Faible a modere si charge ensemble; meilleur en chargement a la demande.</th>
</tr>
</tbody>
</table>
<h3>Evaluation</h3>
<div class="callout ok">
<strong>Consommation estimee: faible a moderee.</strong>
A environ 6 300 tokens pour tout le dossier Markdown <code>purchase_trade/docs</code>, la structure reste tres raisonnable par rapport a un budget conseille de 60k-80k tokens. Le risque principal n'est pas un fichier unique, mais l'accumulation avec l'historique de conversation, les diffs, les logs et les sorties de tests.
</div>
<div class="callout warning">
<strong>Bonne pratique.</strong>
Charger <code>business-rules.md</code> comme index, puis seulement la fiche detaillee, le bug ou le backlog utile. Eviter de charger tous les fichiers docs plus de gros logs ou des diffs complets dans la meme interaction.
</div>
<h2>7. Recommandation finale</h2>
<p>La structure est pertinente et peu couteuse en tokens si elle est utilisee comme une documentation modulaire. Elle donne une bonne base pour travailler avec des agents: contexte court au depart, approfondissement a la demande, liens explicites entre bug, regle, backlog, tests et commit.</p>
<p class="small">Document genere le 2026-05-08 pour le module <code>purchase_trade</code>.</p>
</body>
</html>

BIN
modules/purchase_trade/docs/documentation-structure-summary.pdf Normal file
View File

Binary file not shown.