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?