diff --git a/AGENTS.md b/AGENTS.md
index 509c700..ce99e0e 100644
--- a/AGENTS.md
+++ b/AGENTS.md
@@ -71,6 +71,12 @@ Guide rapide pour les agents qui codent dans ce repository.
   - `modules/purchase_trade/docs/business-rules.md`
 - Decisions templates / reports:
   - `notes/template_business_rules.md`
+- Documentation comptable et reporting:
+  - `notes/accounting/README.md`
+  - `notes/accounting/gap_analysis_workflow.md`
+  - `notes/accounting/reporting.md`
+  - `notes/accounting/business_rules.md`
+  - `notes/accounting/purchase_trade_extensions.md`
 - Regles sensibles `purchase_trade` a relire avant de toucher lots, quantites
   ou fees:
   - `modules/purchase_trade/AGENTS.md`
diff --git a/notes/accounting/README.md b/notes/accounting/README.md
new file mode 100644
index 0000000..ccd776e
--- /dev/null
+++ b/notes/accounting/README.md
@@ -0,0 +1,73 @@
+# Accounting Documentation
+
+Date: 2026-05-05
+Scope: modules `account*` standards Tryton + extensions comptables dans
+`purchase_trade`.
+
+## Objectif
+
+Cette documentation sert a comparer le comportement comptable de ce repository
+avec un standard externe ou une installation Tryton de reference.
+
+Elle distingue volontairement:
+
+- les modules comptables standards `account*`;
+- les rapports imprimables `ir.action.report` / `.fodt`;
+- les vues de reporting SQL exposees comme modeles `ModelSQL.table_query()`;
+- les extensions metier `purchase_trade` qui changent les flux comptables ou
+  ajoutent du reporting de gestion.
+
+## Fichiers
+
+- `modules_inventory.md`
+  - inventaire fonctionnel des modules `account*`.
+- `business_rules.md`
+  - regles comptables et flux critiques extraits des modules standards et des
+    notes de session.
+- `reporting.md`
+  - cartographie detaillee du reporting comptable standard et des extensions
+    `purchase_trade`.
+- `general_ledger_gap_analysis.md`
+  - premiere comparaison detaillee entre le report ideal `GL-001 General
+    Ledger` et le General Ledger Tryton/Tradon.
+- `purchase_trade_extensions.md`
+  - points d'extension comptables propres a Tradon.
+- `comparison_checklist.md`
+  - grille de comparaison avec un standard.
+- `gap_analysis_workflow.md`
+  - methode de comparaison a reutiliser pour les prochains rapports.
+
+## Sources principales
+
+- `modules/account/`
+- `modules/account_invoice/`
+- `modules/account_payment/`
+- `modules/account_statement/`
+- `modules/account_asset/`
+- `modules/account_stock_*`
+- `modules/account_export*`
+- `modules/account_*` pays/localisations
+- `modules/purchase_trade/account.py`
+- `modules/purchase_trade/invoice.py`
+- `modules/purchase_trade/stock.py`
+- `modules/purchase_trade/fee.py`
+- `modules/purchase_trade/forex.py`
+- `modules/purchase_trade/purchase.py`
+- `modules/purchase_trade/valuation.py`
+- `modules/purchase_trade/credit_risk.py`
+- `notes/business_rules.md`
+- `notes/template_business_rules.md`
+- `modules/purchase_trade/docs/*.md`
+
+## Methode d'extraction
+
+1. Lire `tryton.cfg` pour identifier dependances et XML charges.
+2. Lire les classes `__name__ = 'account...'` et les registrations du Pool.
+3. Identifier les workflows: `post`, `validate`, `cancel`, `draft`,
+   `process`, `paid`.
+4. Identifier les rapports:
+   - `ir.action.report` pour les exports imprimables;
+   - `ir.action.act_window` avec `context_model` pour les vues analytiques;
+   - classes `Report`;
+   - classes `ModelSQL` avec `table_query()`.
+5. Croiser avec les docs locales `purchase_trade` pour les decisions metier.
diff --git a/notes/accounting/business_rules.md b/notes/accounting/business_rules.md
new file mode 100644
index 0000000..0b9a57f
--- /dev/null
+++ b/notes/accounting/business_rules.md
@@ -0,0 +1,136 @@
+# Accounting Business Rules
+
+Date: 2026-05-05
+
+## 1. Ecritures comptables
+
+Source principale: `modules/account/move.py`.
+
+### Move
+
+- `account.move` porte un numero interne `number`, un `post_number`, une
+  societe, une periode, un journal, une date effective, une date de post et des
+  lignes.
+- Un move draft peut etre modifie; un move posted ne doit pas etre modifie hors
+  champs explicitement toleres.
+- A la creation, le numero est tire de la sequence du journal si absent.
+- La date ajuste la periode si la date sort de la periode courante.
+- Le posting refuse:
+  - un move sans ligne;
+  - un move non equilibre dans la devise societe.
+- Au `post`, le move recoit `state = posted`, `post_date` et `post_number`.
+- Les lignes a zero sur comptes reconciliables peuvent etre letrees
+  automatiquement.
+
+### Move Line
+
+- `account.move.line` porte debit, credit, compte, party, devise seconde,
+  montant devise seconde, taxes, maturity date et reconciliation.
+- La validite des lignes suit l'equilibre du move.
+- Le lettrage groupe compte, party et devise.
+- Si une devise seconde est presente, le solde de reconciliation peut etre lu
+  dans cette devise plutot que dans la devise societe.
+
+## 2. Comptes
+
+Source principale: `modules/account/account.py`.
+
+- Les comptes sont rattaches a une societe et a un type de compte.
+- Les types de compte portent les categories structurantes:
+  assets, receivable, payable, debt, revenue, expense, stock.
+- Les comptes peuvent etre fermes, reconciliables, ou exiger une party.
+- Les comptes portent aussi des indicateurs Tradon ajoutes:
+  `fx_eval`, `fx_eval_detail`, comptes de gain/perte de change.
+- Les soldes sont calcules par contexte: societe, periodes, dates, posted only.
+
+## 3. Factures
+
+Source principale: `modules/account_invoice/invoice.py`.
+
+### Workflow
+
+Etats:
+
+- `draft`
+- `validated`
+- `posted`
+- `paid`
+- `cancelled`
+
+Regles:
+
+- Une facture fournisseur exige une date de facture des `Validate`.
+- Une facture client standard exige la date au `Post`, mais ce repository a
+  modifie le flux pour creer aussi le move et le numero client au `Validate`.
+- `posted` represente le posting comptable.
+- `paid` depend du lettrage des lignes a payer.
+- `cancelled` cree ou reference les moves d'annulation selon le contexte.
+
+### Montants et taxes
+
+- `untaxed_amount`, `tax_amount`, `total_amount` sont caches et recalcules.
+- Les taxes de lignes alimentent les taxes calculees de facture.
+- Les taxes manuelles sont preservees lors de `update_taxes`.
+- Une ligne produit genere des `account.tax.line` de type `base`.
+- Une ligne de taxe facture genere une move line avec `account.tax.line` de
+  type `tax`; si la taxe est manuelle, une ligne `base` complementaire peut
+  etre ajoutee.
+- La devise seconde est portee par `account.move.line`, pas par
+  `account.tax.line`.
+
+### Paiements
+
+- `lines_to_pay` expose les lignes comptables ouvertes a payer.
+- `payment_lines` rattache les lignes de paiement a la facture.
+- Le wizard `account.invoice.pay` cree/reconcilie les paiements selon la
+  methode de paiement.
+- Les wizards de reschedule/delegate agissent sur les lignes a payer.
+
+## 4. Devises
+
+Regles notees dans `notes/business_rules.md` et vues dans le code:
+
+- `account.move.line.rate` est un champ stocke/editable dans ce repository.
+- Le sens du taux suit Tryton: devise seconde / devise societe.
+- Montant societe = `amount_second_currency / rate` quand la devise societe a
+  une base a 1.
+- Les lignes facture generees doivent renseigner `rate` quand elles portent
+  `amount_second_currency`.
+- Un fallback central sur `account.move.line.create` calcule le taux manquant
+  depuis les montants.
+- La revaluation FX Tradon cree des moves de revaluation sur comptes marques
+  `fx_eval`.
+
+## 5. Reconciliation
+
+Source principale: `modules/account/move.py`.
+
+- Les comptes reconciliables peuvent etre letres automatiquement ou via wizard.
+- Le wizard de reconciliation cherche les comptes avec lignes ouvertes, puis
+  les parties, puis les devises.
+- Il peut proposer uniquement les combinaisons balancees, ou creer un write-off
+  si un ecart reste.
+- La devise de reconciliation est la devise seconde si elle existe, sinon la
+  devise du compte/societe.
+
+## 6. Statements
+
+Source principale: `modules/account_statement/statement.py`.
+
+- Un statement a des lignes, origines, solde de depart/fin, devise et journal.
+- La validation controle solde, montants et nombre de lignes selon la
+  configuration.
+- Le posting cree les moves des lignes.
+- La reconciliation des lignes relie les lignes statement aux lignes comptables.
+
+## 7. Stock et couts
+
+Source principale: modules `account_stock_*`.
+
+- Les modules stock comptables generent des moves depuis les mouvements stock
+  selon methode continental/anglo-saxon.
+- Les landed costs et shipment costs creent des objets dedies, allocation sur
+  mouvements/shipments, puis posting comptable.
+- Dans `purchase_trade`, les fees peuvent creer des mouvements de stock/cout
+  supplementaires lies aux lots.
+
diff --git a/notes/accounting/comparison_checklist.md b/notes/accounting/comparison_checklist.md
new file mode 100644
index 0000000..8912e63
--- /dev/null
+++ b/notes/accounting/comparison_checklist.md
@@ -0,0 +1,137 @@
+# Accounting Reporting Comparison Checklist
+
+Date: 2026-05-05
+
+Method: use `gap_analysis_workflow.md` for the repeatable extraction and
+classification process before filling this checklist.
+
+## 1. Standard financier
+
+Comparer avec le standard cible:
+
+- Chart of Accounts:
+  - types de comptes;
+  - categories assets/liability/equity/revenue/expense;
+  - comptes fermes;
+  - comptes reconciliables;
+  - party required.
+- Fiscal years/periods:
+  - ouverture/fermeture;
+  - posted only;
+  - periodes speciales.
+- Moves:
+  - numerotation draft/post;
+  - controle equilibre;
+  - annulation/reversal;
+  - lettrage automatique.
+
+## 2. Reports standards
+
+### General Ledger
+
+- Colonnes disponibles.
+- Filtre fiscal year.
+- Filtre period range.
+- Filtre date range.
+- Filtre journal.
+- Posted only.
+- Drill-down par compte.
+- Drill-down par party.
+- Lignes d'ouverture et soldes de fin.
+- Devise seconde affichee ou non.
+
+### Trial Balance
+
+- Meme source que General Ledger.
+- Comptes sans mouvement.
+- Total debit/credit.
+- Start/end balances.
+- Posted only.
+
+### Balance Sheet
+
+- Date unique.
+- Comparison N-1.
+- Classification via account types.
+- Presence ou absence d'impression FODT.
+
+### Income Statement
+
+- Period/date range.
+- Comparison.
+- Calcul par account type.
+- Posted only.
+
+### Aged Balance
+
+- Buckets par day/week/month/year.
+- Customers/suppliers/both.
+- Detail par origin.
+- Reconciliation apres date.
+- Maturity date fallback move date.
+- Devise seconde et filtre currency.
+
+### Tax Reporting
+
+- Tax lines base/tax.
+- Taxes manuelles preservees.
+- Cash basis.
+- Non deductible taxes.
+- Localisations pays.
+
+## 3. Invoice Reporting
+
+- Report standard facture.
+- Cache `invoice_report_cache`.
+- Revisions de report.
+- Prepayment.
+- CN/DN.
+- Payment order.
+- Packing list.
+- Dynamic template resolution.
+- Proprietes `report_*`.
+- Regle CN/DN selon type et signe.
+
+## 4. Tradon Specific
+
+- Invoice padding:
+  - report audit;
+  - additional moves;
+  - reversal;
+  - comptes configures.
+- Fees:
+  - fee report;
+  - invoice status;
+  - amount source;
+  - lot effective rule.
+- Valuation/PnL:
+  - sale-first;
+  - purchase matched;
+  - open vs physical lots;
+  - MTM;
+  - fees excluded from MTM.
+- Forex:
+  - revaluation detail/global;
+  - move links;
+  - accounts/journal config.
+- Credit risk:
+  - exposure source;
+  - internal/insurance limits;
+  - payment term/risk classification.
+- Dashboard:
+  - invoices not validated;
+  - invoices not paid;
+  - payments not received;
+  - payments not done.
+
+## 5. Questions ouvertes pour comparaison
+
+- Le standard cible imprime-t-il Balance Sheet et Income Statement ou seulement
+  les expose-t-il en vues UI?
+- Le standard cible supporte-t-il une devise seconde stockee sur toutes les
+  move lines?
+- Le standard cible versionne-t-il les PDFs de facture?
+- Les reports alternatifs facture partagent-ils le meme `report_name`?
+- Les fees et PnL doivent-ils alimenter la comptabilite generale ou seulement
+  le reporting de gestion?
+- La revaluation FX doit-elle etre ligne par ligne, globale, ou les deux?
diff --git a/notes/accounting/gap_analysis_workflow.md b/notes/accounting/gap_analysis_workflow.md
new file mode 100644
index 0000000..e20783b
--- /dev/null
+++ b/notes/accounting/gap_analysis_workflow.md
@@ -0,0 +1,137 @@
+# Accounting Report Gap Analysis Workflow
+
+Date: 2026-05-05
+Purpose: reusable method for comparing Tradon/Tryton accounting reports with an
+external target standard.
+
+## Scope
+
+Use this workflow when comparing one accounting report at a time, for example
+General Ledger, Trial Balance, Aged Balance, Balance Sheet, Income Statement, or
+tax reports.
+
+The first completed example is:
+
+- `general_ledger_gap_analysis.md`
+
+## Source Priority
+
+Read sources in this order:
+
+1. Root `AGENTS.md`.
+2. `notes/accounting/README.md`.
+3. Existing accounting notes, especially `reporting.md`,
+   `business_rules.md`, and `comparison_checklist.md`.
+4. Target standard report definition.
+5. Target standard shared docs, such as reporting standards, parameter rules,
+   and field catalogues.
+6. Tradon/Tryton report code, views, models, templates, and tests.
+
+If the target standard lives outside this repository, request filesystem access
+when needed and keep the resulting notes inside `notes/accounting/`.
+
+## Extraction Steps
+
+1. Identify the target report code and file.
+   - Example: `GL-001 General Ledger`.
+2. Read the target report definition completely.
+3. Read shared target docs that define common rules:
+   - parameters;
+   - fields;
+   - sorting;
+   - grouping;
+   - totals;
+   - exports;
+   - audit controls.
+4. Locate the corresponding Tradon/Tryton implementation with `rg`:
+   - `ir.action.report`;
+   - `ir.action.act_window`;
+   - `context_model`;
+   - report model names;
+   - `Report` classes;
+   - `ModelSQL.table_query()`;
+   - XML views;
+   - `.fodt` templates.
+5. Map parameters and filters.
+6. Map sorting, grouping, and balance logic.
+7. Map output columns field by field.
+8. Compare calculation rules:
+   - debit/credit sign convention;
+   - opening balance;
+   - closing balance;
+   - running balance;
+   - transaction currency;
+   - base currency;
+   - posted/draft behavior.
+9. Compare export behavior:
+   - UI view;
+   - PDF/ODT;
+   - CSV;
+   - XLSX;
+   - audit-ready flat extract.
+10. Compare controls and reconciliation expectations.
+11. Record open questions separately from confirmed gaps.
+
+## Gap Classification
+
+Use these labels consistently:
+
+- `Covered`: current Tradon/Tryton behavior matches the target.
+- `Partial`: current behavior exists but is incomplete or presented differently.
+- `Gap`: target behavior is missing.
+- `Different model`: both systems answer a similar need with different concepts.
+- `Open question`: source evidence is not enough yet.
+
+For priority, use:
+
+- `High`: blocks audit, statutory reporting, reconciliation, or standard export.
+- `Medium`: important reporting difference, but workaround exists.
+- `Low`: presentation or convenience difference.
+- `Trade-specific`: related to `purchase_trade` or commodity business rules.
+
+## Output File Template
+
+Create one file per report:
+
+`notes/accounting/<report_name>_gap_analysis.md`
+
+Recommended sections:
+
+1. Executive summary.
+2. Sources read.
+3. Target report requirements.
+4. Current Tradon/Tryton behavior.
+5. Parameter and filter gaps.
+6. Sorting and grouping gaps.
+7. Column mapping.
+8. Calculation and currency gaps.
+9. Export and audit gaps.
+10. Controls and reconciliation gaps.
+11. Prioritized gaps.
+12. Open questions.
+
+## General Ledger Lessons Learned
+
+For the first General Ledger comparison:
+
+- Tryton exposes an account summary with drill-down lines, while the target
+  standard expects a flat audit/export report.
+- Tryton has date, period, fiscal year, company, posted, and journal filters,
+  but the target also requires explicit account range, currency, entity,
+  document, and voucher filters.
+- Tryton carries second currency as `amount_second_currency`, but the target
+  requires debit, credit, and balance in transaction currency plus base currency.
+- Tryton computes running balance by account, with optional party cumulation,
+  while the target requires account plus transaction currency grouping.
+- The target expects opening and closing rows per account plus transaction
+  currency.
+- Audit metadata and export-oriented columns must be normalized explicitly.
+
+## Maintenance Rule
+
+After completing each report comparison:
+
+1. Add the new analysis file to `notes/accounting/README.md`.
+2. Add any reusable checklist item to `comparison_checklist.md`.
+3. Keep report-specific conclusions in the report gap file, not in `AGENTS.md`.
+4. Keep `AGENTS.md` pointing only to the accounting index and workflow.
diff --git a/notes/accounting/general_ledger_gap_analysis.md b/notes/accounting/general_ledger_gap_analysis.md
new file mode 100644
index 0000000..293568b
--- /dev/null
+++ b/notes/accounting/general_ledger_gap_analysis.md
@@ -0,0 +1,292 @@
+# General Ledger Gap Analysis
+
+Date: 2026-05-05
+
+Comparison scope:
+
+- Ideal target: `C:/DataS/OpenSquared/Tradon/Source/Accounting_report/accounting_report/Reports/GL/GL_001_general_ledger.md`
+- Standards: `Docs/reporting_standards.md`, `Docs/reporting_parameters.md`,
+  `Docs/reporting_fields_catalog.md`
+- Current Tryton/Tradon source:
+  - `modules/account/account.py`
+  - `modules/account/account.xml`
+  - `modules/account/view/general_ledger_account_list.xml`
+  - `modules/account/view/general_ledger_line_list.xml`
+  - `notes/accounting/reporting.md`
+
+## 1. Executive Summary
+
+Tryton already has a strong General Ledger foundation:
+
+- account-level opening, movement and closing balances;
+- date or period filtering;
+- journal filtering;
+- posted-only option;
+- drill-down from accounts to detailed move lines;
+- running balance at line level;
+- party drill-down for party-required accounts.
+
+The main gap is that the ideal `GL-001` is specified as a complete detail
+report, grouped by account and transaction currency, with explicit opening and
+closing rows and a rich audit column set. Tryton's current standard General
+Ledger is split between:
+
+- an account summary view/report (`account.general_ledger.account`);
+- a line drill-down view (`account.general_ledger.line`).
+
+It does not expose the ideal output as one flat, export-ready report.
+
+## 2. Parameters
+
+### Covered by Tryton
+
+Ideal parameter | Tryton current support
+--- | ---
+`date_from` | supported as `from_date`
+`date_to` | supported as `to_date`
+`journal` | supported in `account.general_ledger.account.context`
+`entity` | supported through current `company` context
+
+### Partial or missing
+
+Ideal parameter | Gap
+--- | ---
+`account` | Tryton opens all non-closed typed accounts in the GL account view; account selection is possible via UI/domain/drill-down, but not a first-class explicit report parameter in the context model.
+`currency` | missing as an explicit GL parameter. Tryton exposes company currency and line `second_currency`, but the GL context has no transaction-currency filter.
+`entity` | supported as current company, but no explicit multi-entity selector. This may be acceptable because the ideal spec says current entity unless ERP supports more.
+`document number or voucher number` | not a first-class filter in the General Ledger context.
+
+Out-of-scope ideal parameters (`counterparty`, `analytic_account`,
+`profit_center`) are also not part of the current Tryton GL context. That aligns
+with the ideal scope, except party drill-down exists as an extra Tryton feature.
+
+## 3. Filtering Gaps
+
+Ideal filter | Tryton status
+--- | ---
+Posting date between `date_from` and `date_to` | covered via `from_date` / `to_date`, though Tryton also supports period range.
+Account or account range | partial. Account range is not visible as a standard context parameter.
+Currency | gap. No explicit transaction-currency filter.
+Journal | covered.
+Entity | covered by company context, not explicit user-facing parameter.
+Document/voucher number | gap in context; can likely be searched on line/move fields, but not a report parameter.
+Posted/non-posted scope | Tryton supports `posted` boolean; ideal treats `posting_status` as output information, not default filter.
+
+## 4. Sorting Gaps
+
+Ideal default sorting:
+
+1. account
+2. transaction currency
+3. posting date
+4. document number
+
+Tryton current behavior:
+
+- `account.general_ledger.account` sorts by account.
+- `account.general_ledger.line` sorts by date ascending.
+- running balance window orders by `move.date`, then line id.
+
+Gaps:
+
+- no primary transaction-currency sort;
+- no document-number sort in default GL line ordering;
+- account grouping happens one level above the line view, not as a single flat
+  ordered export;
+- document number is not clearly mapped to `move.number` vs `move.post_number`.
+
+## 5. Grouping and Balance Presentation
+
+Ideal:
+
+- group by account and transaction currency;
+- display opening balance row per account/currency;
+- display detailed movement lines;
+- display closing balance row per account/currency;
+- show balances in both transaction currency and base currency;
+- calculate running balances line by line.
+
+Tryton:
+
+- account summary has `start_balance`, `debit`, `credit`, `end_balance`;
+- line view has `debit`, `credit`, `amount_second_currency`, `balance`;
+- line running balance exists in base currency via `internal_balance` plus
+  start balance;
+- no explicit opening/closing rows in the line report;
+- no grouped transaction-currency balance presentation;
+- second currency amount is a single signed amount, not split debit/credit and
+  running balance.
+
+Gaps:
+
+- missing account/currency opening and closing rows;
+- missing transaction-currency running balance;
+- missing debit/credit split in transaction currency;
+- missing transaction-currency totals;
+- current printable General Ledger is account-driven, not the full ideal
+  detailed layout.
+
+## 6. Output Column Gaps
+
+### Covered or mostly mappable
+
+Ideal column | Tryton source candidate
+--- | ---
+`entity` | `company`
+`account` | `account.account.code` via ledger account
+`account_name` | `account.account.name`
+`base_currency` | company currency
+`posting_date` | `account.move.date` / line date
+`journal` | `account.move.journal`
+`journal_entry_number` | likely `account.move.number` or `post_number`
+`document_number` | likely `account.move.number` or invoice number depending definition
+`posting_status` | `account.move.state`
+`counterparty` | `account.move.line.party`
+`description` | line `description_used` / move description
+`reference` | move `origin`, `ext_ref`, invoice reference depending mapping
+`debit_base_currency` | line `debit`
+`credit_base_currency` | line `credit`
+`balance_base_currency` | line `balance`
+`entered_date` | line/move `create_date`
+`modified_date` | line/move `write_date`
+
+### Gaps or mapping questions
+
+Ideal column | Gap
+--- | ---
+`transaction_currency` | Tryton has `second_currency`, but base-currency lines may have no transaction currency. Need convention: use `second_currency` else company currency?
+`document_date` | not exposed in current GL line view. Could map to invoice date for invoice origins, move date otherwise.
+`document_type` | not exposed. Needs mapping from origin model or journal/type.
+`supplier_invoice_number` | not exposed. Could map to supplier invoice `reference` for AP invoice origins, but requires origin-specific logic.
+`voucher_number` | not exposed; need decide whether `move.number`, `post_number`, `ext_ref` or another internal ref is voucher.
+`payable_qty` | not in standard GL. Tradon may map from lot/invoice/fee/trade links on move lines, but requires custom logic.
+`uom` | same as payable quantity.
+`debit_transaction_currency` | missing as explicit split; Tryton stores signed `amount_second_currency`.
+`credit_transaction_currency` | missing as explicit split.
+`balance_transaction_currency` | missing as running balance.
+`entered_by` | not exposed in GL view; can be mapped from `create_uid`.
+`modified_by` | not exposed in GL view; can be mapped from `write_uid`.
+
+## 7. Sign Convention Gaps
+
+Ideal GL convention:
+
+- debit amounts positive;
+- credit amounts negative;
+- running balances use debit-positive and credit-negative convention.
+
+Tryton:
+
+- base debit and credit are stored/displayed as positive numeric columns;
+- balance uses `debit - credit`;
+- second currency is signed in `amount_second_currency`.
+
+Gaps:
+
+- ideal asks `credit_transaction_currency` and `credit_base_currency` as
+  negative amounts, but Tryton displays credit column as positive amount;
+- need decide whether exports should preserve Tryton UI convention or transform
+  credits to negative for the ideal GL layout.
+
+## 8. Audit Trail Gaps
+
+Ideal requires enough audit references to trace:
+
+- accounting document;
+- source document;
+- AP supplier invoice number when available;
+- creation/modification user and dates.
+
+Tryton has the raw ingredients:
+
+- move;
+- line origin;
+- move origin;
+- invoice origin in many generated flows;
+- `create_uid`, `create_date`, `write_uid`, `write_date`.
+
+But current GL output does not expose:
+
+- source document number/date/type in normalized columns;
+- supplier invoice number;
+- entered/modified user labels;
+- voucher/reference mapping;
+- payable quantity/uom for commodity postings.
+
+## 9. Export Gaps
+
+Ideal:
+
+- CSV;
+- XLSX;
+- PDF including all detail columns.
+
+Tryton:
+
+- standard UI list export may cover CSV-like exports depending client;
+- printable report is `.fodt` -> usually PDF/ODT;
+- the standard PDF is not designed to include all ideal detail columns;
+- no dedicated XLSX export is identified for General Ledger.
+
+Gaps:
+
+- dedicated XLSX export;
+- wide detailed PDF;
+- one export-ready flat GL dataset.
+
+## 10. Controls and Reconciliation
+
+Ideal controls:
+
+- debit/credit reconcile by selected period, account and transaction currency;
+- opening + movements = closing by account/currency;
+- base total reconciles with trial balance;
+- line audit references preserved.
+
+Tryton:
+
+- move posting enforces balanced moves in company currency;
+- GL account start/debit/credit/end balances support reconciliation in base
+  currency;
+- Trial Balance reuses the same account model, which helps base-currency
+  reconciliation.
+
+Gaps:
+
+- transaction-currency reconciliation by account/currency is not explicit;
+- opening/movement/closing by transaction currency not implemented in current
+  GL model;
+- audit reference completeness depends on origin mapping not present in GL
+  report.
+
+## 11. Prioritized Gaps
+
+Priority | Gap
+--- | ---
+High | Build or expose a flat detailed GL dataset matching `GL-001`, not only account summary + drill-down.
+High | Add transaction currency grouping/filtering and running balances.
+High | Add opening and closing rows by account and transaction currency.
+High | Define mapping for `document_number`, `journal_entry_number`, `voucher_number`, `reference`.
+High | Normalize source document metadata: document type, document date, supplier invoice number.
+Medium | Split `amount_second_currency` into debit/credit transaction-currency columns.
+Medium | Decide and implement GL sign convention transformation for credit columns.
+Medium | Add audit columns `entered_by`, `entered_date`, `modified_by`, `modified_date`.
+Medium | Add dedicated CSV/XLSX export target.
+Low/Trade-specific | Add `payable_qty` and `uom` for commodity-related postings, probably using Tradon lot/invoice/fee links.
+
+## 12. Open Questions
+
+- In Tryton mapping, should `document_number` be `account.move.number`,
+  `account.move.post_number`, invoice `number`, or a context-dependent value?
+- Should `journal_entry_number` be `move.number` and `document_number` be the
+  business document number?
+- Is `voucher_number` distinct in Tradon, or should it remain blank?
+- Should `transaction_currency` default to company currency when
+  `second_currency` is empty?
+- Should credit columns be exported as negative values to match the ideal GL,
+  even though Tryton UI displays credit as positive?
+- Which origin models should feed `document_date` and `document_type` in the
+  first implementation?
+- Can payable quantity/uom be derived reliably from `account.move.line.lot`,
+  `fee`, or invoice line origin for all commodity postings?
+
diff --git a/notes/accounting/modules_inventory.md b/notes/accounting/modules_inventory.md
new file mode 100644
index 0000000..6557ee1
--- /dev/null
+++ b/notes/accounting/modules_inventory.md
@@ -0,0 +1,173 @@
+# Accounting Modules Inventory
+
+Date: 2026-05-05
+
+## Modules coeur
+
+### `account`
+
+Module socle comptable.
+
+Fonctionnalites principales:
+
+- plan comptable: `account.account`, `account.account.type`;
+- templates de plan comptable et creation/mise a jour de chart;
+- exercices, periodes et journaux;
+- ecritures: `account.move`, `account.move.line`;
+- lettrage/reconciliation;
+- taxes et lignes de taxes;
+- reporting standard: balance sheet, income statement, general ledger, trial
+  balance, aged balance.
+
+Fichiers pivots:
+
+- `modules/account/account.py`
+- `modules/account/move.py`
+- `modules/account/tax.py`
+- `modules/account/fiscalyear.py`
+- `modules/account/journal.py`
+- `modules/account/account.xml`
+- `modules/account/move.xml`
+- `modules/account/tax.xml`
+
+### `account_invoice`
+
+Module facturation client/fournisseur.
+
+Fonctionnalites principales:
+
+- factures `account.invoice`;
+- lignes `account.invoice.line`;
+- taxes de facture `account.invoice.tax`;
+- workflow facture: draft, validated, posted, paid, cancelled;
+- generation de `account.move`;
+- echeances et `lines_to_pay`;
+- paiement direct via `account.invoice.pay`;
+- credit note/debit note via wizard `account.invoice.credit`;
+- reports facture FODT.
+
+Fichiers pivots:
+
+- `modules/account_invoice/invoice.py`
+- `modules/account_invoice/invoice.xml`
+- `modules/account_invoice/payment_term.py`
+- `modules/account_invoice/payment_term.xml`
+
+### `account_product`
+
+Pont comptabilite/produits.
+
+Fonctionnalites principales:
+
+- comptes de revenu/depense/stock par produit ou categorie;
+- configuration comptable par produit;
+- base pour la generation des lignes comptables depuis facture, stock et frais.
+
+### `account_payment`
+
+Paiements generiques.
+
+Fonctionnalites principales:
+
+- journaux de paiement;
+- paiements entrants/sortants;
+- groupes de paiement;
+- workflow: draft, submitted, approved, processing, succeeded, failed;
+- integrations optionnelles SEPA, Stripe, Braintree, clearing.
+
+### `account_statement`
+
+Releves bancaires/caisse.
+
+Fonctionnalites principales:
+
+- statements et lignes de statement;
+- imports OFX/MT940/CODA/AEB43/SEPA via modules specialises;
+- validation du solde, generation de mouvements, posting et reconciliation;
+- report imprimable `account.statement`.
+
+### `account_asset`
+
+Immobilisations.
+
+Fonctionnalites principales:
+
+- actifs, lignes d'amortissement;
+- lien avec produits et factures;
+- generation d'ecritures d'amortissement.
+
+### `account_budget`
+
+Budgets comptables.
+
+Fonctionnalites principales:
+
+- budgets par compte/periode;
+- suivi budget vs realise.
+
+## Modules taxes et localisation
+
+Modules de localisation ou regles fiscales:
+
+- `account_be`, `account_ch`, `account_ch_os`, `account_de_skr03`,
+  `account_es`, `account_fr`, `account_ict`, `account_itsa`,
+  `account_syscohada`;
+- `account_eu`, `account_es_sii`, `account_fr_chorus`;
+- `account_tax_cash`, `account_tax_non_deductible`,
+  `account_tax_rule_country`.
+
+Fonction:
+
+- plans comptables localises;
+- taxes localisees;
+- codes/tax reports locaux;
+- exports ou e-documents fiscaux.
+
+Point de vigilance:
+
+- ces modules peuvent ajouter des reports fiscaux ou modifier la selection des
+  taxes, mais la base de mouvement reste `account.move` / `account.move.line`.
+
+## Modules stock/couts
+
+Modules de comptabilite stock:
+
+- `account_stock_continental`;
+- `account_stock_anglo_saxon`;
+- `account_stock_eu`;
+- `account_stock_landed_cost`;
+- `account_stock_landed_cost_weight`;
+- `account_stock_shipment_cost`;
+- `account_stock_shipment_cost_weight`.
+
+Fonction:
+
+- valorisation stock;
+- couts d'expedition;
+- landed costs;
+- generation de mouvements comptables lies aux mouvements stock.
+
+## Modules exports et auxiliaires
+
+- `account_export`, `account_export_winbooks`;
+- `account_consolidation`;
+- `account_credit_limit`;
+- `account_dunning`, `account_dunning_email`, `account_dunning_fee`,
+  `account_dunning_letter`;
+- `account_deposit`;
+- `account_cash_rounding`;
+- `account_invoice_correction`, `account_invoice_defer`,
+  `account_invoice_history`, `account_invoice_line_standalone`,
+  `account_invoice_secondary_unit`, `account_invoice_stock`,
+  `account_invoice_watermark`;
+- `account_move_line_grouping`;
+- `account_receivable_rule`, `account_rule`;
+- `account_payment_clearing`, `account_payment_sepa`,
+  `account_payment_sepa_cfonb`, `account_payment_stripe`,
+  `account_payment_braintree`;
+- `account_statement_rule`, `account_statement_*`.
+
+Fonction:
+
+- extensions de comportement ou d'integration autour des flux standards.
+
diff --git a/notes/accounting/purchase_trade_extensions.md b/notes/accounting/purchase_trade_extensions.md
new file mode 100644
index 0000000..07e7869
--- /dev/null
+++ b/notes/accounting/purchase_trade_extensions.md
@@ -0,0 +1,167 @@
+# Purchase Trade Accounting Extensions
+
+Date: 2026-05-05
+
+## 1. Extensions de `account.invoice`
+
+Source: `modules/purchase_trade/invoice.py`.
+
+### Padding comptable
+
+- `do_lot_invoicing()` appelle `_create_sale_padding_moves()`.
+- `_post()` poste aussi les additional moves de padding.
+- Deux descriptions identifient les moves:
+  - `Sale padding accrual`;
+  - `Sale padding reversal`.
+- Les comptes viennent de `account.configuration`:
+  - `default_sale_padding_account`;
+  - `default_accrual_padding_account`.
+- Provisoire vente:
+  - debit sale padding;
+  - credit accrual padding.
+- Finale vente:
+  - debit accrual padding;
+  - credit sale padding.
+- Montant:
+  - `lot.sale_invoice_padding * provisional_invoice_line.unit_price`;
+  - conversion devise via `invoice.rate` si present, sinon `Currency.compute`.
+- Les move lines portent:
+  - `lot`;
+  - `origin = invoice_line`;
+  - `description = Padding`;
+  - party si le compte l'exige.
+
+### Proprietes `report_*`
+
+Le module expose un pont facture -> vente/achat/lot/shipment:
+
+- parties/adresses;
+- contrat;
+- produit;
+- quantites, poids, bales;
+- prix et prix en lettres;
+- BL, vessel, ports, controller, S/I;
+- pro forma liee au lot;
+- freight amount depuis fee shipment `Maritime freight`;
+- payment order.
+
+Regle de conception:
+
+- la logique business reste en Python;
+- les `.fodt` consomment des proprietes simples.
+
+## 2. Extensions de `account.invoice.line`
+
+Sources: `modules/purchase_trade/invoice.py`, `stock.py`.
+
+- Champ `lot` sur `account.invoice.line`.
+- Champ `fee` sur `account.invoice.line`.
+- Champ fonctionnel `included_padding`, affiche `lot.sale_invoice_padding`.
+- Proprietes `report_*` au niveau ligne:
+  - product name/description;
+  - rate currency/value/unit;
+  - crop/attributes;
+  - net/lbs.
+
+## 3. Extensions de `account.move` et `account.move.line`
+
+Source: `modules/purchase_trade/stock.py`.
+
+### Move Line
+
+- `revaluate`: lien vers ligne revaluee;
+- `lot`: rattachement lot;
+- `fee`: rattachement fee.
+
+Utilite:
+
+- audit par lot/fee;
+- revaluation FX detaillee;
+- reporting PnL et couts.
+
+### Move
+
+- `IsBankMove()` detecte un move bancaire si une ligne utilise un compte de
+  payment method debit/credit.
+
+## 4. Extensions de `account.account`
+
+Source: `modules/purchase_trade/stock.py`.
+
+- Detection des devises secondes ouvertes par compte.
+- Recuperation des lignes par devise.
+- Revaluation FX par compte:
+  - detaillee ligne par ligne si `fx_eval_detail`;
+  - globale par devise sinon.
+
+Source standard modifiee observee: `modules/account/account.py`.
+
+- Champs:
+  - `fx_eval`;
+  - `fx_eval_detail`;
+  - `currency_exchange_credit_account`;
+  - `currency_exchange_debit_account`.
+
+## 5. Extensions de configuration comptable
+
+Source: `modules/purchase_trade/configuration.py`.
+
+Ajouts sur `account.configuration`:
+
+- `default_sale_padding_account`;
+- `default_accrual_padding_account`;
+- templates de documents facture/vente/achat/shipment;
+- resolution dynamique des templates via `purchase_trade.configuration`.
+
+## 6. Fees et comptabilite
+
+Source: `modules/purchase_trade/fee.py`.
+
+- `fee.fee` peut retrouver son invoice.
+- Les fees calculent quantity/amount selon mode:
+  - lumpsum;
+  - per quantity;
+  - percent price/cost;
+  - rate selon regle ACT/360.
+- `_get_account_move_fee()` cree des moves de fee lies a un lot.
+- Les comptes utilises viennent du produit fee:
+  - stock/COGS/stock in/stock out selon flux.
+- Les move lines peuvent porter lot et fee.
+
+Regles recentes:
+
+- `% rate` utilise `fin_int_delta`, pas la date du jour.
+- Les fees suivent les lots effectifs:
+  - virtuel si aucun physique;
+  - physiques des qu'ils existent.
+
+## 7. Forex
+
+Source: `modules/purchase_trade/forex.py`.
+
+- `forex.forex` porte achat/vente devise, montant, rate, bank, maturity.
+- Peut creer:
+  - facture fournisseur de frais;
+  - move comptable;
+  - lignes de couverture achat/vente physique.
+- Reporting BI via `forex.bi`.
+
+## 8. Payment terms
+
+Source: `modules/purchase_trade/payment_term.py`.
+
+Extensions:
+
+- `account.invoice.payment_term.is_mixed`;
+- lignes de term avec:
+  - `trigger_event`;
+  - `term_type`;
+  - `trigger_offset`;
+  - unite d'offset;
+  - EOM flag/mode;
+  - risk classification.
+
+Impact:
+
+- utile pour credit risk, maturity date, bills et conditions trade.
+
diff --git a/notes/accounting/reporting.md b/notes/accounting/reporting.md
new file mode 100644
index 0000000..d2f42aa
--- /dev/null
+++ b/notes/accounting/reporting.md
@@ -0,0 +1,484 @@
+# Accounting Reporting Map
+
+Date: 2026-05-05
+
+## 1. Typologie du reporting
+
+Le repository contient quatre familles de reporting comptable:
+
+1. Reports imprimables standards:
+   - `ir.action.report`;
+   - classe Python `Report`;
+   - template `.fodt`.
+2. Reporting UI SQL:
+   - modeles `ModelSQL, ModelView`;
+   - `table_query()`;
+   - `ir.action.act_window` avec `context_model`.
+3. Documents business lies a la comptabilite:
+   - factures, prepayments, CN/DN, payment order, packing list;
+   - resolution dynamique des templates via `purchase_trade.configuration`.
+4. Reporting de gestion Tradon:
+   - PnL, valuation, fees, credit risk, forex, invoice padding, dashboards.
+
+Pour une comparaison avec un standard, il faut donc comparer a la fois les
+rapports imprimables et les vues SQL qui servent de reporting operationnel.
+
+## 2. Reporting standard `account`
+
+### Statement par type de compte
+
+- Action: `report_account_type_statement`
+- Model: `account.account.type`
+- Report name: `account.account.type.statement`
+- Template: `account/type_statement.fodt`
+- Source Python: `AccountTypeStatement`
+
+But:
+
+- imprimer un etat par type de compte;
+- utilise les montants calcules des account types.
+
+### General Ledger
+
+- Action report: `report_general_ledger`
+- Model report: `account.general_ledger.account`
+- Report name: `account.general_ledger`
+- Template: `account/general_ledger.fodt`
+- Action UI: `act_general_ledger_account_form`
+- Context model: `account.general_ledger.account.context`
+- Lignes: `account.general_ledger.line`
+
+Filtres/contexte:
+
+- fiscal year obligatoire;
+- start/end period ou from/to date, mutuellement exclusifs;
+- company;
+- posted only;
+- journal optionnel.
+
+Regles de calcul:
+
+- `account.general_ledger.account` part des comptes non fermes avec type;
+- les montants de debut utilisent les periodes/dates avant la borne de debut;
+- les mouvements de la periode sont calcules par difference entre debut et fin;
+- `line_count != 0` filtre les comptes affiches dans l'action principale;
+- une vue par party existe via `account.general_ledger.account.party`;
+- le drill-down ouvre `account.general_ledger.line`.
+
+Points de comparaison standard:
+
+- presence des colonnes start debit/credit, debit/credit, end debit/credit,
+  start/end balance;
+- support du filtre journal;
+- support posted only;
+- drill-down compte -> party -> lignes.
+
+### Trial Balance
+
+- Action report: `report_trial_balance`
+- Model report: `account.general_ledger.account`
+- Report name: `account.trial_balance`
+- Template: `account/trial_balance.fodt`
+- Source Python: `TrialBalance`
+
+Regles:
+
+- reutilise le modele de Grand Livre;
+- expose les cumuls via fonctions `sum`;
+- depend du meme contexte que le Grand Livre.
+
+Points de comparaison standard:
+
+- verifier les totaux debit/credit;
+- verifier traitement des comptes sans mouvement;
+- verifier posted only et bornes periode/date.
+
+### Balance Sheet
+
+- Action UI: `act_account_balance_sheet_tree`
+- Model: `account.account.type`
+- Context: `account.balance_sheet.comparison.context`
+- Pas de `ir.action.report` dedie dans le XML standard observe.
+
+Filtres/contexte:
+
+- date;
+- company;
+- posted only;
+- option comparison;
+- date comparaison par defaut = date - 1 an.
+
+Regles:
+
+- affiche les account types selon leur categorie de bilan;
+- montants calcules a la date;
+- comparaison optionnelle.
+
+Point important:
+
+- c'est une vue UI analytique, pas un report FODT standard dans ce module.
+
+### Income Statement
+
+- Action UI: `act_account_income_statement_tree`
+- Model: `account.account.type`
+- Context: `account.income_statement.context`
+
+Filtres/contexte:
+
+- fiscal year;
+- start/end period ou from/to date;
+- company;
+- posted only;
+- comparison optionnelle avec fiscal year/periodes/dates de comparaison.
+
+Regles:
+
+- affiche les account types de resultat;
+- calcule sur intervalle, pas seulement a date;
+- comparaison optionnelle.
+
+### Aged Balance
+
+- Action UI: `act_aged_balance_list`
+- Action report: `report_aged_balance`
+- Model: `account.aged_balance`
+- Context: `account.aged_balance.context`
+- Report name: `account.aged_balance`
+- Template: `account/aged_balance.fodt`
+
+Filtres/contexte:
+
+- type: customers, suppliers, customers and suppliers;
+- date;
+- termes 1/2/3;
+- unite: day, week, month, year;
+- company;
+- posted only;
+- currency;
+- detail.
+
+Regles de calcul:
+
+- source: `account.move.line` joint a `account.move`, `account.account`,
+  `account.account.type`, reconciliation et company;
+- inclut les lignes avec party;
+- inclut les comptes receivable/payable selon type demande;
+- exclut les lignes reconciliees avant ou a la date, garde celles non
+  reconciliees ou reconciliees apres la date;
+- utilise `maturity_date`, sinon `move.date`;
+- en mode detail, groupe par `move.origin`;
+- calcule `balance` en devise societe et `balance_curr` en devise seconde;
+- peut filtrer par devise.
+
+Points de comparaison standard:
+
+- definition des buckets;
+- traitement de reconciliation apres date;
+- source maturity date vs move date;
+- detail par origine;
+- devise seconde.
+
+## 3. Reporting standard `account_invoice`
+
+### Invoice
+
+- Action: `report_invoice`
+- Model: `account.invoice`
+- Report name: `account.invoice`
+- Template: `account_invoice/invoice.fodt`
+- Classe: `InvoiceReport`
+
+Regles:
+
+- report single;
+- rendu en contexte `address_with_party=True`;
+- cache possible via `invoice_report_cache` uniquement pour le template standard
+  `account_invoice/invoice.fodt`;
+- revisions conservees dans `account.invoice.report.revision`;
+- contexte expose `invoice`, `record`, `today`.
+
+### Prepayment
+
+- Action: `report_prepayment`
+- Model: `account.invoice`
+- Report name: `account.invoice`
+- Template: `account_invoice/prepayment.fodt`
+
+Point important:
+
+- utilise le meme report name que la facture; dans ce repository,
+  `purchase_trade` evite que le cache standard masque le template alternatif.
+
+### CN/DN
+
+- Action: `report_invoice_ict_final`
+- Model: `account.invoice`
+- Report name: `account.invoice`
+- Template: `account_invoice/invoice_ict_final.fodt`
+
+Regles locales:
+
+- cote sale/out: montant negatif = Credit Note, montant positif = Debit Note;
+- cote purchase/in: logique inverse conservee;
+- les quantites et poids suivent les regles `purchase_trade` documentees.
+
+## 4. Reporting standard `account_statement`
+
+- Report class: `StatementReport`
+- Report name: `account.statement`
+- Source: `modules/account_statement/statement.py`
+
+Fonction:
+
+- impression d'un statement bancaire/caisse;
+- base operationnelle: statements, lignes, origines, moves generes.
+
+Points de comparaison:
+
+- formats d'import supportes par modules `account_statement_*`;
+- validations solde/montant/nombre de lignes;
+- reconciliation apres posting.
+
+## 5. Reporting fiscal/localisation
+
+Modules pertinents:
+
+- `account_es`: `reporting_tax.xml`, SII via `account_es_sii`;
+- `account_fr_chorus`: e-document Chorus;
+- `account_eu`: taxes/operations UE;
+- `account_tax_cash`: cash basis tax groups;
+- `account_export`, `account_export_winbooks`: exports comptables.
+
+Comparaison:
+
+- ces modules doivent etre compares pays par pays;
+- ne pas les melanger avec le reporting financier general.
+
+## 6. Reporting comptable `purchase_trade`
+
+### Dynamic Document Templates
+
+Source: `modules/purchase_trade/invoice.py`, `configuration.py`.
+
+Mecanisme:
+
+- `ReportTemplateMixin` intercepte `_execute`;
+- le chemin du template est resolu depuis `purchase_trade.configuration`;
+- si le champ est vide, erreur explicite `No template found`;
+- si le champ ne contient pas `/`, prefixe automatique:
+  `account_invoice/`, `sale/`, `purchase/`, `stock/`.
+
+Facture:
+
+- Invoice standard -> `invoice_report_template`;
+- Prepayment -> `invoice_prepayment_report_template`;
+- CN/DN -> `invoice_cndn_report_template`;
+- Payment Order -> `invoice_payment_order_report_template`;
+- Packing List -> `invoice_packing_list_report_template`.
+
+Vente:
+
+- Sale -> `sale_report_template`;
+- Bill -> `sale_bill_report_template`;
+- Sale final -> `sale_final_report_template`.
+
+Achat:
+
+- Purchase -> `purchase_report_template`.
+
+Shipment:
+
+- Shipping -> `shipment_shipping_report_template`;
+- Insurance -> `shipment_insurance_report_template`;
+- Packing List -> `shipment_packing_list_report_template`;
+- COO -> `shipment_coo_report_template`.
+
+Point de comparaison standard:
+
+- un standard Tryton a des actions report statiques; Tradon a une resolution de
+  template configurable par action.
+
+### Documents facture ajoutes
+
+Actions:
+
+- `report_invoice_packing_list`
+  - model `account.invoice`;
+  - report name `account.invoice`;
+  - template `account_invoice/packing_list.fodt`.
+- `report_payment_order`
+  - model `account.invoice`;
+  - report name `account.invoice`;
+  - template `account_invoice/payment_order.fodt`.
+
+Regles:
+
+- les deux passent par le meme moteur `account.invoice`;
+- ils doivent bypasser le cache standard de facture;
+- ils utilisent des proprietes Python `report_*`.
+
+### Invoice Padding Report
+
+- Model: `invoice.padding.report`
+- Context: `invoice.padding.context`
+- Source: `modules/purchase_trade/invoice.py`
+
+Champs:
+
+- party, sale, sale line, lot, product, currency, unit;
+- padding quantity, unit price, padding amount;
+- provisional invoice/date/state;
+- final invoice/date/state;
+- padding status: active/reversed.
+
+Regles de calcul:
+
+- source principale: `lot.lot.sale_invoice_padding`;
+- joint sale line, sale, invoice lines provisoire/finale et factures;
+- ne retient que les lots avec padding > 0 et facture provisoire;
+- statut reversed si facture finale existe et n'est ni draft ni cancelled;
+- filtres: date, party, currency, status, sale, lot.
+
+Utilite:
+
+- audit comptable des provisions de padding et de leur extourne.
+
+### Fee Report
+
+- Model: `fee.report`
+- Context: `fee.context`
+- Source: `modules/purchase_trade/fee.py`
+- Action UI: `Fee report`
+
+Champs:
+
+- purchase line, sale line, shipment in/out/internal;
+- type de fee, counterparty;
+- type ordered/budgeted/actual;
+- pay status PAY/REC;
+- mode;
+- quantity/unit/amount calcules depuis `fee.fee`;
+- invoice liee;
+- state invoiced/not invoiced;
+- currency/price.
+
+Regles:
+
+- vue SQL sur `fee.fee`, join purchase line/purchase;
+- filtres par counterparty, fee type, purchase, sale, shipment, dates;
+- quantity et amount recalcules par les methodes metier du fee.
+
+Point de comparaison:
+
+- ce n'est pas un rapport Tryton comptable standard; c'est un reporting de
+  charges/produits attendus et factures par contrats/lots/shipments.
+
+### Valuation / PnL
+
+- Models: `valuation.valuation`, `valuation.report`,
+  `valuation.report.context`;
+- Action UI: `Valuation`;
+- Source: `modules/purchase_trade/valuation.py`.
+
+Regles metier importantes:
+
+- couvre purchase et sale;
+- une sale non matchee doit avoir une valuation sale-first;
+- types stockes: `pur. priced`, `sale priced`, `pur. fee`, `sale fee`,
+  `derivative`, etc.;
+- MTM uniquement sur prix et derivatives, jamais sur fees;
+- lots ouverts finis ignores selon `Mark as finished`, mais lots physiques et
+  derivatives restent valorises;
+- PnL fees suit les lots effectifs: virtuel tant qu'il n'y a que lui, puis
+  physiques.
+
+Point de comparaison:
+
+- reporting de gestion/IFRS metier, pas reporting comptable general Tryton.
+
+### Invoicing Report
+
+- Model: `purchase.invoice.report` dans `purchase_trade.purchase`;
+- Action UI: `Invoicing Report`;
+- Lie aux factures, lignes de facture, paiements et moves.
+
+Utilite:
+
+- vue metier achat/facturation/paiements;
+- a comparer plutot a un reporting AP/AR operationnel qu'a un Grand Livre.
+
+### Credit Risk Overview
+
+- Model UI: `party.credit_risk_report`;
+- Report: `account_credit_risk.credit_risk_overview`;
+- Template: `credit_risk_templates.xml`;
+- Source: `modules/purchase_trade/credit_risk.py`.
+
+Regles:
+
+- calcule l'exposition via lignes `account.move.line` receivable/payable selon
+  logique metier;
+- croise limites internes, limites assurance, devises et conditions de
+  paiement.
+
+### Forex Report / FX Revaluation
+
+- Models: `forex.forex`, `forex.bi`;
+- Wizard/action: `forex.report`;
+- Source: `modules/purchase_trade/forex.py`;
+- Revaluation wizard: `account.revaluate` dans `purchase_trade.stock`.
+
+Regles:
+
+- les contrats forex peuvent creer une facture fournisseur de frais et/ou un
+  move comptable;
+- les comptes avec `fx_eval` sont revalues;
+- mode detail: revaluation ligne par ligne avec lien `account.move.line.revaluate`;
+- mode global: revaluation par devise;
+- comptes de change et journal depuis `account.configuration`.
+
+### Physical Trade IFRS Adjustment
+
+- Model: `account.physical_trade_ifrs`;
+- Action: `Physical Trade - IFRS Adjustment`;
+- Source: `modules/purchase_trade/account.py`.
+
+Champs:
+
+- date, comment, currency, amount.
+
+Utilite:
+
+- saisie/reporting d'ajustements IFRS physiques.
+
+### Dashboard comptable
+
+Source: `modules/purchase_trade/dashboard.py`, `dashboard.xml`.
+
+Actions:
+
+- Invoices not validated -> `account.invoice`;
+- Invoices not paid -> `account.invoice`;
+- Payments not received -> `account.payment`;
+- Payments not done -> `account.payment`.
+
+Utilite:
+
+- reporting operationnel temps reel, non imprimable.
+
+## 7. Ecarts structurants vs standard
+
+- `account.invoice` est fortement enrichi par des proprietes `report_*` pour
+  documents trade.
+- Plusieurs actions de facture partagent `report_name = account.invoice`;
+  le cache standard doit donc etre controle.
+- Les templates ne sont pas seulement statiques: ils sont parametrables par
+  `Document Templates`.
+- Des reports de gestion metier utilisent des vues SQL (`fee.report`,
+  `invoice.padding.report`, `valuation.report`) et non des reports FODT.
+- La devise seconde et le taux stocke sont plus presents que dans un standard
+  Tryton pur.
+- Le reporting comptable standard doit etre compare separement du reporting
+  PnL/valuation/frais, qui est propre au negoce physique.
+