Clarity

Expand all | Collapse all

Timeslices - Update System time slice roll over interval

  • 1.  Timeslices - Update System time slice roll over interval

    Posted Aug 15, 2014 04:20 PM

    Hello Everyone,

     

    Has anyone tried to update the Roll Over interval on DAILYRESOURCEAVAIL time slice request. ( slice_request_id=1 ). If you have tried, what are the impacts ? Did it work consistently?

     

    Purpose of the request - To be able to set the time slice request roll over on weekends instead of a monthly (determined by from_date). So we are planning to set the From date to a Saturday , and update the Roll Over = Monthly to Weekly ( This is not possible currently in the UI ). Time periods is set to 730 and slice = Daily.

     

    Regards,

    AK



  • 2.  Re: Timeslices - Update System time slice roll over interval

    Posted Aug 16, 2014 08:34 PM

    Hi,

     

    Please check/update below stored procedures in clarity schema..

     

    prj_blb_rollover_assignment_sp

    prj_blb_rollover_team_hard_sp

    prj_blb_rollover_team_sp

    pej_blb_rollover_timeentry_sp

    prj_blb_slices......SP

     

    Please try altering above procedures in dev first..

     

    Regards,

    Deepak

     

     




  • 3.  Re: Timeslices - Update System time slice roll over interval

    Posted Aug 17, 2014 04:40 AM

    Just thinking aloud

    So that would do the rollover of that particular rollover 4 - 5 times a month instead of once.

    I guess that would be OK if it were off peak hours which is what you are after, and on coinciding with the rollover of other slices.

    Should something go wrong it is 4 -5 more likely to happen.

    You could try calculate how many slices are involved.

    http://www.nbl.fi/~nbl3674/Clarity/Slice_record_count_calculator_v12.1SP1.xls

    I'd also be concerned with the allocation slices which can have a high number of records.

    The daily availability is not really system but OiOTB and changing the definition is possible in the GUI in supported manner.

    People have been changing the number of periods all the time.

    Changing the rollover should just change what data is he available and when (inconsistent during slicing, but not a problem if it is off peak hours.) but otherwise it is business as usual.

     

    On the other hand....

    Clearing the expiry date will cause regeneration of the slices. Just wondering if manually or with a process setting it to a weekend date will will cause renegeration or just change the expiry date. If it just did the latter would that be an option or you.



  • 4.  Re: Timeslices - Update System time slice roll over interval

    Posted Aug 18, 2014 10:03 AM

    It's not possible to set the roll over period in the UI for DAILYRESOURCEAVAILCURVE

     

    Regards,

    AK



  • 5.  Re: Timeslices - Update System time slice roll over interval

    Posted Aug 21, 2014 12:30 PM

    Thanks for the Time slice record estimator excel. It's an excellent to guage time slicing data and helps in db sizing.

     

    Thanks,

    AK



  • 6.  Re: Timeslices - Update System time slice roll over interval

    Posted Aug 19, 2014 08:59 PM

    If I recall correctly (haven't done much slicing lately) -

     

    A rollover doesn't regenerate slices, but removes 'expired' slices and adds new ones to fill the range. Please don't quote me on that, you can do a test to see if records do get deleted and recreated - just watch the created date on prj_blb_slices.

     

    The Expiration Date can be set from the UI but the system resets it during rollover. This would mean that any manual intervention will have to occur every week to force the rollover to a date that you want.

     

    -Connie (as a time slice user)



  • 7.  Re: Timeslices - Update System time slice roll over interval

    Posted Aug 21, 2014 12:31 PM

    We don't want to reset the expiration date manually, instead modify the Roll over interval from monthly to weekly.

     

    Regards,

    AK



  • 8.  Re: Timeslices - Update System time slice roll over interval

    Posted Aug 21, 2014 04:03 PM

    Connie:

    "The Expiration Date can be set from the UI but the system resets it during rollover. This would mean that any manual intervention will have to occur every week to force the rollover to a date that you want."

    If you set the manually the expiry date will the result be the same as if you clear it and save the slice definition?



  • 9.  Re: Timeslices - Update System time slice roll over interval

    Posted Aug 21, 2014 04:34 PM

    The expiration date is set by the system. It sets it to the next time the roll over would happen

     

    NJ



  • 10.  Re: Timeslices - Update System time slice roll over interval

    Posted Aug 21, 2014 04:43 PM

    I am not disagreeing with that, but is a user editable field so if the user so wishes he or she can write there something -eg something that skips a rollover or two.

    Just wondering what will happen in such a case.

    Clearing the field the way to reset the definition and to force regeneration of the slice records for that definition.



  • 11.  Re: Timeslices - Update System time slice roll over interval

    Posted Aug 21, 2014 04:47 PM

    The system would override it, I guess

     

    You can check and let us know as well

     

    NJ



  • 12.  Re: Timeslices - Update System time slice roll over interval

    Posted Aug 21, 2014 05:59 PM

    Rollover interval = Monthly and it's disabled. What happens if that is changed to Weekly in the backend ? The purpose being to tell the system to slice on a weekend instead of a nth day of the month every month. nth day in a month could fall on any weekday and it becomes extremely troublesome if time slicing does not complete and runs into business hours. This is going to impact Report generation , interfaces depending on time slices and so on. I am also thinking a good idea would be introduce relative dates in time slice settings. For eg. First Saturday of the month.

     

    Thanks,

    AK



  • 13.  Re: Timeslices - Update System time slice roll over interval

    Posted Aug 21, 2014 07:43 PM

    So you're looking to do two things:

     

    to change the rollover interval from monthly to weekly

     

    to set the expiration date to be a weekend date - by default weekly rollover starts at 0 hour on Mondays

     

    #1 is 'use at your own risk', #2 is not a one time change (this should be tested and confirmed if you would like. take a test server, find a slice request, shrink the number of periods in the slice definition, set exp date to be tomorrow so that rollover will occur, check tomorrow what the new exp date is set to once rollover is done). When changing the rollover interval, you would also want to consider how much weekly rollovers the system is already doing so as not to over burden the system on Monday early mornings.

     

    I think the ability to set expiration date using a relative date is an awesome idea! And I don't see why you can't request for the interval to be open for edit. I'd vote for it if you enter the idea!!



  • 14.  Re: Timeslices - Update System time slice roll over interval

    Posted Aug 21, 2014 07:45 PM

    "find a slice request" -> i meant to say 'find a daily slice request'



  • 15.  Re: Timeslices - Update System time slice roll over interval

    Posted Aug 22, 2014 07:30 AM

    There are some practical examples at
    https://communities.ca.com/message/90177329#90177329

     

    Agreed that you cannot change the rollover period in the GUI which means there is no supported way of doing that.



  • 16.  Re: Timeslices - Update System time slice roll over interval

    Posted Aug 22, 2014 04:11 PM

    In v12.1.0.5840

    If you open the definition view of a timeslice

    - the expiry date is automatically cleared

    - a user entered valued is overwritten by the expiry value calculated by the system

    For weekly rollover the expiry date is seven days later from the current date

    For monthly rollover the expiry date is at the start of the next full slice period,

    that is

    if the slices start the 1st of the month then the expiry is the next 1st of a month

    if the slices start the 15th of the month then the expiry is the next 15th of a month

     

    - the rollover period is editable for custom slices but not for system slices

    - changing the rollover period in the database has the same effect as changing it in the GUI

    that is the slices do not change only the expirydate in the prj_blb_slicerequests table

     

    In v13.3.0286

    If you open the definition view of a timeslice

    - the expiry date is not automatically cleared

    - a user entered valued is overwritten by the expiry value calculated by the system

    For weekly rollover the expiry date is the next day

    For monthly rollover the expiry date is at the start of the next full slice period,

    that is

    if the slices start the 1st of the month then the expiry is the next 1st of a month

    if the slices start the 15th of the month then the expiry is the next 15th of a month

     

    - the rollover period is editable for custom slices but not for system slices

    - changing the rollover period in the database has the same effect as changing it in the GUI

    that is the slices do not change only the expirydate in the prj_blb_slicerequests table

     

    In both versions you can delete the custom timeslice definitions

     

    Just wondering if you are going to mess with the database would changing the value of the field is_system for dailyresourceavailcurve from 1 to 0 change the rollover period to editable in the GUI??

    Is that any less risky?



  • 17.  Re: Timeslices - Update System time slice roll over interval

    Posted Aug 22, 2014 04:42 PM

    You are right. is_system = 0 makes the Roll Over field editable in UI. It could be less risky now.

     

    Regards,

    AK



  • 18.  Re: Timeslices - Update System time slice roll over interval

    Posted Aug 24, 2014 04:36 PM

    Why don't you open a case with support and propose that. Then you'll expert opinions.