In my opinion, these new entities should really go into a new
specialpurpose rental component.
If we remove the techdata calendar entities and base everything on the
WorkEffort (a direction that I like) we have to design it in a very
generic way and not limited or specific to "rental" scenario; the new
refactoring will be used by the manufacturing processes as well and for
the manufacturing component AccommodationClass, AccommodationMap,
AccommodationSpot will not be used at all.
Jacopo
Hans Bakker wrote:
> 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).
