When we make a GBAL booking, what does BRM actually do?
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:
- actual bikes
- 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'.
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)