Stop using techdata calendar

[hans_bakker]

Good day,

I (and Bilgin) am extending the rental facilities in OFBiz and i am
struggling with the techdata calendars for rental. They are in fact a
copy of the information which already available in the workeffort
entity.

I would like to propose to stop using the techdata calendars and extract
the information from the workeffort entity and see if we can make it
work performance-wise: a monthly calendar of a fixed asset showing
occupation/availability should not take too long.

What is the opinion of the community?

Regards,
Hans Bakker


--
http://Antwebsystems.com : OFBiz Quality support for competitive rates.

[Jacopo Cappellato]

+100

Jacopo

Hans Bakker wrote:

> Good day,
>
> I (and Bilgin) am extending the rental facilities in OFBiz and i am
> struggling with the techdata calendars for rental. They are in fact a
> copy of the information which already available in the workeffort
> entity.
>
> I would like to propose to stop using the techdata calendars and extract
> the information from the workeffort entity and see if we can make it
> work performance-wise: a monthly calendar of a fixed asset showing
> occupation/availability should not take too long.
>
> What is the opinion of the community?
>
> Regards,
> Hans Bakker
>
>

[Jacopo Cappellato]

Hans,

how do you plan to implement the default capacity for the calendar?
I mean, this screen:

https://localhost:8443/manufacturing/control/EditCalendarWeek?calendarWeekId=DEFAULT

(and the non standard days, e.g. an holiday)

I guess you will define them using a special type of WorkEffort... but
I'd like to know the details.

Jacopo

Hans Bakker wrote:

> Good day,
>
> I (and Bilgin) am extending the rental facilities in OFBiz and i am
> struggling with the techdata calendars for rental. They are in fact a
> copy of the information which already available in the workeffort
> entity.
>
> I would like to propose to stop using the techdata calendars and extract
> the information from the workeffort entity and see if we can make it
> work performance-wise: a monthly calendar of a fixed asset showing
> occupation/availability should not take too long.
>
> What is the opinion of the community?
>
> Regards,
> Hans Bakker
>
>

[hans_bakker]

Hi Jacopo,

The default capacity should be stored in a specific type of workeffort.
I will create the logic to use it for rental facilities. If that works
and shows reasonable performance, you can start looking it for
manufacturing. These two applications are not interfering each other.
Is that a reasonable approach?

Regards,
Hans

On Sun, 2007-08-19 at 11:08 +0200, Jacopo Cappellato wrote:

> Hans,
>
> how do you plan to implement the default capacity for the calendar?
> I mean, this screen:
>
> https://localhost:8443/manufacturing/control/EditCalendarWeek?calendarWeekId=DEFAULT
>
> (and the non standard days, e.g. an holiday)
>
> I guess you will define them using a special type of WorkEffort... but
> I'd like to know the details.
>
> Jacopo
>
> Hans Bakker wrote:
> > Good day,
> >
> > I (and Bilgin) am extending the rental facilities in OFBiz and i am
> > struggling with the techdata calendars for rental. They are in fact a
> > copy of the information which already available in the workeffort
> > entity.
> >
> > I would like to propose to stop using the techdata calendars and extract
> > the information from the workeffort entity and see if we can make it
> > work performance-wise: a monthly calendar of a fixed asset showing
> > occupation/availability should not take too long.
> >
> > What is the opinion of the community?
> >
> > Regards,
> > Hans Bakker
> >
> >
>
>
>

--
http://Antwebsystems.com : OFBiz Quality support for competitive rates.

[Valentina Sirkova]

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

[hans_bakker]

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

--
http://Antwebsystems.com : OFBiz Quality support for competitive rates.

[Shi Yusen]

We have a meetingroom module. I think creating a new UI then everything
should be ok.

We are using this UI for the rental products:
http://www.langhua.cn/ad-reservation.jpg

Regards,

Shi Yusen/Beijing Langhua Ltd.



在 2007-08-29三的 09:13 +0700，Hans Bakker写道：

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

[Valentina Sirkova]

Hi Shi,

Do you base your implementation of hourly reservations on the current logic? Maybe something like this:
 1) You define something like minimum reservation period -say 1 hour.
 2) You check availability of the fixed asset for every 1 hour.
 If you want to reserve a fixed asset for the period  3a.m - 5a.m then you check the availability from 3-4 and then from 4-5?And basically you create record in the TechDataCalendarExcDay for every exceptionStartDate-in our example 2 records? If this is the way - can you reserve for less then this defined minimum reservation period? for example 30 minutes, 45 minutes etc? I mean from 3 to 3.33 for example?

Or you have changed in a way order services to achieve this flexibility?

Valentina

[Shi Yusen]

Hi Valentina,

> Do you base your implementation of hourly reservations on the current logic?
> Maybe something like this:
>  1) You define something like minimum reservation period -say 1 hour.
>  2) You check availability of the fixed asset for every 1 hour.
Every 15 minutes acturally.

>  If you want to reserve a fixed asset for the period  3a.m - 5a.m then you
> check the availability from 3-4 and then from 4-5?And basically you create
> record in the TechDataCalendarExcDay for every exceptionStartDate-in our
> example 2 records? If this is the way - can you reserve for less then this
> defined minimum reservation period? for example 30 minutes, 45 minutes etc?
> I mean from 3 to 3.33 for example?
No, the minimum reservation period is 15 minutes. 3 to 3.33 will be
reserved from 3:00 to 3:45.

> Or you have changed in a way order services?
The price for the rental rooms is charged for every 15 minutes, so the
quantity in an order is how many 15 minutes.

Regards,

Shi Yusen/Beijing Langhua Ltd.

[David E Jones]

Shi Yusen wrote:

> Hi Valentina,
>
>> Do you base your implementation of hourly reservations on the current logic?
>> Maybe something like this:
>>  1) You define something like minimum reservation period -say 1 hour.
>>  2) You check availability of the fixed asset for every 1 hour.
> Every 15 minutes acturally.
>
>>  If you want to reserve a fixed asset for the period  3a.m - 5a.m then you
>> check the availability from 3-4 and then from 4-5?And basically you create
>> record in the TechDataCalendarExcDay for every exceptionStartDate-in our
>> example 2 records? If this is the way - can you reserve for less then this
>> defined minimum reservation period? for example 30 minutes, 45 minutes etc?
>> I mean from 3 to 3.33 for example?
> No, the minimum reservation period is 15 minutes. 3 to 3.33 will be
> reserved from 3:00 to 3:45.
>
>> Or you have changed in a way order services?
> The price for the rental rooms is charged for every 15 minutes, so the
> quantity in an order is how many 15 minutes.

They charge in 15 minute increments? What kind of place is that? ;)

-David

[Jacopo Cappellato]

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

[Jacques Le Roux]

Yes I agree, keep it as general as possible

+1

Jacques

De : "Jacopo Cappellato" <[hidden email]>

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

[Valentina Sirkova]

Hi Hans,

First of all thank you for your comments and suggestions. Maybe as you offered I will create issue for this later.

It is true accommodation classes,spots could be used for theater seats etc but I also think they could be used for room renting as well.
 For example we could define the room types as accommodation classes and through accommodation maps relate to these classes the rooms which are fixed assets. I don`t think the current implementation supports room types renting unless we define the room type as a fixed asset(I mean to reserve room type without assigning an actual room number/fixed asset. I think this could be achieved only if we define the room type as a fixed asset because in this way we would be able to increase its used capacity?) Or maybe there is some better way?  

About reservations - for RENTAL_ORDER_ITEMS right now we create workeffort record from which we extract information like:start,end dates reservMaxPersons,reserv2reservNthPPPerc,reserv2ndPPPerc then we use part of this information for the TechDataCalendars. My idea about reservation is not much different - the only difference is that we won`t use workeffort record + TechDataCalendars to store rental related information like from, thru dates etc but AccommodationSpot(or it could have some other name) entity which will be specifically for reservation data. I guess most of the fields of the workeffort entity won`t be necessary for the rental data while all the AccommodationSpot fields will be used.

And if we use an entity which has from and thru dates maybe we will be able to implement hourly reservations? I think right now the only way is the Shi Yusen`s approach, which is probably not the best solution for hourly reservation - it creates too many records and it is not very flexible?

Thanks : Valentina :)

[Shi Yusen]

> I think right now the only way is the Shi
> Yusen`s approach, which is probably not the best solution for hourly
> reservation - it creates too many records and it is not very flexible?
Not too many records. One reservation is one order record only. The UI
will split it to segments on display.

Regards,

Shi Yusen/Beijing Langhua Ltd.

[Valentina Sirkova]

Hi Shi,

I didn`t mean too many order records but too many techdataexcday records. For example for 1 hour in the techdataexcday don`t you have 4 records(you said you use 15 minutes)? For example to reserve from 1.00 to 2.00 dont you get  the following  exceptionStartDates 1.00, 1.15, 1.30, 1.45 ?

Valentina

[Jacques Le Roux]

David E Jones wrote

Shi Yusen wrote:
> Hi Valentina,
>
>> Do you base your implementation of hourly reservations on the current logic?
>> Maybe something like this:
>>  1) You define something like minimum reservation period -say 1 hour.
>>  2) You check availability of the fixed asset for every 1 hour.
> Every 15 minutes acturally.
>
>>  If you want to reserve a fixed asset for the period  3a.m - 5a.m then you
>> check the availability from 3-4 and then from 4-5?And basically you create
>> record in the TechDataCalendarExcDay for every exceptionStartDate-in our
>> example 2 records? If this is the way - can you reserve for less then this
>> defined minimum reservation period? for example 30 minutes, 45 minutes etc?
>> I mean from 3 to 3.33 for example?
> No, the minimum reservation period is 15 minutes. 3 to 3.33 will be
> reserved from 3:00 to 3:45.
>
>> Or you have changed in a way order services?
> The price for the rental rooms is charged for every 15 minutes, so the
> quantity in an order is how many 15 minutes.

They charge in 15 minute increments? What kind of place is that? ;)

-David

I don't charge in quarters (I charge by hours) but I use a tool which records my work by quarters.

Jacques