Would love to be able to use reaction to build a store where products can be rented out (e.g. lensrentals.com, Rent The Runway, etc) as there is not currently a good open source solution to this business case.
Some challenges that this would introduce on top of standard ecommerce:
Tracking inventory for rental products across a calendar instead of binary in/out of stock
Pricing as a daily/weekly/monthly rate
Variable pricing dependent on rental length
Bumper / Turnover time before product can be rented again
I'm certain there are other issues that would crop up, but those seem to be the big
Is this something that could be implemented as a package or would it have to be integrated into core?
I'd love to jump in and help build this out, but would need some direction as to the best place to start working on something like this.
@spencern on pricing at least, I'm wondering if we could implement some sort of a "pricing engine" approach "price" etc - (probably going to do this with discounts/promos at some level anyways). Instead of pulling direct from the data, we could use the "pricing engine" implementation where you could determine the pricing data.
We have also discussed having product "types" where you could choose from a couple different product types. #152 and #160 touch on these.
I'd like to handle the additional types in core, but add as packages. Since nothing has been done towards 'product types' yet.. maybe you could discuss the challenges that you face as you try to implement something like as a package, and we'll adjust core as needed to make sure it's flexible for extending/adding new product types.
Subscriptions #330, and digital goods are other product types that will have similar requirements as well.
@spencern
I see that the VariantProduct schema has a 'barcode' field. Is this intended to be used for tracking inventory on an item-by-item basis? E.g.
+-- Jacket
| +-- Black
| | +-- Small
| | | +-- Individual Item / Barcode / id
| | | +-- Individual Item / Barcode / id
| | | +-- Individual Item / Barcode / id
| | +-- Medium
| | | +-- ...
| +-- Red
| | +-- Small
| | | +-- ...
If so, are there methods already which aggregate the inventory count for these barcoded items, or does that still need to be written?
@aaronjudd
correct, the barcode and sku fields are on each variant (as it's a unique product).
yes some of this exists, but most likely needs some refactoring. I think it’s mostly client side validation. I’ve not looked at it in a while though, as I doubt it’s something that handles more recursion
This method of individual item tracking is essential to being able to offer rental products. I've been poking around in the Product and ProductVariant schemas a little bit lately.
Say we have 3 identical mountain bikes.
Mountain Bike
-- Full Suspension
-- Small
-- Barcode: 1
-- Barcode: 2
-- Barcode: 3
I'm trying to figure out the best way to store one of these items. Following the schema, it seems like they should be variants where the parentId is the Small variant (to use the above case), but I could see an argument for the parentId being the Full Suspension variant as well.
You're saying that you have "Small" and that should the visible option, but your inventory, is 20 of the same "product" but each has it's own sku/barcode?
I'm thinking that could be a child variant of "small" (same as existing structure) that we could mark as "type: inventory" and then handle that with some unique view and inventory mgmt.... maybe hide (or not ) for the 'consumer', but use and update for inventory
@aaronjudd @spencern "You're saying that you have "Small" and that should the visible option, but your inventory, is 20 of the same "product" but each has it's own sku/barcode?"
I have an almost exact use case, but in a different scenario... imagine something that can be exemplified (such as an ebay item listing) where you have many of the same products (say 500) and you are allowing this specific item to be bought in variable quantities of minimally 1 to x (x being the max number of items remaining in your inventory)... when someone in your commerce site adds the item to his/her cart they are in essence on-the-clock* 'holding or reserving' x qty of the item(s) until his/her checkout is complete. I need a way to mark that specific item/SKU as being reserved or held (until a short threshold datetime is reached to prevent something from being held too long - ie they failed to checkout within the short reservation period of say 5 minutes). So what I'm thinking is that I need to track two things to each item similar to the "barcode" idea presented by Spencer... namely 1. the userId of the person reserving each instance of the available item(s) and 2.) a datetime stamp indicating a hard point in time that the reservation expires and the full reserved qty is made available to everyone once again. (Note: a CRON type job would run through the Mongo Collection every minute or so to remove the expired reservation set for an item.
Instead of polluting the product collection I think perhaps these reservations might make more sense in their own collection which merely alters the product/sku availability quantites when a CRUD event occurs upon the reservation collection.
@aaronjudd exactly. Added a PR that enables products to have and track inventory as child variants.
@markchipman I think that this idea should solve your use case too.
What we will also need to do (and perhaps I should break up this issue into multiple sub-issues) is create packages that modify the (inventory) variant schema to add additional fields as necessary - for us it might be rental availability calendar, condition, etc.
for @markchipman it might be reservation status and reservation expiration time or something similar.
@spencern commented on Fri Mar 13 2015
Would love to be able to use reaction to build a store where products can be rented out (e.g. lensrentals.com, Rent The Runway, etc) as there is not currently a good open source solution to this business case.
Some challenges that this would introduce on top of standard ecommerce:
I'm certain there are other issues that would crop up, but those seem to be the big
Is this something that could be implemented as a package or would it have to be integrated into core? I'd love to jump in and help build this out, but would need some direction as to the best place to start working on something like this.
@aaronjudd commented on Sat Mar 21 2015
@spencern on pricing at least, I'm wondering if we could implement some sort of a "pricing engine" approach "price" etc - (probably going to do this with discounts/promos at some level anyways). Instead of pulling direct from the data, we could use the "pricing engine" implementation where you could determine the pricing data.
We have also discussed having product "types" where you could choose from a couple different product types. #152 and #160 touch on these.
I'd like to handle the additional types in core, but add as packages. Since nothing has been done towards 'product types' yet.. maybe you could discuss the challenges that you face as you try to implement something like as a package, and we'll adjust core as needed to make sure it's flexible for extending/adding new product types.
Subscriptions #330, and digital goods are other product types that will have similar requirements as well.
@aaronjudd commented on Thu Apr 30 2015
I think the options approach described in #367 could be used to handle this case as well
@spencern commented on Wed May 13 2015
From gitter chat: May 12 2015 12:00 PM
@spencern I see that the VariantProduct schema has a 'barcode' field. Is this intended to be used for tracking inventory on an item-by-item basis? E.g.
If so, are there methods already which aggregate the inventory count for these barcoded items, or does that still need to be written?
@aaronjudd correct, the barcode and sku fields are on each variant (as it's a unique product). yes some of this exists, but most likely needs some refactoring. I think it’s mostly client side validation. I’ve not looked at it in a while though, as I doubt it’s something that handles more recursion
@spencern commented on Wed May 13 2015
This method of individual item tracking is essential to being able to offer rental products. I've been poking around in the
ProductandProductVariantschemas a little bit lately.Say we have 3 identical mountain bikes.
I'm trying to figure out the best way to store one of these items. Following the schema, it seems like they should be variants where the
parentIdis the Small variant (to use the above case), but I could see an argument for the parentId being the Full Suspension variant as well.Anyone else with this need or thoughts on this?
@aaronjudd commented on Wed May 13 2015
You're saying that you have "Small" and that should the visible option, but your inventory, is 20 of the same "product" but each has it's own sku/barcode?
I'm thinking that could be a child variant of "small" (same as existing structure) that we could mark as "type: inventory" and then handle that with some unique view and inventory mgmt.... maybe hide (or not ) for the 'consumer', but use and update for inventory
@markchipman commented on Tue Jun 16 2015
@aaronjudd @spencern "You're saying that you have "Small" and that should the visible option, but your inventory, is 20 of the same "product" but each has it's own sku/barcode?"
I have an almost exact use case, but in a different scenario... imagine something that can be exemplified (such as an ebay item listing) where you have many of the same products (say 500) and you are allowing this specific item to be bought in variable quantities of minimally 1 to x (x being the max number of items remaining in your inventory)... when someone in your commerce site adds the item to his/her cart they are in essence on-the-clock* 'holding or reserving' x qty of the item(s) until his/her checkout is complete. I need a way to mark that specific item/SKU as being reserved or held (until a short threshold datetime is reached to prevent something from being held too long - ie they failed to checkout within the short reservation period of say 5 minutes). So what I'm thinking is that I need to track two things to each item similar to the "barcode" idea presented by Spencer... namely 1. the userId of the person reserving each instance of the available item(s) and 2.) a datetime stamp indicating a hard point in time that the reservation expires and the full reserved qty is made available to everyone once again. (Note: a CRON type job would run through the Mongo Collection every minute or so to remove the expired reservation set for an item.
Instead of polluting the product collection I think perhaps these reservations might make more sense in their own collection which merely alters the product/sku availability quantites when a CRUD event occurs upon the reservation collection.
Thoughts?
@spencern commented on Thu Jul 02 2015
@aaronjudd exactly. Added a PR that enables products to have and track inventory as child variants.
@markchipman I think that this idea should solve your use case too.
What we will also need to do (and perhaps I should break up this issue into multiple sub-issues) is create packages that modify the (inventory) variant schema to add additional fields as necessary - for us it might be rental availability calendar, condition, etc.
for @markchipman it might be reservation status and reservation expiration time or something similar.
@faddat commented on Sat Jul 25 2015
A variation on this theme:
Subscriptions