Yes I agree, keep it as general as possible
+1
Jacques
De : "Jacopo Cappellato" <[EMAIL PROTECTED]>
> 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).
>
