We have a meetingroom module. I think creating a new UI then everything should be ok.
We are using this UI for the rental products: http://www.langhua.cn/ad-reservation.jpg Regards, Shi Yusen/Beijing Langhua Ltd. 在 2007-08-29三的 09:13 +0700，Hans Bakker写道： > 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).
