You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When creating a new order in magento admin console for a product that includes custom options, the total product price is incorrectly calculated using the option price for the default store instead of the option price of the new order store.
The product total in the products list is correctly calculated using the correct option price for the order store, but the order totals (the subtotal specifically) is calculated using the product option price for the admin (default) store
Expected Behavior
I would expect the subtotal of the order to match the correct amount calculated using the order store for the option prices
Steps To Reproduce
In a multi-store magento installation
Create a product that has custom options with different FIXED prices in different websites/stores
In the admin console, create a new order in a specific store
Add the product created to the order and configure the product to add the option(s) with specific prices
The product list section shows the correct total for the product and option in the order store
However, the order subtotal in the totals section is calculated with the product price in the order store but the option price in the admin store
Environment
- OpenMage: 20.12.2
- php: 8.2
Anything else?
No response
The text was updated successfully, but these errors were encountered:
I have done some investigation on this issue and the problem is the following:
When the quote items are loaded as a collection, it assigns the products to the quote items, but for some reason magento is using the application store when loading the products into the quote items collection, instead of the quote store, loading the incorrect Product option prices and product option value prices (for multi select options)
This is the trace:
When working with the quote items, we use Mage_Sales_Model_Quote::getItemsCollection()
When we iterate the item collection, magento will load the items in the collection and will call Mage_Sales_Model_Resource_Quote_Item_Collection::_afterLoad() as with any other collection object
This method calls $this->_assignProducts() to load and assign the product to each quote item
This method loads a collection of products using the product IDs from the quote items and loads as well the product options for each product, specifically, in line 169, it prepares the product collection and calls Mage_Catalog_Model_Resource_Product_Collection::addOptionsToResult()
The problem is in this method, addOptionsToResult has hardcoded the current magento application store instead of using the store provided by the quote to the Mage_Catalog_Model_Resource_Product_Collection::setStoreId() method
The function should be using the store in the collection instance instead of the application store. In the frontend this is not an issue since the quote store is always the same as the application store, but this is not the case in admin, where the application store is the admin store (store ID = 0), and is different from the quote store. In this case the product options are loaded using the admin store and the incorrect price, title, etc.
Is there an existing issue for this?
Current Behavior
When creating a new order in magento admin console for a product that includes custom options, the total product price is incorrectly calculated using the option price for the default store instead of the option price of the new order store.
The product total in the products list is correctly calculated using the correct option price for the order store, but the order totals (the subtotal specifically) is calculated using the product option price for the admin (default) store
Expected Behavior
I would expect the subtotal of the order to match the correct amount calculated using the order store for the option prices
Steps To Reproduce
Environment
Anything else?
No response
The text was updated successfully, but these errors were encountered: