Overarching Principle
Employee ID is the key identifier for data flow; not to be confused with Job ID - the key identifier for Job Cards only (see Job Cards section)
Identify fields that require no data flow, one-way data flow, or two-way data flow; what is updated in Omni -> flow to Talenox, and what is updated in Talenox directly and remains there for payroll purposes only, and what is updated in Talenox and sends that data back to Omni
Understanding company structures in Talenox:
Each company is its own unique instance in Talenox Each instance has its own unique Talenox API Token and HTTP Auth Password V1 Talenox API authenticates via URL, V2 moves authentication to request header The idea of of a top-down platform enables an organisation to view, edit, delete data for all employees in all Talenox instances under the organisation without having the hassle of switching instances Integration flow: Omni Company = corresponding Talenox API Token & HTTP Auth Password -> authenticate request in request header using token and password -> Actions allowed = POST PUT GET DELETE Omni Company Field List of Options required to be linked via unique API Token in Talenox. Manual set-up and link most likely needed, Omni CS needs to support
What happens if an employee appears in two or more companies (e.g. part-timer, salary splits).
Automated and rolling Employee ID numbers based on a certain customised format.
Understanding fields that have in Talenox:
Dependencies: Fields that only appear or are mandatory when a selected option is chosen (e.g. Immigration Status)
Bank Information
Omni does not support auto-population of certain fields related to bank information Talenox auto populates these fields based on certain information Figure out POST PUT GET requests and specify one-way integration if required - Talenox automation should not override data that is POSTed from Omni
Job Cards
Compensation information in Omni is seperate from Job information. In Talenox, these are combined in Job Cards, identified by specific Job IDs Each Job Card contains only Basic Salary, on a recurring basis. Other compensation components (allowances, deductions etc) are not recorded here, instead, they are input directly during payroll. Any other information in Omni besides Basic Salary will require an additional POST request to in Talenox Payroll to set pay items as recurring pay items on a monthly basis (e.g. transport allowance, mobile allownce) The downside to this is that the reccuring pay item will not become effective until a Payroll Payment Run is created and processed. These cards can be directly integrated to Omni’s Career Journey via Job ID Job Change Event field does not exist in Talenox, but it is an important part of tracking careers. In addition to Promotions, Transfers, Job Changes - other scenarios include Increment, Demotions, Termination
Leaves
Decision to be made: Follow Talenox leave policies and use GET POST PUT DELETE to retrieve leave balance, make / delete leave application Leave versioning in Talenox (speak to Chloe / Kenneth for more info): Introducing leave grades, set effective date of leave grades, pro-rate leave balances according to policy based on date. Common issue when employees are promoted or leave policy changes This versioning is already available on Omni (with a certain degree of inaccuracy due to rounding differences and options) via the “Time Off Policy” -> “Effective Date”. Figure out if this should be integrated at all. Leave dependency-workflows: Especially if you do not intend to use Talenox to power region-specific leave regulations. Omni workflow logic: If [event] occurs, then [action] | Talenox workflow logic: If [field] = [state], then [action] Figure a way to create legally mandatory leave items (e.g. parternity, maternity, CCL, ECCL, NS) as well as voluntary leave items (birthday, marriage) that checks for a specific state (have child = true, check child < 7 y/o, Singaporean, check spouse = legally married etc) of an employee. Approval Process in Omni: Allow for two-level approvals? Team Calendar in Omni: Views - allowing managers or admins to choose which departments and which locations they’d like to view OR admin assigns acess levels as to which location employees can view (e.g. Operations Director is stationed at HQ, but oversees 7 other locations (restaurants), s/he would need to see leave calendars for all 7 locations)
ID & Visa
Immigration status is the field that controls SHG & CPF contributions in Talenox. No such field exists in Omni. Nationality and Immigration Status are NOT the same.
Payroll
Leave encashment: Dictating encashment policy, creating leave payment in Talenox payroll run. Talenox automatically takes leftover balance of AL to encash, if balance is not maintained in Talenox, how this data is given to Talenox. Before any payroll item can be created, a Payroll Payment Run must be created for that employee, or a group of employees.
{
“payment”: {
“year”: 2023,
“month”: “March”,
“period”: “Whole Month”,
“pay_group”: null,
“with_pay_items”: true
},
“employee_ids”: [
“ENF-0001"
]
} In a POST request, the pay items can be added on to the request with “pay_items” parameters. See above on Job Cards for recurring pay item information Retrieving payslip data: Talenox currently allows for us to send payslips to employees via individual emails in PDF for them to see payslip. To check pay data, I want to avoid asking employees to log into Talenox to retrieve their payslips. Therefor Omni can retrieve both pay data + actual payslips for the month and display within Omni itself Using will return a fucking long list of pay items and subtotals related to the month’s payroll. How to cipher this information, and present it in a way that makes sense and easy to see is to be worked on from a UI/UX perspective
Attendance
Omni Attendance (if intending to further develop this feature in-house instead of working with another partner) needs further versatility to cater to blue collar companies. Break times not taken into account (which there are pros and cons) Hard-coded in Omni to follow standard work schedule assigned, which is technically not always correct and always changing (this is usually true for hourly-rated workers, but full-time employees have a contractual obligation to fulfil 44 hours of work a week without breaks, anything in excess is overtime. Puts us in an interesting situation where employee is entitled to overtime pay even if s/he has not fulfilled contractual working hours per week Usually a good idea to only push hours as data into the appropriate attendance pay item field into Payroll, use Payroll’s in built calculation to make sense of the hours and convert into $
UI
Home interface slightly out of proportion, especially saying hi to new hires section Organisation chart - strictly follows direct manager? What about cases of indirect managers - any intentions for UI to allow for that Organisation chart - is there a role the field “Team” plays in the chart? People - Most fields are truncated; most of the time no meaningful information is immediately visible here Testing Tenants in Talenox
All Suite Plans