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

[David E Jones]

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

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!

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)

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

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

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

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

[Jacques Le Roux]

From: "David E Jones" <[hidden email]>
> 4. while creating the entities we should also add corresponding seed  data, including:

Another area we should think about is camping and related (mobile home, camping caravan/recreational vehicule, etc.). I don't know
in US and in other part of the world, but there is a lot of seasonal activity in Europe.

> 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

Camping site

> 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

Camping Offering, (RentalCar Offering should be ok for camping caravan/recreational vehicule, not sure for mobile home which are
between home and car)

Jacques

> 4.d. RoleType: Travel Provider (if it's not already there)
>
> 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
>
> 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
>
> I think that's my main feedback on this... just a few little  things... ;)
>
> -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.....
>>
>
>

[David E Jones]

To generalize this we should probably use "Lodgin" instead of "Hotel".  
There are lots of kinds of lodging including hotel, motel, hostel,  
campsite, condo/timeshare, etc. One the same note instead of "Hotel  
Offering" we should use "Lodging Offering".

As for an RV/motorhome I'd say it should be considered like a rental  
car. The way each cars and lodging are reserved and rented are really  
pretty similar, but in general from experience the terms and practices  
seem far more similar to the rental car industry.

-David


On Jan 27, 2008, at 10:56 PM, Jacques Le Roux wrote:

> From: "David E Jones" <[hidden email]>
>> 4. while creating the entities we should also add corresponding  
>> seed  data, including:
>
> Another area we should think about is camping and related (mobile  
> home, camping caravan/recreational vehicule, etc.). I don't know in  
> US and in other part of the world, but there is a lot of seasonal  
> activity in Europe.
>
>> 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
>
> Camping site
>
>> 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
>
> Camping Offering, (RentalCar Offering should be ok for camping  
> caravan/recreational vehicule, not sure for mobile home which are
> between home and car)
>
> Jacques
>
>> 4.d. RoleType: Travel Provider (if it's not already there)
>>
>> 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
>>
>> 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
>>
>> I think that's my main feedback on this... just a few little  
>> things... ;)
>>
>> -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.....
>>>
>>
>>
>

[hans_bakker]

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

[Jacques Le Roux]

From: "David E Jones" <[hidden email]>

>
> To generalize this we should probably use "Lodgin" instead of "Hotel".  
> There are lots of kinds of lodging including hotel, motel, hostel,  
> campsite, condo/timeshare, etc. One the same note instead of "Hotel  
> Offering" we should use "Lodging Offering".
>
> As for an RV/motorhome I'd say it should be considered like a rental  
> car. The way each cars and lodging are reserved and rented are really  
> pretty similar, but in general from experience the terms and practices  
> seem far more similar to the rental car industry.

Agreed to both :o)

Jacques
 

> -David
>
>
> On Jan 27, 2008, at 10:56 PM, Jacques Le Roux wrote:
>
>> From: "David E Jones" <[hidden email]>
>>> 4. while creating the entities we should also add corresponding  
>>> seed  data, including:
>>
>> Another area we should think about is camping and related (mobile  
>> home, camping caravan/recreational vehicule, etc.). I don't know in  
>> US and in other part of the world, but there is a lot of seasonal  
>> activity in Europe.
>>
>>> 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
>>
>> Camping site
>>
>>> 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
>>
>> Camping Offering, (RentalCar Offering should be ok for camping  
>> caravan/recreational vehicule, not sure for mobile home which are
>> between home and car)
>>
>> Jacques
>>
>>> 4.d. RoleType: Travel Provider (if it's not already there)
>>>
>>> 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
>>>
>>> 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
>>>
>>> I think that's my main feedback on this... just a few little  
>>> things... ;)
>>>
>>> -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.....
>>>>
>>>
>>>
>>
>

[Valentina Sirkova]

(sorry i didnt notice i sent it to the user list so i am resending it)

Hi Hans and others,
I will start from discussing Hans post and then comment and answer to
the rest of the posts (they are a lot :) ).

On Mon, 2008-01-28 at 10:58 +0700, Hans Bakker wrote:

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

Yes Hans, I agree here but maybe it will be even better if we still KEEP
this field as it is designed to store accommodation number and not the
description. Maybe we could simply add one more field for description.

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

Well, I put overbooked field there as this entity`s purpose is to keep
the general data for the class, so I thought its logical place is there.
Also these 3 entities are part of "travel orders" from the book which do
not involve the Workeffort entity at all. I know the CURRENT OFBiz
implementation involves it in the reservation logic and therefore the
easiest way is to put it there..but I am not sure if extending the
workeffort entity is the real solution, it is probably sort of a FIX
with our current logic.
IMHO workeffort and techdata calendars should not be involved with
reservations and NEW improved implementation of the reservations in
OFBiz should be introduced based on the book-I can help with that.
Actually there was discussion based on that which died
http://www.nabble.com/Stop-using-techdata-calendar-to12220306.html#a12220306 

> 3. should the fixed asset be part of the primaryKey of the
accomodation
> map? let me know why?

Well, it makes sense to me why the book models it this way -
I guess the reason for that is as all classes are related to some
fas(hotels,restaurants etc) but I do not believe this should be a must
for us!

> 4. Should the class be a field in the map? isn't it more a
specification
> of the spot?

YES, definately..there is no point of the map without the class... It
should say how many places a class has in a given FIXEDASSET.

I guess the question comes from the fact that these two entities are
almost the same! Well, I was with this confusion for a while too. These
two entities have really similar fields so for some time on I was using
the map instead of the spot in my local copy and that is why I described
to you the number of the seats etc in the map entity:)  see here
<a href="http://www.nabble.com/Re%3A-seats-tables-in-a-restaurant-%">http://www.nabble.com/Re%3A-seats-tables-in-a-restaurant-%
28or-plane-or-cinema%29-p14891741.html

Here is a quote from the book p370 (I guess I am answering
David`s question here)
"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"

I guess 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. Which means availability services would check the
total capacity of the the room type in the map entity and then would
reserve spots (real room numbers) from the spot entity.

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.

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

(just a note here)
The last relation to the Map entity..if you get rid of the class field
in the map entity as you have showed in your post you cant use the last
relation to AccommodationMap like this.Maybe something like this would
be right:
        <relation type="one-nofk" fk-name="ACCOMM_MAP"
         rel-entity-name="AccommodationMap">
            <key-map field-name="fixedAssetId"/>
        </relation>

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

I do not believe this is a good approach.

>
> Add 2 fields to WorkEffort and to the shoppingcart:
>
>         <field name="accommMapId" type="id"/>
>         <field name="accommSpotId" type="id"/>

IMHO, this way of thinking would lead to many more
extentions to an entity which is probably more intented for
manufacturing and workeffort usage and not for reservations.
For example sooner or later we`ll need to add as David suggested
ScheduledTransportation entities, also I believe we`ll need to add
Ticket entitiy and maybe others which would relate to the
ReservationItem directly. This`ll lead to further extentions to
Workeffort.

The book handles reservations thru Reservation and Reservation entities.
In our OFBiz project this is neither the Workeffort nor any of the
TechDataCalendars and I am not sure if complicating them further is a
good way to go.

I guess the better direction would be to rethink our current OFBiz
implementation and improve it based on the book`s way. IMO,
OrderItem is logically what is ReservationItem from the book and
this is the entity which will have to be extended(but I need the
comminity`s opinion on that). Of course this
would mean we`ll have to reimplement our current OFBiz code. I have
ideas how this could happen and what exactly should be changed. If the
community is interested in this idea we could discuss it further and
I could provide more detailed picture of that.

Valentina

[Jacques Le Roux]

From: "Valentina Sirkova" <[hidden email]>

> (sorry i didnt notice i sent it to the user list so i am resending it)
>
> Hi Hans and others,
> I will start from discussing Hans post and then comment and answer to
> the rest of the posts (they are a lot :) ).
>
> On Mon, 2008-01-28 at 10:58 +0700, Hans Bakker wrote:
>
>> 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.
>
> Yes Hans, I agree here but maybe it will be even better if we still KEEP
> this field as it is designed to store accommodation number and not the
> description. Maybe we could simply add one more field for description.

I agree surely less work later and can't hurt.

I have still to read the book before making any comments below. I begin to read Chapter 8 travel...

Jacques

[Valentina Sirkova]

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

[David E Jones]

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