Commit Graph
80 Commits
Author SHA1 Message Date
Christophe Simonis d74b451805 [MERGE] forward port branch 13.0 up to f4105eb9c7 2019-10-09 02:08:17 +02:00
Arnold Moyaux 6cdaea7223 [FIX] mrp_subcontracting: Initial demand in a BO
Usecase to reproduce:
- Create a receipt with a quantity of 2
- Receive 1 and create a back order
- Receive 2 in the BO

It will only require the components for 2 units and not 3.

closes odoo/odoo#37305

Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
2019-09-24 07:45:31 +00:00
Simon Lejeune d1814891fe [REF] mrp_subcontracting: manage backorder
closes odoo/odoo#37046

Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
2019-09-18 07:15:32 +00:00
Arnold Moyaux 167fd934a8 [FIX] mrp_subcontracting: empty BoM if no subcontractor
_bom_subcontract_find return a BoM of typer subcontractor for
any partners if the subcontractor is not set. The real behavior is
to not create a subcontracting order if the partner is not set.
2019-09-18 07:14:53 +00:00
Arnold Moyaux 93c53265ed [FIX] mrp_subcontracting: multi company 2019-09-18 07:14:53 +00:00
Raphael Collet 8546d07d0f [FIX] mrp_subcontracting: cannot order by many2many field 2019-09-12 13:53:12 +00:00
Christophe Simonis 64e43808b7 [MERGE] forward port branch saas-12.5 up to 58a83d1222 2019-09-20 17:34:45 +02:00
Simon Lejeune 9d4a552690 [REF] mrp_subcontracting: multi company
Ensure proper domains are applied and enforced on relation fields thanks
to the `check_company` attributes.

task-1985992
2019-09-03 15:05:03 +00:00
Raphael Collet 9920f20e4c [IMP] models: ORM speedup
This branch is the combination of several optimizations in the ORM:

* store field values once in the cache: the cache reflects more
faithfully the database, only fields that explicitly depend on the
context have an extra indirection in the cache;

* delay recomputations by default: use method `recompute` to explicitly
flush out pending recomputations;

* delay updates in method `write`: updates are stored in a data
structure that can be flushed efficiently to the database with method
`flush` (which also flush out recomputations);

* make method `modified` take advantage of inverse fields to inverse
dependencies;

* filter records by evaluating a domain on records in Python;

* a computed field with `readonly=False` behaves like a normal field
with an onchange method;

* computed fields are computed in superuser mode by default.

Work done by Toufik Ben Jaa, Raphael Collet, Denis Ledoux and Fabien
Pinckaers.

closes odoo/odoo#35659

Signed-off-by: Denis Ledoux <beledouxdenis@users.noreply.github.com>
2019-08-20 12:43:59 +00:00
Arnold Moyaux 4055293873 [IMP] mrp_subcontracting: bypass reservation
A subcontracting receipt should be always assigned even
if the components are not deliver. It depends on the partner
and not our company.
2019-08-19 15:03:59 +00:00
Arnold Moyaux 5d809fd6b4 [MOV] purchase_mrp_subcontracting -> mrp_subcontracting_account 2019-08-19 15:03:59 +00:00
Arnold Moyaux a684372fdd [IMP] mrp_subcontracting: subcontractors required
Force to set subcontractors on subcontracting BoM since
it's always used in order to determine if a subcontracting
should be apply on a receipt or not. Also there is not magical
behavior has 'if there is no subcontractor on the BoM then it
means all partners...'
2019-08-19 15:03:59 +00:00
Arnold Moyaux 39c5d0f35e [IMP] mrp_subcontracting: cancel subcontract order
A subcontracting receipt cancellation should cancel the
subcontracting order and the associated document.
2019-08-19 15:03:59 +00:00
Arnold Moyaux a3aeabd44d [FIX] mrp: do not base default on active_id
Since active_id do not works allows to use a context
key that will not be modified magically.
2019-08-19 15:03:59 +00:00
Arnold Moyaux d151373941 [REF] mrp_subcontracting: views v2
- nothing tracked
The "register components" button shouldn't appear, the receipt looks normal.
- finished products tracked
The "register components" button shouldn't appear, the receipt looks normal.
- finished products not tracked and components tracked
The "register components" button appear and the burger redirects to "Produce" wizard. The user should record all the productions before being able to access SML through the burger wizard. He cannot force any SML for subcontracted products with tracked components before having recorded all the productions.
- finished products and components tracked
The "register components" button appear and the burger redirects to "Produce" wizard. The user should record all the productions before being able to access SML through the burger wizard. He cannot force any SML for subcontracted products with tracked components before having recorded all the productions.
2019-08-19 15:03:59 +00:00
Arnold Moyaux 5b526e8756 [IMP] mrp_subcontracting: modify initial demand
Modify the initial demand for a subcontract receipt should
update the delivery to the subcontractor.
2019-08-19 15:03:59 +00:00
Arnold Moyaux cbea919a9a [FIX] mrp_subcontracting: access error on purchase
Usecase to reproduce:
- Validate a purchase_order with a user without group inventory user or manufacturing user.

AccessError on operation read for BoM. A purchase user should be able
to validate an order independently of the documents that will be
generate.
2019-08-19 15:03:59 +00:00
Arnold Moyaux 4c4a7879e9 [ADD] mrp_subcontracting_dropshipping
Allow to do a dropshipping with a subcontractor.
If the product uses the routes drophipping and have
a subcontracting BoM. Then a PO for the subcontractors
will genrate a need in the subcontracting location for
the required components.

A module is needed because the picking_type_id for dropshipping
do not have a warehouse_id. The warehouse_id is needed in order to
know from which warehouse the subcontracting components should be
deliver.
2019-08-19 15:03:59 +00:00
Arnold Moyaux 8c2b0a937f [IMP] mrp_subcontracting: partner on subcontract delivery
If the components have the route resupply subcontractor on order then the
delivery order triggered by the receipt do not have the origin nor the
subcontractor partner. This commit update the procurement group in
order to add those information and propagate it.
2019-08-19 15:03:59 +00:00
Arnold Moyaux 875d99812f [FIX] mrp_subcontracting: allow to create lot.
due to commit 108ee65af2a88d61526dc047043138bddc3f9b63#diff-99ad190cf09687f6efdebc1f7636062c
picking type for subcontracting order use field use_create_components_lots
instead of classic picking type.
2019-08-19 15:03:59 +00:00
Arnold Moyaux 33cf89a6c6 [REF] mrp_subcontracting: remove partner type
Replace the type subcontractor on the partner.
Instead replace it by a property for a subcontracting location.
The purpose is to have a simplier configuration. The user would
just need to add the partner on the BoM in order to start a
subcontracting process.
2019-08-19 15:03:59 +00:00
Arnold Moyaux 37200abfc5 [REF] mrp_subcontracting: lot produced/consumed management
Currently, the subcontract picking present multiple difficulties:
- The user has to introduce multiple time the lot produced.
In register components button and then create a new move line with
the show details operation button.
- Same problem with the correction system. The user has to modify the
lot in details operation and then go on the subcontract production and
unlock and edit it.

In order to facilitate those behavior. A move line will be automaticaly
created during the register components process. Also the subcontract
moves for components will be available in the detail operations tab.
2019-08-19 15:03:59 +00:00
Arnold Moyaux 6c09ffb634 [FIX] mrp_subcontracting: remove hook
The hook only generate a useless rule. It has been already
generated in stock_warehouse.py. Also remove the hook method
and add it in data file.
2019-08-19 14:14:13 +00:00
Arnold Moyaux abc8253448 [FIX] mrp_subcontracting: extra move correctly handle.
Usecase to reproduce:
- Create a receipt of 1 units of a subcontracted product
- Receive 2
- Validate the receipt

-> An extra move for subcontractor of 1 has been validated but a
new move of 2 still in waiting availability and can not be
validated.

It happens due to action_done that will validate existing subcontract
order (with the initial quantity). Then the move is validated and an
extra move is created and merged in the first one. This new merged
move of 2 is then confirmed and validated. That will recreate a
subcontract order of 2 that will not be validated since it was validated
in the picking action_done at the start.

This commit will modify:
- action_done on move in order to validate the subcontract order after
the move validation and the new subcontract order creation too.
- action_confirm in order to create the subcontract order with the
additional quantity and then merge it to the existing moves.
2019-08-19 14:14:13 +00:00
Arnaud Baes 062ad598bf [IMP] stock: default sequence for picking types 2019-08-14 12:27:04 +00:00
Dhaval Panchal a580538e98 [IMP] stock, mrp, purchase: default value for cancel propagation
cancelling propagation in a move chain was True be default. That means,
without any configuration, a cancel move will always cancel its next ones

This commit change the default to allow only cancelation of move chain
until the stock location. Here are 2 examples :
 1. Reception and delivery in 3 steps. The moves chain is the following:
    Vendor -> Input -> Quality -> Stock -> Pack -> Output -> Customer
  In case the Purchase order is cancelled, we want to move from Vendor to
  Stock are cancelled but not the ones from Stock.

  2. pbm + sam. The manufacturing process is the following;
    Stock -> Pre-prod -> Production -> Post-prod -> Stock
  cancelling the first move should cancelled until Production and not after

Task : 1913297
2019-06-11 07:56:11 +00:00
Dhaval Panchal 1ccca8d267 [IMP] stock, mrp, purchase: rename propagate into propagate_cancel
This commit rename propagate field into propagate_cancel to be
more consistent with c514e8ae6a (introducing
propagate_date)

Task : 1913297
2019-06-11 07:56:11 +00:00
Yannick Tivisse f5dfe4727c [IMP] api.py: Rename company_id/company_ids into company/companies
The goal is to be coherent with the user property.

Actually, company_id and company_ids on the environment are no fields.

Calling env.company_id returns a browse record, not an id.
2019-05-29 08:09:15 +00:00
Yannick Tivisse a5b6f31cf2 [IMP] base: Contextualize the multi company
Purpose
=======

Allow the user to select the allowed companies for which he wants to see records
on top of selecting his current company.

It is confusing for users to see the records from the company he is connected to
and the records of the children companies.

Instead of using the hierarchy of companies to access records across companies,
the user can now select (from his set of allowed companies) the companies for
which he wants to access records.

/!\ This means that the user will interact with records from company A when in
company B.
Example: a SO has been created and confirmed in A. When in B, I create the
invoice from it.

Specifications
==============

1/ Deprecate the parent/children hierarchy on the res.company model. The fields are
kept on the res.company model to ensure the retro-compatibility, but won't be used
accross the standard code anymore. The only functional usage for this mechanism
was to allow to see records from several companies by creating a virtual parent
company, which will be possible with the new mechanism.

2/ By default, a user will only see the records of the company he is connected
to (or records without a company). (It is still editable by the user if needed).
For that, put this information in the user context, to allow having different
configurations on different browser tabs. Instead of having domains like
['|',
('company_id', '=', False),
('company_id', 'child_of', user.company_id.id)]
you'll have something like
['|',
('company_id', '=', False),
('company_id', 'in', company_ids)]
Note that the 'company_ids' is a value that is passed in the evaluation
context on the record rule, as we already have user, or time.
company_ids is a list of the ids of all the enabled companies in the
user's context.

3/ Out of the generic improvements brought by this task, this will illustrate
issues that could exist since several versions. For example, it should not be
possible to create a scrap order for the company A with a package of the company
B, or it should not be possible to create an invoice on the company A with
payment terms from the company B. Before the version 12.0, it was easy to
encounter this kind of issues as the admin was the SUPERUSER_ID. A positive side
effect of the fact that the SUPERUSER_ID has become an inactive user was to
make it more difficult to introduce mismatch on the records, but haven't solved
the issue, as it was still possible to do it with parent companies
configuration. Some of these issues have been fixed in this commit, but all the
business flows should be re-tested to check if an ir.rule should be introduced
(eg: a multi company rule for stock.quand.package), if the company of a record
is correctly transfered to another record created from the first record (eg:
From a SO, create an invoice and a payment, the company of the sales order
should be transfered on the invoice and the payment, even if the company of the
sales order is A and I'm logged into the company B with the company A enabled.

4/ Currently, if I click on a button on a notification email (example 'View
Task'), I face a traceback if I'm not logged into the company of the record.
Now, if you click on a button and if you have access to the record, the correct
company will be automatically set.

5/ If I display a kanban view with several records from several companies (and
an image), all the images should be displayed.

6/ Currently if you copy paste an url, this will crash if you're not in the
correct company. This won't be fixed because it's quite impossible to do it in
a clean way. This task brings a workaround. Copy/Paste -> Traceback -> Log into
the correct company, re-copy/paste -> Ok.

7/ 2 property methods have been added on the environment to retrieve the company
on which the user is logged in and the companies the user enabled, on a specific
tab.
That way, when creating a record, instead of doing
default=lambda self: self.env.user.company_id
do
default=lambda self: self.env.company_id
On the other hand, to retrieve the enabled companies, do
companies = self.env.company_ids

8/ Modify the Company Switcher widget to allow to log into another company
WITHOUT writing on the res.users (and thus bringing cache invalidation issues
and so on). Also allow to enable several companies and see records from several
companies, and independantly of the other browser's tabs.

9/ When focusing on a tab, save the current company configuration on the local
storage. That way, when doing 'CTRL+T' or a middle click, the context is
propagated to the new tab.

10/ Improve the error message in case of multi company access errors. Now, when
the user is in debug mode, display the related names of the records and the name
of the user who brings the issue.

11/ Remove the context erasing when writing on a res.users
This is probably coming from the migration to new API of the base module.
The context was not propagated at this moment, which was a common mistake at
that time. When migrating the module, probably by using the 'black box' method,
as the context was not propagated, it was erased on the new version. This is
now an issue because the context (i.e. the enabled companies) was erased when
writing on a res.users, leading to tracebacks.
See: https://github.com/odoo/odoo/commit/7eab8e26d3d46c53f4be924d6a34e80a66e74960#diff-4c2e738ee8f64f11806c889ea097b5e7R624

12/ Fix the crash manager on redirect warnings. The issue is the following
- Create an invoice on a company without a configured CoA.
- Set a partner
- On the onchange_partner_id, a redirect warning is raised to propose you
to configure a CoA
- Click on 'Go to the configuration panel'
- A generic warning says something like 'Do you want to discard your changes?'
- Click on yes, the page refreshes, but not on the redirect action.
Now, set correctly the action on the hash, and reload instead. The breadcrumb is
lost for example, but you reach the correct action at least.

13/ Introduce a res.group to enable/disable the multi company per tab
feature.

14/ To help the users to know which tab is in which company, add the
possibility to have a favicon per company. When creating a company,
the classical 'O' icon is colored by default in a random color.

15/ Remove the company switcher on the frontend. This was mainly there
to allow a user to swicth to the company linked to the website.
This behavior is now transparent to the user. If the website A is
activated, then the company set on the context is the company of the
website.

16/ Deprecated the _company_default_get method on the res.company
model. Remove the method _get_company on the res.users model.

17/ Add 'allowed_company_ids' and 'current_company_id' on the pyeval
context. You can now use those variables on domains in the views to
access directly to the activated company.ies on the current tab.

TaskID: 1960971

closes odoo/odoo#32341

Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
2019-05-13 08:57:49 +00:00
Simon Lejeune d91db5bde6 [ADD] mrp_subcontracting
In a few words, it allows to send components to a subcontractor partner
and receive a finished product. The production is managed through classical
manufacturing orders where the raw and finished location is the
subcontracting location. When creating a receipt picking for a
subcontractor partner, the location_id of the moves will be set to the
subcontracting locations by using the property_stock_customer and
property_stock_supplier of the partner. An override of _action_confirm
will create the manufacturing order.

When a subcontracted bom contains tracking, the produce wizard is
available from the picking to record which lots were produced/consumed.

New type on the BoM: subcontract
New type on res.partner: subcontactor
New location per company (we still own the components stored at the
subcontractor so they're still valued)
New routes created to resupply the subcontracting location on order or
not (through a reordering rule).
Override of res.partner to set the property_stock_customer/supplier on
subcontactor partners.

Proper tests were added too.

Joint work with: Arnaud Baes <arb@odoo.com>

task 1831382
2019-04-03 13:52:22 +00:00