Hide the forecast widget in case of kits. Indeed:
- the forecast report doesn't support kits
- the semantic for a kit forecast is far from being obvious, especially
in case of partial deliveries, returns, returns of returns, etc.
Better hide it than displaying an incorrect information.
closesodoo/odoo#61522
X-original-commit: c1fccaee5dd676f2fe07bb5c17eb2967ee6b742e
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
date_deadline of the stock move has been reviewed:
- Now, it represents the datetime when the operation must
be done to be in time for the uppest document (SO/PO/MO/RR).
- At the creation of stock move the date_deadline is computed in
the same way than the sheduled date expected that it is not include
security days (inverse the logic for PO).
- When we update the delivery date (or lead time) of SO (or PO).
The deadline of related stock move is updated and the delta is propagate
between origin and dest moves.
task-2324039
Change the default rouning digits of all UoMs to be two, also change the
decimal.precision of UoM to be two. Adapt all the tests.
Also to avoid hardcoded digits in `should_consume_qty` widget.
PR #56000
X-original-commit: 460ec0402a2352a5b179d81935f7230f6bc97cb7
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>
- 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
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>
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,... )
Improve onboarding by removing the replenish on order route.
Companies that do MTO process could unarchive the route in
order to have a basic configuration.
closesodoo/odoo#55147
Task: 2245882
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
l10n runbot builds are all failing when running at least one test depending of AccountTestCommon because it:
- doesn't create a sandboxed testing environnement to manage the multi-currency, multi-company, the default company's currency, the exchange rates...
- doesn't setup a testing user then all tests are done using the superuser.
- doesn't provide a fully setup chart of accounts: exchange difference journal is not set, accounts have bad types, etc...
- is run sometimes at-install.
--task: 2301180
This commit fixes all issues detected by the new pylint
gettext-variable test.
It converts some calls to the new syntax
_("Foo %s", bar)
to progressively migrate the code to the new syntax.
A few calls were not technically incorrect but still detected by the
linter.
_("Foo" +
"Bar")
has been converted to
_("Foo"
"Bar")
as it has the same effect and make sure the argument is of type
asteroid.Const instead of BinOp).
closesodoo/odoo#53683
Related: odoo/enterprise#11467
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
- Create 4 products A, B, C, D
- Create a product AB, which is a kit made from A & B
- Create a product CD, which is a kit made from C & D
- Create a product ABCD, which is a kit made from AB & CD
- Create a SO with 1 unit of ABCD, validate
=> a picking with A, B, C and D is created
- Validate the picking
The delivered quantity remains zero on the SO.
This happens because we don't find any `relevant_bom`. Indeed, the
`bom_line_id` written on the stock moves correspond to products AB & CD,
but they do not correspond to ABCD.
We fall back on the 'all-or-nothing' policy.
opw-2273392
closesodoo/odoo#53091
X-original-commit: 972eab4bcdcc9ee246621a6991d064f96ccd5ccb
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Now, by default, a Bill of Material have a flexible
consumption instead of strict consumption. Also
add new consumption choice: a flexible consumption
but with a warning when the bom isn't respected.
Also, now, the strict (a new warning option) consumption
is checked only when we try to mark as done the MO.
task-2241471
Allow to "backorder" a production, meaning create another manufacturing
order with the quantity remaining to produce. We also use the
reservation of the first order on the next ones by using
`post_inventory` on the first one and moving the newly created stock
moves to the backorder.
We introduce a wizard similar to the one in stock.
Backorders have a sub-sequence.
Backorders are linked together through the procurement group.
We allow creating a backorder even if workorders are running by closing
them, the backorder will call `button_plan` and create its own.
task-2241471
Usecase : sell a mto/manufacture product. Confirm the sale order.
Cancel the delivery and the production then
duplicate the delivery.
- if the delivery was cancelled before the production, another
production is created.
- if the delivery was cancelled after the production, no other
production is created.
In the second case, the production cancellation will reset the procure
method of the delivery. The duplication will not trigger the mto
procurement.
This commit will override the procure method of each cancelled moves and
set it to `make_to_stock'. This way, we have the same behavior independently of the flow.
Task : 2212125
closesodoo/odoo#48366
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
In the same xml file (meaning one of the two rule is useless, or wrong
if giving less rights than the other).
Removing rules that had no impact will ease the understanding of
security problems, by reducing the number of interconnecting rules.
- Activate Dropshipping
- Create 3 products: KIT AB, A, B
All have the Dropship route and a supplier set
- Create a BOM of type kit: KIT AB is composed of A & B
- Create a SO for 1 unit of KIT AB, validate
- Validate the created PO
- Deliver the products
The delivered quantity remains zero.
This happens because the `bom_line_id` was not written on the
`stock.move`. Indeed, the latter is created from a PO, not from a SO.
Since the PO doesn't have a `bom_line_id` field, the information is
lost.
As a solution, we apply the 'all or nothing' policy in case of
dropshipping.
opw-2207118
closesodoo/odoo#47014
X-original-commit: 6016476952f53097f8b04f34bdbaf09c12e431fe
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
In case of MTO (+buy) on products used in a MO,
add the link between the MO source and the PO generated.
Also add links between MO's when MTO+manufacturing.
task-1913392
closesodoo/odoo#43366
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
In case of MTO+Mufacturing on product in a confirmed sale order,
add a stat button to the MO generated by this SO. Also add the inverse,
from MO to SO source document.
task-1913392
Previously when the BoM on a product do not have components but only
services. Then during scheduler a log was posted on the product explaining
that components are required.
However since this process is possible in another usecase it should be
possible with procurement. The only difference is that procurements
confirm records in order to propagate. In this case since there is
no components and services are not propagate with procurements, it's
not needed to confirm the MO.
closesodoo/odoo#43133
Task: 2170845
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Since revision cb618e9a99, `previous_product_uom_qty` is not
set in the context anymore but passed as parameter.
opw-2146706
closesodoo/odoo#42820
X-original-commit: 33741910e32680e644e2509d108b0cd4a4138013
Related: odoo/enterprise#7565
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Without demo data, for the odoo-master transifex project
closesodoo/odoo#41935
X-original-commit: dab7670b73506fb3a835695ee3bd735e0c5e5c2b
Related: odoo/enterprise#7287
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Followup of a425695e
The terms were back in 12.0
Courtesy of Juan José Scarafía
closesodoo/odoo#41624
X-original-commit: 85d0c7001a997748d7691205bbb8d066597591a5
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
followup of rev [0]
If these wizards are called on multiple pickings, display the list of
the pickings that could be impacted and allow to select which one should
be impacted.
We also adapt the sanity checks at the start of `button_validte` in
order to specify the concerned pickings if needed. We do not enable the
multi behavior for batch at the moment, so it's only enabled for the
validate multi in the list view.
[0] 6ab4b0d496
task-2069646
closesodoo/odoo#41497
X-original-commit: ff276c6484b138982f185ec9c832f2dbf25baaef
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Overwrite the method ``write`` of the model ``product.product``.
When we write on ``standard_price``, if
- the context key ``disable_auto_svl`` is not set
- the ``cost_method`` is not "fifo"
We automatically compute ``stock.valuation.layer``
(before we needed to manually call ``_change_standard_price``)
Task #2031422closesodoo/odoo#41265
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Before commit: - If there are multi level production order,
and user cancelled any one then,
there is no activity logged on related production order.
After this commit: - In multi level production order
(i.e. one production order creates another production order
to consume the raw material)
if user cancelled raw material production order then,
exception will be generated on main production order,
so that user can easily get the idea that
raw material for this production order is not available.
[ADD] sale_mrp: add testcase for cancellation of the multilevel production orders
task-1819526.
closesodoo/odoo#28708
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Following 40487aca5c there was an issue
where a delivery could be splitted because of mrp specific code.
This test checks that when creating a sale order including a level 3
bom (MTO) the delivery is one, containing the correct products
closesodoo/odoo#36961
X-original-commit: c07ecea7923c1609c4461fadbc61040e9fd3d86a
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
This commit removes 'location' and 'warehouse' from the api.depends_context
of _compute_quantities() as:
1. They are not needed. They are never changed in a single transaction in the current code
2. The ORM doens't support the fact that they are sometimes passed as list instead of integer
closesodoo/odoo#36788
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Slovenian language, as many others languages, is not present in the
beta/master projects in Transifex.
For some reason, Transiflex removed all current translations, this was
already fixed in 12, but as there are not automatic forward-port for
translations, this is a manual forward-port.
opw-2060055
closesodoo/odoo#36374
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Task 2041865
We want to show a hierarchy to ease the account type selection (hack in the select widget)
BALANCE SHEET
ASSETS
Fixed Assets
Non-current Assets
Current Assets
Prepayments
Receivable
Bank and Cash
LIABILITIES
Equity
Current Year Earnings
Non-current Liabilities
Current Liabilities
Credit Card
Payable
PROFIT & LOSS
Income
Other Income
Expenses
Cost of Revenue
Depreciation
OTHER
Off-Balance Sheet
closesodoo/odoo#36170
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Nicolas Martinelli