Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Suggestion: Rental / For Hire Products #343

Closed
spencern opened this issue Mar 13, 2015 · 8 comments
Closed

Suggestion: Rental / For Hire Products #343

spencern opened this issue Mar 13, 2015 · 8 comments

Comments

@spencern
Copy link
Contributor

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.

@aaronjudd
Copy link
Contributor

@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
Copy link
Contributor

I think the options approach described in #367 could be used to handle this case as well

@aaronjudd aaronjudd added this to the Product Management milestone Apr 30, 2015
@spencern
Copy link
Contributor Author

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.

+-- 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

@spencern
Copy link
Contributor Author

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.

Anyone else with this need or thoughts on this?

@aaronjudd
Copy link
Contributor

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
Copy link

@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
Copy link
Contributor Author

spencern commented Jul 2, 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
Copy link

faddat commented Jul 25, 2015

A variation on this theme:

Subscriptions

jshimko pushed a commit that referenced this issue Dec 3, 2015
…#343. Adds tests, and fixes issue where parent/grandparent quantities were not adding up properly. (11 Squashed)

Squashed commits:
[272ddf1] Make publications more consistent. Fixes #395.
[be04b1c] Allow database ids as valid slug for tags.

Bevor this change it was for example not possible to use a product id
as name (slug) for a tag, because the application interpreted the id as
a tag id, instead of a tag name.

A valid use case would be to display a link to a product's related products.
Allowing a product's id as tag name (slug) it is easy to build an URL to related products e.g.
product/tag/<product_id> .

The old behaviour is still in service as a fallback.
[9cf1232] remove testing logging.
[97a4a5f] Update inventory calculator again. Passes all tests against inventory calculation, is less brittle, and faster.
[207c0ad] WIP: Still need some work to update all variants if/when the inventory starts wrong.
[c360ae1] Fix issue where inventory was undefined if variant was new option
[2beb2a0] Compensate for bootstrap's padding when applying .container-fluid class.
[0055b68] Replace brittle inventory update hook with slightly more robust update hook that will update all ancestors in parent chain.
[7f6a91c] Update inventoryVariant tests to test creation of variable quantities of inventoryVariants being added.
[192b7c5] Addl Inline doc for cloneVariant method.
@aaronjudd aaronjudd modified the milestone: Product Management Sep 9, 2016
@aaronjudd aaronjudd removed the backlog label May 2, 2017
@spencern spencern closed this as completed Aug 1, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants