Hi David and all,

> 1. the package-name should be the same as the FixedAsset entity as  
> these really describe the FixedAssets used for transportation or lodging

Yes,I agree.

> 2. while we're at it we should create entities for Scheduled  
> Transportation and Scheduled Transportation Offering

Yes I agree here either. I can create one more initial patch and jira if
the community agrees upon that? Also maybe Ticket entities and
PartyTravelPreferences could be added later in the future...:)

> 3. looking at the data model it appears that the Accommodation Map  
> structure is meant to handle the Accommodation Spot concept, ie I  
> don't think there is a need to distinguish those... but correct me if  
> I'm wrong and I'm missing the distinction!

I was confused for some time on with that too. Here is a quote from the book 
p370:
"Because Transportation vehicles and hotels have AccommodationMaps to
show what can be booked figure 8.3 each ReservationItem may be reserving
an AccommodationSpot which would reserve a specific SEAT Number or Room
number whihch would correspond to a spot that is available withiin the
AccommodationMap for that type of accommodation"
IMO this separation is logical. Map entity saying only the total
number of spaces per class and spot entity - the actual spot(seat,room)
within this class. 
Well this could be achieved with one entity only - the spot entity.
The cons of having one entity is it will be larger and this logical
distinciton- map and the specific spot within that map will not be that
intense.

> 4. while creating the entities we should also add corresponding seed  
> data, including:
> 4.a. need an AccommodationTypeMap entity starting with types for Seat  
> Map, and Room Map
Yep, very good idea. The book also shows in its schemas (8.3) that
different types of maps should exist.

> 4.b. for fixedAssetTypeId we should have Vehicle, Transportation  
> Vehicle, Rental Vehicle, and Hotel
> 4.c. for ProductType we should have a bunch including:
> 4.c.1. Passenger Transportation Offering and sub types including:  
> Flight Offering, Bus Offering, Train Offering, Ship Offering, Other  
> Offering
> 4.c.2. misc such as Hotel Offering, Rental Car Offering, Amenities  
> Offering, Other Travel Offering
> 4.d. RoleType: Travel Provider (if it's not already there)

I agree with everything here.

> 5. some refinements in names would be good, like using  
> "numberOfSpaces" instead of something more difficult to read and  
> remember how it is shortened; also accommClassId might as well be  
> accommodationClassId, and parentAccommClassId can be like other  
> entities and just be parentClassId

Yes, I agree. I didn`t think on that when making the patch:)). I can
correct it once the community approves of the basic concepts behind it.

> 6. these entities are ONLY for modeling the travel offerings, ie the  
> Products, and other changes/additions will be needed for the Order*  
> and related entities, and for the ShoppingCart and related classes

Yes, these entities model the travel product and they are also part of
the order process. I suppose we should note also, travel orders in the
book are modeled with Reservation and ReservationItem entities.
What do you think on that David... Is it really the best way to extend
the Workeffort entity and keeep on useing it together with
TechDataCalendars for travel orders?

In my humble opinion, travel reservations in OFBiz(and generally) could
be modeled as order and order items. I do not like the idea of extending
the WorkEffort entity as I can`t figure out its logical place in the
resevation process and I also see further extentions on it with the
oncoming future entities from the reservation model like :
ScheduledTransportation and Ticket for example. Maybe a way to go would
be to think of the ReservationItem as OrderItem of Reservation as
OrderHeader and enhance/improve our current OFBiz code based on that? Or
somehow introduce these two entities(Reservation, ReservationItem)
directly? 

Of course this is just one idea which might not be the best for Ofbiz
and I might be wrong thinking like this.

Thanks for your time : Valentina


Reply via email to