The purpose of this document is to assist campus users with troubleshooting items that arise in AM.
Absence Request
In AM, approvers can submit a request on behalf of an employee. When that request is fully approved the employee will receive an email notification. If the employee reports that they did not submit the request and it should not have been approved, begin by identifying who submitted the request. This can be done by having the employee provide a screenshot of the approval in question by going to their Employee Self Service > CSU Time Tile > View Request
- If the request shows "Manager Absence Request" then their manager submitted the request on their behalf and confirming with the manager would be next steps.
- If the request does not show "Manager Absence Request", this indicates the employee submitted the absence.
This message normally appears because an absence already exists for those date(s). To verify the absence does exists, the appropriate administrator should complete the following steps:
- Navigate to the Absence Event page
- Navigation: Menu > Global Payroll & Absence Mgmt > Payee Data > Maintain Absences > Absence Event
- Enter the employees ID in the search section.
- Once the results appear, look for the date(s) the message indicated already existed.
- When the absence already submitted for the same date(s) has been located, communicate to the employee.
If an absence cannot be located for the same date(s), a ServiceNow ticket is required.
If any employee cannot find an absence that has been submitted, the appropriate administrator should complete the following steps:
- Navigate to the Absence Event page
- Navigation: Menu > Global Payroll & Absence Mgmt > Payee Data > Maintain Absences > Absence Event
- Enter the employees ID in the search section.
- Once the results appear, look for the date(s) the employee claims to have submitted the absence for.
- If the request cannot be located, the employee should submit again.
- If the request can be located, but has a has a blank workflow status, then select “-“ (minus) on the right-hand side of the identified row to delete and have the employee submit the absence again.
- If the request can be located and the workflow status is is populated, meet with the employee.
This can occur for various reasons, before submitting a ServiceNow ticket review the following:
Begin by reviewing the employees balance's for the request being submitted. If the employee does NOT have enough balance for the requested absence, this will explain why the Forecasting error occurred.
- Use the Results by Calendar Group page to review the employees balances
- Navigation: Menu > Global Payroll & Absence Mgmt > Absence and Payroll Processing
Use the Forecasting Message tab under Absence Event to determine if a message generated during the Forecasting process. If a Forecasting Message Error did occur then it could explain why the employee experienced issues.
Navigation: Menu > Global Payroll & Absence Mgmt > Payee Data > Maintain Absences > Absence Event > Forecast Messages
This can be determined by running a CSU_AM_RETROTRIGGERCHECK which uses the GP_RTO_TRGR - Retro Triggers table. If a retro trigger has been initiated and left unprocessed, a ServiceNow ticket will need to be submitted requesting for the retro trigger to be canceled.
Be very clear when submitting the ticket that a retro trigger needs to be canceled.
Absence Approval
There are occasions when an employee "submits" an absence request, that an error will occur resulting the request to have a blank workflow status on the Absence Event page. When this occurs, the appropriate administrator should select “-“ (minus) on the right-hand side of the identified row to delete.
Campuses do not need to monitor for absences having a blank workflow status on the Absence Event page. However, the query CHRS_AM_ABS_EVENT is available for campuses that would like to.
This issue can arise for several reasons. Before submitting a ServiceNow ticket, please confirm the following:
Confirm that the approver has
- AM Secuirty Roles
- Accurate Row Level Security
- Is the "Report To" for the employee who submitted the absence
Identify if the approver has other campus association using CSU ID Search. As Absence Management is using the PeopleSoft delivered AWE functionality which does not account for an employee or managers having multiple OPRID. The delivered functionality only looks for the OPRID with the lowest alpha numeric number which is causing the absence request to route to the managers account that has the OPRID with the lowest alpha numeric number.
If the approver does have other campus association, it is possible that the transaction routed incorrectly. Run the CSU_AM_ROUTE_WRONG_EMAIL query to confirm if the approver appears. If the approver appears, the workflow administrator can reroute the request to the correct OPRID.
Balance Details
Employees that work at multiple campuses, should have their State Service Sum appear calculated correctly. However in some cases, conversion is unable to successfully calculate the value. When this occurs, the conversion team will provide an audit indicating the multi-campus employees impacted to the converted campuses. The campuses already in production, will have to refer to the employees State Service Sum for the previous month, to determine if the incorrect amount is due to new campuses implementing.
The steps for campus to resolve, is to:
- Identify what the correct value is for the employee at the recently converted campus
- Identify the other campuses that employee is associated with using CSU ID Search
- Contact the other campus the employee is associated with and discuss the value that the employee should have with that campus
- Work together to make the adjustment for the employee
Various scenarios and circumstances can lead to inaccurate display of Excess +/- for an employee. Before submitting a ServiceNow ticket, please review the following to determine the appropriate next steps.
During conversion, an employee’s accruals will be carried forward. Often, it may appear that the employee’s balances—especially Excess +/-—are incorrect. However, this may not be the case, depending on factors such as when the employee was hired, whether they are shared, if a schedule modification occurred, or if transaction changes took place in Job Data. When reviewing the employee’s balances, those factors must be considered, along with the month your campus was converted and the calendar currently open in CHRS. For campuses recently converted into CHRS, balances should be reviewed once the calendar has been finalized in CHRS. After review, if the balance still appears inaccurate, a ServiceNow ticket should be submitted.
Employees who are hired, reassigned, or terminated mid-month may occasionally have their balances—especially Excess +/-—appear incorrect. This may be due to an AM calculation failing to initiate or a trigger not being created when the transaction was entered. Often, in these scenarios, a ServiceNow ticket is required once it has been determined that there is no issue with the employee's schedule, the campus is not recently converted, and no trigger can be found.
Start by reviewing the employee’s assigned schedule, paying particular attention to the following:
- Effective Day/Date - There is a common misconception that the date and day a schedule begins has no impact. However, this is inaccurate, as an incorrectly set schedule can cause employee balances—particularly Excess +/-—to appear incorrect. A schedule intended to begin on a specific day of the week must have a start date that aligns with that day. For example, if the schedule runs from Tuesday through Thursday, it must be set to begin on a Tuesday. Verify if the effective day/date is accurate based on when the schedule is intended to begin. If there is a conflict, the schedule will need to be adjusted, and a ServiceNow ticket will not be required.
- Duplicate Schedule- Often, when updating, creating, or assigning a schedule to an employee, it’s overlooked that one may already be set up. Review the employee’s schedule to ensure there are no multiple schedules within the same or overlapping date range, and that there are no conflicts between the Primary and Alternate Schedules. If conflicts are found, one or more schedules may need to be removed, and a ServiceNow ticket will not be required.
- Mid-Month Modification- An employee's schedule should generally be modified at the beginning of a new month or pay period. Although, in reality, this is not always possible and can occasionally lead to employee balances—especially Excess +/-—appearing incorrect. If this is the case, it may be necessary to determine whether the original schedule was modified or if a new schedule was created. Depending on the situation, further research may be required, as a retro trigger could be initiated by the change.
Identifying whether a retro trigger has been initiated or remains unprocessed can help clarify the cause of a balance discrepancy. This can be done by running a private query using the GP_RTO_TRGR - Retro Triggers table. If a retro trigger has been initiated and left unprocessed, a ServiceNow ticket will need to be submitted requesting for the retro trigger to be canceled.
In CHRS, one Personal Holiday is accrued annually at the employee level, regardless of the number of jobs held. Regardless of the number of active jobs held at the same or different campus, the employee will still only receive one Personal Holiday at the beginning of each year.
When the Personal Holiday balance appears inaccurate or an employee seems to have not accrued their Personal Holiday, it could be due to various circumstances. Before submitting a ServiceNow ticket, verify if any of the following circumstances apply.
- Conversion: During conversion, an employee’s accruals will be carried forward. Often, it may appear that the employee’s balances are incorrect. However, this may not be the case, depending on factors such as when the employee was hired, whether they are shared, if a retro trigger was created and if the employee already used Personal Holiday prior to conversion. When reviewing the employee’s balances, those factors must be considered, along with the month your campus was converted and the calendar currently open in CHRS. For campuses recently converted into CHRS, balances should be reviewed once the calendar has been finalized in CHRS. After review, if the balance still appears inaccurate, a ServiceNow ticket should be submitted.
- Usage: Verify that the employee has not already used their Personal Holiday balance for the year. The Personal Holiday balance resets at the beginning of each year and is maintained at the employee level. If they have, a ServiceNow ticket will not be necessary.
- Multi Campus: Identify if the employee has other campus association using CSU ID Search. If the employee is currently or recently active with another campus, it is possible that they used the Personal Holiday under that other campus. You may need to contact the other campus directly to confirm the usage. Depending on their response, a ServiceNow ticket may not be necessary.
Delegation
Job Aid: Pending
Unfortunately there is a known Oracle Bug with Delegations, that will remain in CHRS until all campuses are live and PUM updates can occur. To resolve, the appropriate administrator should complete the following steps:
- Navigate to the Administer Delegation page
- Navigation: Menu > Workforce Administration > Self Service Transactions > Approvals and Delegation > Administer Delegation
- In the Selection Criteria, enter the Proxys EMPL ID
- Press "search"
- In the results, toggle to the Request Details tab.
- Confirm the delegation request has a Delegation Status of "Inactive".
- If status appears as "active" then additional troubleshooting will be required as the delegation request has been already approved.
- Navigate to Monitor Approvals page
- Navigate: Menu > Enterprise Components > Approvals > Approvals > Monitor Approvals
- In the Search Criteria, select "Delegation" in the Approval Process field and enter the EMPL ID of the employee requesting the delegation in the Requester field.
- Press "search"
- Use the Search result filters to further refine the search scope and select the delegation approval request that is pending approval.
- A detailed screen will appear titled "Monitor Approvals"
- Review the information and press "Approve"
- Return to the Administer Delegation page
- Navigation: Menu > Workforce Administration > Self Service Transactions > Approvals and Delegation > Administer Delegation
- In the Selection Criteria, enter the Proxys EMPL ID
- Press "search"
- Review the results to confirm the delegation request has a Delegation Status of "Active"
On the Administer Delegation a Delegation Status of
- Inactive - means that the request has not previously been approved and is not currently an active delegation
- Active- means that the request has been approved and is currently an active delegation.
Notifications
This issue can arise for several reasons. Before submitting a ServiceNow ticket, please confirm the following:
On occasions the BUSN email, located in the User Profile, can be updated through integration between CS and CHRS. Unless the campus is continuously monitoring BUSN email updates through a private query, campuses have no knowledge of the update. Therefore, it is important to make sure the email in the User Profile is accurate for the employee receiving the email.
If the email BUSN email, located in the User Profile, is incorrect work with the correct campus administrator to make the correction in CS.
Navigation: Menu > PeopleTools > Security > User Profiles
Identify if the employee has other campus association using CSU ID Search. As Absence Management is using the PeopleSoft delivered AWE functionality which does not account for an employee having multiple OPRID. The delivered email functionality only looks for the BUSN email associated with the OPRID with the lowest alpha numeric number. This is occuring for employees and managers.
If the employee is associated with another campus, this may explain the misrouting of the email. The employee should simply be aware of how this functionality behaves in a shared environment.
This issue can arise for several reasons. Before submitting a ServiceNow ticket, please confirm the following:
On occasions the BUSN email, located in the User Profile, can be updated through integration between CS and CHRS. Unless the campus is continuously monitoring BUSN email updates through a private query, campuses have no knowledge of the update. Therefore, it is important to make sure the email in the User Profile is accurate for the employee receiving the email.
If the email BUSN email, located in the User Profile, is incorrect work with the correct campus administrator to make the correction in CS.
Navigation: Menu > PeopleTools > Security > User Profiles
In AM, the approval workflow is based on the 'Reports To' structure, with only one individual designated as the approver. If this structure is incorrect, it may result in communications being misrouted. To resolve this, start by reviewing the employees who should report to the approver that is not receiving the expected email communications. Verify that the position numbers have the correct 'Reports To' assignment and check for any recent changes to their position that may have affected the reporting structure.
If the 'Reports To' structure has been updated, collaborate with the appropriate campus administrator to review the changes and determine if any additional modifications are needed. A ServiceNow ticket is not required in this instance.
Identify if the employee has other campus association using CSU ID Search. As Absence Management is using the PeopleSoft delivered AWE functionality which does not account for an employee having multiple OPRID. The delivered email functionality only looks for the BUSN email associated with the OPRID with the lowest alpha numeric number. This is occuring for employees and managers.
If the employee does have other campus association, this will explain why the email is routing incorrectly. Run the CSU_AM_ROUTE_WRONG_EMAIL query to confirm if the approver appears. If the approver appears, the workflow administrator can reroute the request to the correct OPRID.
The email notification may be triggered for several reasons, including:
- NLT has already been submitted
- The approver for the request cannot be identified
- The employee that attempted to submit NTL is not eligible (i.e. Student Employee)
- A system error (e.g., timeout or connection issue) occurred during submission, and the employee will need to resubmit the NLT request, as it was not successfully recorded.
Upon receiving this email, begin by reviewing the details it provides. Next, confirm if the employee is associated with your campus. If they are, verify their eligibility, check if something has already been submitted, and ensure they have an active approver in Job Data. If the cause of the email cannot be identified, submit a ServiceNow ticket.
In AM, when an error occurs for NLT an email is generated to a group of users notifying them about the error. The email notification is based on the those who have role CHR_AM_NLT_Administrator. Remove the role from their User Profile to stop them from receiving the email communication.
Error Messages
Each month, CHRS Operations will email a listserv of campus users to notify them that an error has been identified which will prevent the calendar from being finalized. It is the responsibility of each campus to review and resolve the error. If the issue remains unresolved three days prior to calendar finalization, a High Priority ServiceNow ticket will be created and assigned to CMS. Refer to the error messages below to guide resolution efforts.
The calendar must be free of errors before it can be finalized. Failure by a campus to resolve issues in a timely manner may result in significant operational impacts.
These messages may differ based on the scenario, as they are only examples of what might appear. If the message you received is not listed, a ServiceNow ticket may be required.
Message Set and Number: 17005,470
Message Severity: Error
Meaning: In order to process the request the system needs to determine the payees Paygroup as of the absence event end date. According to the data in the job table the payee is not associated with any global payroll or absence management Paygroup prior to this date. Either enter a later date and try again, or review and update the job information for this payee as appropriate.
Next Steps: Before submitting a High Priority ServiceNow ticket related to calendar finalization, take a moment to confirm the accuracy of the employee’s Job Data and review any absences or potential NLT entries submitted for the month.
Message Set and Number: 17005,941
Message Severity: Error
Meaning: Eligibility Group could not be found. Segment is set in error without being processing Eligibility Groups are setup at the Pay Group level.
Next Steps: Before submitting a High Priority ServiceNow ticket related to calendar finalization, take a moment to confirm the accuracy of the employee’s Job Data and review any absences or potential NLT entries submitted for the month.
Message Set and Number: 17005,553
Message Severity: Error
Meaning: The Shift ID definition was not found. The Absence Take or Proration element was not resolved. Processing Proration and Absence Take elements often require work schedule information to be resolved.
Next Steps: Before submitting a High Priority ServiceNow ticket related to calendar finalization, take a moment to verify the employee’s schedule for multiple schedules set up within the same or similar date range, or any conflicts between the Primary and Alternate Schedules. If there are conflicts, one or more schedules may need to be removed, and a ServiceNow ticket will not be necessary.
Message Set and Number: 17005,942
Message Severity: Error
Meaning: Eligibility Group is not active within the time period of the segment. Segment is set in error without being processed Eligibility Groups are setup at the Pay Group level.
Next Steps: Before submitting a High Priority ServiceNow ticket related to calendar finalization, take a moment to confirm the accuracy of the employee’s Job Data and review any absences or potential NLT entries submitted for the month.
Message Set and Number: 17005,943
Message Severity: Error
Meaning: Element Group could not be found. Segment is set in error without being processing Element Groups are linked to an Eligibility Group. Eligibility Groups are setup at the Pay Group level.
Next Steps: Before submitting a High Priority ServiceNow ticket related to calendar finalization, take a moment to confirm the accuracy of the employee’s Job Data and review any absences or potential NLT entries submitted for the month.
Message Set and Number: 17005,951
Message Severity: Error
Meaning: The program could not find any information for the payee in the table(s) indicated by the message.
Next Steps: Before submitting a High Priority ServiceNow ticket related to calendar finalization, take a moment to verify the accuracy of the employee’s Job Data, review any absences or potential NLT entries submitted for the month, and confirm the employee’s schedule.
Message Set and Number: 17005,943
Message Severity: Error
Meaning: The return value of the partial formula assigned to a deduction is not in the valid range. The value must be greater than zero and less or equal to the current net without the calculated deduction. An invalid return value will lead to incorrect results when performing net pay validation.
Next Steps: Submit a High Priority ServiceNow ticket, noting that the request pertains to calendar finalization.
Message Set and Number: 17005,954
Message Severity: Error
Meaning: When Net Pay Validation by Priority is selected for a sub-process section a control formula is required for correct processing of priority order. Valid values are 0 (process in processing order), 1 (calculate), 2 (skip element) and 3 (perform net pay validation). Please either deselect Net Pay Validation by Priority flag from sub-process section or define a valid control formula on the country set up page for the country of the current pay run.
Next Steps: Submit a High Priority ServiceNow ticket, noting that the request pertains to calendar finalization.
Message Set and Number: 17005,956
Message Severity: Error
Meaning: The program could not find any information for the payee/job in the table indicated (effective as of date indicated).
Next Steps: Before submitting a High Priority ServiceNow ticket related to calendar finalization, take a moment to verify the accuracy of the employee’s Job Data, review any absences or potential NLT entries submitted for the month, and confirm the employee’s schedule.
Message Set and Number: 17005,147
Message Severity: Warning
Meaning: Multiple Retro Events exist with contradictory Retro Process Definitions Ids. To process retro, the Ids must be equal.
Next Steps: Before submitting a High Priority ServiceNow ticket related to calendar finalization, take a moment to check for any retro triggers. This can be done by running a private query using the GP_RTO_TRGR - Retro Triggers table. If a retro trigger has been initiated and left unprocessed, a ServiceNow ticket will need to be submitted requesting for the retro trigger to be canceled.
Message Set and Number: 17005,317
Message Severity: Warning
Meaning: The payee was active in the other Calendar Group when your run was initiated.
Next Steps: A High Priority ServiceNow ticket will be required, noting that assistance is required from CHRS Operations. As CHRS Operations must temporarily suspended from the Calendar Group identified. As soon as this calendar group is either Canceled or Finalized, the employee will be automatically re-activated in the other run upon executing the Calculate phase.
Message Set and Number: 17005,551
Message Severity: Warning
Meaning: No rows or not enough rows were found in the work schedule table to cover the entire processing period from the (earliest process date -1 day) to the (latest process date +1 day). The adjusted dates are required to resolve the day before and day after system elements related to work schedule.
Next Steps: Before submitting a High Priority ServiceNow ticket related to calendar finalization, take a moment to verify the employee’s schedule for multiple schedules set up within the same or similar date range, or any conflicts between the Primary and Alternate Schedules. If there are conflicts, one or more schedules may need to be removed, and a ServiceNow ticket will not be necessary.
Message Set and Number: 17005,552
Message Severity: Warning
Meaning: The Work Day Definition was not found and an Absence Take or Proration element could not be resolved . Processing of Proration and Absence Take elements often requires work schedule information to be resolved.
Next Steps: Before submitting a High Priority ServiceNow ticket related to calendar finalization, take a moment to verify the employee’s schedule for multiple schedules set up within the same or similar date range, or any conflicts between the Primary and Alternate Schedules. If there are conflicts, one or more schedules may need to be removed, and a ServiceNow ticket will not be necessary.
Message Set and Number: 17005,840
Message Severity: Warning
Meaning: A payee can only be open in one Calendar Group for a Country at any one point in time. The payee has been suspended from the current Calendar Group.
Next Steps: Submit a High Priority ServiceNow ticket, noting that the request pertains to calendar finalization.
Message Set and Number: 17005,907
Message Severity: Warning
Meaning: While searching to determine FTE code, the process was not able to locate a JOB data row matching the payment keys of the segment being processed. The rate code element was not resolved.
Next Steps: Before submitting a High Priority ServiceNow ticket related to calendar finalization, take a moment to confirm the accuracy of the employee’s Job Data and review any absences or potential NLT entries submitted for the month.
Message Set and Number: 17005, 952
Message Severity: Warning
Meaning: The program could not find any information for the payee/job in the table indicated (effective as of date indicated). A possible cause could be a retro change in hire date or Paygroup change.
Next Steps: Take a moment to confirm that the employee’s Job Data is correct and no Retro Triggers are preventing processing. Before submitting a High Priority ServiceNow ticket related to calendar finalization, take a moment to check the accuracy of the employee’s Job Data and review for any retro triggers. This can be done by running a private query using the GP_RTO_TRGR - Retro Triggers table. If a retro trigger has been initiated and left unprocessed, a ServiceNow ticket will need to be submitted requesting for the retro trigger to be canceled.
Message Set and Number: 17005, 1
Message Severity: Warning
Meaning: No Element Rule Definition was found for the element indicated (as of the date indicated). Please review the element and the parent element definition.
The message is an indication that the element is referred to within a period of time before the element was defined (or the element has never been defined). The most likely reason would be that an element has been removed or its EFFDT has been changed after it has already been referenced within a process list section or from another element. The parent element is provided when applicable to give more direction as to where this element is being referenced and where to trouble-shoot or correct the setup. Record refers to the database table where data was sought, but not found.
The following is a map of table names to element types:
GP_ABS_ENTL = Absence Entitlements,
GP_ABS_TAKE=Absence Take,
GP_ARRAY = Arrays,
GP_ARRAY_FLD = Array return columns,
GP_ARRAY_KEY = array look-up columns,
GP_BRACKET = Brackets,
GP_DATE=Dates,
GP_COUNT = Counts,
GP_PRORATION = Proration,
GP_ROUND_RULE=Rounding,
GP_ERN_DED=Earnings or Deductions,
GP_FORMULA=Formula,
GP_GCTL=Generation Control,
GP_HIST_RULE=Historical Rule,
GP_RATE_CODE=Rate Codes,
GP_FC_TBL=Fictitious Calculations,
GP_VARIABLE=Variables,
GP_WA_ARRAY=Writable Array
Next Steps: Submit a High Priority ServiceNow ticket, noting that the request pertains to calendar finalization.
Message Set and Number: 17005, 2
Message Severity: Error
Meaning: The PINT-DATA array of GPCUPINT.CBL contains an entry for every loaded element, entries are indexed and positioned based on PIN-number. Expand the array to fit elements with higher PIN numbers if necessary
The database has reached more than 300,000 elements (less certain number series reserved for PeopleSoft delivered system data and elements). The remedy is to expand the COBOL array defined in the GPCUPINT.CBL file. The number - as indicated by the message - may be different/higher if the file has previously been modified. See also message 3 for further information
Next Steps: Submit a High Priority ServiceNow ticket, noting that the request pertains to calendar finalization.
Message Set and Number: 17005, 3
Message Severity: Error
Meaning: Data volume exceeds the number of rows allocated for the COBOL array identified. Modify the COBOL storage definition to expand the size of the array.
To limit database access (and gain performance) a lot of data is stored in fixed size COBOL memory. Should there be more rows of data in the database than can fit in this array there is no way to dynamically expand the area nor resolve elements that are dependent on data not loaded. The message indicates the name of the array that has run out of room and in what COBOL file it is defined.
To rectify the problem the size of the array must be expanded and the number in the -COUNT or -LIMIT related to the array be updated accordingly. [By nature the memory requirement will vary from customer to customer. We have tried to define them to support everyone without making them so large that it impacts performance too adversely. Thus we must encourage that these be customized until we see the same array become a problem at multiple installations.]
Next Steps: Submit a High Priority ServiceNow ticket, noting that the request pertains to calendar finalization.
Errors that occur during the Forecasting process often generate a message explaining why the error occurred. Refer to the error messages below to guide resolution efforts.
These messages may differ based on the scenario, as they are only examples of what might appear. If the message you received is not listed, a ServiceNow ticket may be required.
Meaning: This message may indicate an issue with the employee's assigned schedule.
Next Steps: Review the employee’s schedule to confirm there are no multiple schedules set up within the same or similar date range, or any conflicts between the Primary and Alternate Schedules. If there are conflicts, one or more schedules may need to be removed, and a ServiceNow ticket will not be necessary.
Meaning: The Forecast Balance As of Date overlaps with an existing absence event. This creates an issue, as two events cannot occur for the same absence on the same day.
Next Steps: Determine what absences the employee has already submitted. If there is an overlap with an existing absence event, either the existing or new request may need to be adjusted, and a ServiceNow ticket will not be required.
Meaning: For each call to PTPSQLRT, there is the potential that an SQL-ERROR could occur for either the Select or the Fetch. This is set in the ZZ000-SQL-ERROR section. This requires system administrator intervention.
Next Steps: Submit a ServiceNow ticket, noting that who the employee is and what was being entered.
Meaning: There are no absence events for this employee. This is indicated if no rows are returned for a SELECT against GP_ABS_EVENT looking for the min (bgn_dt) and max (end_dt) (for non voided events only). This could happen if forecasting and only voided events exist. It wouldn’t happen if you forecast after creating or modifying an event.
Next Steps: Determine what absences the employee has already submitted, modified, or canceled. If there is an overlap with an existing absence event, either the existing or new request may need to be adjusted, and a ServiceNow ticket will not be required.
Meaning: The calendar detail corresponding to the calendars on the template are missing or the dates are missing. This is indicated by a SELECT on a join of GP_CALENDAR, GP_CAL_DTL and GP_CAL_PRD for the CAL_RUN_ID from the run control. This is a data setup issue that requires system administrator intervention.
Next Steps: Submit a ServiceNow ticket, noting that who the employee is and what was being entered.
End of Article
0 Comments
Add your comment