<a class="reference external image-reference" href="http://www.gnu.org/licenses/agpl-3.0-standalone.html"><img alt="License: AGPL-3" src="https://img.shields.io/badge/licence-AGPL--3-blue.svg"> </a> <a name="analytic-structure"></a> <h2>Analytic Structure</h2> <p>This module allows to use several analytic dimensions through a structure related to an object model.</p> <a name="configuration"></a> <h3>Configuration</h3> <p>In your OpenERP server's configuration file, you can set several optional parameters related to the analytic module:</p> <pre> <code>[analytic] key = value ...</code> </pre> <p>Those options must be grouped under the [analytic] category. If the category doesn't exist, add it to your configuration file.</p> <dl class="docutils"> <dt>analytic_size (default: 5)</dt> <dd>define the maximum number of analytic dimensions that can be associated with a model.</dd> <dt>translate (default: False)</dt> <dd>enable or disable the translation of field values on analytic dimensions (name) and codes (name and description).</dd> </dl> <a name="usage"></a> <h3>Usage</h3> <a name="add-the-metaanalytic-metaclass-to-a-model"></a> <h4>Add the MetaAnalytic metaclass to a model</h4> <p>At the beginning of the source file, import the MetaAnalytic metaclass:</p> <pre> <code>from openerp.addons.analytic_structure.MetaAnalytic import MetaAnalytic</code> </pre> <p>Inside your Model class, define MetaAnalytic to be used as metaclass:</p> <pre> <code>__metaclass__ = MetaAnalytic</code> </pre> <a name="add-analytic-fields-to-a-model"></a> <h4>Add analytic fields to a model</h4> <p>First of all, make sure you are using the MetaAnalytic metaclass. Then, add the _analytic attribute to your class, using the following syntax.</p> <ol class="upperalpha"> <li><p class="first">Use the analytic fields associated with the model:</p> <pre> <code>_analytic = True</code> </pre> </li> <li><p class="first">Use analytic fields associated with another model:</p> <pre> <code>_analytic = 'account_move_line'</code> </pre> </li> <li><p class="first">Use several analytic field structures, associated with different prefixes:</p> <pre> <code>_analytic = { 'a': 'account_asset_asset', 't': 'account_move_line', }</code> </pre> </li> </ol> <a name="add-analytic-fields-to-a-view"></a> <h4>Add analytic fields to a view</h4> <p>Analytic fields can be added to the view individually, like any other field:</p> <pre> <code>&lt;field name=&quot;a1_id&quot; /&gt;</code> </pre> <p>'a' is the prefix associated with the structure. By default, it is 'a'. '1' is the dimension's ordering as defined by the analytic structure.</p> <p>You can also use a field named 'analytic_dimensions' to insert every analytic field within a given structure (defined by its prefix) that wasn't explicitly placed in the view. This field is automatically generated when you call the Metaclass:</p> <pre> <code>&lt;field name=&quot;analytic_dimensions&quot; required=&quot;1&quot; prefix=&quot;t&quot; /&gt;</code> </pre> <p>The prefix can be omitted for a structure that uses the default prefix 'a'. Any other attribute will be propagated to the analytic fields.</p> <p>Warning: analytic fields should generally not be used inside nested sub-views. If possible, create a separate record and use the context to specify the view:</p> <pre> <code>&lt;field name=&quot;order_line&quot; colspan=&quot;4&quot; nolabel=&quot;1&quot; context=&quot;{ 'form_view_ref' : 'module.view_id', 'tree_view_ref' : 'module.view_id' }&quot;/&gt;</code> </pre> <a name="bind-an-analytic-dimension-to-a-model"></a> <h4>Bind an analytic dimension to a model</h4> <p>First of all, make sure you are using the MetaAnalytic metaclass. Then, add the _dimension attribute to your class, using the following syntax.</p> <ol class="upperalpha"> <li><p class="first">Bind the model to a new analytic dimension named after the model, using default values:</p> <pre> <code>_dimension = True</code> </pre> </li> <li><p class="first">Bind the model to a new analytic dimension with a specified name, using default values:</p> <pre> <code>_dimension = 'Funding Source'</code> </pre> </li> <li><p class="first">Bind the model to a new or existing analytic dimension, using either custom or default values:</p> <pre> <code>_dimension = { 'name': 'School', 'column': 'analytic_code_id', 'ref_id': 'school_analytic_dimension', 'ref_module': 'my_module', 'sync_parent': False, 'rel_description': True, 'rel_active': (u&quot;Active&quot;, 'active_code'), 'use_inherits': False, 'use_code_name_methods': False, }</code> </pre> </li> </ol> <dl class="docutils"> <dt>name (default: value of the model's _description or _name field)</dt> <dd>The name of the analytic dimension. This name is only used when creating the dimension in the database.</dd> <dt>column (default: analytic_id)</dt> <dd>The field that links each record to an analytic code.</dd> <dt>ref_id (default: value of the model's _name field + analytic_dimension_id)</dt> <dd>The external ID that will be used by the analytic dimension. By setting this value, you can allow two models to use the same dimension, or a model to use an already existing one.</dd> <dt>ref_module (default: empty string)</dt> <dd>The name of the module associated with the dimension record. Change this value in order to use a dimension defined in a data file.</dd> <dt>sync_parent (default: False)</dt> <dd>Controls the synchronization of the codes' parent-child hierarchy with that of the model. When using an inherited, rename dparent field, you must give the parent field name rather than simply True.</dd> <dt>use_inherits (default: True or False, special)</dt> <dd>Determines whether the analytic codes should be bound to the records by inheritance, or through a simple many2one field. Inheritance allows for better synchronization, but can only be used if there are no duplicate fields between the two objects. The default value is True if the model has no 'name' and 'code_parent_id' field as well as no inheritance of any kind, and False otherwise. If the object's inheritances do not cause any conflict, you can set it to True.</dd> <dt>rel_active (default: False)</dt> <dd>Create a related field in the model, targeting the analytic code field 'active' and with an appropriate store parameter. This is useful when the model doesn't inherit analytic_code and/or when it already has a field named 'active'. Can take a pair of string values: (field label, field name). If given a string, the default field name 'active' will be used. If given True, the default field label 'Active' will also be used.</dd> <dt>rel_description (default: False)</dt> <dd>Same as rel_active for the code field 'description'. If given a string, the default field name 'description' will be used. If given True, the default field label 'Description' will also be used.</dd> <dt>use_code_name_methods (default: False)</dt> <dd>Set to True in order to override the methods name_get and name_search, using those of analytic code. This allows the analytic code's description to be displayed (and searched) along with the entry's name in many2one fields targeting the model.</dd> </dl> <a name="active-view-type-disabled-in-my-company"></a> <h4>Active / View type / Disabled in my company</h4> <p>Differences between the various &quot;active&quot; fields:</p> <ul class="simple"> <li>Active: Determines whether an analytic code is in the referential.</li> <li>View type: Determines whether an analytic code is not selectable (but still in the referential).</li> <li>Disabled per company: Determines whether an analytic code is disabled for the current company.</li> </ul> <a name="bug-tracker"></a> <h3>Bug Tracker</h3> <p>Bugs are tracked on <a class="reference external" href="https://github.com/OCA/server-tools/issues">GitHub Issues</a>. In case of trouble, please check there if your issue has already been reported. If you spotted it first, help us smashing it by providing a detailed and welcomed feedback <a class="reference external" href="https://github.com/OCA/server-tools/issues/new?body=module:%20analytic_structure%0Aversion:%202.0.1%0A%0A**Steps%20to%20reproduce**%0A-%20...%0A%0A**Current%20behavior**%0A%0A**Expected%20behavior**">here</a>.</p> <a name="credits"></a> <h3>Credits</h3> <a name="contributors"></a> <h4>Contributors</h4> <ul class="simple"> <li>Alexandre Allouche &lt;<a class="reference external" href="mailto:alexandre.allouche&#64;xcg-consulting.fr">alexandre.allouche&#64;xcg-consulting.fr</a>&gt;</li> <li>Anael Lorimier &lt;<a class="reference external" href="mailto:anael.lorimier&#64;xcg-consulting.fr">anael.lorimier&#64;xcg-consulting.fr</a>&gt;</li> <li>Nicolas He &lt;<a class="reference external" href="mailto:nicolas.he&#64;xcg-consulting.fr">nicolas.he&#64;xcg-consulting.fr</a>&gt;</li> <li>Florent Aide &lt;<a class="reference external" href="mailto:florent.aide&#64;gmail.com">florent.aide&#64;gmail.com</a>&gt;</li> <li>Jérémie Gavrel &lt;<a class="reference external" href="mailto:jeremie.gavrel&#64;xcg-consulting.fr">jeremie.gavrel&#64;xcg-consulting.fr</a>&gt;</li> <li>Alexandre Brun &lt;<a class="reference external" href="mailto:alexandre.brun&#64;xcg-consulting.fr">alexandre.brun&#64;xcg-consulting.fr</a>&gt;</li> <li>Vincent Hatakeyama &lt;<a class="reference external" href="mailto:vincent.hatakeyama&#64;xcg-consulting.fr">vincent.hatakeyama&#64;xcg-consulting.fr</a>&gt;</li> <li>Matthieu Gautier &lt;<a class="reference external" href="mailto:matthieu.gautier&#64;mgautier.fr">matthieu.gautier&#64;mgautier.fr</a>&gt;</li> </ul> <a name="maintainer"></a> <h4>Maintainer</h4> <a class="reference external image-reference" href="https://odoo-community.org"><img alt="Odoo Community Association" src="https://odoo-community.org/logo.png" /></a> <p>This module is maintained by the OCA.</p> <p>OCA, or the Odoo Community Association, is a nonprofit organization whose mission is to support the collaborative development of Odoo features and promote its widespread use.</p> <p>To contribute to this module, please visit <a class="reference external" href="http://odoo-community.org">http://odoo-community.org</a>.</p>