Accrual Transfer Request

The self-service Accrual Transfer Request workflow offers employees the opportunity to request transfers of unused accruals — such as vacation, RTT, or overtime — into a designated time-savings account. This the workflow is designed to support France Compte Épargne Temps (CET) compliance requirements; yet it is fully configurable and can be adapted to meet global organization-specific or regional policies.

Note: This business process is an extension model that is developed outside the normal release schedule to meet specific customer needs. To request one of these models, you must submit a Salesforce Service Request to UKG. After the model is delivered to your tenant, you can edit it to meet your needs.

Administrators control eligibility through configurable decision table rules, allowing definition of parameters such as:

Allowed source and target accrual types
Annual, total, and rolling transfer limits
Employee age restrictions
Source accrual balance thresholds
Contribution windows

The workflow includes automated hours-to-days conversion logic, which leverages employee-specific daily hours. It supports full-day and half-day conversion rules while preserving any remaining balances.

Administrators can configure a multi-level approval process with up to five levels and a maximum of 20 reviewers per level. Eligibility is reevaluated at each approval step and after final approval to ensure compliance with defined rules.

Employees may cancel (retract) their own payout requests provided that the review process has not yet completed.

Additional configuration options include:

Audit tracking through reference paycodes and comments, providing visibility into rule evaluation outcomes
Automatic accrual balance updates upon request completion

How it works

An employee initiates the accrual transfer request.
The system validates the employee's eligibility based on the administrator-configured AccrualConfig Decision Table.
If eligible, the transfer request form opens from which the employee submits the request for review.
Comprehensive validation logic is applied, including checks for annual, total (lifetime), rolling limits, age criteria, and accrual-specific limits.
A request that meets validation criteria (fully or partially) triggers a multi-level approval workflow.
Eligibility is reevaluated at each approval step to ensure continued compliance.
Upon final approval, eligibility is reevaluated. If the request remains compliant, accrual balances are updated accordingly.
A reference paycode, along with a comment containing transfer audit details, is recorded in the employee's timecard.

Accrual conversion requirements

When transferring accruals between different unit types, the system applies the following conversion logic:

For transfers from hours-based accruals to day-based accruals:
- The system uses the employee’s Daily Working Hours, if available.
- If not available, the system defaults to the working hours defined in the AccrualConfig Decision Table.

Accrual transfer scenarios and unit compatibility rules

In the France CET implementation, the target accrual type is typically defined in days. However, to support global and flexible implementations, the system also allows hours-based accruals to be configured as the target through the AccrualConfig Decision Table.

The system supports the following transfer scenarios based on the unit types of the source (From) and target (To) accruals:

Hours → Days
- If a corresponding row exists in the Rule Validation Decision Table, all configured validation rules are applied to the transfer amount.
Days → Days
- If a corresponding row exists in the Rule Validation Decision Table, all configured validation rules are applied to the transfer amount.
Days → Hours
- If no row is configured in the Rule Validation Decision Table:
  - Half-day transfers are not allowed (default = No).
  - Only full-day transfers are permitted.
- If a row is configured:
  - Only the Half Day Rule is evaluated:
    - Yes → Half-day transfers are allowed
    - No → Only full-day transfers are allowed
Hours → Hours
- If no row is configured in the Rule Validation Decision Table:
  - Half-day transfers are not allowed (default = No).
  - Only full-day transfers are permitted.
- If a row is configured:
  - Only the Half Day Rule is evaluated:
    - Yes → Half-day transfers are allowed
    - No → Only full-day transfers are allowed

Note:

Full validation rules apply only to Days-based target scenarios (Hours → Days, Days → Days).
For Hours-based target scenarios, only the Half Day Rule is considered, regardless of other configured rules.
If no validation rule is defined, the system defaults to disallowing half-day transfers.

Hours-to-Days Conversion in CET

In CET, the Time Savings Account is maintained in days. When employees transfer from an hours-based accrual, the system automatically converts hours into their day equivalent using the following formula:

CET Days = Requested Hours ÷ Daily Working Hours

Important: This process:

Maintains CET consistency (day-based balances)
Prevents rounding errors
Eliminates the need for manual calculations by employees
Preserves any remaining balance in the source accrual

The following examples illustrate how overtime hours are converted into CET days under different scenarios:

Full-Day Conversion

Employee's daily working hours: 7
Overtime balance: 14 hours
Transfer request: 14 hours

Calculation:

14 ÷ 7 = 2 days

Result:

2.0 days are transferred to the Time Savings Account

Partial-Day Conversion (Half-Day Allowed)

Half Day Contribution Allowed: Yes
Employee's daily working hours: 7
Overtime balance: 20 hours
Transfer request: 20 hours

Calculation:

20 ÷ 7 = 2.857 days

Result:

2.5 days are transferred to the Time Savings Account
2.5 hours remain in the overtime balance

Partial-Day Conversion (Half-Day Not Allowed)

Half Day Contribution Allowed: No
Employee's daily working hours: 7
Overtime balance: 20 hours
Transfer request: 20 hours

Calculation:

20 ÷ 7 = 2.857 days

Result:

2 days are transferred to the Time Savings Account
6 hours remain in the overtime balance

Insufficient Balance Scenario

Employee's daily working hours: 8
Overtime balance: 7 hours
Transfer request: 10 hours

Result:

The request is rejected due to insufficient balance
The system displays an error message to the employee

Considerations and limitations

Money-type accrual codes are excluded by the process.
Required employee data must be assigned:
- Birthdate (required for Minimum Age validation, if applicable)
- Accrual Profile
- Approvers and reviewers (including Symbolic Purpose and Reviewer List)
- Daily working hours in Scheduler
Key benefits:
- Ensures compliance with configured rules and limits
- Prevents invalid or excess transfers
- Provides automatic adjustments to maximize allowable transfers
- Maintains transparency through clear system feedback and audit tracking
Summary of System Behavior:
- Requests with valid inputs and sufficient balance proceed through approval and are fully processed
- Requests with insufficient balance are blocked before submission
- Requests exceeding configured limits are automatically adjusted to allowable values

Before you start

Configure the following:

Accrual codes: Create both the From and To accrual codes (Hours and Day types) that should be available for transfer requests.

Only accrual codes that are configured with Allow Manual Edits will be visible and selectable in the transfer request form.

See the Accrual codes topic.
Accrual policies: Create accrual policies using the configured accrual codes, ensuring that all accrual codes intended for transfer are included in the policy — both the Transfer From and Transfer To accrual codes — so they are properly associated with the employee’s accrual profile and available for the transfer process.

See the Accrual policies topic.
Accrual profiles: Add the accrual policies to an accrual profile and assign the profile to the employee in People Information or the employment term.

See the Accrual profiles topic.

Caution: Any Accrual Policy that is used by the Accrual Transfer Request extension must be set as Visible in the Accrual Profile.
(Optional) Paycode: You can create paycodes that are added in the Timecard as reminders of the accrual transfer. Do not configure these paycodes as takings in the accrual policy; this ensures that these paycodes do not affect processing of accruals.
See the Paycode definition topic.
Comment: Configure a comment that the workflow adds to the paycode entry on the employee's Timecard. This comment includes the accrual transfer details (from/to accrual codes, transferred amount, request date, and any reviewer notes) so the transaction is fully auditable. Select the paycodes category during configuration.
See the Comments topic.
Symbolic purposes: create a Reviewer Override type symbolic purpose. People Information uses this purpose to link to the reviewers list.
See the Symbolic Purposes topic.
Reviewer lists: Create a reviewer list. Select Leave Administrator, Attendance Administrator, Manager, or a named user to act as the administrator.
See the Reviewer Lists topic.
Note:
- Configure no more than 5 review steps and no more than 20 reviewers at each step.
- Do not repeat the same reviewer on multiple steps.
- Assign the Reviewer List to the employee in People Information under Timekeeping > Approvals & Reviewers.
(Optional) Workflow notifications: Create generic workflow notifications that are sent to the manager and employee upon accrual transfer request and approval.
Select Recipient List will be supplied at runtime, Send to employee, and Do not suppress duplicates during configuration.
In Subject, Long Message , and Control Center Fields, the following tags can be used as placeholders to dynamically populate message details:
<status>, <message>, <employee>, <requestDate>, < fromAccrCode>, <toAccrCode>, <requestedAmount>, <amountType>, <eligibleAmount>, <amountInDays>, <userComment>.
See the Configure Notifications for Business Processes topic.
Note: Control Center notification mapping is not required for these workflow notifications, as they are sent as system messages. However, system messages must be enabled in the Control Center profiles assigned to employees and managers.

Notification Tags: Refer to the Tag Names table for the list of predefined notification tags that dynamically populate transfer-related details in workflow notifications and messages. Each tag displays based on the user's assigned locale policy.

Tag Names

Tag name	Description
<`employee>`	Employee full name and person number.
<`requestDate`>	Accrual transfer request date.
<`fromAccrCode`>	"From" accrual code.
<`toAccrCode`>	"To" accrual code.
<`requestedAmount`>	Accrual transfer requested amount.
<`eligibleAmount`>	Eligible amount of the accrual transfer.
<`amountInDays`>	"From" accrual code type.
<`userComment`>	Employee's request reason or comment.
<`status`>	Accrual transfer status. Potential values include: Approved — The request has been successfully approved. Refused — The request has been refused by a reviewer. Failed — The request was approved by a reviewer, but failed to complete successfully due to an error. Canceled — The request was canceled by the employee.
<`message`>	The message specific to the accrual transfer status. Potential values include: Approved requests — Displays the last reviewer's comment, or the default approval comment configured in the Locale table if no comment is provided. Refusal requests — Displays the last reviewer's refusal comment, or the default refusal comment configured in the Locale table if no comment is provided. Failed requests — Displays either the API error message or the validation error message configured in the Locale table. Canceled requests — Displays the person number and full name of the employee who canceled the request.

Deploy the Accrual Transfer Request business process model

Deploy the Business Process Model to install and make it available for use.

Note: The process for configuring and deploying this and other Business Process Extensions is the same as all Business Process models .

Migrate the Accrual Transfer Request process model to the customer tenant using Setup Data Manager (SDM).
1. Log in to the appropriate tenant.
2. Go to Main Menu > Administration > Setup Data Manager.
3. Select the Source tenant where the Process Model resides, and select the template to copy. It is a .zip file. A message appears in the Source column: Source: Import from <filename>.zip.
4. Click Tap Review and Publish. The Publish Summary panel appears.
5. Click Tap Review and Publish. The Publish Summary panel appears.
6. Review the Publish Summary panel. It lists the items that were extracted from the migration file. If you approve, click tap Publish with Comment or just Publish.
7. Click Tap Go to Publish History at the bottom of the panel to view the status of the data transfer. The Publish History page contains a table that lists the items you have published. If there were errors during the transfer, the button under the Errors column for that row is black.
8. To view details, click tap the appropriate row and click tap View Selected.
9. On the History for publish run page, click tap Show all to view the setup data that you published, and the errors that occurred, if any, listed by item type and name.
Deploy the business process model

Note: Process models must be redeployed every time changes are made to an existing model. Re-deployment is not required for decision table changes.

Follow these steps to deploy the process model. For detailed information, see the online help topic Deploy Business Process Models .
1. Go to Main Menu > Administration > Time application setup > Business Process setup > Process Models.
2. Select the AccrualTransferRequest_v1 process and click tap Deploy
3. On the Business Process page, configure the required parameters and deployment dates.
4. Select Hide for the Action List and GoTo List options.
  
  Caution: Do not make a selection from the Template Categories list.
5. Click Tap Save and Return to deploy.
6. Add the process model to the required process profile. See the Process Profiles setup page topic.
7. Assign the process profile to employees by way of People Information.

Configure the Accrual Transfer Request decision tables

Important: Process models must be redeployed every time changes are made to an existing model. Re-deployment is not required for decision table changes.

Caution:

Values entered in the decision tables are case-sensitive, and must match configured values in the application.
Do not remove variables, variable names, or variable types from any decision table.

From the Main Menu, go to Administration > Time application setup > Business Processes Setup > Process Models.
Click Tap Filter Columns, and then search for AccrualTransferRequest_v1 under Model Name.
Select the AccrualTransferRequest_v1 process and click tap Edit . The process model enters edit mode.
Select the Decision Tables tab.
Click Tap Everyone's, and then search for AccrualTransferRequest_v1. Select the decision table to edit.
Click Tap Decision Table Editor to add or update the rows in the table.
Click Tap Save and close.

Edit the following decision tables:

Note:

Decision tables support operators like "Contains," "Starts with," "Ends with," and "Is Not Empty." You can achieve your preferred results by following these examples:

To match any non-empty or any string (like *), use the "Is Not Empty" operator.
To match a string starting with "ABC" (like "ABC*"), use the "Starts with" operator and set the value to "ABC".
To match a string containing "English" as substring, use the "Contains" operator with the value "English".

AccrualTransferRequest_v1_Parameters — Controls the Accrual Transfer Request process.

Accrual Transfer Request — Parameter decision table structure

Parameter name	Description
SymbolicPurpose	Associates a Reviewer List with the payout business process.
EmployeeNotification	Name of the workflow notification sent to employees when the process completes. Note: Enter `None` or leave blank if employee notification is not required.
ReviewerNotification	Name of the workflow notification sent to reviewers when the process completes. Note: Enter `None` or leave blank if reviewer notification is not required.
IndicativePayCodeComment	Name of the comment attached to the IndicativePayCode.
IndicativePayCode	Name of the reference paycode that the process adds to the Timecard on the day of the accrual transfer.
ValidationYearStartDayMonth	Start date of the validation period. Caution: The value must adhere to the DD/MM format.

AccrualTransferRequest_v1_InternalParameters — Configuration variables for the workflow system. Default values are configured to optimize the performance of the workflow. This table is for internal use only; do not makes changes to the content.

Accrual Transfer Request — Internal Parameters decision table structure

Parameter name	Description
Admin	Internal user; do not change. Default value: `SERVICES-LEVEL3`
MaximumContributionPeriod	Internal Activiti variable that retrieves the maximum number of transfers allowed within a year; do not change. Default value: `6`

AccrualTransferRequest_v1_AccrualConfig — Contains parameters that support the initial validation performed when the employee initiates the accrual transfer request. The request form renders only when an employee meets eligibility criteria defined in the decision table.

Accrual Transfer Request — Accrual Config decision table structure

Parameter name	Description
#	For the same profile, if multiple contribution periods exist, increment the value by 1.
Employment Terms	Input parameter for the matching employment terms.
Pay Rule	Input parameter for the matching pay rule.
Accrual Profile	Input parameter for the matching accrual profile.
From Accrual Codes	A semicolon-separated list of accrual codes that display in the From selection list on the request form.
To Accrual Codes	A semicolon-separated list of accrual codes that display in the To selection list on the request form.
Default Working Hours	The number of hours used to convert hours into days when daily working hours are not assigned to the employee in People Information.
Contribution Start Date	Start date associated with the contribution period. Caution: The value must adhere to the DD/MM format.
Contribution End Date	End date associated with the contribution period. Caution: The value must adhere to the DD/MM format.

AccrualTransferRequest_v1_RuleValidations — Contains parameters that support full validation logic.

Important:

Rules and validations are optional; any rules not applicable to the process must be set to NA
If multiple rows are configured for the same target accrual, the validation values (Annual, Total, Minimum Age, and Rolling) must be identical across all rows, except for the From Accrual Codes.

Accrual Transfer Request — Rule Validations decision table structure

Parameter name	Description
Employment Terms	Input parameter for the matching employment terms.
Pay Rule	Input parameter for the matching pay rule.
Accrual Profile	Input parameter for the matching accrual profile.
From Accrual Codes	Accrual codes from which balances can be transferred.
To Accrual Codes	Accrual codes to which balances can be transferred.
Annual Contribution Limit	Maximum contribution that can be transferred to the To Accrual Codes balance during a validation year.
Total Contribution Limit	Maximum total lifetime contribution that can be transferred to the To Accrual Codes balance. The calculation is based on the employee's hire date.
Half Day Contribution Allowed	Determines whether half day adjustments are allowed. Supported values: `Yes` or `No`.
Minimum Age	Employee's eligibility age.
Rolling Validation Years	Defines the maximum number of years used in rolling validation calculations.
Rolling Validation Limit	Defines the To Accrual Codes grant transfer limit balance.
From Accrual Code Limit	Defines the maximum contribution during a validation day from From Accrual Codes.

AccrualTransferRequest_v1_Locale — Contains configurable labels and messages to support Accrual Transfer Request.

Accrual Transfer Request — Locale decision table structure

Parameter name	Description
Locale Parameter Name	Internal field label; do not change.
Locale Policy	Locale Policy. You can use an asterisk (`*`) as a wildcard, but put the less-restrictive locale policy names at the bottom of the table because the integration scans cross-reference tables from the top.
Locale Parameter Value	Text displayed in the workflow form or notification.

Parameter name

Description

Locale Parameter Name

Internal field label; do not change.

Locale Policy

Locale Policy.

You can use an asterisk (*) as a wildcard, but put the less-restrictive locale policy names at the bottom of the table because the integration scans cross-reference tables from the top.

Locale Parameter Value

Text displayed in the workflow form or notification.

Note:

Localization of business process workflows remains optional, but is supported.
You can translate some or all messages by adding lines to the table in their preferred translation for specific locales. Decision tables are scanned from top to bottom; therefore, place messages for the most commonly used Locale Policy at the top of the decision table and less-restrictive locale policies at the bottom.
Text within tags ("<>") must not be changed.
The decision table holds all messages represented with standard English labels; these apply to all locales when the Locale Policy is set to !=empty.
Names of the parameters in the decision table column Parameter Name must be used as is. If any parameter value needs to be localized for a different Locale Policy, copy the Parameter Name with the !=empty Locale Policy, add a new row to the decision table with the appropriate Locale Policy, and then add the localized value in the Message column.
Decision tables support operators like "Contains," "Starts with," "Ends with," and "Is Not Empty." You can achieve your preferred results by following these examples:
- To match any non-empty or any string (like *), use the "Is Not Empty" operator.
- To match a string starting with "ABC" (like "ABC*"), use the "Starts with" operator and set the value to "ABC".
- To match a string containing "English" as substring, use the "Contains" operator with the value "English".
The last row in the decision table must remain empty ("!=empty".)

AccrualTransferRequest_v1_Locale — Sample content

Locale Parameter Name	Locale Policy	Locale Parameter Value
Error_AgeLimit	!= empty	Not eligible for transfer due to age limit
Error_Age_Empty	!= empty	Birth Date is empty. Birth Date is required for CET transfer validation.
Error_AnnualLimitExceeded	!= empty	Not Eligible for transfer due to annual Limit Exceeded
Error_InvalidReviewerList	!= empty	Invalid Reviewer List
Error_MissingAccrualProfile	!= empty	Accrual Profile is missing
Error_NoReviewerListPurposeFoundInPeopleInfo	!= empty	No Reviewer List purpose found in people information
Error_RevieweListPurposeNotConfiguredInDT	!= empty	Reviewer List Purpose is not configured in Decision Table.
Error_RollingCETLimitExceeded	!= empty	Not eligible for transfer due to rolling year limit exceeded
Error_TotatCETLimitExceeded	!= empty	Not eligible for transfer due to total CET limit exceeded
ErrorMessage_NotEligible	!= empty	Currently there is no active campaign for your profile. Please contact your admin.
Label_Amount	!= empty	Amount
Label_Approve	!= empty	Approve
Label_Close	!= empty	Close
Label_Comment	!= empty	Comment
Label_CommentPlaceholder	!= empty	Type your comment here
Label_FormBack	!= empty	Go Back
Label_From	!= empty	From
Label_ManagerFormEmployee	!= empty	Please select an option-
Label_ManagerFormEmployee	!= empty	<`EmpFullName`> (<`EmpPersonNum`>)
Label_Next	!= empty	Next
Label_Refuse	!= empty	Refuse
Label_RequestFormHeader	!= empty	Accrual Transfer Request
Label_Reviewers	!= empty	Reviewer(s):
Label_Step	!= empty	Step
Label_Submit	!= empty	Submit
Label_Summary	!= empty	Request Summary
Label_To	!= empty	To

User experience

Accrual Transfer Workflow – End-to-End User Experience

The accrual transfer workflow enables employees to request the transfer of unused accruals while ensuring compliance through automated validations and a structured approval process.

1. Request Initiation (Employee)

An employee initiates an accrual transfer request from the Business Process tile.

The system performs initial eligibility checks, including:

Employment terms
Pay rule
Accrual profile
Contribution window validity
Eligible From and To accrual types

If the criteria are met, the transfer form is displayed with available accrual options.

The employee:

Selects the From and To accrual types
Enters the transfer amount
Provides supporting comments
Proceeds to the next step

2. Validation and Review (System)

The system evaluates the request against configured rules, including:

Annual and total (lifetime) contribution limits
Rolling validation limits
Minimum age requirements
Half-day contribution eligibility
Source accrual limits

If all validations are satisfied, the requested amount is accepted without adjustment.

The employee can review:

Request summary
Requested and allowed amounts
Assigned reviewers

3. Submission and Approval Workflow

Once submitted, the request is routed through the configured multi-level approval workflow.

During the approval process:

Reviewers evaluate the request and may approve or reject it with comments
The system reevaluates validation rules at each approval step
Notifications are sent to employees and reviewers after each action (configurable)

If any reviewer rejects the request:

The workflow ends
The employee receives a refusal notification

4. Final Approval and Processing

If the request receives final approval:

Eligibility is reevaluated. If the request remains compliant,
- The approved amount is deducted from the source accrual
- The amount is credited to the target accrual (for example, CET Time Savings Account)

5. Audit and Tracking

The system creates a reference paycode entry in the employee's timecard to record the transaction.

This entry provides a summary of the transfer, including:

Source and target accrual types
Requested and approved amounts
Converted amount (in days, if applicable)
Employee and reviewer comments

6. Status Tracking and Cancellation

The employee can monitor the request status throughout the approval process
The request can be retracted (canceled) at any time before final approval using the Control Center task

Accrual Transfer Workflow – All Scenarios

The accrual transfer workflow supports multiple outcomes based on validation results and available balances. The following scenarios illustrate how the system responds under different conditions.

Successful Transfer (Sufficient Balance)

When all eligibility and validation criteria are met, the requested amount is approved and processed.

Example:

Source accrual: Vacation Days
Requested amount: 2.0 days

Result:

The request is approved and routed for workflow approval
Upon final approval:
- The approved amount is deducted from the source accrual
- The amount is credited to the target accrual (CET Time Savings Account)
A reference paycode entry is created for audit purposes

Insufficient Balance

If the source accrual does not have enough balance, the system prevents the request from being submitted.

Example:

Source accrual (Overtime Hours): 7.0 hours
Target accrual (CET Time Savings Account): 55.5 days
Requested amount: 10.0 hours

Result:

The request is not allowed
The employee is notified of insufficient balance

Smart Adjustment

If the requested amount exceeds allowable limits (but sufficient balance exists), the system automatically adjusts the transfer to the maximum permitted amount.

Example:

Source accrual (Overtime Hours): 14.0 hours
Target accrual (CET Time Savings Account): 55.5 days
Requested amount: 14.0 hours
Daily working hours: 8

Result:

Allowed amount is adjusted to 12.0 hours (1.5 days)
Updated CET balance: 57.0 days
Remaining overtime balance: 2.0 hours

APIs

API details

Name	Resource path	Type	Description
Retrieve User Preferences for Current User	/v1/commons/user_preferences/locale_policy?userCurrent=true	GET	Returns user preferences to the current user or tenant. locale policies.
Retrieve User Preferences for Tenant	/v1/commons/user_preferences/locale_ policy?tenantDefault=true	GET	Returns user preferences to the current user or tenant.
Retrieve Employee Data	/v1/commons/data/multi_read	POST	Retrieves employee details.
Retrieve Employee Reviewers Data	/v1/commons/persons/extensions/multi_read	POST	Returns person records which includes reviewers list and symbolic purpose.
Retrieve Display Profile For Hours Format Handling	/v1/commons/display_profiles/<empDisplayProfileId>	GET	Returns the display preferences of employee for handling hour format.
Retrieve Tenant Accrual Codes	/v2/timekeeping/setup/accrual_codes	GET	Retrieves all the tenant accrual code in default and also in other languages.
Retrieve Accrual Summary/Transactions	/v1/timekeeping/timecard_metrics/multi_read	POST	Retrieves the Accrual summary which includes grants, balance, types and other details.
Retrieve Reviewer List Steps	/v1/commons/reviewer_lists?name="+encodeURI(reviewerListName)	GET	Retrieves reviewer list steps.
Retrieve Reviewers on each step	/v1/commons/reviewer_lists/reviewers/apply_read	POST	Retrieves all the reviewers present on each step.
Retrieve Comments	/v1/commons/comments	GET	Retrieves comments added to timecard.
Retrieve Paycodes	/v1/timekeeping/setup/pay_codes	GET	Retrieves paycodes and corresponding details.
Add Paycode Edits	/v1/timekeeping/timecard	POST	Adds the paycode with comments to the timesheet.
Retrieve Timecard paycode edits	/v1/timekeeping/timecard/multi_read	POST	Retrieves timecard paycode edits.
Updates Accrual Balances	/v1/timekeeping/accruals/updates	POST	Updates accrual balances.

Version history

Version	Description
1	Initial release.