Skip to main content


         This documentation site is for previous versions. Visit our new documentation site for current releases.      
 

This content has been archived and is no longer being updated.

Links may not function; however, this content may be relevant to outdated versions of the product.

Best practices for defining calendars

Updated on August 30, 2019

Summary

An administrator asks:

Calendar instances (Data-Admin-Calendar) are defined with a two part key made up of Name and Starting Date.  In theory our system could have a single Calendar rule, which spans a number of years. 

Should we create a new calendar at the start of each year or just use a single version, or does it matter? What is the best practice and are there any hazards involved in either of the options?


 

Suggested Approach

The recommended practice is to define a new Data-Admin-Calendar instance for each year that a particular calendar name is valid.

Data-Admin-Calendar instances are associated with operator definitions, used primarily to establish a business calendar library that determines when operators are working.

In many applications , business day calculations may involve end dates of contracts, insurance or loan agreements, and other business materials, so creating calendar instances for future years is important. (If a calculation involves a future year but no calendar instance for that date is found, Process Commander assumes that that year has no holidays; all days are business days except Saturdays and Sundays.)

Data-Admin-Calendar supports calculations that involve your business calendar - for example, transfer of assignments among worklists and workbaskets based on how long they've remained at one list or another.

The ability to define calendar instances that span multiple years is a flexibility option. You could use it, for example, if particular circumstances required that a financial year span longer than a calendar year.

Have a question? Get answers now.

Visit the Support Center to ask questions, engage in discussions, share ideas, and help others.

Did you find this content helpful?

Want to help us improve this content?

We'd prefer it if you saw us at our best.

Pega.com is not optimized for Internet Explorer. For the optimal experience, please use:

Close Deprecation Notice
Contact us