Stock.location is ordered by "complete_name" which is possible to be the
same (i.e. default production locations for different companies). This
may result non-deterministic order. Add "id" to avoid it.
closesodoo/odoo#79181
X-original-commit: 94a8ad3fae914b046064bb7ce17572be8280f6e0
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
"Material Availability" vs "Component Availability" label means
the same thing but it shouldn't.
- Rename these and add a help string for both fields.
- Change decoration to be green if the MO Readiness is
'ready'.
- The logic of `_compute_*_availability` doesn't take in account the
'ready' `(reservation_)state` to distinct clearly both fields
(`(reservation)_state` vs `*_availability`)
task-2668922
closesodoo/odoo#79033
X-original-commit: acc385137a6a59f3632d91a7fcabd5ab42e8bc7f
Signed-off-by: Tiffany Chang <tic@odoo.com>
It may happen that there is a property defined on some field that is not
the default property, but rather the property associated to a record.
For example
```
=> select id,name,company_id,fields_id,value_reference,res_id from ir_property where name like '%property_stock_inventory%'
+------+--------------------------+--------------+-------------+-------------------+----------------------+
| id | name | company_id | fields_id | value_reference | res_id |
|------+--------------------------+--------------+-------------+-------------------+----------------------|
| 528 | property_stock_inventory | 1 | 4665 | <null> | product.template,752 |
| 6 | property_stock_inventory | <null> | 4665 | stock.location,5 | <null> |
+------+--------------------------+--------------+-------------+-------------------+----------------------+
```
In this case the property with id=528 is not a default property since
res_id is not NULL. Alternatively the property id=6 is a default one.
The issue here is that when searching for the missing locations we do
not filter out the properties with res_id not NULL, thus we may get that
a company has the location define while in fact it doesn't. Following
the example above, this means that we incorrectly get property id=528 as
the one defining the location for the company id=1 here:
https://github.com/odoo/odoo/blob/c5c47da2e96fd5e37030c70d6bb1bae4c4047fa8/addons/stock/models/res_company.py#L107
This not only prevents the creation of the correct default property but
also the default locations
https://github.com/odoo/odoo/blob/c5c47da2e96fd5e37030c70d6bb1bae4c4047fa8/addons/stock/models/res_company.py#L36-L51
On this patch we fix the domain search for default property. This allows
for the correct creation of the default locations and associated
properties.
This issue was observed during upgrade 40921, where it prevents the
upgrade to 15.0
closesodoo/odoo#79000
X-original-commit: b9d98950826e7272b1df4f6f2467d1d2d14dcc64
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Hide the "Clear All" button next to "Assign Serial Numbers" button when
there are no move lines to clear.
Follow up to task: 2426281
closesodoo/odoo#75676
Signed-off-by: Arnold Moyaux <arm@odoo.com>
- Improve _search methods of stock/product by using subqueries
- Improve efficiency _search_on_hand of stock.quant (see
odoo/odoo#77190)
closesodoo/odoo#78847
X-original-commit: 82562cc25c10500d30056ca19d816c1d211a24eb
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Rémy Voet <ryv@odoo.com>
Sets the `inventory_quantity_set` as an editable field (not readonly)
and creates its own compute to avoid to override it each time the
`inventory_quantity` is modify and we set the `inventory_quantity_set`
aside (before this commit, this field new value was always overrided by
the `inventory_diff_quantity` compute).
This is useful when we want to write on the quants from the Barcode App
as we can write on `inventory_quantity` and `inventory_quantity_set` at
the same time.
task-2632818
closesodoo/odoo#78719
X-original-commit: 489e76ade600f7983a9a1976c04529ac542fdd44
Related: odoo/enterprise#21810
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
Signed-off-by: Steve Van Essche <svs-odoo@users.noreply.github.com>
The allocation order is not based on the pickings order
To reproduce the issue:
(Need sale_management,mrp)
1. Create a storable product P
2. Create a BoM for another product dummy_P and add 1xP as component
3. Create and confirm a SO with 1x product P
4. Create and confirm a MO for 1x dummy_P
5. Process a receipt transfer with one P
Error: On the SO, the reserved quantity is still 0. The product has been
reserved for the MO, even if the picking of the SO has been created
first
The default order of several SM is based on the sequence and the
identifier:
https://github.com/odoo/odoo/blob/abc9fdaae2927214d98082f391a1dc0fc75e4c77/addons/stock/models/stock_move.py#L26
The default value of the field `sequence` is 10:
https://github.com/odoo/odoo/blob/abc9fdaae2927214d98082f391a1dc0fc75e4c77/addons/stock/models/stock_move.py#L26
When creating a SO, the field isn't defined so its default value is used
(10). However, when creating the MO, the field is defined thanks to the
sequence of the related BOM line:
https://github.com/odoo/odoo/blob/864d90a064f093bd6ba24d8464ee491a443a320e/addons/mrp/models/mrp_production.py#L940
Which, in our case, is equal to 1
As a result, when allocating the quantities in `_action_assign`, the
recordset will contain first the SM of the MO and then the SM of the SO.
This commit ensures the order will be based on the priority, the date
and the identifier (the latter allows the search result to be
deterministic)
Side note: this commit also adds the identifier to the search in
`_run_scheduler_tasks` to keep consistency between the different
flows
OPW-2524205
closesodoo/odoo#78497
X-original-commit: da2b336d467d95cda8ed21707535fb7119f5d777
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>
Creating lots of production lot can take a huge amount of time if the
mail message follower is added on each chatter.
This commit removes this functionality to speed up the creation as
there is no real need to have the lot creator as follower of it.
closesodoo/odoo#78547
X-original-commit: 9b0e669216948da2710e2e16007f03e47fb7e704
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Searching the stock move line candidate to update at reservation can be
shorten by breaking the loop once one is found
X-original-commit: 93df2568914bee307209e1e739912976c23e1f1d
Part-of: odoo/odoo#78547
The recomputation of stock move state is often done with already
the correct state (for instance in the case of move line deletion only
one of the deletion will change the state).
This commit check the move state before changing it only when it's
necessary.
Task: 2507143
X-original-commit: 80033446a091ff3ba98c58ba44ad665bfba30c98
Part-of: odoo/odoo#78547
Co-authored-by: Remy Voet <ryv@odoo.com>
How to reproduce:
- Create a product tracked by lot;
- Create two receipts for this product;
- Use the same lot name in the two receipts;
- Try to validate the two receipts in the same time
=> `ValidationError` will trigger in the `_check_unique_lot`
constrain of the production lot.
task-2646107
X-original-commit: cf018e9f215336ef19e0a517d4e116f0da26850e
Part-of: odoo/odoo#78189
scrap_qty field was missing the digits attribute, and therefore the user
could not create a scrap with a quantity with more than two decimal places.
With this commit, scrap_qty will follow the 'Product Unit of Measure'
precision setting, just like any other quantity fields.
closesodoo/odoo#78338
X-original-commit: d9ed98f56e00f38cb3fd87bc9b7cad981a1c4400
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
The generate serial number button uses the stock.lot.serial sequence by default
(default value for name of stock.production.lot)
Serial Mass Produce (and other parts) allow to generate serial numbers
starting from a user supplied initial value.
This fix makes the button generate the next serial number
according to the last generated.
task 2647238
closesodoo/odoo#78258
X-original-commit: b80259dff3aaafb9d11af9d936f5106bdf5ed781
Related: odoo/enterprise#21641
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Signed-off-by: Jean-François Aubert <ajf-odoo@users.noreply.github.com>
In large database with unique serial number. The index add performance.
closesodoo/odoo#78087
X-original-commit: ccefa18bb2873412e6b0ac9e0f5e61ac82ccc51e
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
- Remove unused method get_theoretical_quantity
- Remove unused args of _get_domain_locations_new and simplify it
closesodoo/odoo#78078
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
When increasing the quantity of a validated Sale Order, the reserved
quantity in the related pickings aren't updated to match the new
quantity set in the Sale Order. It requires to either let the scheduler
run or clicking the 'Check Availability' button to update the reserved
quantity in those pickings.
If the reservation_method for this picking_type is set to 'at_confirm',
this is not the intended behavior as this picking is already confirmed,
so it should be updated without user input.
The reason is that when the new moves (which adds to the quantity) is
merged to the old one, its status is changed to 'partially_available'
because at that moment, the product_qty is bigger than the
reserved_quantity, which needs to be updated to match the new needs.
closesodoo/odoo#76752closesodoo/odoo#78070
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Allow the quantity decrease of Sale Order line of a MTO product.
When increasing de quantities, the related pickings, RFQ / PO are
increased as well, but it wasn't the case if decreasing the quantity.
It should allow the cascade of the decrease in the related pickings as
it would work for the increase. Also modifies a related Purchase Order
if it wasn't yet validated (and thus still a RFQ).
merge_moves was modified so it would allow the merge of negative moves
with positive ones, while trying to "deplete" as much quantity as
possible for each mergeable move.
But negative moves don't always have all required properties to be
compared to the positive ones (some keys might be missing, such as
'created_production_id'). That means we will merge strictly the positive
moves at first as it was done before. But then we try to merge them "less
strictly", using less keys to compare.
Let's say we have those moves (and all other relevant keys matches) :
- move_1 : {qty : 5, created_production_id: 1}
- move_2 : {qty : 3, created_production_id: 2}
- move_3 : {qty : -6, created_production_id: False}
move_1 and move_2 cannot be merged as they don't share the same
created_production_id. But to merge move_3, we'll need to merge it into
move_1 and move_2. It will then deplete move_1 and decrease move_2.
Which will leave us with :
- move_1 : {qty : 0, created_production_id: 1}
- move_2 : {qty : 2, created_production_id: 2}
move_3 will be unliked as its purpose is done.
Task-2513592
Part-of: odoo/odoo#78070
Steps to reproduce the bug:
- Create a product and enable serial number option
- Create one “on hand qty” with SN e.g: “001”
- Create a SO for SN product
- Confirm SO and check the delivery order
- In the Operations tab > Enable Serial Number field
- “001” SN is already reserved in Detailed Operations and the qty done is 0 but the Serial Number field in “stock.move” is empty
- Edit and add “001” in the SN field
- save
Problem:
- The SN is deleted and the quantity done in the `”stock.move.line”` is not updated
Solution:
Update the quantity done in the `“stock.move.line”` linked to the selected SN
opw-2623101
closesodoo/odoo#77564
X-original-commit: abc9fdaae2927214d98082f391a1dc0fc75e4c77
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Avoid some useless read_group on stock move (fetch too much qty fields
in product.product) and use a query object to avoid fetching data.
To compute 11K of forecasted information of stock move (multi-warehouse
):
- Before: 1.704 ± 0.046 sec and 174 SQL request
- After: 1.554 ± 0.012 sec and 134 SQL request
X-original-commit: 338edd616c2afe1d7a08a06a0b0278c3d7083c05
Part-of: odoo/odoo#77402
- create Tree warehouses, WH1, WH2, WH3, with three different address
- add route 2-1 to resupply WH2 from WH1, complete partner_address_id on rule with partner_id of WH2
- add route 3-1 to resupply WH3 from WH1, complete partner_address_id on rule with partner_id of WH3
- create a product
- add orderpoint, WH2/Stock with route 2-1 and min_quantity to 1
- add orderpoint, WH3/Stock with route 3-1 and min_quantity to 1
Lauch scheduler.
Issue:
You have 1 out picking of WH1, with qty = 2. It doesn't make sens because WH2 and WH3 have not the same address.
With this PR, 2 out picking are created.
closesodoo/odoo#77151
X-original-commit: 26833a045e48a88bbc41857110f310acd4fa5335
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Merge duplicate code of `_check_move_lines_map_quant_package` (of
`stock.picking` and `stock.package.level`.
Also remove unused `_get_contained_quants` method in
`stock.quant.package`
task-2648449
closesodoo/odoo#76761
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Instead of using sort + groupby of itertools (which group only
consecutive), use only the groupby of odoo.tools which
decrease the complexity of the code and avoid unmatched keys
between sort keys and groupby keys
task-2648449
Part-of: odoo/odoo#76761
Improve the performance/scalability of the forecasted compute.
Duplicate the code of the `_get_report_lines`
(`_get_forecast_availability_outgoing`) and specialize it to only
compute necessary information for the `_compute_forecast_information`.
It is mandatory to readd 'Component/Product Availability' (MO/picking)
which aggregate the result of `_compute_forecast_information`.
Note that with this refactor, it is still too slow to add in the
view normally. We should fetch it with a lazy way.
With a DB populate with 3 company and 6 warehouses (2 for each company),
50 locations, 30K stock moves, 9K quants and 1700 products.
Before fix:
To read 40 confirmed stock move (with forecast information):
35 SQL request, 0.031 ± 0.0004 sec of SQL, 0.204 ± 0.008 sec of Python
=> 0.235 sec
To compute 7300 forecast information (52 draft MO - 99 confirmed MO):
382 SQL request, 1.334 ± 0.052 sec of SQL, 6.807 ± 0.223 sec of Python
=> 8.141 sec
After refactor:
To read 40 confirmed stock move (with forecast information):
35 SQL request, 0.029 ± 0.0004 sec of SQL, 0.074 ± 0.003 sec of Python
=> 0.103 sec
To compute 7300 forecast information (52 draft MO - 99 confirmed MO):
369 SQL request, 0.550 ± 0.009 sec of SQL, 0.969 ± 0.012 sec of Python
=> 1.519 sec
task-2579011
Part-of: odoo/odoo#77092
The `_compute_warehouse_id` wasn't never batched (never prefetch)
because of the `recursive=True` in its declaration.
Remove the recursion depends and add manual
invalidate cache to stay consistent.
It avoids extra SQL request by prefetching correctly
the `warehouse_id` fields.
task-2579011
Part-of: odoo/odoo#77092
Improve 'Component Availability' and 'Product Availability':
Add these fields in form and tree view (the performance issues
is addressed in next commits and these fields will be load lazily)
task-2579011
Part-of: odoo/odoo#77092
The `_compute_json_popover` of (`mrp.production`)
was slowing down the tree view of MO (because it loaded
every move due to `production.move_raw_ids` even if there
isn't `delay_alert_date`.
Make it more lazier: we gain a speed up
when the there aren't any delay_alert_date
(always when the setup is simple)
To read 150 MO (7500 moves behind):
Before: 0.099 ± 0.002 SQL sec, 0.224 ± 0.005 Python sec (37 SQL requests)
After: 0.060 ± 0.0008 SQL sec, 0.096 ± 0.002 Python sec (29 SQL requests)
Also, unify the code with `stock.picking`.
task-2579011
Part-of: odoo/odoo#77092
In multi-warehouse, when we open the forecasted report from a component
line of MO, the default warehouse in the forecast_report was always the
first of the company. Because it took destination location warehouse
(== False because it is destination location == subcontracting location)
instead of the source location in case of MO.
task-2579011
Part-of: odoo/odoo#77092
We fix 2 related UoM issues:
1. Fix quant inconsistency from changing the UoM of Done
stock.move.lines
Steps to reproduce:
- Enable "Storage Locations" setting
- Create a new "Storable Product" and create a receipt for 1 unit of it
- Validate the 1 unit receieved
- Open "Detailed Operations" of the move and change the stock.move.line
UoM to dozen.
Expected result: 13 on hand
Actual result: 1 on hand
To fix this:
- prevent users from editing the UoM after the picking is
done (i.e. unless adding a new stock.move.line and not saving).
- update the write on done logic so stock.move.line UoM changes are
considering and will update the quant correctly (in case of RPC or
direct write).
2. Prevent changing UoM of Done stock.move to prevent inconsistent field
values within stock.move and confusion for users
Steps to reproduce:
- Complete a picking (incoming is easiest to see) with a new product
(i.e. 0 qty) having 1 unit done.
- Unlock picking and add a new stock.move with 1 unit done and save.
- Edit the just added stock.move's UoM from Units to Dozen.
- Check the quantity on hand / Done qty of stock.move after leaving and
returning to form.
Expected result: 13 On Hand
Actual Result: 2 On Hand and the "Done" qty in the picking is 0.0083
(i.e. 1/12 of a dozen)
To fix this:
- prevent users from editing the UoM after the picking is done (unless
adding a new stock.move and not saving)
- if a Done stock.move UoM is uodated, a UserError occurs because there
is no straightforward way to ensure the quant is updated correctly
since is handled within the move.line (i.e. has no visibility to its
move's uom change => changing only UoM and not qty done will result in
no quant update)
closesodoo/odoo#76916
X-original-commit: 72a1e7d75f0b13f23def912c8bcc758c58438b04
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Signed-off-by: Tiffany Chang <tic@odoo.com>
Usecase:
- 2 warehouses 1 and 2
- Create a route with a rule from inter-warehouse to WH2
- Create a picking type for WH1 for stock to inter-warehouse
- Create a planned transfer with 2 stock.move in the wH1 new picking
type
-* Go back to inventory overview
- Click on process on the picking type WH1 -> inter-warehouse
-* Process the picking created before
- Go to WH2 delivery
You see 2 pickings for each stock.move despite they share the same
data (procurement group, source and dest locations)
If you don't do the steps bewteen *, you only have 1 picking.
It's due to the context of the views that is propagate to the
new picking created by push rules.
opw-2533718
closesodoo/odoo#76821
X-original-commit: 60c7722eedc1835a8aca9d6bbd75f5ab66ea4b59
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
This commit fixes two bugs:
1) When the user changes the tracking of a product template with
variants, they get a traceback.
2) When the user changes the tracking of a product with quantity
available, the warning is not shown.
For the 1), it was due to reading `tracking` and `qty_available` fields
on a record set (happens when the template has variants).
For the 2), it was due to the `qty_available` who is wrongly computed in
the onchange because of the records having a "new-id" instead of their
usual id.
How to reproduce:
- Create a new product with some variants, no tracking;
- Add quantities for those product variants;
- Edit the product and change its tracking -> Traceback.
task-2618203
closesodoo/odoo#76071
Co-authored: svs-odoo < svs@odoo.com >
X-original-commit: 75572da12b3ad5d0f930e7e2f5dbac067a350b3c
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
Calling the xml action directly in the view make it miss the filling
context done in _get_action().
closesodoo/odoo#76294
X-original-commit: b818927898e42e8837230b7d1f089d4d822d7d76
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Commit 04f3cac527 makes picking_type_id compute on stock_move_line to
get the picking type of either the picking or the manufacturing order.
Right after, commit dd53f5323f set picking_type_id related of the
picking one to be able to search on it. (in this later scope,
manufacturing part was not needed, hence the related instead of compute.
This commit mix the two idea by having a new search function on the
computed fields to filter stock move line depending on their picking
type.
X-original-commit: d535108f96d62f217dda7cbb676f9d60b7477f4f
Part-of: odoo/odoo#76294
Before this commit, Inventory Admin was not able to create new /edit picking type
as Non-admin users doesn't have rights to create/edit sequence.
With this commit, we are creating/editing `sequence_id` with sudo
closesodoo/odoo#76258
X-original-commit: c5de12310be023e1048f8a1174f87582c13a9160
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Because the "Replenishment" can unlink a lot (thousand of
`stock.warehouse.orderpoint`).
and psql needs to check every Many2one `orderpoint_id` constraint
and without index it takes too much time.
opw-2637321
closesodoo/odoo#76116
X-original-commit: 864d90a064f093bd6ba24d8464ee491a443a320e
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
Setting a default value on a readonly related field without an inverse
method is nonsense. We log some warning when it happens.
We also fixed other cases where a related field has a default value
that overrides the target field's value.
closesodoo/odoo#67762
Related: odoo/enterprise#17313
Signed-off-by: Julien Castiaux <Julien00859@users.noreply.github.com>
revert part of #4467734b77f19e3c4f4623e878d74c529a135bad
compute_qty_to_order is triggered manualy but not commited,
later in the scheduler task action_assign is call. However
product_id.stock_move_ids.state is a trigger of compute_qty_to_order
so it will be trigger a second time and deadlock itself
Also replace the cursor before procure_orderpoint_confirm,
so the procurement could have access to the data commited
by _compute_qty_to_order
closesodoo/odoo#75972
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
Since return moves are linked to their original move, it's easy to
manage reservation in those case. We just don't bypass the reservation
when it comes from a reservation outside our stock in order to manage
the computation on linked moves and reserve pieces that were not yet
return.
Also add a return picking type for 2 reasons:
- Allow to select existing lot.
- Display reserved move line for an incoming picking.
Note that this picking type is just a default configuration and could be
modify by the user without any issue.
closesodoo/odoo#64384
Related: odoo/enterprise#20605
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
The button "Set Quantity" have a different behavior
(it doesn't take in account tracked product) than
the immediate process which is confusing.
Now both flow share the same code and allow to avoid
the "Set Quantity" for the subcontracting with tracked component.
task-2486811
Part-of: odoo/odoo#75041
The logs of the scheduler wasn't correct ( 4467734b77 ):
- The number of object process wasn't correct for the last batch
- Fix Spelling of "commited"
Also, we commit every 1000 moves assignation instead of 100.
(Because the prefetch already prefetch by 1000 and to benefit
futher the batch optimisation of _action_assign).
Part-of: odoo/odoo#75041
When a product's has a kits bom, we consider it a kits product.
When a product is a kits product, we count its "on hand" and "forecast"
qty by caculating how many can be produced according to the bom.
We add status button to the show the qty on kit product form.
Task-2444000
COM PR odoo/odoo#75555
ENT PR odoo/enterprise#20440
UPG PR odoo/upgrade#2783
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Before this commit, multiple package types can have the same barcode.
As it makes no sense and could lead to confusion, it's no more possible.
task-2627002
Part-of: odoo/odoo#75699
This commit introduce Wave Pickings. This new object is a group of stock
move lines related to different pickings. The goal is to group stock
movements having similar characteristics like same source location, same
product category, ...
Wave pickings are created from stock move lines. Those are removed from
their picking to a copy of it. All the new picking are grouped together
in a new batch picking. This batch is the wave.
To differentiate the batch pickings and the wave pickings. This commit
introduces a new menu and a new sequence.
Task : 2411102
Part-of: odoo/odoo#63291
This commit add a quick access to all the move lines of a picking
type (only transfers picking type) ready to be processed from the
Inventory dashboard
Task : 2411102
Part-of: odoo/odoo#63291
- Create a product with a kit BOM and weight
- kit components should have list price and weight as well
- Create SO with kit product
- Add shipping (fedex int. or bpost will do)
- Delivery product
A custom's form is generated but the value of the product it is not
correct as it take the valuation of the kit in the sale order
for every component of the kit, resulting in higher customs taxes for
the final customer
opw-2628309
closesodoo/odoo#75658
X-original-commit: e13f048a78b41d81602e868a3b0c7ded24ce992b
Signed-off-by: agr-odoo <agr-odoo@users.noreply.github.com>
yhu-odoo