# 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.