This commit aims at:
1. Fixing a bug where the invoice would be uploaded in the wrong journal
------------------------------------------------------------------------
To reproduce:
- Go to Customer invoices
- Upload an invoice (with an embedded FacturX)
- The journal is set to Vendor Bill
2. Letting the FacturX move type override the user-chosen move type
-------------------------------------------------------------------
Currently, if the user uploads a credit note in a customer invoice journal,
the document is not created and set to the OCR. This is due to a restrictive check
which has been removed. Therefore, when the move type is defined in the FacturX XML,
we will use it to override the user choice so that the document is always created
within the right journal.
3. Harmonizing the invoice upload between the Accounting and the Documents apps and avoid code duplication
----------------------------------------------------------------------------------------------------------
Currently, the flow of uploading an invoice from the Accounting app and the Documents app is different.
Indeed, if one uploads an invoice in the Document app and click on the "Create invoice",
the document is sent directly to the OCR. Now, instead, we will pass this document to the same upload method
of the Accounting (which will try to create the invoice from the FacturX XML if present).
Therefore, the flow will now be the same from the two apps for better harmonization.
4. Adding a 4th button in the Documents app to create a Vendor refund
---------------------------------------------------------------------
Currently, there are 3 buttons to create a customer invoice, a credit note, a vendor bill, but no vendor refund.
This is due to a duplicate xmlid which has now been fixed allowing the 4th button to be seen in the UI.
5. Adding a button "Switch into customer invoice/vendor bill" button in the account.move's form view
----------------------------------------------------------------------------------------------------
Currently, the user has access to a "Switch into credit note/refund" but not the reverse button to
go from a credit note/refund to an invoice/bill. This is now the case.
Task id 2961932
closesodoo/odoo#103427
Related: odoo/enterprise#32890
Signed-off-by: William André (wan) <wan@odoo.com>
Steps to reproduce the bug:
- Create a storable product “P1”:
- change the cost to $20
- product category > costing method > standard price
- Create a SO:
- Add the product “P1”
- Change the cost from $20 to $10
- Save
- Sent the quotation by Email
Problem:
The `purchase_price` is recomputed and changes back to the original value.
When the quotation is sent, the state of the order lines change,
marking the field `qty_delivered_method` to be recomputed, but also
other computed fields depending on it, including the purchase_price
(because of the dependency added in sale_timesheet_margin).
To avoid this unexpected recomputation, we remove the useless
dependency on the `state` for the field `qty_delivered_method`.
There is no reference/check on the state in the method
_compute_qty_delivered_method or any of its overrides and
therefore the field should not be necessary in the compute
dependencies.
opw-2994136
Fw-port of 296ec254b8ba88022fd15cabb0e44956163835fb to 16.0+
X-original-commit: 6f2faf5ccfca41c4e3d8b85105dd5bca5d031106
Part-of: odoo/odoo#107909
Cleanups and fixes/improvements extracted from another task
on the settings of sale.
* indentation
* code simplification
* privatize method not meant to be called by rpc
* double quoted strings for strings shown to users, single quoted for
technical strings
* translate onchange warning message
closesodoo/odoo#107897
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
* = {account, sale, purchase, hr_expense}
When a plan is mandatory for SOL, POL or expenses, the flow should still be blocked when pressing the button, and not only when creating analytic lines.
We add the info in the context of the button, so automatic flows are still not blocked.
When the applicability rule requires a mandatory analytic distribution, raise an error upon :
- confirming PO,
- sending or confirming SO
- approving Expense Report by manager.
t-3040929
closesodoo/odoo#107166
X-original-commit: 8623a7850288828759db125b1054b0fed6b6b135
Signed-off-by: William André (wan) <wan@odoo.com>
When decreasing the qty of a SOL, if there is already a packaging
defined, a return will be created for the difference
To reproduce the issue:
1. Create a product P
- Storable
- With one packaging PK for 10 x P
2. Create and confirm a SO
- Order Lines:
- 10 x P with PK
3. On the SO, decrease the quantity of P to 8
Error: a return is created for the difference. Instead, the existing
picking should be updated
At some point, we try to merge the stock moves (`10 x P` and `-2 x P`)
and, to do so, they must have the same `product_packaging_id`:
https://github.com/odoo/odoo/blob/08f53ffa30479cfb452ebaed61b42655eb0e6a95/addons/stock/models/stock_move.py#L808-L813
However, on the SO, when decreasing the quantity, an onchange tries to
find the best packaging. Because the new quantity is not a multiple of
PK, this one is not returned. As a result, the SO has no more packaging
and so does the new stock move (`-2 x P`). Therefore, the stock moves
can not be merged and a new picking (the return) is created.
This commit updates the onchange method so it behaves the same way as
purchase side:
https://github.com/odoo/odoo/blob/20fa7c6f0f5c9cdfae2519ea8d0ff849d7fa3b9e/addons/purchase/models/purchase.py#L1224-L1231
In this onchange, the same diff has recently be added for another reason
(see [1])
[1] 20fa7c6f0f5c9cdfae2519ea8d0ff849d7fa3b9e
OPW-3027110
X-original-commit: e92e960a36babf4daf8f79d210c7f53fb376aa74
Part-of: odoo/odoo#107045
Current behaviour:
Changing the package quantity may change the package type,
leading to an incoherent product quantities in the SOL.
(For ex: 20 uom in 2 packages of 20)
Expected behaviour:
When setting the package quantity, don't change the
package type. If the user wants to change the package type
they can do it by manually setting it or changing the product_uom.
Steps to reproduce:
- Install Sale and Inventory
- Activate Packages in settings
- Create 2 package types for a product of choice, one of 10, another of 20
- Create a new SO with that product
- Set the quantity to 10 (a new package_qty=1 and packaging type of 10 should appear)
- Save
- Edit package_qty to 2
- Observe that we have 20 units of the product, 2 packages of 20,
instead of 2 packages of 10
Reason for the problem:
When setting the `product_packaging_qty`, the `product_uom_qty` compute is triggered.
When `product_uom_qty` changes, it triggers `product_packaging_id`'s compute.
When `product_packaging_id` is computed, it doesn't trigger `product_package_qty`,
because it is protected, since we are writing to it.
Fix:
When we are writing the `product_packaging_qty` and the `product_uom_qty`
we remove the compute for `product_packaging_id`.
Affected versions:
- saas-15.2
- saas-15.3
- 16.0
- master
opw-3010703
closesodoo/odoo#106924
X-original-commit: acfa94b7aeea9f8efdc1886b094697ae3f0f1d2a
Signed-off-by: Piryns Victor (pivi) <pivi@odoo.com>
PURPOSE
Purpose of this task is to cleanup attachment management done in generic mail
models overrides and move it in account as model overrides.
SPECIFICATIONS
Update addons
* in purchase and sale: context key update should be done at message_post
level, especially this is not used in mass mailing mode;
* in website_sale: code to update sale order to avoid sending recovery
emails several times belongs to a "post hook" method on sale order model;
* in loyalty: remove a deprecated / unsupported 'mark_coupon_as_sent' key;
Task-2792146 (Mail: Move model-dependent code from composer / template)
Part-of: odoo/odoo#106658
Before this commit, the auto-invoice flow did not consider `sale order`
lines with negative quantities. It led to partially paid invoices.
Now, invoices generated by the auto-invoice flow are considered final.
This will allow `sale order` lines to be invoiced, even with negative
quantities.
task-2887019
closesodoo/odoo#104277
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Prior to this commit, payment was requested on sale orders with a
negative balance. Customers could settle transactions with a negative
amount. No payment provider allows negative transactions which would
lead to crashes and errors during payment.
Now, payment is only requested if the total amount of the sale order is
strictly positive.
task-2887019
Part-of: odoo/odoo#104277
To Reproduce
============
- create a subscription
- confirm it and create invoice for it then confirm it too
- go back to the subscription and renew it
- from *Action* generate a payment link
- a validation error will be raised
Problem
=======
we can't generate the payment link because the amount is 0, this value came from the fact that we substract
the sum of invoices amount linked to this subscription from the total amount.
Solution
========
The invoices from the old subscription are kept just as history in the new one, and must not be taken into account when
computing the amount, so a condition was added to remove theses kind of invoices from computation of amount.
opw-3052816
closesodoo/odoo#106104
X-original-commit: 62e6db19d6ec17805756f277ca6f17c50281f707
Signed-off-by: abla001 <abla@odoo.com>
The image for the sample product was updated in 76141b0d which made the
'Sample quotation' onboarding step hang for databases without any
`product.product` record.
A simple unit test for `_get_sample_sales_order` is included.
Technically, it wasn't possible to add it to the existing onboarding test class
because these tests are run post_install, and would fail on ENT builds because
of pos_loyalty preventing archiving `product.product`s.
--Additional note for 15.3 fw-port:
As logic moved from pos_loyalty to loyalty, which is installed before sale on
runbots, the problem described above resurfaces. We chose this cross module but
simple and limited-impact fix to avoid it.
Task-3045287
closesodoo/odoo#105339
X-original-commit: 0698388aab821e21309cbb2dd2411dac60f71be6
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Reading only 'id' with `search_read` is equivalent to use `search` but
complexify the result usage. Fix all these bad usages.
Part-of: odoo/odoo#104838
Co-authored-by: Julien Castiaux <juc@odoo.com>
The price_reduce field is not shown to the users, and was not useful for
business computations because of its digits specification (losing decimal data
when we only want to round the total amounts, not the price before taxes).
This commit removes the field to reduce the table size, remove useless computation,
avoid misuses of the field and clean code.
Task-3018371
closesodoo/odoo#103611
Related: odoo/upgrade#3977
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
The `analytic_distribution` field is a Json.
It was stored temporarily as a char.
Search is not available yet, so we do queries by hand when we need to search on keys.
Also added a constraint on account_analytic_distribution_model,
so we don't have models with accounts specific to a company when the model has no company or another company.
It would cause an issue when looking at the models from another company.
X-original-commit: 7064c95aa04e5138bb12ae97acfee04ebb67cc0e
Part-of: odoo/odoo#103097
Add choices for the business domain on applicability rules, so rules are more precise
Also put 'general' as domain from the view when it's what should have been.
Make analytic field visible since owl migration (for sale and purchase)
closesodoo/odoo#102461
X-original-commit: c5867d5009a7fb448fff1be487b9e9c3e7945d4b
Related: odoo/enterprise#32421
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Wala Gauthier (gawa) <gawa@odoo.com>
This repeats the fix from #80049, which already solved the same problem.
That `compute_sudo` was dropped by #81510 afterwards, but only in the
`sale` module.
closesodoo/odoo#99840
X-original-commit: f1d30dd3bb55b756120fa298b3b2c7d591cedbf3
Signed-off-by: Olivier Dony <odo@odoo.com>
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
correctly used
When a boolean ir.config.parameter is set to False,
self.env['ir.config_parameter'].sudo().get_param('parzm_key') will return
'False'. As the string is not falsy, the parameter value match as true.
This commit fix the behavior for the sale.automatic_invoice to keep coherence
with the subscription module
closesodoo/odoo#101906
X-original-commit: ade1a1f5ee00baa88347bfd151f028bd17d7f4f1
Related: odoo/enterprise#32173
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Signed-off-by: Arnaud Joset <arj@odoo.com>
Allow our users to modify mail template more easily
- make the list accessible from the settings
- give them a link to update relevant views to update header/footer
- make the list and form of templates more readable
- add a description on templates, allowing to describe their usage
In order to better filter templates, a new category field is added that
is computed based on active flag, description being set and the template
having an xml ID. Master templates are active, with a description and an
xml ID.
Update master data to add description on some templates.
task-2944770
closesodoo/odoo#101730
X-original-commit: dfa867343ee8842f3f127ac62584fd471b41dde1
Related: odoo/enterprise#32079
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Currently, When we create an invoice from a sale order containing some notes or sections.
The analytic account from the sale order is set on the invoice/move line.
During the creation of analytic lines, a line is created from the section/note line.
This commit makes no analytic line is created for section/notes.
closesodoo/odoo#100989
X-original-commit: a1bff32113bb0b551cd62efea5030c8f3bd4d1de
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
The goal of this commit is to get rid of the analytic tags as they were confusing, serving tag purposes as well as distribution on analytic accounts.
Everywhere analytic tags were used as a distribution have been replaced with a new widget that will dispatch distribution on analytic accounts. If there was an analytic account field next to the tags, it has been included in the distribution.
Analytic tags that were used simply as information tags have been removed.
To fill the new widget, there are now 2 kind of rules that will help fill and prefill it.
The first are applicability: previous groups have been removed, and have by replaced by plans. Each account is required to have a plan. These plans define when they are available in the widget: a default applicability per plan and applicability lines that can specify rules following the context of the widget.
The second one are distribution models, that will replace previous default rules but follow the same principles. The accounts (and so the plans) that will be given by the distribution model can override the applicability rules from before.
closesodoo/odoo#98914
Related: odoo/upgrade#3885
Related: odoo/enterprise#30743
Signed-off-by: William André (wan) <wan@odoo.com>
Co-authored-by: Habib (ayh) <ayh@odoo.com>
Current behaviour:
In the context of a multilevel contact hierarchy, if a contact is creating an SO, only that contact and it's commercial partner (usually the first company when going up in hierarchy from that contact) can see the SO.
The other contacts that are in that hierarchy could see the number of related SO on the smart button, but once clicking on it, no SO were shown.
Expected behaviour:
Every direct or indirect parent of a contact should be able to see the SO, as shown in the smart button count.
Steps to reproduce:
- Create 3 contacts with the following hierarchy: Company -> Contact 1 -> Contact 2 (Company is the root)
- Create an SO with Contact 2 as a customer
- On each of the contacts, click on the SO smart button, all of them have 1 SO shown on the button, but only Constact 1 has none shown once clicked. (Regardless if Contact 1 is an Individual or Company)
Fix:
Simplify domain search to only take into account the children's ids.
There is no need to make a distinction between a contact that is a company or not, since all commercial_partners are also partners by default.
Affected versions:
- 14.0
- 15.0
- saas-15.2
- saas-15.3
- master
opw-2961030
closesodoo/odoo#100544
X-original-commit: c34e0200b2db3ad191ee08f91f9293404a2c3340
Signed-off-by: Piryns Victor (pivi) <pivi@odoo.com>
Steps to repoduce:
- create a customer with a private address (first select "individual" to show the selection field)
- create a quotation (and/or invoice) and select this customer
- this customer cannot receive an email and cannot be contacted afterwards (this behavior is intended)
Issue:
- it's possible to choose this type of client
Cause:
- there is no address type filter for this field
Solution:
- add a condition in the domain of the field
opw-2909395
closesodoo/odoo#100487
X-original-commit: a24384b7ede2a132125d24681cba7056bc64ccbe
Signed-off-by: Lefebvre Thomas (thle) <thle@odoo.com>
Signed-off-by: William André (wan) <wan@odoo.com>
Check state before execution in _set_pending()
When using webhooks, _set_pending() can be called two times (when the
user comes back and when the webhooks notify the db). To avoid doing
the same treatment twice, we add a check in _set_pending to see if the
transaction is not already pending before doing anything else.
Part-of: odoo/odoo#100186
When payment providers receive a notification from a webhooks and log
something in the chatter of transactions, sale orders or invoices, the
message is shown as from 'Public User'.
Now, all messages will be logged as 'OdooBot'.
Part-of: odoo/odoo#100186
This related field is useful in sale to simplify the logic of the
product configurators (incoming adaptation to OWL).
Thanks to that, we'll be able to avoid an useless rpc to get the
detailed type of the SOL product.
closesodoo/odoo#100310
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Sending confirmation email is generally done on a singleton recordset but
some calls could end up calling in batch. Anyway better safe than sorry.
Task-2710804 (Mail: Clean MailThread API)
closesodoo/odoo#100137
Related: odoo/enterprise#31301
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Currently, the `partner_credit_warning` only works with companies,
not individuals related to a company.
Which means that the credit warning will not appear if you use a
contact from a company, instead of the company itself.
This PR solves the issue.
https://github.com/odoo/odoo/pull/83205#issuecomment-1242971077closesodoo/odoo#100038
X-original-commit: acd3545372082268b86d18cd38197d4a464930c9
Signed-off-by: William André (wan) <wan@odoo.com>
"mail_notification_paynow" mail template layout has been renamed to
"mail_notification_responsible_signature_layout" as it now only differ by the
signature. It allows to use it more widely.
Task-2801600
Part-of: odoo/odoo#88466
Ease the understanding of the notifications sent when users are assigned to an
activity or a model (task, lead, ...).
Technical note:
- the customization of data sent to the email layout template (here subtitles)
should be done by overriding
mail_thread._notify_by_email_prepare_rendering_context on the model.
But in this case, we send an activity (ex.: todo) for a model (ex.: crm.lead)
which involves 2 models. Data from both models must be sent to the template
layout. To solve this problem an optional parameter to
mail_thread.message_notify has been added: subtitles. This allows the
caller which knows about the 2 models to set the values for subtitles for
the template.
- mail_activity._render_notify_header has been added to render the subject and
subtitles using the language of the recipients through the context lang
variable.
- a generic mail notification template has been added and the specific
mail_notification_paynow has been derived from it as the only change is the
handling of the signature.
Task-2801600
Part-of: odoo/odoo#88466
Steps to reproduce:
- create two products
- create two analytic accounts
- create two new analytic rules by assigning an account to a product
- Create a new PO and select on of the product
- On the same line, change the product to the other one
Issue:
- The analytic account won't be updated
Cause:
Bypass of the `account_analytic_id` whenever there is already on defined
Solution:
For the `Sale` fix, I added the `line.state == 'draft'`.
The reason? Because the compute is triggered after confirmation of the order due to:
https://github.com/odoo/odoo/blob/14.0/addons/sale/models/sale.py#L931-L935
Therefore, the compute won't also be triggered after confirmation of the SO.
opw-2948950
closesodoo/odoo#99858
X-original-commit: 61604e18128c1cfd0e6d4e510852f780491d6e4e
Signed-off-by: William André (wan) <wan@odoo.com>
Changing the name of model payment.acquirer to payment.provider
and everything that it touches. It is technically incorrect to
use the term "acquirer" for systems that only provide a service
of payment.
After this commit the model payment.acquirer and all related to
it will be renamed to payment.provider.
Task - 2842088
closesodoo/odoo#90899
Related: odoo/upgrade#3542
Related: odoo/documentation#1981
Related: odoo/enterprise#27131
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
* = account, sale
- Fix typo
- Make private as very specific role
- Allows to grep similar functionality from new onboarding module and previous
common implementation of onboardings.
Task-2852375
Part of Task-2900763
Part-of: odoo/odoo#97105
The module `payment_transfer` was originally meant to implement a
payment with Wire Transfer flow, which it does not exactly do since all
it does it making transactions follow the payment flow until their
`pending_msg` field's content is shown to the customer. Because of that,
other modules (`website_delivery_ups`, `website_sale_picking`) started
duplicating the base acquirer Wire Transfer to create new payment modes
such as Cash on Delivery and Pay in Store.
To better prepare for a proper dinstinction of the custom modes enabled
by other modules, this commit renames the module `payment_transfer` to
`payment_custom`.
The module `payment_transfer`'s `auto-install` key is also set to
`False` since we no longer want Wire Transfer to be the default payment
acquirer for new databases.
task-2853489
Part-of: odoo/odoo#99400
website: get_base_url was not working with unprivileged users
Before this commit, when a unprivileged user tried to generate a report
(in sale for example), he could not access to the field website_id on ir.ui.view
An access error would be raised. This commit allows to read the base_url for all users.
Misc: UI for sale order templates
Before this commit, the sale order template information was not clear enough.
Note: these changes were merged into a single commit to ease the manual FW port of
changes in 15.3 for sale_subscription
taskid: 2942621
1) Invoicing wizard refactoring
* reduce the use of context in the business logic,
store the orders being invoiced
* factorize invoice creation values, using the correct method from
the sale.order model
* switch from default fields to computed fields, and avoid computing
unnecessary fields when the wizard is opened to invoice multiple
orders together (most fields are only used for down payments)
* Rely on python constraints instead of error messages scattered
accross business methods to notify the user that the invoice cannot be
created.
* Clean the code to make it easier to follow, understand and maintain
2) Distinguish Down Payment Invoice lines from standard ones
(with a dedicated field)
Allows to stop relying on the dumb property,
not specifically reliable, e.g. if the down payment product is modified
in the settings after down payments orders were already created.
closesodoo/odoo#98600
Related: odoo/enterprise#30653
Related: odoo/upgrade#3799
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Despite recent improvements, the method is still quite confusing,
especially with the 'force_confirmation_template' parameter.
Splitting this parameter logic in a split method giving only the
confirmation template when needed.
Part-of: odoo/odoo#98600
`_compute_discount` from subscription add dependencies that triggered
the compute before the `product_uom` was set in a sale order line, once
the uom is set, the `_compute_discount` will be triggered again.
task-2960768
closesodoo/odoo#98780
Related: odoo/enterprise#30721
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
* Local variable 'filtered_self' might be referenced before assignment
* confusing use of `order` from the previous for loop, support multi recordset
in the method instead.
closesodoo/odoo#98068
Related: odoo/enterprise#30408
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
By default, a related field dependencies are the fields in his relation
path.
But for non stored UX fields, the field should only be recomputed when
values editable in the view are edited.
Example:
On a given model:
product_id = fields.Many2one(...)
product_type = fields.Char(related='product_id.type')
The product_id field can be changed on the model view, but not the
linked product,
so there is no need for the orm to search records whose product_type
must be invalidated
when the type is changed on a product.
To avoid this 'useless' search, we can manually restrict the field
dependencies:
product_type = fields.Char(related='product_id.type',
depends=['product_id'])
Part-of: odoo/odoo#98068
Victor Feyens