What is GBAL actually doing?

When we make a GBAL booking, what does BRM actually do?

Let's start with a definition

1. Generic Booking: When you create a GBAL reservation, you book a bike at the Product Line level without specifying a particular bike. For example, booking one bike out of a Product Line with two identical bikes marks the Product Line as partially booked, but no specific bike is allocated yet.
2. Virtual Inventory: Behind the scenes, BRM creates a 'virtual' counterpart of your actual inventory to manage these generic bookings. This virtual space holds the generic reservations until you allocate them to specific bikes. You can view this virtual inventory in the planner.
3. Allocation: As the rental date approaches, you can assign specific bikes to these generic bookings, a process known as 'just-in-time allocation.' This method ensures that you don't overbook and allows for flexible management of your fleet.  (see the back of the pile problem)

• Online Booking Support: GBAL enables bike stores to not worry about being overbooked (for a given model-size) while not having to worry about actual bikes, until the time is right to do so.
• Operational Efficiency: By deferring the allocation of specific bikes, GBAL aligns with operational practices where accessing particular bikes on demand may be challenging, such as when bikes are stored in sheds or stacked configurations.

A closer look into th

Let's say I book a bike using GBAL for 2 days, here is what happens on the database.

First of all, I book it generically:

Which will put in a booking at the Generic level:

This means the parent Product Line is busy; for 1 bike (out of 2) for that period.  

But, crucially we've not yet allocated a bike.

(this can create the impression that you have more availability than you really do.

So what is going on behind the scenes?

Whenever we have a Product Line (the purple row) we actually secretly create a mirror-image of your real inventory in what we call 'virtual space'  This is where your generic bookings are kept until they are allocated.

You can actually see this if you go to search mode, and choose the 'day planner'

So in fact, if we were to draw the create view completely accurately it would include both:

1. actual bikes
2. virtual bikes (for generic bookings)

something like this:

(Please note that we derive the IDs of our virtual assets sequentially from our Product Line ID (110000)

Here you can more clearly see how a GBAL booking (the purple row) translates into activity on the database.

So, why don't we show like the above??

Because we have discovered a phenomenon we call 'can't transfer between two boots'.

See this article for an in-depth discussion. 

Also, it is inherently confusing to have virtual space, which leads to the impression that you have more availability than you really do.  So we're re-building this part of the system.

We are moving to a system where we provisionally allocate to a physical item.

• This way we don't have to transfer from virtual to physical space on allocation.
• It is also just easier to keep track of how 'booked up' you actually are - even when taking GBAL bookings.

You will still have all the advantages of GBAL, it will just be easier and less problematic.

Here is a mockup:

Note: we'll automatically assign an actual bike (albeit provisionally)

Crucially provisionally booked bikes can be moved around (by BRM when trying to fit more in, and by yourself manually)

See Also

can't transfer between cars connundrum