Ive been googling around for an answer about how the stock datatype works with variants.
Because we have a customer where they only have a stock field on the "product" but not on each variant. But the stock didnt tick down, on purchases.
On the variant we have a "sku" and a "name", but I could on the specific variant they hadnt given a SKU, so im guessing that was why, since stock is stored on sku level.
I just got a bit confused, and couldnt find any doc :)
Bonus question the alias "sku" is something that is "hardcoded" like "umbracoNaviHide" and is not something we should set somewhere right?
Yea, I think because you give the variants their own unique SKU the logic that sets the stock level uses that SKU to update with and because you don't have variant stock levels, it's not changing anything.
In answer to your second question, yea, "sku" is a fixed alias so can't be changed, but, in this example, I'm wondering if we can use that to our advantage and you give your variants a "variantSku" property instead, which means TC won't attempt to use that as true SKU and attempt to set the stock level. It might then mean that it will use the stock level of the main product (I'm not really sure, but worth trying). You could then set variantSku as a property that gets copied to the order line so you can still show it in receipts etc.
I just tested this, by changing the sku property on the variant to an variantSku alias. But this dosnt change the stock on the "product" level. So im gussing that its not working the way i thought.
Dont know if its changed or something since v3.2.4.
I don't have thorough knowledge of how all the variants stuff works so I'll have to dig through it. I would have thought that would do it, but I'll have to set something up and see if I can replicate / suggest a solution.
Ok, I've done a bit of digging and can see why there is a problem (thought I still need to figure out how to fix it).
Ultimately, when you save an order that has variants, it seems to be pretty much assuming that you will have variant stock levels. When you save the order, and it calls to update the stock level, it builds an SKU to update the stock on by combining the product SKU + variant ID. The problem is, if you don't supply a variant SKU, it still generates an ID so it ends up trying to update the stock on an SKU that doesn't exist.
I'm gonna have to figure this out, but ultimately, when saving the product, it really needs a better way of knowing if the variant has independent stock levels (other than the current check, which is, is the variant null).
I'll see what I can figure out and let you know. I just wanted to give you an update.
If you aren't using variants with their own SKU, then you need to make sure you send the productIndentifier of the parent product for the order lines productIdentifier property.
Essentially at this point your variants are no longer really variants, the values have just been copied to the order line, but I don't think this really matters if your don't need stock control.
Do we need a stock level on each variant or will it inherit from product?
Hey
Ive been googling around for an answer about how the stock datatype works with variants.
Because we have a customer where they only have a stock field on the "product" but not on each variant. But the stock didnt tick down, on purchases.
On the variant we have a "sku" and a "name", but I could on the specific variant they hadnt given a SKU, so im guessing that was why, since stock is stored on sku level.
I just got a bit confused, and couldnt find any doc :)
Bonus question the alias "sku" is something that is "hardcoded" like "umbracoNaviHide" and is not something we should set somewhere right?
Hi Rasmus,
Yea, I think because you give the variants their own unique SKU the logic that sets the stock level uses that SKU to update with and because you don't have variant stock levels, it's not changing anything.
In answer to your second question, yea, "sku" is a fixed alias so can't be changed, but, in this example, I'm wondering if we can use that to our advantage and you give your variants a "variantSku" property instead, which means TC won't attempt to use that as true SKU and attempt to set the stock level. It might then mean that it will use the stock level of the main product (I'm not really sure, but worth trying). You could then set variantSku as a property that gets copied to the order line so you can still show it in receipts etc.
I will give it a test and get back!
I just tested this, by changing the sku property on the variant to an variantSku alias. But this dosnt change the stock on the "product" level. So im gussing that its not working the way i thought.
Dont know if its changed or something since v3.2.4.
Hmm, I'll need to dig into it further.
I don't have thorough knowledge of how all the variants stuff works so I'll have to dig through it. I would have thought that would do it, but I'll have to set something up and see if I can replicate / suggest a solution.
Ok, I've done a bit of digging and can see why there is a problem (thought I still need to figure out how to fix it).
Ultimately, when you save an order that has variants, it seems to be pretty much assuming that you will have variant stock levels. When you save the order, and it calls to update the stock level, it builds an SKU to update the stock on by combining the product SKU + variant ID. The problem is, if you don't supply a variant SKU, it still generates an ID so it ends up trying to update the stock on an SKU that doesn't exist.
I'm gonna have to figure this out, but ultimately, when saving the product, it really needs a better way of knowing if the variant has independent stock levels (other than the current check, which is, is the variant null).
I'll see what I can figure out and let you know. I just wanted to give you an update.
Ok, I think I know what you need to do.
If you aren't using variants with their own SKU, then you need to make sure you send the
productIndentifierof the parent product for the order lines productIdentifier property.For all the variant properties that you need recorded on the order, you'd then want to copy them to the orderlines properties collection.
Essentially at this point your variants are no longer really variants, the values have just been copied to the order line, but I don't think this really matters if your don't need stock control.
Hopefully this helps.
Matt
Hey Matt
Awesome, i will take it for a spin and see if i can make it work.
is working on a reply...