tradon/notes/accounting/reporting.md

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.