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.
I revisited this one and made it like the customer wanted, and its acutally a role back but for a purpose of fun or/ expansion of TC.
So at the moment on the Variant, I have a stock, sku and price. So that It works with stock on the variants.
On the product i also have the stock/sku/price, so that if they set up a product with no variants the stock on the "main product" will work.
So one scenario left, not working.
That is the one where the customer uses variants, without stock on variant level, but on product level instead.
--
To fix, there must be some point in the code, where you choose to deduct the stock of a product/variant. I was looking for it at github but thinks its in the compiled part of your codebase. My thought is, if there is no stock filled out on the variant, we could look upwards to deduct the master stock field.
So I would love to do this if i can somewhere, or do you find the idea absurt?
No, the idea is completely logical, I'm just tied by the previous implementation atm. As mentioned above, for some reason it is coded that if you are defining variants using the variants property editor, it seems to assume that the variants will always control the stock level.
I'll be honest, the variants side of things via the property editor is pretty new to me so I don't fully know it's ins and outs. Unfortunately, like you say, that code is part of the core so not open to PR's. The only thing I could say at this point is to add it as an issue to the TC for Umbraco repo and I'll look into what can be done.
Thinking about it, it could be possible, as a work around, to implement this from the front end. With the info provided previously, you could check whether the variant has it's own SKU / Stock level in your view and if it does, add the variant to the order and if it doesn't, add the parent product but with the variant details as order line properties. Not ideal, but it would allow it to work.
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.
Hey Matt
I revisited this one and made it like the customer wanted, and its acutally a role back but for a purpose of fun or/ expansion of TC.
So at the moment on the Variant, I have a stock, sku and price. So that It works with stock on the variants.
On the product i also have the stock/sku/price, so that if they set up a product with no variants the stock on the "main product" will work.
So one scenario left, not working.
That is the one where the customer uses variants, without stock on variant level, but on product level instead.
--
To fix, there must be some point in the code, where you choose to deduct the stock of a product/variant. I was looking for it at github but thinks its in the compiled part of your codebase. My thought is, if there is no stock filled out on the variant, we could look upwards to deduct the master stock field.
So I would love to do this if i can somewhere, or do you find the idea absurt?
Hey Rasmus,
No, the idea is completely logical, I'm just tied by the previous implementation atm. As mentioned above, for some reason it is coded that if you are defining variants using the variants property editor, it seems to assume that the variants will always control the stock level.
I'll be honest, the variants side of things via the property editor is pretty new to me so I don't fully know it's ins and outs. Unfortunately, like you say, that code is part of the core so not open to PR's. The only thing I could say at this point is to add it as an issue to the TC for Umbraco repo and I'll look into what can be done.
Thinking about it, it could be possible, as a work around, to implement this from the front end. With the info provided previously, you could check whether the variant has it's own SKU / Stock level in your view and if it does, add the variant to the order and if it doesn't, add the parent product but with the variant details as order line properties. Not ideal, but it would allow it to work.
is working on a reply...