Company-wide HR policy configuration on Kitikiti HRM
Company HRM configuration
- Setup Tricks
- Company Details
- Personal Data Types
- Off Days, Work Schedules & Leave Types
- Expense Types
- Default Payroll Configuration & Pay Component Types
- Workflow Types
Setting up Kitikiti HRM for your organization may require a lot of configuration testing and changes. Similarly, you may also need to create test employees and documents.
It's best to do this without triggering emails to actual employees. This can be done via the Email Sink feature.
This feature is reachable via Administration > General Configuration > Application Configuration. You simply need to uncheck 'Send emails', and specify an email sink to take all emails coming from Kitikiti HRM. This way you won't accidentally spam your employees' email during testing. You can read more details of this feature here.
It's also best to clean up test employees and documents once you have finalized your HR policies. This can be done via the Company Reboot feature.
This feature is reachable via Administration > General Configuration > Company Details > 'Reboot' button. It allows you to circumvent the strict HRM data deletion policy, which is a good thing to have when the system is live. You can read more details of this feature here.
In Company Details, you can personalize your company in terms of the company's:
These details may be used in various facets of Kitikiti HRM. For example, it is best to upload your company logo so that it appears on the employee's pay slip.
You can also specify a promo code for your company here, to take advantage of any offer that Kitikiti HRM opens from time to time.
This feature is reachable via Administration > General Configuration > Company Details.
Personal Data Types
Personal Data Types define what information an employee should have. Kitikiti HRM attempts to predefine, according to the company's country, as to the minimal data types required for successful processing of employee's HR documents, most importantly pay slips.
For example, a pay slip, and ultimately its actual disbursement, requires the employee's full legal name, his / her legal identification, bank account number and other details such as tax filing number / employee's registration numbers with statutory bodies.
You can also specify a default value for each personal data type, especially if most of the employees would have the same setup. Whenever a new employee is created, he / she will have his / her own set of personal data, initially set to the corresponding default values.
You can further tweak the prepopulated personal data types to suit your company's template for employee's biodata at any time.
This feature is reachable via Administration > General Configuration > Personal Data Types.
Off Days, Work Schedules & Leave Types
The first thing to do when it comes to configuring leave, is to configure the Off Days and Work Schedule. A work schedule basically determines whether a day is a working day or not. As such, work schedule usually requires us to define what are the Off Days applicable under it.
For example, most countries have the weekends off - Saturdays and Sundays. This is an example of a weekly recurring off day.
On the other hand, 25th of December of each year is a holiday for most countries - as that's when Christmas is celebrated. This is an example of an annually recurring off day.
To define Off Days, go to Administration > Leave Configuration > Off Days.
You can define Off Days that recur weekly, bi-weekly, monthly or annually. Different recurrences may prompt you to define the recurrence pattern differently. For example, for weekly / bi-weekly recurrence you will need to specify the day(s) of the week for which the off day occurs. For monthly recurrence you will need to specify the days of the month (in numbers). Finally, for annual recurrence you will need to specify the exact date(s) on when the off day would take place.
By default the recurrence runs for the full length of the year. However, for weekly, bi-weekly and monthly recurrences you can also specify the exact start and end dates to narrow down the recurrence period further.
We also allow you to even specify an off day that only takes place partially within a day. To specify such day, you need to set the partial day hours applicable for that single day. Kitikiti HRM assumes an 8-hour work day, therefore the partial day hours should be set to 4 for a half day off, for example.
In any case, each off day entry is associated to a specific year. This allows you to easily pick what off days to be associated to your work schedule later, which is also associated to a specific year. This yearly scoping of off days is also helpful for holidays that don't fall on the same dates each year e.g Thanksgiving, Eid and Chinese New Year.
By default Kitikiti HRM creates a default off day entry for weekends - setting Saturdays and Sundays as off days.
Once the off days are set, you can then associate these off days to your work schedule. This feature is reachable via Administration > Leave Configuration > Work Schedules.
By default Kitikiti HRM creates a default work schedule under the name 'Regular', which includes the weekends. This is a good starting point for a work schedule, but you would probably want to include other off days such as public holidays applicable to your company.
Depending on the year set for the work schedule, a list of off days for that year is shown. You can then select the off days applicable for the work schedule by checking on a given off day's checkbox.
Modeling and structuring the Off Days and Work Schedules this way allows Kitikiti HRM to provide for more complex scenarios such as companies having presence and employees in multiple locations with differing weekends and public holidays. You can read more details on how we handle such scenario here.
The final piece is the Leave Types. This feature is reachable via Administration > Leave Configuration > Leave Types. Upon signup, Kitikiti HRM attempts to predefine several leave types according to your country, or a set of generic ones.
Feel free to add new leave types, or modify existing ones. The notable properties of a Leave Type are:
- Entitlement hours
- Entitlement usage type
- Leave approval workflow
- Supporting document required
In Kitikiti HRM, entitlements are defined in hours and not days, which allows better processing of leave days especially for partial day leave applications. Kitikiti HRM assumes an 8-hour working day, hence a leave type with 120 entitlement hours is equal to 120 / 8 = 15 entitled leave days. The entitlement hours are the default entitlements for all employees, however you can further customize employee-specific entitlements later in employee's Leave Entitlements configuration.
Those entitlements can be utilized two ways - Working Days or Calendar Days. For example, Annual Leave entitled days are usually utilized on working days only. On the other hand, a 2-month long Maternity Leave entitled days are usually utilized on any calendar day, even on weekends. In short, entitlement usage type essentially defines whether a leave type should follow working days defined by a work schedule, or not at all.
By default, most leave types require manager's approval. This approval workflow can also be changed to others. For example, Unpaid Leave should probably require more than just the manager's approval. To change, you will need to first define a new approval workflow type, which is discussed in Workflow Types.
Sometimes, a leave application is incomplete without supporting document(s). For example, certain companies require employees to also submit their medical certificate upon taking Sick Leave. This can be configured by simply checking the 'Supporting documents required' checkbox.
Finally, most leave types are often paid for by the employer - meaning employee pay is not deducted upon availing those leave types. However, there could be certain unpaid leave types, such as the ones for long sabbaticals, extended sick leave and others. By marking these leave types as unpaid, the employee pay under the period when unpaid leave is taken is automatically deducted.
Upon filing claims, it is best practice to categorize each claim under a predefined category. This categorization helps in breaking down the expense claims later for reporting purposes. For example, a company may be interesting in the breakdown of transportation claims versus medical claims.
Claim categorization can be done by defining expense types. This feature is reachable via Administration > Expense Configuration > Expense Types.
The notable properties of an Expense Type are:
- Receipt required
- Linked pay component
Receipt required property is pretty straightforward. Having this property set makes all expense claims under this expense type to need receipts as proof of payment. Usually this is required for accounting / auditing purposes.
Linked pay component property is slightly more complex. In short it serves as a mapping to decide under which pay component should the expense claim fall under in the pay slip. By default most expense report claim amounts would appear as a single amount under 'Expense Reimbursement' on the employee's pay slip.
You can choose to map it under a different pay component by selecting the corresponding linked pay component for the expense type. For example, you may want to map it under a taxable pay component especially if the expenses are taxable. We have covered this scenario in depth here.
Finally, you also have control over how expense claims are approved. By default, all expense claims are approved via Manager's Approval. If you prefer to have a different approval workflow, such as approval by your Finance Manager, you can define that workflow and assign it on the General Expense Configuration.
This feature is reachable via Administration > Expense Configuration > General Expense Configuration.
Default Payroll Configuration & Pay Component Types
Payroll configuration can be broken into two parts. First is to define the default payroll settings, such as how frequently would employees be paid? Weekly, bi-weekly, monthly or semi-monthly?
This feature is reachable via Administration > Payroll Configuration > General Payroll Configuration.
The notable properties of General Payroll Configuration are:
- Pay run approval workflow
- Default annual salary
- Default pay run type
- Default payout target
- Default payout reference
By default, the pay run approval workflow is set to Admin Approval - which means only those with Admin role in Kitikiti HRM gets to approve pay runs. If you prefer to have a different approval workflow, such as approval by your Finance Manager, you can define that workflow and assign it here.
Note that employees can only see their pay slips if the pay run containing them is approved.
The rest of the 'default' values are basically values set for any new employee created. Thus it's best to set the default annual salary, pay run type, payout target and payout reference to reflect the majority of the employees.
For example, the default annual salary should probably be set to reflect the most common salary grade e.g entry-level employees. Note that this can always be customized later for each employee.
The default pay run type sets how frequently are employees paid. Again, this will be the default pay run type reflected for any new employee. That however doesn't mean all employees must be paid using the same frequency. Even if you have monthly payroll frequency as the default, you can still have employees being paid weekly or semi-monthly, for example.
The last two properties, default payout target and reference both describes the default payment method, and circles back to the Personal Data Types configuration. If we look closely, the two dropdown lists for those two properties are basically listings of Personal Data Types. In short the idea is to reuse whatever employee data we already have to process payroll rather than requiring the info again.
By default, Kitikiti HRM assumes that the 'target' of employees' compensation should always be the employees' bank account, and that the 'reference' used in such payout transactions would be the employees' bank account number.
With this default payment method, any new employee will be paid via transfer into his / her bank account. This default payment method can always be changed for any employee by simply changing his / her pay configuration in the employee's Pay Configuration settings, detailed later in Employee HRM Configuration.
Once the default payroll settings for your company has been defined, you can then tackle the Pay Component Types - which are essentially the default earnings and deductions you normally see in a pay slip. This feature is reachable via Administration > Payroll Configuration > Pay Components Types.
The notable properties of a Pay Component Type are:
- Calculation type
- Default payout target
- Default payout reference
The default payout target and reference are similar to what we have in General Payroll Configuration. Essentially it defines the payment method used to disburse the pay component. For example, assuming the pay component is a Tax component, ideally the payment method should be channeling the amount to a certain tax authority (payout target), using the employee's tax filing number (payout reference).
This default payment method for the pay component can always be overridden later for each specific employee, if needs be. Also, the default payment method is usually only specified for deductions, since those amounts will not be paid out to the employee, but rather someplace else.
The more interesting property of a Pay Component Type is actually the calculation type. This determines how the amount of a pay component type is calculated for a pay period. Kitikiti HRM offers 3 calculation types:
- Default Amount
- Percentage Based
- Specified Amount
Default Amount is the simplest of all. It basically states a static, default value for a pay component for any pay period. For example, assume that each employee receives a flat $300 travelling allowance from the company for each pay period. This Therefore, there should be a 'Travelling Allowance' pay component type, where the calculation type is set to Default Amount, and the amount is set to $300.
On the other hand, Percentage Based calculation type is actually a formula describing how the amount for the pay component type is calculated. A good example is a 'Tax' pay component type. Usually, the tax amount is not a static amount but rather it depends on other amounts.
For example, the tax amount is usually a percentage of taxable income. The percentage is usually defined by the tax authority, with different percentages / rates for different income brackets. For example, a 100K annual income may incur a 13.92% tax rate. The percentage is specified in the 'Percentage' field, which only comes up when the Percentage Based calculation type is selected.
On the other hand, the second part of the formula - the taxable income - can be made up of different pay component types, such as Base Salary, Allowance and Bonus. These components are selected via the 'Component selections' list of checkboxes, which only comes up when the Percentage Based calculation type is selected.
By defining this formula, we're ensured to get the correct Tax component calculated even if the amounts for the Tax component dependent component change. For example, if bonus is paid out for the month of December, the Tax component will still ensure that its cut is calculated accordingly.
Note that both Default Amount and Percentage Based calculation types are period-aware. This means that such pay component types are prorated against the period they're applied against. For example, if an employee is paid monthly, and he / she only works for half a month - then a $300 monthly travelling allowance gets calculated as $150 for that month. This is all automatically done by the system.
The last calculation type is Specified Amount. There's really no configuration work required for pay component type with this calculation type. Specified Amount essentially means that the amount will only be specified manually during the preparation of the pay run itself. For example, a Bonus pay component type is usually specified manually, as bonus payouts don't occur regularly for each pay period, and the amounts usually differ for each employee.
Another subtle behavior of a pay component type with Specified Amount is that it won't be enabled by default for a pay run, so that it doesn't appear unnecessarily on every pay slip. However, you can always choose to enable it during pay run preparation if you need to.
Last but not least - there's a slight difference when it comes to creating a new pay component type versus editing an existing pay component type. The idea behind pay component type is to be a 'template' for how an employee pay is structured via earnings and deductions. This means any new employee by default will have a copy of the pay component types as his / her initial pay components.
Those pay components can always be customized according to each employee. For example, an employee may decide to contribute more towards his retirement fund compared to the default rate. You can then modify the employee's retirement fund pay component, and it will only apply to that employee alone. This is later discussed in Employee HRM Configuration.
Coming back to company-level pay component types - if you edit an existing pay component type, this change is not reflected on existing employees' pay component. This is to respect whatever existing employee-specific customizations that have been made.
But, if you create a totally new pay component type, you do have the option to allow existing employees to have it. For example, assume that from now onwards your company gives out Internet Allowance to employees, as a way to subsidize their personal Internet subscription. If the new pay component type is not reflected on existing employees, you would have to go to each employee's profile and manually add it in.
Instead, Kitikiti HRM provides an additional checkbox upon creating a new pay component type to apply it to all employees. You can see this checkbox at the end of the form upon creating a new pay component type.
The idea behind Kitikiti HRM is to make managing HR documents easy - whether they're leave applications, expense reports and pay runs (consequently pay slips). Employees can create these HR documents and go about their business.
However, these documents are only considered to take effect once they're approved. By manipulating Workflow Types, you can create different approval flows to suit your company's HR processes.
This feature is reachable via Administration > Workflow Configuration > Workflow Types.
By default, Kitikiti HRM provides the following workflow types:
- Manager Approval
- Admin Approval
Manager Approval is quite straightforward. If an employee submits an HR document, the Manager is notified via email and is given a link to view and approve / reject the document.
Admin Approval is only for special HR documents, and it is applicable to only users with Admin role. For example, the approval of a Pay Run, which consists of Pay Slips, should only be done by an Admin as it's quite an important and sensitive HR document. Note that it only takes one Admin to approve the document even though you may have multiple Admins in your setup.
By default, the HR documents are approved as follows:
- Leave Application
- Manager Approval for most leave types
- Admin Approval for extraordinary leave types e.g Unpaid Leave
- Expense Report
- Manager Approval
- Pay Run
- Admin Approval
All of the above are not set in stone and can always be customized. You can either change to another workflow type, or even create your own. For example, you may want the Pay Runs to be approved by your Finance Officer instead. To do so, you can create a new workflow type, select the approval type of 'Approval By Specified Employee(s)', and assign your Finance Officer.
Note that you can also select multiple employees, for which the approval takes place only if all approvers endorse and approve the HR document.