Hi, Chris,
On 02/25/2014 05:47 PM, Chris Travers wrote:
On Tue, Feb 25, 2014 at 8:32 AM, John Locke <..hidden..> wrote:
Hi,
While I haven't actually built something like this, we have done some preliminary planning and use case analysis on a couple different projects along these lines.
I would suggest a couple terminology changes -- instead of individual units being "slots", they should be Inventory. E.g. a hotel has a room inventory.
Time slots for booking (hour, day, week, month, year) -> "Slots" define the granularity based on the business model
My initial thinking was that the services could handle that.
By "Services" are you referring to services under Parts & Services?
I think a service can certainly be used for pricing -- e.g. "Lawnmower Rental, hourly", "Lawnmower Rental, daily", with qty fields working as needed.
But it does not capture the time period of the booking -- or else you would need to create a new service for every rental...
Well, I would tend to think that you would track the bookings and slots in the rental module, and use a sales order to track the service rate (along with some link to the corresponding booking in the rental module -- serial number?)
Booking -> Service -- A booking consists of an inventory item and 1 or more consecutive slots. You might have a variety of services that can be used for booking -- an hourly rate, a daily rate, a weekly rate, a student rate, an employee rate, not to mention different prices for different inventory, or prices that change based on how far in advance they are purchased, etc.
For now (trying to keep this simple and reasonably achievable in the first iteration), what about tying it to an order where other goods and services can be added? I.e. we track the service rate with the rental in the rental module and link to an order for other add-on services.
In my use case, I would handle the booking and slots in a completely external system, for managing availability, and then just generate a sales order with the appropriate services to capture payment details, and turn into an invoice for the actual charge.
I guess my question here would be what use cases does the "rental module" have, if you're not going to build booking functionality?
So for me, what would be most useful to have in LSMB is really good deposit management, and possibly asset management of the rental inventory. The actual booking system to my mind has too much variation, but there's also a lot of value making it available to customers (or at least a broader range of staff/partners), so we would build those in a customer-facing system, not LSMB.
Right. Two thoughts here is that a full booking module may be rather beyond the scope of what I am likely to want to do on this current project. I am thinking that (unless there are others who want to jump in and offer funding to build such a thing), the best option would be to get a rental module done first and then look at building a booking module on the top of it down the road.
E.g. for your "Renting Unit" workflow, how are you going to determine what rentals are available, if you aren't tracking time slots and bookings?
Is this more of a library model, a simple check-in/check-out system?
By all means, if you have a customer asking for this, I completely understand putting time into it. But if not, I would really like to see the precursors that are coming up in this thread dialed in before expanding the scope of the system:
1. Deposit/pre-payment management
2. Asset management covering purchase, depreciation, and disposal of rental equipment (I'm sure this can be done now, but I don't know how...)
3. Options/product modifiers
Actually charging for rentals seems pretty straightforward without an add-on!