Sunday, March 5, 2023
8 changes · master
Miscellaneous changes
Steps to reproduce: 1. Settings > Accounting > Vendor Payments > Checks > Enabled with Print Check (Top) - US 2. Accounting / Vendors / Payments 3. Create at least 2 vendor payments using "Checks" as the payment method 4. In the list view select both payments and click action/print checks 5. Error Bug: in `_render_qweb_pdf_prepare_streams`, in the case of multiple documents on multiple pages, we can only split them if the pdf has an outline, and it will have an outline only with tem
Original PR description
Steps to reproduce: 1. Settings > Accounting > Vendor Payments > Checks > Enabled with Print Check (Top) - US 2. Accounting / Vendors / Payments 3. Create at least 2 vendor payments using "Checks" as…
Steps to reproduce:
1. Settings > Accounting > Vendor Payments > Checks > Enabled with Print Check (Top) - US
2. Accounting / Vendors / Payments
3. Create at least 2 vendor payments using "Checks" as the payment method
4. In the list view select both payments and click action/print checks
5. Error
Bug:
in `_render_qweb_pdf_prepare_streams`, in the case of multiple documents on multiple pages, we can only split them if the pdf has an outline, and it will have an outline only with templates that have a header tag. For the ones that don't have them like
`l10n_us_check_printing.print_check_top`, it is not possible with the current logic to unambiguously split them. (maybe we can add a heuristic like if number of pages = number of documents we can assume 1 document/page)
thus the streams returned by `_render_qweb_pdf_prepare_streams` don't contain the record ids and
`safe_eval(report_sudo.attachment, {'object': record, 'time': time})` might fail based on the expression to evaluate.
Fix:
It doesn't make sense to save the attachment if we can't split the attachments clearly anyway, so we can just continue and skip the saving
if record is null
OPW-3124089
OPW-3164483
Forward-Port-Of: odoo/odoo#111511Expected singleton res.currency() trace back that occurs in account/account_move : _compute_tax_total was caught by sentry. Because currency is not available when we remove journal_id in account_move. Steps to reproduce the issue: - Install accounting module - Create a new invoice in Customer Invoices - Now select customer and remove the journal_id - Try to add a product . -In the above case (while adding a product trace back generated). In res.company currency_id is a required fiel
Original PR description
Expected singleton res.currency() trace back that occurs in account/account_move : _compute_tax_total was caught by sentry. Because currency is not available when we remove journal_id in account_move. Steps to reproduce the issue: - Install accounting module - Create a new invoice in Customer Invoices - Now select customer and remove the journal_id - Try to add a product . -In the above case (while adding a product trace back generated). In res.company currency_id is a required field. So we are accessing currency value from res.company.  Sentry-3946448424 I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#113815
## first commit Before this commit, when the user goes to project update of a project with many tasks and some tasks are linked to some miletones of that project the the `_compute_can_be_marked_as_done` could take more than 500ms depending on the tasks and miletones in the project (when the project update of that project is loaded). This commit fixes the performance by adding an index on `milestone_id` field in `project.task` model. ### Test case: The sql query made in that comput
Original PR description
## first commit Before this commit, when the user goes to project update of a project with many tasks and some tasks are linked to some miletones of that project the the…
## first commit Before this commit, when the user goes to project update of a project with many tasks and some tasks are linked to some miletones of that project the the `_compute_can_be_marked_as_done` could take more than 500ms depending on the tasks and miletones in the project (when the project update of that project is loaded). This commit fixes the performance by adding an index on `milestone_id` field in `project.task` model. ### Test case: The sql query made in that compute method took more than 600ms before that commit. With the index, the query takes less than 1ms. ## Second commit Before this commit, when the user wants to see the project.update of a project billable to see the project profitability, the project profitability could take more 20 seconds to be loaded because of a search on account.move.line to get the others revenues (that is, the invoices manually created without any SO linked) for which the AA of those invoices are the one of the project. The problem is the AA of a account.move.line is stored as key in a JSON field called `analytic_distribution` and so the fetch of related `account.move.line` could be slower when there are many records in the `account_move_line` table. This commit adds a new index on `account.move.line` to spped up the search in `analytic_distribution` field. By doing that, the project update is loaded in less than 2sec instead of 15-20sec. Co-authored-by: Yannick Tivisse <yti@odoo.com> Forward-Port-Of: odoo/odoo#111845
Currently, it is possible to resequence account moves which are hashed. This should not be the case. Therefore, we are adding the name of the move into the list of hashed fields. However, since we are changing the hashing algorithm by including a new field in its computation, we must add a versioning system to make sure we don't break the integrity (data inalterability) report. In practice, this means that prior to this commit, all hashed moves used the fields of v1, and moves after this c
Original PR description
Currently, it is possible to resequence account moves which are hashed. This should not be the case. Therefore, we are adding the name of the move into the list of hashed fields. However, since we are changing the hashing algorithm by including a new field in its computation, we must add a versioning system to make sure we don't break the integrity (data inalterability) report. In practice, this means that prior to this commit, all hashed moves used the fields of v1, and moves after this commit will use v2 (which adds the name into the list of hashed fields). Thus, whenever we generate the integrity report, we will run the v1 algorithm, and if it a potential corrupted move is found, we will switch to v2 and check again. If it also fails, this means the hash is indeed corrupted. task-id 3102481 Forward-Port-Of: odoo/odoo#113164 Forward-Port-Of: odoo/odoo#112320
The BuyerReference (BT-10) should be easily editable by the user, so it is read from the `commercial_partner_id.ref`. The OrderReference (BT-13) should also be editable by the user, it is read from the `move.ref`. The definition for both tags in the peppol doc defines these tags as: "An identifier assigned by the Buyer used for internal routing purposes". The new tag SalesOrderId (BT-14) is added, and is read from the `move.invoice_origin`. opw-3175906 Forward-Port-Of: odoo/odoo#114
Original PR description
The BuyerReference (BT-10) should be easily editable by the user, so it is read from the `commercial_partner_id.ref`. The OrderReference (BT-13) should also be editable by the user, it is read from the `move.ref`. The definition for both tags in the peppol doc defines these tags as: "An identifier assigned by the Buyer used for internal routing purposes". The new tag SalesOrderId (BT-14) is added, and is read from the `move.invoice_origin`. opw-3175906 Forward-Port-Of: odoo/odoo#114374 Forward-Port-Of: odoo/odoo#114291
1) Reimplement improvements made in saas-15.4 and lost during reportalypse. Namingly warnings with links to amls and partners when EC Sales tags are set on amls with: - partners with no valid vat - partners from same country as aml company - partners from non EC countries 2) Add warning on tax report that the user must file a EC Sales report if relevant Task : 3159976 Forward-Port-Of: odoo/enterprise#37282
Original PR description
1) Reimplement improvements made in saas-15.4 and lost during reportalypse.
Namingly warnings with links to amls and partners when EC Sales tags are set on amls with:
- partners with no valid vat
- partners from same country as aml company
- partners from non EC countries
2) Add warning on tax report that the user must file a EC Sales report if relevant
Task : 3159976
Forward-Port-Of: odoo/enterprise#37282This PR fixes/improves the Accounts Coverage Report in two ways: - we improve it by adding another check which verifies if an account is mentioned multiple times on the same line of the report (Task 3097719) - we fix/improve the trie regrouping feature which currently regroups errors with non-errors. This is problematic as we can see on the following two examples: 1. If we have the same error on the codes 4282, 4284, 4286 (used multiple times in the report) but no error on the code 4287
Original PR description
This PR fixes/improves the Accounts Coverage Report in two ways: - we improve it by adding another check which verifies if an account is mentioned multiple times on the same line of the report (Task 3097719) - we fix/improve the trie regrouping feature which currently regroups errors with non-errors. This is problematic as we can see on the following two examples: 1. If we have the same error on the codes 4282, 4284, 4286 (used multiple times in the report) but no error on the code 4287. These 3 codes will be regrouped under 428 even though 4287 is not flagged as an error. 2. If we have an error on the code 201 (code reported multiple times on the same line) but nowhere else in the up the trie (20, and 2), the reported account code with an error will be "2" and not "201" because of this regrouping. Forward-Port-Of: odoo/enterprise#35976
With a BE company Setup a EU partner with vat (i.e. Sweden SE810354746201) Create an invoice for the partner Go to Reporting>Ec Sales List Click on the partner>Audit Traceback Method partner_vat_listing_open_invoices is defined in model l10n_be.partner.vat.handler, while EC Sales List is handled by l10n_be.ec.sales.report.handler opw-3191820 Forward-Port-Of: odoo/enterprise#37691
Original PR description
With a BE company Setup a EU partner with vat (i.e. Sweden SE810354746201) Create an invoice for the partner Go to Reporting>Ec Sales List Click on the partner>Audit Traceback Method partner_vat_listing_open_invoices is defined in model l10n_be.partner.vat.handler, while EC Sales List is handled by l10n_be.ec.sales.report.handler opw-3191820 Forward-Port-Of: odoo/enterprise#37691