Salary Category Historic - Functional Specifications
Until now there was not a salary category historic where all the different salary categories of an employee were stored.
The purpose of this project is to create a window to be able to register the salary category of an employee. A new table will be created to store the different employee categories.
Also, the different salary categories could have or not cost associated. A new check will be created to indicate if cost is applied or not to the salary category.
Finally, the Profitability Report will take in consideration the salary category in order to calculate the real cost of a project, looking for the effective salary category of the employee at the moment he/she was working for the project.
One table to manage the salary categories of an employee will be created. Users with enough privileges could add, modify and delete records. All the modifications in that table will be registered then in the salary category field for the employee.
Also, the salary category historic of each employee will be considered in the Profitability Report in order to calculate more accurately the cost.
This application provides an "historic" of the salary categories that will enable to modify the stored records. This will make possible to modify the starting date since one employee has a specific salary category. These records can be updated and deleted.
User roles & profiles
This application can be used by any user with Administration permision, so any user that can use the Business Partner window could use this new application.
Business process definition
The field for the Salary Category in the Business Partner - Employee window will be modified to be non updatable in order to show the last employee salary category.
Any modification in the business partner's salary category table will be registered via trigger to the employee Current Salary Category field.
All that records could be accessed from a new created window. They could be updatable once it could be desirable to modify the starting date since when the employee has the new category. A unique constraint will be added in order to ensure that only one record could be created for one salary category and a starting date.
The Profitably Report will consider the historic salary category to calculate more accurately the cost of the employee. The cost will be calculated looking for the employee salary category when he/she was assigned to the project, retrieving
Paul is the person in charge of Human Resources in a Services Company. He has updated every salary category of all the company employees since the employee tab in Openbravo. But now he would like to have the historic of all the employee salary categories. He also thinks that the Profitability Report should take into consideration the real category of the employee in the moment he/she was working for the project.
First of all, with the new development, Paul has created different Salary Category and their respective costs associated. Now Paul has also the capability to create salary categories without cost associated unchecking the Cost Applied. This possibility could be useful if costs are not going to be used and Paul wants to use the salary category just for classifying purposes.
Then, he goes to the Employee tab in the Business Partner window and see that he is not able to modify the "Current salary category" field. He also realizes that field is only displayed for those business partners noticed as "Employee". So he has to go to the "Salary Category" tab to manage the different salary categories for each one employee.
Then, the field in the "Employee" tab is automatically updated with the salary category with maximum starting date in the salary category window.
Now Paul is able to create more accurate Profitability Reports since now the cost calculated for a project take into account the real salary cost of each employee at the moment he/she was assigned to the project (and not the last value as it did before the modification). For example, in the project "Past Project" in which just only Mick was assigned. During that epoch Mick had the Production worker salary category. After successfully completing the project, Mick was promoted to Production manager salary category. So the Profitability Report should calculate the project cost taking the cost associated to the category Production worker (because that was the salary category of Mick during the project) and not the cost associated to his new salary category.
- A new table C_BP_SALCATEGORY should be created to store the different salary categories of the employee.
- A constraint to ensure the uniqueness of the pair SalaryCategory-StartingDate will be included.
- A trigger C_BP_SALCATEGORY_TRG will be created to ensure that exists the salary category cost and a valid date.
- A trigger C_BP_SALCATEGORY_TRG2 will be created to update the salary category field in the employee table. In order to prevent mutating errors, this trigger will made a massive update to the salary category for all the employees.
- A new check field isCostApplied will be created in the C_SALARY_CATEGORY table to enable the use of salary categories with/without cost.
- A display logic will be added to the tab employee in order to show/hide the field "salary category" in case of the business partner was/was not employee.