Wednesday, September 25, 2024
3 changes · saas-17.2
Resolved issues and error corrections
This fix ensures dropshipped goods between related companies are sent through the proper inter-company transit location. It helps keep deliveries, inventory movements, and lot or serial number tracking correctly linked when one company sells goods supplied or shipped by another.
Original PR description
Fixes two uses cases: - Sale Order in Company A that dropships goods *stored* in Company B to the Customer. - Sale Order in Company A that dropships goods from company B to the Customer. But in company B, we also dropship from the vendor to the customer. In both cases, make sure to properly send goods to the Inter-Company Transit location for inter-co transactions, so that goods (and lot/serials) can be properly linked. opw-4163612
Intercompany sales and dropship orders now route goods through the Inter-Company Transit location as intended, instead of incorrectly treating the end customer as the internal destination. This helps companies avoid inventory routing errors and keeps cross-company deliveries aligned with the expected business flow.
Original PR description
Since #156437, the moves can have a final location representing their final endpoint. This causes some issues for inter-company transactions, as they are meant to deliver to/pick from the 'Inter-Company Transit' location. This means that for sale orders meant to other companies, they are always supposed to deliver their goods there: - Normal delivery: CompA/Stock -> ICT, ICT -> CompB/Stock - Dropship: CompA/Stock -> ICT, ICT -> Customer But this opens a few issues, as the compA SO's `partner_shipping_id` is the customer itself, meaning that the final location would end up as Customers, which we want to avoid. Also, to accomodate both these cases, we need to add a bit complexity computation of the location_dest of a move. We consider that if the location_dest is Customers but its final is ICT, then we apply the ICT. opw-4163612 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes a Point of Sale issue where product information could fail to open after refreshing a session that uses employee login. The system now reads the cashier role from the correct place, preventing an error for users with administrator PoS access.
Original PR description
Problem: The `role` attribute is being retrieved from the `raw` field, but when the page is refreshed, all attributes (including `role`) are set in the `cashier` object, not in `raw`. Steps to reproduce: - Set up a PoS session with the "Log in with Employees" setting enabled. - Use a User/Employee with Administrator PoS access (e.g., Mitchell Admin). - Start a PoS session. - Refresh the page. - Click the "i" icon to see more information about a product. - A traceback occurs. opw-4120414 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr