Behavior prior to this commit:
When a PO is generated (via reordering rule, mto rule, or manual replenish),
the description on the PO line includes the internal notes.
Behavior after this commit:
The description on the PO line does not include the internal notes.
Note:
Per c324526ad0, the description on the picking also does not include
the internal notes (anymore), and the test has been updated to reflect
that.
opw-24222438
closesodoo/odoo#64883
X-original-commit: 5db67fb2931517ae94fe0396ef80e9ad997e59cd
Signed-off-by: Nicolas Galler <ngaller@users.noreply.github.com>
In order to easily compare delivery slip from vendor and receipt, vendor
product name and reference should be visible on the receipt operations.
The receipt description was just the name of the product before, it is
now taking the same description as the PO line, using vendor product
name and reference if it exists.
Task ID-2411544
closesodoo/odoo#62967
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
In case of RFQ with the "Ask confirmation X day(s) before" set,
the email send to the vendor give a link where he (portal user)
can change the date_planned of PO lines. But
the change wasn't done in the server side because the
`_update_date_planned` (of stock_purchase) doesn't call super if
there isn't a linked move (none in case of RFQ).
Call super also in case there isn't any moves.
close#59040closesodoo/odoo#63629
X-original-commit: b29ac84fd55923abf582cdee39cb32bacda3eec9
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
Issue
- Install 'Accounting' module
- Create a new 'Tax' X with a fixed price (e.g.: O.O57 $)
- Create a new 'Customer Invoice'
- Add a product P and set unit price to 0 $
- Set tax X to product P
Total tax amount : - 0.06 $ .
Solution
The sign must be forced to a negative sign in case the balance is on credit
to avoid negatif taxes amount.
enterprise PR : https://github.com/odoo/enterprise/pull/15035
opw-2378978
closesodoo/odoo#62758
X-original-commit: 684855529e8aaafa0cb90f958d19c563d6e2a897
Related: odoo/enterprise#15105
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: bon-odoo <nboulif@users.noreply.github.com>
STEPS:
* Create a BoM with two components purchased the same vendor, but with
different "Delivery Lead Time". First component must have lower value
* Create Manufactoring order, Mark as ToDo
* Open created purchase order
BEFORE: Order Date is equal "MO planned day MINUS delivery lead time for the first component"
AFTER: Order Date is equal "MO planned day MINUS maximum amout delivery lead
time for the components"
---
opw-2388031
closesodoo/odoo#62411
X-original-commit: 8f0cc3609ce7a02d0e3f39586a7b0299ab221d48
Signed-off-by: Ivan Yelizariev // IEL <yelizariev@users.noreply.github.com>
During a return the purchase_order_line field is propagate, order_line.move_ids include returned move, that why use returned_move_ids is not mandatory.
closesodoo/odoo#35878
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
1. Create a storable product
2. Set the category: Costing
- Method: First In First Out (FIFO)
- Inventory Valuation: Automated
- Price Difference Account: Price different accounts.
3. Create a vendor bill with the product and the quantity set as 0, and set a tax
4. Post the vendor Bill
A ZeroDivision error is raised.
opw-2375464
closesodoo/odoo#62120
X-original-commit: beeb83ca53c52dc189faaff4d76711bbcf24a08c
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
- Create a product P with a MTO Reordering Rule (Buy Route)
- Add a supplier to P with a specific vendor code
- Create a SO for 1 unit of P, validate
A PO is created for the supplier but without using the vendor code.
It happens because the vendor code is overridden by the product
description.
To avoid losing information and redundancy, we add the line description
only if different from the product name.
opw-2383418
closesodoo/odoo#62037
X-original-commit: 0b138ffa5a1b2b03f03fb5dc51994a3bfc4e5dea
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
The open_action_with_context was not using _for_xml_id, producing an
error when reading the action content.
In open_action, the action_name was taken from the context and needs
sanity checks. Ensure only actions from the account module can be
read and only if the user has access to the target model.
This is a limitation of the previous behaviour but, at the moment, all
known calls are made refering to an action from the account module.
Limit the scope of this method while the 14.0 is still early to avoid
having a door open to ready any action, and difficult to close later.
Remove old action fetching from the context in create_move that is no
longer used.
closesodoo/odoo#61602
X-original-commit: a39e94f7e4dc74e850650ac90bbc5f85af130bc8
Related: odoo/enterprise#14695
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Co-authored-by: Xavier Morel <xmo@odoo.com>
Purchase
- When a RFQ is in "To Approve" stage, on the printed pdf, keep "Request for Quotation" as a title
- "Send Reminder" action should open the composer when triggered manually.
Inventory
- In tree view of transfer, set date_done optional = hide
- In (mobile) picking view, replace button text with 'add a product'
- fix Vendor Group by in Replenishment report
- Warning message when changing product tracking from untracked to tracked
MRP
- Reporting > Manufacturing Orders : change measure for total quantity grouped by scheduled date = month and by product
- Reporting > Work Orders : change measure for Duration per unit grouped by workcenter and by product & add unit (minutes)
- Reporting > Overall equipment effectiveness : group by loss reason added to the current group by workcenter
closesodoo/odoo#57036
Related: odoo/enterprise#12926
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Commit 0f80e69b8d tracked all changes on
qty_received on the purchase order. But did that wrongly by calling
`write` inside a compute.
Commit b7cc3b068f685d1339f9fe7e47d0c564de1708e7 fixed this `write`
by an `=` to avoid error when the compute is called on virtual records.
This fix result on forgetting to track the quantity delivered.
This commit sends a message to post in `write` AND in the
`compute_qty_received` to be sure it is posted. This way, we do not call
write in compute anymore.
closesodoo/odoo#60067
X-original-commit: 3d592649970df3d755ccb57d68c074acdff67894
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Calling write in a compute won't works (and shouldn't) if there is any
automated action in the model. fix this issue in the
compute of `_compute_qty_received`.
task-2351175
closesodoo/odoo#59421
X-original-commit: b7cc3b068f685d1339f9fe7e47d0c564de1708e7
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
When a Purchase Order is created by the replenishment report, doesn't
pass the origin ("Manual Replenishment" or "Replenishment Report").
task-2328830
closesodoo/odoo#59398
X-original-commit: 170729ee58b199041d7545e7789ac9474e86f998
Related: odoo/enterprise#13876
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
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>
Previously, when no on-time delivery data, we should 100%. Now we show
"No data" to make it more clear.
Task 2346121
PR #58653
X-original-commit: 8179dd974f23d8bb8c15e0ab72072fffb0866b38
Before this this commit there would be `ZeroDivisionError` if product is archived.
Steps to Reproduce Issue:
Create product with AVCO and Automated Valuation
Create PO and Received all Quantities
Archive Product
Create Bill and Post
There will be Traceback
```
File "/data/build/odoo/addons/purchase_stock/models/account_invoice.py", line 84, in _stock_account_prepare_anglo_saxon_in_lines_vals
valuation_price_unit = valuation_price_unit_total / valuation_total_qty
ZeroDivisionError: division by zero
```
Now we consider Archived `stock_valuation_layer_ids` as well.
closesodoo/odoo#59317
X-original-commit: bedbc577d13148527fa9bab104eaf67b3ffba34f
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
- Create stockable product P: FIFO, Automated Valuation
- Set the price difference account
- Configure Decimal Accuracy for Product Price to 6 digits
- Create a PO
- Add a line with:
Product P
Quantity: 100,000
Price unit: 0.005
- Confirm the PO, receive the product and create the invoice
- Set a price unit of 0.006 on the invoice line
- Post the invoice
No price difference booking is generated, while a price difference of
100 should be created.
It happens because we compare the price units with the currency
precision.
Comparing the price units, even with the proper Product Price precision,
is not a good idea. Indeed, in case discounts are applied the price
unit computed ends up with a larger precision.
As a solution, we check if the subtotal of the journal entry is
different from zero.
opw-2341181
closesodoo/odoo#58364closesodoo/odoo#58888
X-original-commit: 654be58894c51d2c5384ead67a5a7c68fdebf0a7
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
- Create stockable product P: FIFO, Automated Valuation
- Set the price difference account
- Configure Decimal Accuracy for Discounts to 5.
- Create a PO
- Add a line with:
Product P
Quantity: 10,000
Price unit: 100
A tax
- Confirm the PO, receive the product and create the invoice
- Set a discount of 0.92431 on the invoice line
- Post the invoice
The journal entries for the invoices contains the price difference move,
the amount must be 9,243.10 but is 9,200.00.
In case taxes are defined on the the invoice line, we call `compute_all`
which will round the `price_unit`. In this case, we don't want to round
it.
Fixes#56832
opw-2329028
X-original-commit: 286ea6b681e9ba77357f91b546052449f6342f20
The original feature was introduced in commit #8248f0e153a and works
well for internal transfers, but fails for dropship.
For latter, if quantity is changed on confirmed PO line, new picking is
created, even if the quantity was decreased not increased, leaving the
new draft picking empty.
closesodoo/odoo#57893
X-original-commit: 77a96b2dd0fab4c6b6136d0f23422d8a2bc68bca
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Was not super visible, especially without HR as the dialog immediately
closes (limitation of the web client), or when an administrator user
massively disables totp.
Show a toast notification indicating the success of the action.
Also fix the logging of `totp_disable` so it correctly handles being
called on more than one record, and change the logging data to
<browse_record> (<logins>) across the board.
Also add a way to provide an action to execute after a notification:
by default nothing happens, which leads to dialogs not closing and
forms not reloading, and there is no good way to show a notification
and/then do some other thing, which is inconvenient.
Mainly transifex issues but also some errors found through 'grep' checks.
Fix typos and obscure english strings in xml contents, fields strings/helps, some docstrings, ...
ensuring correct translations base (and fallback when translations isn't available).
closesodoo/odoo#57276
X-original-commit: 4214f05d454bca2b60fda3a288d529c098e84f77
Related: odoo/enterprise#13053
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
With:
- Anglo-saxon activated,
- Costing Method: FIFO,
- Inventory Valuation: Automated.
Create a PO for product AAA, receive the product and archive it,
create and try to POST the vendor bill.
> This lead to a ZeroDivisionError: float division by zero
The anglo-saxon entries cannot be generated as the product
is not valued anymore.
This commit is displaying a clearer error message for end users.
more info from SLE on 2250451
opw-2307562, 2317338, 2320080, 2311843
Fine tuning of https://github.com/odoo/odoo/commit/8ce4db8ca04cd8e5266fc186b35deef76506da46closesodoo/odoo#57016
X-original-commit: 83239af1d396cf7f5aca37e33445405238fcfc48
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Co-authored-by: simongoffin <sig@odoo.com>
PURPOSE
Clean code. Be more performance oriented.
SPECIFICATIONS
Improvements applied in this commit
* not all() --> any(not) for earlier returns;
* all([generator]) --> all(generator) to avoid unnecessary list casting.
This code construct is better managed by all;
This commit will probably not have a big performance effect on standard
production databases. However each performance and cleaning improvement
is welcomed.
LINKS
Task ID-2328619
closesodoo/odoo#56810
X-original-commit: 1cc6bb1231401ea7f501d2f5b5e9641ec8734850
Related: odoo/enterprise#12802
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.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>
- 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
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.*
Replace wrong usages of any(list|recordset), by any(generator)
to speed up computations, avoiding list creations and/or looping twice on a recordset
for nothing.
any([generator]) => any(generator)
any(filtered) => any(generator)
closesodoo/odoo#55768
Related: odoo/enterprise#12360
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Before this commit, when we manually create a PO line, the
propagate_date will always be false. So the change on scheduled date
will never pass to corresponding move.
After this commit, when create a PO line, if no propagate_date for it,
we find if the product has a route with a buy rule. If yes, use the
setting on its first buy rule, if no, set the default to be true.
Task 2298950
PR #55155
Add an easy way to not post the entries in the future when calling
post() on it, but rather set it to be auto-posted at accounting date.
This is useful when we are creating a lot of entries in batch and some
might be in the future, some in the past, and we don't want to separate
that in two batch every time. (asset, accrual, transfer,... )
Some PO lines could be ignore during _run_buy and _find_candidate.
It happens since the sorted only take a function and a string do
nothing.
Close#53247closesodoo/odoo#55011
X-original-commit: 09d77ff467a3ce5cde78da7e153d33d881fb9b87
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
- Create a product with routes MTO + Buy.
- Create a vendor pricelist with a minimum quantity:
Min. Qty 1000 for 10 USD
- Create a SO, sell 1000 quantity
=> A PO is created automatically in draft.
- Go back to SO and update quantity to 1200.
The following message pops up: "There is no matching vendor price to
generate the purchase order for product..."
We select the supplier based on the procurement quantity, which is lower
than the minimum quantity of the supplier.
To avoid this situation, we fall back on any supplier like it was the
case in v12.
opw-2297001
closesodoo/odoo#54526
X-original-commit: 4d4913fc366dcd62740b91eda3aa3f81270affda
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Issue
- Install English and French languages
- Create a customer contact and assign french as his language
- Create a product with correct names in both languages.
For example 'French product name' and 'English product name' for easy reference.
- Create an inventory transfer with the french customer as contact
- Add the product that you created
- Print > Delivery Slip
The report will show in the lines:
"""
French product name
English product name
"""
Cause
Getting product description without checking partner language.
Solution
If partner is set, get product description with partner language in context.
opw-2280490
closesodoo/odoo#54061
X-original-commit: cebe2cf57e68e2d1d54cd442aff6ba7d9554d043
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Signed-off-by: bon-odoo <nboulif@users.noreply.github.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
1) Before this commit, propagate date on 1st receipt move was always False
if PO was created manually.
After this commit, move will be assigned with propagte_date of buy
route of warehouse only if there is not move_dest_ids.
2) Default settings on routes as -
1) If receipts in 3 steps > the alert on the receipt
(+ propagate) and the propagate rescheduling on the followings
2) If receipt in 1 step > the alert on the buy rule
(no propagate rescheduling)
Task-2209541
closesodoo/odoo#51853
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Support two new syntaxes with `_()` method:
_("This is so %s") % 2019
_("Text with %s placeholders", 42)
_("Text with %(num)s placeholders %(symbol)s", num=42, symbol="🧀")
The main benefit is to have a fallback on the source string if formating the
translated string fails (e.g. "Foo %s" translated "Foo s%").
This PR converted most (but not all) calls to _ using placeholders to use the
new syntax. Hopefully, the remaining ones will be converted in the future and
avoid technical debt.
Use named placeholders when needed. If more than one placeholder is present in a
string, using named placeholder can be beneficial to reorder the placehodler
position (for languages like Japanese that do not use the same phrase
construction). On some sentences, it also brings clarity on the meaning of the
placeholders.
closesodoo/odoo#52155
Task-id: 1853119
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
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.
This commit makes it so products can be replenished without any other
module. This is achieved by adding a "pull" rule to the default receipt
route generated when a warehouse is created. "Pull" rule is added to 1-,
2-, and 3-step receipt routes. Previous to this commit, an additional
module (e.g. purchase, mrp, etc.) was needed for a pull rule to trigger
with the existing receipt route rules. Replenishments can be triggered
via "Replenish" button in product form, recording rules (auto trigger),
and replenishment (manual trigger).
Additionally, this commit makes it so when other modules (mrp, purchase)
that handle replenishment are installed, this additional "pull" rule is
removed from the default receipt route to prevent undesired behavior
(e.g. MTO manufacturing components magically being received from no
where). Unfortunately this means 2 undesirable situations:
1. If a user adds adds/changes rules to the receipt route and then installs
mrp or purchase then their additions/changes will be removed.
2. If a user removes either (when only 1 installed) or both of these
modules then stock module will again not be able to replenish as the
pull rule will not be re-added to the receipt route.
It is expected that these 2 cases do not need to be handled in most
cases or can be handled by advanced users.
Stock tests have also been updated to accomodate this new pull rule.
Specification 4 of overall inventory onboarding improvement task.
Task: 2220129
Related Enterprise PR: odoo/enterprise#10719
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>
Add on-time delivery rate to vendor. When editing a PO, user can see
the overall on-time delivery rate during the last 365 days next to the
vendor. When click it, user will be redirect to a graph view showing
the detail of the on-time delivery rate of this vendor. Also add a stat
button to show the on-time delivery rate on partner form.
Task: 2230811
PR: #49921
Before this commit, after install purchase_stock, old pol records won't
update their qty_received when receive products. This is because their
qty_received_method are not updated during the installation.
Task 2230811
PR #49921
- Set two companies (A and B);
- Set intercompany flows enabled between company A and B with
synchronization of PO/SO;
- create a product X is configured as follows in company B:
- Storable product;
- Routes “Buy” and “Dropship”;
- Vendors price list set with vendor = company A.
- Product X is configured as follows in company A:
- Storable product;
- Reordering rule Min 0 / Max 0;
- Route “Buy”;
- Vendors price list set with vendor = 'External Vendor'.
- Create and validate a sale order for product X to final customer
within company B; Odoo will automatically create a purchase order for
product X to company A within company B;
- Validate the purchase order in company B; Odoo will automatically
create a sale order for product X to company B within company A;
- If there is no available stock in warehouse A; Odoo will automatically
create a purchase order for product X within company A.
Before this commit, the purchase order is created with vendor as
'Company A'. As '_select_seller' is run in sudo mode (see:
https://github.com/odoo/odoo/blob/a16c4a0dabe58ab2cfade353c113387ae5bcd572/addons/stock/models/stock_rule.py#L458),
so is not company-aware, therefore the first matching supplier is
chosen.
Now, the purchase order will be created with vendor as 'External Vendor'.
opw-2255989
closesodoo/odoo#51596closesodoo/odoo#51908
X-original-commit: e2dd8ea7544fba659810ba829433fce7099c1d40
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
- Create a dropship product
- Set a supplier
- As a portal user, buy the product on the eCommerce
The portal user is added as a follower of the PO created.
This is a side-effect of `sudo` keeping the current user and the
following adding the current usr as a follower:
https://github.com/odoo/odoo/blob/96b0dcf9e51f5a924e2cbf618c2ee5462cc1f03f/addons/mail/models/mail_thread.py#L262
When the PO is created from a procurement, the current user might not
have access to the Purchase app. For example, the user might only have
access to Sales. Therefore, there is no need of adding him as follower.
opw-2249357
closesodoo/odoo#51895
X-original-commit: a561ad050e0c8cfe1dafb699c4c84c7c39bf777d
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
render, render_template, load, activity_schedule_with_view,
get_website_pages should all be private:
It should not be possible to render an aribtrary template only with
its name or id
Still need to render some qweb views from js so the method
render_template is kept public.
This explains why the website editor still need read access on
ir.ui.view as we want to allow any snippet to be rendered.
Nicolas Galler