Current behavior:
The invoice payment term of the report is a p tag with another p tag inside like:
<p name="payment_term">
<span>
<p> This is a payment term note</p>
</span>
</p>
but because nested p tags are not supported in html de result in the browser is something like:
<p name="payment_term">
<span></span>
</p>
<p> This is a payment term note</p>
<p></p>
Similar behavior can be observe for the fiscal position note.
Expected behavior:
The code should respect html format rules and not have nested p tags.
Solution: We replace the parent p tags by div tags, and we modify xml file that have xpath relying
on this tag.
opw-2804933
closesodoo/odoo#88660
Related: odoo/enterprise#26372
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
For the Switzerland localization, we need to append some extra pages during the PDF generation such as QR barcodes or ISR payment slip.
There were multiple difficulties with the current codes:
- The ir.attachment was generated before the hook allowing to append the extra pages.
- There is no existing hook allowing to get the pages for each invoice when printing on multiple records at once.
This commit aims to dispatch the generation of PDFs from the creating of extra attachments:
- `_render_qweb_pdf_prepare_streams` is called first and creates a stream for each record containing the PDF pages.
- Then, the ir.attachment are generated if necessary.
- Finally, all streams are aggregated together to get the final PDF.
Task: 2726507
Part-of: odoo/odoo#85150
These helpers are used to create the repartition lines and the taxes in
the upgrade script which upgrades the tags on the taxes.
See https://github.com/odoo/upgrade/pull/3137closesodoo/odoo#89912
X-original-commit: 8927003d0c32e81d28ece68e61c1a737bd7532d2
Signed-off-by: Olivier Colson <oco@odoo.com>
Signed-off-by: Julien Van Roy <juvr@odoo.com>
This reverts commit fe7d56dc32c71e04b54de9dbd756a48942a832f4.
The original commit created an unwanted side effect that was
being solved here https://github.com/odoo/odoo/pull/89632
But while testing the new PR, it appeared that the initial bug
was no longer there, even without the original fix.
Hence this PR.
closesodoo/odoo#89895
X-original-commit: af01dac8e35fe814b1d42a1620ff766908425b33
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: John Laterre <jol@odoo.com>
Canceled and draft entries are the same color as posted entries. They should be in a different color (grey/blue) in order to be distinguished from other invoices/bills.
Amount Due, a.k.a. amount_residual(_signed), is not 0 for draft and canceled entries. It should be 0 since they haven't been posted yet.
A few tests have to be adapted to reflect this change in spec.
Task=2801521
closesodoo/odoo#88295
X-original-commit: 498a4a52b5fbc5466d8d0652db10563ccba55032
Related: odoo/upgrade#3435
Signed-off-by: Laurent Smet <las@odoo.com>
- Setup at least 2 bank accounts [ACC1] and [ACC2]
- Setup a Journal [BNK1] with [ACC1]
- Setup a second journal [BNK2] with [ACC2]
- Create an Internal Outgoing Transfer from [BNK1]
setting as destination journal [BNK2]
- Save and confirm
partner_bank_id will be selected from:
- the Journal, for inbound payments, so [ACC1]
- one, possibly the first, bank account of the company for
outbound payment, so [ACC1] or [ACC2]
This is wrong as [ACC2] should be used because defined on [BNK2]
which is the destination journal
opw-2794081
closesodoo/odoo#89599
X-original-commit: 4624d1ebdedf84ed3031f7af1be827de54f72566
Signed-off-by: William André (wan) <wan@odoo.com>
Create a 15% tax [TaxA] *not* included in price
Create a 15% tax [TaxB] included in price
Create a fiscal position mapping TaxA to TaxB
Create a customer and assign this fiscal position
Create a product :
Price = 100€
Tax = TaxA
Create a SO with this customer and this product
We have this situation
| Price Unit | Tax | Subtotal |
|------------|-----|----------|
| 115 | TaxB| 100 |
While it should be
| Price Unit | Tax | Subtotal |
|------------|-----|----------|
| 100 | TaxB| 86.96 |
after tax mapping, as it was before
https://github.com/odoo/odoo/commit/625486a8382fde9033b73e2a4b4e7713cf4131c1
opw-2811596
closesodoo/odoo#89361
X-original-commit: 1a5b2b44c63afb302a2d6fc1e841e4ef3af46df5
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Grazioso Andrea (agr) <agr@odoo.com>
Have a purchase tax with cash basis payment enabled
Have a product with said tax
Create a bill with the product, save and confirm
Register a payment
Check CABA entries
There should be 4 entries, but only 2 have been generated
opw-2782561
closesodoo/odoo#89101
X-original-commit: d8d255ec68ab4f220da51fb2be7292dcc74d5783
Signed-off-by: Olivier Colson <oco@odoo.com>
Signed-off-by: Grazioso Andrea (agr) <agr@odoo.com>
Co-authored-by: oco-odoo <oco@odoo.com>
When invoicing a tracked product, the lots/SN delivered (or the related
quantities) are not always the correct ones displayed on the printed
invoice
To reproduce the issues:
1. In Settings, enable "Display Lots & Serial Numbers on Invoices"
2. Create a product P:
- Storable
- Tracked by lot
3. Update its quantity > 5 with lot L
Use case 01:
4. Create and confirm a SO with 5 x P
5. Process the delivery
6. Create an invoice
7. Edit the invoice line:
- Quantity: 1
8. Post and print the invoice
Error: The quantity related to lot L is 5, it should be 1
Use case 02:
4. Edit P:
- Invoicing Policy: Ordered quantities
5. Create and confirm a SO with 1 x P
6. Create and post the invoice
7. Process the delivery
8. Print the invoice
Error: There isn't any information about delivered lot L
Use case 03:
4. Create and confirm a SO with 3 x P
5. Deliver 1 x P (with backorder)
6. Invoice 1 x P + Post the invoice (-> INV01)
7. Deliver 2 x P
8. Reset, post INV01 again and print it
Error: The quantity related to L is 3, it should be 1. Moreover, if the
user then invoices the 2 others P, posts and prints this second invoice,
it won't contain any information about L
OPW-2730270
closes#81444closesodoo/odoo#89088
X-original-commit: 3598c0c8cda813efa1aebc17f041e4c0a1a29f06
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
Co-authored-by: Adrien Widart <awt@odoo.com>
Co-authored-by: Florent de Labarre <florent.mirieu@gmail.com>
Steps to repoduce:
- Accounting > Customers > Invoices:
select several invoices to send
- Action > Send & Print > (deselect Print) > Send & Print
Issue:
- It sends only one invoice per company
Cause:
- the mail_compose_message sets the status of an email as `cancel` when a mail has already been sent to a specific adress mail in the batch
Solution:
- If the use of mass mailing is document-based (e.g.: sending multiple invoices) it will allow to send multiple emails to the same adress
opw-2775121
closesodoo/odoo#88992
X-original-commit: f08685020f6a00d4e10e30ccbcf70c9eb1a764d5
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
1. _get_payment_method_codes_to_exclude was not considered on _compute_payment_method_line_id
2. to avoid duplicating code on _compute_payment_method_line_id we can directly call available_payment_method_line_ids
3. to avoid re-defining dependencies (and make inheritance easier) we can use 'available_payment_method_line_ids' on _compute_payment_method_line_id
4. fix docstring, _compute_payment_method_fields does not exists anymore, it's called _compute_payment_method_line_fields
5. fix using "self" instead of pay when calling _get_payment_method_codes_to_exclude
closesodoo/odoo#88666
X-original-commit: 63d46ba547c3b0fbadd7c076451659734ad767ae
Related: odoo/enterprise#26167
Signed-off-by: Florian Gilbert <flg@odoo.com>
There is an issue where we redirect to a list view/form view of
res.partner but with id's from res.partner.bank, thus redirecting to
the wrong views.
closesodoo/odoo#88865
X-original-commit: a1cce790fcd2d1823fb9e3d5c3c3e916d34568e5
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Signed-off-by: Nicolas Viseur <vin@odoo.com>
The Credit Limit group on the res.partner record
doesn't appear until you save the record.
This means you have to perform extra clicks
if you want to edit this value.
The goal is to show the `credit` field on the accounting tab
on creation if `res.partner` is a company and
Credit Limit setting is activated.
task-2817650
closesodoo/odoo#88830
X-original-commit: 0ac5f58d4d4786a0b86bf0b71406d7d2c5d470bf
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Signed-off-by: John Laterre <jol@odoo.com>
Fix two issues linked to payment methods and their journal link.
SEPA Credit Transfer was marked as only available on EUR journals, but
from what we have been told, and we have seen, it should also be made
available for other currencies (CHF/SEK).
So we are changing the rule used to determine if SEPA Credit Transfer
is available on a journal to allow to use it on journals using CHF or
SEK as a currency.
There is another issue, where the filtering is done differently at the
journal creation and when the user add the payment method manually in
the lists.
The filter rules were not respected at the journal creation, which
would lead to incorrect default inbound and outbound payment method list.
For example, a new journal would have the company currency (let's say,
USD) but still have SEPA Credit Transfer (EUR,CHF,SEK) added on it by
default while it should not be available there.
opw-2777522
X-original-commit: 0ad8faf3bfc7b28e5668c3445fcc06c24ad98354
[FIX] account_*: payment method journal filter
Fix two issues linked to payment methods and their journal link.
SEPA Credit Transfer was marked as only available on EUR journals, but
from what we have been told, and we have seen, it should also be made
available for other currencies (CHF/SEK).
So we are changing the rule used to determine if SEPA Credit Transfer
is available on a journal to allow to use it on journals using CHF or
SEK as a currency.
There is another issue, where the filtering is done differently at the
journal creation and when the user add the payment method manually in
the lists.
The filter rules were not respected at the journal creation, which
would lead to incorrect default inbound and outbound payment method list.
For example, a new journal would have the company currency (let's say,
USD) but still have SEPA Credit Transfer (EUR,CHF,SEK) added on it by
default while it should not be available there.
opw-2777522
closesodoo/odoo#88677
X-original-commit: e2cd91ad8339f73b2547bc839e675443528f3adf
Related: odoo/enterprise#26172
Signed-off-by: Florian Gilbert <flg@odoo.com>
Even if ORM normally filters them out, no need to specify .id in domains.
This leads to better and easier to read queries / domains.
Task-2816580
closesodoo/odoo#85648
Related: odoo/enterprise#24911
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
If applied, this commit will fix the following bug by using the price
with the additional cost added instead of only the price
Steps to reproduce:
1- install sales
2- create a product p with variant pv
3- set an extra value for pv
4- go to Products>Product Variants
5- open the pv in form view
6- the Sales Price is the price of p not pv
(which should be p + extra value)
7- also the tax string is calculated on p not pv
Bug:
```list_price``` is being used
Fix:
replace ```list_price``` with ```lst_price```
OPW-2774199
closesodoo/odoo#88270
X-original-commit: 46526f629f7645eaac8ce86e81e806cfa392b8b8
Signed-off-by: William André (wan) <wan@odoo.com>
Task ID: 2712093
Currently:
- In the payment widget the exchange difference value is always shown as 0 and is described as "Paid on", which can be confusing for a user
Desired:
- The exchange difference should have the difference amount and be described as "Exchange difference" (text-muted)
- In the payment widget pop-up, show the both the amount in company and foreign currencies
closesodoo/odoo#82206
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Currently, when modifying an invoice line and setting taxes
(price included) for 100%, the price_unit field will
be displayed as 0.
This is incorrect and is being fixed here.
opw-2793284
closesodoo/odoo#88180
X-original-commit: 674eaa3bc10210d34a02145529516da1fa1c1b66
Signed-off-by: Laurent Smet <las@odoo.com>
Most of the extensions of `_name_get` are very similar and only want to
search for the given string in multiple fields.
A lot of extensions also don't take into account the negative operators.
Some implementations were also really outdated and needlessly
complicated.
closesodoo/odoo#86588
Related: odoo/enterprise#25608
Signed-off-by: Raphael Collet <rco@odoo.com>
* Previously, when reconciling journal items in multi-currencies, the exchange difference entry was created only on the full reconciliation. It will now be created directly at each partial to ensure the ratio between amount_residual_currency and amount_residual is always kept identical.
* Also when reconciling two lines, one with a foreign currency and one expressed in company currency, the reconciliation is now made based on the foreign currency.
==== RATIONALE ====
This patch allows to fix the following use cases (among others)
1) When everything is expressed in foreign currency, the reconciliation is made in that currency:
Suppose EUR is the foreign currency and USD is the company currency. Reconciling:
L1: 120 EUR 60 USD (rate 2:1)
L2: 240 EUR 80 USD (rate 3:1)
..leads to a partial of 120 EUR and min(80, 60) = 60 USD
After the reconciliation, L1 is fully matched but L2 is still open with 120 EUR but only 20 USD.
This is the first problem is the current reconciliation because L2 is supposed to have a rate 3:1 so the residual amount should be 120 / 3 = 40 USD.
Since the rate is no longer consistent on L2, the user will probably close the reconciliation by using another line in EUR or will close manually the reconciliation with 20 USD but without any additional exchange difference journal items explaining where this unconsistency comes from.
2) When the current lines are mixing multiple currencies, the reconciliation is made using the company's currency.
In some countries like Mexico, Ethiopia or Costa Rica, the customer is free to pay an invoice using the company's currency instead of the foreign one.
So, suppose USD is the foreign currency and MXN is the company currency.
The invoice is expressed by:
L1: 120 USD 60 MXN (rate 2:1)
If the customer is paying at a date in which the rate is 3:1, he is free to pay
either L2: 120 USD 40 MXN (rate 3:1), either L2: 40 MXN.
In the second case, he is expecting the invoice to be fully paid because its paiement is equivalent to 120 USD at the payment date.
In Odoo, the second case led to an open balance of 20 MXN and the invoice was not completely paid.
Even this situation could be easily fixed by a manual write-off, this makes the Mexican payment EDI very complicated to fullfil correctly because the government is expecting a complete matching between the invoice and the payment.
When the customer is paying multiple invoices or the invoices are paid using multiple payments, the currently generated mexican EDI file in Odoo was wrong.
==== REFERENCES ====
Original idea suggested by hbto@vauxoo.com. Thanks for the contribution and patience of the many persons having, at some point, helped on that.
github issue: https://github.com/odoo/odoo/issues/37469closesodoo/odoo#84201
Task: 2669371
Related: odoo/enterprise#24268
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
This patch solves memory problem on exporting `account.move.line` records:
while export method invalidate cache for `account.move.line`, it keeps cache for
`account.move`, which may lead to memory error.
opw-2764457
closesodoo/odoo#88060
X-original-commit: 80c65498adf05b37d91207e0b59c781c6057f64b
Signed-off-by: Raphael Collet <rco@odoo.com>
no need to select * in a query that looks like
select ...
from A
where exists(select * from B where ...)
we can instead use
select ...
from A
where exists(select 1 from B where ...)
closesodoo/odoo#88013
Signed-off-by: Raphael Collet <rco@odoo.com>
Add quicksearch on 'Number' (name) and 'Reference' (ref) for the journal entries
Add quicksearch on 'Label' (name) and 'Reference' (ref) for the journal items
Even though those fields are already searched on in the 'main' quicksearch
of each view (i.e. 'Journal Entry' and 'Journal Item'), users might look to
specifically search on the label and reference, and get frustrated when they
won't find it in the available quicksearches.
task-2753889
closesodoo/odoo#87532
Signed-off-by: Laurent Smet <las@odoo.com>
=> Create an invoice in foreign currency
=> Register a payment of 0 using the currency of the company and select "Keep open"
A traceback is raised
closesodoo/odoo#87886
X-original-commit: 14894623029c24230dea92ccef950cff914e1704
Signed-off-by: Olivier Colson <oco@odoo.com>
Signed-off-by: Laurent Smet <las@odoo.com>
- Create an invoice having a foreign currency
- Register a payment of 0.0 using a different currency with a write-off of any account
=> traceback
Task: 2809565
X-original-commit: c86faecc980523fcfa6a3258f4c17bf30b41522c
Part-of: odoo/odoo#87886
Task: 2760136
Currently, when a credit note is created there is a message in the chatter "Invoice created", which is not coherent.
- Credit Note creation message should be "Credit Note created"
closesodoo/odoo#87868
X-original-commit: 93f65ff0b9e19037112c33ebda4cbfbd34f633e8
Signed-off-by: Olivier Colson <oco@odoo.com>
Signed-off-by: Tastemirova Aliya (alta) <alta@odoo.com>
When looking at the list of the payments and grouping by company, the total amount per company is no longer displayed since v15.
This is due to the fact that the new variable used to represent this data was no longer stored.
By storing this data, we can regain this ability.
task-2801688
closesodoo/odoo#87535
Related: odoo/upgrade#3401
Signed-off-by: Laurent Smet <las@odoo.com>
Have 3 moves named 0, 1 and 2
Delete move 1 to make a hole.
Resequence, starting the sequence at 2.
Expected: new names are 2 and 3
Result: an error because 1 is renamed to 2 but 2 still exists, leading
to a (temporary) duplicated name, which is not allowed.
We clear all the names to be resequenced before doing it in order to
avoid that.
closesodoo/odoo#87836
X-original-commit: bf5173f64582e2675f4121122ce26cb57624e08a
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Signed-off-by: William André (wan) <wan@odoo.com>
The basic idea of this functionality is for users
to be able to put limits on Partners that would
trigger non-blocking warnings when trying to confirm new:
- Sales Orders
- Invoices
when that partner has too many open invoices.
task-2722165
Part-of: odoo/odoo#83205
Improve a few things in accounts modules:
- Users wants to be able to change the account in the general ledger
list view
- Do not group by date by default when auditing a tax line.
- Make the currency fields only show in debug mode for accounts and assets
- Disallow to delete taxes linked to a tax repartition line, and
clarify the error message when trying to delete one linked to a
fiscal position's account mapping
Task id # 2810379
[IMP] account_*: some Back2Basics improvements
Improve a few things in accounts modules:
- Users wants to be able to change the account in the general ledger
list view
- Do not group by date by default when auditing a tax line.
- Disallow to delete taxes linked to a tax repartition line, and
clarify the error message when trying to delete one linked to a
fiscal position's account mapping
Task id # 2810379
closesodoo/odoo#87659
Related: odoo/enterprise#25770
Signed-off-by: Laurent Smet <las@odoo.com>
Have a Reconciliation model [DEMO] without tax
Create a bank statement
Open reconciliation widget
Select 'Manual Operation', select [DEMO], add any tax
Traceback will raise
This occur because the server will generate a line without `tax_ids`
field, that will remain undefined in the frontend
opw-2777191
closesodoo/odoo#87704
X-original-commit: 08f5dc605ccf42429d6405ec6c192322909c6c34
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Signed-off-by: Grazioso Andrea (agr) <agr@odoo.com>
The resequence feature and the possibility to edit the invoice number in
draft are powerful flexibility tools. Though, misusing them can lead to
holes in a sequence that can be hard to detect.
This task aims at providing alerts on the dashboard (on Sales and
Purchases journals' cards) highlighting the holes in the sections
_____________
Suppose the following sequence on a journal
BILL/2022/01/0001
BILL/2022/01/0002
BILL/2022/01/0004
> BILL/2022/01/0003 is missing.
Then show a link on this journal's card in the kanban view of journals
(accounting dashboard) mentioning.
> Check the sequence
Pressing the button opens the list view of bills on this specific
journal.
BILL/2022/01/0004 appears in red ; since it is after a hole
task-2767272
closesodoo/odoo#84788
Signed-off-by: Laurent Smet <las@odoo.com>
Steps to reproduce:
1. Install sales
2. Change Mitchell Admin contacts so that he is set in the "YourCompany" company
3. Create a quotation with Michell Admin as the customer
4. Put any item and confirm the quote
5. Receive the product and create the invoice
6. Go to the invoice, confirm the payment and register it
Issue:
-> Error with the journal id
Cause:
The payment is considered as internal payment and in https://github.com/odoo/odoo/blob/6d129783b53115927f664499207c8c800d40bca2/addons/account/models/account_payment.py#L886-L895
There is no destination_journal which violates not-null constraint
Solution:
Be sure that there is a destination journal when `is_internal_transfer` is computed.
opw-2753819
closesodoo/odoo#87625
X-original-commit: 362d8cbf7724431672b8b73fb5f4682d4d2c3f66
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: yosa-odoo <yosa@odoo.com>
Do not allow users to create accrual entries for locked periods.
This would either create an entry for another date, since the date is
changed automatically by `_get_accounting_date` when posting.
Reproduce:
* Set a lock date
* Do an automatic entry for either changing the account or the period
before that lock date
Or it would traceback because the date would be changed automatically
and no matching would be possible when changing the period.
* Set a lock date
* Create an automatic entry to change the period of an entry before the
tax lock date
closesodoo/odoo#87391
X-original-commit: f830b008781c2f6f5644395688654e64edd5c836
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Signed-off-by: William André (wan) <wan@odoo.com>
Unify taxes computation between 'account', 'sale' and 'purchase' including:
- computation of price_subtotal/price_total.
- computation of business models total (using the json field)
closesodoo/odoo#80231
Task: 2654784
Related: odoo/enterprise#25620
Signed-off-by: Olivier Colson <oco@odoo.com>
There were inconsistencies in the calls to `_render`.
* the view context could contain information that misled developers.
Indeed, the context and value of the view are not supposed to be found
in the rendering. Thus by calling `ir.qweb` with the name of the
template, we ensure that there is no unwanted information and in
addition the cache key is that of the name of the template which saves
a query.
* the context used for rendering was modified by a method on
`ir.ui.view`, except this is not information used by this model. There
is now a `_prepare_environment` method residing on `ir.qweb`. This
method allows to modify the value dictionary as well as the context in
which the rendering will be done. This preparation of the data as well
as my security check is done only once per rendering. This also saves
some queries
* Freeze options for rendering were inconsistent. It could be that
options on which rendering depends were not part of the cache key. Thus,
depending on the user who generated the generation of the rendering
function, there was or was not information in the template. For example
for automatic branding. This is no longer possible, because it is the
context that is used. The options serving as a cache key are only
recorded for information (for the profiling system for example). A
simplification of the `ir.qweb.field` models could be made.
The report rendering and call `ir.qweb` instead of `ir.ui.view`.
Part-of: odoo/odoo#85110
Purpose
=======
Pictures from the digest emails are currently stored on the database
itself, meaning that if the database expires (e.g. after trial expires) all
pictures from previously sent emails won't be visible.
This is an issue since digest tips are meant as a marketing tool to bring
people to Odoo after trying a database.
Digest pictures are now taken from Odoo's server
(https://download.odoocdn.com/digests) so that the pictures will still
be visible after the database has expired.
From this commit onwards, it should not be allowed to change a digest
picture with the same name (to display a gif of a newer version), since
all databases with previous versions would receive pictures of a version
that does not correspond to theirs.
This also means that everyone client's Odoo server will contain pictures
that are never used. This could be fixed if Odoo stored them somewhere
else and didn't make them dependent from the git repository.
Task-2372195
closesodoo/odoo#87343
X-original-commit: 35157677a2a63a2559a72aff21e62e23a3c671a2
Related: odoo/enterprise#25654
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
By adding an index the cost of the SQL's will be a lot lower.
See #86615 for info/sample
closesodoo/odoo#87287
X-original-commit: 44b445eba6287348211e002235e1d003b45f2d6e
Signed-off-by: William André (wan) <wan@odoo.com>
Show the optional field analytic_tag_ids with widget many2many_tags in
view account.move.line.tree.grouped
opw:2778260
closesodoo/odoo#86990
X-original-commit: fa4d41bcebde71c5aa7bbf53dd19bdaab748f4c8
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Simon Goffin <sig@odoo.com>
The journal in a cut-off has to be of type general. But there is an
issue at the moment where a default_journal_id would be provided in
the context (coming from the dashboard for example) and thus, fill
the journal in the cut-off wizard with a wrong value (vendor bill for
example).
This change make sure no default values are provided to the wizard.
closesodoo/odoo#87179
X-original-commit: 5b099bf6135b2ff517078d1839b513da7830f718
Signed-off-by: Florian Gilbert <flg@odoo.com>
Signed-off-by: Nicolas Viseur <vin@odoo.com>
mafo-odoo