\\ 



 \\ 



Personality 5.05
Key Differences\\ 



\\ 



\\ 



__Overview__\\ 



Personality Version 5.05 was built on the base
functionality of Personality 5.04 to add features that support new forms and
technologies. Version 5.05 continues to be available with __2__ user interfaces: Browser and
Administrative/Professional (java swing), however, the sizing was removed from
forms. This ensures that they show better in the browser but they __may not show as well in the Admin UI__. \\ 



This update brings Multi-Tenancy to Personality.
Multi-Tenancy will be based on site records. The new HRIS version made
available by NEOGOV also is multi-tenancy.\\ 



Additional new functions in 5.05 merge and simplify
some Payroll processes.\\ 



Other changes include additional screens, reports
and functionalities, and many, many bug fixes.\\ 



5.05 marks the end of High Line putting out “Full”
releases. Future releases will be based off of Personality 5.05 as small
updates are needed.\\ 



Below are highlights of changes between versions
5.04 and 5.05.\\ 



__Multi-Tenancy Database__\\ 



5.05 introduces Multi-Tenant architecture to the
database.  This architecture is like an apartment building. All clients
share the front gate, the parking garage, the security, and the pool. Each
client still has their own private apartment, which is where all your data is
securely stored and made unavailable to anyone except you. This means no other
client can access your data.\\ 



Why is this change in architecture important? This
architecture allows us to provide all clients with stronger security measures,
improved hardware for performance, and a code base to share product and
functionality improvements easily with all clients at the same time. It also
gives clients an easier transition from Personality to the HRIS platform.\\ 



If you are currently an on-premise client or pay to
be a hosted Single Tenant, __this
change still affects you!__ Database updates and system configuration,
including necessary changes to site codes and forms, should be in place before
upgrading to Personality 5.05. You may continue to be a Single Tenant even
though the new architecture makes it possible for you to become Multi-Tenant.\\ 



Site Reference
Column\\ 



All Personality tables now have a SITE_REFERENCE_ID
column added to them. This is required to enable the Multi-Tenant database
structure. The values required for this column are populated automatically as
part of the upgrade to version 5.05. Once active in 5.05, this column is
updated each time a new record is added to the database. In the new
multi-tenant database, users are limited to the SITE_REFERENCE_ID associated
with their user login. This is referenced as the “Tenant” code. The “Tenant”
code is the “Site Reference” code seen on IMST.\\ 



New Lexicons\\ 



There are two new fixed lexicons included in the
5.05 release.  The lexicons X_TABLES_NO_SITE and X_TABLES_PARTIAL_SITE
identify the tables that are exceptions to the population of the
SITE_REFERENCE_ID. \\ 



Both lexicons list tables defined by preloaded
values. These are typically provided in seed data that are not subject to
change.\\ 



Tables not listed in either of these lexicons must
have a reference to a tenant site and can be viewed and modified only by that
tenant.\\ 



__Note - These lexicons
are both fixed and should [[not be changed by Users.__\\ |]



__X_TABLES_NO_SITE __\\ 



This lexicon lists tables with records that can [[__never__ be updated or customized by a
client.  These are generic values, which are the same for every tenant,
and tenant-specific records will never exist for these tables. \\ |]



For example: States and Provinces do not change by
tenant. These records will never contain a reference to the tenant-specific
site code but will instead have 'No Site'.\\ 



__X_TABLES_PARTIAL_SITE  __\\ 



This lexicon lists the tables in which clients are
allowed to add new, tenant-specific records to customize their experience.\\ 



 \\ 



Since some records will have the site ID populated
and others may not have a site reference, these tables remain ‘Partial Site’.\\ 



 \\ 



For example, Functions (IMFN) - every tenant has
access to the forms that are provided while still having the option to create
their own functions & forms for their users.  \\ 



The “Pre-Loaded” (supplied) function does not
contain a reference to any specific tenant sites.\\ 



Any “User Defined” new records (User Created) will
have a reference to the tenant site which created it. \\ 



New Database
Function\\ 



To ensure the SITE_REFERENCE_ID column is populated
correctly, on all INSERT triggers, the P2K_SESSION.DETERMINE_SITE function will
pull from the values documented in the lexicons above if the site is NULL. The
value inserted into the SITE_REFERNCE_ID will not be changed on any subsequent
updates to the record.\\ 



 \\ 



Before going through the upgrade, review the value
of your current Site Code (IMST) as this will have an impact on some DB user
names and roles (see section “New Admin Users”). We recommend keeping the site
code short if you’re still using the Admin User Interface. Site records on IMST
will be set up for the Base site and the Master site.\\ 



Changes to Forms
(IMFDH)\\ 



The IMFDH screen is one of the key places where
users may notice changes in the multi-tenant environment.\\ 



In the new multi-tenant set-up, users are not able
to make any changes to preloaded data, including form definitions, unless
logged in as a MASTER (Admin UI) user.\\ 



Preloaded screens will still allow the addition of
fields as long as they are “User Defined”. Any preloaded aspect of the form
will no longer be modifiable. It has always been a best practice to not alter
the default set up of a form. In Personality 5.05, this practice is not just
best practice; it is now a requirement.\\ 



User Profile
Changes (IMUS)\\ 



There are several changes to the ADMIN user roles
in 5.05. The P2K user profile should no longer be used within the Admin or
Browser User Interface. The P2K user profile has been replaced by MASTER and
MASTER_[[SITE_CODE] user profiles. The P2K_USER role, as defined on IMRO, is
still a requirement for all users and should be included in all user profile
setups, including these new administrator profiles.\\ 



__P2K User Profile__\\ 



The P2K user profile should no longer be used to
log into the application in the Admin User Interface. \\ 



The P2K user profile will not have access to any
data and should be treated as a “Schema” only.   If you sign in as P2K,
the system will appear to be __empty__.  \\




The P2K user profile user is replaced with the
MASTER_(SITE_CODE) user profile. \\ 



The P2K user profile can still be used to see
everything at the Database level. \\ 



Symmetry is site independent with installation and
the owner is still under the P2K schema.\\ 



__MASTER User Profile__\\ 



The MASTER user profile is used to access and
modify global data. In the SAAS model, this user is [[not accessible to end
users. In the non-SAAS model, MASTER is added to every database.  \\ |]



Custom integrations, links, ODBC connections, etc.
that currently use P2K need to be changed to the Master user of the base site.
The P2K user profile can be used to access data at the DB level and the MASTER
user profile should [[__not__ be
used.\\ |]



Preloaded items cannot be changed from any sites
except the MASTER. While MASTER can modify forms, it is [[__not__ the recommended
practice.  \\ |]



When logged into the Admin User Interface, the
MASTER user profile is not able to access any employee data. A new entity was
created named ADMINISTRATION. This entity and all its related data are visible
to the MASTER user alone. This entity is hidden from all other user types
logging into the environment.\\ 



The SITE CODE for the MASTER user profile on IMST
is MASTER.\\ 



 \\ 



When accessing the Browser UI, the MASTER user
profile is associated with an identity record on IEID called “Super
User.” \\ 



The Access Code used to log into the BROWSER UI on
IEID is ADMIN_MASTER.  \\ 



The User Profile associated with this identity
record is MASTER\\ 



__MASTER_[[SITE_CODE] User
Profile__\\ 



While the MASTER user profile controls the records
that are global in nature, a site-specific admin user is also required. The
MASTER_[[SITE_CODE] user profile now replaces the P2K user profile when
accessing the User Interface. \\ 



 \\ 



In this document [[SITE_CODE] represents the value
found in the SITE_CODE column found on IMST.\\ 



After the database is loaded and prior to
installation of the 5.05 software, please update the site code (IMST) to make
the code meaningful and to [[__not__ have spaces or dots. Once the 5.05 software is loaded, the
master admin and self-service users are created using the site
code.  \\
|]



P2K preferences and logics (i.e. Setting
preferences on forms, Establishing Report Parameters, Publishing Usercalcs,
etc) will be transferred to the MASTER_(SITE_CODE) user profile.\\ 



Preferences that are noted as Global should be established
using the new MASTER_(SITE_CODE) profile.\\ 



Note - To avoid any conflicts, all scheduled jobs
should be canceled before any major upgrades and then rescheduled after. \\




The username to log into the Admin User Interface
is the MASTER_[[SITE_CODE] from IMST\\ 



For example: the site code in our test environment
is TRAIN, therefore the sign-in user is MASTER_TRAIN.\\ 



After completing the upgrade process, users may
initially log in with the password “p2k”. It is highly recommended that clients
change their password as soon as possible.\\ 



Site data is only visible to a user logged into
that site. \\ 



When accessing the Browser User Interface, the
MASTER_[[SITE_CODE] user profile is associated with an identity record on IEID
called “Super User1”. The number in the name of the user increases with each
new tenant record (User1, User2, User3, etc.). Most clients are not expected to
have more than one tenant record. \\ 



The Access Code used to log into the BROWSER user
interface on IEID is ADMIN_MASTER_[[SITE_CODE].  \\ 



This identity record’s user profile is
MASTER_[[SITE_CODE].\\ 



__Payroll Process Smoothing__\\ 



UPPAY - Payroll
Batch Audit and Pay Calculation Report \\ 



UPPAY is a new function that allows payroll users
to do both the audit and calculation of pays using one function. This merges
UPAUDT ‘Payroll Batch Audit Report’ and UPCALC ‘Pay Calculation Report’. The
new function does the UPAUDT for selected Payroll and Batches and if batches
are balanced and audited, then it automatically runs UPCALC. If there is a
correction that requires UPUNDO ‘Undo a Pay Run’ and brings at least one pay
header to a ‘To Be Audited’ stage, UPPAY can be run again after the UPUNDO is complete.
UPPAY uses single thread processing.\\ 



UPCLOSEPAY - Close
and Disburse Pay \\ 



UPCLOSEPAY is a new function that allows payroll
users to close the pay runs and disburse them using one function. This merges
the UPCLOZ ‘Close a Pay Run’ and UPDISB ‘Disburse Pay’ for pay runs. The
function does the UPCLOZ for the selected payroll and pay runs and then UPDISB
for the same payroll and pay runs. If there is a correction that requires
UPUNDISB ‘Undisburse a Payrun’. run UPDISB after the UPUNDISB.\\ 



Transaction Loading \\ 



Location and Tax Jurisdiction Information can now
be loaded to IPTL ‘Manage Loaded Pay Lines’ and processed by UPTL ‘Loaded Pay
Transactions Report’. UPTL now supports the creation of Pay Headers with this
information overridden and creates multiple timesheets if multiple
jurisdictions are found. The new fields added are HOME_JURISDICTION,
WORK_JURISDICTION, and WORK_LOCATION.\\ 



__General / Miscellaneous__\\ 



Field Sizes
Increased\\ 



Column sizes and field sizes were increased for the
fields below. Server code referencing these fields was updated to support the
increased sizes.\\ 



Passwords increased from__ 16 to 30 __characters\\ 



Columns with the domain Code
increased from__ 16 to 60__ characters \\ 



Columns with the domain Description
increased from __50
to 200__ characters\\ 



User Profile added
to Employments\\ 



Self-service user profiles can now be attached to
an employment. When an employee is terminated and then re-hired, the older
employment record can have a different, more restricted user profile.\\ 



HELP_URL\\ 



Personality 5.05 supports linking the Wiki (also
known as Knowledge Base or Internal Wiki) to the role level using the updated
HELP_URL preference. With this change, regular self-service users can have a
different Wiki than Administrators. The preference HELP_URL was updated to have
the "Applies to Role" toggled on. This automatically sets the
preference at the role level on IMRO. If this preference is set at the site
level on IMST, this will be used for all users except those who have this
overridden on their role (i.e. WWW_EMPLOYEE role).\\ 



Open
Enrollment \\ 



Flex Plan Running Amounts and Totals are now
displayed in Self Service Open Enrollment.\\ 



Feature added to allow the system to determine
which plans/coverages are dependent on other plan choices. A new table
P2K_BE_PLAN_DEPENDENCIES (BPD) was created. \\




Personnel
Action \\ 



ISPY PA Type Tables can now be updated
automatically with the new columns once a PA is created (‘Create/Refresh All PA
Columns for Tables’)\\ 



New function ISFPT ‘Maintain Function PA Types’ is
the screen to set up a function’s PA Type.\\ 



This form contains the PA Type that is associated
with a function.\\ 



Each function can only be linked to one PA Type.\\




A PA Type can apply to multiple functions.\\




Removed PA Type field from the IMFD and IMFDH
screens. \\ 



__New Functions__\\ 



Below is a list of new functions in 5.05.\\ 



 



||__FUNCTION - Analytics
Dashboard__||__DESCRIPTION__



|DASHBOARD_CONF|User Configurable Dashboard



|MSS_DASHBOARD_CONFIG|Mgr. Configurable Dashboard



||__FUNCTION - Analytics
Dashboard Panel__||__DESCRIPTION__



|BBDD|Benefits
Dynamic Dashboard



|BBSH|Benefits
Static Dashboard



|BDATDM|Dash - Approvals to Do



|BDQL|Dash
- Quick Link Icons



|BECTA|Dash - Emergency Contacts (Admin)



|BEDD|Human
Resources Dynamic Dashboard



|BESH|Human
Resources Static Splash



|BET4|Print
My T4 form



|BEW2|Print
My W2 form



|BPDD|Payroll
Dynamic Dashboard



|BPSH|Payroll
Static Dashboard



|BPTC|Dash
- Total Compensation



|BTADD|Time and Attendance Dynamic Dashboard



|BTASH|Time and Attendance Static Dashboard



|BWTDM|Dash - Workflow to complete



||__FUNCTION -
Interactive Screen__||__DESCRIPTION__



|IDVARA|View All Approval Records (Admin)



|IMSOIC|Candidate Document Signoff by Doc



|IMSOIE|Employee Document Signoff by Doc



|IMTRM|Maintain Trace Modes (Changes lost after restart)



|IRNB|Maintain
NGV Benefits



|ISFPT|Maintain Function PA Types



||__FUNCTION - Report__||__DESCRIPTION__



|REBES2|Employee Total Compensation Statement



|RPGLP|Payroll G/L Distribution Report



|RPGLX|Payroll G/L Distribution Report



|RPW2W4TB|Produce W2 forms



||__FUNCTION - Self
Service Screen__||__DESCRIPTION__



|WAOD|Onboarding
Dashboard



|WAPSN|Deductions



|WAPTSS|Enter Employee Timesheets



|WAPWC|Process Wage Changes



|WASPA|Maintain Personnel Actions



|WAVEEP|Employee Profile



|WCRAS_INTV|My Interview Time Options



|WCRAS_SPLASH_INTV|My Assessments



|WEPAY|View My Pay Stubs



|WEPETBWD|My Time Card - Entered Time By Week Date



|WETETBWD|My Projected Timesheet - Entered Time By Week Date



|WEVBEN|My Benefits



|WMEPR|Process Promotions



|WMPTSS|Review Time Cards



||__FUNCTION - Update
Process__||__DESCRIPTION__



|UEINH|Import Employee Hires



|UEINHF|Generate Interface Format for Importing New HIres



|UEPAIF|Generate Interface Format for PA in csv



|UFBUIF|Create Budget Interface File



|UPCLOSEPAY|Cloz and Disburse Pay



|UPCTER|Change Timesheets Edit Rights



|UPPAY|Payroll Batch Audit and Pay Calculation Report



|UVACAMONTHLY|ACA Monthly Data Processing



__New  Windward Reports__\\ 



Below is a list of the new or existing reports that
were converted to Windward, most are in .xlsx format.\\ 



 



||__REPORT__||__DESCRIPTION__



|RPFRS| Florida Retirement Report



|RPSNR| Sundry Register



|RFBU|
Budget Structures Report



|RPNYRS| New York State Retirement Report



|UPORPERS| Report Oregon State PERS



|UPWAPERSW| Report Washington State PERS



New Preferences\\ 



Below is a list of the new preferences.\\ 



 



||__PREFERENCE__||__DESCRIPTION__



|ADD_CALENDAR_APPOINTMENT|The preference ADD CALENDAR
APPOINTMENT will allow a user to automatically send an email and add an
appointment to outlook calendar for an event (Implemented for Leave Request and
Class Registration)



|ALLOW DEPENDENCIES|Feature for benefits to allow dependencies on plans



|DB_OUTPUT_BASE_FLDR|This preference is for new logic that allows output
directory option on reports and dynamically creates and saves directory on DB



|DEFAULT ESS ROLE|This preference is used to Auto assign IMUS on IEID
upon hire via IEQH if the IDJB IMUS is missing.



|DEFAULT_RANGE_MIDPOINT|Defaults the Position Wage Rate from
the Job’s Salary Range.



|DFT_PRENOTE_REQUIRED|This preference will allow the user to turn OFF the
PRENOTE_REQUIRED toggle on insert. Default value is Y.\\ \\ If this preference
is set to N the PRENOTE_REQUIRED toggle will be turned OFF.\\ \\ NOTE: t the
PRENOTE_REQUIRED toggle is turned ON only when the PRENOTE_DAYS on Payroll Bank
Accounts is not null. \\ \\ Setting the preference value to Y will not
turn the PRENOTE_REQUIRED toggle ON if the PRENOTE_DAYS on Payroll Bank Accounts
is null\\ 



|DFLT ESS ROLE|This preference is used to Auto assign IMUS on IEID
upon hire via IEQH if the IDJB IMUS is missing.



|DFLT_ESS_EFF_DT|This preference is used for the Start Date override
for IEID access begins.



|DFLT_ESS_USER |When an employee is hired via
IEQH or via API/conversion process, they should automatically have access to
self-service. The agency should be able to have an IMST setting that is the
default user profile for the identity. There should also be an IMST for the
default accessor_key. This should allow for work email as this will be Neogov's
approach for unique user logins



 \\ 



\\ 



\\