• EmployeeRecord

Feature Specification

Feature Name: Employee Record

Overview

This specification describes how to build a basic core Employee record functionality in xTupleERP. It is a necessary subset of functionality that will be required to implement certain advanced features on the Highlander Project including Advanced Sales Commissions and Time & Attendance.

Functional Requirements

• The system must allow independent record to be created for employees.
• Employee New, List and Search options should be added to the System Menu.
• The Employee list should be printable from the list and search windows.
• The employee record must reference contact information from the CRM system.
• The employee record may have, but is not required to have, a relationship to a system user id.
• The employee record may have, but is not required to have, a relationship to a sales rep id.
• A sales rep may only be associated with one employee.
• A user may only be associated with one employee.
• The interface should allow one to jump from the employee record to the user record and vice versa.
• The interface should allow one to jump from the employee record to the sales rep record and vice versa.
• The employee should appear as one of the uses listed on the contact window.
• Employees should have a unique number identifier.
• Employees should have an active status independent of the contact.
• Employees may have notes.
• Employees may have comments.
• Employees may have characteristics.
• Employees may be assigned a Site (currently known as Warehouse).
• Employees may be associated to a manager employee
• The employee will be designated hourly or salary.
• The employee record will have a field to record pay rate per a time period of per hour, day, week, biweekly, or year.
• Department and shift information on the user record will be moved to the employee record.
• There must be an interface to group employees.
• An API view should exist for Employee and its related records.
• Employee and Employee Groups should have View and Maintain Privileges.
• The employee record must provide a link to an image

New Terms and Definitions

• Employee

  • A record of an individual who works for the organization

Related Existing Functionality

• Sales Rep, User Management and CRM Contact are related to this functionality. The same methodology CRM Account uses to handle relationships to other records should be used here.

Similar and Related Requests

This feature is a prerequisite for Advanced Sales CommissionsMantis issue 6697.

There will be problems for existing xTuple users linking existing sales reps to the new employee table. This problem is conceptually similar to Mantis issue 5786.

Conflicting Features

None known.

User-Level Functionality

A new menu item should be added to the System menu for Employee with submenus for New, List and Search. They should basically mirror the same functionality as found in CRM contact except that columns Account Number and Description should be replaced with Employee number and Department respectively, and the Employee Search should have a New button. ViewEmployee or MaintainEmployee privileges must be granted to access the Employee windows.

The new Employee window should look as pictured below. This screen mock up has already been committed the SVN repository as employee.ui.

Employee Number is a user entered text field. Contact information is handled by the contact cluster. Relationships for User (as in User Information Window) and Sales Rep should behave the same way Customer does on the CRM Account Window, which means that all related information must complete before saving. Site is actually the warehouse combo box which is being relabeled system wide on Mantis issue 6692. Manager uses an Employee cluster to search and relate another employee to the current employee record. Hourly or Salary are required selections. Rate is a currency cluster to store the employees pay rate. Dept. and Shift cluster store the data that is currently stored in the user management window. The group membership tab should allow a user to add and remove groups that the employee belongs to; users must have ViewEmployeeGroups or MaintainEmployeeGroups to view and edit this tab respectively. There will be a tab (not picture) to link the employee record to an image in the database. The linked image should be displayed on the tab.

The User Information window should be altered to remove department and shift information which will now be stored on the employee record. Proper name in the User Information window should be replaced with the employee cluster.

The Sales Rep window should have the Employee Cluster added to it to show that whether a Sales Rep has been associated to an employee.

Employee Groups should be listed in the Employee submenu divided from the other windows by a separator. Employee groups should behave identically to the way groupings work for customer and item, with the exception an employee can be added to a group from the employee window itself. Users should have ViewEmployeeGroups or MaintainEmployeeGroups to access Employee Group management.

The Contact Window will need to be modified to show if the contact information is used on an employee record.

Report Changes

An Employee List report will need to be created to support the Employee list view.

Batch Manager Changes

No Changes

Usability Considerations

Creating a new employee/user will be slightly more cumbersome than before as two screens will be involved.

Problems and Alternatives

Generally having data for a single individual spanning so many windows (contact, employee, sales rep, user) may appear confusing to users. Each of these actually represents different roles and individual can have in an organization. While some users may find this cumbersome to navigate, it is basically essential to keep the records separate as each role has a distinct purpose.

The separation could become even more unwieldly as additional HR, Commissioning and Time and Attendance functionality is added either to the core or by extension. However, the good news is the Screen builder, API Views and scripting could be used to create special purpose consolidated versions of these windows if the need arises.

One might argue the sales rep could simply be a check box option on the employee record, however, there are situations where sales reps are not employed by the organization, and it is likely in the future a mutually exclusive relationship between sales rep and employee or sales rep and vendor is likely to handle commission payments for independent sales reps.

Internal Design

Custom Widget Changes

A subclass EmployeeCluster should be created from the VirtualCluster class to be used where employees are references in other windows.

Schema Changes

A new employee table should be created in the public schema to store the new data. The usr table will be altered to remove department and shift data and add the employee id. Since this is a straight forward design, it will be at the developer's discretion to determine the table and column names and data types necessary. Foreign keys should be provided to maintain integrity between related tables. Employee Id should be unique on Sales Rep and User records to prevent one-to-many relationships.

API views for employee should be created the API schema that mirror functionality available in the Employee window.

Stored Procedure Changes

getEmployeeId(text), getDeptId(text), and getShiftId(text) functions will need to be created to support the API view. This should work identically to several "get...id" functions used in existing API views.

Performance Considerations

No impact expected

Error Handling

Minimal error handling expected other than relationship enforcement.

QA Considerations

This is a straightforward implementation. Care should simply be taken to make sure all the widgets and relationships between employees and other records work as expected.

Documentation Considerations

Moderate documentation will be required as Employee is all-new functionality.

Release Considerations

The release target is version 3.0.

Care should be taken to port all existing system users over as employees with department and shift data intact, and employee linkages added to the usr table. If this data turns out to be inappropriate, it is easy enough for users to delete unwanted employee records.

This employee record functionality is absolutely essential to build necessary extensions for the .5 release of the Highlander project.