01-04-2014, 12:11 PM
SWOT - Sales Tax Workload Distribution System
[attachment=60724]
Introduction
The purpose of this document is to define scope and requirements of Workload Distribution System to allocate equitable work amongst officers at Sales Tax Department. Such flow of work is in form of new registrations, refund processing and CST declaration. The proposed system will automate the work allocation to each officer at the Department of Sales Tax on a real time basis, while ensuring equal workload on each officer.
This document should be used by the development team to architect the solution the project.
Management Summary
Sales Tax Department has a challenge to manage the large influx of work that flows daily in form of new registration requests, refund processing and processing of CST declarations. These are referred as work types. This work needs to be allocated to its officer on an equitable basis so that each officer has virtually the same workload with him/her. Since the number of requests runs in to several hundreds and each request has a different processing complexity, this allocation task itself becomes prohibitively complex and results in to delays and customer dissatisfaction. The problem is further compounded as the work type needs a specific skill to complete it; plus each work type has a priority for completion.
High Level Architecture
SWOT’s high level logical architecture is illustrated through the diagram shown in figure 1 below. It will have following categories of users, also referred as officers:
1. Assistant/Deputy Commissioner (to whom work is assigned)
2. Joint/Additional Commissioner (who are consulted as SME and view their dashboards)
3. Commissioner (who has overall access to dashboards)
Database Design Guidelines
This involves the transformation of the use cases, state diagrams, and logical object model into detailed and optimized physical database table designs.
Typically persistent classes will map to table(s) with their attributes as columns of the table. In some cases a high level object may map in to a master-child table. Invoice is one such example where it maps in to "invoice_header" and "invoice_line_item" table.
Associations between two persistent objects are realized as foreign keys to the associated objects. A foreign key is a column in one table that contains the primary key value of the associated object.
Similarly, a standard technique in relational modeling is to use an intersection entity to represent many-to-many associations. Following is a broad checklist for physical database database design:
1. Database must be properly normalized except those instances where de-normalization help improves performance. This option must be used with special care.
2. All persistent classes that use the database for persistency must map to database structures.
3. Many-to-many relationships must have an intersecting table.
4. Primary keys should be defined for each table, unless there is a performance reason not to define a primary key.
5. Indexes should be defined to optimize access.
6. Data and referential integrity constraints should be defined.
[attachment=60724]
Introduction
The purpose of this document is to define scope and requirements of Workload Distribution System to allocate equitable work amongst officers at Sales Tax Department. Such flow of work is in form of new registrations, refund processing and CST declaration. The proposed system will automate the work allocation to each officer at the Department of Sales Tax on a real time basis, while ensuring equal workload on each officer.
This document should be used by the development team to architect the solution the project.
Management Summary
Sales Tax Department has a challenge to manage the large influx of work that flows daily in form of new registration requests, refund processing and processing of CST declarations. These are referred as work types. This work needs to be allocated to its officer on an equitable basis so that each officer has virtually the same workload with him/her. Since the number of requests runs in to several hundreds and each request has a different processing complexity, this allocation task itself becomes prohibitively complex and results in to delays and customer dissatisfaction. The problem is further compounded as the work type needs a specific skill to complete it; plus each work type has a priority for completion.
High Level Architecture
SWOT’s high level logical architecture is illustrated through the diagram shown in figure 1 below. It will have following categories of users, also referred as officers:
1. Assistant/Deputy Commissioner (to whom work is assigned)
2. Joint/Additional Commissioner (who are consulted as SME and view their dashboards)
3. Commissioner (who has overall access to dashboards)
Database Design Guidelines
This involves the transformation of the use cases, state diagrams, and logical object model into detailed and optimized physical database table designs.
Typically persistent classes will map to table(s) with their attributes as columns of the table. In some cases a high level object may map in to a master-child table. Invoice is one such example where it maps in to "invoice_header" and "invoice_line_item" table.
Associations between two persistent objects are realized as foreign keys to the associated objects. A foreign key is a column in one table that contains the primary key value of the associated object.
Similarly, a standard technique in relational modeling is to use an intersection entity to represent many-to-many associations. Following is a broad checklist for physical database database design:
1. Database must be properly normalized except those instances where de-normalization help improves performance. This option must be used with special care.
2. All persistent classes that use the database for persistency must map to database structures.
3. Many-to-many relationships must have an intersecting table.
4. Primary keys should be defined for each table, unless there is a performance reason not to define a primary key.
5. Indexes should be defined to optimize access.
6. Data and referential integrity constraints should be defined.