Previously, when compute on-time delivery, we compare the date_planned
on PO line with the date on stock.move. Since they are both datetime,
the product that delivered on the scheduled date may be considered delay
because of the 'time' part is late, which is normally not what we want.
In this commit, we only compare the date part of them to decide whether
it's late or not.
Task 2346121
PR #58653closesodoo/odoo#59386
X-original-commit: 86af7c647fe56f776c6cebc22dd5856577878980
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Before this commit vendor's currency wasn't used on creating an invoice if there
is default journal in context. As I understand, the idea was to let onchange("journal_id")
handler to update the currency. It works well, if journal has the same currency
as specified in vendor record (res.partner). But it confuse users in following
scenario:
* there is just one vendor journal
* vendor is configured to invoice in another currency
* then, if you create invoice via "Accounting >> Overview >> Vendor Bills", it
would have journal's currency
* while, if you create invoice via "Accounting >> Vendor >> Bills", it
would have vendor's currency
This commit force to switch to vendor's currency on changing vendor field, even
if it differs from journal's currency. If after changing vendor, you set another
journal, then journal's currency is used (thanks to onchange("journal_id") handler)
opw-2339966
closesodoo/odoo#59162
X-original-commit: 513cc1abe121cd05623be1a6519239f8f4b3fb48
Signed-off-by: agr-odoo <agr-odoo@users.noreply.github.com>
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Steps to reproduce the bug:
- Create a purchase order P with one line L
- Set a tax of 10%, a quantity of 1 and a unit price of 100€ on L
- Save P
- Edit P and change the unit price of L to 120€
Bug:
The amount_tax was not updated until you saved
opw:2341757
closesodoo/odoo#58912
X-original-commit: d7598086b8ac642f2cfe497ab6e33e380edb244a
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Before this commit, `stock.warehouse.orderpoint` `_compute_qty` didn't
depend on `purchase.order.line` (POL). This means when a relevant POL
was edited/cancelled, then the `qty_forecast` wouldn't correctly update.
To reproduce:
- Create a product w/ a vendor and buy route active,
- Go to replenishment report, create a reordering rule, and hit
order for product (RFQ should be created)
- Cancel the RFQ and go back to replenishment report
The product should reappear in the list view, but does not because it's
`qty_forecast` has not updated and therefore has not updated
corresponding `qty_to_order` value.
Note string rename of `purchase_line_warn` 'Purchase Order Line' =>
'Purchase Order Line Warning' is due to repeat label use issue. It is
better to rename the poorly labeled `purchase_line_warn` than to give a
hacky label for new One2many field.
Task: 2285912
Manual forward port of: odoo/odoo#56580 due to migration test error
closesodoo/odoo#56625Closes: odoo/odoo#56625
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Currently, if users try to send invoices / quotations / purchase orders to
themselves in order to look at final result, they can't do so because our
default chatter protection prevents sending mails to authors themselves.
This commit uses 'mail_notify_author' context key and allows users to send
mails from the header buttons available on SO / PO / invoices to themselves
if they are in recipients.
This commit targets only those buttons as this is the main case where we
want to allow people to send emails to themselves. In order to avoid
side effects no other use case is supported.
Task ID-2294130
closesodoo/odoo#56370
X-original-commit: 08c0dc929da38595e29a9d1db93065547cd98ad1
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This provides a better API to search for records by name without the
formatting part (`display_name`).
This also simplifies all the overridings of `_name_search` that no
longer need to call `name_get()`. The call to `name_get()` is done in
method `name_search` in a generic way.
- Avoid to truncate the hour/min/sec in the computation of the
effective date which is related to the `date_done`
of the first incoming picking.
- With manufacturing in 3-step (pbm_sam), the store picking
had a source document == "New". It was the case because
the `_get_move_finished_values` was call before the create
and the name is set only on create.
To fix this issue, during the `create` set the origin of all move.
- To avoid to maintain old views unused,
remove unused view of stock move.
- The computation of the products_availability json is too expensive
to be in tree view (2.5 times long with it) of picking.
It will be hard to optimize because the half the time
is due to _get_report_lines method - already in batch (on 80 records).
- Review buttons of the replenishment list to be more Odooer.
- In some cases the delay alert date was wrongly compute:
- If we new dest_move_ids of a existant move, the delay alert date
won't be compute.
- If the state (to done) and the date are save in same write call
the alert date of next move won't be reset.
To avoids these issues, refactor the alert date to be a compute stored
fields.
- To avoid any confusion between date expected in the replenishement
(in date) and the purchase order receipt date (datetime),
we put the receipt date at the middle of the day.
Also On-Time Delivery Rate computation counts
only when date are bigger effective date trunced to date.
Also used the timezone of the company by default (if not user timezone)
task-2246665
closesodoo/odoo#55379
Related: odoo/upgrade#1586
Related: odoo/enterprise#12309
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
- The deadline of MO generated via procurements is calculated differently.
Now, it doesn't take anymore in account the manufacturing_lead
of the company (Security Lead Time of MO). The computation of planned date remains unchanged.
- The date_expected fields was duplicated with the date fields
except when the move was done. Merge both fields.
The only information lost is: we can't know what was the
scheduled date before processing move (`state` == done).
Indeed, the date becomes the actual move processing datetime.
- The `date` in `stock.picking` field contained the time of
(purchase) order `date_order` (`purchase.order`).
This field is was wrongly used in the kanban view where we
expected to see date_planned instead. Also, the `_order` used
this date instead of date_planned too.
- The `delay_alert` is activate independently of stock rules.
Then it is now activate in all case.
- Remove the auto-reschedulting process of stock move via
the stock rule (`propagate_date` and `propagate_date_minimum_delta`).
Replace it by a automatic deadline date (`date_deadline`) propagation.
The deadline is the promise done to/by vendor/client (SO/PO)
then it is a readonly fields on picking/move and MO.
- Now the Scheduled date (`date`) of stock move is never propagate
and it is only related to the Scheduled date of
related document (MO or picking).
- Now when a move is created from procurement (sale),
`date_planned` = `date_deadline` - `security_lead`.
- The `delivery_date` of sale is no editable after confirmation
and propagate as the deadline to related stock move linked to order_line
- Adapt filter and decoration of MO and picking.
- Because we are the client in case of purchase (PO), the promise of vendor
can be not respected. Then we add the lead security to the deadline
(inverse the sale order logic) of PO picking (promise reciept date
+ security lead) to match with the replenishment.
task-2246665
- MO/picking/PO/stock.move have now the "same" `priority` fields
(Boolean logic: Normal or Urgent).
These models are now sort by priority first. Note that the priority field of
stock move is a technical one.
- For MO and picking, the set of `priority` field change priority of
the related stock move. The prioriry field on stock move is
used by the scheduler for reservation ('Urgent' before 'Normal')
- The Stock Replenishment Report also take in account the priority
to be consistent with the reservation.
task-2246665
Use _for_xml_id to replace all the self.env.ref().read()[0]
This has the advantage of having a single point of control and to add
the fields filtering and model verification.
Add sudo for other operations on ir.actions.*
This commit removes "state = purchase" in account move attrs domain. The purchase state doesn't exist.
This commit adds a related field to purchase order in account move line.
Task ID: 2312024
closesodoo/odoo#55611
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
In stock:
1. remove string of action_show_details button, only show icon
2. late filer have been megered with planning issues filer,
update the name. (also in mrp)
3. add width to json_lead_days_popover field to show it properly
4. change inventory adjustment empty screen image.
In purchase:
1. in reminder mail, show "undefined" when no date. This will
only be shown in preview. When no date, we won't send reminder mail to
the vendor.
2. remove old book icon for document in setting.
3. check if there is date_planned when craete a confirm date url
4. RFQs late filter now show all late RFQs with in state "draft",
"sent", and "to approve".
5. improve the the words in KIP and empty screen and list view
Task 2298950
PR #55155closesodoo/odoo#55740
Related: odoo/enterprise#12344
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Issue
- Accounting & Purchase
- Create a PO for wood corner
- Create a bill for wood corner, add a ref
and auto complete with the previous PO
The ref is replaced by the PO's one
Cause
In purchase account_invoice _onchange_purchase_auto_complete
we update all the bill values with the PO values including
the PO ref (empty or not)
Solution
Exclude the ref of fields to be updated
OPW-2313418
closesodoo/odoo#55560
X-original-commit: ae0c3b600403a21a196e51ce88fa6b25990f2b64
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
By specifying the with_company at a higher level:
1) The risk of multi-company conflicts decreases
2) We allow customizations to use _prepare_* methods to potentially
create records in other companies when needed.
closesodoo/odoo#55192
X-original-commit: 33c767e1778d2b1fc83aaaea92c3c2aa008b9520
Related: odoo/enterprise#12105
Signed-off-by: Toufik Benjaa (tbe) <tbe@odoo.com>
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
1. Show only date not datetime on update portal. When update the
scheduled date, set it to be the last minute of that date.
2. Send updated date immediately when user pick a date.
3. If an activity for update the date already exist, update the
note instead of creating a new one.
Task #2265912
PR 52809
When more than one parameter is present in a message, it helps the
translation to use named placeholder. This way, the order can be
changed. It also helps the comprehension of the message.
Using a few regex like
\((_\(.*%s.*)(\) % )([\w\[\]][\w .\[\]\(\)'"]*)\)
($1, $3))
Old syntax is still compatible but starts the migration to the new
syntax that catches error.
When set scheduled date on PO line, set it to be the last minute of
that day to correctly decide the late of the receipt.
Task 2265912
PR #52693
Related: odoo/enterprise#11034
Related: odoo/upgrade#1323
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Some change to imporve reminder mail usability:
1. Scheduled date on POL of the PO form now is always editable.
2. Improve tooltip for the reminder email
3. don't show number of days when reminder email not checked on
both PO and partner form.
4. only show "confirm receipt date" button in debug model
5. In the mail, format date by partner.lang
6. Add button to send preview reminder mail
7. On default, receipt_reminder_email on res.partner is False
8. merge expected_date with date_planned (done by FP)
Task 2265912
PR #52693
1. automatically send a reminder mail to vendor to confirm the receipt
date. If confirmed, (confirmed by vendor) will be added next to the
receipt date. If not, vendor can update the date on the portal website.
An warning activity will be set for the purchase representative for this
update.
2. Vendor can also comfirm recieption of the PO when we 'send PO by mail'.
If confirm, (confirmed by vendor) will be added next to the confirmation
date. An filter is added in the PO search view to show all unconfirmed
PO.
Task 2230811
PR #49921
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Merge account_analytic_default into account
Merge account_analytic_default_hr_expense into hr
Merge account_analytic_default_purchase into purchase
Prevent having to manually install default modules after activating analytics
closesodoo/odoo#50816
Task: 2182900
Related: odoo/upgrade#1186
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
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
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>
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>
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
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>
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
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>
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>
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>
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>
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
yhu-odoo