This commit adapts the directional icons to improve the usability and
maintain consistency with the ui icons library.
task-2818586
Part-of: odoo/odoo#116641
*: hr_holidays, stock, sale, product, web, sale, purchase, stock,
website, survey
Adapt some custom control panels (mainly for custom reports) to the
milk controlpanel.
hr_holidays:
Move the buttons to create a new time off or a new allocation to the
"create button" slot and transform it into a dropdown (creating
allocation requests is clearly a secondary action, not a primary one)
stock:
3 lines does not fit, must be on 2 lines
Part-of: odoo/odoo#116641
Adds back the direct link on the purchase line product's column when the
`product_matrix` is enabled. This allows the user to still click on the
product and go to its form when the module is enabled.
Also removes the direct link to the UoM, since it has no use.
Finally, sets a width for the product column in the purchase form to
keep it usable even when multiple columns are selected.
Part of task-3218314
Part-of: odoo/odoo#119381
Currently, automatically PO is generated in that PO buyer field is empty.
So in this commit, we added buyer field in partner form view, when rfq is
generated automatically and vendor has a specific buyer then at creation
of rfq, the PO buyer field will be set according to that.
TaskID - 3151213
closesodoo/odoo#113709
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
We want to propagate the analytic breakdown on the accrued
entries that user can already create from the PO/SO list views.
task-3096126
closesodoo/odoo#120864
X-original-commit: d4d92029bf7c2a2c6a670170d3207b457dda5c68
Signed-off-by: William André (wan) <wan@odoo.com>
# Steps to reproduce
* create two 17% sales taxes. We'll call those taxes `17a` and `17b`.
* set rounding method to global
* create a SO with the following 2 lines:
* Price = `50.4`, Taxes = `17a`
* Price = `47.208`, Taxes = `17b`
* note that the total tax amount on the SO is `16.59`
* confirm and invoice the SO.
You should see that the total tax amount on the invoice is `16.60`. The
invoice and SO should have the same tax amount.
opw-3179228
closesodoo/odoo#120224
X-original-commit: 715d0e269c3d42a5e25f8ddf648d275069354aaa
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Nshimiyimana Serge Séna (sesn) <sesn@odoo.com>
Co-authored-by: Laurent Smet <las@odoo.com>
Co-authored-by: Yolann Sabaux <yosa@odoo.com>
Failing use case:
Create a vendor bill and use the auto-complete field to select a purchase order multiple times.
The purchase order gets added to the vendor bill multiple times, this doesn't happen in V15 and was never intended.
The reason is simply that the code was checking on self.line_ids which get only populated after the record is saved and its invoice_line_ids are synchronized. Before that, only the field invoice_line_ids is filled witht new_ids.
opw - 3196149
closesodoo/odoo#119758
X-original-commit: 29d5862d447dd369432b345e43d5875d3b2a4474
Signed-off-by: William André (wan) <wan@odoo.com>
Steps to reproduce:
- put the currency of the bill to eur
- change the partner with a partner with no purchase currency set
Issue:
The bill is re-set to usd
Note:
addendum to https://github.com/odoo/odoo/pull/116852
opw-3233527
closesodoo/odoo#119753
X-original-commit: 51ff9c6026b8f9079aba7c9e26891f62c782761d
Signed-off-by: Cedric Snauwaert <csn@odoo.com>
Signed-off-by: Yolann Sabaux (yosa) <yosa@odoo.com>
Steps to reproduce:
- company currency = USD
- set a partner P with a `property_purchase_currency_id` in EUR
- create a bill with Azure partner and set an bill line
- change to partner P
issue -> the currency of the line has not been change
- change to Azure
issue -> no change about the currency
Cause:
- We update the move.currency_id but not the line_ids.currency_id
- after setting Partner P, we try to set a partner that no `property_purchase_currency_id`, we do not enter in the condition
opw-3233527
X-original-commit: 213e22c63f6259e2e69193b7d6a7022d8b6eab20
Part-of: odoo/odoo#119753
The issue is when we create a new PO with notes/sections and these notes/sections are showed on purchase reporting and only the products were supposed to appear there.
This issue happens because the SQL query wasn't applying any filter to the lines. The solution is apply a filter by display_type.
Steps to reproduce:
1) Go to Purchase App -> Purchase Orders -> Create a new PO with notes/sections
2) Go to Reporting -> View as pivot
3) You'll be able to see the section/notes you just created
closesodoo/odoo#119001
Opw: 3245933
X-original-commit: 8a9aa4c65bfdc776772e46bd199f6042f2678895
Signed-off-by: Adrien Widart <awt@odoo.com>
Signed-off-by: malv-odoo <malv@odoo.com>
Replaced _.each() functions (average 235 occurences)
Description of the refactoring this PR addresses:
Current behavior before PR:
There are underscore.js function enumerated above used in odoo.
Desired behavior after PR is merged:
These functions has been replaced by native javascript
prototypes/methods/functions.
TaskId : 3246238
closesodoo/odoo#118565
Signed-off-by: Georis François (fge) <fge@odoo.com>
Install only the “purchase” module and run the test, it’ll always fail
since the product type is added in the stock module
Bug introduced in: https://github.com/odoo/odoo/pull/117956
Solution:
Use the consumable type instead
closesodoo/odoo#118672
X-original-commit: e155d91a906fabff02c0d34af51f874daebef909
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
account, purchase, sale
before this commit, opening a record from
portal(sale, purchase, invoice, project)
shows the window title as Invoice Portal Template,
Purchase Order Portal Template and
Sales Order Portal Template etc
* navigate to portal
* click sales order
* click and open any sales order
* see the window title
after this commit, better title will be
displayed to the portal users.
Invoice Portal Template --> Invoice/Bill
Purchase Order Portal Template --> Purchase Order
Sales Order Portal Template --> Sales Order
closesodoo/odoo#118567
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
When using message_post, the body format must be explicitly specified.
If html is expected, a Markup object should be used.
If text is given, the content will be escaped.
Before this PR:
message_post was unaware if the content of a message was HTML or
text. This lead to multiple situation where the content was
incorrectly considered as HTML and led to display errors.
In
self.message_post(body="Hello %s!" % self.name)
if the name contained HTML, it would be evaluated.
In
self.message_post(body="Contact Raoul <raoul@caramail.be>")
the email would not be displayed as considered as unknown HTML and
discarded by the sanitizer
Now each call must explict the type of content.
Use the escape() helper to properly combine Markup and translations.
It would also be acceptable to use Markup() to wrap a static
translation but escape is better as one can not guarantee the content
of a translation.
closesodoo/odoo#111850
Related: odoo/documentation#3612
Related: odoo/enterprise#36728
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Steps to reproduce:
1-create a weight unit 'jm' bigger than reference
ratio 2.47541 rounding 0.001
2-create a stored product uom:'jm' / purchase_uom: 'kg'
3-set valuation method to automated (fifo)
4-create a replenishement for 200 (jm)
5-confirm and recieve the products
6-valuation for that stock move is null
Bug:
computations in the stock module are done with rounding method (half-up)
when computing the unit price the recieved quantity is computed with up
rounding which leads to a mismatch
Fix:
applied the same rounding method on all the Steps
opw-3213997
closesodoo/odoo#118251
X-original-commit: c305942958c73414def47ebd299227999841c6ed
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Walid Hanniche (waha) <waha@odoo.com>
Steps to reproduce the bug:
- Create a storable product “P1”
1:/
- Select the company A
- Create a purchase order:
- product: “P1”
- vendor: “V1”
- confirm the PO
The vendor “V1” is added to the supplier list of “P1”
2:/
- Select the company B
- Create a purchase order:
- product: “P1”
- vendor: “V2”
- confirm the PO
Problem:
The vendor “V2” is added to the list but “V1” is deleted from the list
in company A
The “seller_ids” field is in the “product.template” model, we try to
modify it in the “_add_supplier_to_product” function from the
“product_id”(product.product) field which inherits from the
“product.Template” model:
https://github.com/odoo/odoo/blob/3b88ed5ea458a37ee4d440f83bab45bd0fb13845/addons/purchase/models/purchase.py#L531-L532
So the function “inverse_related” will be called, in which the function
“__set__” will be triggered: In the values, the command for the create
will be added but the command for the set will be added as well while
it shouldn't. So in the `write_real` function a search will be done to
get all `product.supplierinfo` with the same product_tmpl_id:
https://github.com/odoo/odoo/blob/36544651f2049bcf18777091dbf02c9631b33243/odoo/fields.py#L4415-L4417
but as we are in sudo, those of company “A” will also be recovered, so
they will be unlinked since they are not in the command.set
opw-3251941
closesodoo/odoo#117985
X-original-commit: 78f803f3c1963711e2a5541f913f030da4f06fb7
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Current behavior:
When you create a contact and a delivery adress for this contact. If you
add the delivery adress as a vendor to a product, and purchase this
product from the delivery adress, the contact will be added to the
product vendor list.
Steps to reproduce:
- Create contact C
- Create delivery adress D for C
- Create product P
- Add D as a vendor to P
- Create PO for P from D, and confirm it
- Go to P, and check the vendor list (C is there)
opw-3177309
closesodoo/odoo#117902
X-original-commit: 67031d2b3d7d52297d18a69c76b4f747b17142e3
Signed-off-by: Engels Robin (roen) <roen@odoo.com>
Purpose of the commit is to do the generic improvements for project.
So in this commit did the following changes:
- adding a label 'last update' to the stat button in project form view.
- indicate 'my project' in the tab instead of 'project sharing view in portal' in project sharing.
- set the first non-folded stage of the project as default on newly created tasks.
- remove user confirming the SO as the default project manager.
- hide fields service_tracking, service_upsell_threshold if sale_ok is false.
- set purchase_method to purchase by default if product is of service type.
- remove the : next to the totals labels and decrease the font-size for values of 'total hours'
and 'remaining hours' in timesheets notebook in project task form view.
task-2897867
closesodoo/odoo#96548
Related: odoo/enterprise#29774
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Co-authored-by: Manisha Tulsiyani <matu@odoo.com>
Since BS5 integration in v16.0, the pdf of the sale and purchase report have changed. Borders would be present in the body of the report and the total detail.
Came back to v15 display by using the table-borderless class on those elements.
closesodoo/odoo#117492
X-original-commit: 8dd6927ca6195f9972f6f444395765aafca1b593
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
This commit converts almost all odoo module by native module.
The goal is to deprecate odoo.define in favor of native module and then
simplify boot.js by removing the regexp that finds module dependencies.
task id: 3162300
closesodoo/odoo#117305
Related: odoo/enterprise#39118
Signed-off-by: Géry Debongnie <ged@odoo.com>
With this PR, the `digest_data` template has been changed, so the `digest_tips`
is not compatible with the new changes.
This commit changes the `digest_tips` data to be compatible with the new changes.
Below are the modules affected:
- account
- crm
- digest
- hr_expense
- hr_timesheet
- im_livechat
- mrp
- project
- purchase
- sale_management
- stock
- website
task-2717426
Part-of: odoo/odoo#89549
According to Wiktionary, French spacing is "the archaic practice (though
still current in French) of inserting a space around colons, semicolons,
question marks, and exclamation marks". This is not standard practice in
English and most languages of the world.
The purpose of this commit is to start purging the code from this typo,
as it may reflect poorly on the software for some people.
closesodoo/odoo#116167
Related: odoo/enterprise#38542
Signed-off-by: Louis Wicket (wil) <wil@odoo.com>
The current algorithm to match vendor bills with purchase orders was written
while keeping in mind that the vendor bill data came from an OCR scan and was
thus not very detailed or totally reliable.
The current algorithm tries to match in this order:
1. Document reference(s) match(es) one or more purchase orders and the total
amounts of the bill and the purchase order(s) match as well.
2. Document reference(s) match(es) one or more purchase orders and the total
amount of the bill matches a subset of lines in the matched purchase order(s).
3. Document reference(s) match(es) one or more purchase orders but the amounts
do not match.
4. No document reference, but the vendor and total amount of the bill matches
exactly one purchase order.
When we generate a vendor bill from an EDI document (electronic invoice), we do
have very accurate information however and can also match line by line, since
our vendor bill will contain separate lines.
In this commit we add an extra algorithm specifically for EDI documents:
* We find all purchase orders matching the vendor bill reference(s)
* For every vendor bill line (having a unit price), we try looking in our
matched purchase orders' lines for the same unit price and a remaining
quantity higher than or equal to what is in the vendor bill. If multiple matches
are found, we check the name similarity and take the most similar line.
* We replace the vendor bill line with the purchase order line, changing the
quantity to the one on the original vendor bill line.
* Unmatched vendor bill lines remain untouched.
We also remove matching method 2 (see above) for EDI documents, in favor of the
new algorithm.
This approach makes that more purchase order lines will be able to get matched
when using EDI documents.
task-3140712
closesodoo/odoo#112684
Related: odoo/enterprise#37061
Signed-off-by: Laurent Smet <las@odoo.com>
They dates from < 2027 and are quite outdated. Favour the nl
translation instead.
n_BE is not on Transifex so it was not possible to correct bad
translations.
closesodoo/odoo#115845
X-original-commit: d04c8b7e484db8306d858c891a7a2b11885fdcd9
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
* The tours are now run by the `MacroEngine` defined in `macro.js`.
* This is accomplished by converting (at runtime) the user-defined tours to
`Macro`s. See `tour_compilers.js` for the step (and tour-to-macro) compilation.
* API is kept the same as much as possible. Basically, declaring tours stayed
the same with some exceptions:
* `allowInvisible` can be provided in a step to allow consuming the trigger
element even if it is invisible.
* `isCheck` can now be used to replace the no operation `run` that is
traditionally signals the runner to only perform a check.
* Before, multiple `run`s can be called simultaneously. Now, each `run` method
is awaited before proceeding to the next step.
* If the trigger element is `disabled`, the tour runner will *not* proceed on
calling the `run` method and the runner will stay on current step until the
trigger element becomes `enabled`.
* However, the tour runner is okay with `disabled` trigger element if the step
has `isCheck = true`. As long as the trigger element is found for `isCheck`
step, the tour runner will happily move to the next step.
* Some tours are adjusted to properly run with this new tour runner.
* When the tour failed:
* The dom string is not logged anymore.
* However, a warning message containing the relative location of the step will
be logged. This is better in helping the author in locating the failed step.
**Some guidelines learned during the development:**
* Each step may trigger a dom mutation. It's a good practice to insert an
intermediate step that *checks* the existence of an element that result from
the action of the previous step.
* Refrain from using the `run` method for assertions. `run`, in principle, is
provided to perform actions that are not offered by the helper. Use the
`trigger` for assertions.
* During dev, find `SHOW_POINTER_DURATION` and set it to `250`. This will show
the pointer (pointing to the trigger element) for 250ms when watching the
tour.
closesodoo/odoo#107618
Task-id: 3082036
Related: odoo/enterprise#37560
Signed-off-by: Géry Debongnie <ged@odoo.com>
Co-authored-by: Julien Mougenot <jum@odoo.com>
To reproduce the issue:
1. Create user with no access rights apart from user rights in Sales,
Sign, Project and Timesheet
2. Create a project, add a task inside and link an analytic account
to the project
3. Create an RFQ, add a product linked to the analytic account
4. Confirm order, receive product, validate, create bill
5. Log in with user
6. Try to access the analytic account through:
Project->Task->project name->Settings->Analytic account
7. An error message pops-up "You are not allowed to access Purchase
Order (purchase.order) records."
Error: You should be able to access the analytic account, but the
Purchase Order smart button should not be visible/present
The data access by the smart button was not stopped by rules or
groups, thus data was always trying to be loaded, even when the user
did not have the access rights
OPW-3180788
closesodoo/odoo#115058
X-original-commit: 9e8b2ba1ae05de72f492d833edd8da91ded6f5b0
Signed-off-by: Adrien Widart <awt@odoo.com>
Signed-off-by: Demany Antoine (ande) <ande@odoo.com>
- Create a product with a very long product description
- Add in a PO and print the RFQ
The description overlaps with the table header on the second page.
This is a known issue of wkhtmltopdf (see issues 1770 and 1524 for
example), and there is no known workaround. It can be avoided by
preventing the repetition of the header.
closesodoo/odoo#114916
Opw: 3208347
X-original-commit: cc5be8a907b2c3f33c6a62c5693726d757ffd113
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
This commit contains mainly code cleaning, docstrings and a small split
for notification tool methods. In this commit we
* make some notification groups variable explicit;
* move the filler of groups into its own submethod to ease being called
from other code (to be used soon);
* fix some strange overrides or code manipulation;
* propagate some additional parameters to ease future commits that will
improve rendering of groups-based notification emails;
* cleanup, fixup and improve docstrings;
This does not change anything from functional point of view, just preparing
further work.
Task-3046371 (Mail: Better Language Support in Composer)
Part-of: odoo/odoo#106177
The type fields of actions already defaults to
the model name in the base model definition.
Therefore, specifying `ir.actions.server`, `ir.actions.act_window`
& so on as type is useless (and adds noise since it's the same as
the action model).
closesodoo/odoo#114539
Related: odoo/enterprise#37855
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
before this commit, enabling the mass editing for the picking operation type tree view or for purchase.order tree view using the studio, throws the exception.
* install studio
* open purchase order tree
* enable mass editing for the tree from studio app
* exception will be shown
after this commit, on enabling mass editing on this tree view, will not throw exception.
closesodoo/odoo#114669
X-original-commit: dad9d98697781307a1cb537e8e818a775b50432a
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
This fulfills the goal of searching and fetching fields in a single SQL
query. We introduce the new method search_fetch() for that purpose.
Also introduce method fetch() to fetch some fields for a recordset if
they are not in cache yet.
The call graph is as follows:
search() calls search_fetch()
search_read() calls search_fetch() and _read_format()
read() calls fetch() and _read_format()
search_count() calls _search()
search_fetch() calls _search() and _fetch_query()
fetch() calls _search() and _fetch_query()
The methods _search() and _fetch_query() are usually the ones to
override to implement business-specific logic. The method _search()
returns a Query object to retrieve the records that satisfy the given
domain and are accessible for reading. The method _fetch_query() uses a
Query object to retrieve fields from the database and store them in
cache.
Also use search_fetch() to save one query in search_read() and the
reading of one2many fields.
Part-of: odoo/odoo#112126
Before this commit, the accounting module had a setting on the selection of taxes used by the sales, purchase, website_sale, ... modules. In addition, the website_sale module had the same setting related to the accounting one.
This PR isolates the tax selection parameter in the website_sale module, and instead of using the tax selection, the accounting module will use rounding method (round per line, round globally).
Selecting one of the two will change the display of all account_move or other view using the tax selection setting.
Display changes:
In round per line, a column tax excluded will always be displayed while a column tax included will be in optional hide.
On the other hand, in the round globally, only the tax excluded columns will be available.
closesodoo/odoo#99209
Task-id: 2954332
Related: odoo/upgrade#3826
Related: odoo/enterprise#30853
Signed-off-by: William André (wan) <wan@odoo.com>
Before this commit, the widget's description was stored on the
component and this component was then registered.
Now, an object describing the widget is used on registration the same way
as it is done for views since b828cfc.
This split the component's description (props, template, ...) of
the widget's description ( component, extractProps, ...) and makes
it clearer.
We did the same thing for fields in 9f4622492c
Part of task: 3179751
closesodoo/odoo#112962
Related: odoo/enterprise#37215
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
With Rounding Method set to 'Round Globally'
Create a Quotation with 2 lines:
- Price 6.7, Tax 15%
- Price 6.7, Tax 15%
Total is 15.41, Tax amount 2.01
When sending the quotation via email or in list view the amount total
shown is 15.42.
This occurs because:
- order total is computed as sum of the lines `price_total` field,
which, defined as Monetary, store already rounded values
- line total is computed via `_compute_taxes`, where
tax amount is always rounded per line
opw-3113851
closesodoo/odoo#113026
X-original-commit: c677f45dcb050ce7e6f755b71e56c9b9120bf613
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Grazioso Andrea (agr) <agr@odoo.com>
This commit fixes an issue where the "No records found" helper text is
wrongly positioned below the sample data's records (i.e. not visible)
instead of over them.
This is basically a revert of 9407383a56
due to the changes in the DOM and styling made in the meantime.
But actually we can go further and ensure we always have the ListView's
table present in the DOM. This change allows to simplify the positioning
of the helper and the implementation of the Purchase's dashboard.
Steps to reproduce:
- create a new database **without demo data**
- install "Planning" and "Sales" apps
- with a mobile-like screen size, open Planning
- switch to Gantt view
- in a cell, click/tap on the magnifier button (which is on hover...)
- the many2x view doesn't contain data
=> action helper "No records found" isn"t visible (scroll to bottom to
find it)
closesodoo/odoo#112878
X-original-commit: 766498a36b322ffe9c647616f56f3ba04cc51d96
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
Steps to reproduce:
- Install stock, purchase
- Create a product with a long name without whitespace
- Create a purchase order with that product
- Go to portal and access the purchase order
Current behavior:
- Product description overflows when accessing the PO from the portal
Behavior after the PR:
- To fix the problem in the Portal we add table-responsive to the table
opw-3133407
closesodoo/odoo#112672
X-original-commit: 5abccc5efc6e333c8a889a1c24419dadc9c6e7f0
Signed-off-by: Bouvy Damien (dbo) <dbo@odoo.com>
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This commit fixes the case where portal_customer is not added in the
recipients group by the portal mixin.
Steps to reproduce:
- Go on a purchase
- Log a note and tag a user who handles notification by email
- Traceback:
```
File "/home/odoo/src/odoo/addons/purchase/models/purchase.py",
line 346, in _notify_get_recipients_groups
customer_portal_group = next(group for group in groups if group[0] == 'portal_customer')
StopIteration
```
Current Behavior:
- Traceback StopIteration
Expected Behavior:
- Log a note with the tagged (boomer) user.
See odoo/odoo@f879cf2867closesodoo/odoo#112465
X-original-commit: 7b9dd53a5573141275d41436189c782bccb96c3d
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This commit removes the legacy implementation of the form, kanban
and list views. It also removes the legacy view widget registry,
and all legacy widgets it contained. The legacy field registry
couldn't be removed yet as some fields are still used (e.g. in
client actions: FieldMany2One, FieldMany2ManyTags...), and
sometimes accessed from that registry (e.g. uom service). More
clean up will come later. Note that all tests using legacy views
have thus been removed, even though the tested feature might still
remain (e.g. FieldMany2One tests have been removed, but that field
is still there). However, those features are deprecated and
unlikely to evolve. They should be removed in the next saas, or the
one after.
Finally, this commit also removes the legacy view dialogs.
Task 3168640
Part-of: odoo/odoo#111809
To reproduce the issue:
1. Install [Inventory], [Purchase] on Apps
2. [Settings]>[Inventory]>[Storage Locations]: enable
3. On [Purchase], Create. 'Deliver to' field is ill-positioned
Desired view: use the full width of the row
Applicable versions: 16.0 - master
opw-314167
closesodoo/odoo#111759
X-original-commit: 46700f12b0b4e64029bccf3abb791fe95400331d
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Lee, Hansun (hale) <hale@odoo.com>
Steps to reproduce:
- Create an analytic plan with the domain as a Bill
- Create an analytic account for the above plan
- Create an analytic distribution model and include condition as account prefix, and product.
Issue:
The analytic distribution model doesn't apply to the bill created via purchase order
Solution:
Make sure we set the analytic_distribution only if present in order
to trigger the compute during invoice creation.
opw-3160041
closesodoo/odoo#111717
X-original-commit: ce5cae1da3f453ce1aad0915189e0e305d7e55e0
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Yolann Sabaux (yosa) <yosa@odoo.com>
When a vendor bill document is uploaded (EDI, PDF,..) the link with
the purchase order is often lost.
We want to reuse the purchase.order OCR' matching logic to enhance
vendor bill extracted from documents.
To sum up the logic;
- if we find a partner or reference match (invoice_origin)
AND the same amount, we use autocomplete and replace the line in the vendor
bill with the purchase order one.
- if we find a match with the reference and some line in the purchase order
sum up to the vendor bill total, we add those line in the vendor bill
but we set the qty to zero (the accountant can manually remove the XML
line and link the new one afterwards).
task-id: 2828521
[community](https://github.com/odoo/odoo/pull/109093)
[enterprise](https://github.com/odoo/enterprise/pull/35436)
update master: make _find_matching_subset_invoice_lines private
closesodoo/odoo#111491
X-original-commit: ebc8b007ecb375d20c566b6e6ecc3f6749ebaa2a
Related: odoo/enterprise#36545
Signed-off-by: Josse Colpaert <jco@odoo.com>
This is a step closer to a goal of avoiding dependence on asynchronous
modules. Starting from this commit, new tour definition should be
registered to `registry.category("web_tour.tours")` registry.
So, instead of the following:
```js
import tour from "web_tour.tour";
tour.register(name, options, steps);
```
We now do:
```js
import { registry } from "@web/core/registry";
registry.category("web_tour.tours").add(name, optionsWithSteps);
```
Notice the `options` and `steps` params are merged when registering
the tour definition. It should look something like so:
```js
registry.category("web_tour.tours").add("account_tour", {
test: true,
steps: [ ... ],
});
```
And if the `TourManager` instance is needed, one can get it from the
registry like so `registry.get("tourManager")`. Note however that
this instance is only available when the `TourManager` has been
instantiated -- so it's not available at top level of the module.
closesodoo/odoo#111103
Related: odoo/enterprise#36335
Signed-off-by: Géry Debongnie <ged@odoo.com>
Brieuc-brd