When creating a product "down payment" in multi company in function "create_invoices"
of the model "sale.advance.payment.inv", a default company was set on this product
and it could lead to access rights error when trying to invoice a SO from an other
company.
NB: The down payment product must be shared with all the companies, as this is
the only one that you can set in the ir.config_parameter.
opw:1841468
When creating an invoice with 'Down payment' option for an SO, it should
first consider income account of the 'Deposit Product'. if it does not
have one then it should consider that product category's income account.
Fixes#23100
Task# 1819531
When you create a down payment invoice from an SO, the product that is used in the line is 'Down Payment'.
The description of this product, which is visible for the customer, was not translated to the language
of the customer in the SO and in the invoice. It was translated to the language of the user logged.
This fix is made to keep the same behavior for the description of an SO line and for the description
of the invoice line.
opw:1820081
Steps to reproduce the bug:
- Subscribe another person as follower to all kind of messages in your default sales team.
- Create a new quotation.
- Hit on Send by Email and send the email.
Bug:
A empty email was sent to the followers.
Fix:
Now only the email rendered in the wizard is sent to the followers.
opw:1816028
When you create a down payment invoice from an SO, the product that is used in the line is 'Down Payment'.
The description of this product, which is visible for the customer, was not translated to the language
of the customer in the SO and in the invoice. It was translated to the language of the user logged.
This fix is made to keep the same behavior for the description of an SO line and for the description
of the invoice line.
opw:803977
Since this field is an analytic account and not a project, its
name should be more explicit. This commit makes the code more
understandable. Naming things correctly improve developper's
sleep.
Commit 55549f1e61 changed the way bindings between action and
contextual menu entries are generated. However a typo was introduced
linking Invoice Orders to sale order lines instead of sale orders.
Fields like `default_foo` still used ir.values although those are system-wide
parameters and should therefore be stored in ir.config_parameter
table.
When no default_model is set on a field, don't prefix it by `default_`.
``import odoo.addons.foo as bar`` doesn't seem to properly trigger the
import hook in Python 3 (it blows up on decimal_precision and
base). Thus convert *all* examples of that pattern to the more
sensible ``from odoo.addons import foo as bar``.
When creating a down payment for a SO, the applied taxes must
be the taxes of the company order. In this way, it's the same behavior
as a product with multiple taxes is added on a SO, only the order company
taxes are applied.
opw:741958
When the invisible attr doesn't need to be evaluated (e.g. = "1"),
it is better not to specify it within the attrs as they are
automacally re-evaluted at each field changed.
We directly write "invisible=1" instead.
The JS framework supports both, but we encourage the later one.
The `map_account()` method expects a browse_record as
parameter, and returns a browse_record (possibly the
argument if no mapping happened).
It was being called with an account ID instead, so
fiscal position mapping would never match, and would
always return the argument itself.
When creating a SO line and an invoice line for a downpayment,
the fiscal position set on the SO must be taken into account
to map the right taxes.
opw:688611
SPECIFICATION:
==============
- hide income account in invoicing wizard (if user is not a accounting accountant at least)
- hide Inventory tab in products form if no access to Inventory app
- in internal category form, hide accounts if user is not an accounting accountant
- hide Vendors if no access to purchase (as well as Description for Vendors in Notes)
- remove Warranty or hide it with related access rights
- tax cloud config is not userfriendly (product form, what is TIC category? what does it imply?)
- rename Accounting tab (in products) into "Invoicing" and move Invoicing Policy and Taxcloud Config there. Make tax field visible for sales
- reset Internal notes field on product (under Notes). Used by many companies and useful for search on website.
- invoice: validate button should be for billing users only
- a sales user can't see Configuration menu (with salesteams)
- a sales user should not see Invoicing report link &nd settings link in salesteam dashboard
- a sales user should not see the field for invoicing target in dashboard (in invoicing if activated for salesteam)
- In sales team, quotations and invoices should be only one option -> that way invoicing fields & targets show up to the admin
- SO status: sale order -> Sales Order
- Everywhere: Payment Term -> Payment Terms
When making an advance payment in percent, the function onchange_advance_payment_method
set the Down Payment Product to False. Then each time an advanced payment in percent
was made, a new down payment product was created and set in sale.config.setting in the field
deposit_product_id_setting.
Now the function onchange_advance_payment_method let the Down Payment Product
even if the payment method is in percent.
opw:683167
When making an advance payment in percent, the function onchange_advance_payment_method
set the Down Payment Product to False. Then each time an advanced payment in percent
was made, a new down payment product was created and set in sale.config.setting in the field
deposit_product_id_setting.
Now the function onchange_advance_payment_method let the Down Payment Product
even if the payment method is in percent.
opw:683167
Goffin Simon