Sunday, February 23, 2025
2 changes · 18.0
Miscellaneous changes
Description of the issue/feature this PR addresses: Currently, when an order is generated in the POS system and the payment method is set to pos_online_payment, after displaying the popup with the QR code, if the popup is closed, and then a customer (partner_id) is selected, reopening the popup does not update the customer information on the order. This means that the customer (partner_id) is not synchronized correctly on the backend of Odoo, leading to the order not reflecting the updated cust
Original PR description
Description of the issue/feature this PR addresses: Currently, when an order is generated in the POS system and the payment method is set to pos_online_payment, after displaying the popup with the QR…
Description of the issue/feature this PR addresses: Currently, when an order is generated in the POS system and the payment method is set to pos_online_payment, after displaying the popup with the QR code, if the popup is closed, and then a customer (partner_id) is selected, reopening the popup does not update the customer information on the order. This means that the customer (partner_id) is not synchronized correctly on the backend of Odoo, leading to the order not reflecting the updated customer selection. Current behavior before PR: When the popup with the QR code is closed, and a customer is selected afterward, the partner_id (customer) is not updated on the order. The order does not reflect the latest customer selection on the backend. Desired behavior after PR is merged: When the customer (partner_id) is selected after the popup is closed and reopened, the order will be updated with the correct customer information. The system will ensure that the partner_id is synchronized in real-time with the backend, so the customer is correctly assigned to the order. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Before this commit, the invoice cancelled with payment state set to "Invoicing App Legacy" is actually not really cancelled, it seems to just be a way to create accounting entry. However, the timesheets are considered as not billed if there is no invoice linked to them or if the invoice is cancelled (that is, if the state is set to "Cancelled"), which means, if the invoice is in "legacy status", the timesheets could move in a new invoice since those ones are considered as not billed. This com
Original PR description
Before this commit, the invoice cancelled with payment state set to "Invoicing App Legacy" is actually not really cancelled, it seems to just be a way to create accounting entry. However, the…
Before this commit, the invoice cancelled with payment state set to "Invoicing App Legacy" is actually not really cancelled, it seems to just be a way to create accounting entry. However, the timesheets are considered as not billed if there is no invoice linked to them or if the invoice is cancelled (that is, if the state is set to "Cancelled"), which means, if the invoice is in "legacy status", the timesheets could move in a new invoice since those ones are considered as not billed. This commit adds a condition to determine to know if a timesheet is not billed. The timesheet should now be: - not linked to an invoice - or the invoice linked should be cancelled and payment status should not be "Invoicing App Legacy". Steps to reproduce the issue: ---------------------------- 1. install Accounting, Sales and Timesheets app 2. Create a SO with a service product and confirm the SO 3. Create a timesheet for the SOL contained the service product 4. Create a invoice to partially invoice the service made for the SO. 5. Go to "Accounting app > Settings" 6. Enable the "Invoicing Switch Threshold" feature and make sure the date set on that feature is most recent than the one set on the invoice created in step 4. By doing that, the invoice created in step 4 should now be cancelled but with payment status set to "Invoicing App Legacy". 7. Create another timesheet for the same SOL 8. Go back to the SO created in step 2 and create another invoice to invoice the another timesheet. Current behavior: ---------------- The timesheet linked to the first invoice is now linked to the second one with the other timesheet. Expected behavior: ------------------ Since the first invoice is not really cancelled, the timesheet should still be linked to the invoice and so that timesheet should be considered as billed. opw-4556956 Forward-Port-Of: odoo/odoo#198669 Forward-Port-Of: odoo/odoo#198277