Hi Valentina,
This sounds like a good idea, can you create a Jira issue for it? If you
copy your request in there we can keep the discussion together.
i agree we need accommodation maps and spots for theater seats, bus and
airplane seats. At the moment not so much for rooms, because a room
(group) in itself is a fixed asset.
A reservation at the moment is an order combined with orderitems and a
related workefforts. Using now another method for reservations?
A hotel offering is now a products in different classes related to the
same fixed asset so that the same hotel room can be offered with 2 or
with 3 beds, with or without flowers and fruitbasket etc.
Regards,
Hans
On Tue, 2007-08-28 at 12:22 -0700, Valentina Sirkova wrote:
> Hi Hans, Jacopo and all,
>
> I am currently working with rental stuff and I saw your recent posts "stop
> using the techDataCal" (because of the repeated data in the workeffort
> entity) and decided to share my ideas with you. I am reading the book "The
> Data Model Resource Book Revised Edition" volume 2 and I was wondering if
> you could be interested in extending the data base with a few more entities
> described in the book. Pages 364-371 - figures 8.3 and 8.4 describe the
> entites AccommodationClass, AccommodationMap,AccommodationSpot.
>
> Maybe they could have these fields:
>
> - AccommodationClass {accommodClassId, parentAccommodClassId description}.
> -
> AccommodationMap{fixedAssetId,totalAvailable,accommodClassID,roomsOverbooked}.
> - AccommodationSpot{fixedAssetID, from, thru, accommodClassId,
> usedCapacity, orderItemId}.
>
>
> These entities could have the following relationships between them:
>
> AccommodationClass -----
> AccommodationMap-------AccommodationSpot-----OrderItem----Product-----FixedAsset----AccommodationMap
>
> The logic behind them:
>
> We can use AccommodationClass to define different roomTypes, accommodation
> classes, and further make relations between them(parent-child).
>
> AccommodationMap could tell us the accommodClassId(e.g room type) how many
> rooms/places it has(totally), which is the fixedasset itself and how many
> rooms can be overbooked.
>
> AccommodationSpot is the actual room/roomtype or whatever that has been
> reserved. It is something like the extended TechDataExcDay entity.
> Advantages are that it has from and thru dates which could be used for
> reservation of hours.
>
> If we use AccommodationSpot for rental and not the workeffort itsself the
> order process will simplify in a way - we will create AccommodationSpot
> record and put all the data needed there, in this way we wont need to keep
> the data in two entities -workeffort and techdatacalendar.
>
> Do you think that this is a good approach? I am currently working on this
> idea and if you like it I would be happy to work with you(after your opinion
> and advice).
--
http://Antwebsystems.com : OFBiz Quality support for competitive rates.
