Re: new accomodation map entities Jira OFBIZ-1590 (was on the user mailing list)

[Hans Bakker <ma...@antwebsystems.com>]

Hi David,

i am not sure if you are now making it too big...adding scheduled
transportation also needs a 'from' and a 'to' destination which are
fields which are not present on the product yet....Then we need a
'regular schedule' which we have to add..... 

The proposal we have now does not limit these extensions in the future.
Now we need it for restaurants to be able to accept reservations for
that.

Please see my other answers in-line below....

Regards,
Hans


On Sun, 2008-01-27 at 22:11 -0700, David E Jones wrote:
> NOTE: I've moved this to the dev list from the user list because this  
> is very clearly a discussion of enhancements to OFBiz itself.
> 
> 
> I've been looking over these a bit, and it seems like there are a few  
> things outstanding with them so far, including:
> 
> 1. the package-name should be the same as the FixedAsset entity as  
> these really describe the FixedAssets used for transportation or lodging
> 

sure should do that.

> 2. while we're at it we should create entities for Scheduled  
> Transportation and Scheduled Transportation Offering
> 
> 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!

A accomodation plan is a kind of drawing of the accomodation, which
seats/table are where located. The number of spots and their description
vary in number and definition, therefore we need the accomodation spot.

> 
> 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
> 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)

sure we will do that.

> 
> 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

good suggestion.

> 
> 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
> 

at the moment as metioned in the proposal 2 fields need to be added to
workeffort and shoppingcart.

> I think that's my main feedback on this... just a few little  
> things... ;)

thanks for the comments David, very usefull.

> 
> -David
> 
> 
> On Jan 27, 2008, at 8:58 PM, Hans Bakker wrote:
> 
> > Hi Valentina,
> >
> > thanks for your input. The first thing we have to agree now is the
> > entity definitions. Then later we can see how we do the availability
> > checking. For the good order: Karnchana is working with me here.
> >
> > here was you original proposal from you which is a little modified by
> > me:
> > 1. on the accomodation spot it is perhaps better to use the
> > 'description' field instead of number, to be able to also say:  
> > "table in
> > the corner with the nice view"? It still can contain a number.
> > 2. In the accomodation map i do not see the reason for the  
> > 'overbooked'
> > field, availability is better kept the the workeffort entity (search  
> > the
> > workeffort entity for the specific time and the specific accomodation
> > map/spot) and the number of spaces is available in the accomodation  
> > map.
> > 3. should the fixed asset be part of the primaryKey of the  
> > accomodation
> > map? let me know why?
> > 4. Should the class be a field in the map? isn't it more a  
> > specification
> > of the spot?
> > 5. I did some adjustments to the field types.
> >
> > please let me know what you, and others think about this proposal.
> >
> >    <entity entity-name="AccommodationClass"
> >            package-name="org.ofbiz.order.reservations"
> >            title="Accommodation Class">
> >        <field name="accommClassId" type="id-ne"></field>
> >        <field name="parentAccommClassId" type="id"></field>
> >        <field name="description" type="description"></field>
> >        <prim-key field="accommClassId"/>
> >        <relation type="one" fk-name="ACCOMM_CLASS_PAR" title="Parent"
> > 		rel-entity-name="AccommodationClass">
> >            <key-map field-name="parentAccommClassId"
> > 	 rel-field-name="accommClassId"/>
> >        </relation>
> >    </entity>
> >
> >    <entity entity-name="AccommodationSpot"
> >            package-name="org.ofbiz.order.reservations"
> >            title="Accommodation Spot">
> >        <field name="accommSpotId" type="id-ne"></field>
> >        <field name="accommClassId" type="id"></field>
> >        <field name="fixedAssetId" type="id"></field>
> >        <field name="nrOfSpaces" type="numeric"></field>
> >        <field name="description" type="description"></field>
> >        <prim-key field="accommSpotId"/>
> >        <relation type="one" fk-name="ACCOM_CLASS"
> > 	 rel-entity-name="AccommodationClass">
> >            <key-map field-name="accommClassId"/>
> >        </relation>
> >        <relation type="one" fk-name="SPOT_FA"
> > 	 rel-entity-name="FixedAsset">
> >            <key-map field-name="fixedAssetId"/>
> >        </relation>
> >        <relation type="one-nofk" fk-name="ACCOMM_MAP"
> > 	 rel-entity-name="AccommodationMap">
> >            <key-map field-name="accommClassId"/>
> >            <key-map field-name="fixedAssetId"/>
> >        </relation>
> >    </entity>
> >
> >    <entity entity-name="AccommodationMap"
> >            package-name="org.ofbiz.order.reservations"
> >            title="Accommodation Map">
> >        <field name="accommMapId" type="id-ne"></field>
> >        <field name="fixedAssetId" type="id"></field>
> >        <field name="nrOfSpaces" type="numeric"></field>
> >        <prim-key field="accommMapId"/>
> >        <relation type="one" fk-name="ACMD_MAP_FA"
> > 	 rel-entity-name="FixedAsset">
> >            <key-map field-name="fixedAssetId"/>
> >        </relation>
> >    </entity>
> >
> > Add 2 fields to WorkEffort and to the shoppingcart:
> >
> >        <field name="accommMapId" type="id"/>
> >        <field name="accommSpotId" type="id"/>
> >
> > -- 
> > AntWebsystems.com: Quality OFBiz services for competitive rates.....
> >
> 
> 
-- 
AntWebsystems.com: Quality OFBiz services for competitive rates.....

Re: new accomodation map entities Jira OFBIZ-1590 (was on the user mailing list)

[David E Jones <jo...@hotwaxmedia.com>]

On Jan 28, 2008, at 1:00 AM, Hans Bakker wrote:

> On Sun, 2008-01-27 at 22:11 -0700, David E Jones wrote:
>> 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!
>
> A accomodation plan is a kind of drawing of the accomodation, which
> seats/table are where located. The number of spots and their  
> description
> vary in number and definition, therefore we need the accomodation  
> spot.

What you're described is pretty much exactly what I understand the  
Accommodation Map structure to be used for.

-David