If some orders have no taxes (e.g. manual reimbursement with a negative amount)
the sum of taxes lines gave a different result than the total amount sold.
e.g.:
order 1: price 10€, including 2€ for taxes
order 2: price -5€, no taxes
report:
taxes:
20%, 2€ taxes, 8€ base amount
total sold:
5€
2+8 != 5
Also change line.price_subtotal as it was computed twice if there was two taxes
on a line (although it will probably never happen in the pos)
opw-805415
In the case where:
create an invoice with payment terms that contains at least 2 term lines
Validate
create a refund by clicking cancel and reconcile
Before this commit, the refund move lines were wrongly created and reconciled with the invoice's move lines
After this commit, since payment terms are irrelevant on refunds, we set it to false and the problem doesn't raise
OPW 804752
The case: create an invoice of 2000 euros. Payment terms have been configured as:
1) fixed amount 150, 0 days after invoice date.
2) fixed amount 200, 10 days after invoice date.
3) fixed amount 200, 20 days after invoice date.
4) balance, 30 days after invoice date
Before this commit, when issuing a payment of 150 at day 0, that payment got reconciled with the balance line.
After this commit, the payment is reconciled with the right payment term line
OPW 805006
Take as example:
having demo user as expense manager
create with demo user an expense sheet for the employee linked to admin
on save, there was an access rights error for the write on mail_followers
After this commit, there isn't the error anymore,
since the computation of the field related is done with sudo
OPW 804740
On the payment confirmation page, when the payment is still pending.
Before this commit:
the user friendly message disappeared and a warning icon took its place
After this commit, the warning icon is prepended to the message.
OPW 787799
Step to reproduce:
- Go to 'Blog' > 'Blog Posts' in the 'Website Admin' module
- Select several blog.post on the list view
- Click on 'Archive' in the 'Action' dropdown
This will throw a server error since write() is overriden for blog.post and
do an ensure_one()
This commit closes#22208
- Set the OS to a GMT- timezone (e.g. 'America/Los Angeles')
- Set the format of the date to '%d/%m/%Y'
- Go to 'Account > Adviser > Journal Entries'
- Type '02-01-2018'
The suggested date is 31/01/2018.
Setting the moment object as UTC will lead to a conversion of the date
to the OS timezone when calling `toDate`, e.g.:
Mon Jan 31 2018 16:00:00 GMT-0800 (PST)
UTC should only be used in case of datetime, not date.
opw-803466
In any piece of code, execute the following:
```
self.env['account.config.settings'].create({})
```
It overwrites the values of `fiscalyear_last_day` and
`fiscalyear_last_month` to 31 and 12.
Setting a default value on a related field will automatically write
these values on the related.
opw-805205
In the case where:
1- Do an order on the pos selling a product A (amount = 10)
2- Do another order returning a certain quantity of A (with a quantity < 0)
3- Do a third order selling something else (amount = 5)
Before this commit, the account move lines of the payment move and of the sale move of operation 2 weren't reconciled
This was because the credit to the receivable account of the return was reconciled with the debit of the first operation,
leaving the debit of the payment of the return alone
(i. e. the lines number 1 & 3 & 5 were reconciled together, instead of 1 & 2 & 5, and 3 & 4)
We end up in a situation like this (at validation time)
RECEIVABLE
D | C || OPERATION | Line Number
----------------------------------------------------------------------------
15 | || (1 & 3-Engaging Sale) | 1
| 10 || (1-Payment) | 2
| 10 || (2-Engaging Return) | 3
10 | || (2-Payment Return) | 4
| 5 || (3-Payment) | 5
After this commit, we reconcile the returns for each order before reconciling other transaction chains
The fix is limited in its scope as the automatic reconciliation for the pos transaction is fairly recent
and a "nice to have"
OPW 787298
Depending on the location, on the website different timezone were used
to display tracks:
- in `Agenda` day date (as of saas-14): the current user timezone
- in `Agenda` track times: the event timezone
- in `Talks` subtitle: the event timezone
- in `Talks` tracks: the current user timezone
- in a track page: the first user (admin) timezone
With this change in all those instance the event timezone is used.
There is still a usability hindrance in the backend: the timezone used
when encoding track or event datetime is the browser timezone.
So if the browser is GMT+2 and the event is GMT+6, encoding a 4h00 time
would save it as 2h00 (in UTC) and display it on the website as 8h00.
This would make sense to encode these datetime in user timezone but
currently there is no framework option to do it.
opw-805358
closes#22427
Changing the `deleteContents` method of the editor is tricky. This
commit however dares to add a behavior: if the range does not
represent a selection but only the cursor position and is then asked
to delete its content... it should not do anything as nothing is
selected.
Before this commit, users had only access to messages if they were
recipients. However, you can still be notified for messages your are not
a recipient; leaving you with notifications (needaction) on unreachable
message.
This commit display only 'Invoicing' if cart have only service.
Set website_sale_order variable to get right context of order.
This commit closes 22259
In multi company, when a user 1 creates a purchase invoice I in company A.
The responsible of the invpoice I is user 1. But if the user 1 changes his company from
company A to company B. Then it raised an access error when a user 2 in company A
tries to duplicate the invoice I because the responsible is in an other company.
Now the responsible is not duplicated to avoid access error.
opw:805573
Issue: when the qWeb compress rendered HTML for a better Google PageSpeed
result, some text fields are missing spacebar between fa icons and text,
and between some fields.
The function action_payslip_done has been overwritten in module hr_payroll_account.
Due to this overwrite, the function compute_sheet which creates the payslip lines
was called after the creation of the entries.
Then creating a refund payslip didn't create any entries.
opw:785033
Martin Trigaux