Odoo has native Analytic Accounting support through Anaytic Accounts. Documents, such as Sales Orders or Invoices, can have Analytic Accounts on them. These are carried to the GL Accounting moves, so that finantial data ends up with analytic informatin available for management analysis.
What are Analytic Accounts is a business decision, and depends on what needs to be measured. These can be Activities, Contracts, Projects, Cost Centers, etc.
However the Odoo Analytic Account support is one dimensional. In multidimensional anaytic accounting systems several Analytic Dimensions are available. Business documents are classified in each of the required dimensions.
For example, a services company could setup as Dimensions the Business Unit (BU )and the Market Segment(MS). A particular Invoice could regard BU "SaaS" and MS "Retailers".
The feature adds multidimension analytic accounting to Odoo, by leveraging the already Analytic Account existing features. For reference, a different approach, independent from Analytic Accounts, is proposed in the PR: OCA/server-tools#275
The end user experience would be like this:
- On a Document, such as a Sales order or Invoice, with an empty Analytic Account field, an "Edit Dimensions" button/link is available.
- The "Edit Dimensions" opens a form, with several fields to select Dimension values. Example:
- Dimension 1 (Business Unit): set to "BU2"
- Dimension 2 (Market Segment): set to "MS1"
- The "Edit Dimensions" form creates a new Analytic Account for this combination (even this combination already exists) and assigns it to the Document.
- The Document's Analytic Account field now displays the Dimension Combination name "BU2.MS1"
- The "Edit Dimensions" button/link still opens the form for the Analytic for the Combination created, and allows to edit it. No side effects on other documents since this analytic combination is uniquely connected to this Document.
Reuses the existing Model "analytic_id", or equivalent, fields, so that the feature is immediately available from wherever an Analytic Account is used. Since the Dimension Combinations are just regular Analytic Accounts, they are also naturally handled by the existing business logic that takes care of carrying the Analytic Account between trecords and transactions. Dimension Values can be easily made available directly on Documents using Realated fields.
The Dimensions and their Combinations make use of a specific organization of the Analytic Account tree:
Anaytic Root
|__ DIM1: Business Unit
| |__ BU1
| |__ BU2
|__ DIM2: Market Segment
| |__ MS1
| |__ MS2
|__ DIM3: ...
|
|_ COMBINATIONS: (dynamically feeded from new documents)
|__ ...
|__ Id 234 = BU2.MS1
|__ Id 235 = BU1.MS2
|__ Id 236 = BU2.MS1
|__ ...
- analytic.account data:
- Create 5 records for Analytic Dimension Roots
- Create a record for the Dimension Combinations root
- analytic.account model:
- Add 5 dimension fields, with the appropriate domain filter (child_of corresponding dimension root)
- "Edit Combination" Action, detects the Analytic Account Many2one field and opening the form for the value (possibly new).
- "Edit Combination" Form (a wizard?), with the 5 fields available. In the future support validation logic (see roadmap).
- ORM inject the "Edit Combination" button/link. Two possible approaches:
- Ir.Values ibjects "More" option in all models (see https://github.com/OCA/project/blob/8.0/project_model_to_task/action.py)
- fields_view_get (monkey patched) injects link/button on forms
- Add multi-dimension analytic view fot G/L moves
- Dimension Combination validations: setup per domain allowed and forbidden combinations.
- Required Dimensions: setup per domain required Dimensions to be provided.
- Dimension Values inheritance: Documents inherit default Dimension values from related entities, such as Partners, Products, Contracts/Projects.
@dreispt, how would MS1 capture the cost / revenue from the combinations BUS2.MS1, XXX.MS1?