Copied to clipboard

Flag this post as spam?

This post will be reported to the moderators as potential spam to be looked at


  • Rasmus Fjord 640 posts 1518 karma points c-trib
    Feb 01, 2019 @ 08:23
    Rasmus Fjord
    0

    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?

  • Matt Brailsford 2216 posts 10802 karma points MVP 6x c-trib
    Feb 01, 2019 @ 09:21
    Matt Brailsford
    0

    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.

  • Rasmus Fjord 640 posts 1518 karma points c-trib
    Feb 11, 2019 @ 12:39
    Rasmus Fjord
    0

    I will give it a test and get back!

  • Rasmus Fjord 640 posts 1518 karma points c-trib
    Feb 13, 2019 @ 09:25
    Rasmus Fjord
    0

    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.

  • Matt Brailsford 2216 posts 10802 karma points MVP 6x c-trib
    Feb 14, 2019 @ 16:22
    Matt Brailsford
    0

    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.

  • Matt Brailsford 2216 posts 10802 karma points MVP 6x c-trib
    Feb 17, 2019 @ 13:20
    Matt Brailsford
    0

    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.

  • Matt Brailsford 2216 posts 10802 karma points MVP 6x c-trib
    Feb 17, 2019 @ 14:04
    Matt Brailsford
    0

    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 productIndentifier of the parent product for the order lines productIdentifier property.

    <input name="productIdentifier" value="@productPage.Id" type="hidden" />
    

    For all the variant properties that you need recorded on the order, you'd then want to copy them to the orderlines properties collection.

    <input name="AddOrUpdateOrderLine" value="productIdentifier, quantity, properties" type="hidden" />
    <input name="storeId" value="@storeId" type="hidden" />
    <input name="productIdentifier" value="@productPage.Id" type="hidden" />
    <input name="properties" value="variantSku,variantName,etc" type="hidden" />
    <input name="variantSku" value="V1000" type="hidden" />
    <input name="variantName" value="Blue / Black" type="hidden" />
    ....
    

    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

  • Rasmus Fjord 640 posts 1518 karma points c-trib
    Feb 20, 2019 @ 07:25
    Rasmus Fjord
    0

    Hey Matt

    Awesome, i will take it for a spin and see if i can make it work.

  • Rasmus Fjord 640 posts 1518 karma points c-trib
    Mar 08, 2019 @ 12:51
    Rasmus Fjord
    0

    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?

  • Matt Brailsford 2216 posts 10802 karma points MVP 6x c-trib
    Mar 08, 2019 @ 13:32
    Matt Brailsford
    0

    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.

Please Sign in or register to post replies

Write your reply to:

Draft