Friday, May 14, 2021
7 changes · master
Enhancements to existing features
Bank statement journal entries now open with a view tailored for bank and cash transactions. This removes less useful fields like due date, next activity, and payment status from that context, helping users focus on the information that matters for bank reconciliation and review.
Original PR description
Beforehand, when display the journal entries from a bank statement, some fields (Due Date, Next Activity, Payment status) that are not very relevant were displayed. Now, we use the bank & cash view to display the bank statement in a more relevant manner. task-2459562 https://www.odoo.com/web#id=2459562&action=333&active_id=967&model=project.task&view_type=form&cids=1&menu_id=4720 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Customer follow-up reports are now titled "Payment Reminder" in English instead of "Followup Report". This makes the document purpose clearer for customers and better reflects its purpose as a payment reminder.
Original PR description
Up until now, Followup reports that were sent to customers were titled "Followup Report". They are now titled "Payment Reminder" in english.
Miscellaneous changes
Create a draft payment with payment type and 0 amount. Save. The payment type will be overwritten opw-2495461 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#70603
Original PR description
Create a draft payment with payment type and 0 amount. Save. The payment type will be overwritten opw-2495461 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#70603
When using the boxed layout, if the business document has a table, its first row (after the table head) will have a bottom border and the last cell in the row has a white background. To reproduce the error: (Need timesheet_grid. Use demo data) 1. In Settings > General Settings, Change Document Template: - Select the second template 2. In Timesheets, select list view 3. Select several lines 4. Print > Timesheet Entries Error: In PDF, the first timesheet row has a bottom line and
Original PR description
When using the boxed layout, if the business document has a table, its
first row (after the table head) will have a bottom border and the last
cell in the row has a white background.
To reproduce the error:
(Need timesheet_grid. Use demo data)
1. In Settings > General Settings, Change Document Template:
- Select the second template
2. In Timesheets, select list view
3. Select several lines
4. Print > Timesheet Entries
Error: In PDF, the first timesheet row has a bottom line and its last
cell has a white background (instead of grey).
The bottom line should only be applied on row in table header. The
background color should also be applied on first row in table body.
OPW-2478311
Forward-Port-Of: odoo/odoo#70660When exporting the tax report's monthly xml with enterprise, the file wasn't accepted by the government in case 0% taxes were used. Grid 033 is optional, and can be used for custom tax rates. If specified, it MUST always go with grid 403 (giving the tax rate) and 042 (giving the tax amount). In Odoo, we made the choice to use it for 0% taxes, so 403 and 42 will always be present, and always 0. In community, grids number were missing on the lines' labels, and the codes (used to retrieve the
Original PR description
When exporting the tax report's monthly xml with enterprise, the file wasn't accepted by the government in case 0% taxes were used. Grid 033 is optional, and can be used for custom tax rates. If specified, it MUST always go with grid 403 (giving the tax rate) and 042 (giving the tax amount). In Odoo, we made the choice to use it for 0% taxes, so 403 and 42 will always be present, and always 0. In community, grids number were missing on the lines' labels, and the codes (used to retrieve the value of each grid when generating the XML) were not correct. Forward-Port-Of: odoo/odoo#70754 Forward-Port-Of: odoo/odoo#70744
When exporting the tax report's monthly xml with enterprise, the file wasn't accepted by the government in case 0% taxes were used. Grid 033 is optional, and can be used for custom tax rates. If specified, it MUST always go with grid 403 (giving the tax rate) and 042 (giving the tax amount). In Odoo, we made the choice to use it for 0% taxes, so 403 and 42 will always be present, and always 0. In enterprise, 403 grid needed to always be injected to the XML values, and grids 033, 042 and 04
Original PR description
When exporting the tax report's monthly xml with enterprise, the file wasn't accepted by the government in case 0% taxes were used. Grid 033 is optional, and can be used for custom tax rates. If specified, it MUST always go with grid 403 (giving the tax rate) and 042 (giving the tax amount). In Odoo, we made the choice to use it for 0% taxes, so 403 and 42 will always be present, and always 0. In enterprise, 403 grid needed to always be injected to the XML values, and grids 033, 042 and 0433 had to be made mandatory in the xml, so that they are not removed from it when amounting to 0. Forward-Port-Of: odoo/enterprise#18292 Forward-Port-Of: odoo/enterprise#18287
When adding a write-off move to reconcile an invoice, its value will always be the amount residual instead of the amount defined by the user. To reproduce the error: 1. Accounting > Configuration > Reconciliation Models, Create - Type: Manually [...] - Add one Counterpart Values: - Account: Bank Fees - Amount Type: Fixed - Journal: Miscellaneous Operations - Amount: 50 2. Create/Confirm an invoice INV of $1000 3. Create a payment P - Type
Original PR description
When adding a write-off move to reconcile an invoice, its value will always be the amount residual instead of the amount defined by the user. To reproduce the error: 1. Accounting > Configuration >…
When adding a write-off move to reconcile an invoice, its value will
always be the amount residual instead of the amount defined by the user.
To reproduce the error:
1. Accounting > Configuration > Reconciliation Models, Create
- Type: Manually [...]
- Add one Counterpart Values:
- Account: Bank Fees
- Amount Type: Fixed
- Journal: Miscellaneous Operations
- Amount: 50
2. Create/Confirm an invoice INV of $1000
3. Create a payment P
- Type: Receive Money
- Customer/Vendor: INV's customer
- Amount: $600
4. Confirm P, Payment Matching
5. Select INV, P and add Bank Fees (Manual Operations)
6. Reconcile
7. Open INV
Error: The amount due is 0, there are two payments: one of $600 (payment
P) and a second one of $400. The latter is incorrect and should be $50
(bank fees).
The issue comes from method `_prepare_writeoff_moves`, its parameter
`vals` contains the following information:
```python
{
'name': '1',
'balance': -50,
'analytic_tag_ids': [[6, None, []]],
'account_id': 29,
'journal_id': 3,
'reconcile_model_id': 3
}
```
However, the method does not check if `vals` already has a balance
value. Instead, it computes this balance by adding up the residual
amounts. This is where the incorrect amount ($400) comes from.
OPW-2485656
Forward-Port-Of: odoo/enterprise#18241