Bill control policy is the setting that defines at which point a Bill can be created for a product in a purchase order.

There are two available options:

• Ordered quantities
• Received quantities

The first option allows to create a bill for all ordered quantities right after the purchase order is confirmed, which means it will not make any difference if the products are received or no. While the second option allows to create a bill only for the received quantities, that is the default option when the module is installed.

This setting is per product and can be found in the Product Form View in the “Purchase Tab”.

The default value for each product is taken from the setting available in Purchase Configuration Page. This setting does not have direct influence on the purchase orders but instead on the default value for the newly created products. Which means in case there is old products that have different option selected already, that one will be still the relevant one for them in the purchase orders, unless it is manually changed.

To summarize , in case the business logic for bill control policy change, it is not enough only to update the setting in the purchase configuration page, but also all products that have the old setting need to be updated.

In some cases, there is a need to override the create​ method in Odoo and add additional logic to it. 

When overriding this method, the custom logic is triggered on each iteration of creating a new object.

 This means whenever a new object is created the extra code will be evaluated and applied.

In case when the additional logic is closely related to the object's data, this approach can be all right, since the codebase looks simpler and more clear.

However, in situations where some of the custom logic is repeating, especially when using database data, the logic will be executed n-times for n-objects, without any need for that.

In such cases should be used the decorator model_create_multi​. Adding this decorator to the create​ method allows the repeating code to be executed only once and applied to each object using a for​ loop.

It is important to mention that when using the model_create_multi​ decorator, the method receives a list of values while returns a list of newly created objects.

A very simple case to understand the need for this decorator is shown below:

@api.model_create_multi
def create(self, vals_list):
    round_precision = self.env['decimal.precision'].precision_get('Product Unit of Measure')
    for vals in vals_list:
		    vals["quantity"] = float_round(vals["quantity"], precision_digits=round_precision)
    return super().create(vals_list)
        

Without using the decorator the logic related to getting the value for round_precision​ will be executed every time a new object is created, which means for a batch of n-objects will be executed n-times.

But in our example, it will be executed only once and applied to all object values using the for​ loop.

When using many2many_tags​ widget, it is possible to define a background color for each of the tag values. For that to work the following steps need to be done:

• The related model needs to have an Integer type field where the color index will be stored, usually named color​.
• The color​ field needs to be added in the view using the widget color_picker​
• In the definition of the relational field in the XML view, when using the widget many2many_tags​, it needs to be set the option color_field​ with value the name of the color field previously defined.​
• The last step is optional, by default when a user selects a value, can edit the background color of the value's tag, however, it is possible to make the color not editable at this stage, by using the option no_edit_color​

Let’s review the steps above using as an example the relational many2many​ field tag_ids in the sale.order​ model related to the relational model crm.tag​​.

The model crm.tag​ there is a field color​ defined in the model definition as the following:

color = fields.Integer("Color")

The definition of the field in the XML view, using the widget color_picker​ looks like the following:

<field name="color" required="True" widget="color_picker"/>

Having this definition of the field makes it possible for every sales tag value defined in the system to be selected a color which later will be used as a background color for the tag.

Once the field is set up in the relational model the next step is when defining the related field tag_ids​ in the XML views to use the widget many2many_tags​ and add as an option the color_field​.

<field name="tag_ids" widget="many2many_tags" options="{'color_field': 'color'}"/>

This will add a background color for the selected tag values in the sales order. Also users will be able to change the color of the tags during the selection process. A possible issue with this change is that the color will be applied to all sales orders where the same value is used. In case the admin wants to keep the colors same as initially set, it is possible to disable the edit of the color at the moment of selection by using the option no_edit_color​ set to True​.

<field name="tag_ids" widget="many2many_tags" options="{'color_field': 'color', 'no_edit_color': true}"/>

In Odoo it is possible to change the color or text style of a column in a list view using the “decoration” attributes.

The syntax for them is decoration-<style>​ where the style can be one of the following options:

• Color: info​, warning​, danger​, muted​, primary​ and success​
• Text style: bf​ (bold) and it​ (italic)

The color that each of the color-styles represents can be seen in the image below:

These attributes, as most of the Odoo attributes in the views, accept as a value python-based condition. The style is displayed when the condition is evaluated as boolean True​. In case when the color need to be applied to the column without condition the value can be simply set to 1​ or True​

An example of using the attributes in the view is shown below:

<field name="state" decoration-success="state == 'posted'" decoration-info="state == 'draft'"/>

In case the attributes are used together with the attribute widget="badge"​ then the color will apply as a background color of the badge.

In Odoo it is really convenient to change the price of multiple products using the pricelist option. In this post we will go through the steps that are needed to make that happen.

At first would be need to enable the option “Advanced Price Rules” in the Sales configuration page, which can be found in Sales >> Configuration >> Settings​

Once that is done, open the pricelist page from Sales >> Products >> Pricelists​ and select an existing pricelist or create a new one.

The pricelist can be specific per company, country group or website. In our case we will assume that the pricelist is global for all products without any restriction.

In the “Price Rules” tab click on the button “Add a line” which will open a wizard as the one on the image:

Select the Computation​ method “DIscount” and in the Discount​ field set the value by which the price should be changed.

The important thing when setting this field is to take into consideration that if the price need to increase the value should be negative or in case of decrease it should be positive.

For example if the price need to increase for all products by 10% than the value in this field should be -10. In case the price for all products need to decrease by 10% the value should be 10.

For more complex pricing rules need to be used the option “Formula”, which still have the field Discount​ but additionally can be setup few more variables such as:

• Base On​:  The price field based on which the calculation will be done (Sales Price or Cost Price)
• Extra Fee​: Additional fixed fee added on the price calculated with the discount
• Rounding Method​: Decimal number representing the minimum non-zero value at the desired precision.
• Margins​: Minimum margin over the base price

An image of the wizard with “Formula” options is shown in the image below:

The created pricelist need to be used in the Order for the new prices to apply.

Starting from Odoo 16 it is possible to make an image partially overlap over another image in the website. 

In order for that to be possible it is needed the layout for the block to be set to “Grid”. That can be done by opening the “Edit” mode, selecting the block and on the right side in the “Customize” section select Layout: Grid. When that is set, below the Layout option is shown “Add Elements” option with three possible choices: Image, Text and Button.
Each of them can be set as an additional element above the initial image.

By clicking on the “Image” option it is shown a default image, which can be replaced with another one by double clicking on it. Additionally the image can be re-positioned, resized or moved to back if that is needed.

Multiple images can be added by clicking multiple times on the “Image” option. Every image can be positioned in different part of the block.

In mobile view, all images, unless excluded, will be displayed as separate sections one by one.

In everyday business cases, there are a lot of situations where a particular field needs to have different attributes or attribute values based on different access groups.

This type of case is possible to handle in Odoo, however, there are two different solutions based on which version of Odoo is used.

In Odoo 15 and older versions, this can be achieved by adding a more generic definition of the field in the main view, while the one specific for certain groups is added in a new inherited view, which is limited only to the specific access group.

For example, a very simple case can be if the field phone​ in the Leads view by default needs to be readonly​, but only for group Sales Administrator is editable:

<record id="crm_lead_view_form" model="https://ir.ui.view">
	​  <field name="name">https://crm.lead.form</field>
	​  <field name="model">crm.lead</field>
	​  <field name="arch" type="xml">
	​      <form>
	          ​​...
            <field name='phone' readonly="True"/>
        </form>
    </field>
</record>

<record id="crm_lead_view_phone_form" model="https://ir.ui.view">
    <field name="model">crm.lead</field>
    <field name="inherit_id" ref="crm.crm_lead_view_form"/>
    <field name="priority">99</field>
    <field name="groups_id" eval="[(6, 0, [ref('sales_team.group_sale_manager')])]"/>
    <field name="arch" type="xml">
        <form>
            <field name='phone' position="attributes">
                <attribute name="readonly">False</attribute>
            </field>
        </form>
    </field>
</record>

Starting from Odoo 16 this type of inherited view with an attached group to it is no longer supported, and will show a server error if used. The new approach now is by defining the same field twice in the view with different access group rules.

The same example with the phone​ field in Odoo 16 would look like the following:

<record id="crm_lead_view_form" model="ir.ui.view">
    <field name="name">crm.lead.form</field>
    <field name="model">crm.lead</field>
    <field name="arch" type="xml">
        <form>
            ...
            <field name='phone' groups="!sales_team.group_sale_manager" readonly="True"/>
            <field name='phone' groups="sales_team.group_sale_manager" readonly="False"/>
        </form>
    </field>
</record>

To avoid any confusion, this example does not intend to show the best solution on how to make a field editable only for certain access groups, but it is just used to demonstrate how to define the same field with different attributes for different groups.