Updating Magento Inventory through Extension on simple and complex products - magento

I am updating the Stock on Hand Inventory Qty on a Magento store through an extension that I have developed, using the following code:
Mage::getModel("cataloginventory/stock_item")
->loadByProduct($pid)
->setQty($qty)
->save();
Now, from my testing, this works fine, however I am a little concerned if this is having any negative affects on the different types of product that can be created in Magento (such as simple and complex products).
Is the above the correct way to update the SOH, and do I need to handle Complex products any differently? My gut feeling is that I don't need to do anything differently with complex products as they all end up deriving from a Simple product which has its own Stock on Hand?
Any advice appreciated

As long as you only update simples you'll be fine like this. Indeed all other non-virtual product types derive their stock from the simples.
You might even want to add
$stockItem = Mage::getModel("cataloginventory/stock_item")
->loadByProduct($pid)
->setQty($qty);
if ($stockItem->getCanBackInStock() && $stockItem->getQty() > $stockItem->getMinQty()) {
$stockItem->setIsInStock(true)
->setStockStatusChangedAutomaticallyFlag(true);
}
$stockItem->save();
See Mage_CatalogInventory_Model_Stock::backItemQty() to see how Magento adds stock.

Related

Magento: how to get the price of a product with catalog rules applied

I'm developing a script (external to Magento, not a module) which aims to output a text list of all available products, their prices and some other attributes. However, catalog price rules don't seem to be applied to product prices. If I use any of the following:
$_product->getPrice()
$_product->getFinalPrice()
I get the normal price (without rules being applied).
If I use:
$_product->getSpecialPrice()
I get null unless the product actually has a special price inserted in the product itself (i.e. if special price is not related with catalog rules).
I also tried
Mage::getModel('catalogrule/rule')->calcProductPriceRule($product,$product->getPrice())
as suggested in the answer given by Fabian Blechschmidt, but interestingly it returns the normal price only if the product is affected by any catalog rule, returning null otherwise.
There was a similar question in StackOverflow and Magento Forums some time ago, but the provided answer (which is to insert the code bellow) doesn't work for me (returned prices remain the same).
Mage::app()->loadAreaPart(Mage_Core_Model_App_Area::AREA_FRONTEND,Mage_Core_Model_App_Area::PART_EVENTS);
Does anybody have an idea of how to achieve this?
I'm using Magento 1.6.2.0.
Thanks in advance.
Thanks to you, I found a new site:
http://www.catgento.com/magento-useful-functions-cheatsheet/
And they mentioned:
Mage::getModel('catalogrule/rule')->calcProductPriceRule($product,$product->getPrice())
HTH
As catalog price rules heavily depend on time, store and visiting customer, you need to set those parameters when you want to retrieve the product final price with it's price rules applied.
So, in your case, make sure that provided product is passed with the desired store and customer group id, which can be set as:
Mage::getModel('catalogrule/rule')->calcProductPriceRule($product->setStoreId('STORE_ID')->setCustomerGroupId('CUSTOMER_GROUP_ID'),$product->getPrice())
I discovered the problem. The discounted prices display Ok in the store frontend. The problem was that I was developing a script "external" to Magento (thus not a Magento module), something like:
<?php
set_time_limit(0);
ignore_user_abort();
error_reporting(E_ALL^E_NOTICE);
header("Content-Type: text/plain; charset=utf-8");
require_once "app/Mage.php";
// Get default store code
$default_store = Mage::app()->getStore();
...
For everything to work properly it seems that one must follow the proper Magento bootstrap, and develop everything as a module. My script was so simple that I thought it wouldn't be necessary to code a complete module. In other words, everything in Magento should really be a module.
Concluding, using the module approach, all the methods work as expected:
$_product->getPrice()
$_product->getFinalPrice()
$_product->getSpecialPrice()
Thank you all for your input.
This helped me in this issue: http://www.magentocommerce.com/boards/viewthread/176883/
. Jernej's solution seems plausible, but it does not handle rules that Overwrite other rules by using 'stop processing' and therefore can apply more than one rule.
$original_price = $_product->getPrice();
$store_id = 1; // Use the default store
$discounted_price = Mage::getResourceModel('catalogrule/rule')->getRulePrice(
Mage::app()->getLocale()->storeTimeStamp($store_id),
Mage::app()->getStore($store_id)->getWebsiteId(),
Mage::getSingleton('customer/session')->getCustomerGroupId(),
$_product->getId());
// if the product isn't discounted then default back to the original price
if ($discounted_price===false) {
$discounted_price=$original_price;
}

Magento product load - difference between loadByAttribute and load methods

today I'm fighting with Magento again :) and I found a difference between
$product = Mage::getModel('catalog/product')->loadByAttribute('sku', $product_sku);
and
$product = Mage::getModel('catalog/product')->load($product_id);
Can anyone exaplain me a difference between these two approaches? I found that when I'm loading a product by sku then when I 'try to re-save it with changed data then I get error exception 'Varien_Exception' with message 'Invalid method Varien_Object::save in app\code\core\Mage\CatalogInventory\Model\Observer.php(153): Varien_Object->__call('save', Array) that's true because once you try to load by sku then another observer sets product's stock item as Varien_Object, that looks like pitfall or I just dont understand it enough, but
I do daily Magento development from its beginnig so I know a lot about system and this is new for me. Thanks in advance, Jaro.
Interesting. While both methods will net you a single product model instance with fully loaded EAV data (provided the third parameter of loadByAttribute() is not passed or is *), the observers which add stock-related data are different for products vs. product collections, yet both stock information objects are added to the product data key "stock_item". It's debatable, but this feels like a bug. I would think that Mage_CatalogInventory_Model_Observer::saveInventoryData() or Mage_CatalogInventory_Model_Observer::_prepareItemForSave() would handle this.
You could resolve this issue by setting the product stock item fully on your product instance using the stock_item object.
loadByAttribute is a serious misnomer in my opinion because it doesn't actually trigger a load(); rather it uses getResourceCollection():
public function loadByAttribute($attribute, $value, $additionalAttributes = '*')
{
$collection = $this->getResourceCollection()
->addAttributeToSelect($additionalAttributes)
->addAttributeToFilter($attribute, $value)
->setPage(1,1);
Because it doesn't trigger the observer events associated with load() it means the resulting product object doesn't include the full set of product data you might want. In my case I needed the "description" attribute and it wasn't included.
There are several ways to resolve this:
Use a different method to load by SKU:
$product = Mage::getModel("catalog/product");
$product->load($product->getIdBySku("whatever"));
Force the desired attribute data to be included in the default product resource data by visiting Magento Admin > Catalog > Attributes > Edit attribute > "Used in Product Listing" = "Yes" and then reindexing. You should then be able to use the attribute data (in the frontend, at least) using loadByAttribute().
See also https://magento.stackexchange.com/a/197286/18855

Magento - Calculated Product Attribute (property)

I would like to add a calculated attribute (property) to Products. It's value is to be calculated using a PHP function eg:
function CalculateCustomAttribute() {
...
//Do some calculations based on other Product attributes, date, etc
...
return $calculatedValue; // type float
}
This calculated attribute needs to be:
displayed in the Product page,
filterable through the "Layered Navigation", and
sortable in the "Product Listing".
Could this be done? And how?
What you want to do might be possible, but I am not sure that the approach you have described would be doable, I think it is too simplistic to work with the very complex Magento platform.
I had a similar project where the actual price of the products was constantly changing based on a few inputs and I was able to solve the problem fairly well, but it was definitely more complicated thank what you seem to be hoping for. I am not sure this scenario is helpful to you or not, but here it goes...
The basic idea was that I created new product attributes (eav attributes). These served as the inputs to determine what the price really should be. Note that in my case, these attributes were being updated fairly regularly by an outside process.
Then I created an observer on the "catalog_product_save_before" event that would simply do something like this:
//some calculations to get the $newPrice
$product->setPrice($newPrice);
So basically that will make it so that the price field will always be current whenever you save a product in the administrative screens.
Then also, since several of the attributes that were used as inputs were constantly changing (updated by an outside process), so we also had to add a magento cron job to run every so often, and it would recalculate the price for all the affected products with something like this...
//some calculations to get the $newPrice
$product->addAttributeUpdate("price", $newPrice, Mage::app()->getStore()->getStoreId());
So it all boils down to the fact that you should have the attribute saved in the db. And of course you need to find the specific spots of where to update that derived attribute. Maybe your requirements will vary slightly from what I have described, but it might get you on the right path at least.

Fastest/best way to return attributes of associated products, of a configurable product, that are available to purchase

We're building a custom Ajax product search and are returning attribute options, from associated simple products for a configurable product, that are available to purchase.
In this case, the attribute is 'gender', so to illustrate, I'm trying to show, in the search, whether we have 'Guys, Girls, Kids' in stock, or just 'Guys'.
It's the EXACT same logic as product options on a product page, but it's global.
I have it working with this code:
$attributeOptions = false;
$jsonConfig = $this->getLayout()->createBlock('Mage_Catalog_Block_Product_View_Type_Configurable')->setProduct($_product)->getJsonConfig();
$jsonConfigDecode = Mage::helper('core')->jsonDecode($jsonConfig);
$genderAttributes = reset($jsonConfigDecode['attributes']);
$attributeOptions = $genderAttributes['options'];
But it's taking up to 1 second per product result so can't be used in our Ajax implementation, which may have dozens of results.
I'm wondering if there's a better/faster way. Perhaps, I'm bypassing flat catalog, which we're using by doing this?
Thanks for your help!
Wilson
Better way.
$product->getTypeInstance()->getConfigurableAttributesAsArray()

how to add more simple products into configurable products using magento API

How can I simply add new simple products incrementally to configurable products?
or do I still need to retrieve the 2 original arrays of the pre-defined configurable product (getConfigurableAttributesData and getConfigurableProductsData) first, append the new arrays and set them again? Is it worked for my case just as the first-time creation?
And if the new simple product owns a new attribute / attribute options, do I also need to create /edit the attribute first before adding?
Thanks in advance!
The API as it stands does not have the functionality to do this.
Your options are:
Extend the API. (Hours of fun)
Do it with Magento methods in your own module or standalone code that includes Mage.php.
SQL script mixed in with your existing API code.
Buy someone's module - (Hope your German is good)
The approach you take also depends on your SKU naming scheme, if you have a simple BASECODE-SIZE-COLOUR type of scheme then the SQL option can work a treat, and in next to no time, but will be heavily scorned on by Magento evangelists.
That means you are probably going to have to write your own code. Here is a very useful site that should help get you started:
http://www.ayasoftware.com/
As well as being able to import configurables (by a variety of means including SQL) there are also snippets of code useful for updating superattribute price differentials. No readymade complete solution, but, you may need to roll your own anyway depending on your SKU naming scheme.
Whilst you are at it you may also want to write some code to find simple products that are not hooked up to anything when they should be, i,e. the ones with no visibility.

Resources