> ## Documentation Index
> Fetch the complete documentation index at: https://documentation.2cloudnine.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Lilly Pilly Release Notes

The Lilly Pilly ‘21 release for 2cloudnine Payroll delivers a number of exciting enhancements designed to
provide greater capability and efficiency in your workplace. Below is an outline of the new features and
updates that are included in the release.

### Pay Employee Leave in Advance

Functionality has been introduced to allow employees to be paid leave in advance. Where the leave period
is for one or more entire *Calendar Periods*, users and employees (via *Experience/Communities* ) will have
the option to indicate on a *Payee Leave Event* that the leave should be processed in full during the *Pay*
*Batch* for the *Calendar Period* directly prior to the leave commencing. If the leave period does not cover an
entire calendar period, it cannot be paid in advance. This is to ensure, in the case of other payments being
made within the same *Calendar Period*, all payments are calculated correctly. To cater for leave that
crosses over a whole *Calendar Period* and only covers part of the surrounding periods, users will need to
create separate *Payee Leave Events* for the portion(s) that only cover part *Calendar Periods* . The *Payee*
*Leave Events* for the portion covering the whole *Calendar Period(s)* can be paid in advance whereas the
part period can not.

This upgrade includes new validations on the *Payee Leave Event* record to ensure the correct setup is used
in preparation for payroll. Furthermore, the *Pay Batch Manager* has been updated to cater for the
payment of the leave in advance. This includes the introduction of new alerts to highlight to the users
where they are occurring.

### Configuration Requirement: Compulsory

**User Story Reference Number(s):** SC-31717 (SC-31716, SC-31718, SC-31719, SC-31720, SC-31837, SC-31838,
SC-31839, SC-31840, SC-31979, SC-32036, SC-32087)

### Indicate the Rate that Leave Will Be Paid

Improvements have been made to allow users to define the rate at which leave will be paid. Previously,
leave would automatically be paid at the standard pay rate of an employee. Now, users and employees (via
*Experience/Communities* ) will be able to indicate whether a *Payee Leave Event* is to be paid at half pay,
standard pay, or double pay. The type of rate available to be paid for each *Payee Leave Event* (half pay,
standard pay, or double pay) is controlled by settings available on its related *Leave Rule* record. By default,
the leave will continue to be paid at standard pay, unless specified otherwise.

This functionality also ensures that during the payroll *Pay Batch* finalisation process, the corresponding
leave deducted from an employee’s leave balance, as well as any leave accruals earned, will be calculated
correctly. Deductions from the employee’s leave will be completed based on the rate of pay used. That is,
half-pay will deduct the standard pay at a quantity of half of what was taken. Double pay will deduct the
standard pay at a quantity of double of what was taken. Accruals will continue to occur at the standard
rate.

**Configuration Requirement: Compulsory**

**User Story Reference Number(s):** SC-31649 (SC-31687, SC-31687, SC-31690, SC-31692, SC-31695, SC-31702,
SC-31703, SC-31708, SC-31709, SC-32086, SC-32088)

### Update Leave Functionality in Experience/Communities

The leave functionality available in employee *Experience/Communities* has been updated to provide an
improved user interface, functionality and controls which, in turn, will cater for a positive employee
experience when accessing their information. These enhancements include modifications to how leave
balances are shown, making it easier for employees to identify each type of leave that applies to them and
the current balance. Also, when applying for leave, the selection of which *Leave Rule* to apply against has
been simplified by improving the option labels held within the picklist. Likewise, the approvers will also be
able to see the *Leave Rule* name when reviewing submitted *Leave Requests* .
Further, to assist in the customisation of leave functions available to employees via
*Experience/Communities,* controls have been added within the *Experience/Communities Leave*
*Component* to allow system administrators to turn its sub-tabs on and off based on the organisation’s
requirements.

### Configuration Requirement: Optional

**User Story Reference Number(s):** SC-31432, SC31445, SC-32053

### Define Dual Leave Loading Interpretation Rules

Extensions to the *Timesheet Interpretation* capabilities have been introduced to support adherence with
modern award requirements that, when annual leave is paid, leave loading should be paid at the highest
rate calculated between ‘standard leave loading’ versus ‘shift loaded leave loading’. Now users can define,
at a *Leave Rule* and *Interpretation Rule* level, if the highest leave loading rate should be applied. If yes,
during *Timesheet Interpretation* the system will perform both calculations and produce *Pay Transactions*
for the option that has the highest total value.

**Configuration Requirement** : **Optional**

**User Story Reference Number(s):** SC-31984 (SC-31398, SC-32013)

### Apply For Time Off In Lieu Credit in Experience/Communities

Further to the above detailed leave updates in *Experience/Communities*, new functionality has been
introduced relating to time off in lieu. Now, in addition to submitting requests to take the various types of
leave, employees will also be able to submit requests for credit against time off in lieu. These credit
requests will go through the same submission, approval, rejection process as normal leave requests,
however, when approved and processed via payroll, they will add a credit to the employee’s time off in lieu
balance.

The facility for employees to submit time off in lieu requests is controlled by whether they have one or
more active *Payee Leave Rules* related to a time off in lieu *Leave Rule*, which specifies that employees can
apply for leave credits via *Experience/Communities* . Likewise, the ability for approvers to
view/approve/reject the submitted credit requests is controlled by the same leave rule field when related to
*Payee Leave Rules* where they are listed as an approver.

**Configuration Requirement: Optional**

**User Story Reference Number(s):** SC-31429

### Perform Streamlined Payee Exit Tasks

The *Payee Exit* feature has been improved to provide further capabilities relating to leave and the
calculation of leave payout values. Through the *Payee Exit Advanced Calculation Tool*, entries for annual
leave, leave loading and long service leave are automatically generated during the calculation process.
Users are then able to edit values ( *Quantity* and *Pay Rate* ) within the created records as needed.
Previously, where manual overrides are completed, if the user was to recalculate the exit values, the records
would regenerate and the overrides would effectively be reversed, resulting in the user needing to perform
the overrides again. Now, when a manual override is completed on these leave records when the
calculation button is clicked, the overridden values will be retained.

Further, the *Add Components* functionality within the *Payee Exit Advanced Calculation Tool* has been
extended to automatically populate a list of current *Payee Leave Rules*, excluding annual leave and long
service leave, that can be incorporated into the exit calculation for the user to select from. This will make
the process of identifying and adding exit components more streamlined which lower the likelihood of
components being missed in the exit calculation. General updates to the standard page layouts and the
*Payee Exit Tool* user interface layout have also been completed.

**Configuration Requirement: Optional**

**User Story Reference Number(s):** SC-22606 (SC-31712, SC-30308, SC-32152)

### Automate Payee Allowance Records and Assignment Rate Creation

A new feature to allow the automatic creation of *Payee Allowance Records* and *Assignment Rates* based
on details held in template records has been introduced. With this functionality, users will be able to create
*Payee Allowance Record* templates for both *Payroll Allowance* and *Timesheet Allowance* and/or
*Assignment Rate* templates for the *Timesheet* record type. These templates can then be grouped together
via template groups and assigned to any *Assignment(s)* . Once assigned, the system will automatically
create the required *Payee Allowance Records* and *Assignment Rates* based on the templates held within
the group.

Further, with *Timesheet Assignment Rates*, users will have options as to how the information that is
defined on the *Assignment Rates Template* is carried down to the *Assignment* level. When the
*Assignment Rates* are created for an *Assignment*, they can have all details, including the template defined
pay and invoice rates, copied down onto the new record(s) or they can exclude the template defined pay
and invoice rates. To exclude them, users will define a base pay and base invoice rate against the
*Assignment* and when *Assignment Rates* are created, these base rates coupled with information held on
the *Pay Codes*, will be used to populate the pay and invoice rates on each *Assignment Rate* record created.
This feature gives users the ability to use standard rates easily while also allowing the flexibility to provide
rates that are customised specifically to the *Assignment* where needed.

**Configuration Requirement** : **Optional**

**User Story Reference Number(s)** : SC-31374, SC-31618 (SC-30722, SC-31851, SC-31937, SC-31937, SC-32026,
SC-32028, SC-32081, SC-32136, SC-32138, SC-32141, SC-32156, SC-32158)

### Simplify Assignment Rate Sort Order and Expiry

To make the creation and maintenance of the *Assignment Rate* record more streamlined, new
enhancements have been introduced to enable the automatic population of fields. Now when a new
*Assignment Rate* is created, the *Sort Order* of the *Assignment Rate* will automatically be populated based
on the values held within the record. If there are no other records with the same *Assignment*, *Pay Code*,
*Project Code, Timesheet Activity* and *Auto Pay* combination, the *Sort Order* of 1 will be applied to the
*Assignment Rate* . If there are existing *Assignment Rates* with the same combination, the *Sort Order*
applied will be the next consecutive number. For example, if there is an existing record with the *Sort Order*
of 6, then the new record will have the sort order of 7. Where needed, the sort order applied can be
updated after the creation of the record.

To cater for the use of the same *Sort Order* value multiple times for a single *Assignment* (based on the
*Assignment*, *Pay Code*, *Project Code, Timesheet Activity* and *Auto Pay* combination) the previous
validation that prevented any duplicate values against an *Assignment* has been removed. Also, the existing
functionality to automatically expire *Assignment Rate* records that have the same combination as the new
record has been improved to cater for additional scenarios where an overlap on the start and expiry dates
could previously occur.

**Configuration Requirement:** Not Required

**User Story Reference Number(s)** : SC-31343 (SC-31942, SC-32070, SC-32147)

### Define and Use Minimum Pay Rates

Extending the above feature to automate the creation of *Payee Allowance Records* and *Assignment Rates*,
new *Minimum Pay Rates* functionality has been introduced to assist in the maintenance of payments
against Modern Award and Fair Work requirements. This functionality allows users to consolidate
information relating to *Award Classification* and *Levels, Pay Codes, Pay Rates and Interpretation Rules*
that apply for a specific time frame. These *Minimum Pay Rate* records can then be assigned to
*Assignment Rate Template Groups* and, via those, to the *Assignments* . Once allocated to an *Assignment*,
the system will use details held on the *Assignment* record to determine which of the templates within the
Template Group apply and then create the records needed.

Further, the annual update of *Minimum Pay Rates* has also been catered for. Now, when an increase is
required, users can create new template records for the new rates and assign them to the existing
*Template Group* . Once complete, an automated process will identify the *Assignments* that require
*Assignment Rate* updates, expire the old *Assignment Rates* and create new ones based on the new
*Minimum Pay Rates* . This functionality is intended for use when there are no invoicing requirements. The
*Assignment Rate* records created based on the *Minimum Pay Rates* will hold payment details only and will
not cater for the calculation of invoice rates. Where invoicing is required, the above-detailed *Assignment*
*Rate* template functionality should be used.

**Configuration Requirement** : **Optional**

**User Story Reference Number(s)** : SC-31374, SC-31618 (SC-31847, SC-31854, SC-31854, SC-32032, SC-32060,
SC-32078, SC-32079, SC-3217)

### Create and Allocate Work Schedules Efficiently

Managing schedules and rosters can be a complex and time-consuming process. With the introduction of
*Work Schedules* functionality, users will be provided with advanced tools to greatly assist in reducing the
workload normally involved in creating and applying *Work Schedules* for employees. With this new feature,
users will be able to easily identify and create shift patterns detailing essential information such as *Start*
*Time, End Times, Breaks* and *Total Hours* that will apply to a *Work Schedule* . These patterns can then be
automatically replicated for an extended period of time resulting in a *Work Schedule* that details all shifts
that will apply within a defined period.

The *Work Schedules*, once all shift details are correct, can then be easily allocated against one or more
*Assignment* records. Further, provided their time periods do not overlap, an *Assignment* can have multiple
*Work Schedules* applied to it. For ease in management over shift days and shift times, users will be able to
view, from the *Assignment*, all allocated *Work Schedules* and the individual shifts held within the schedule.

Note: This is a beta release of *Work Schedule* functionality and additional updates and improvements will
be included in the next release

**Configuration Requirement** : **Optional**

**User Story Reference Number(s):** SC-22924(SC-31296, SC-31302, SC-31537, SC-31538, SC-31539, SC-31540,
SC-31541, SC-31542, SC-31778, SC-31961, SC-32019, SC-32030, SC-32067, SC-32068, SC-32071, SC-32110)

### Apply Work Schedule Information to Payroll

Building on the functionality to effectively create and manage *Work Schedules*, existing payroll functions
have also been updated to extend this feature right through to payroll. Now, where a *Work Schedule* is
applied to an *Assignment*, key information held within the schedule will be used to enhance the payroll
experience. Employees that use *Timesheets* will benefit from the information held within their allocated
*Work Schedule* being carried forward to provide default values on their *Timesheets.* This change is aimed
at facilitating more accurate reporting of actual hours worked, while making the submission and approval
of *Timesheets* an improved and timely experience for both the employee and *Timesheet* approvers.
Further, a new *Auto Pay Type* has been introduced for those employees not using *Timesheets* . Users will
now have the additional option of calculating pay based on the scheduled hours. When applied during
payroll, this autopay function will take information held on the *Work Schedule* and generate *Pay*
*Transactions* based on the employee’s scheduled shift. Also, the auto pay functionality now has inbuilt
tools to handle when a scheduled shift falls on a public holiday. Where this occurs, depending on the shift
settings, the payment of the public holiday will automatically be transacted as either a paid day off or at
the working public holiday rate.

**Configuration Requirement** : **Optional**

**User Story Reference Number(s):** SC-22924 (SC-30740, SC-31904, SC-31905, SC-31906, SC-31907, SC-31909)

### Extend Minimum Rest or Break Loading Interpretation

Previously, when defining *Interpretation Rule Breakpoints* for *Minimum Rest* and *Break Loading*, users
were only able to define a single *Pay Code* that covered all the days including Sundays & Public Holidays
per *Breakpoint* . The *Interpretation Rule* and the corresponding *Timesheet Interpretation* logic has now
been improved to allow users to define multiple *Pay Codes* per *Breakpoint* . These include a default *Pay*
*Code* (the previously existing field) used for all days and an optional *Pay Code* field for Sundays and Public
Holidays. If the optional Sunday and Public Holiday fields are not populated, the default *Pay Code* will be
used for those days as well during interpretation.

**Configuration Requirement: Compulsory** This functionality is optional, however there are compulsory
configuration items required to ensure all the existing *Interpretation Rules* continue to function correctly,
regardless of if this new feature is utilised or not.

**User Story Reference Number(s):** SC-31683

### Utilise Daily Interpretation Rules for Partial Days

The *Daily Interpretation Rule* has been extended to include additional interpretation capabilities.
Previously, these rules only catered for day, or part thereof, interpretations, which meant if an employee
worked as little as one minute, they would be paid for the whole day. Now the functionality has been
extended to cater for partial days. Users will control, via the *Interpretation Builder*, if a *Daily Interpretation*
*Rule* will allow for partial day payments and, if so, have the ability to define *Breakpoint* parameters
including hour thresholds and limits, and the corresponding quantity that will be used during *Timesheet*
*Interpretation* . If the option to apply partial days is not taken, the default behaviour of paying the whole
day quantity will be applied.

**Configuration Requirement: Optional**

**User Story Reference Number(s):** SC-31984 (SC-22891)

### Pay Partial Allowances

Additional options for the payment of *Interpretation Rule* defined *Allowances* have been provided to cater
for the partial payment of *Allowance* amounts. Previously, the calculation of *Allowances* conducted via
*Timesheet Interpretation* was completed on a period (hours, days or frequency) or part thereof basis. This
meant if the employee worked part of a period, they were paid the whole allowance amount for the partial
period, not for only the portion completed. For example if the *Allowance* was an *Hourly Allowance* and the
employee worked 9.5 hours, the quantity paid would be 10. Now, a new option has been added to the
*Interpretation Rules* to define if a payment for the partial period should also be paid. This means for the
above example the employee would be paid a quantity of 9.5. If the option to apply partial quantity for
*Allowances* is not taken, the default behaviour of paying based on the period or part thereof will be
applied.

**Configuration Requirement: Optional**

**User Story Reference Number(s):** SC-31984 (SC- 31337)

### Provide Greater Detail on Pay Advice Documents

The existing *Pay Advice* functionality allows payees to receive their *Pay Advice* documents with their
line-by-line breakdown, grouped on a per *Assignment* basis. Now, where *Assignments* are using *Project*
*Codes* to differentiate projects/tasks, *Pay Advice* documents can be created with the details provided at a
*Project Code* level. This improved level of detail is enabled on the *Pay Schedule* and will allow payees to
more clearly determine which projects/tasks are included in their payments.

**Configuration Requirement: Optional**

**User Story Reference Number(s):** SC-23223 (SC-31841)

### Set a Custom Pay Advice Footer

A customisable footer on the ‘out of the box’ version of the *Pay Advice* PDF has been introduced to allow
more flexibility to tailor the look of *Pay Advice* documents to suit your organisation’s branding
requirements. The custom footer, which is defined at a *Pay Advice Template* level, can include a single line
of coloured text (specified by hex code) that is either left, center or right justified on the page. If the pay
advice falls over multiple pages, the footer will appear on the bottom of all pages.

**Configuration Requirement: Optional**

**User Story Reference Number(s):** SC-23223 (SC-31651)

### Define a Default Pay Advice Message

The existing functionality of including a message on the *Pay Advice* document has been extended to
include a new level of default messaging. Previously, default messages could only be defined at a *Payment*
*Entity* ( *Account* ) and at *Payee* level, with users being able to also enter a message through the *Pay Batch*
*Managers Create Pay Advice* page. Now, users can also define a default message at *Pay Advice Template*
level and it will be displayed for all new *Pay Advice* records generated, between any *Payment Entity* level
messages and *Payee* level messages.

**Configuration Requirement: Optional**

**User Story Reference Number(s):** SC-23223 (SC-31652)

### Mark Pay Advice Templates as Active or Inactive

A new feature has been added that will now allow users to make a *Pay Advice Template* active or inactive
so that a particular template can be excluded or included during the *Pay Advice* creation process. This
feature is enabled by adding a new *Available For Use* field on the *Pay Advice Template* record.

When new *Pay Advice* records are generated, only the *Pay Advice* templates that have an *Available for Use*
value as ‘ *Yes* ’ can be used unless it is specifically overridden on the *Payee* record. *Pay Advice* documents
generated prior to the *Pay Advice Template* being made unavailable will continue to be rendered using
the *Pay Advice* template that is applied at the time of creation. This will ensure that historic *Pay Advice*
PDFs remain unchanged.

**Configuration Requirement: Compulsory**

**User Story Reference Number(s):** SC-22136 (SC-31643)

### Consolidate Multiple Pay Advice Amounts in a Payment File

Within a *Pay Batch,* there may be scenarios where a *Payee* has multiple *Pay Advice* records. Currently,
when the *Payment File* associated with the *Pay Batch* is generated, the payments are determined on a
per *Pay Advice* basis. This means that, when there is more than one *Pay Advice* for the same employee
within a *Pay Batch*, they would receive multiple payments for each *Payment* detail record they have
active. The advantage of this approach is that it ensures the payments received can easily be reconciled
against each individual *Pay Advice* record. There are however instances where the higher number of
payments is not ideal for the *Payee* . To cater for these scenarios, new functionality has been introduced to
allow for *Payment Files* to be consolidated so that, if there are multiple payments to the same
*Payee/Payment Details* combination, they can be combined into one single payment on the *Payment File* .

The default behaviour will continue to separate the payments on a per *Pay Advice* basis. Should the ability
to consolidate the payments be required, it needs to be defined on the *Payee* record. Depending on the
settings of the *Payees* included within the *Payment File*, there may be a mix of combined and separated
payments within the same file.

**Configuration Requirement: Compulsory**

**User Story Reference Number(s):** SC-23225 (SC-31263)

### Automatically Assign Defined Permission Sets to Experience/Community Users

In the previous release (v1.84), a new feature that automatically created *Experience/Community* users was
introduced to expedite the process of setting up new employees. The functionality has been extended to
not only create the *Experience/Community* user but also to automatically assign any required *Permission*
*Sets* to the user record.

System administrators will be able to define one or more *Permission Sets* to be automatically assigned
based on the new user’s *profile* . Furthermore, if an existing user is updated, and new *Permission Sets* have
been defined for that *Profile*, the additional *Permission Sets* will be allocated to the user while still
maintaining their existing *Permission Set* assignments.

**Configuration Requirement: Conditionally Compulsory** Overall this item is optional, however, it is
required when the previously introduced functionality to auto-create *Experience/Community* users is in
use.

**User Story Reference Number(s):** SC-29328

### Customise Invoice Grouping

The existing functionality of generating Invoices provides multiple standard options for grouping *Pay*
*Transaction* information into *Invoices* . This *Invoice Group By* feature has been extended to provide even
more flexibility with the *Invoice* grouping. Now, users can populate a *Custom Invoice Group By Id* field on
the *Assignment* which will then automatically copy down to any *Pay Transactions* created. When the field
on the *Pay Transaction* is populated, and the *Invoice Group By* option on the related *Client* is set to
‘ *Custom Group By ID* ’, it will override the system generated *Invoice Group By ID* when generating *Invoices* .
Where this option is not undertaken, the existing system-generated *Invoice Group By ID* will be used.

Further, to provide even more customisation options, system administrators will be able to set up
automation (custom workflows/process builders etc) to populate the *Invoice Group By ID* directly onto the
*Pay Transaction*, bypassing the field on the *Assignment* . This will allow for scenarios where the *Invoice*
*Group By ID* needs to be different for individual transactions under the same *Assignment* .

**Configuration Requirement: Optional**

**User Story Reference Number(s):** SC-30723

### Include Expense Receipts/Evidence as Attachments with Invoice Emails

**Configuration Requirement** : **Optional**

**User Story Reference Number(s):** SC-31563

### Make ‘Funding Requirement' Mandatory

A greater level of control over the filters used within the *Pay Batch Manager* to generate *Pay Batches* has
been introduced. Now, system administrators can define if the existing, optional *Funding Requirement*
field is made compulsory. When this organisation-wide custom setting is enabled, users will not be able to
proceed past the filter page and generate *Pay Batches* without first selecting a *Funding Requirement* to
filter the records by.

**Configuration Requirement: Optional**

**User Story Reference Number(s):** SC-31546

### Setup Self Managed Super Funds Via Experience/Communities

Previously the setup and maintenance of *Superannuation Fund Payee Withholding* via
*Experience/Communities* were limited to where the *Superannuation Fund* record to be applied already
exists. This meant that employees could not define payments to *Self Managed Superannuation Funds*
without first organising externally for the fund details to be added by a payroll user. Functionality has been
introduced to allow employees to set up a *Superannuation Fund* record for their *Self Managed*
*Superannuation Fund* and then apply that fund to their required *Payee Withholding* records.

This functionality carries the same validation of *Superannuation Fund* information as is used for internal
users to ensure fund information collected is compliant with SuperStream requirements.

**Configuration Requirement:** Not Required

**User Story Reference Number(s):** SC-31715

### Updated Format of SAFF File Extracts for Superannuation Lodgement <Badge color="green">New</Badge>

The SAFF file format for extracting SuperStream compliant data has been updated to meet the standard
ATO approved format. This is a critical update and System Administrators must ensure that the 2cloudnine
Payroll Australia Extension package is updated as only the files that adhere to the required format will be
accepted during the SuperStream upload process.

**Configuration Requirement: Conditionally Compulsory** (Employers who extract data using SAFF Format
when using 2cloudnine Payroll Australia SuperStream functionality must have the 2cloudnine Payroll
Australia Extension package updated)

**User Story Reference Number(s):** SC-32229\_**Adhere to SuperStream Requirements**\_

To ensure that all the required data is collected for future processing activities, including Superstream
compliance, validation has been added to the *Payee Withholding* rule object to make the *Superannuation*
*Fund* field mandatory. Now, on the creation and update of all *Payee Withholding* records, with the record
type of *AU Super*, the field must be populated.

**Configuration Requirement: Compulsory**

**User Story Reference Number(s):** SC-31933

### Filter Timesheets on the Approver Community

Timesheet approvers can be responsible for the approval of a high number of *Timesheets* . Within
*Experience/Communities*, this means that the list of *Timesheets* on the *Timesheet* submitted, approved,
rejected tabs can become excessively long. To assist approvers to refine these lists to only show those they
are currently actioning/reviewing, new functionality has been added to allow them to filter the *Timesheets*
listed based on a date range. When used, only *Timesheets* that have *Timesheet* entries that fall within the
range (inclusive) will be listed.

**Configuration Requirement:** Not Required

**User Story Reference Number(s):** SC-31790

### Customise Experience/Communities Terminology <Badge color="green">Update</Badge>

In some instances, the terminology used within the standard *Experience/Communities* components will
not match those used within an organisation. To allow for an *Experience/Communities* setup that can be
aligned to any businesses needs, including the use of various languages and different terms/expressions,
functionality has been introduced to provide for a higher level of customisation. All previously hardcoded
labels and messages have been updated to be held within *Custom Labels* which, when required, will allow
the use of the Salesforce translation tools to override the standard text.

These updates apply to both the employee and approver *Experience/Communities*, with the same
overrides applied to both.

**Configuration Requirement: Optional**

**User Story Reference Number(s):** SC-31715

### Minor Updates

Minor updates in the following areas have also been provided. There are no configuration requirements for
any of these items which will become available on installation of the package.

* **Improvements to Payment Details validations**
  User Story Reference Number(s): SC-30837 (CI-216779)

* **Refinement of Timesheet Interpretation logic**
  User Story Reference Number(s): SC-31984 (SC-31740, SC-31935, SC-31986, SC-31987, SC-32005,
  SC-32112, SC-31680)

* **Streamline Invoice deletion record updates**
  User Story Reference Number(s): SC-31253

* **Enhancements to Invoice Creation User interface**
  User Story Reference Number(s): SC-31691

* **Refinement of the Assignment automatic field population logic**
  User Story Reference Number(s): SC-31452

* **Addition of optional Lookup filtering on Assignment Rate fields**
  User Story Reference Number(s): SC-32051

* **Enhancements to the Timesheet Manager user interface**
  User Story Reference Number(s): SC-31808

* **Improvements to Overnight Time Entry validations**
  User Story Reference Number(s): SC-31834

* **Enhancements to Interpretation Builder user interface**
  User Story Reference Number(s): SC-31984 (SC-31648, SC-31680, SC-31617), SC-31914

* **General updates to override validations functionality**
  User Story Reference Number(s): SC-31730

* **Upgrade to Pay Batch Manager warning and alerts**
  User Story Reference Number(s): SC-31646

* **Updates to Timesheet and Leave Reminder/Notification Tools**
  User Story Reference Number(s): SC-32127, SC-31697

* **Improvements to Leave Calculations logic**
  User Story Reference Number(s): SC-22132 (SC-31826), SC-31918 (SC32107, SC-32106)

* **Additions to Create Pay Batch logic**
  User Story Reference Number(s): SC-32065

* **Improvements to Experience/Communities Timesheet Submission**
  User Story Reference Number(s): SC-30960

* **Improvements to Experience/Communities Expense Claim Submission and Approval functionality**
  User Story Reference Number(s): SC-30960, SC-31530

* **Improvements to Experience/Communities Leave Submission and Approval functionality**
  User Story Reference Number(s): SC-30960

* **Provision of Required Experience/Communities Permission Set**

### Updates

User Story Reference Number(s): SC-31923, CI-217109

* **Improvements to Base General Ledger Integration** <Badge color="green">Update</Badge>

User Story Reference Number(s): SC-32186, SC-32084, SC-32237

* **General Code optimisation to improve overall system performance** <Badge color="green">Update</Badge>

User Story Reference Number(s): CI-217109, SC-31943, SC-31538, SC-32107, SC-32281, SC-32282,
SC-31611, SC-32233

<Tip>
  Take advantage of these new features and improvements now. Talk to your Partner Provider or System Administrator about upgrading so you can experience the benefits of the Lilly Pilly ‘21 Release for yourself.
</Tip>

Refer to the **Upgrade Guide for the Lilly Pilly ‘21 Release** for further information on installation
requirements including pre and post-installation checklists, installation links and configuration
instructions.