Steps to reproduce:
[account_edi_ubl_cii]
- create an invoice and set a line with on the control character https://unicode-explorer.com/b/0000
- confirm it
- try to print it
Issue:
Ugly Stack Trace
Cause:
XML does not accept such characters
```
The characters to be escaped are the control characters #x0 to #x1F and #x7F (most of which cannot appear in XML)
[...] XML processors must accept any character in the range specified for Char:
`Char ::= #x9 | #xA | #xD | [#x20-#xD7FF] | [#xE000-#xFFFD] | [#x10000-#x10FFFF]`
source:https://www.w3.org/TR/xml/
```
opw-3773808
closesodoo/odoo#163433
X-original-commit: d06a22991cd604e46d6392f6394b2b0e6a4ae673
Signed-off-by: William André (wan) <wan@odoo.com>
Steps to reproduce:
- create-aprove-post an expense
- Go to the accounting dashboard
Issue:
expenses' amount is 0
Cause:
In `_count_results_and_sum_amounts`, since the expense.currency is the same as the company we don't get the correct result:
https://github.com/odoo/odoo/blob/d29a622740f6c34d25c52add5367bfdf58bbaf49/addons/account/models/account_journal_dashboard.py#L641-L644
Solution:
Get the right columns.
We also change the domain to make sure that expenses partially paid are also displayed.
Note:
For the test we check that even partially paid expenses are displayed. In Master we want the residual amount to be displayed.
In master:
Use the amount_residual (discussed with po Laura)
opw-3849036
closesodoo/odoo#162182
Signed-off-by: John Laterre (jol) <jol@odoo.com>
Issue:
Discounts are not displayed in DDT
Steps to reproduce:
- create a quotation with a sale line having a discount
- smart button delivery > set qty > validate
- Print
opw-3745866
closesodoo/odoo#162287
X-original-commit: 957443d8a0f416997de9c99354c9d3ae2fb3dfbf
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Yolann Sabaux (yosa) <yosa@odoo.com>
Steps to reproduce:
- have two companies; Company A and Company B
- create a product Product A and set a different cost in each company
- create an invoice for Company A with Product A and post it
- Go in invocie analysis > pivot view and set the y-axis as 'move'
Issue:
The invoice will be taken twice
Issue:
for Product A, there are two ir_property lines (one per cost/company)
opw-3753395
closesodoo/odoo#157268
Signed-off-by: de Wouters de Bouchout Jean-Benoît (jbw) <jbw@odoo.com>
Steps to reproduce:
- Create an invoice and confirm it
- reset to draft
- change the account of an aml (product sales -> asset)
-> on the log note you will see the detail of the modification `Account: 400000 Product Sales -> 101000 Current Assets`
- connect with Demo
- go on the same invoice
Issue:
You will not see the details of the aml account change
This is problematic since Accountant and auditors should be able to see it.
Cause:
Sub-model tracking is not supported. Although we override this constraint in accounting (refer to https://github.com/odoo/odoo/blob/f56de22f10d09e6e34b25cbff04bbb6bf0823e54/addons/account/models/account_move.py#L5058-L5071), it remains inaccessible for users other than base.system. This is because we attempt to locate the account_id field on the model account.move defined in tracking.mail_message_id.
opw-3632295
closesodoo/odoo#155034
X-original-commit: 20f00a73cb280fd9a3636122c4a8a316abcee0d0
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Yolann Sabaux (yosa) <yosa@odoo.com>
Steps to reproduce:
[account, iap credit]
- create a new invoice
- start to write "test" for the partner
Issue:
The partner autocomplete is not displayed
Cause:
in #150106 we add a condition for the quickCreate bypassing the possibility of having createEdit set to true
opw-3698400
closesodoo/odoo#155781
X-original-commit: 5f342b816c16fbbaefdb61d8bfac8376132dbfeb
Signed-off-by: Louis Baudoux (lba) <lba@odoo.com>
Signed-off-by: Yolann Sabaux (yosa) <yosa@odoo.com>
Steps to reproduce:
- create an invoice with an invoice line having a big amount
- confirm
- print invoice
Issue:
The alignment of total is not correct
Solution:
In l10n_ar, we need more cols to be able to display the correct information. In the base report, the difference is not important visually (the line total is slightly longer)
opw-3670830
closesodoo/odoo#155670
X-original-commit: fca032c6cc2d6b7eb9f8c4bc71b7b259c4ce93ce
Signed-off-by: John Laterre (jol) <jol@odoo.com>
Signed-off-by: Yolann Sabaux (yosa) <yosa@odoo.com>
Steps to reproduce:
- activate analytic
- Create two assets with different analytic distribution
- Open the first asset
- Navigate to the second asset via the arrow
Issue:
The analytic account will not be displayed correctly
Cause:
In `jsonToData` the record used is the previous one.
Solution:
Use the record that will efectively be displayed
opw-3698383
closesodoo/odoo#153681
Signed-off-by: Habib Ayob (ayh) <ayh@odoo.com>
Steps to reproduce:
- open bom
- open product `Table`
- set the quantity of all subproduct to `0`
- Open overview
Issue:
the table top has 1 in qty
Cause:
For a bom subproduct, if there is no qty set (0/False), we automatically set the qty defined on the bom
opw-3677052
closesodoo/odoo#151141
X-original-commit: 4db4fe4466292ca2041bf04434ababfbc10cd9dd
Signed-off-by: Adrien Widart (awt) <awt@odoo.com>
Steps to reproduce:
[l10n_sa_edi]
- create a SA customer with phone number e.g.:`+971 56 777 7777`
- create an invoice
- Zatca Process it
Issue:
Error: "The Buyer’s contact phone number (BT-57) shall start with “0“ or “+”, followed by a maximum of 15 number and minimum 4 character after the “+“ or “0“ , if exist."
Solution:
For Saudi Arabia, it is not necessary to have the phone number.
For other locations, I assume that stripping the phone number could not harm the process.
opw-3666195
closesodoo/odoo#150495
X-original-commit: c8d93c7574f97ddd8924ed80031327db36c1c336
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
Signed-off-by: Yolann Sabaux (yosa) <yosa@odoo.com>
Steps to reproduce:
- In Settings/technical/actions/reports: find the invoice report
- in advanced: activate "Reload from attachment"
- create an invoice with a swiss customer
- confirm and print
- print the invoice again
Issue:
There are two pages with the same qr-code
opw-3626815
closesodoo/odoo#147281
X-original-commit: a6e06531cdd15736b6ed51702e6ba17fb73fe89d
Signed-off-by: de Wouters de Bouchout Jean-Benoît (jbw) <jbw@odoo.com>
Steps to reproduce:
- create a bill
- add a product line
- add a payment reference
- save it
- change the payment ref
- confirm
- register a payment
Issue:
The memo is not the updated payment reference
Cause:
The memo is computed by taking in priority the `line.name`
https://github.com/odoo/odoo/blob/a39050e15195eb095b3480899cedb5cb458fa6cc/addons/account/wizard/account_payment_register.py#L139-L145
And whenever we change the payment reference, the line.name is not recomputed if it has already been set
opw-3476835
closesodoo/odoo#144362
X-original-commit: 367754e760e41eee605176f1a712190a0cc388a1
Signed-off-by: Yolann Sabaux (yosa) <yosa@odoo.com>
Steps to reproduce:
- Enable the merge on account.account in data cleaning APP (in debug)
- Create an invoice with a receivable account = A
- Define a lock date after the invoice date
- Go to chart of accounts
- Select your receivable = A et receivable = B
- Action = Merge accounts where B is the MASTER
Issue:
Upon revisiting the customer invoice: Notice that the journal items have been updated.
Solution:
We simply prevent ~~the use of a nuclear weapon~~ the merge of `account.account` as there other possibilities less dangerous such as multi-edit + archiving
We also prevent the merge of `res.partner` if this one is used in hashed entries
oe:https://github.com/odoo/enterprise/pull/47053
opw-3389157
closesodoo/odoo#142937
X-original-commit: bc66f698e2c4edf2cedce4637dfb7aafaf119251
Related: odoo/enterprise#51170
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Yolann Sabaux (yosa) <yosa@odoo.com>
steps to reproduce:
- enable analytic
- open journal items in list view
- select one item, set an analytic account
- select the same item, click on the analytic account, click on the save button (floppy disk)
- pop up opens
- close it
Issue:
Traceback
Cause:
In multiEdit mode, the main element cannot be focused in
opw-3463911
closesodoo/odoo#136576
X-original-commit: 93e553c211e1b74c0e712e387290db6455cf0e3d
Signed-off-by: Habib Ayob (ayh) <ayh@odoo.com>
Steps to reproduce:
- Set "To Check" for a bill in the Bill list view
- go back to the dashboard
Issue:
There won't be the "To Check" shortcut as it was the case in 15.0
opw-3455414
closesodoo/odoo#134432
X-original-commit: d8498091bc6e2cd441f5e4387e3833d1a2a1abc0
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Yolann Sabaux (yosa) <yosa@odoo.com>
Steps to reproduce:
- set a tax lock date
- create a new move
- set the accounting date prior to the tax lock date
- set an invoice_line with a tax
Issue:
The banner teeling you information about the tax lock date won't appear unless the move is created.
opw-3370727
closesodoo/odoo#134388
X-original-commit: d67aa6a798d9f7359549bbf56ec6fa2913f930ec
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Yolann Sabaux (yosa) <yosa@odoo.com>
Steps to reproduce:
- install l10n_it_edi
- create a bill and set the move line with a tax "RC"
- confirm
-> the blue banner edi appears
- reset to draft
- change the tax to a non "RC" tax
- post the bill
Issue:
Despite resetting the bill to draft state and rectifying the tax configuration, the document could still undergo unintended processing as a Reverse Charge Bill.
Solution:
Reverse Charge bills, particularly those involving Intra-EU transactions, mandate that the VAT be paid by the buyer rather than the seller.
Italian EDI regulations necessitate the submission of such bills to the Tax Agency, specifying the buyer's tax obligations through a process known as tax-integration or self-invoicing.
In cases where an incorrect Reverse Charge tax is mistakenly applied to a domestic vendor bill, the existing issue becomes evident.
Even if the bill is Reset to Draft and the incorrect tax is removed, the associated edi_document will still be existing and will still have its "to_send" state. Consequently, the Scheduled action incorrectly attempts to send it.
This commit rectifies the problem by ensuring that when a bill is reset to draft state, the associated edi_document is promptly deleted.
The document will be recreated only during the posting process, should it genuinely require submission to the tax agency.
opw-3281007
closesodoo/odoo#132752
X-original-commit: f2c973a970af947a0e77a5e835237b09f11bdf7e
Related: odoo/enterprise#46112
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Signed-off-by: Yolann Sabaux (yosa) <yosa@odoo.com>
Steps to reproduce:
- Create two Bills with different payment terms with one having no "early_discount" such as '30% Now, Balance 60 Days'
- Select the Bills and click on Register Payment (make sure the payment is not grouped)
Issue:
Server Error
Cause:
We try to Register Payment for all the Bills at once, but the "early_discount" is not defined for all the Bills.
So, whenever there is a move with an early discount, the mode is always considered as "early_payment".
Therefore, we call `_get_invoice_counterpart_amls_for_early_payment_discount` with an empty list since there is no early discount
https://github.com/odoo/odoo/blob/0ffaaebfa5c25c4bf71fb0e02288767dbfac959d/addons/account/wizard/account_payment_register.py#L750-L755https://github.com/odoo/odoo/blob/0ffaaebfa5c25c4bf71fb0e02288767dbfac959d/addons/account/wizard/account_payment_register.py#L760
Causing the "local variable 'aml' referenced before assignment" error.
Solution:
We only iterate through moves belonging to the batch. This way, we avoid setting the mode to "early_payment" and entering the confition.
opw-3378445
closesodoo/odoo#132113
X-original-commit: 9bba9576d3365500a5c1eda0cfd57457fd999878
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Signed-off-by: Yolann Sabaux (yosa) <yosa@odoo.com>
Steps to reproduce:
- Install l10_ch
- create a journal entry with account 9991 or 9992
- go on the general p&l and compare it to the swiss p&l
Issue:
The results won't be the same
Cause:
The accounts 9991 and 9992 are not taken into account into the swiss expenses.
The `CH_4` only takes into account accounts with code `4 <= x < 5`.
https://github.com/odoo/enterprise/blob/bd43cba9e7b5bdbab6319ae1a90e8bf3a8960c15/l10n_ch_reports/data/account_financial_html_report_data.xml#L416
Therefore accounts 9991 and 9992 won't be take into account.
Solution:
When initialising the localisation, we change their code so they fit in the range of `CH_4`
opw-3210100
closesodoo/odoo#129238
X-original-commit: 0896fbb0957060c82bf0f08deef167f866e63cc0
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
Steps to reproduce:
- Install website_sale, contact, l10n_ch
- make sure your company is in Switzerland and has all the address information
- in settings, activate QR
- in Accounting/Journals/Bank:add a bank account (iban: CH4431999123000889012; qr-iban: CH11 3000 5228 1308 3501 F)
- install and enable the provider "Wire Transfer"
- From the Website, create an order and make sure the customer set an Invoicing address in Switzerland (address + Country)
- Validate the order
- In Website/unpaid orders: select your order and Confirm the order
- Create and confirm the invoice
- Print the invoice
Issue:
User Error is raised
Cause:
With Swiss QR code you need to have a valid payment reference. That is, an ISR reference such as in
https://github.com/odoo/odoo/blob/c6631df1c5b0b6d4c2268a826ca150edd0ca653e/addons/l10n_ch/models/account_invoice.py#L90
But when you create an order from the website, it creates an automatic reference "SO0001" which, when converted to an invoice, stays the same.
Since the reference is prepoluted, the `_compute_l10n_ch_isr_number` will not be triggered and therefore will raise an error when trying to print the invoice.
Solution:
Check if the Customer Invoice Journal uses the swiss reference model, then we know that the swiss loca is installed and can call the correct function to compute the reference/
Note:
In the test we check that `payment_custom` is installed. It is because the `_set_pending` method checks taht the payment_provider.code is "custom"="wire_transfer" in which case the sale order reference is computed
https://github.com/odoo/odoo/blob/b4ed9537895ecee48ed146add4257af0aebeb3f4/addons/sale/models/payment_transaction.py#L54-L56
opw-3334534
closesodoo/odoo#127338
X-original-commit: dfa4844e57b67d16b181e1e58813cdbbc7efa956
Signed-off-by: Yolann Sabaux (yosa) <yosa@odoo.com>
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
Co-authored-by: flvr-odoo <flvr@odoo.com>
Commit #2:
Splite the method `_compute_from_product_id_company_id` so each stored field has its own compute method to avoid invalidation issues.
opw-3336796
closesodoo/odoo#126529closesodoo/odoo#127794
X-original-commit: b64a378aab79ae4b6682ad66902c43a98a6f776d
Signed-off-by: William André (wan) <wan@odoo.com>
Steps to reproduce:
- install Expense and Accounting
- create 3 separate Expense categories ( this will create a related product of 'service' type) with a different Expense account and Vendor tax on it.
- Configuring different Taxes are important to replicate the issue
- Create a 'test' user who has no access to apps
- login a 'test' user and create an expense for one of the categories and save it.
- Update the expense to a different category and click 'submit to Manager'
Issue:
The account_id of the expense is not updated
Reason:
Multiple fields are computed using the same method `_compute_from_product_id_company_id`. The field being read-only=False
https://github.com/odoo/odoo/blob/c38cf4c2038d15890d5d50ec05fd5cb4f9f379b1/addons/hr_expense/views/hr_expense_views.xml#L199
It is protected during the write; that is, considered as user input
Solution:
Duplicate the field is it will not be read-only and put it as invisible
Split the compute method
opw-3336796
X-original-commit: 6664ccba5230d7890964cfe372ca863314f2fad4
Part-of: odoo/odoo#127794
Steps to reproduce:
- Install the lux localization
- Configure Peppol for a customer: Select a customer > tab accounting > under "electronic invoicing":
format: Peppol BIS Billing 3.0
Peppol e-address: 0130 - Directorates of the European Commission
Peppol Endpont: testendpoint
- Create an invoice for the peppol customer
- Add a section or a note in the Invoice
- Confirm the Invoice
Issue:
Raise user error: Odoo requires a tax for EACH LINE, instead of each product
Solution:
Exclude the section/note line
opw-3354757
closesodoo/odoo#126312
X-original-commit: fb716296dbdb4921d26ebe1c3a420965f07d61e4
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Steps to reproduce:
- create an invoice with a certain number of items so that when printed there are multiple pages
Issue:
- the invoice name does not appear on each page
According to the French legislation it is mandatory
See https://entreprendre.service-public.fr/vosdroits/F31808
Solution:
- set a config parameter specifically for l10n_fr in stable
- set it in account directly for Master
To allow the footer of the invoice to contain the name (and therefore the number) of the invoice
opw-3199906
closesodoo/odoo#124989
X-original-commit: 7b071c995f1c9587cf4de56d6d1a632ea39db8ac
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
Signed-off-by: Yolann Sabaux (yosa) <yosa@odoo.com>
This PR added a constraint https://github.com/odoo/odoo/pull/120892
This constraint should only be applied on `add_invoice_line` cash rounding strategy.
Initial opw-3185950
closesodoo/odoo#124289
X-original-commit: 02183ef878f8809032892338c41cc8816cab9669
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Yolann Sabaux (yosa) <yosa@odoo.com>
Steps to reproduce:
- install l10n_be (company B)
- stay on Company A and create a cash rounding
- Go to Company B and create an invoice
- In Other Infos > Cash Rouding Method, set it to the earlier created one
- Save
Issue:
You won't be able to save. But the message is too generic to know what is the cause of it
"Missing required account on accountable invoice line."
Cause:
The field `profit_account_id` is company_dependent. Therefore, the same cash rounding record will be accessible in both companies but in Company B the `profit_account_id` won't be set.
When Saving, we compute a cash difference (rounding) and try to create a new line for it. But since there is no account set, the sql constraint will be raised.
Solution:
The less dirty solution is to have an onchange that check that whenever we want to set a cash rounding method, it has all the required fields set
opw-3185950
closesodoo/odoo#123072
X-original-commit: e0df7cafefa3c2956105bd35c5bedc0c5bcdffaa
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Yolann Sabaux (yosa) <yosa@odoo.com>
Steps to reproduce:
- activate qr-code
- create a contact with a valid account and activate "send money"
- create a bill for this customer
- register the payment
- view the payment
Issue:
The QR-code is displayed as plain text
Cause:
The commit 688986f deleted the use of markup and the field qr_code is still as char and cannot be Markup'ed by the ORM
opw-3293289
closesodoo/odoo#122553
X-original-commit: 61a519aa5d62891fd8bda232ae09b48381786cf8
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
Steps to reproduce:
In an account move, if the partner_id is changed to one that does not have a value assigned in the property_purchase_currency_id field and with a value in the context for default_currency_id,
when passing through the _onchange_partner_id function of the purchase module,
Cause:
the variable currency_id will take the value in the context as second option causing an error when trying to get the value in currency_id.id because currency_id will be an integer and not a record.
issue-121232
note fw 16:
The record must be saved in order to trigger the compute in
https://github.com/odoo/odoo/blob/5a256af35e5d612efed9ed8af1cf23fd62bd83f4/addons/account/models/account_move_line.py#L449-L457
in order to recompute the currency of the lines
closesodoo/odoo#122075
X-original-commit: d0109dc5d7b0012ad1a4c45e5204934ae481779b
Signed-off-by: Yolann Sabaux (yosa) <yosa@odoo.com>
Steps to reproduce:
- create an expense product, re-invoice: "at cost"
- create a sale order with the product and set an analytic account
- create a purchase order with the expense product and the same analytic account
- create the bill
-> a new line on the SO is created with the same "Quantity Delivered" as the "Quantity Invoiced" for the purchase order
- for the bill, create a Credit Note of x unit
-> the purchase order has the Quantity Invoiced diminished of x
Issue:
- the Sale Order has not taken into account the new quantity after refund
- Since the line is an "analytic" one, the quantity delivered cannot be changed even if we wreate a credit note for the invoice
Solution:
During the processus of creation of new analytic lines, instead of creating new so lines we adapt the analytic line
closesodoo/odoo#120660
X-original-commit: 5258e2ce7d2df915eff02218636aa3272a7d9faf
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Yolann Sabaux (yosa) <yosa@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
Steps to reproduce:
- activate Purchase Receipt
- Create a Purchase Receipt
Issue:
- the edit tax total is not displayed as it is in Bill
opw-3253060
closesodoo/odoo#117980
X-original-commit: a7706ae581bcdb02fd72035ac67208cb4197a009
Signed-off-by: William André (wan) <wan@odoo.com>
Steps to reproduce:
- Activate Analytic Account
- Create a Service Product - create project on order
- Create a quotation with the product
- Confirm the quotation
- Go on the project -> analytic account is "order # - partner_name"
- On the quotation - Create Invoice
Issue 1:
- The invoice has "order #" has the analytic account and not the "order # - partner_name"
Issue 2:
- if you create an invoice and wants to select the analytic account
you cannot search it by the partner name, only by the "order #"
Cause:
When confirming the quotation, we create an analytic account. The
default name of the analytic account is the order name:
https://github.com/odoo/odoo/blob/bba5b6a440544151cc610bbc6848adfbadb38bfb/addons/sale/models/sale_order.py#L1416
Why is the analytic account displayed correctly on the project?
Because we use the `get_name` is triggered:
https://github.com/odoo/odoo/blob/bff34e0e8a8b2d211ef90ffea4f43c514e8cad28/addons/analytic/models/analytic_account.py#L115-L123
In the analytic distribution view, we only render the name of the
analytic account as it is defined primarly.
opw-3165655
closesodoo/odoo#117770
X-original-commit: b709a4491074169f6203ba98dec8847036262d6d
Signed-off-by: William André (wan) <wan@odoo.com>
Steps to reproduce:
- Install l10n_mx modules
- Switch to MX company
- Create invoice and confirm it
- Send it to PAC in test environment (Process Now button)
- Click Send & Print button
Issue:
- XML Preview does not display, only shows the file name in the top right corner of the chatter.
Cause:
In l10n_mx_edi, when posting the invoice, the only attachment available is the xml sent to the government in `_message_set_main_attachment_id`.
Therefore the xml is set as the main attachment.
When clicking on "Send and Print", the pdf is generated but the main attachment is still the xml
Solution:
Redefine the main attachment everytime the the main attachment is an xml
Note:
- octet-stream have also been filtered out
opw-3085934
closesodoo/odoo#116784
X-original-commit: 48e6e81a47f5371f5985d135e56f39f445eb2854
Related: odoo/enterprise#38861
Signed-off-by: Yolann Sabaux (yosa) <yosa@odoo.com>
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Steps to reproduce:
- In Journals/Bills/Advanced activate "Lock post entries with hash"
- Create a purchase tax of 17%
- Create a bill with a product of a cost of 30 and apply the "17%" tax
- Post it
- Export the data inalterability check report
Issue:
"Corrupted data"
Cause:
In python we have a reprentation issue
```
>>> 30*0.17
5.1000000000000005
```
We define the hash string during the `_compute_string_to_hash` at the
move creation. The issue is, at that time, the move_line tax debit
is not rounded.
Therefore, when we print the report, we take the `move.line_id.
debit` from the db which is rounded and equal to '5.10' and compare
it to '5.1000000000000005' which gives a different hash
Solution:
Implementing a V3 version that uses `repr` for monetary fields.
opw-3072693
closesodoo/odoo#114567
X-original-commit: cfd71892aabf1510273b28032ff8f2d4cfd4d1f7
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Yolann Sabaux (yosa) <yosa@odoo.com>
Steps to reproduce:
- Go to Contact-Configuration-Countries
- Remove the code of a country
- Create a new contact
- Select the country from which you deleted the code
- Put any vat number starting with country code you deleted
Issue:
Traceback
Cause:
in `_run_vat_test` we want to `country.code.lower()` -> country code does not exist
Solution:
Prevent the user to delete a country code by making the field required.
sentry-3923412146
closesodoo/odoo#113207
Signed-off-by: William André (wan) <wan@odoo.com>
Steps to reproduce:
- Create a new journal Bank
- In Sequence, find the 'New Bank Check" and edit it so the sequence can be 10 number digits long
- Create a Vendor Payments with the the New Banck and Check as a method
- Click on Print a check
- Set the check number to 2147483648 and validate
- Create a new payment with the check method
- Click on Print a check
Issue:
Error is raised
Cause:
As for https://github.com/odoo/odoo/pull/112832 there is a second check in order to increment the check number
opw-3140973
closesodoo/odoo#114496
X-original-commit: 531147bb5fad6372c3742bc061f78687f7f11e5b
Signed-off-by: John Laterre (jol) <jol@odoo.com>
Signed-off-by: Yolann Sabaux (yosa) <yosa@odoo.com>
Steps to reproduce:
- create two storable products (Great Product - Super Product) - automated avco
- create rfq with the two products - confirm -receive products
- create Bill - set qty of one Great Product to 0 -> save
- create bill for the Great Product - confirm
Issue:
User Error You can only reconcile posted entries
Cause:
`_get_all_related_aml()` fetches all aml related to the `stock_moves` with the product in the bill we want to post.
It retrieves the aml of the bill in which we have put the product quantity to 0 but that it is still in draft.
And we try to reconcile this draft move_line in
https://github.com/odoo/odoo/blob/d0fdc38385f5f259da259d21e9137494e6d7c17d/addons/account/models/account_move_line.py#L2308
Solution:
filter the `product_account_moves(_lines)` so we don't take into account moves that are still in draft
opw-3180209
closesodoo/odoo#114328
X-original-commit: b1a74a1841c05e4e37643e17f6b97dfff11555cd
Signed-off-by: Adrien Widart <awt@odoo.com>
Steps to reproduce:
- Make sure language preference is 'en_US'
- In accounting, in the dashboard click on bills
- Filter 'due_date' by week
Issue: The start day is Monday and should be, for 'en_US', Sunday as it
is the case in the dashboard view in accounting (see appendix).
Cause: The query uses the `date_trunc('week', date)` which in Postgres
retrieves the first day of the week as Monday (ISO week).
Solution: Create an offset in the query depending on the first day of
the locale variable.
Note: the `web/tests/test_read_progress_bar.py` has been modified: since
the default language is 'en_US' there will be an offset of one day. To
make it less confusing, I used only two anglo-saxons countries so the
day offset is not the variable tested. (for this matter, pleaser refer
to `test_read_group/tests/test_read_group_process_groupby.py`)
Appendix:
Language (english-US)
VIEW (per week) | DASHBOARD
___________________________________________________________________
W23 -> 06/05 | 05/29 -> 06/04
W24 06/06 -> 06/12 | 06/05 -> 06/11
W25 06/13 -> | 06/12 -> 06/18
(Monday - Sunday) (Sunday - Saturday)
Language (french-BE)
VIEW (per week) | DASHBOARD
___________________________________________________________________
W22 -> 06/05 | 05/30 -> 06/05
W23 06/06 -> 06/12 | 06/06 -> 06/12
W24 06/13 -> | 06/13 -> 06/19
(Monday - Sunday) (Monday - Sunday)
opw-2747066
closesodoo/odoo#93053
Related: odoo/enterprise#29539
Signed-off-by: Raphael Collet <rco@odoo.com>
Steps to reproduce:
- Create a new journal Bank
- In Sequence, find the 'New Bank Check" and edit it so the sequence can be 10 number digits long
- Create a Vendor Payments with the the New Banck and Check as a method
- Click on Print a check
- Set any number > 2147483647 and validate
Issue:
Traceback
Cause:
The query SQL make a check to verifiy that the number is correct ('025'::integer == '25'::integer but '025'!='25)
But using INTEGER limits the number up to 2147483647 (https://www.postgresql.org/docs/current/datatype-numeric.html)
Solution:
Use BIGINT whose limit is 9223372036854775807
opw-3140973
closesodoo/odoo#113499
X-original-commit: 49dd9dffd7b96fd90860123f8b3f0e623979b246
Signed-off-by: Yolann Sabaux (yosa) <yosa@odoo.com>
Signed-off-by: John Laterre (jol) <jol@odoo.com>
Steps to reproduce:
- Create a parent analytic plan with no analytic account
- Create a subplan for this analytic plan with no analytic account.
- Create a subplan for the above subplan and create an analytic account for this subplan.
- create an invoice and try to put the created analytic account
Issue:
The analytic account is not availble (nor the subplan, nor the root
plan are displayed)
Cause:
We only fetch root plans (plans without parent_id) that have an
analytic account set. In this cas, the root plan is not retrieved
since the account_id is defined on the sub-sub-sub plan and not on the subplan nor the direct child of the root plan.
Solution:
Fetch all plans that have account_ids set and append the root plan to the relevant plans
opw-3107652
closesodoo/odoo#112419
X-original-commit: d725c74336feb27bd02e0f05491b24cb51627374
Signed-off-by: William André (wan) <wan@odoo.com>
Steps to reproduce:
- have a Swiss configuration for qr-code
1) make sure your customer company is in Switzerland and has all the address information
2) make sure the customer set an Invoicing address in Switzerland (address + Country)
3) have set for your bank account in in Accounting/Journals/Bank: the Iban AND the QR iban
- create an invoice for a Swiss client
* monthly
* confirm
- Preview the invoice
Issue:
error, we should able to see the invoice without qr code.
Solution:
the user will still see the error when trying to print the invoice
opw-3104890
closesodoo/odoo#111929
X-original-commit: 30a8e933b3cda9c3c663c4d05d1efdc023b17b1e
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
Signed-off-by: Yolann Sabaux (yosa) <yosa@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>
Steps to reproduce
* Create an analytic plan with the domain as `invoice`
* Create an analytic account for the above plan
* Create an analytic distribution model and include condition as account prefix (4000), and product.
* Create a sale order, confirm and create an invoice
Issue
During the conversion from the Sale Order to the Invoice, the
analytic plan is not applied
Cause
The analytic distribution is set even where there is none. Therefore,
the compute is not trigger
opw-3109003
closesodoo/odoo#110202
X-original-commit: fd5249ea8687f24e7c9c2a2a3bcbb8cc14333efd
Signed-off-by: William André (wan) <wan@odoo.com>
Steps to reproduce:
- create a cash rounding
- create an invoice
- in Other Infos, select the created Cash Rounding Method
Issue:
Accounting wise, everything works fine but the back-end view and the Invoice Reports do not take into account the rounding
(except wen you create a partial payment, the amount due is correct of course)
Solution:
Make sure the value `formatted_amount_total_rounded` is returned by the method `_prepare_tax_totals` so it can be used in the templates
opw-3090556
closesodoo/odoo#109312
X-original-commit: 5724858a374c894bf787b4381bdcd466b4cc2816
Signed-off-by: William André (wan) <wan@odoo.com>
Steps to reproduce:
- Create a price list with different currency and discount with "show price and discount to the customer"
- On the website select this pricelist and try to select the booth
Issue:
The displayed price will not be the correct one
Note:
This is an issue discovered during the correction of https://github.com/odoo/odoo/pull/101375 (forward-port of https://github.com/odoo/odoo/pull/85640)
It allows to have the correct price depending of the currency of the pricelist applied.
Now the unlink of the rate makes the new rate directlt effective. There is no need of having a `new_company` anymore.
Summary:
- view modification in `website_event_booth_sale` -> price of selected booth, simplification of comparison for the `<del>`
- view modification in `website_event_sale` : simplification of comparison for the `<del>`
- backend test modification in `website_event_[booth_]sale` common: addapt the rate; take out useless `new_env`; simplified pricelists creation
- tour test addition: added the tour for essential use cases in event and event_booth; simplified the command so it is more readable
related ticket:
opw-2766997
closesodoo/odoo#106593closesodoo/odoo#107768
X-original-commit: 43c9d9892f593a41c7fe139dada0ce3f79f6f287
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Yolann Sabaux (yosa) <yosa@odoo.com>
Steps to reproduce:
- Create a price list with different currency and discount with "show price and discount to the customer"
- On the website select this pricelist and register for the event.
Issue:
The price in the cart is shown in the main currency
Solution:
[website_event_sale] There is an initial issue which when it calls '_compute_price_reduce'. We compare, 'product.lst_price' (in product.currency) and 'product.price' (which has been converted to the pricelist.currency).
In order to compare apples with apples, a conversion is applied to have the 'product.lst_price' in the same currency.
After that, we have kind of a coherent behaviour in the sense that 'ticket.price_reduce' is in the same currency as 'ticket.price'.
Thereafter, a conversion is applied (if the pricelist.currency is different) to get the expected amount.
The same reasoning is applied to [website_event_booth_sale].
Note: 'list_price' has been changed to 'lst_price' in Booth to have the same logic between Event and Booth
opw-2766997
X-original-commit: ced49554dd7cca73a1da440607d545bad64e7af0
Part-of: odoo/odoo#107768
Steps to reproduce:
(Activate Project, Timesheets, Sales, and Inventory)
- connect with portal
- open Projects
- try to open project "AGR - S00021 - Sales Order"
Issue:
Access Error
Cause:
We want to access to the field "is_gs1_nomenclature" for which Portal has no access.
Note:
On the main Runbot (all apps) it does work because the subcontractin_portal adds the Barcode Nomenclature access to Portal user
opw-3073064
closesodoo/odoo#106493
X-original-commit: e0fec5af209229546061c70509c834bb28dd1336
Signed-off-by: Adrien Widart <awt@odoo.com>
Signed-off-by: Yolann Sabaux (yosa) <yosa@odoo.com>
Steps to reproduce:
There is no possibility to reproduce it in test mode
But the flow would be:
- create a company with a NIF not registered
- Set up the EDI invoice
- Create an invoice
Issue:
When the NIF is not registered, is is possible to use it. It will only create an error `approbado con errores` which is apparently fine
Solution:
Whenever the server sent us an '1117' error code, we call again the post_invoice with a new context so we are able to send the request with the right information; that is, the correct ID Type whenever a NIF is not registered.
Indeed, whenever the error code is related to the NIF, is is possible to send again a request without having the invoice defined as "duplicated". It will only go through the process "AceptadoConErrores".
opw-2952108
closesodoo/odoo#104375
X-original-commit: 415d095cd418fd38d5749200724b6ce775ffa7f8
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Yolann Sabaux (yosa) <yosa@odoo.com>
Steps to reproduce:
- Activate Dropship and multi routes
- Create a SO and select the route Dropship
- Confirm the SO
- Confirm the purchase
- Click on Customer Preview
Issue:
In the customer preview, if the customer click on the do, vendor's info will be displayed.
opw-2961884
closesodoo/odoo#102020
X-original-commit: 672a3edce29bd1e16de64c4bcc8452842d3e16d4
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Yolann Sabaux (yosa) <yosa@odoo.com>
Steps to reproduce:
- have a project with a stage having the user_id set to Mitchell Admin (in this scenario you would have to add the field in the view)
- create a task in this stage
- log in with Marc Demo
- Try to open the project
Issue:
There will be an access error
Cause:
The domain allows to fetch all tasks from a project; even those from a prohibited stage
Solution:
- As in d4252825f5, we'll restrict the domain and "hide task stages if user is set".
- Prevent the user to create/modify a record to it with with a `user_id` and `project_ids`
opw-2917631
closesodoo/odoo#101965
X-original-commit: fdaef9276b89e2170128e205a4b7fd0b8defc2b1
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Signed-off-by: Xavier <xbo@odoo.com>
Steps to reproduce:
- in Barcode > Inventory Adjustment
In the quantities add a decimal numpad
Issue:
Traceback
Cause:
The field is from type=number. This kind of field does not accept methods such `selectionStart()` or `selectionEnd` which causes an error: https://html.spec.whatwg.org/multipage/input.html#do-not-apply
Solution:
When of type=number, just return.
On Chrome, numpad won't be possible for regions such as Portugese - BR. They would have to use the keyboard key `period`, code '.' in order to be able to put a decimal via the keyboard.
In Firefox, HTML is parsing the input correctly if the browser settings are set to the right localization. https://developer.mozilla.org/en-US/docs/Web/HTML/Element/Input#localization
opw-2956481
closesodoo/odoo#100953
X-original-commit: d95fbd80f63efbb47c9635e299f6ac417c5cb4c2
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Yolann Sabaux (yosa) <yosa@odoo.com>
Cookies should be used internally by the web UI. The server-side is not supposed to be aware of it at all.
Reverts:
odoo#88745
Based on odoo#93812
discussion. It has been decided to revert the fix to avoid further unattended behaviours.
closesodoo/odoo#100178
X-original-commit: bdde7dda7356744d459e3991a7f382fee42bf8c5
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Yolann Sabaux (yosa) <yosa@odoo.com>
Steps to reproduce:
- create two products
- create two analytic accounts
- create two new analytic rules by assigning an account to a product
- Create a new PO and select on of the product
- On the same line, change the product to the other one
Issue:
- The analytic account won't be updated
Cause:
Bypass of the `account_analytic_id` whenever there is already on defined
Solution:
For the `Sale` fix, I added the `line.state == 'draft'`.
The reason? Because the compute is triggered after confirmation of the order due to:
https://github.com/odoo/odoo/blob/14.0/addons/sale/models/sale.py#L931-L935
Therefore, the compute won't also be triggered after confirmation of the SO.
opw-2948950
closesodoo/odoo#99858
X-original-commit: 61604e18128c1cfd0e6d4e510852f780491d6e4e
Signed-off-by: William André (wan) <wan@odoo.com>
Steps to reproduce:
- create a contact with a phone number
- enable IAP-sms
- take off the number of the admin-contact
- create an event in the calendar with a "text-sms reminder" with the new created user
Issue:
No sms will be sent
Cause:
The IAP server-side does not accept request with `number` set to False such as in:
```{'messages': [{'res_id': 23, 'number': False, 'content': 'Event reminder: test-local, 07/11/2022 at (15:46:00 To 16:46:00) (Europe/Brussels)'}, {'res_id': 24, 'number': '+32487253270', 'content': 'Event reminder: test-local, 07/1>
Solution:
Filter partners with a valid phone number in `_sms_get_default_partner`
opw-2867763
closesodoo/odoo#99697
X-original-commit: 512010cfeb80fd6f5511888ddbd58dd26212105b
Signed-off-by: Yolann Sabaux (yosa) <yosa@odoo.com>
Signed-off-by: Arnaud Joset <arj@odoo.com>
Steps to reproduce:
- set a pricelist: discount, global, 10%
- set promotion program: free product
- In pos, select the product
Issue:
The product is deducted at its lst_price and not at the discounted price such as in `Sales`.
opw-2892748
closesodoo/odoo#96477
X-original-commit: ca933667e2b5e1633f08555b2852dcf30a4a11ab
Signed-off-by: Masereel Pierre <pim@odoo.com>
Signed-off-by: Yolann Sabaux (yosa) <yosa@odoo.com>
Steps to reproduce:
- Create a partner-individual, assign to a company
- Create an invoice and set the new partner as the customer
- Go to the partner view
- Delete it
Issue:
- It is possible to delete it
Cause:
The constraint in "account.move.line" uses the "commercial_partner_id" as the partner
Solution:
- Prevent the unlink if the partner is used in 'account.move' -> To delete in Master
- add "ondelete='restrict' for partner and commercial_parner in 'account.move'
opw-2858789
closesodoo/odoo#94591
X-original-commit: 7d37f5ef7ecd87aea666d96dc8200a74c8dc0b31
Signed-off-by: William André (wan) <wan@odoo.com>
Steps to reproduce:
- Define the decimal accuracy for the "Product Price" to 5
- Create a product with "cost = 0.00875"
- On-hand product = 10'000
- Change the cost to "0.00975"
Issue:
In Inventory valuation, for the product you will have two layers valued at:
- 87.5
- 12.5
Instead of:
- 87.5
- 10
Cause:
We round with currency precision
Solution:
Use the "Product Price" decimal precision as it is the case when we define a "standard_price"
https://github.com/odoo/odoo/blob/4c7ef5673b8fc28bf7fe2bc36fe2450987f15a28/addons/product/models/product.py#L110-L112
opw-2724975
closesodoo/odoo#93257
X-original-commit: deb26bb1182682a5071287ae313064801d080607
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Yolann Sabaux (yosa) <yosa@odoo.com>
Steps to reproduce:
just be sure you activate "packages" from the Inventory settings and you can find that button on a picking. Inventory dash > Operations > Transfers > Form view
Solution:
Add the hotkey
The choice has been made as following:
- not used in stock.picking
- used in other models
https://docs.google.com/spreadsheets/d/1QIPwUiEDv37H1P_FjN-WctzPey2Niu6K5dCL157Z8BY/edit#gid=0
opw-2858629
closesodoo/odoo#92838
X-original-commit: 73ab94402878a16c34c0e131818ffc0d2e8da3da
Signed-off-by: Adrien Widart <awt@odoo.com>
Signed-off-by: yosa-odoo <yosa@odoo.com>
Steps to repdroduce:
- In Reconciliation Models create a new rule
- Add two new lines with a "From Label" type and respectively set the "Amount" field to:
Koerperschaftst.{5,10}\s([\d\,\.]+)
Solid.Zuschl.KSt.{5,10}\s([\d\,\.]+)
- Change the "Decimal Separator" to a comma ","
- In Bank statement, create a new one with the following label:
Stnr 330/5707/3700 Koerperschaftst. 1.Vj.22 1.250,00 Solid.Zuschl.KSt 1.Vj.22 50,00 - FOLGELASTSCHRIFT
- Reoncile by using the button corresponding to the new rule
Issue:
-> "1.250,00" won't extracted contrarily to the "50,00"
Cause:
In: https://github.com/odoo/odoo/blob/affdd8d6276cb3c3aea9b994fa2427a6e97de691/addons/account/models/account_reconcile_model.py#L353
Our scenario: float("1.250.00") -> will throw an error
Solution:
Clean the match group to only keep the numebers and the decimal_separator
opw-2794209
closesodoo/odoo#92827
X-original-commit: d4da8be3669fbfdfdcad752af1f0311accaf34a3
Signed-off-by: William André (wan) <wan@odoo.com>
Steps to reproduce:
- In CRM seetings, activate Leads
- Create a sales team with "Pipeline" selected in Sales Teams Settings
- Set a form. The action is "create opportunity" and the Sales Team is the one you created
- Send a form
Issue:
A lead will be created. Not opportunity.
Solution:
Fetch the info related to the team
opw-2856520
closesodoo/odoo#92563
X-original-commit: 1e35d5a2f832901e1269c0f133eb846350f4ba0a
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: yosa-odoo <yosa@odoo.com>
Steps to reproduce:
- In Marketing Automation - Campaigns
- Select the demo campaign
- Click on "Launch a test"
- Select Brandon
- Send the two mails from the campaign
- Redo all the steps with a new Test but the same contact
Issue:
- The mails won't be sent
Cause:
- Since for this campaign we already sent these mails to Brandon, the mails will be considered as duplicate in:
https://github.com/odoo/odoo/blob/11b7d89114178fa43545fb8e6224cb4ccbcf8ec1/addons/mail/wizard/mail_compose_message.py#L499
Solution:
We want to make sure that:
- when doing a test, since there is only one linked partner to it, we can send as many mails as we launch tests.
-> repeated tests make sense as we want to fine tune campaigns and maybe get feedback from actual customers
- when launching the actual campaign, there are no duplicates (normal flow) but that eventual test-customers receive the final campaign
In order to do that, we have to filter out from the seen_list
https://github.com/odoo/odoo/blob/9b25a4b5a782146e8c0b41eb75ceea7ac3cd3abf/addons/mass_mailing/models/mailing.py#L736
the test-records.
opw-2810298
closesodoo/odoo#92062
X-original-commit: 4cebf53aa89c21ef255f5d5da450fdf98c4c9ac1
Related: odoo/enterprise#27660
Signed-off-by: yosa-odoo <yosa@odoo.com>
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Steps to reproduce:
- Have two companies set up
- In settings, check for company 2 the Files Centralization
- For a Product, upload a document
Issue:
The document will not appear in Documents.
It will only appear if the option is checked for company 1
Cause:
The company_id is not fetched correctly throughout the process.
There is a similar solution for the specific `documents` upload route:
https://github.com/odoo/enterprise/blob/bdf712d66c3e5cee70a6b424b69a618fe655a39f/documents/controllers/main.py#L147-L149
Solution:
Get the id directly from the cookies
opw-2774365
closesodoo/odoo#91751
X-original-commit: 46db92d5211c215d07448676e619154390b7147f
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: yosa-odoo <yosa@odoo.com>
Steps to reproduce:
- Create two extra warehouses (B and C):
* Warehouse B: Resupply from San Francisco
* Warehouse C: Resupply from San Francisco
- Create a new Product:
* Storable
* Inventory > Routes: select only Warehouse B and Warehouse C
- Create a new Move:
* From WHC to a Customer
* Confirm the order
Issue:
In replenishment, the defined prefered route will be Warehouse B
Cause:
When the replenishment view is loaded, in
https://github.com/odoo/odoo/blob/5757502a79c920e1aa4c7ca1c581c533907ce674/addons/stock/models/stock_orderpoint.py#L427
The preferred route (route_id) is defined as the first element of the routes defined for the produc which is wrong.
Solution:
Filter the route_ids by selecting the route for which the supplied warehouse is equal to the warehouse selected for the orderpoint.
Note:
1) The test in "test_bom" has been modified because it was using the wrong flow (a route should have been set by default)
2) In Master we only use the _set_default_route method
opw-2815462
closesodoo/odoo#90560
X-original-commit: 15b04d616a5196192a96e6bf2114698b34654348
Signed-off-by: Adrien Widart <awt@odoo.com>
Signed-off-by: yosa-odoo <yosa@odoo.com>
Steps to reproduce:
- Select any two storable product that has invoicing policy set on 'Delivery'
- Create a sales order lines with these two products and make sure that one of the lines should have a quantity set to 0
- Add shipping
Issue:
- The Invoice Status has changed to 'To Invoice'
Solution:
Add en extra filter to consider only lines that have not been invoiced.
opw-2750861
closesodoo/odoo#89548
X-original-commit: bfeb5f6317786edfd0fa464fe5798c7f7bc65ac9
Signed-off-by: yosa-odoo <yosa@odoo.com>
Steps to reproduce:
- define a home action for the user
- delete the action in configuration > Window Action
- refresh to the home page
-> id not found
Solution:
- prevent the deletion of a window action if used as a home action
OPW-2728824
closesodoo/odoo#89420
X-original-commit: b868583690d8560d3cc300b9448f0af32f41d81a
Signed-off-by: yosa-odoo <yosa@odoo.com>
Steps to reproduce:
- Go to time off - >New Time Off-> in the list you will see the all the times that are possible to take(that require allocation and not)
- Go to time off->My time off->create
- Select Sick Time Off
Issue:
If you want to select "Paid Time Off" it won't be displayed anymore
Cause:
When selecting a leave_type that does not require allocation the "default_date_from" is False. And so the get(key, default) does not return the default.
opw-2813263
closesodoo/odoo#89196
X-original-commit: ee6e6cb26528f42de9652b88fe022ebae2cfacfc
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Signed-off-by: yosa-odoo <yosa@odoo.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>
Steps to reproduce:
Decimal Accuracy - Product Price = 2
- create a product `alc 50%` with BOM (10 unites = 1 unit Water [cost=0.14]; 1 unit Alc [cost=0.08])
- Set `quantity on hands` = 10,000
- Trigger `Compute Price from BoM`
-> In Reporting > Inventory Valuation; click on the layer; in Other Info: You will see "Product value manually modified (from 0.0 to 0.022000000000000002)"
=> It can cause computing mistakes as we changed the costs
Cause:
The value is calculated as the difference between the New Price (cost) and and the current Product Standard Price (cost).
But, on one hand the Product Standard Price is rounded to the number of digits defined in the Decimal Accuracy for the Product Price.
On the other hand, the New Price is used as is with no rounding.
If we add an extra step and modify the cost of the Water to 0.45 and trigger again the `Compute Price from BoM` we will have:
"Product value manually modified (from 0.02 to 0.053000000000000005)"
Solution:
Use for the New Price the same rounding precision as we use for the Standard Price.
Example:
Product Price/unit
--------------------------
Water 0.14
Alc. 100% 0.08
BoM: Alc. 50%
Product Quantity Needed
--------------------------
Water 0.1
Alc. 100% 0.1
Cost/unit of Alc. 50%: 0.022 => 0.02 (standard_price is rounded)
Set Quantity on Hand: 10,000
Stock Valuation: 200 = 10,000 * 0.02
=> The standard_price is rounded to the second digit when intialized
Product Price/unit
--------------------------
Water 0.45
Alc. 100% 0.08
BoM: Alc. 50%
Product Quantity Needed
--------------------------
Water 0.1
Alc. 100% 0.1
Cost/unit of Alc. 50%: 0.053
Set Quantity on Hand: 10,000
Stock Valuation WITHOUT FIX: 530 = 200 (first layer) + 330 (second layer) = 0.02 * 10,000 + (0.053-0.02) * 10,000
Stock Valuation WITH FIX: 500 = 200 (first layer) + 300 (second layer) = 0.02 * 10,000 + (0.05-0.02) * 10,000
=> Without fix, the value is computed with the rounded standard_price and the not rounded new_price.
=> With fix, the new_price is rounded the same way as the standard_price
opw-2724975
closesodoo/odoo#88616
X-original-commit: 2d6f4213af7464c5fe737e2e9265454cf9711020
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: yosa-odoo <yosa@odoo.com>
Steps to reproduce:
- Create a new product as a storable
- Set quantity to 0
- Create a new internal transfer
Issue:
- The forecast button is in green which should not be the case
Solution:
For the internal transfers view, the green forecast button was invisible when "forecast are strictly less than 0". It should be "less than or equal to 0".
Inversely, the red forecast button should be invisible only when is "forecast are strictly greater than 0".
opw-2806764
closesodoo/odoo#88207
X-original-commit: a23108cba301a866504e2fc70aabdaf22c7ee0f8
Signed-off-by: Adrien Widart <awt@odoo.com>
Signed-off-by: yosa-odoo <yosa@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>
Steps to reproduce:
- Install accounting
- Create more than 6 analytical tags
- Create an invoice
- Create a payment
- Go in Accounting>Actions>Reconciliation, tab Manal Operations
- In the field Analytical Tag, click on 'Search More' and selected 1 or multiple tags
Issue:
Void tags are displayed
Solution:
Fetch the field `display_name`
ref commit: 84f0644802865c6454014059842eb6a9d4fd40e4
opw-2734029
closesodoo/odoo#87311
X-original-commit: 936bad32cf1024570da4880ccc5375b02b30c1c2
Related: odoo/enterprise#25631
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Steps to reproduce:
- create a contact with a very long name
- create a quotation
- in customer, type the first letter of the very long customer's name
- try to use the horizontal scroll bar
Issue:
close window on horizontal scroll
Solution:
Discriminate an horizontal scroll from a vertical scroll
A test has been added as well as the triggerScroll utility function
to allow proper tests when scrolling on elements
opw-2777443
closesodoo/odoo#86744
X-original-commit: e0b26496196bd4ee39fa06e1a3274982d2c7fb12
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Iucapad <luvi@odoo.com>
Steps to repoduce:
- Go to Sales - products
- Create a product
- Add variants (3 attributes and 2 values each) Total is 8 variants.
- onfigure variants: Select 1 attribute and exclude it for 1 variant (for example: exclude for size 12x12)
-> the number of variants remains at 8. The one that is excluded is still visible in the Product variants tab.
Solution:
When an exclusion is created, archive all the not-possible-combination.
OPW-2729329
closesodoo/odoo#84883
X-original-commit: 91642f4e29beb89d110084a20443fb300ee26530
Related: odoo/enterprise#24512
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Steps to reproduce:
- install only sale_project
- go to Project > Configuration > Projects
-> Warning in the JS console
Cause: sale_order_many2one widget is added by sale_expense which is not
a dependency of sale_project, so we should not use the widget in
sale_project.
OPW-2717655
closesodoo/odoo#83593
X-original-commit: d5f62067685503b6698d6b876a842512834027bf
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: yosa-odoo <yosa@odoo.com>
Steps to repdroduce:
- install Purchase - Accounting
- Create a new Purchase Order
- Add a product
- Add a section or a note
- in Actions select Accrued Expense Entry
-> traceback rounding error
OPW-2728854
closesodoo/odoo#83057
X-original-commit: 582be68bb5e4d441548a987fda3ff6450faa24ca
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: yosa-odoo <yosa@odoo.com>
steps to reproduce:
- install blog
- create more than 12 articles with at least on word (the one we will search for)
- Go to the "blog" menu of the website
- Go in the search field
- Search for the word in the created articles
-> Odoo removes the search criteria on the blog (Website) + number of results is inconsistent
OPW-2720355
closesodoo/odoo#83031
X-original-commit: bc2ed4a5f0997929930e3f279e5e1347818f8880
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Steps to reproduce:
- install accounting (account_accountant)
- go to invoice
- click on "send and print"
-> template is not loaded directly
Solution:
- revert changes of commit #fc5812c327daab4 since the onchange is now called only once
OPW-2732687
closesodoo/odoo#82805
X-original-commit: fa25a3b2b7cdafbce70e39a8a896924f015185a9
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: yosa-odoo <yosa@odoo.com>
Description of the issue/feature this PR addresses: in version 15,
sometimes Google and Microsoft calendar synchronizations break with error:
Create/update: a mandatory field is not set.
Delete: another model requires the record being deleted. If possible, archive it instead.
Model: Calendar Attendee Information (calendar.attendee), Field: Contact (partner_id)
This is happening, because when Odoo is syncing an event, it will match
attendee with res.partner, if no existing partner is found, a new one
will be created unless:
- the address matches an existing mail alias ([alias_name]@[mail.catchall.domain])
- the address is invalid (eg. in outlook the email address is sometimes
in the form /o=ExchangeLabs/ou=.../cn=Recipients/cn=...
In this case we should not try to add the attendee to the odoo event.
Current behavior before PR: Error when syncing that the customer can
only solve by removing the erroneous attendee or remove the event from
their calendar.
Desired behavior after PR is merged: if the partner cannot be created
we ignore it.
opw-2670002
opw-2683889
opw-2702661
opw-2704631
opw-2711907
opw-2720032
opw-2722028
closes#82109fixes#78678closesodoo/odoo#82667
X-original-commit: 1cd470c8922119d0da0b69ab7d4b4ff746533689
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: yosa-odoo <yosa@odoo.com>
Co-authored-by: andro19951 <andro19951@gmail.com>
Steps to reproduce:
- Go to Contacts
- type "управління" in the filter
- click on add to google spreadsheet
-> error
Solution:
- encode the domain in utf-8
OPW-2701434
closesodoo/odoo#82404
X-original-commit: 077e554703b6d8a71c81fbf6783228d04e77d96f
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: yosa-odoo <yosa@odoo.com>
Steps to reproduce:
- Install and launch sales
- In settings: activate price lists and discount; price list based on advanced rules
- Create a new price list; based on percentage (54%)*; applicable on all products; show discount
- Make sure the Public Price List has show discount activated
- Create a new quotation
- Select the Test pricelist
- Select a product (price 0.03 eur/$/other)*
- Change the price list to Public price list
- update the prices
- change the price list to Test price list
- update the prices
-> The Discount shown is not the one defined in the price list (66.67%)*
*(values for my example)
Solution:
Use the real price and not the a posteriori-rounded price for the computation of the discount in the `update_prices` method.
opw-2677884
closesodoo/odoo#81395
X-original-commit: 986dbc20952caae9d5a1b4b7ee34cfb994dea077
Signed-off-by: yosa-odoo <yosa@odoo.com>
yosa-odoo