Sunday, November 13, 2022
2 changes · master
Miscellaneous changes
This commit is to compute correct lot number for serial/lot tracked products on refund invoices Reproduction: 1. Install Sale, Accounting, Inventor. In setting of Inventory, enable Lots & Serial Numbers, Display Lots & Serial Numbers on Invoices, Display Lots & Serial Numbers on Delivery Slips. 2. Create a product with lot/serial number 3. Create a order of this product, confirm. Click the delivery and validate it. 4. Back to the SO, create an invoice, confirm and print it, the serial
Original PR description
This commit is to compute correct lot number for serial/lot tracked products on refund invoices Reproduction: 1. Install Sale, Accounting, Inventor. In setting of Inventory, enable Lots & Serial…
This commit is to compute correct lot number for serial/lot tracked products on refund invoices Reproduction: 1. Install Sale, Accounting, Inventor. In setting of Inventory, enable Lots & Serial Numbers, Display Lots & Serial Numbers on Invoices, Display Lots & Serial Numbers on Delivery Slips. 2. Create a product with lot/serial number 3. Create a order of this product, confirm. Click the delivery and validate it. 4. Back to the SO, create an invoice, confirm and print it, the serial number shows. 5. At the invoice, click “Add credit note”, choose “Full refund” (2 invoices for the SO) or “Full refund and new draft invoice” (3 invoices for the SO), the lot number doesn’t show in new draft invoice or the refund invoice Reason: the current lot number tracking workflow focused on invoicing different numbers of products and making sure it gets the correct lot/serial number. It doesn’t include the refund invoice case. Fix: since the current working logic works great with invoicing products which are delivered from the warehouse to the customer, we can reuse this logic for refund invoices for products which are returned from the customer to the warehouse. In the refund and return case, we switch the calculation of warehouse and customer. Thus, a return can be seen as a delivery from the customer to the warehouse. In the code, we set a new variable, return_source_usage, to check if the account move type is a delivery or a return. If it’s an invoice for return, we take the opposite of the previous invoiced product quantity. Because in a refund, previous invoiced is now considered as refunded. In the original workflow, when sml.location_id.usage is “customer”, it’s a return and we update the returned_qty and the related quantities. In the new workflow, if the invoice is a refund one, we do the same steps when sml.location_id.usage is “internal”, e.g. when the stock move line is a delivery, we consider it a return. For refund invoices. There are two choices of refunding: 1. refund and a refunding invoice: 2 invoices for the order, one is the original one, another is the refund 2. refund and create a new draft invoice: 3 invoices for the order, original one, a new draft one and the refund. In the second case, we will create a new draft invoice. If we simply apply the original work logic, the lot number will not be printed on the draft invoice. This is because the previous amls list includes its original invoice. We have to filter out the duplication of the same invoice to print the right lot number for the new draft invoice. Added the report test for two refund cases, one for cancel (Full refund) and another for modify (Full refund and new draft invoice) opw-2879714 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#105282 Forward-Port-Of: odoo/odoo#99691
In V16.0 it is currently no longer possible to use the POS if the pos_six module is installed This bug is a combination of 3 factors 1. the new assets: a single file contains all the JS files, concatenated. 2. one of these files contains the instruction "use strict", which stiffens the code of the function in which this is mentioned, and which prevents certain syntactic approximations (like calling a variable without seeing it declared, this case) 3. We added Sha1, in its file of cours
Original PR description
In V16.0 it is currently no longer possible to use the POS if the pos_six module is installed This bug is a combination of 3 factors 1. the new assets: a single file contains all the JS files, concatenated. 2. one of these files contains the instruction "use strict", which stiffens the code of the function in which this is mentioned, and which prevents certain syntactic approximations (like calling a variable without seeing it declared, this case) 3. We added Sha1, in its file of course, but not in its own function, the use strict then applies to the entire asset file This reverts commit e08858e5ed02fe74160dabd6a91e1de88640956f. 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#104044