CA2648383C

Call center application data and interoperation architecture for a telecommunication service center

Abstract

A call center application data and interoperation architecture provides a centralized design for managing applications providing call center functionality. The architecture integrates information flow using a mater data repository for all applications for all aspects of a call center operation. The architecture provides employee information at defined levels through the complete employment life cycle, including the initial hiring and termination. The architecture provides the employee information by integrating human resources information with call center applications such as Employee attendance and Leave management, ID management, Transport management, Commitment logs, and Movement management, or any other application.

CA2648383C, drawing sheet 1 — Sheet 1 of 122

Term

2.3 yearsleft in the term

Expires 5 January 2029.

20 claims: 3 independent, 17 dependent

1
CA 02648383 2013-12-06 71035-54PPH CLAIMS:1. A call center application data and interoperation architecture, the architecture comprising: a master application data repository comprising a master data organization schema unified across multiple call center application dataset requirements, the master data organization schema comprising a schema subdivision defining: a first application data schema within the master data organization schema that is specific to a first application dataset requirement for a first call center application;a second application data schema within the master data organization schema that is specific to a second application dataset requirement for a second call center application;a call center application communication interface operable to: receive a first call center application data request from the first call center application in communication with the call center application communication interface;receive a second call center application data request from the second call center application in communication with the call center application communication interface;and a processor coupled to the call center application communication interface and the master application data repository and operable to: process the first call center application data request by performing first data manipulation responsive to the first call center application data request on the first application data schema in the master application data repository, thereby CA 02648383 2013-12-06 71035-54PPH relieving the first call center application from first application local database overhead;and process the second call center application data request by performing second data manipulation responsive to the second call center application data 5 request on the second application data schema in the master application data repository, thereby relieving the second call center application from second application local database overhead, where the schema subdivision further defines a common application data schema that implements a shared dataset requirement common to the first call center application and the second call center application. 10
11
A method for coordinating the operation of multiple call center applications in a call center architecture, the method comprising:establishing a master application data repository according to a master data organization schema unified across multiple call center application dataset requirements;subdividing the master data organization schema into: a first application data schema that supports a first application dataset requirement for a first call center application;a second application data schema that supports a second application dataset requirement for a second call center application;establishing a call center application communication interface;receiving a first call center application data request from the first call center application through the call center application communication interface;receiving a second call center application data request from the second call center application through the call center application communication interface;and processing the first call center application data request by performing first data manipulation on the first application data schema in the master application data repository, thereby relieving the first call center application from first application local database overhead;processing the second call center application data request by performing second data manipulation on the second application data schema in the 101 CA 02648383 2013-12-06 71035-54PPH master application data repository, thereby relieving the second call center application from second application local database overhead;and establishing a common application data schema in the master data organization schema that implements a shared dataset requirement common to the 5 first call center application and the second call center application.
16
A product comprising:a non-transitory machine readable medium;and logic stored on the medium operable to: 10 establish a master application data repository according to a master data organization schema unified across multiple call center application dataset requirements;subdivide the master data organization schema into: a first application data schema that supports a first application dataset 15 requirement for a first call center application;a second application data schema that supports a second application dataset requirement for a second call center application;establish a call center application communication interface;receive a first call center application data request from the first call 20 center application through the call center application communication interface;receive a second call center application data request from the second call center application through the call center application communication interface;process the first call center application data request by performing first data manipulation on the first application data schema in the master application data 103 CA 02648383 2013-12-06 71035-54PPH repository, thereby relieving the first call center application from first application local database overhead;process the second call center application data request by performing second data manipulation on the second application data schema in the master 5 application data repository, thereby relieving the second call center application from second application local database overhead;establish a common application data schema in the master data organization schema that implements a shared dataset requirement common to the first call center application and the second call center application. 10

Independent claims3

1,757 paragraphs in 87 sections, as filed

CA 02648383 2013-09-09

71035-54

CALL CENTER APPLICATION DATA AND INTEROPERATION ARCHITECTURE FOR A TELECOMMUNICATION SERVICE CENTER

INVENTORS:

Amit Sarin

Shubhabrata Sengupta

Sunandita Ganguly

Amit Kumar Tewari <sub>ΓΛΛ</sub>„, BACKGROUND

[001]

2. Technical Field

[002] This application relates to data processing systems, and in particular, to a call center system architecture.

3. Related Art

[003] The rapid growth of information technology has led to increasingly complex and sophisticated products and services. In an effort to provide meaningful assistance to customers, companies have made significant investments in call centers. The primary goals of a call center include working with customers to resolve issues, answering questions, and providing ongoing support for products and services.

[004] Despite the general level of sophistication of a modern call center, challenges still remain. In particular, many areas are still prone to error, and suffer from the need to perform repetitive manual labor to carry out tasks. Furthermore, call center data was often managed in a chaotic manner, leading to data redundancy and data loss. At the same time, data manipulation was hectic and required a high level of skill for even routine maintenance. These drawbacks limited the ability of the call center to provide

CA 02648383 2009-01-05 timely, accurate, and automated reports; to secure data; and to provide real-time data tracking.

[005] A need exists for an improved call center application architecture.

Summary

[006] A call center application data and interoperation architecture (architecture) provides a centralized design for managing the many applications that cooperate to provide call center functionality. The architecture coordinates information flow through a master application data repository and provides tailored support for applications that handle all aspects of call center functionality. The architecture adeptly handles information flow for all call center applications and for the employees who use the applications, including managers, supervisors, and call handlers.

[007] The applications implement functionality applicable across the complete span of the employment cycle from hiring to termination, and well as other support functions. The applications may implement functionality including human resources functions, employee attendance tracking, and employee attrition management. Other examples of application functionality include employee leave management, employee commitment logging, and identification management. The applications are not limited to voice specific applications (e.g., teleconference based problem resolution), but may also encompass non-voice processes (e.g., email or Internet based order processing).

[008] The architecture may be implemented in a network-based tool that provides significant improvements with respect to the labor intensive processes and data integrity challenges described above. The network may include local and remote networks, or interconnections of networks, whether private and internal, or publicly accessible. The network may include Internet based connectivity for local or remote access to the applications and the data stored in the master application data repository. Furthermore, the architecture provides both visibility and collaboration across the call center and its applications.

[009] The dynamic environment of a call center means that resources, such as employees or call center equipment, are moved across processes very often. A

CA 02648383 2009-01-05 process may be any instance of call center functionality, such as fielding technical inquiries from callers about specific products, activating products or services, or placing and confirming orders for products or services. The wide variety of processes and frequent resource movement across processes gives rise to a need to track the resources in a systematic manner. In this regard, the architecture facilitates, for example, tracking the processes for which any call handler or supervisor has worked during his or her tenure with the call center. The architecture may also track other relevant details, such as the call handler's duration in each process, subsequent supervisors and performance data, and other details.

[0010] Furthermore, the architecture tracks information about each employee within the system. The architecture may track information about each employee at every defined level of hierarchy. The hierarchy may reflect relative position or rank, such as manager>supervisor->call handler, with the architecture maintaining information on each employee at each level in the hierarchy. The architecture also supports, at every defined level in the hierarchy, specific individual access rights for all employees. The access rights may be set depending upon employee level in the hierarchy, the process the employee belongs to, and other factors.

[0011]As noted above, the architecture includes a master application data repository. In one implementation, the master application data repository adheres to a master data organization schema. The master data organization schema is unified across multiple call center application dataset requirements in that the master data schema handles all of the information flow generated by the call center applications. The master data organization schema is partitioned along a schema subdivision that defines multiple individual application data schemas that are specific to individual application dataset requirements for different call center applications.

[0012]A communication interface receives call center application data requests from the call center applications. A processor and supporting software (e.g., database management software) process the call center application data requests. In particular, the processor performs data manipulation responsive to the call center application data requests, while working with the specific application data schema in the master application data repository. Data manipulation may include adding, deleting, or

CA 02648383 2013-12-06

71035-54PPH changing data fields on a per-application basis, such as adding employee attendance records on a daily basis, changing the processes to which an employee is assigned, or deleting completed commitments from a commitment requirements list, when the employee has met the commitment. The architecture thereby relieves the call center applications from local database and processing overhead.

[0012a] According to one aspect of the present invention, there is provided a call center application data and interoperation architecture, the architecture comprising: a master application data repository comprising a master data organization schema unified across multiple call center application dataset requirements, the master data organization schema comprising a schema subdivision defining: a first application data schema within the master data organization schema that is specific to a first application dataset requirement for a first call center application; a second application data schema within the master data organization schema that is specific to a second application dataset requirement for a second call center application; a call center application communication interface operable to: receive a first call center application data request from the first call center application in communication with the call center application communication interface; receive a second call center application data request from the second call center application in communication with the call center application communication interface; and a processor coupled to the call center application communication interface and the master application data repository and operable to: process the first call center application data request by performing first data manipulation responsive to the first call center application data request on the first application data schema in the master application data repository, thereby relieving the first call center application from first application local database overhead;

and process the second call center application data request by performing second data manipulation responsive to the second call center application data request on the second application data schema in the master application data repository, thereby relieving the second call center application from second application local database overhead, where the schema subdivision further defines a common application data

CA 02648383 2013-12-06

71035-54PPH schema that implements a shared dataset requirement common to the first call center application and the second call center application.

[0012b] According to another aspect of the present invention, there is provided a method for coordinating the operation of multiple call center applications in a call center architecture, the method comprising: establishing a master application data repository according to a master data organization schema unified across multiple call center application dataset requirements; subdividing the master data organization schema into: a first application data schema that supports a first application dataset requirement for a first call center application; a second application data schema that supports a second application dataset requirement for a second call center application; establishing a call center application communication interface; receiving a first call center application data request from the first call center application through the call center application communication interface; receiving a second call center application data request from the second call center application through the call center application communication interface; and processing the first call center application data request by performing first data manipulation on the first application data schema in the master application data repository, thereby relieving the first call center application from first application local database overhead; processing the second call center application data request by performing second data manipulation on the second application data schema in the master application data repository, thereby relieving the second call center application from second application local database overhead; and establishing a common application data schema in the master data organization schema that implements a shared dataset requirement common to the first call center application and the second call center application.

[0012c] According to yet another aspect of the present invention, there is provided a product comprising: a non-transitory machine readable medium; and logic stored on the medium operable to: establish a master application data repository according to a master data organization schema unified across multiple call center application dataset requirements; subdivide the master data organization schema into: a first application data schema that supports a first application dataset requirement for a

CA 02648383 2013-12-06

71035-54PPH first call center application; a second application data schema that supports a second application dataset requirement for a second call center application; establish a call center application communication interface; receive a first call center application data request from the first call center application through the call center application communication interface; receive a second call center application data request from the second call center application through the call center application communication interface; process the first call center application data request by performing first data manipulation on the first application data schema in the master application data repository, thereby relieving the first call center application from first application local database overhead; process the second call center application data request by performing second data manipulation on the second application data schema in the master application data repository, thereby relieving the second call center application from second application local database overhead; establish a common application data schema in the master data organization schema that implements a shared dataset requirement common to the first call center application and the second call center application.

[0013] Other systems, methods, features and advantages will be, or will become, apparent to one with skill in the art upon examination ofthe following figures and detailed description. It is intended that all such additional systems, methods, features and advantages be included within this description, be within the scope of the invention, and be protected by the following claims.

BRIEF DESCRIPTION OF THE DRAWINGS

[0014] The innovation may be better understood with reference to the following drawings and description. The components in the figures are not necessarily to scale, emphasis instead being placed upon illustrating the principles of the invention. Moreover, in the figures, like referenced numerals designate corresponding parts throughout the different views.

[0015] Figure 1 shows a call center application data and interoperation architecture.

CA 02648383 2013-12-06

71035-54PPH

[0016] Figure 2 shows a call center application data and interoperation architecture including a schema subdivision defining multiple individual application data schemas for specific applications.

[0017] Figure 3 shows a portion of a common application data schema that 5 implements a shared data set requirement common to multiple call center applications.

[0018] Figure 4 shows a Case Management application data schema.

[0019] Figure 5 shows a Case Management application data schema.

[0020] Figure 6 shows a Case Management application data schema.

[0021] Figure 7 shows a Case Management application data schema.

[0022] Figure 8 shows a Leave application data schema.

[0023] Figure 9 shows a Leave application data schema.

[0024] Figure 10 shows a Commitment Log application data schema.

[0025] Figure 11 shows an Attendance application data schema.

CA 02648383 2009-01-05

[0026] Figure 12 shows a Movement application data schema.

[0027] Figure 13 shows an Attrition application data schema.

[0028]Figures 14 - 34 show examples of graphical user interfaces (GUIs) and reports that a human resources application may implement.

[0029]Figures 35 - 48 show examples of GUIs and reports that the attrition application may implement.

[0030]Figures 49 - 56 show examples of GUIs and reports that the commitment log application may implement.

[0031]Figures 57 - 65 show examples of GUIs and reports that the leave application io may implement.

[0032] Figures 66 - 71 show examples of GUIs and reports that the attendance application may implement.

[0033]Figures 72 - 87 show examples of GUIs and reports that the My OneView application may implement.

[0034]Figures 88 - 95 show examples of GUIs and reports that the transportation application may implement.

[0035]Figures 96 - 109 show examples of GUIs and reports that a case management application may implement.

[0036]Figures 110 - 112 show examples of GUIs and reports that the ID management application may implement.

[0037]Figures 113 - 117 show examples of GUIs and reports that the movement application may implement.

[0038] Figure 118 shows one example of logic flow for coordinating the operation of multiple call center applications in a call center architecture.

[0039] Figure 119 shows one example of logic flow for authenticating a user.

[0040] Figure 120 shows one example of a graphical user interface that displays a checklist to a user while the user is taking a call.

Detailed Description

[0041] Figure 1 shows a call center application and interoperation architecture 100

CA 02648383 2009-01-05 (architecture 100). The architecture 100 provides a consistent and timely view of key records and improves the individual performance by empowering agents with their own information. The architecture 100 also provides the ability to drill from dashboards into analytical and detailed reports, both historical and real-time, for root cause analysis. A central repository of all the events in the organization provides accurate, timely, and secure data storage.

[0042] In particular, the central repository may be implemented as a master application data repository 102. In the master application data repository 102, data is organized according to a master data organization schema 104. The master data organization io schema 104 will be described in more detail below.

[0043]The architecture 100 coordinates the processing of multiple call center applications and their interactions with the master application data repository 102. Examples of applications shown in Figure 1 include a Case Management application, have three logical parts: an Accounts Integrity Management (AIM) application 106, an online order processing (KANA) application 108, and a Sales Order Entry (SOE) application 110. The AIM application 106 may, for example, provide a GUI and processing logic that allow users to correct account errors or otherwise maintain the integrity of any account. The KANA application 108 may provide a GUI and processing logic for processing online web orders. The SOE application 110 may provide a GUI and processing logic for processing telephone orders. Thus, once a customer subscribes over the phone, the SOE team loads the order into the system through the SOE application 110.

[0044] Other examples of applications include the Commitment Log application 112, the

Attrition application 114, the Identification Management application 116, the Employee

Details application 118, and the Leave application 120. Additional examples of applications include the Attendance application 122, the Transport application 124, the Movement Management application 126, and the human resources (HRIS) application 128.

[0045]The architecture 100 implements a hub and spoke design. The applications 106

-120 exchange data with the master application data repository 102, which relieves each individual application of local database overhead and processing requirements.

CA 02648383 2009-01-05

Additional, different, or fewer applications may be running in the architecture 100.

[0046] Figure 1 also shows that the architecture 100 provides administrative access for the administration team 130. The administration team 130 may interact with the architecture 100 through a user interface through which authorized users may update personnel data maintained by the weekly roster module 132, or may make other changes to data stored in the master application data repository 102. In addition, a scheduling team 134 may provide input into the weekly roster module 132. Accordingly, the weekly roster application 132 maintains an up-to-date view of the employees and their schedules assigned to any particular process for a particular week. Furthermore, io an upload process 136 may be established to manually or automatically upload attendance data into the attendance application 122.

[0047]Call centers work on shifts, and any employee can be scheduled to work in any shift. The schedule includes their working days and weekly offs (their time off). The scheduling team 134 prepares rosters of employees in shifts based on many different parameters. The architecture 100 makes the roster available every week (e.g., in an Excel (TM) spreadsheet format). The administration team 130 or scheduling team 134 enters weekly employee rosters into the architecture 100 (e.g., into the attendance module) through the upload process 136.

[0048]The processing in the architecture 100 may be hosted on an Internet Information

Web Server (IIS). The processing may be implemented, as examples, in C# and using ASP.NET, with the data stored in a SQL 2000 database. For example, the databases and data schemas described above may be implemented with Microsoft® SQL Server 2000, Microsoft SQL Server version 7.0, or other database server technology. The relational database engine can return data as Extensible Markup Language (XML) documents. Additionally, XML can also be used to insert, update, and delete values in the database.

[0049] Furthermore, the architecture may run multiple instances of the relational database engine on the same or different machine. Each instance may have its own set of system and user databases. Applications can connect to each instance on a single machine similar to the way they connect to instances running on different machines.

CA 02648383 2013-09-09

71035-54

[0050] Other technology that may be used to implement the architecture includes Asynchronous JavaScript and XML (AJAX) to create interactive Web applications, XHTML, for stricter, cleaner rendering of HTML into XML, Cascading Style Sheets (CSS) for marking up and adding styles, Javascript Document Object Model (DOM) for providing content, structure and style of a document to be dynamically accessed and updated, and an XMLHttpRequest object which exchanges data asynchronously with the Web server and reduces the need to continually fetch resources from the server. [0051] Since data can be sent and retrieved without requiring the user to reload an entire Web page, small amounts of data can be transferred as and when required.

io Moreover, page elements can be dynamically refreshed at any level of granularity to reflect this. Unchanged information need not be sent across the network. The implementation may be standardized around the W3C ‘Document Object Model (DOM) Level 3 Load and Save Specification’ or other specification.

[0052] In addition to the applications described above, the architecture 100 may provide additional functionality. For example, the architecture 100 may provide an employee information access application 136 (My OneView). The My OneView application 136 may be accessed by any employee to review leave balance, schedules, holiday lists, and other aspects of employment associated with the employee. Additional examples are described in more detail below.

[0053] Figure 2 shows another view of the call center application data and interoperation architecture 100 including a schema subdivision 202 defining multiple individual application data schemas 204 - 218 for specific applications. The schema subdivision 202 may be a logical or physical partitioning of database tables, fields, and other structures into sets of tables, fields, and other information specific to individual call center applications. In addition, the master data organization schema 104 defines a common application data schema 220. The common application data schema 220 may include fields, tables or other structures that multiple applications use to share data or have common access to in order to support their processing roles.

[0054] Examples of individual application data schemas in Figure 2 include: a Case

Management AIM data schema 204, a Commitment Log data schema 206, a Case Management ΚΑΝΑ data schema 208, and an Attrition data schema 210. Additional

CA 02648383 2013-09-09

71035-54 examples include: a leave data schema 212, a movement data schema 214, a Case Management SOE data schema 216, and an attendance data schema 218. The data schemas 204 - 218 maintain the data specific to a particular application. More specifically, each data schema 204 - 218 supports a specific application data set requirement. For example, the Attrition data schema 210 includes tables and fields for maintaining any data that the Attrition application 114 manipulates, sends, receives, displays, or otherwise processes in performing its attrition management, tracking, and reporting role. The subdivision 202 ensures a clean separation between the data set requirements for each call center applications, rather than smearing all of the data set io requirements across a set of tables and fields common to multiple applications.

[0055] The individual applications may communicate with the rest of the architecture 100 over one or more local or remote networks or interconnection of such networks. The individual applications may submit data requests, and receive data responses from the architecture 100 as they perform their processing. To that end, the architecture 100 implements a communication interface 222, and includes a processor 224 that may receive the data requests, process the data requests, and return data responses to the individual applications. More specifically, a memory 226 may store data request processing logic 228, such as a database management application.. The data request processing logic 228 receives data requests (such as the attendance data request 230 and the attrition data requests 232). In, response, the data request processing logic 228 process the data requests by performing data manipulation (e.g., database queries, or database reads, writes, or updates) responsive to the data requests. The data request processing logic 228 adheres to the application data schemas in the master application data repository 102 so that specific application data schemas support specific call center application. One result is that the architecture 100 relieves the call center applications 106 - 128 from local database proceseing overhead, and provides centralized storage and control over the call center data across multiple applications. [0056] Specific examples of call center application data schemas are given in the tables below.

[0057]The following Tables 1-4 show a transport application data schema that may support the Transportation application 124.

CA 02648383 2009-01-05

<td colspan="4"> Table 1 : ADHOC Jbl_RequestAction This table stores information about adhoc transportation requests.</td>

<td> Data field</td><td> Data Type</td><td> Constraints</td><td> Description</td>

<td> inActionld</td><td> Integer</td><td> Primary Key</td><td> Unique identifier to identify the possible actions that can be taken for adhoc transport requests.</td>

<td> vcActionName</td><td> string</td><td> Not Null</td><td> Describe whether adhoc is approved/denied/forwarded.</td>

<td> vcActionDescription</td><td> string</td><td> Not Null</td><td></td>

<td> vcNextPossibleAction</td><td> string</td><td> Null</td><td> Describe adhoc approved/denied/forwarded.</td>

<td> inActionType</td><td> integer</td><td> Not Null</td><td> 1. Logged 2. Forwarded/ Approved 3. Closed</td>

<td> inSquenceOrder</td><td> Integer</td><td> Not Null</td><td> Order in which to display the actions</td>

<td> IsbolActive</td><td> bit</td><td> Not Null</td><td> Whether the current action can be executed (Active)or not (Inactive).</td>

<td> dtCreatedOn</td><td> date</td><td> Not Null</td><td> Date on which the action was entered into the database.</td>

<td> inCreatedBy</td><td> numeric</td><td> Not Null</td><td> The action was created by which user</td>

<td colspan="4"> Table 2: ADHOC_tbl_RequestDetails This table describes the action taken on the adhoc transportation requests.</td>

<td> Data field</td><td> Data Type</td><td> Constraints</td><td> Description</td>

<td> inDetailld</td><td> numeric</td><td> Primary Key</td><td> Unique identifier to identify the possible actions that can be taken for adhoc transport requests.</td>

<td> inAdhocid</td><td> numeric</td><td> Null</td><td> Reference from (Foreign Key) Adhoc tbl RequestMst.</td>

<td> inHeadID</td><td> numeric</td><td> Null</td><td> Reference from (Foreign Key) Adhoc tbl RequestHead</td>

<td> inStatus</td><td> integer</td><td> Null</td><td> 1. Adhoc requested. 2. Forwarded. 3. Approved. 4. Denied.</td>

CA 02648383 2013-09-09

71035-54

<td></td><td></td><td></td><td> 5. Sent to transport.</td>

<td> inRequestedBy</td><td> numeric</td><td> Null</td><td> Employee who is requesting.</td>

<td> dtRequestedOn</td><td> date</td><td> Null</td><td> Date on which Adhoc is requested.</td>

<td> inClosedBy</td><td> numeric</td><td> Null</td><td> Supervisor who took action.</td>

<td> dtClosedOn</td><td> date</td><td> Null</td><td> Date on which Adhoc request is closed.</td>

<td> vcComments</td><td> string</td><td> Null</td><td> Whether approved/denied.</td>

<td colspan="4"> Table 3: ADHOC_tbl_RequestHead The table stores the information when adhoc transportation is required by the employee and when it is approved.</td>

<td> Data field</td><td> Data Type</td><td> Constraints</td><td> Description</td>

<td> inHeadld</td><td> numeric</td><td> Primary Key</td><td> Unique identifier to identify the possible actions that can be taken for adhoc transport requests.</td>

<td> inAdhocId</td><td> numeric</td><td> Not Null</td><td> Reference from (Foreign Key) Adhoc tbl RequestMst.</td>

<td> inDetailld</td><td> numeric</td><td> Null</td><td> Reference from (Foreign Key). Adhoc tbl RequestDetails.</td>

<td> inRequestedBy</td><td> numeric</td><td> Not Null</td><td> Employee who is requesting for the transport.</td>

<td> dtRequestedOn</td><td> date</td><td> Not Null</td><td> Date on which the Adhoc has been requested.</td>

<td> inApprovedBy</td><td> numeric</td><td> Null</td><td> Supervisor who is approving.</td>

<td> dtApprovedOn</td><td> date</td><td> Null</td><td> Date on which it has been approved.</td>

<td> bollsClosed</td><td> bit</td><td> Not Null</td><td> Approved/Denied</td>

<td colspan="4"> Table 4: ADHOC_tbl_RequestMst</td>

<td> The table contains the</td><td colspan="3"> jcket number and other related information about the employee.</td>

<td> Data field</td><td> Data Type</td><td> Constraints</td><td> Description</td>

<td> inAdhocId</td><td> numeric</td><td> Primary Key</td><td> Unique identifier to identify the possible actions that can be taken for adhoc transport requests.</td>

<td> vcTicketNo</td><td> string</td><td> Null</td><td> New ticket is raised for each new request.</td>

<td> dtAdhocdate</td><td> date</td><td> Not Null</td><td> Date for which Adhoc is requested.</td>

<td> inTeamld</td><td> integer</td><td> Not Null</td><td> Team Leader Name.</td>

<td> inProcessId</td><td> integer</td><td> Not Null</td><td> Process which employee belongs.</td>

CA 02648383 2009-01-05

<td> inUserld</td><td> numeric</td><td> Not Null</td><td> Employee ID.</td>

<td> inSupervisorld</td><td> numeric</td><td> Not Null</td><td> Supervisor ID.</td>

<td> dtAdhocTime</td><td> date</td><td> Not Null</td><td> Time at which adhoc is required.</td>

<td> dtStarttime</td><td> date</td><td> Not Null</td><td> Shift start time.</td>

<td> dtEndtime</td><td> date</td><td> Not Null</td><td> Shift end time.</td>

<td> inAdhocType</td><td> integer</td><td> Not Null</td><td> 1. Pick 2. Drop</td>

<td> inReason</td><td> integer</td><td> Not Null</td><td> Team Meeting/Official Official.</td>

<td> vcComments</td><td> string</td><td> Not Null</td><td> Reason for Adhoc request.</td>

<td> dtCreatedOn</td><td> date</td><td> Not Null</td><td> Date on which adhoc is raised.</td>

<td> inCreatedBy</td><td> numeric</td><td> Not Null</td><td> Employee ID.</td>

[0058]The following Tables 5-11 show a Commitment Logs data schema 206 that may support the Commitment Logs application 112. Figure 5 provides additional detail. The career/organizational levels in may be defined from A to H, with A being the top level.

For example, people in Level E may be team leaders, F may be Subject Matter Experts and G & H may be team member / Customer Support Representatives having similar work profiles and commitments.

<td colspan="4"> Table 5: AGM_tbl_CommitmentLogMst (Table 1002)</td>

<td colspan="3"> The table describes the commitment the Team Leader (TL)</td><td> and the Deputy Manager (DM) has to perform.</td>

<td> Data field</td><td> Data Type</td><td> Constraints</td><td> Description</td>

<td> inLogld</td><td> integer</td><td> Primary Key</td><td> Unique identifier to identify the possible Log Activity.</td>

<td> inLogType</td><td> integer</td><td> Not Null</td><td> 1. TL Activity. 2. DM Activity.</td>

<td> vcLogName</td><td> string</td><td> Not Null</td><td> 1. Side by side monitoring. 2. Remote monitoring. 3. Team huddle Etc.</td>

<td> vcDescription</td><td> string</td><td> Null</td><td> 1.2 Per agent per month. 3. per agent per month. 3. Daily.</td>

CA 02648383 2009-01-05

<td> vcOrganizationLevel</td><td> string</td><td> Null</td><td></td>

<td> inCommitmentType</td><td> integer</td><td> Null</td><td> 1. F, G+H Level. 2. G+H Level.</td>

<td> bollsActive</td><td> bit</td><td> Not Null</td><td> Status is Active/de-active.</td>

<td> inCreatedBy</td><td> numeric</td><td> Not Null</td><td> Employee ID.</td>

<td> dtCreatedOn</td><td> date</td><td> Not Null</td><td> Date on which Created.</td>

<td> inModifiedBy</td><td> numeric</td><td> Null</td><td> Employee ID.</td>

<td> dtModifiedOn</td><td> date</td><td> Null</td><td> Date on which it is modified.</td>

<td colspan="4"> Table 6: AGM_tbl_CommitmentLogTarget (Table 1006) Target to be achieved by the supervisor.</td>

<td> Data field</td><td> Data Type</td><td> Constraints</td><td> Description</td>

<td> inTargetld</td><td> integer</td><td> Primary Key</td><td> Unique identifier to identify the possible Log Activity Target.</td>

<td> inLogld</td><td> integer</td><td> Not Null</td><td> Reference from (Foreign Key) AGM tbl CommitmentLogMst.</td>

<td> inProcessId</td><td> integer</td><td> Not Null</td><td> Process for which commitment are taken.</td>

<td> inOrganizationLevel</td><td> integer</td><td> Null</td><td> 1. E 2. F 3. G+H</td>

<td> inLogType</td><td> integer</td><td> Null</td><td> 1. TL Activity. 2. DM Activity.</td>

<td> inCommitmentType</td><td> integer</td><td> Null</td><td> 1. Team Commitment. 2. Individual Commitment.</td>

<td> inTarget</td><td> integer</td><td> Null</td><td> Target Achieved.</td>

<td> inCreatedBy</td><td> numeric</td><td> Null</td><td> Employee ID.</td>

<td> dtCreatedOn</td><td> date</td><td> Null</td><td> Date on which created.</td>

<td colspan="4"> Table 7: AGM_tbl_CommitmentLogTarget_History (Table 1008) The table describes the history of commitment targets that have been done.</td>

<td> Data field</td><td> Data Type</td><td> Constraints</td><td> Description</td>

CA 02648383 2009-01-05

<td> inTargetld</td><td> integer</td><td> Primary Key</td><td> Unique identifier to identify the possible Log Activity Target.</td>

<td> inLogld</td><td> integer</td><td> Not Null</td><td> Reference from (Foreign Key) AGM tbl CommitmentLogMst.</td>

<td> inProcessId</td><td> integer</td><td> Not Null</td><td> Process for which commitment are taken.</td>

<td> inLogType</td><td> integer</td><td> Not Null</td><td> 1. TL Activity. 2. DM Activity.</td>

<td> inCommitmentType</td><td> integer</td><td> Not Null</td><td> 1. Team Commitment. 2. Individual Commitment.</td>

<td> inOrganizationLevel</td><td> integer</td><td> Null</td><td> 1. E 2. F 3. G+H</td>

<td> inTarget</td><td> integer</td><td> Not Null</td><td> Target Achieved.</td>

<td> inCreatedBy</td><td> numeric</td><td> Not Null</td><td> Employee ID.</td>

<td> dtCreatedOn</td><td> date</td><td> Not Null</td><td> Date on which created.</td>

<td> inModifiedBy</td><td> numeric</td><td> Not Null</td><td> Employee ID.</td>

<td> dtModifiedOn</td><td> date</td><td> Not Null</td><td> Date on which modified.</td>

<td colspan="4"> Table 8: AGM_CommitmentLogType (Table 1010) The table describes the commitment of TL and DM.</td>

<td> Data field</td><td> Data Type</td><td> Constraints</td><td> Description</td>

<td> inLogType</td><td> integer</td><td> Primary Key</td><td> Unique identifier to identify the possible Log Activity Target.</td>

<td> vcLogType</td><td> string</td><td> Null</td><td> 1. TL Activity. 2. DM Activity.</td>

<td> vcLevels</td><td> string</td><td> Null</td><td> 1.Senior Manager 2. Manager 3. Deputy Manager</td>

<td> bollsActive</td><td> bit</td><td> Null</td><td> Active/de-active.</td>

<td> inCreatedBy</td><td> numeric</td><td> Null</td><td> Employee ID.</td>

<td> dtCreatedOn</td><td> date</td><td> Null</td><td> Date on which created.</td>

<td> inModifiedBy</td><td> numeric</td><td> Null</td><td> Employee ID.</td>

<td> dtModifiedOn</td><td> date</td><td> Null</td><td> Date on which modified.</td>

CA 02648383 2009-01-05

<td colspan="4"> Table 9: AGM_UserCommitment_Achieved (Table 1004) This table describes commitments achieved.</td>

<td> Data field</td><td> Data Type</td><td> Constraints</td><td> Description</td>

<td> inAchievedld</td><td> numeric</td><td> Primary Key</td><td> Unique identifier to identify the possible Log Activity Target.</td>

<td> dtAchievedOn</td><td> date</td><td> Null</td><td> Date on which target achieved,</td>

<td> inCommitmentTo</td><td> numeric</td><td> Null</td><td> Employee ID.</td>

<td> inLogld</td><td> integer</td><td> Not Null</td><td> Reference from (Foreign Key) AGM tbl CommitmentLogMst.</td>

<td> inCommitmentBy</td><td> numeric</td><td> Not Null</td><td> Employee ID.</td>

<td> inLogType</td><td> integer</td><td> Not Null</td><td> 1. TL Activity. 2. DM Activity.</td>

<td> inCommitmentType</td><td> integer</td><td> Not Null</td><td> 1. TL Activity. 2. DM Activity.</td>

<td> inLevelld</td><td> integer</td><td> Null</td><td> G+H</td>

<td> inTargetAchieved</td><td> integer</td><td> Not Null</td><td> Targets that are achieved.</td>

<td> inProcessId</td><td> integer</td><td> Null</td><td> Process.</td>

<td> vcComments</td><td> string</td><td> Null</td><td> One on One.</td>

<td> inMonth</td><td> integer</td><td> Null</td><td> How many completed.</td>

<td> inYear</td><td> integer</td><td> Null</td><td> Which year.</td>

<td colspan="4"> Table 10: AGM_tbl_UserCommitment_Schedule (Table 1014) The table describes the commitments that are scheduled for the week.</td>

<td> Data field</td><td> Data Type</td><td> Constraints</td><td> Description</td>

<td> inScheduleld</td><td> numeric</td><td> Primary Key</td><td> Unique identifier to identify the possible Activity Scheduled.</td>

<td> inUserld</td><td> numeric</td><td> Null</td><td> Employee ID.</td>

<td> inProcessId</td><td> integer</td><td> Null</td><td> Process Name.</td>

<td> dtCommitmentdate</td><td> date</td><td> Null</td><td> Date on which committed.</td>

<td> dtFromtimeStamp</td><td> date</td><td> Null</td><td> Starting date.</td>

<td> dtTotimeStamp</td><td> date</td><td> Null</td><td> End date.</td>

<td> inLogld</td><td> integer</td><td> Null</td><td> Reference from (Foreign Key)</td>

CA 02648383 2009-01-05

<td></td><td></td><td></td><td> AGM tbl CommitmentLogMst.</td>

<td> inLogType</td><td> integer</td><td> Null</td><td> 1. TL Activity. 2. DM Activity.</td>

<td> inCommitmentType</td><td> integer</td><td> Null</td><td> 1. Individual Commitment. 2. Team Commitment.</td>

<td> inScheduledTarget</td><td> integer</td><td> Null</td><td> Target to be achieved.</td>

<td> vcComments</td><td> string</td><td> Null</td><td> Reason.</td>

<td> inMonth</td><td> integer</td><td> Null</td><td> How many completed.</td>

<td> inYear</td><td> integer</td><td> Null</td><td> How many in one year.</td>

<td> inCreatedBy</td><td> numeric</td><td> Null</td><td> Employee ID.</td>

<td> dtCreatedOn</td><td> date</td><td> Null</td><td> Date on which created.</td>

<td> inModifiedBy</td><td> numeric</td><td> Null</td><td> Employee ID.</td>

<td> dtModifiedOn</td><td> date</td><td> Null</td><td> Date on which modified.</td>

<td colspan="4"> Table 11: AGM_tbl_UserCommitment_Target (Table 1012) The table describes the target that are to be achieved.</td>

<td> Data field</td><td> Data Type</td><td> Constraints</td><td> Description</td>

<td> inTargetld</td><td> numeric</td><td> Primary Key</td><td> Unique identifier to identify the possible Target.</td>

<td> inCommitmentBy</td><td> numeric</td><td> Not Null</td><td> Employee ID.</td>

<td> inCommitmentTo</td><td> numeric</td><td> Not Null</td><td> 1. TL 2. DM.</td>

<td> inLogld</td><td> integer</td><td> Not Null</td><td> Reference from (Foreign Key) AGM tbl CommitmentLogMst.</td>

<td> inLogType</td><td> integer</td><td> Not Null</td><td> 1. TL Activity. 2. DM Activity.</td>

<td> inCommitmentType</td><td> integer</td><td> Not Null</td><td> 1. Individual Commitment. 2. Team Commitment.</td>

<td> inLevelld</td><td> integer</td><td> Null</td><td> G+H.</td>

<td> inTargetAssigned</td><td> integer</td><td> Not Null</td><td> Total target assigned.</td>

<td> inTargetAchieved</td><td> integer</td><td> Not Null</td><td> Target achieved.</td>

<td> inProcessid</td><td> integer</td><td> Null</td><td> Process Name.</td>

<td> inMonth</td><td> integer</td><td> Null</td><td> Achieved each month.</td>

<td> inYear</td><td> integer</td><td> Null</td><td> Achieved in year.</td>

CA 02648383 2009-01-05

[0059]The following Table 12 shows a human resources IS (HRIS) data schema that may support the HRIS application 128 roster functionality.

<td colspan="4"> Table 12: HRIS_RPT_ViewRoster</td>

<td> This table describes the u</td><td colspan="3"> ser who has viewed the data.</td>

<td> Data field</td><td> Data Type</td><td> Constraints</td><td> Description</td>

<td> inViewUser</td><td> numeric</td><td> Not Null</td><td> Employee ID.</td>

<td> dttimeStamp</td><td> date</td><td> Not Null</td><td> Date on which viewed.</td>

<td> inUserld</td><td> numeric</td><td> Not Null</td><td> Employee ID.</td>

<td> inLocationld</td><td> integer</td><td> Null</td><td> 1. Mumbai 2. Bangalore.</td>

<td> vcLocation</td><td> string</td><td> Null</td><td> Bangalore/Mumbai.</td>

<td> vcEmployeeCode</td><td> string</td><td> Null</td><td> Employee ID.</td>

<td> vcEmployeeName</td><td> string</td><td> Null</td><td> Employee Name.</td>

<td> inProcessId</td><td> integer</td><td> Null</td><td> 1. Dial 2. Dsl 3. Felix</td>

<td> vcProcessName</td><td> string</td><td> Null</td><td> Felix/Dsl/Dial.</td>

<td> inTeamld</td><td> integer</td><td> Null</td><td> Supervisor ID.</td>

<td> vcTeamName</td><td> string</td><td> Null</td><td> Supervisor Name.</td>

<td> vcShiftStart</td><td> string</td><td> Null</td><td> Start Time.</td>

<td> vcShiftEnd</td><td> string</td><td> Null</td><td> End Time.</td>

<td> vcStatus</td><td> string</td><td> Null</td><td> 1. Scheduled. 2. Weekly Off</td>

[0060]The following Tables 13 - 16 show an Attendance data schema 218 that may support the attendance application 122. Figure 11 provides additional detail.

Table 13: HRISJbl_Attendance_Details (Table 1108)

This table saves the information about the attendance of the employee.

CA 02648383 2009-01-05

<td> Data field</td><td> Data Type</td><td> Constraints</td><td> Description</td>

<td> inDetailsid</td><td> numeric</td><td> Primary key</td><td> Unique identifier to identify the details.</td>

<td> inHeadld</td><td> numeric</td><td> Not Null</td><td> Reference from(Foreign Key) ADHOC tbl RequestHead</td>

<td> dtAttendance</td><td> date</td><td> Not Null</td><td> Present day.</td>

<td> inUserlD</td><td> numeric</td><td> Not Null</td><td> Employee ID.</td>

<td> inParameterlD</td><td> integer</td><td> Not Null</td><td> Reference from(Foreign Key) HRIS tbl AttendanceParameter</td>

<td> inRosterld</td><td> numeric</td><td> Null</td><td> Reference from(Foreign Key) HRIS tbl RosterHead.</td>

<td> inRosterType</td><td> integer</td><td> Null</td><td></td>

<td> inAttritionld</td><td> numeric</td><td> Not Null</td><td> Reference from(Foreign Key) H RI S tbl Attrition Mst.</td>

<td> bolSelfMarked</td><td> bit</td><td> Not Null</td><td> 1. Self Marked. 2. Supervisor Marked.</td>

<td> vcComments</td><td> string</td><td> Null</td><td> 1. Attendance Marked. 2. Attendance not Marked.</td>

<td> inLocationld</td><td> integer</td><td> Null</td><td> 1. Mumbai 2. Bangalore</td>

<td> inDesignation</td><td> integer</td><td> Null</td><td> 1 .Analyst 2.Agent</td>

<td> inMarkedBy</td><td> numeric</td><td> Null</td><td> Employee ID.</td>

<td> dtMarkedOn</td><td> date</td><td> Null</td><td> Date on which attendance is marked.</td>

<td colspan="4"> Table 14: HRIS_tbl_Attendance„Head (Table 1102) This table has the information about the Employee Status.</td>

<td> Data field</td><td> Data Type</td><td> Constraints</td><td> Description</td>

<td> inHeadld</td><td> numeric</td><td> Primary Key</td><td> Unique identifier to identify the details.</td>

<td> dtAttendance</td><td> date</td><td> Not Null</td><td> Attendance date.</td>

<td> inTeamID</td><td> integer</td><td> Not Null</td><td> Reference from(Foreign Key) Sys tbl ProcessTeams.</td>

<td> inParentTeam</td><td> integer</td><td> Null</td><td> Reference from(Foreign Key)</td>

CA 02648383 2009-01-05

<td></td><td></td><td></td><td> Sys tbl ProcessTeams.</td>

<td> inProcessID</td><td> integer</td><td> Not Null</td><td> 1. Dsl 2. Dial 3. Felix</td>

<td> inSupervisorlD</td><td> numeric</td><td> Not Null</td><td> Supervisor ID.</td>

<td> inHeadCount</td><td> integer</td><td> Null</td><td> Total Strength.</td>

<td> inPreRosterabsenteei sm</td><td> integer</td><td> Null</td><td> Employee who is rostered but not present.</td>

<td> inPostRosterabsente eism</td><td> integer</td><td> Null</td><td> Employee who has informed before the roster.</td>

<td> inNotMarked</td><td> integer</td><td> Null</td><td> Total attendance not marked.</td>

<td> inWeeklyOffs</td><td> integer</td><td> Null</td><td> Total weekly Off.</td>

<td> inPresent</td><td> integer</td><td> Not Null</td><td> Total Present.</td>

<td> inAttrition</td><td> integer</td><td> Null</td><td> Total Attrition.</td>

<td> inSickLeaves</td><td> integer</td><td> Null</td><td> Total Sick Leave.</td>

<td> inUnauthorisedLeave s</td><td> integer</td><td> Not Null</td><td> Not approved leaves</td>

<td> bolVerified</td><td> bit</td><td> Not Null</td><td> If verified.</td>

<td> inVerifiedby</td><td> numeric</td><td> Null</td><td> Employee ID.</td>

<td> dtVerifiedOn</td><td> date</td><td> Null</td><td> Date on which verified.</td>

<td colspan="4"> Table 15: HRIS_tbl_Attendance_History This table contains the history ofthe employee attendance.</td>

<td> Data field</td><td> Data Type</td><td> Constraints</td><td> Description</td>

<td> inDetailsid</td><td> numeric</td><td> Not Null</td><td> Unique identifier to identify the details.</td>

<td> inHeadld</td><td> numeric</td><td> Not Null</td><td> Reference from(Foreign Key) HRIS tbl Attendance Head</td>

<td> dtAttendance</td><td> date</td><td> Not Null</td><td> Attendance Date.</td>

<td> inUserlD</td><td> numeric</td><td> Not Null</td><td> Employee ID.</td>

<td> inParameterlD</td><td> integer</td><td> Not Null</td><td> 1 .Sick Leave 2. Present 3. Planned Leave</td>

<td> inOldParameterlD</td><td> integer</td><td> Not Null</td><td></td>

CA 02648383 2009-01-05

<td> inRosterld</td><td> numeric</td><td> Null</td><td> Reference from(Foreign Key) HRISJbLRosterHead</td>

<td> inRosterType</td><td> integer</td><td> Null</td><td></td>

<td> inAttritionld</td><td> numeric</td><td> Not Null</td><td> Reference from(Foreign Key) HRlS tbl Attrition Mst</td>

<td> bolSelfMarked</td><td> bit</td><td> Not Null</td><td> If attendance is self marked.</td>

<td> vcComments</td><td> string</td><td> Null</td><td> Remarks.</td>

<td> inMarkedBy</td><td> numeric</td><td> Null</td><td> Employee ID.</td>

<td> dtMarkedOn</td><td> date</td><td> Null</td><td> Date on which marked.</td>

<td> inModifiedBy</td><td> numeric</td><td> Null</td><td> Employee ID.</td>

<td> dtModifiedOn</td><td> date</td><td> Null</td><td> Date on which modified.</td>

<td colspan="4"> Table 16: HRIS_tbl_AttendanceParameter (Table 1110) This table contains the parameter about the status of employee like present, leave.</td>

<td> Data field</td><td> Data Type</td><td> Constraints</td><td> Description</td>

<td> inParameterlD</td><td> integer</td><td> Primary Key</td><td> Unique identifier to identify the details.</td>

<td> inParameterType</td><td> integer</td><td> Not Null</td><td></td>

<td> vcParameter</td><td> string</td><td> Not Null</td><td> 1.Present 2.Sick Leave 3.Planned Leave</td>

<td> vcCode</td><td> string</td><td> Not Null</td><td> 1.P 2.SL 3.PL</td>

<td> vcNotes</td><td> string</td><td> Null</td><td> 1. Present 2. Paid Leave 3.Sick Leave</td>

<td> chSexAppiicable</td><td> string</td><td> Not Null</td><td> Null</td>

<td> bolHoliday</td><td> bit</td><td> Not Null</td><td> 1. Present 2. Weekly Off</td>

<td> bolActive</td><td> bit</td><td> Not Null</td><td> Active.</td>

<td> bolShowBalance</td><td> bit</td><td> Not Null</td><td> Balance.</td>

<td> inSeqOrder</td><td> integer</td><td> Not Null</td><td> Sequence.</td>

<td> inCreatedBy</td><td> numeric</td><td> Not Null</td><td> Employee ID.</td>

<td> dtCreatedOn</td><td> date</td><td> Not Null</td><td> Date of Creation.</td>

CA 02648383 2009-01-05

<td> inModifiedBy</td><td> numeric</td><td> Null</td><td> Employee ID.</td>

<td> dtModifiedOn</td><td> date</td><td> Null</td><td> Date of Modification.</td>

[0061]The following Tables 17 - 20 show an Attrition data schema 210 that may support the Attrition application 114. Figure 13 provides additional detail.

<td colspan="4"> Table 17: HRIS_tbl_Attrition_History (Table 1302) The table contains the history of attritioned employees.</td>

<td> Data field</td><td> Data Type</td><td> Constraints</td><td> Description</td>

<td> inAttritionlD</td><td> numeric</td><td> Primary Key</td><td> Unique identifier to identify the details.</td>

<td> vcTicketNo</td><td> string</td><td> Null</td><td> Ticket for each attrition.</td>

<td> inAttritionType</td><td> integer</td><td> Not Null</td><td> 1. Approval Pending 2. Approved 3. Released</td>

<td> inProcessID</td><td> integer</td><td> Not Null</td><td> 1. Dial 2. Dsl 3. Felix</td>

<td> inTeamID</td><td> integer</td><td> Not Null</td><td> Reference from(Foreign Key) Sys tbl ProcessTeams</td>

<td> inSupervisorlD</td><td> integer</td><td> Not Null</td><td> Supervisor ID.</td>

<td> inUserlD</td><td> integer</td><td> Not Null</td><td> Employee ID.</td>

<td> inHrRepresntative</td><td> decimal</td><td> Not Null</td><td> HR ID.</td>

<td> inAttritionStatus</td><td> integer</td><td> Not Null</td><td> 1. Approval Pending 2. Approved 3. Released</td>

<td> dtResignation</td><td> date</td><td> Not Null</td><td> Date of resignation.</td>

<td> dtLastWorking</td><td> date</td><td> Null</td><td> Last working day.</td>

<td> inReasonld</td><td> integer</td><td> Not Null</td><td> Reason ID.</td>

<td> bolNoticePeriodWaiver</td><td> bit</td><td> Not Null</td><td> Notice period.</td>

<td> Boldocumentrecived</td><td> bit</td><td> Not Null</td><td> Document received.</td>

<td> dtlnitiatedOn</td><td> date</td><td> Not Null</td><td> Date on which resigned.</td>

<td> inlnitiatedBy</td><td> decimal</td><td> Not Null</td><td> Employee ID.</td>

<td> vcComments</td><td> string</td><td> Null</td><td> 1. Resigned 2. Absconding</td>

CA 02648383 2009-01-05

<td></td><td></td><td></td><td> 3.Approved</td>

<td> inApprovedBy</td><td> numeric</td><td> Null</td><td> Employee ID</td>

<td> dtApprovedOn</td><td> date</td><td> Null</td><td> Date on which approved.</td>

<td> vcApproverComments</td><td> string</td><td> Null</td><td> Employee ID.</td>

<td> inModifiedBy</td><td> numeric</td><td> Null</td><td> Employee ID.</td>

<td> dtModifiedOn</td><td> date</td><td> Null</td><td> Date of modification.</td>

<td> vcReason2</td><td> string</td><td> Null</td><td> Reason for resigning.</td>

<td> vcReason3</td><td> string</td><td> Null</td><td> Reason for resigning.</td>

<td> vcEmpPerformance</td><td> string</td><td> Null</td><td> Grade</td>

<td colspan="4"> Table 18: HRIS_tbl_Attrition_Mst (Table 1304) The table contains the status of Attrition e.g., released.</td>

<td> Data field</td><td> Data Type</td><td> Constraints</td><td> Description</td>

<td> inAttritionlD</td><td> numeric</td><td> Primary Key</td><td> Unique identifier to identify the details.</td>

<td> vcTicketNo</td><td> string</td><td> Null</td><td> Ticket for each attrition.</td>

<td> inAttritionType</td><td> int</td><td> Not Null</td><td> 1. Approval Pending 2. Approved 3. Released</td>

<td> inProcessID</td><td> int</td><td> Not Null</td><td> 1. Dial 2. Dsl 3. Felix</td>

<td> inTeamID</td><td> int</td><td> Not Null</td><td> Reference from(Foreign Key) Sys tbl ProcessT earns</td>

<td> inSupervisorlD</td><td> int</td><td> Not Null</td><td> Supervisor ID.</td>

<td> inUserlD</td><td> int</td><td> Not Null</td><td> Employee ID.</td>

<td> inHrRepresntative</td><td> decimal</td><td> Not Null</td><td> HR ID.</td>

<td> inAttritionStatus</td><td> int</td><td> Not Null</td><td> 1. Approval Pending 2. Approved 3. Released</td>

<td> dtResignation</td><td> date</td><td> Not Null</td><td> Date of resignation.</td>

<td> dtLastWorking</td><td> date</td><td> Null</td><td> Last working day.</td>

<td> inReasonld</td><td> integer</td><td> Not Null</td><td> Reason for leaving.</td>

<td> bolNoticePeriodWaiver</td><td> bit</td><td> Not Null</td><td> Notice period completed.</td>

CA 02648383 2009-01-05

<td> Boldocumentrecived</td><td> bit</td><td> Not Null</td><td> Document received.</td>

<td> dtlnitiatedOn</td><td> date</td><td> Not Null</td><td> Date on which resigned.</td>

<td> inlnitiatedBy</td><td> decimal</td><td> Not Null</td><td> Employee ID.</td>

<td> vcComments</td><td> string</td><td> Null</td><td> 1. Resigned 2. Absconding 3. Approved</td>