This commit adapts several views to make them use newly defined
widgets, the new decoration-xxx mechanism on fields, and to adapt
them to the new design of buttons.
Part of task 2195254
New report to easily order missing products in each warehouse.
Orderpoint have a new type: 'manual'. Manual orderpoint are not
trigger by the scheduler but the user could create replenishment
from the report directly. The report use the forecast report in
order to detect missing quantity for today (it does not search
depending the lead time for each product warehouse due to lake
of performance). It compares missing quantity with incoming RFQ
and other ongoing orderpoint. If it still missing a new entry
for replenihsment is created (it's also automaticaly deleted if
the replenihsment has been done another way).
Task: 2161378
Improve onboarding and guide first clicks of users in the purchase application
to create a purchase order.
In case Stock module is installed, it will also guide the users
through the receipt first clicks process.
Task ID 2219988
closesodoo/odoo#49031
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Minor improvements/fixes:
- Prevent overlap of 'o_view_nocontent' (when there are no relevant
records) with kpis table in list/kanban views on small screens/windows.
- Create separate list views to prevent kpis table appearing in
appropriate situations (e.g. action windows showing linkages between
purchase orders and other models.)
- Override bootstrap styling that was making kpi table wider than the
width of the window in list view.
closesodoo/odoo#49509
Task: 2228175
X-original-commit: ee831f7aff400f76e20e54b7cb9b5610bcec4839
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
In compute method _compute_expected_date() all PO lines
are processed to get expected date, but in note and section
line we dont have date_planned, it generates error. filtered
the PO line to process if only they are not having display_type.
Fixes-2234053
closesodoo/odoo#49433
X-original-commit: 2163c6a05476ddfbf899e46eac565b7f5cc5f46e
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
- Create journal entries as soon as bank/cash statement lines are created, temporary booked on a suspense account set on the journal.
- Simplify the management of "blue" lines in the reconciliation widget. A "blue" line is now a journal item using a temporary liquidity account (outstanding payment/receipt accounts, set on the journal).
- Adapt and simplify the bank reconciliation report.
- Remove the bank reconciliation threshold date. The reconciliation report will show the not already reconciled journal entries using a liquidity account and the not already reconciled journal entries using a temporary liquidity account. Without accounting, an account.payment will involve directly the liquidity account and then, will be considered as a statement line directly.
- Remove the post_at bank reconciliation feature. The "paid" state will be set on the invoices only if reconciled with a journal entry involving the journal's liquidity account.
With invoicing, the payment will do that so the "in_payment" state should never be shown up.
With accounting, only the statement lines have the power to move an invoice to the "paid" state.
- Fix various corner cases about the management of multi-currency in bank statement lines.
- Fix the conversion dates in multi-currency: Since the bank/cash is always used on the statement lines, it will use always the real "bank" date instead of the fictive payment one.
- Ensure the 'reconcile' method will raise an error if the involved moves are not posted.
related enterprise PR odoo/enterprise#7019closesodoo/odoo#41301
--task: 2092096
Related: odoo/upgrade#1018
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Currently, when we add many2many field relation with purchase.order in view
where view does not have state field, it throws error, it is because
purchase.order list view has attrs for column_invisible which parent.state
which is wrong, purchase.order will not have parent.
With this commit, remove wrongly added column_invisible attrs on invoice_status
field.
task-2195175
closesodoo/odoo#49416
X-original-commit: 79a738fb7fa852c4e2e9fc127fa63dbc4ffd4a53
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Filter out section and notes from the invoice status computation.
opw-2233550
closesodoo/odoo#49301
X-original-commit: 55d3c59235cadb70aa9206eaec7ff1e4631fb019
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Before the commit, when there is no pricelist, we set the unit price to be 0
on the PO. After the commit, when in the same situation, we use the cost
set on the product form.
Task 2072560
PR #49067
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
- moved company_id in other info tab
- currency_id is shown near journal_id
- invoice:
-- ref renamed to 'customer reference' and move to other info tab
-- payment_reference hidden if state is draft
-- Fixed bug in l10n_in where xpath did not find removed element
- vendor bill: auto-complete only shown in edit mode
was task:2209497
closesodoo/odoo#48913
X-original-commit: 170635c901914cfe8f33fdbe8d498cbd5f54054e
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Steps to reproduce the bug:
- Let's consider a vendor V with a supplier currency €
- Let's consider the current company's user C in $
- Let's consider two vendor bills journals J1 in € and J2 in $ from C
- Create a vendor bill for V
Bug:
The default currency was $ instead of € and the default journal was J2 instead
of J1. This fix keeps the same behavior as implemented in 82794c8662
opw:2226115
closesodoo/odoo#48857
X-original-commit: 801182f6222521c2961560b3b67743a143a22eff
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Adds a customized table to top of list and kanban views of requests for
quotation (RFQs). This table includes the following values:
- RFQs to Send (PO.state = 'draft')
- RFQs Waiting (PO.state = 'sent' and PO.date_order >= now)
- RFQs Late (PO.state = 'sent' and PO.date_order < now)
- Avg Order Value (specifically only for POs)
- Avg Days to Purchase (PO.date_approved - PO.date_created and PO.state
in ('purchase', 'done'))
- Purchased Last 7 Days (specifically only for POs)
- RFQs Sent Last 7 Days (hacky calculation looking at chatter for state
change 'RFQ' => 'RFQ Sent')
This change corresponds to "Requests for Quotations KPI's" subsection of Purchase
KPIs task.
Task: #2198420
"Edition" is a French-English false friend word. "Edition" in English
means "version" whereas "edition" in French means "editing". This commit
updates user facing strings/documents that incorrectly use "edition" instead
of "edit" or "editing". Attempts were made to clean up English around
"edition" usage so please excuse any errors from lack of context
knowledge. Code comments and names incorrectly using "edition" were NOT
updated.
Added new values "Average Days to Purchase" and "Average Receipt Delay" to be
used in purchase enterprise reporting tab where:
Days to Purchase = confirmation date (i.e. 'date_approved') - creation date
Receipt Delay: effective Date - ('date_planned' or 'expected_date' if
no 'date_planned)
Note that these 2 new values are specific to purchase orders only.
Because of this the standard query result cannot be used since it is
done at the purchase order line level. This means duplication of PO
values occur and results in incorrect aggregation calculations. A hack was
done to ensure that these value will aggregated correctly when used at the
enterprise level. Therefore these 2 new values should only be used in
aggregate.
To support these new measures the following updates were also done:
- Addition/improvement of help descriptions for other date related
measures to avoid confusion
- Change state string to "Status" to match purchase.order (for
consistent filtering purposes)
This commit supports "Adapt Reporting" subsection of Purchase KPIs task.
Upgrade PR: odoo/upgrade#877
Enterprise PR: odoo/enterprise#8945
Task: 2198420
Adds "Expected Date" and "Effective Date" fields to purchase orders to
match what exists in sales orders. "Effective Date" mirrors sales logic
(= first completed stock move). "Expected Date" has simplier logic due
to simplier nature of receiving stock vs shipping (= earliest "Scheduled
Date" of all PO lines). Form view has been updated to include these new fields.
Additionally code was changed to not have PO 'order_line.date_planned' be
overwritten by the 'purchase_order.date_planned' value. Previous behavior
was both confusing and made it so info was lost. Also logic for related
stock move picking line expected date values has been updated to now consider
'purchase_order.date_planned' value if set. Related changes include:
- not overwriting when PO is edited+saved (this only occurred in write()
logic, not create() which caused inconsistent behavior anyways.),
- updating related tests,
- removing PO line date_planned editing restriction when PO date_planned
is set
- updating of relevant stock moves/picking expected date due to
PO.line.propogate_date = True ('purchase_order.date_planned' if
exists, otherwise 'order_line.date_planned')
This change also includes some small related improvements:
- Removal of outdated code comment.
- Addition of Help strings to better explain fields.
- Prevent copy of 'date_planned' value into new POs (now mirrors sales
logic).
This change corresponds to "Receipt Date on PO's" subsection of Purchase
KPIs task.
Task #2198420
Several improvements in order to improve user interface are done here.
[IMP] purchase: Prevent create PO&RFQ in calendar
It was possible to create PO's and RFQ's from the calendar view.
The Product Owner wanted to prevent the users from doing so.
[IMP] purchase: Add tooltip to Receipt Date
[FIX] purchase: Align report & stat button data on product form
The use of Last 365 days time_range in the purchase analysis was automatically
excluding today's purchases wich was confusing users as the stat button info
was taking those into account.
Different behaviours were implemented for product template and product product
in the filters that were used which makes no sense.
Use of context_today() instead of datetime.now() in order to take the user's
timezone into account.
[IMP] purchase: Use relevant dates for RFQ's and PO's in calendar view
The date used in order to display RFQs and POs in the calendar was date_planned
which is not mandatory and so not always filled. It has been decided to use the
order_date for the RFQ's and date_approve for PO's.
[IMP] purchase_requisition: Making Agreement selection type more explicit
[IMP] purchase: Show UOM menu only if installed
[IMP] purchase: Add product variant in settings
[IMP] purchase: Remove Favorites predefined filters
[IMP] purchase: Rephrase PO action helper
[IMP] purchase: Allow open/edit Agreement Type
[IMP] purchase: Rephrase RFQ action helper
[IMP] purchase: Remove PO's and RFQ's name from fields in calendar
The Product Owner originally wanted to have a link on the PO name field
that was shown in the calendat popover. As the Edit button already allows
to edit the PO's or RFQ's from the popover it was decided to simply remove
the field (as it was already displayed at the top of the popover)
[IMP] purchase: Open the right view when click on Reporting top menu
Task ID #2196688Closes#47810
Related: odoo/enterprise#9294
Related: odoo/upgrade#961
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
========
Purpose
========
Currently, purchase missing some billing functions that we have in sale
invoicing:
- Create credit note when necessary
- Create vendor bill in batch in list view
========
Spec
========
- In case of retures, when create a bill for a purchase order, we check
the total amount we want to bill to decide whether it's a vendor bill or
a credit note.
- In the list view, add a new action to create vendor bill/credit note
for all selected order.
========
Links
========
Task 2170715
PR #44210
Related: odoo/upgrade#919
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
The 'vendor bills' stat button on purchase order, once clicked, will
have a specific behavior depending on the invoice count :
0 : open a new invoice with pre filled fields (not saved yet)
1 : open the form view of the invoice
2+: open the list view of the invoices.
Before this commit, the invoice count was computed with an environment on
the current user. That means a record rule could make the invoice count
lower than the real count and so give an unwanted behavior. Ex: create a
new invoice even if there is already one created because the user cannot
see the other people's invoices.
After this commit, the action_view_invoice with make an explicit read()
in database to fill the cache with all the purchase order's invoices and
make sure the count is the real one.
Task : 2206969
closesodoo/odoo#48274
X-original-commit: e3101d92187946b2bd539e05956e4e83cd9c9097
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Before this patch, the purchase users get an access violation error
at the invoice creation from a purchase order. This was due to
some missing ACL between v12 and v13.
Task : 2206969
X-original-commit: 4c4fb33e4bbc78a85ad309baf5df906cf16566ea
PURPOSE
Clean and rename code about language management and template rendering in mail
template model.
SPECIFICATIONS
Clean method naming and try to make code easier to understand and call. Also
add and/or clean docstrings of rendering methods.
Notably
* ``_classify_per_lang``: for each lang-contextualized template, give the list
of record ids;
* ``_render_template``: now working only on a valid list of IDs instead of
allowing both int / list and having a return type depending on the input
type. It allows to simplify code and delegate some processing to callers;
Introduce new API method
* ``_render_lang``: for each record id return the lang matching it;
* ``_render_field``: render a field of mail.template, on given set of record
ids. Usage: template._render_field('body_html', records.ids). Language
computation is available for this method;
Remove the "multi mode" support of rendering that either returned a rendered
value, either a dict based on given ids. Now all methods always work in batch
and caller have to fetch the correct result if necessary.
LINKS
Task ID 1963529
Community PR odoo/odoo#32397
stdout:
stderr:
closesodoo/odoo#48197
Error: could not apply b0c5370fd25... Revert "[FIX] web, purchase, sale: fix no currency in calendar view"
Hint: after resolving the conflicts, mark the corrected paths
Hint: with 'git add <paths>' or 'git rm <paths>'
Hint: and commit the result with 'git commit'
X-original-commit: e8d6f1eae0f4f9c0f4df78553b7d51a03087940f
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Jason Van Malder (jvm) <jvm@odoo.com>
Purpose of this task is to prevent users from setting portal users on
internal documents by mistake, and preventing noise and performance
issues resulting from loading all the portal users in those fields.
This commit fixes internal many2x fields to res.users which are now
restricted to internal users by setting domain (share=false) on form view.
closesodoo/odoo#47553
Taskid: 2172779
Related: https://github.com/odoo/enterprise/pull/9204
Related: odoo/enterprise#9204
Closes: #47553
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
ir.rule are default values but can be customized based on the
company's policy and needs.
This is typically a record that is in noupdate as should be
customization-friendly.
685f4eff50 added date_approved as
fields.Date.context_today
b5cea7e2b6 has changed the field
as a Datetime
Both together introduced a miss calculation of the date_approved
closesodoo/odoo#48055
X-original-commit: 6dff3024d19c9dd44c71992469540e3f09dd3247
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
Fixes#47727Closes#47955
Before this commit, it was possible to change the Vendor/Currency of the PO when Grouped by Vendor/Currency on Kanban view which is not Ideal Behavior.
Now we block drag and drop using these fields.
closesodoo/odoo#48050
X-original-commit: 7b19964a203c205b67d8f3bc05c1279362d38a61
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Purpose
=======
- Change the font-awesome icon from fa-book to fa-question.
- Change the icon color to text-secondary (the same than the multi-company
icon).
- Adjust the icon size to the uppercase text size.
closesodoo/odoo#47210
Taskid: 2209062
Related: odoo/enterprise#9116
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
1. Create a product A with 'Control Policy' set to 'On received
quantities'
2. Create a PO for 10 units
=> status is `no`
3. Validate the PO
=> status is `no`
4. Receive 5 units
=> status is `to invoice`
5. Invoice 5 units
=> status is `invoiced`
6. Receive the remaining quantity
=> status is `to invoice`
7. Invoice the remaining quantity
=> status is `invoiced`
There is an inconsistency between steps 3 and 5: there is pending
material to receive, but the status is different.
This is due to the fact the `order.invoice_ids` is checked, while it
shouldn't affect the computation of the status.
The status should be `no` in steps 3 and 5.
opw-2206447
closesodoo/odoo#47802
X-original-commit: 15330712d2ea3c16c57e01c236c783a6febd1376
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
For stock, purchase, repair and mrp modules, do a small clean of ACL:
Remove duplication and useless line.
Also improve the readability of the stock traceability report.
task-2172399
closesodoo/odoo#45055
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Purpose
=======
The current kanban view is messy. It is difficult to identify which
apps are installed or not. The user can completely miss a module
that might have interested him. A search panel would make things way
more readable.
closesodoo/odoo#44401
Taskid: 2181557
Related: odoo/enterprise#8144
Related: odoo/upgrade#879
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Purpose
=======
A 'book icon' link to the documentation of a feature has been
added in its settings panel, when it is useful (complex feature).
Add a nightly test that parses all the res_config_settings views
from the base one and checks that all documentation links are still valid.
Add the o_doc_link class to all documentation links to be able to easily
catch them if needed.
closesodoo/odoo#45813
Taskid: 2180574
Related: odoo/enterprise#8601
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
- Since 2c5022b4f3 , the action with
id:'purchase_order_action_generic' was unused.
- Since 7743af00bf , the action with
id='purchase_open_picking' was unused.
Co-authored-by: Victor Feyens <vfe@odoo.com>
Issue
- Install Sale and/or Purchase
- Create new order
- Debugger > Set Defaults
- Set default value for payment terms
- Quit and re-create
Default value is not filled
Cause
The default value is set but it's overridden
by a onchange
Solution
Remove the override who puts the value to False
OPW-2197940
closesodoo/odoo#45776
X-original-commit: 4d03e6dd81fab2aa12e3205106fd59758c6c90f6
Signed-off-by: Jason Van Malder (jvm) <jvm@odoo.com>
Issue
- Create new db with language en_CA
- Install Sales & Purchase
- Enable fr_CA
- Create a product & Save
- Edit the name & Save
- Create a quotation or RFQ
- Do not select partner
- Select your product
The description is still the old name
Cause
We try to browse a product with an empty
partner language
Solution
Use odoo.tools.misc.get_lang() in order
to fallback to a language is the partner's
one is empty
closes#44357
OPW-2196602
closesodoo/odoo#45620
X-original-commit: 4561b6bd4c2afab8ae29ced1a9085e6878a9921d
Signed-off-by: Jason Van Malder (jvm) <jvm@odoo.com>
Create a purchase order, confirm it and create the vendor bill. The
source document will be not filled.
Fixing the related variable and changing also the missing reference to
the partner
opw-2197272
closesodoo/odoo#45534
X-original-commit: 8498dbe10db87f718b9287f69188c627e36f98a3
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
RATIONALE
Mail template model holds a field telling odoo mail engine to automatically
add the current user's signature to the body. Its use depends on the use
case
* using the template in the composer on a single record: it is displayed
in the rendered template in the composer, meaning people could change it.
This behavior is interesting as it allows to see the email content;
* using the template in the composer in mass mail mode: it is not displayed
as only the raw jinja is displayed. It is therefore not obvious that it
will be appended to the body of the mail. People could add it manually and
have 2 signatures as a result;
A mechanism automatically adding a signature to sent emails when posting a
message is already implemented and is based on template existence. If a
template has been used when posting, no signature is added in sent emails.
Otherwise it is automatically added. This behavior should not change.
Behavior will therefore be
* use a template -> specify signature usage in it manually through jinja;
* do not use a template -> signature added in sent emails;
SPECIFICATIONS
Remove user_signature.
Update template body accordingly. In customer oriented templates that are using
it and do not already contain it, manually add a call to user.signature within
the jinja code. When set to False, just remove its declaration.
Quickly clean some signature integration.
LINKS
Task ID 2089252
Community PR odoo/odoo#39482
Enterprise PR odoo/enterprise#6459
Upgrade PR odoo/upgrate#761
Related: odoo/enterprise#6459
Related: odoo/upgrade#761
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Co-authored-by: Michaël Mattiello <mcm@odoo.com>
Co-authored-by: Thibault Delavallée <tde@odoo.com>
Before this commit the purchase_rfq action had two context keys
defined. One being empty {} and one with quotation_only set to
True. After this commit there is just one context (the one that is
actually used and applied) on the action.
Empty key added in 12.0 at 6138686d41b
Second key added in 13.0 at b5cea7e2b6closesodoo/odoo#44990
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
The filter for Purchase orders in the Purchase report did not filter out Sent RFQ,
despite the fact that they were not really ordered yet.
opw:2158248
closesodoo/odoo#44892
X-original-commit: 201cfb46462590bb2460bc76317e37742c789fae
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
1) Go to purchasing, and in the search area type "8888"
2) Click on the little arrow next to "Search Product for: 8888"
3) Select "[FURN_8888] Office Lamp"
4) Choose Purchase Order PO00009 which has FURN_8888 on the second line:
5) Choose Action > Duplicate
The 1st line end up with the searched product, not the original product.
This happens because the search add the context key
'default_product_id'. By chance the product.product model has a
'product_id' field which may happen to be not filled.
This cause the model api to look for a default value in the context and the
first line of the order get overridden.
Removing the specific key from the env solve the issue
opw-2188429
closesodoo/odoo#44802
X-original-commit: ed6ac9c63b4e8a5815e2f46693ababbde4a82919
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
if product have taxes and taxes_id field is empty
then it will fill the 'taxes_id', so price_total field
have taxed Total.
Task- 2093205
closes- #41681
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
purpose of this commit is when we import po with po lines
system expects from user to import all those requried fields manually.
Using sale's hack 'prepare_add_missing_fields' fix this issue.
Now we can import po lines in purchase too.
Task- 2093205
closes- #41681
This started from noticing that purchase somewhat oddly *removes* a
filter (internal_type='other') from a domain which is fairly
rare. Looking at the file histories didn't yield anything of
interest ("v9 accounting") but finally looking at the model revealed
an additional multi-company filter missing from both views.
After consulting with @qdp-odoo, @sle-odoo and @lap-odoo, no good
reason was found for the discrepancies:
* internal_type filter should probably always be there, unclear why it
would get removed from purchase
* whoever added the multicompany filter *probably* missed that it
would never be used because there was not one but two views
overriding it (differently)
* sibling "income" field, as well as the corresponding fields on the
product category, should match (though they were less incoherent).
closesodoo/odoo#44602
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
- Create a product A
MTO, Buy
Add a supplier S1 and set a specific reference
- Create a product B
MTO, Buy
Add a supplier S2 and set a specific reference
- Create a SO with A & B, confirm
- 2 RFQ are created
The first RFQ is created with the correct reference, but not the second
one.
This is because `display_name` depends on context keys: it is computed
once for both products with `partner_id` set as `S1`, while it should be
recomputed for product B with `partner_id` set as `S2`.
In order to avoid this, we use `with_prefetch()` to avoid reusing the
prefetched value.
opw-2176638
closesodoo/odoo#44564
X-original-commit: d96c1910be8f242455de9b443fc9db82155b4dd1
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
purpose of this commit is to make import template compatible with v13
task-2146510
closes-#42279
closesodoo/odoo#44375
X-original-commit: 37aadf1227531838ada7dc3810cf463379736e96
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
Aaron Bohy