Note: The following documents have been converted from the original format of MS Word.  Some formatting used in the original document is not available in this format.

 

The following examples are from my work at various telecommunications companies.  

 

 

My Role: Sr. Business Systems Analyst

 

Reporting Data Collection Document

 

Technical Specification for June 2010 Release

 

Projects Included in this Document

 

198746 – Shared Equipment/ Payment Responsibility

 

179133 – Generally Available ESLA Reporting Web Access

 

108470 – TCM Inventory Reports

 

933 – Auto Domain Loads Per Blitz

 

 

 

No Reporting has been identified for the Following Projects in This Release:

 

191666 P. Tax Exempt Enhancements

 

195083 – Business Offers and Promotions Phase 3 – Includes Bulk Orders – All reporting is included in the August Release.

 

216375a – Revised ETF

 

108445 – ATG Content Administration & Merchandiser Integration

 

Project Assumptions

 

For 943 Auto Domain Loads Per P.: All reporting will be on new profiles only.

 

Clearance Level : All proprietary information has been removed to protect my clients.
Last Update: 5/5/2010
Revision: V0.07

 

 

 

Table of Contents

 

1     Release Specifics. 5

 

1.1     Document Contacts. 5

 

1.2     Revisions. 5

 

1.3     Related Documents. 5

 

1.4     Clickstream & Reporting Summary. 6

 

1.4.1     Reporting Risks. 6

 

2     Data Capture Tagging for Clickstream… 6

 

2.1     FRs Not Addressed by this Document. 7

 

2.2     Common Page Views Data Capture Elements. 7

 

2.2.1     Business Requirements and Technical Specifications Addressing Page Views. 7

 

2.3     Common Link Tracking Data Capture Elements. 9

 

2.3.1     Business Requirements Addressing Link Tracking and Technical Specifications. 9

 

2.4     Common Action Event Tracking. 11

 

2.4.1     Business Requirements Events and Technical Specifications Addressing Action Events. 11

 

2.5     Add/Remove from Cart Tracking. 13

 

2.5.1     Business Requirements and Technical Specifications Addressing Add and Remove Cart Tracking. 13

 

2.6     Check Out Tracking. 13

 

2.6.1     Business Requirements and Technical Specifications for Check Out Tracking. 13

 

2.7     Download Tracking. 13

 

2.7.1     Business Requirements and Technical Specifications addressing Download Tracking. 13

 

3     Business Objects (BO) & eDM Details. 15

 

3.1     BO Naming. 16

 

3.2     BO Folder Organization. 17

 

4     Report Writer Specifications. 18

 

4.1     Business Requirements and Technical Specifications for Report Writer. 18

 

5     Extract Specifications. 19

 

5.1     Business Requirements and Technical Specifications for Extracts. 19

 

Appendix A – Reporting Reference Data.. 21

 

6     Event Naming Conventions. 21

 

7     Event Type Definition and Purpose. 21

 

8     Status Code Use and Purpose. 21

 

9     Query String Retention.. 22

 

Appendix B – WebTrends Standard Tags & Code. 23

 

10     WT Base Tag.. 23

 

11     WebTrends Meta Tagging for Page Views. 23

 

12     WebTrends Meta Tagging for Link Tracking.. 24

 

13     WebTrends Meta Tagging for Action Events. 24

 

14     WebTrends Meta Tagging for Add and Remove Cart Tracking.. 26

 

15     WebTrends Meta Tagging for Check Out Tracking.. 28

 

16     Download Link Tracking WebTrends Meta Tagging.. 28

 

17     Valid Event Names for Existing Processes. 28

 

Appendix C – Template Reference Data.. 31

 

18     Template Revision History. 31

 

19     Confidentiality Legend.. 31

 

20     Project Complexity Legend.. 31

 

21     6/12/2010 Release Project Complexity Grid.. 32

 

1           Release Specifics

 

Responses to BR/FR Document for the following projects

 

  • 216375a – Revised ETF
  • 198746 – Shared Equipment/ Payment Responsibility
  • 179133 – Generally Available ESLA Reporting Web Access
  • 108470 – TCM Inventory Reports
  • 194343 – Auto Domain Loads Per Blitz

 

Project Files can be found at:

 

Note: Hyperlink was here to SharePoint project files.

 

Copy the above into the browser to retrieve project documents, if clicking the above does not work.

 

1.1       Document Contacts

 

Document Name Contact Name Contact Method/Info
Data Collection Document Tech Specs Sharon Brown Email
Data Collection Document Tech Specs Ed Putnam Email

 

1.2       Revisions

 

Date By Version Reason Change
12/2/09 S. Brown .01 Created
1/28/2010 S. Brown .02 Updated from Dev Review

Corrected titles in Specifications sections throughout the document.  Added more detail about the Standardized Credit Rules projects.

Removed Standardized Credit Rules Projects from 06/2010 Release doc.
2/10/2010 S. Brown .03 Update from Review

Added Assumption for 194343 Auto Domain Loads Per P. Blitz

Project.  Added comments to reporting FRs for same project.
4/30/2010 S. Brown .04

New Project

Update Based on Developer Questions

Added 216375a Revised ETF project to the document.

Added wtLinkType to Link Tracking and removed Tags not available.
5/5/2010 S. Brown .05 Removed all References to New Project Removed 216375a Revised ETF project form document.
5/19/2010 S. Brown .06 Updated for ETL and BO Effort Added Complexity Matrix, and Updated ETL and BO Section.
5/24/2010 S. Brown .07 Updated from UAT defects review Added clarification on Link Type
6/9/2010 S. Brown .08 Updated FRs not addressed in this document

 

1.3       Related Documents

 

Date File Name/Version How Used
1/28/2010 108470 Requirements_TCM Inventory Reports v0.4.xls Technical specifications are based on FRs from this document.
1/28/2010 WF_108470_TCM_Dwnld_Inv_Rpts_v1.2.pdf Technical specifications are based on WFs from this document.
1/28/2010 179133 – GSLA-ESLA Bus_Funct Requirements v.06.xls Technical specifications are based on FRs from this document.
1/28/2010 WF-179133-GSLA-v1.1-DRAFT.pdf Technical specifications are based on WFs from this document.
1/28/2010 P_Business_Requirements_189858_Cancellation_Fee_v0.03.xlsx Technical specifications are based on FRs from this document.
1/28/2010 P Requirements_Auto Domain Loads_v0.8_20091230.xls Technical specifications are based on FRs from this document.
1/28/2010 WF_194343_Auto_Domain_v1.0.pdf Technical specifications are based on WFs from this document.
1/28/2010 198746_SharedPayment_FRD_0.02.xls Technical specifications are based on FRs from this document.
1/28/2010 WF_198746_Shared Payment_DRAFTv.02.pdf Technical specifications are based on WFs from this document.

 

1.4       Clickstream & Reporting Summary

 

This project will require the following additions/modifications to the existing Clickstream data collection process.

 

Release Deployment Date: 6/12/2009

 

Business Objects License: None

 

Estimated Data Volume: No Significant Increase in Data Volume

 

Release Complexity: Level 01 – This is a New Project with less than five New Page Views and five New Action Events

 

Page Views: New Pages with BAU tags

 

Link Tracking: New Link Tracking

 

Parameters: 1 New Parameter

 

Action Events: 1 New Action Event

 

Parameters: 9 New Parameters

 

Extract Changes: New Extract from BASE with profile information and Update to the Order Extract to Include Order Statuses.

 

All work efforts should include a process where every page’s meta tags, event names, and WebTrends Code is validated against the standard event names, WebTrends meta tags, and Code included in Appendix B.  This validation should include the confirmation of accurate spelling, case, syntax and format.

 

1.4.1      Reporting Risks

 

Replacement of BASE will impact – 194343 Auto Domain Loads for Blitz

 

Extracts not yet available in eDM

 

2           Data Capture Tagging for Clickstream

 

FRs with outstanding Questions

 

Project FR # Description Specifications
746 – Shared Equipment/ Payment Responsibility FR-71.1 EDM Reporting tool must be able to track the number of orders where the company paid for the device and/or accessories How is the order identified as being paid for by the Company?  Email to Ramesh for details.
933 Auto Domain Loads for P. Blitz REP-1 P. will be able to report on the number of Profile requests from BASE that have ‘Domain’ information. Report from BASE.
933 Auto Domain Loads for P.Blitz REP-1.2 P. will be able to report on the number of Profile requests broken down by POS channel/system: OPUS, Phoenix, BASE Report from BASE.
933 Auto Domain Loads for P. Blitz REP-2 P. will be able to report on the number of Profile requests from BASE that do NOT have ‘Domain’ information. Report from BASE.
933 Auto Domain Loads for P. Blitz REP-2.1 P. will be able to report on the number of Profile requests broken down by POS channel/system: OPUS, Phoenix, BASE Report from BASE.
933 Auto Domain Loads for P. Blitz REP-3.1 P. will be able to report a list of Profile requests that did not have a Module Primary assigned.

Report from BASE.

What is “Module Primary”?  The Primary Salesperson assigned to the P. Customer.
933 Auto Domain Loads for P. Blitz REP-4 P. will be able to report on the number of Profile requests that have an enterprise type of ‘SBA’ (small business) Report from BASE.
933 Auto Domain Loads for P. Blitz REP-5 P. will be able to report on the number of Profile requests that have an enterprise type of ‘GBS’ (large business) Report from BASE.
933 Auto Domain Loads for P. Blitz REP-6 P. will be able to report on the number of Profile requests broken down by ‘Business Segment’
o Signature Accounts:  Large Business
o P. Client Group:  Medium Sized business
o Select Accounts:  Employee size >100 with certain Rev threshold
o Small Bus:  Employee Size <100
o GEM:
o Wholesale:		 Report from BASE.
933 Auto Domain Loads for P. Blitz REP-7 P. will be able to report on the total number of Profile requests from BASE. Report from BASE.

 

 

2.1        FRs Not Addressed by this Document

 

The following table lists the FRs Not Addressed by this Document

 

Project FR Description Specification
933 Auto Domain Loads for P. Blitz REP-3 P. will be able to report a list of Profile requests from BASE that have ‘Domain’ information, and the ‘Domain’ was NOT loaded successfully into P., along with the Error code and message. Not an eDM report.  Error code report from p’s load of BASE data.  P. Dev to provide report.
933 Auto Domain Loads for P. Blitz REP-1.1 P. will be able to report on the number of Profile requests for which the ‘Domain’ was loaded successfully into P.

Report to come from Data Team

For new profile requests only

 

Table 1 – FRs Not Addressed by this Document

 

2.2       Common Page Views Data Capture Elements

 

The standard out-of-the-box WebTrends tags are not included in the following requirements.  Those are associated with every page without requiring additional tagging.

 

2.2.1      Business Requirements and Technical Specifications Addressing Page Views

 

The following table lists the standard page view attributes

 

 Project FR # Description Specifications

470 – TCM Inventory Reports

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

133 – GSLA/ESLA Reporting

FR-33.1

FR-33.2

FR-33.3

FR-33.4

FR-33.5

FR-33.6

FR-33.9

FR-31.1

FR-31.2

FR-31.3

ATT shall be able to run metrics reporting on the TCM Account Management Reporting solution that shows:
Total number of TCM Account Management Reports requested in P. for a given period of time.ATT shall be able to run metrics reporting on the TCM Account Management Reporting solution that shows:
Total number of TCM Account Management Reports requested for each User.ATT shall be able to run metrics reporting on the TCM Account Management Reporting solution that shows:
Total Number of Subscriber Wireless Inventory Reports in the given period of time.ATT shall be able to run metrics reporting on the TCM Account Management Reporting solution that shows:
Total Number of Rate Plan Summary Reports in the given period of time.ATT shall be able to run metrics reporting on the TCM Account Management Reporting solution that shows:
Total Number of ETF Reports in the given period of time.

 

ATT shall be able to run metrics reporting on the TCM Account Management Reporting solution that shows:

Total Number of Upgrade Eligibility Reports in the given period of time.

ATT shall be able to run metrics reporting on the TCM Account Management Reporting solution that shows:

The number of report requests that failed to be fulfilled at all, by report type.

The reporting solution shall provide metrics on SLA report usage in the Online Care Solution.

The reporting solution shall provide metrics on user activity on the report information page.

The reporting solution shall provide metrics on visitor counts to the SLA report information page url in the Online Care Solution.

Page Views:

Reporting Notes: These FRs will be covered by Page Views, Action Events, Link Tracking & Download Link Tracking.

 

Add Standard Page View Tags and Code to all New Pages

Retain Parameters & Values in eDM:  ‘Keep’

 

Include the Web Trends code (Appendix B) at the bottom of each page and all Page View Meta Tags Listed in (Appendix B) for every page.
 746 – Shared Equipment/ Payment Responsibility FR-70.1 P. Online Store must be able to track the number of unique visitors using the Shared Equipment Payment Transaction flow

Page Views:

Reporting Notes: These FRs will be covered by Page Views, Action Events, Link Tracking & Download Link Tracking.

 

 Add Standard Page View Tags and Code to all New Pages

Retain Parameters & Values in eDM:  ‘Keep’

 

Include the Web Trends code (Appendix B) at the bottom of each page and all Page View Meta Tags Listed in (Appendix B) for every page.

 

Table 1 – Page View Requirements

 

2.3       Common Link Tracking Data Capture Elements

 

2.3.1      Business Requirements and Technical Specifications Addressing Link Tracking

 

The following table lists the BR/FRs that applies to Link Tracking.

 

Project FR # Description Specifications

470 – TCM Inventory Reports

 

 

 

 

 

 

 

133 – GSLA/ESLA Reporting

FR-33.1

FR-33.2

FR-33.3

FR-33.4

FR-33.5

FR-33.6

FR-33.9

FR-31.1

FR-31.2

FR-31.3

ATT shall be able to run metrics reporting on the TCM Account Management Reporting solution that shows:
Total number of TCM Account Management Reports requested in P. for a given period of time.ATT shall be able to run metrics reporting on the TCM Account Management Reporting solution that shows:
Total number of TCM Account Management Reports requested for each User.ATT shall be able to run metrics reporting on the TCM Account Management Reporting solution that shows:
Total Number of Subscriber Wireless Inventory Reports in the given period of time.ATT shall be able to run metrics reporting on the TCM Account Management Reporting solution that shows:
Total Number of Rate Plan Summary Reports in the given period of time.ATT shall be able to run metrics reporting on the TCM Account Management Reporting solution that shows:
Total Number of ETF Reports in the given period of time.

 

ATT shall be able to run metrics reporting on the TCM Account Management Reporting solution that shows:

Total Number of Upgrade Eligibility Reports in the given period of time.

ATT shall be able to run metrics reporting on the TCM Account Management Reporting solution that shows:

The number of report requests that failed to be fulfilled at all, by report type.

The reporting solution shall provide metrics on SLA report usage in the Online Care Solution.

The reporting solution shall provide metrics on user activity on the report information page.

The reporting solution shall provide metrics on visitor counts to the SLA report information page url in the Online Care Solution.

Link Tracking:

Reporting Notes: These FRs will be covered by Page Views, Action Events, Link Tracking & Download Link Tracking.

Add Link Tracking to all new menu items (i.e. “Request Reports” and “View and Download Reports”) for all menus, all links for Help and Support, and all Links for Reports

Retain Parameters & Values in eDM:  ‘Keep’

  • wtLinkName = Name of Link
  • wtLinkLoc = Location of Link
  • WT.svl = Number, if more than one reference to the same URL.
  • wtLinkType = Inventory Report, GWPR Report (GSLA), CWPR Report (ESLA), ‘Request Report Help and Support’, ‘ Dwnld Reports Help and Support’, ‘GWPR Help and Support’, ‘CWPR Help and Support’
585 Cancellation Fee Options REP-1 P. will be able to report on the number of page views for the Cancellation Fee Options help topics.

Link Tracking:

Reporting Notes: Add Link Tracking to all new links for Cancellation Fee project.  This includes Help & Support and all new Menu items.

Retain Parameters & Values in eDM:  ‘Keep’

·         wtLinkName = Name of Link

·         wtLinkLoc = Location of Link

·         WT.svl = Number, if more than one reference to the same URL.

 

Table 2 – Link Tracking Requirements

 

2.4       Common Action Event Tracking

 

2.4.1      Business Requirements Events and Technical Specifications Addressing Action Events

 

Action Events have Standard Parameters that are associated with all action events.  In addition to standard parameters, an action event may have parameters that are specific to the action event.  In each of the Functional Requirements below, new or “Added Parameters” are listed and they will be added to the standard parameter list for the action event.

 

The following table lists the BR/FRs that applies to Tracking Action Events.

 

Project FR # Description Specifications

470 – TCM Inventory Reports 

 

 

 

 

 

 

 

 

133 – GSLA/ESLA Reporting

FR-33.1

FR-33.2

FR-33.3

FR-33.4

FR-33.5

FR-33.6

FR-33.9

FR-31.1

FR-31.2

FR-31.3

User shall be able to run metrics reporting on the TCM Account Management Reporting solution that shows:
Total number of TCM Account Management Reports requested in P. for a given period of time. shall be able to run metrics reporting on the TCM Account Management Reporting solution that shows:
Total number of TCM Account Management Reports requested for each User shall be able to run metrics reporting on the TCM Account Management Reporting solution that shows:
Total Number of Subscriber Wireless Inventory Reports in the given period of time shall be able to run metrics reporting on the TCM Account Management Reporting solution that shows:
Total Number of Rate Plan Summary Reports in the given period of time shall be able to run metrics reporting on the TCM Account Management Reporting solution that shows:
Total Number of ETF Reports in the given period of time.

 

ATT shall be able to run metrics reporting on the TCM Account Management Reporting solution that shows:

Total Number of Upgrade Eligibility Reports in the given period of time.

ATT shall be able to run metrics reporting on the TCM Account Management Reporting solution that shows:

The number of report requests that failed to be fulfilled at all, by report type.

The reporting solution shall provide metrics on SLA report usage in the Online Care Solution.

The reporting solution shall provide metrics on user activity on the report information page.

The reporting solution shall provide metrics on visitor counts to the SLA report information page url in the Online Care Solution.

Action Events:

Reporting Notes: These FRs will be covered by Page Views, Action Events, Link Tracking & Download Link Tracking.

 

Action Event:
Add an Action Event for the Button Choice and collect the Reporting Details

Event Name: Report_Request_Submitted

Retain Parameters & Values in eDM:  ‘Keep’

Additional Parameters:

·         wtButtonChoice, valid values ‘Cancel’, ’Back’, ’Request Report’

·         wtReportStatus, The status of the report, valid values will be but are not limited to…Failed, Processing, Submitted, etc.

·         wtReportType, Base Standard Report Type

·         wtReportName, Name of the Report as presented to the visitor

·         wtReportLevel, FAN/BAN Level

·         wtRptSelectedAccount, FAN or BAN Number, FAN~#####

·         wtOutputFormat, Format of output file as presented to the visitor

·         wtCTNCount, count of the number of CTNs in report

·         wtDataTimePeriod, Data Time Period as presented to the visitor

·         wtReportRequestDateTime, The date and time of the report request was submitted.

 

Table 3 – Action Event Requirements

 

2.5       Add/Remove from Cart Tracking

 

2.5.1      Business Requirements and Technical Specifications Addressing Add and Remove Cart Tracking

 

The following table lists the BR/FRs that applies to Add and Remove from Cart Tracking

 

Functional Requirements Requirements Description/eDM Specification
No Cart Tracking

 

Table 4 – Add to Cart Requirements

 

2.6       Check Out Tracking

 

2.6.1      Business Requirements and Technical Specifications for Check Out Tracking

 

The following table lists the BR/FRs that applies to Check Out tracking

 

Functional Requirements Requirements Description/eDM Specification
No Check Out Tracking

 

Table 5 – Check Out Requirement

 

2.7       Download Tracking

 

2.7.1      Business Requirements and Technical Specifications addressing Download Tracking

 

The following table lists the BR/FRs for Tracking Downloads

 

Project FR # Description Specifications

470 – TCM Inventory Reports

 

  

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

133 – GSLA/ESLA Reporting

FR-33.1

FR-33.2

FR-33.3

FR-33.4

FR-33.5

FR-33.6

FR-33.9

FR-31.1

FR-31.2

FR-31.3

ATT shall be able to run metrics reporting on the TCM Account Management Reporting solution that shows:
Total number of TCM Account Management Reports requested in P. for a given period of time.ATT shall be able to run metrics reporting on the TCM Account Management Reporting solution that shows:
Total number of TCM Account Management Reports requested for each User.ATT shall be able to run metrics reporting on the TCM Account Management Reporting solution that shows:
Total Number of Subscriber Wireless Inventory Reports in the given period of time.ATT shall be able to run metrics reporting on the TCM Account Management Reporting solution that shows:
Total Number of Rate Plan Summary Reports in the given period of time.ATT shall be able to run metrics reporting on the TCM Account Management Reporting solution that shows:
Total Number of ETF Reports in the given period of time.

 

ATT shall be able to run metrics reporting on the TCM Account Management Reporting solution that shows:

Total Number of Upgrade Eligibility Reports in the given period of time.

ATT shall be able to run metrics reporting on the TCM Account Management Reporting solution that shows:

The number of report requests that failed to be fulfilled at all, by report type.

The reporting solution shall provide metrics on SLA report usage in the Online Care Solution.

The reporting solution shall provide metrics on user activity on the report information page.

The reporting solution shall provide metrics on visitor counts to the SLA report information page url in the Online Care Solution.

Download Tracking:

Reporting Notes: These FRs will be covered by Page Views, Action Events, Link Tracking & Download Link Tracking.

 

Download Link Tracking:

Add Download Link Tracking to all files that are downloaded.

Retain Parameters & Values in eDM:  ‘Keep’

  • wtLinkName = Name of Link
  • wtLinkLoc = Location of Link
  • WT.svl = Number, if more than one reference to the same URL.

·         wtLinkType = Inventory Report, , GWPR Report (GSLA), CWPR Report (ESLA)

·         wtDnLdFileName, The name of the file being downloaded.

  • wtReportRunDateTime, The date and time the report was run and available to the visitor.
  • wtReportRequestDateTime, The date and time of the report request was submitted.
  • wtReportStatus, The status of the report, valid values will be but are not limited to…Failed, Processing, Submitted, etc.
  • wtReportType, Base Standard Report Type
  • wtReportName, Name of the Report as presented to the visitor
  • wtReportLevel, FAN or BAN Level,
  • wtRptSelectedAccount, FAN or BAN Number, FAN~#####
  • wtOutputFormat, Format of output file as presented to the visitor
  • wtCTNCount, count of the number of CTNs in report
  • wtDataTimePeriod, Data Time Period as presented to the visitor
  • wtDatePosted, The date the report was posted and available to the visitor.

 

Table 6 – Tracking Downloads Requirements

 

3           Business Objects (BO) & eDM Details

 

Project FR # Description Specifications
None

 

Business Objects Requirements

 

3.1       BO Naming

 

Developer to use the following information to update BO descriptions

 

New Item New Item Business Name New Item Description (Tool Tips) Data Example Flow Name Full URL for New Page
wtLinkType Link Type Link Type and unique identifier for the link.  Used by the business for reporting. ‘Inventory Report’, ‘GWPR Report (GSLA)’, or ‘CWPR Report (ESLA)’
Report_Request_Submitted Report Request Submitted Event related to the report request N/A
wtButtonChoice Button Choice The button choice as selected by the visitor. ‘Cancel’, ’Back’, ’Request Report’
wtReportStatus Report Status The status of the report. Failed, Processing, or Submitted
wtReportType Report Type
wtReportName Report Name Name of the Report as presented to the visitor
wtReportLevel Report Level The level of the report FAN or BAN
wtRptSelectedAccount Report Selected Account The FAN or BAN Number FAN~#####
wtOutputFormat Output Format The format of the report as selected by the visitor. .xls, .pdf
wtCTNCount Count of CTNs The count of the CTNs in the report. 5
wtDataTimePeriod Date Time Period Data Time Period as presented to the visitor
wtReportRequestDateTime Report Request Date Time The date and time of the report request was submitted.
wtDatePosted Report Posted Date Time The date and time the report was Posted and available to the visitor.
Place Holder for Extract Changes to add Order Status.

 

3.2       BO Folder Organization

 

Developer to add/modify the BO environment to reflect the following:

 

New Tag Name Value Action to be Taken Object Type Notes
None

 

4         Report Writer Specifications

 

4.1       Business Requirements and Technical Specifications for Report Writer

 

The following table lists the BR/FRs for Report Writing

 

Project FR # Description Specifications
470 – TCM Inventory Reports FR-33.7

ATT shall be able to run metrics reporting on the TCM Account Management Reporting solution that shows:

Total Number of report requests completed within SLA;

Total Number of report requests completed outside of SLA;

Average Report Completion Time by report.

 Report Writer Spec:

Get SLA information from BA

1/6/2010 Email sent to Randy Henderson for SLA information.  1/8/2010 Randy is unable to provide the SLA at this time.

5/13/2010 Per Gopal New View created to provide data.
933 Auto Domain Loads for P. Blitz REP-8 The solution shall automatically send reports on Monday of each week for rolling 30 days. Report Writer Spec: Schedule new reports to be delivered each Monday with rolling 30 day content.

 

Table 7 – Report Writer Requirements

 

5         Extract Specifications

 

5.1       Business Requirements and Technical Specifications for Extracts

 

The following table lists the BR/FRs for Extract Creation or Modification.

 

Project FR # Description Specifications
746 – Shared Equipment/ Payment Responsibility FR-71.2 P. Reporting Implementation team must ensure that all necessary extracts are updated to support the tracking of Shared Equipment Payment Transactions in EDM Order Extract – How to identify Shared Equipment Orders and who paid.
746 – Shared Equipment/ Payment Responsibility FR-73.1 EDM Reporting tool must be able to track how many orders were Approved/Denied

What is considered an approved/Denied order?  What criterion identifies this?  The Order Status (not currently apart of the order extract)

Need an extract to provide the status of an order with the date and time of the status.  With order number and any other details to link the data to the order & Clickstream.

 

Appendix A – Reporting Reference Data

 

6           Event Naming Conventions

 

For P., the Developers know where the events are.  They have not been provided by the BRs and BA has said the Developers know where they are; therefore the location and naming of the Action Events needs to be addressed by the Developers.

 

Name of events in the logs (event_code column in the eDM) shall be proper case and shall have underscores between words. The eDM ETL will replace the underscores with spaces for the “event_desc” column, which is most often used on reports. In addition, since eDM shall have multiple event names for the same purpose ETL can translate old formats into the new one (e.g. SubmitCartAdd and CartAddSubmit and Cart_Add_Submit => Cart_Add_Submitted).

 

7           Event Type Definition and Purpose

 

As of today there are two types of events:

 

  1. Events initiated by the customer (action events)
  2. Events initiated by the system (system event).

 

If the customer clicks on a form submit then it results in a action event (wtEventType = ‘A’) vs. if the system performs an action on behalf of the user (e.g. OLAM application, the system, sends out SMS messages to customer’s cell phone letting them know their temp password so they can register for OLAM) then it is a ‘system event’ (wtEventType = ‘S’). It is important to note which events occur from the customer directly vs. the system from an analysis standpoint.

 

8           Status Code Use and Purpose

 

Action events (no page view events nor link clicks) have (or should have) an associated status code (wtStatusCode= [1234]) with each event. That is, the event that records when the customer clicks on a form submit should have a status code in the same log line (NOT a separate log line) as well. This status code is an alphanumeric code that uniquely identifies if what the customer did succeeded (typically = “0” but does not have to be) or failed (e.g. 1234) in the action they were trying to commit. The source team shall provide a reference extract file or database table that maps the status code to a status code type (“Success”, “Failure”, “Failure – User”, “Failure – System”, “Unknown” is generally wtStatusCode = ”-2”, “Window Close/Cancel” is wtStatusCode = “-1”) and a status code description.

 

Status Code Reference Table

 

Status Code Status Code Type Status Code Description
-2 Unknown Status of this event is not known by the system whether it succeeded or failed. This happens with events that lead customer away from the specific application or where architecture does not support status code tracking.
-1 Cancel Event was cancelled by user by choosing the “x” or “close” or “cancel” button and did not complete the transaction
0 Success Customer/system performed intended action successfully

 

An event can have a status code type of “unknown” only if the application truly does not know the status of the event; generally action events always have a status code. In a systems’ application logs there has been no problem with this data capture, however there are issues using ‘js’ tagging methodology (see the “capture” issues listed below).

 

When the status code is exactly the same across different apps, the domain and root folder will distinguish the different sources.

 

Example Status Code Reference Table

 

Status Code Status Code Type Status Code Description
-2 Unknown Status of this event is not known by the system whether it succeeded or failed. This happens with events that lead the customer away from the specific application or where architecture does not support status code tracking.
-1 Cancel Event was cancelled by visitor by choosing the “x” or “close” or “cancel” button and visitor did not complete the transaction
0 Success Customer/system performed intended action successfully
4321 Success – incomplete Customer submitted order and was able to do so, but no online credit check was possible
101 Failure – User User left zip code field blank
1111 Failure – System System Y unavailable at time of submit
1234 Failure – User Visitor password does not match the password the user id provided
N Failure  

 

Action events should also have categories/groupings (e.g. for events called “Login Pg”, Login Submit”, “Login Final Submit” the category is “Login”. This aids users in easily identifying which event they are looking for from the many that are available. This also helps with grouped analysis and reporting output showing groupings. Development teams shall provide a file with Event Code and Event Category and Event Description when possible.

 

9           Query String Retention

 

Retention Code Intended Use
0 Don’t Keep (Ignore)
1 Keep for 1 week
2 Keep as long as possible

 

 

 

Appendix B – WebTrends Standard Tags & Code

 

10       WT Base Tag

 

<!– WebTrends Base Tag : include only at end of page –>

 

<script src=”//www.corporatewebsite.com/webtrends/scripts/dcs_tag.js” type=”text/javascript”></script>

 

11       WebTrends Meta Tagging for Page Views

 

Note: Do not pass the tags with empty or null values.  If the data is not in context or known, do not pass the tag.

 

On every page when the data is in context place the following Meta Tags:

 

  1. Account Group ID <meta name = ‘DCSext.wtAccntGrp’ content = ‘AccntGrpValue’>
  2. Agreement Number <meta name = ‘DCSext.wtAgreementNum’ content = ‘Agreement Number from Base’>
  3. Agreement Status <meta name = ‘wtAgreementStatus’ content = ‘Agreement Status from Base’>
  4. BAN Number <meta name = ‘DCSext.wtBAN’ content =‘ BANNumberValue’>
  5. Consolidator Type <meta name = ‘DCSext.wtConsolidatorType’ content = ‘BillingConsolidatorTypeValue’>
  6. Contract Type <meta name = ‘DCSext.wtContractType’ content = ‘ContractTypeValue’> Extract for contract name
  7. CSR Login ID <meta name =‘wtCSRLoginID’ content=’CSRLoginID’>
  8. CTN Number <meta name = ‘DCSext.wtCTN‘ content = ‘CTNNumberValue’>
  9. Customer Type <meta name = ‘DCSext.wtCustType’ content = ‘CustomerTypeValue’> (Required) The customer type value of “Consumer”, “Business” etc whenever in context/known.  The value will always be Business for P. projects.
  10. FAN Number <meta name = ‘DCSext.wtFAN’ content = ‘FANValue’>
  11. Impersonator Type <meta name = ‘DCSext.wtImpersonatorType’ content=‘Impersonator type’> Expected Values Telesales, CSR maybe other values
  12. IP address is for user, not the load balancer, Akamai’s site. <meta name = ‘DCSext.wtIpAddress’ content = ‘IPAddressValue’> of the visitor
  13. IP Recognition (Business Center only) <meta name = ‘DCSext.wtIPR’ content = ‘true’ or ‘false’> where ‘true’ designates that the IP Address Is Recognized ‘false’ designates that the IP Address is NOT Recognized
  14. Liability Type <meta name = ‘DCSext.wtLiabilityType’ content = ‘LiabilityValue’>
  15. LOSG (Buy Flow Type) <meta name = ‘DCSext.wtBuyFlowType’ content = ‘BFTValue’>
  16. LOSG Subtype <meta name = ‘DCSext.wtLOSGSubType’ content = ‘LOSGSubTypeCode’> Tracking when there is more then one LOSGId (Buy Flow Type), BAN and CTN in context at the same time <meta name = ‘DCSext.wtLOS’ content = ‘LOSGID1~LOSG1~LOSGSubType1~BAN1~CTN1 |LOSGID2~LOSG2~LOSGSubType2~BAN2~CTN2 |LOSGIDN~LOSGN~LOSGSubTypeN~BANN~CTNN’>
  17. Order ID <meta name = ‘DCSext.wtOrderID’ content = ‘OrderIDValue’>
  18. Page Context (when in context) < meta name = ‘DCSext.wtPN’ content = ‘ThePageNameValue’> Tracking when there is more then one version of a page due to content only changes. This is valuable when the visitor can see multiple versions of content on a page where the URL, Page Title and other page identifiers remain the same, but different visual instances/versions of the page can be presented to the visitor (e.g. Tabs).
  19. Role <meta name = ‘DCSext.wtRole’ content = ‘RoleTypeValue’>
  20. SBS Indicator < meta name = ‘DCSext.wtSBSIndicator’ content = 0 (Failed SBS Eligibility), 1 (Passed SBS Eligibility) This page view attribute must be populated for both conditions.
  21. SBS Invoice Count <meta name=‘DCSext.wtSBSInvoiceCnt’ content = ‘the count of SBS Invoices based off the Contract id and Login>
  22. SBS Service Location Count <meta name=‘DCSext.wtSBSServiceLocCnt’content = ‘the count of SBS FANs based off the Login>
  23. Session ID < meta name = ‘DCSext.sessionid’ content = ‘TheSessionValue’>
  24. User ID / Login ID < meta name = ‘DCSext.wtLoginID’ content = ‘LoginValue’>
  25. ZipCode <meta name=‘DCSext.wtZipCode’content = ‘Zip Code entered in the Zip code page’>

 

12       WebTrends Meta Tagging for Link Tracking

 

For all link tracking the following meta tags will be used.

 

Developer to put the following tags in the post position of all the links

 

wtLinkName = “zzz”
wtLinkLoc = “yyy”
WT.svl = “xxx”

 

Where ‘zzz’ is the text of the link with all spaces and special characters removed

 

Where ‘yyy’ is the location of the link – The business will be providing a Reference Table to standardize the location definitions across applications (Business Center, POS, POC) See Section 3.1.1

 

Where ‘xxx’ will be used to distinguish between duplicate links; a duplicate link is defined as having the same name and location as another link on the same page.  The value will be a numeric value, numbered top to bottom on the page.

 

The following table is the reference data that will be used to collect link activity and how the locations will be displayed on reports.

 

Location Code Location Name Location Description
HDR Header The area above the main Navigation Bar
MNB Main Navigation Bar Main Navigation Bar near the top of the page
S1 First Sub Navigation The first sub level navigation below the Main Navigation Bar
LN Left Navigation Navigation that is to the left of the page body
RN Right Navigation Navigation that is to the right of the page body
BDY Body Central area of the page
FTR Footer The area below the main body of the page area

 

Table 1 – Link Location Reference table

 

13       WebTrends Meta Tagging for Action Events

 

See Section 8 for details on the use of status codes.

 

Developer is hard coding the on-click event, but dynamically populating the values.

 

OnClick = “dcsMultiTrack (

 

‘DCSext.wtAccntGrp’, ‘MMM’

 

, ‘DCSext.wtAcctGrpName’, ‘DZZ’

 

, ‘DCSext.wtAcctType’, ‘CZZ’

 

, ‘DCSext.wtAgreementNum’, ‘Y’

 

, ‘DCSext.wtAgreementStatus’, ‘Z’

 

, ‘DCSext.wtBAN’, ‘OOO’

 

, ‘DCSext.bref’, ‘ZZZ’

 

, ‘DCSext.browserid’, ‘AZZ’

 

, ‘DCSext.wtBuyFlowType’, ‘LLL’

 

, ‘DCSext.wtConsolidatorType’, ‘YYY’

 

, ‘DCSext.wtContractType’, ‘QQQ’

 

, ‘DCSext.wtCSRLoginID’, ‘WWW’

 

, ‘DCSext.wtCTN’, ‘PPP’

 

, ‘DCSext.wtCustType’, ‘JJJ’

 

, ‘DCSext.dcsuri’, ‘AAA’

 

, ‘DCSext.dcsref’, ‘BBB’

 

, ‘DCSext.wtEvent’, ‘CCC’

 

, ‘DCSext.wtEventType’, ‘A’ or ‘S’

 

, ‘DCSext.wtFAN’, ‘NNN’

 

, ‘DCSext.wtFormSubmit’, ‘GGG’

 

, ‘DCSext.wtImpersonatorType’, ‘UUU’

 

, ‘DCSext.wtInterfacingSys’, ‘VVV’

 

, ‘DCSext.wtLiabilityType’, ‘RRR’

 

, ‘DCSext.wtLoginID’, ‘TTT’

 

, ‘DCSext.wtLOSGSubType’, ‘MMM’

 

, ‘DCSext.wtLOS’, ‘LOSGID1~LOSG1~LOSGSubType1~BAN1~CTN1 | LOSGID2~LOSG2~LOSGSubType2~BAN2~CTN2 | LOSGIDN~LOSGN~LOSGSubTypeN~BANN~CTNN’

 

, ‘DCSext.wtNoHit’, ‘HHH’

 

, ‘DCSext.wtRole’, ‘SSS’

 

, ‘DCSext.wtSBSIndicator’, ‘X’

 

, ‘DCSext.sessionid’, ‘BZZ’

 

, ‘DCSext.wtStatusCode’, ‘EEE’

 

, ‘DCSext.wtSuccessFlag’, ‘DDD’

 

, ‘DCSext.wtZipCode’, ‘PPP’

 

);

 

Where:

 

‘DCSext.wtAccntGrp’, ‘MMM’ (Required when in context) is the Account Group ID

 

‘DCSext.wtAcctGrpName’, ‘DZZ’ (Required when in context)

 

‘DCSext.wtAcctType’, ‘CZZ’ (Required when in context)

 

‘DCSext.wtAgreementNum’, ‘Y’ (Required when in context) this is the BASE Agreement Number

 

‘DCSext.wtAgreementStatus’, ‘Z’ (Required when in context) this is the BASE Agreement Status

 

‘DCSext.wtBAN’, ‘OOO’ (Required when in context) is the BAN in context

 

‘DCSext.bref’, ‘ZZZ’ (Required when in context) is the Bref in context

 

‘DCSext.browserid’, ‘AZZ’ (Required when in context)

 

‘DCSext.wtBuyFlowType’, ‘LLL’ (LOSG TYPE, Required when in context) where the value is the type of buy flow (AKA LOSG Type) the customer is in (New, upgrade, AAL etc)

 

‘DCSext.wtConsolidatorType’, ‘YYY’ (Required when in context) is the Billing Consolidator Type in context

 

‘DCSext.wtContractType’, ‘QQQ’ (Required when in context) is the Contract Type in context

 

‘DCSext.wtCSRLoginID’, ‘WWW’’ (Required when in context) the login ID of the CSR Rep

 

‘DCSext.wtCustType’, ‘JJJ’ (Required) is the customer type value of “Consumer”, “Business” etc whenever in context/known.  The value will always be Business for P. projects.

 

‘DCSext.wtCTN’, ‘PPP’ (Required when in context) is the CTN in context

 

‘DCSext.dcsuri’, ‘AAA’ (Required) is the Destination/Target Page URL

 

‘DCSext.dcsref’, ‘BBB’ (Required) is the URL of the page where the ‘Submit’ is currently located (window.location.href).

 

‘DCSext.wtEvent’, ‘CCC’ (Required) is the event name Cart_Add_Submit or Cart_Remove_Submit

 

‘DCSext.wtEventType’ (Required when available) as of today there are two types of events, ‘A’ designates a customer imitated the action event, ‘S’ designates a system performed the action.  See Appendix A

 

‘DCSext.wtFAN’, ‘NNN’ (Required when in context) is the FAN in context

 

‘DCSext.wtFormSubmit’, ‘GGG’ (depending on how the event values are captured) is a value of ‘0’ if false (not a form submit), ‘1’ if true (event fired was a result of the customer clicking on a form submit button)

 

‘DCSext.wtImpersonatorType’, ‘UUU’

 

‘DCSext.wtInterfacingSys’, ‘VVV’ (Required when available) is the Interfacing system when applicable.  If there is more then one interfacing system separate them with a pipe (|)

 

‘DCSext.wtLiabilityType’, ‘RRR’ (Required when in context) is the Liability Type in context

 

‘DCSext.wtLoginID’, ‘TTT’

 

‘DCSext.wtLOS’, ‘LOSGID1~LOSG1~LOSGSubType1~BAN1~CTN1 |LOSGID2~LOSG2~LOSGSubType2~BAN2~CTN2 |LOSGIDN~LOSGN~LOSGSubTypeN~BANN~CTNN’ (Required when in context) Tracking when there is more then one losgid (Buy Flow Type), BAN and CTN in context at the same time

 

‘DCSext.wtLOSGSubType’, ‘MMM’ (Required) the LOSG Subtype (See Appendix B)

 

‘DCSext.wtNoHit’, ‘HHH’ (Required) is the NoHit indicator which lets the reporting team know not to count this as a page view, this value should be “1” for all form submits events (both successes and failures), link clicks and any other event that does not result in a page view.

 

‘DCSext.wtRole’, ‘SSS’ (Required when in context) is the Role for the visitor

 

‘DCSext.wtSBSIndicator’, ‘X’ content =  0 (Failed SBS Eligibility), 1 (Passed SBS Eligibility), This page view attribute must be populated for both conditions.

 

‘DCSext.wtSuccessFlag’, ‘DDD’ (Required) is a value of 0 if false, 1 if true

 

‘DCSext.wtStatusCode’, ‘EEE’ (Required when available) is the value of a unique alphanumeric status code (e.g. 1234) that represents successes (typically “0”) and failures at the field level for both user and system failures. If multiple status codes return on a submit event then the status codes should be separated by a pipe ‘|’.

 

‘DCSext.wtZipCode’, ‘PPP’ (Required when in context) is the Zip Code

 

14       WebTrends Meta Tagging for Add and Remove Cart Tracking

 

See Section 8 for details on the use of status codes.

 

OnClick = “dcsMultiTrack (

 

‘DCSext.wtAccntGrp’, ‘MMM’

 

, ‘DCSext.wtBAN’, ‘OOO’

 

, ‘DCSext.wtB2BAddSKUQty’, ‘WWW’

 

, ‘DCSext.wtB2BRemoveSKUQty’, ‘XXX’

 

, ‘DCSext.wtBuyFlowType’, ‘LLL’

 

, ‘DCSext.wtConsolidatorType’, ‘YYY’

 

, ‘DCSext.wtContractType’, ‘QQQ’

 

, ‘DCSext.wtCTN’, ‘PPP’

 

, ‘DCSext.wtCustType’, ‘JJJ’

 

, ‘DCSext.dcsuri’, ‘AAA’

 

, ‘DCSext.dcsref’, ‘BBB’

 

, ‘DCSext.wtEvent’, ‘CCC’

 

, ‘DCSext.wtEventType’, ‘A’ or ‘S’

 

, ‘DCSext.wtFAN’, ‘NNN’

 

, ‘DCSext.wtFormSubmit’, ‘GGG’

 

, ‘DCSext.wtImpersonatorType’, ‘UUU’

 

, ‘DCSext.wtInterfacingSys’, ‘VVV’

 

, ‘DCSext.wtLiabilityType’, ‘RRR’

 

, ‘DCSext.wtLoginID’, ‘TTT’

 

, ‘DCSext.wtLOSGSubType’, ‘MMM’

 

, ‘DCSext.wtLOSG’, ‘LOSGID1~LOSG1~LOSGSubType1~BAN1~CTN1 | LOSGID2~LOSG2~LOSGSubType2~BAN2~CTN2 | LOSGIDN~LOSGN~LOSGSubTypeN~BANN~CTNN’

 

, ‘DCSext.wtNoHit’, ‘HHH’

 

, ‘DCSext.wtRole’, ‘SSS’

 

, ‘DCSext.wtStatusCode’, ‘EEE’

 

, ‘DCSext.wtSuccessFlag’, ‘DDD’

 

, ‘DCSext.wtZipCode’, ‘PPP’

 

);

 

Where:

 

‘DCSext.wtAccntGrp’, ‘MMM’ (Required when in context) is the Account Group ID

 

‘DCSext.wtB2BAddSKUQty’, ‘WWW’ is the Add to Cart (wtB2BAddSKUQty) where the value is in the format of ‘mmm’ is the SKU that has been added and the ‘nnn’ is the quantity of that SKU added. If there is more than one unique SKU added in a single event then a pipe shall delimit each pair (e.g. ‘mmm’~’nnn’|’mmm’~’nnn’).

 

‘DCSext.wtB2BRemoveSKUQty’, ‘XXX’ is the Remove from Cart (wtB2BRemoveSKUQty) where the value is in the format of ‘mmm’~’nnn’ where ‘mmm’ is the SKU that has been removed and the ‘nnn’ is the quantity of that SKU removed. If there is more than one unique SKU removed in a single event, then a pipe shall delimit each pair (e.g. ‘mmm’~’nnn’|’mmm’~’nnn’).

 

‘DCSext.wtBAN’, ‘OOO’ (Required when in context) is the BAN in context

 

‘DCSext.wtBuyFlowType’, ‘LLL’ (LOSG TYPE, Required when in context) where the value is the type of buy flow (AKA LOSG Type) the customer is in (New, upgrade, AAL etc)

 

‘DCSext.wtConsolidatorType’, ‘YYY’ (Required when in context) is the Billing Consolidator Type

 

‘DCSext.wtContractType’, ‘QQQ’ (Required when in context) is the Contract Type in context

 

‘DCSext.wtCustType’, ‘JJJ’ (Required) is the customer type value of “Consumer”, “Business” etc whenever in context/known.  The value will always be Business for P. projects.

 

‘DCSext.wtCTN’, ‘PPP’ (Required when in context) is the CTN in context

 

‘DCSext.dcsuri’, ‘AAA’ (Required) is the Destination/Target Page URL

 

‘DCSext.dcsref’, ‘BBB’ (Required) is the URL of the page where the ‘Submit’ is currently located (window.location.href).

 

‘DCSext.wtEvent’, ‘CCC’ (Required) is the event name Cart_Add_Submit or Cart_Remove_Submit

 

‘DCSext.wtEventType’ (Required when available) as of today there are two types of events, ‘A’ designates a customer imitated the action event, ‘S’ designates a system performed the action.  See Appendix A

 

‘DCSext.wtFAN’, ‘NNN’ (Required when in context) is the FAN in context

 

‘DCSext.wtFormSubmit’, ‘GGG’ (depending on how the event values are captured) is a value of ‘0’ if false (not a form submit), ‘1’ if true (event fired was a result of the customer clicking on a form submit button)

 

‘DCSext.wtImpersonatorType’, ‘UUU’

 

‘DCSext.wtInterfacingSys’, ‘VVV’ (Required when available) is the Interfacing system when applicable.  If there is more then one interfacing system separate them with a pipe (|)

 

‘DCSext.wtLiabilityType’, ‘RRR’ (Required when in context) is the Liability Type in context

 

‘DCSext.wtLoginID’, ‘TTT’

 

‘DCSext.wtLOSG’, ‘LOSGID1~LOSG1~LOSGSubType1~BAN1~CTN1 |LOSGID2~LOSG2~LOSGSubType2~BAN2~CTN2 |LOSGIDN~LOSGN~LOSGSubTypeN~BANN~CTNN’ (Required when in context) Tracking when there is more then one LOSGId (Buy Flow Type), BAN and CTN in context at the same time.

 

‘DCSext.wtLOSGSubType’, ‘MMM’ (Required) the LOSG Subtype (See Appendix B)

 

‘DCSext.wtNoHit’, ‘HHH’ (Required) is the NoHit indicator which lets the reporting team know not to count this as a page view, this value should be “1” for all form submits events (both successes and failures), link clicks and any other event that does not result in a page view.

 

‘DCSext.wtRole’, ‘SSS’ (Required when in context) is the Role for the visitor

 

‘DCSext.wtSuccessFlag’, ‘DDD’ (Required) is a value of 0 if false, 1 if true

 

‘DCSext.wtStatusCode’, ‘EEE’ (Required when available) is the value of a unique alphanumeric status code (e.g. 1234) that represents successes (typically “0”) and failures at the field level for both user and system failures. If multiple status codes return on a submit event then the status codes should be separated by a pipe ‘|’.  See further details below.

 

‘DCSext.wtZipCode’, ‘PPP’ (Required when in context) is the Zip Code

 

15       WebTrends Meta Tagging for Check Out Tracking

 

See Section 8 for details on the use of status codes.

 

Developer to populate the tag as follows when appropriate.

 

Yes/No meta tag for when a credit card is required for ‘0’ one time changes.
< meta name = ‘DCSext.wtCreditCardRequired’ content = ‘Y’ or ‘N’>

 

16       Download Link Tracking WebTrends Meta Tagging

 

For all Download Link Tracking the following meta tags will be used.

 

Developer to put the following tags in the post position of all the links

 

wtLinkName = ‘zzz’
wtLinkLoc = ‘yyy’
WT.svl = ‘xxx’

 

wtDnLdFileName = ‘www’

 

Where zzz is the text of the link with all spaces and special characters removed

 

Where yyy is the location of the link – The business will be providing a Reference Table to standardize the location definitions across applications (Business Center, POS, POC) See Section 3.1.1

 

Where xxx will be used to distinguish a duplicate link: A duplicate link is defined as having the same name and location as another link on the same page. It will be a numeric value, numbered top to bottom.

 

Where www will be the filename of the file being downloaded

 

17       Valid Event Names for Existing Processes

 

For all Event Names the following Names must used unless called out separately in this document.

 

7/24/09 – Valid Event Names
Accept_Agree_Submitted
Accept_Not_Agree_Submitted
Accnt_Permission_Chng_Submitted
Address_Verification_Response
Agree_Reject_Submitted
Agreement_Accept_Submitted
Agreement_Application_Verify
Application_Cancel_Confirm
Application_Fill_Out
Application_Submitted
Assign_Edit_Name_Confirm_Submitted
Assign_Edit_Name_Req_Submitted
BAN_PW_Check
BAN_Reassign_Submitted
Billing_Info_Submitted
Billing_Info_Updated
Biz_Agreement_Accept
Biz_Agreement_Reject_Confirm
Bulk_User_Info_Change_Validation_Submitted
Bulk_User_Info_Changed
Bulk_User_RatePlan_Change_Submitted
Bulk_User_RatePlan_Change_Validation_Submitted
Cart_Add_Cancel_Submitted
Cart_Add_Req_Submitted
Cart_Add_Submitted
Cart_Cancel_Save_Submitted
Cart_Change_Request
Cart_Change_Submitted
Cart_Close_Save_Submitted
Cart_Confirm_Save_Req
Cart_Duplicate_Line_Submitted
Cart_Empty_Confirm_Submitted
Cart_Empty_Req_Submitted
Cart_Remove_Confirm_Submitted
Cart_Remove_Req_Submitted
Cart_Retrieve_Confirm_Submitted
Cart_Retrieve_Req_Submitted
Cart_Save_Confirm_Submitted
Cart_Save_Req_Submitted
Cart_Save_Submitted
Cart_Update_Submitted
Change_Confirm_Request
Change_Req_Confirm_Submitted
Change_Request_Submitted
Chat_Assistance_Submitted
Chat_Decline_Submitted
Checkout_Form_Submitted
COFR_Submitted
Complete_Order_Submitted
Contact_Us_Submitted
Credit_Card_Verification_Response
Credit_Check_Response
CSR_Tool_Select_Customer
Cust_Pkg_Req_Submitted
Device_Compare_Submitted
Device_Update_Submitted
Email_Authentication_Submitted
Enrollment_CertifyAffiliation_Submitted
Enrollment_OnlineValidation_Submitted
Enrollment_Submitted
FAN_Attachment_Submitted
FAN_BAN_CTN_Search_Type
FAN_Reassign_Submitted
FAQ_System
Feature_Change_Submitted
Group_Plan_Type
Information_Submitted
IRU_Conversion
Line_Remove_Submitted
LNP_Eligibility_Check_Response
LNP_Port_Status_Submitted
Login_BAN_Created
Login_New_Created
Login_Profile_Updated
Login_Submitted
Non_POC_Registration
Not_Accept_Sponsorship_Fee
Order_Review_Form_Submitted
Order_Status_Form_Submitted
Paper_Shdow_Billing_Disable
Paperless_Billing_Change_Rqst
Password_Reset
Payment_Details_One_Time
POC_Register
P._Login_Submitted
Prequalification_Submitted
Product_Select
Product_Select_Submitted
Product_Select_Summary
Rate_Plan_Change_Submitted
Real_Time_Plan_Change
Recurring_Payment_Setup_Mod_Submitted
Report_DDP_Recur
Report_DDP_Usage
Report_Request_Submitted
Return_Validation_Number_Continue
Review_Edit
SBPL_Apply_Submitted
Shipping_Info_Submitted
Shopping_Options_Submitted
SM_Business_Info_Submitted
TimeOut_Warning
Upgrade_Eligibility_Check_Response
User_Info_Changed
User_Information_View_Submitted
Username_Retrieve
Verification_Back_Submitted
Verification_Cancel_Submitted
Voicemail_PW_Change_Submitted
Wireless_Num_Search
Wirelessnum_Change_Request_Submitted

 

 

 

Appendix C – Template Reference Data

 

18       Template Revision History

 

Revision Date By Whom Description
4/10/09 Sharon Brown

Added Appendix C Template Revision History

Added Confidentiality Information

Added Document Descriptor Box to the First Page of the Report to Contain the Confidentiality, Version, and Date Last Updated.
6/4/09 Sharon Brown Added Project Complexity Chart to Appendix C
6/16/09 Sharon Brown Updated Event Valid Name List, Added Proprietary Information disclosure to footer
6/29/09 Sharon Brown Added the Consolidator Type to Page Views, Action Events, Cart Activity as new Core Tag.  Also added Logo.
7/27/09 Sharon Brown Modified Tags as follows:  wtBANNum to wtBAN, wtFANNum to wtFAN, wtCTNNum to wtCTN, Bref to bref
7/30/09 Sharon Brown Updated Event Valid Name List
8/20/09 Sharon Brown Removed internal check list.  New check list outside document.
9/8/09 Sharon Brown Added Query String Retention Matrix, Report Writers Specifications Section
11/10/09 Sharon Brown Updated Core Tags List to include new core tags from SBS Project.  Added Flow Name and URL to BO Section.

 

19       Confidentiality Legend

 

Type Description
Confidential

Document contains confidential information and should be limited to only those individuals authorized to receive it.  These documents should be destroyed via shredding.

Refers to information relating to a specific individual or company proprietary information involved in  transactions or intellectual knowledge for which there is a reasonable expectation that due care will be taken to keep it confidential.  Examples include, Customer Personal Information, Technical Documentation Related to a Proprietary System, Company Financial Information, etc.
Restricted

Document contains information that should be restricted to appropriate audiences only.  These documents should be destroyed via shredding.

Refers to information relating to a specific individual or company proprietary information involved in transactions or intellectual knowledge for which there is a reasonable expectation that care will be taken to keep it restricted.  Examples include, Customer Personal Information, Functional Documentation Related to a Proprietary System, Company Statistical Information, etc.
Sensitive Document contains sensitive information, to include any unclassified information not cleared for public release.  These documents should be destroyed via shredding.
Public Document contains publicly releasable information defined as; information that has undergone a review and been cleared for public release.

 

20       Project Complexity Legend

 

Level Description
Level 00 New Project. BAU, No New tagging.
Level 01

New Project. <5 New Page Views

or Action Events
Level 02

New Project. <5 New Page Views

and <5 New Action Events
Level 03

New Project. <5 New Page Views

and New Action Events on Multiple Platforms

and < 3 Columns on an Extract

or >5 <8 New Page Views

and New Action Events on one Platform

and < 3 Columns on an Extract
Level 04

New Project. >8 New Page Views

and New Action Events on Multiple Platforms

and >1 Extract Affected or new Extract
Level 05

New Project. >8 New Page Views

and New Action Events on Multiple Platforms

and >1 Extract Affected or new Extract

and New Fact Table

and New Subject Area

 

21       6/12/2010 Release Project Complexity Grid

 

Project Platforms Impacted New Pages Tags Action Events Action Event Parameters Link Tracking Download Tracking Extracts Impacted eDM Impacts BO Impacts
Business Offer and Promotion Enhancements Phase 3 POS None None None None None None None None
Cancellation Fee Options POC None None None None None None None None
eBill eInvoice eBill None None None None None None None None
Generally Available ESLA Reporting Web access POC New Pages None None 1 Parameter None None New Fact Table and Dimensions New Fact Table and Dimensions
Revised ETF POC None None None None None None None None
Shared Equipment/ Payment Responsibility POS New Pages None None None None Update Order Extract None None
Tax Exempt Enhancements POS None None None None None None None None
TCM Inventory Report POC New Pages 1 Event 10  Parameters 1 Parameter 12 New Parameters New Fact Table and Dimensions New Fact Table and Dimensions

 

 

 

End Document

 

 

 

 

 

 

 

 

My Role: Functional Analyst

 

Point of Sale (POS) – Restocking Fee Policy Enforcement – Functional Specification Document

 

POS Impacts

 

New Re-Stocking Fee Override Codes coming from SAP into POS

 

Re-Stocking SKU will be added to the SAP article file

 

UI Changes to add Override Capabilities

 

New Data Elements added to POSLog

 

Item Control File for POS Database modified to accommodate new data elements.

 

Items in Green are new/changes to POS for this project.

 

a.      Revision Information

 

Document Type: Functional Specification Document, POS
Description POS – Restocking Fee Policy Enforcement
Author(s) Sharon Brown, Functional Analyst (POS)
Version 1.03a
Date 3/28/2011

 

Table of Contents

 

I. Document Overview 5

 

  1. Document History 5
  2. Related Documents 5
  3. Document Approvals 6

 

  • Approvals 6
  • Reviewers 6

 

II.  Introduction   6

 

  1. Existing System 6
  2. To-Be Process 6
  3. Advantages of implementing 7
  4. Assumptions 7
  5. Scope Statement 7
  6. In Scope 7
  7. Out of Scope 8
  8. Risks/Issues 9
  9. Key Dependencies 9

 

III. The Existing and To-Be System Specifications: 9

 

  1. Existing System 9
  2. To-Be System 9
  3. System Modification Summary for POS 9
  4. Data Elements, POSLog file Changes 9

 

IV.     POS UI Changes  10

 

  1. Use Cases 10
  2. Definitions 27
  3. Business Requirement 27
  4. Business Requirements Document 27
  5. Functional Requirement 27
  6. End-to-End Functional Requirements Document 27
  7. Functional Specification 27

 

Appendix for Regression Testing and Trace-ability   28

 

 

I. Document Overview

 

The purpose of this document is to provide Functional Specifications for POS – Restocking Fee Policy Enforcement covering POS requirements.

 

1.     Document History

 

Version Date of Change Person Description of Change
1.0 1/21/2011 Sharon Brown Initial Draft
1.01 1/27/2011 Sharon Brown Updated from Dev Feedback and Added Screens for Use Cases.
1.02 2/8/2011 Sharon Brown Updated from Team Feedback
1.03 2/15/2011 Sharon Brown Updated to reflect resolution with SAP Team.
1.03a 3/28/2011 Sharon Brown Corrected spelling for Cancelation to Cancellation to be consistent with other POS language.

 

2.      Related Documents

 

Document Name Location
Restock Fee Policy Enforcement BRD  v 1.2 Project sharepoint
PR203110 – Restock Fee Policy Enforcement HLSD  – v 1.2 Project sharepoint
Retail Restocking Fee Process – Future Project sharepoint
SKU Tiers Work Sheet SKU Tiers 1-14-11.xlsx Found in BRD document.

 

3.    Document Approvals

 

Approvals

 

Name Project Role Approvals
Suresh Agaram POS – Lead Developer 2/28/11 Verbal
Sean Peterson Retail – Architect 2/28/11 Verbal
Mark Williams BSA Lead 2/28/11 Verbal

 

Reviewers

 

Name Project Role
Manoj Sukumaran SA-ESP
Yash Singh Dev Mgr – Retail
Suraj Dubey Dev Lead –  Watson
Chris Rothering SA  – EPSI
Jana Marchand BSA SSI
Robert Hildebrand Business Owner
Ian McKay SBAF Owner
Sagar Jain POS – Sr. Developer
Raju Merugumala Watson – Lead Developer
Tancy White Customer Delivery – POS

 

II. Introduction

 

This project is intended to increase restock fee revenue and decrease remorse return expenses.  These goals will be accomplished by increasing the restock fee and by systematically requiring an override to remove the fee.  These approvals will only be able to be performed by persons with the appropriate POS permissions, currently on the manager profile (i.e., RSM, RAM, or RSL).

 

1.       Existing System

 

Currently the restock fee is $10.00 and the user can remove this fee without acquiring approval.

 

2.      To-Be Process

 

The restock fee will change from $10.00 to a value derived from a configurable, tiered fee system.  The user will not be able to remove this fee without manager approval.  Certain items will not be charged a restock fee (e.g., loaner phones, demo phones, ISWE Defects, accessories).  Certain geographic regions will not be allowed to collect any restock fees (e.g., Hawaii).

 

3.     Advantages of implementing

 

There are various advantages of implementing this project such as:

 

Reduced remorse returns.

 

Increased restocking fee policy adherence.

 

Collection of restocking fee data on overrides.

 

Better user experience.  The user will no longer be required to manually remove the restocking fee in regions where the collection of restocking fees is not allowed.

 

4.        Assumptions

 

1.8.1 Existing generic restock fee disclaimer text on both the Service agreements and POS receipts will remain unchanged.  Currently the text says “You may be required to pay a restocking fee if you return your Device.”  The Spanish version of the text (used in Puerto Rico and elsewhere) is “Si devuelve un Equipo, se le podría exigir el pago de un cargo por restitución de mercancía.”

 

  1. Scope Statement

 

5.        In Scope

 

Any parameter that is not specifically mentioned in this document is assumed to be out of scope.

 

1.5.1.1  All organic retail, TPR and TPRi, including Puerto Rico, but excluding locations where the collection of restock fees is prohibited (e.g., Hawaii)

 

2.3.1 The restock fee will be modified from the current $10.00 to a tiered amount based on the recovery cost of restocking various SKUs

 

2.3.2  No restock fee line item will appear on items in the $0.00 restock fee tier.

 

2.3.3 Once in place, the approach for the tiering system will be configurable (i.e., the number of tiers, the fee rate for a given tier, and the list of items to be included in any given tier will be updateable) with no development work involved

 

2.3.4  No restock fee line item will appear in stores where these fees are not allowed (e.g., stores in Hawaii).

 

2.3.5  The approach for designating stores where restock fees are not allowed will ensure that indivi

 

dual stores can be added/removed.

 

2.3.6  Once in place, the approach for designating stores where restock fees are not allowed will be configurable (i.e., the list of stores will be updateable) with no development work involved.

 

2.3.7  Whether a restock fee is charged and how much is charged will be systematically enforced.

 

2.3.8  The restock fee line item on POS will only be removable via a manual override by someone with the appropriate POS permissions, currently on the manager profile (i.e., RSM, RAM, or RSL).

 

2.3.9 As part of an override, the manager must supply a reason for the override approval from the following list:

 

  1. Defective Handset
  2. Service Cancellation
  3. Retention/Customer Loyalty
  4. Customer Escalation
  5. System Error
  6. Price Adjustment
  7. Exempt SKU

 

2.3.10  Once in place, the approach for designating override reasons will be configurable (i.e., the list of reasons will be updateable) with no development work involved.

 

2.4  Retail Partner Sales Requirements

 

2.4.1  T-Mobile Premium Retailer

 

All the requirements from section 2.3 also apply here.3  Reporting Requirements

 

3.1  Sales and Service Information

 

3.1.1  The overrider ID, override reason, and dollar amount of the restocking fee will be available in SAPPDM.

 

4.  Systems Support Requirements

 

4.1  System Performance Requirements

 

4.2.1  There should be no adverse affects on performance with this change. The expectation is any new functionality will not be performance impacting.

 

4.3  Security/Permissions Requirements

 

The restock fee line item on the POS receipt can only be removed via a manual override by someone with the appropriate POS permissions, currently on the manager profile (i.e., RSM, RAM, or RSL).

 

6.     Out of Scope

 

Following parameters are considered as out of scope for this project:

 

1.5.2.1   All other channels outside of the organic retail and the branded retailers called out in section 1

 

1.5.2.2  Changes to existing products and services

 

7.        Risks/Issues

 

 Risk /Issue Details
Timeline Overall project time line is aggressive.
Issues Documented in Issue Log

 

8.   Key Dependencies

 

None

 

III. The Existing and To-Be System Specifications:

 

1.     Existing System

 

Currently POS applies a restocking fee to some returns/exchanges.  The restocking fee entry can be removed without consideration by a manager and without knowing who removed the fee or why the restocking fee was removed.

 

2.     To-Be System

 

3.    System Modification Summary for POS

 

  • Prepare POS infrastructure to handle new data elements coming from SAP. Modifications to data feed (daily article file) coming from SAP to POS will be made to accommodate new data elements identified for this project.  This new feed will include the new configured codes for re-stocking fee override codes and the addition of a new element to contain the SKU of the restocking fee.
  • Item Control File for POS Database should be modified to accommodate the addition of the new data elements identified for this project.
  • UI Changes to add restrictions to re-stocking fee line item to prevent the fee from being removed without manager approval/consideration. And a new screen will be added to allow the manager to select the override reason code.
  • New Data Elements are being added to POSLog to capture the dealer code of the manager making the override, the overrider id of the manager making the override, and the re-stocking fee override reason code with the description.

 

4.    Data Elements, POSLog file Changes

 

1.     List of new data elements for POSLog.

 

Data Element Name Location Description
Overrider_Dealer_Code Item Detail Dealer Code of person/manager making override
Overrider_ID Item Detail Watson or pos login id generally matches NT ID of Override Manager.
Restocking_Fee_Override_Reason_Code Item Detail Override reason code (please provide code as well as description) – Reason Overrider Overroad the charge.  Different than the return reason code.
Restocking_Fee_Override_Reason_Code_Desc Item Detail The description of the Restocking Fee Override Reason Code.  Expected to be used by the business for reporting.  Comes from SAP.

 

IV.    POS UI Changes

 

Changes to the UI of POS, the use cases shown below represent POS transactions impacted by this project.

 

1.    Use Cases

 

RFUC-01 Restocking Fee Removal – Sales Rep

 

1.1   Use Case 1 – Restocking Fee Removal

 

Use Case Number RFUC-01
Use Case Name Process a Return with a Restocking Fee
Description Return of a handset that has a restocking fee.  The restocking fee will be removed from the customer’s transaction requiring a manager to approve the override.
Preconditions) Sales Rep has validated that the customer qualifies for the return and has logged into POS to process the return.
Trigger Event The use case begins when the Sales Rep receives an item return from a customer interaction.
Actors

Sales Rep – Non Manager

POS

TIBCO

EIP
Inputs Mobile Number (MSISDN), Transaction information from original receipt.  Serial Number
Process Steps

Use Case Starts

1.       Sales Rep Clicks Airtime Payment/Sales

2.       Sales Rep enters MSISDN in Customer Information Screen

3.       Sales Rep Clicks Search to Look Up Customer Information

4.       Systems displays Screen with Validated Customer Information

5.       Sales Rep Clicks Item Entry Button

6.       System displays Item Entry Screen

7.       Sales Rep Views SKU List by Clicking on “?” Button

8.       Sales Rep Selects SKU to be Returned

9.       System displays Item Entry Screen

10.   Sales Rep Clicks Return Button

11.   System displays screen prompting user for Return Reason

12.   Sales Rep Selects Reason for Return

13.   System displays screen prompting user for MSISDN and information from the receipt

14.   Sales Rep Enters Return Transaction Information and Clicks OK

15.   System displays screen prompting user for Serial Number of Returned Item.

16.   Sales Rep Enters Serial Number for Returned Item

17.   Sales Rep Selects Reason for Activation (same as when sold)

18.   Sales Rep Clicks “X” to remove Restocking Fee

19.   System determines the Sales Rep has no  Authorization to Override/Remove Restocking Fee

20.   System displays screen prompting user for Manager Login

21.   Manager Enters Manager Login Information and Clicks OK

22.   Systems Captures Manager Login Information (Restocking Fee Overrider Dealer Code and Restocking Fee Overrider ID)

23.   System displays screen prompting user for Restocking Fee Override/Removal Reason

24.   Sales Rep Selects Reason for Restocking Fee Override/Removal

25.   System captures Restocking Fee Override Reason Code and Restocking Fee Override Reason Desc.

26.   Sales Rep Clicks Calculate/Continue Button to Complete Transaction

27.   Sales Rep selects option to tender return

28.   Sales Rep enters tender information and Clicks Tender

29.   System displays new receipt

Use Case ends

Items in green are new/changed items.
Outputs Return Receipt
Post Conditions

1.       T-Mobile Customer return has been completed.  Customer has received a refund/exchange for equipment returned.

2.       Restocking Fee has been removed from Customer Transaction

3.       POS Log is updated with details from customer return
Required Data Elements for POSLog
Additions to the POS Log

The following new pieces of data must be captured in the POSLog as part of the request:

Attribute Name Location Attribute Type Required
Restocking_Fee_Overrider_Dealer_Code Item Detail Number Y
Restocking_Fee_Overrider_ID Item Detail TEXT Y
Restocking_Fee_Override_Reason_Code Item Detail TEXT Y
Restocking_Fee_Override_Reason_Code_Desc Item Detail TEXT Y

The POSLog will populate the following elements.

<RSTKFEEOVERRIDECODE>####</RSTKFEEOVERRIDECODE>

<RSTKFEEOVERRIDECODEDESC>Description of the Override Code here. </RSTKFEEOVERRIDECODEDESC>

<RSTKFEEOVERRIDERID>ALPHANUM</RSTKFEEOVERRIDERID>

<RSTKFEEOVERRIDERDEALERCODE>#######</RSTKFEEOVERRIDERDEALERCODE>
Business Rules N/A
ALT Flow 1 – A Manager as Sales Rep

19a. System determines the Sales Rep is Authorized to Override/Remove Restocking Fee

22a. Systems Captures Manager Login Information (Restocking Fee Overrider Dealer Code and Restocking Fee Overrider ID)

23a. System displays screen prompting user for Restocking Fee Override/Removal Reason

24a. Sales Rep Selects Reason for Restocking Fee Override/Removal

25a. System captures Restocking Fee Override Reason Code and Restocking Fee Override Reason Desc.
ALT Flow 2 – B Customer Has No Receipt

14b. Sales Rep Looks up Customer Receipt and Prints Duplicate Receipt (Existing Capability)

c. Sales Rep Enters Return Transaction Information and Clicks OK
Risks N/A
Special Requirements N/A

 

Select Airtime Payment/ Sales

 

Enter Mobile Phone Number or Account Number

 

Click Item Entry button

 

View SKU List by Clicking on “?” Button

 

Select SKU to be returned

 

Click Return Button

 

Select reason for return

 

Enter Return Transaction Information

 

Click OK

 

Enter Serial Number for Returned Item

 

Select Reason for Activation

 

Notice the 2 Line Items that appear in the screen

 

SKU selected for item being returned

 

SKU for restocking fee with restocking fee dollar amount

 

Click X to remove Restocking Fee – Change Restocking Fee Charges Screen

 

Enter the Override Manager Login Information – New Screen

 

Select reason for Restocking Fee Override/Removal – New Screen

 

Click Calculate/Continue button to complete transaction.

 

Note: Restocking fee is not present

 

New Process Flow

 

2. Definitions

 

2. 1    Business Requirement

 

A Business Requirement is an element or a process, consisting of multiple elements, performed within an organization to do their business.

 

2.2     Business Requirements Document

 

A Business Requirements Document includes a (high level) description of the business requirements, which need to be performed within an organization to do their business.

 

2.3      Functional Requirement

 

A Functional Requirement is the intended behavior of a Software System, i.e. what the system must accomplish or perform. Functional requirements are a decomposition and part of the business requirements, i.e. actions and tasks to meet the business requirement.

 

2.5      End-to-End Functional Requirements Document

 

A (high level) description – in non computer oriented or technical language of functional requirements to be performed by a Software System.  The Functional Requirements Document provides the user a clear statement of the functions required of the system in order to solve the users’ information issue.  The document includes use cases and transaction flows with data elements.

 

2.6       Functional Specification

 

A detailed description of what a Software System needs to do to support a business requirement.  This document includes screen shots, invoice layouts, and detailed business logic.

 

Appendix for Regression Testing and Trace-ability

 

An appendix will be provided to include the following:

 

New Restocking SKUs with associated price.

 

New Restocking Fee Override Reason Codes and Descriptions

 

Alternate flows/Use cases to include a case for a $0 fee.

 

Alternate flows/Use cases to include a case for Hawaii Store No Restocking Fee

End Document

 

 

 

 

 

Point of Sale (POS) Functional Specification Document

 

POS Impacts

 

  • New Data Element coming to POS Application
  • New Data Element added to POS Database
  • New Data Elements added to POSLog
  • Change to POSLog file creation.

 

Revision Information

 

Document Type: Functional Specification Document, POS
Description Point of Sale Changes
Author(s) Sharon Brown, Systems Analyst (POS)
Version 2.0a
Date 3/16/2011

 

 

Table of Contents

 

Document Overview 5

 

Document History 5

 

Related Documents 5

 

Document Approvals 5

 

Approvals 5

 

Reviewers 5

 

Introduction   6

 

Existing System 6

 

To-Be Process 6

 

Advantages of implementing 6

 

Assumptions 6

 

Scope Statement 6

 

In Scope 6

 

Out of Scope 7

 

Risks/Issues 7

 

Key Dependencies 7

 

The Existing and To-Be System Specifications: 7

 

Existing System 7

 

To-Be System 7

 

Use Cases  8

 

Definitions 11

 

Business Requirement 11

 

Business Requirements Document 11

 

Functional Requirement 11

 

End-to-End Functional Requirements Document 11

 

Functional Specification 11

 

 

Document Overview

 

The purpose of this document is to provide Functional Specifications for POS – Restocking POS requirements.

 

Document History

 

Version Date of Change Person Description of Change
1.0 2/7/2011 Sharon Brown Initial Draft
1.01 2/18/2011 Sharon Brown Final Version – Changes from Team Review
2.0 3/4/2011 Sharon Brown Re Design
2.00a 3/16/2011 Sharon Brown Small corrections to clarify POS Impacts and expected results.

 

 

Related Documents

 

Document Name Location
Yakima HLSD.pptx http://projects.infonet.t-mobile.com/sites/ProgramOffice/PP/yakima/default.aspx?RootFolder=%2fsites%2fProgramOffice%2fPP%2fyakima%2fPL%2f04%2dDesign&FolderCTID=&View=%7b20F5E6C2%2dCA1A%2d49D0%2dA5E5%2d2EC1DC1D70B9%7d
BRD_Yakima ver 101.docx http://projects.infonet.t-mobile.com/sites/ProgramOffice/PP/yakima/default.aspx?RootFolder=%2fsites%2fProgramOffice%2fPP%2fyakima%2fPL%2f02%2dRequirements&FolderCTID=&View=%7b20F5E6C2%2dCA1A%2d49D0%2dA5E5%2d2EC1DC1D70B9%7d

 

Approvals

 

Name Project Role Approvals
Suresh Agaram Lead Developer – POS  email
Sean Peterson Architect – Retail  email
Brent Koons EPO  BSA  email
Dave Crum EIT Business Solutions – SA  email
Ravi Ramalingam Retail Testing Lead  email
Jason Siegel Customer Delivery  email

 

Reviewers

 

Name Project Role
Keri She ESP – SA
Emily Moneymaker Mgr Customer Delivery
Yash Singh Dev Mgr – Retail
Sagar Jain Sr. Developer – POS
Catherine Fan BI – Solution Architect

 

Introduction

 

This project seeks to leverage the opportunity to merge leadership and sales staff of multiple co-located retail entities (e.g. a corporate retail store and a retail kiosk located in the same shopping mall).

 

Existing System

 

Currently there are mall locations which share multiple retail entities (e.g. a corporate retail store and a retail kiosk).  Each of these retail entities has a dedicated sales and management team supporting its operations.

 

To-Be Process

 

Under this project co-located retail entities within a shopping mall could be merged into a single entity, allowing for cost savings through the streamlining of operations and more flexible staff assignment

 

Advantages of implementing

 

There are various advantages of implementing this project such as:

 

  1. Reduced management headcount
  2. Reduced staffing for opening and closing
  3. Flexible staffing across co-located facilities

 

Assumptions

 

  1. All reports available thru the POS Menu will continue to report with the Original Store Location ID.
  2. No impacts are expected to the POS Book File and its supporting processes.
  3. Scope Statement

 

In Scope

 

Any parameter that is not specifically mentioned in this document is assumed to be out of scope.

 

1.5.1.1 Organic owned retail stores and kiosks sharing a mall location

 

3.1 Following the merger of co-located retail entities, SSI Retail Reporting will reflect the retail structure created by the merger of multiple co-located retail entities into a single retail entity.

 

3.2  SSI Retail Reporting will reflect any pre-merger historical reporting information for any of the merged retail entities under each individual retail entity as originally reported.

 

3.3  SSI Retail Reporting will require the ability to identify which retail entities have been merged through the efforts of this project.

 

Out of Scope

 

Following parameters are considered as out of scope for this project:

 

1.5.2.1   All other sales channels

 

Risks/Issues

 

 Risk /Issue Details
Timeline

·         Overall project time line is aggressive.

·         Resource constraints for impacted areas could impact delivery timeline.

·         Expanding scope to include RPS could impact delivery timeline.

·         Rejection for Design by Executive Staff is delaying code development.
Issues None

 

Key Dependencies

 

None

 

The Existing and To-Be System Specifications:

 

Existing System

 

Currently POSLog file stores data as it relates to a customer transaction no unique identifier is present to allow the distinct identification of a sales pod (cash register) within a retail entity.

 

To-Be System

 

Modifications to POS are as follows:

 

  • Prepare POS infrastructure to handle new data elements coming from SAP. Modifications to data feed (daily article file) coming from SAP to POS will be made to accommodate new data elements identified for this project.  This new feed will include the new In-Line Store Location ID.  When the element is blank then the store is the Parent Store.

 

  • Modify the POS Database to include a new field to store the In-Line Store Location ID (Stored in the PA_STR_RTL table).
  • New Data Element is being added to POSLog to contain the Original Store Location ID for each store.
  • Change to the POS Log to swap the Store Location ID with the In-Line Store Location ID at the creation of the POS log.  The rule is:  If the In-Line Store Location ID is populated then copy the value into the Store Location ID; if the In-Line Store Location ID is empty then do nothing and always populate the Original Store Location ID with the Store Location ID in the POS database.

 

Naming to POSLog files will include the value of the Original Store Location ID in the file name (Will work as is today).

 

Data Elements, POSLog file Changes

 

List of changed data elements for POSLog.

 

Data Element Name Location

Required

Y/N

 Attribute Type Length Description
Original_Store_Location_ID Transaction Header Y TEXT 5 The store location ID is the identification code for each store.

 

POS UI Changes

 

No Changes to the UI of POS, the use case shown below represents a generic POS transaction impacted by this project.  Changes will only be made on the back end.

 

Use Cases

 

  • POS Transaction – Sales Rep – Manager or Non-Manager

 

Use Case 1 – POS Transaction

 

Use Case Number YUC-01
Use Case Name Any POS Transaction
Description Any identified transaction from the POS application.
Preconditions Sales Rep has logged into POS.
Trigger Event The use case begins when the Sales Rep performs any transaction in POS as part of a Sale or Return.
Actors

Sales Rep, Non Manager or Manager

POS

TIBCO

POSLog File (XML)
Inputs Mobile Number (MSISDN)
Back End Process Steps

Use Case Starts

1.       Sales Rep performs transaction

2.       Sales Rep Clicks Tender Button

3.       POS Writes to POSLog.xml file

4.       POS Log distributed via TIBCO

Use Case ends
Outputs Receipt
Post Conditions

1.       Transaction has been completed.

2.       POS Log is updated with details from transaction

3.       POS Log data will have the Store Locations ID business rule applied to the data to populate when appropriate with the In-Line Store Location ID.
Required Data Elements for POSLog
Additions to the POS Log

The following new pieces of data must be captured in the POSLog as part of the request:

Attribute Name Location Attribute Type

Required

Y/N
Original_Store_Location_ID Transaction Header TEXT Y

The POSLog will populate the following new elements.

<ORIGINAL_STORE_LOCATION_ID>276</ ORIGINAL_STORE_LOCATION_ID >
Business Rules When the In-Line Store Location ID is populated then copy the value into the Store Location ID; if the In-Line Store Location ID is empty do nothing; always populate the Original Store Location ID with the Store Location ID in the POS database.
ALT Flow 1 – N/A
Risks N/A
Special Requirements N/A

 

Definitions

 

Business Requirement

 

A Business Requirement is an element or a process, consisting of multiple elements, performed within an organization to do their business.

 

Business Requirements Document

 

A Business Requirements Document includes a (high level) description of the business requirements, which need to be performed within an organization to do their business.

 

Functional Requirement

 

A Functional Requirement is the intended behavior of a Software System, i.e. what the system must accomplish or perform. Functional requirements are a decomposition and part of the business requirements, i.e. actions and tasks to meet the business requirement.

 

End-to-End Functional Requirements Document

 

A (high level) description – in non computer oriented or technical language of functional requirements to be performed by a Software System.  The Functional Requirements Document provides the user a clear statement of the functions required of the system in order to solve the users’ information issue.  The document includes use cases and transaction flows with data elements.

 

Functional Specification

 

A detailed description of what a Software System needs to do to support a business requirement.  This document includes screen shots, layouts, and detailed business logic.

End Document

 

 

The following examples are from a billing implementation project for a utility company.  I was the reporting lead for the project and created reporting standards and requirements as part of the implementation of a new billing system.

 

Standards for Crystal Reports

 

Security and Distribution – Reports available from within CC&B will utilize CC&B security. The same groups & roles that are set up for non-reporting functions will be used for reports whenever possible.  Report security will be documented by Security Group/Role and Report Name/Application Service Name.  If new Crystal Reports are identified that must be run outside of the CC&B environment, for client or other staff, a security solution will be documented at that time for the Business Objects scheduler.

 

Timing – We expect both scheduled and on demand reports.  Report criteria captured will include run frequency such as on demand, daily, weekly, monthly, quarterly, annually.  The Reports Environment will be an exact copy of the Production database and refreshed daily after business processes have all completed for the day.  All report development for CNG will utilize the Oracle Reports Environment CC&B database.  The Business Objects universe will be developed at a later date.  When capturing requirements for reports, any on demand reports will note data update timing needs.

 

Storage and Archiving – Nothing should be stored only on PC hard drives.

 

  • Storage of Crystal Reports Requirements documents – On SharePoint Site, Reports Tab, Shared Documents, Reports In Progress
  • Storage of Crystal Reports and SQL files during development – On SharePoint Site, Reports Tab, Shared Documents, Reports Ready for Development, Once a week copies updated to CNG’s network as a backup.
  • Storage of Completed Technical Specifications – On SharePoint Site, Reports Tab, Shared Documents, Reports Ready for Tech Review
  • Storage of Completed Reports –  On SharePoint Site, Reports Tab, Shared Documents, Reports Ready for Unit Test
  • Storage of Reports that have passed Unit Testing with check list – On SharePoint Site, Reports Tab, Shared Documents,  Reports Completed.  These reports are ready for UAT.

 

Naming Conventions – Reports development documents will be named with the prefix of “CM_”, then, using the two letter designation for the department and then the Report ID, then the title of the report (i.e. CM_ RA0710_XxxxxxxxXxxxxxxxxxxXxxxxxxxx.rpt).  When a report is designed and programmed specifically for only one of the companies, preface the report ID with the three/four letter designation for each company (MDU, CNG, GPNG).

 

Report Format Standards

 

  1. Orientation – Default to landscape.
  2. Margins – minimum ½ inch on top, bottom, left and right side
  3. Color – B&W standard. Color if requested.
  4. Parameters –
    1. Use business name for field names in prompts (e.g. Billing Date).
    2. Use format MM/DD/YYYY for dates.
    3. Specify date format in parenthesis on date parameters (e.g. Billing Date (MM/DD/YYYY)).
    4. Display run parameters as report subtitle:  e.g. “Beginning Billing Date mm/dd/yyyy Ending Billing Date mm/dd/yyyy”

 

  1. Font: Default to Times New Roman or Arial
  2. Suggested Alignment (use as appropriate):
    1. Title, and Subtitle if any – center
    2. Column Headers – Use Business Name centered above column contents
    3. Detail Lines –
      1. Numbers – Negative numbers – shown with “-” in front of numbers.
    4. For reports with no data, display column headings only Title Line, Subtitle Line(s), along with “No Data Found” in the detail line.
    5. Use the Crystal layout templates for all reports.
    6. Report Title, Requesting User ID, Report Data Date, Page of Pages, Report File Location, and Report Parameters.
    7. Add report properties to each report to include Department, Owner and Developer.

 

PL/SQL format standards:

 

Name stored procedures using the same convention as the report name.

  1. Begin separate lines for each SQL phase, including SELECT, FROM, WHERE, ORDER BY, etc.
  2. Within a phrase, list the first field name after 3 spaces and on the same line as the key word.
  3. Start each AND on a new line and as needed to align the field name with the field name above it.
  4. Place commas at beginning of lines as shown in the example.
  5. Place the semicolon on the end of the last line.
  6. To continue a line that doesn’t fit on a single line, indent 3 additional spaces from the first line.
  7. Table aliases should be meaningful.
  8. Comments should be used for explanation of the code, not for unused code.

 

Example:

CREATE or REPLACE PROCEDURE cm_tbd(p_rep_cursor in out cr_package.cr_cursor)

IS 

BEGIN

OPEN p_rep_cursor for

SELECT distinct sys_context(‘userenv’,’db_name’) as databasename

, user

, acct.cis_division

, acct.coll_cl_cd

, sa_type.debt_cl_cd

, cis_division_l.descr

, coll_cl_l.descr

, debt_cl_l.descr

FROM cisadm.ci_acct acct

, cisadm.ci_sa sa

, cisadm.ci_sa_type sa_type

, cisadm.ci_cis_division_l cis_division_l

, cisadm.ci_coll_cl_l coll_cl_l

, cisadm.ci_debt_cl_l debt_cl_l

WHERE acct.cis_division = cis_division_l.cis_division

AND acct.coll_cl_cd = coll_cl_l.coll_cl_cd

AND acct.acct_id = sa.acct_id

AND sa.sa_type_cd = sa_type.sa_type_cd

AND sa_type.debt_cl_cd = debt_cl_l.debt_cl_cd

AND NOT EXISTS (SELECT ‘X’

FROM cisadm.ci_coll_cl_cntl coll_cl_cntl

WHERE coll_cl_cntl.cis_division = acct.cis_division

AND coll_cl_cntl.coll_cl_cd = acct.coll_cl_cd

AND coll_cl_cntl.debt_cl_cd = sa_type.debt_cl_cd)

ORDER by acct.cis_division

, acct.coll_cl_cd

, sa_type.debt_cl_cd;

END cm_tbd;

 

Crystal Report Programming Best Practices

 

  Topic: A better practice is to:
1 Standard Logic

Perform joins, logic, and standard selection criteria in BO Universe to improve performance. (Due to delayed use of BO Universe Implementation re-visit this topic when the Universe tool is utilized).

While using only Crystal Reports to develop reports, whenever possible create re-usable code and objects and store them in the BO repository for all developers.
2 Record selection formulas in Crystal or Basic syntax. Use ranges in the select statements to avoid additional db calls.
3 Sorting, grouping, or totaling on a Crystal formula field. Sort, group or total in the field named in BO Universes to improve performance. (Due to delayed use of BO Universe Implementation re-visit this topic when the Universe tool is utilized).
4 Grouping or sorting in Crystal on description fields if they have corresponding codes. Group or sort on codes because the sort is faster. Usually codes are shorter and also indexed.
5 Using sub-reports as a method of joining data Join tables in the report query, because it provides better performance.
6 Unlinked sub-reports with common data Link sub reports with the main report to pull the common data only once.
7 Data type conversion. Leave data in its original data type whenever possible, to avoid later maintenance problems that can arise from data not being in the expected format. If needed for comparison, use a value in a similar data type.
8 Using distinct count summary fields or distinct count running total fields as a ‘quick and dirty’ method of eliminating duplicates. Use ‘distinct’ only when required by the specs. Display  duplicates if they exist, because they can indicate errors in the data or select statement
9 Multiple command objects in Crystal Reports and linking between command objects Use a single command object in the Crystal Design for the output of the report because it improves performance.
10 Hard Coded values within the report. Always document if used Use variables because it is easier to maintain.
11 Leaving obsolete formulas, parameters, or other objects in a report Clean up/remove obsolete objects when making report changes because it improves report performance and maintenance.
12 Hiding sections if not needed for drill-down information Suppress sections (no drill-down) because calculations are still performed if hidden making performance better.
13 Pasting SQL directly into the Crystal report. Whenever possible only use SQL added to the crystal report when no function within crystal exists.  Always use parameters it is by far the quickest way to retrieve a dataset from the server.
14 ODBC connections for data. Use native database drivers to access your data for greater efficiency
15 Using Basic syntax in the Crystal Report Use Crystal syntax because it is more efficient and should be familiar to any Crystal Report programmer tasked with supporting or maintaining the report.
16 Reports Security Guidelines Whenever possible use CC&B security to identify the user and group.  This should restrict the user to the level of access needed for each report.
17 Reports Logos and Text Storage Whenever possible store reusable objects in the repository.  Name the object with enough information to identify the object.
18 Company & State All reports will have the Company and State as a parameter.

 End Document

 

Report Requirements for Cash Payments Report

 

Report Number: CL0704

 

Cash Payments

 

Last Update     : 6/11/08
Revision : 1.3
Clearance : All proprietary information has been removed to protect my clients.
Document : CL0704 – Cash Payments

 

Revision History

 

Version & Rev ID Date Changed By Changes Made
1.0 4/30/08 S. Brown Created
1.1 5/22/08 S. Brown Added sample output and refined business requirements.
1.2 5/27/08 S. Brown Add additional detail to requirements.
1.3 6/11/08 S. Brown Add technical specs.

 

Related Documents

 

Version & Rev ID Related Documents Source Release Date
None

 

 

Report Complexity Actual

 

Hours Estimate for Detailed Design / Development / Unit Testing Justification
40 to 80 Hours

The report requires a moderate level of special processing or calculations

There are between 2-5 tables that information need to be queried from

There is a simple user interface  with minimal user prompting

 

 

 

Table of Contents

 

Report Complexity Actual 1

 

Document Overview.. 2

 

Business Specifications. 2

 

Requirement Definition. 2

 

Justification. 3

 

Assumptions. 3

 

Security Requirements. 3

 

Requirements Summary. 4

 

Configuration Information. 5

 

Application Service. 5

 

Report Definition. 5

 

Technical Specifications. 6

 

Report Parameters. 6

 

Processing Functionality / Pseudo Code. 6

 

Data Extract Logic Overview.. 6

 

Data Mapping. 8

 

Data Sorting & Grouping. 8

 

Sample Output 10

 

Testing Criteria. 10

 

Document Overview

 

This document establishes the report purpose, content, and design for the business users and the report writers.  It is intended to be utilized for report development, testing and training.

 

Business Specifications

 

Requirement Definition

 

Purpose:  Used to show cash transfers between accounts.  Verify account transfers are correctly posted, also, used to troubleshoot issues with revenue.

 

Description: The client requires a report that will monitor cash postings each day.  This report is created after cash is posted each day.  The report lists all cash transactions performed by call center representatives (use deposit control to identify call center location) by employee number.

 

Key Criteria Includes:

 

  • Any SA associated with a Tender Control Number (Daily Batch Number), Employee ID,  and contains a Transfer Amount (show credit and debit)

 

Key data elements include:

 

  • Tender Control Number (Daily Batch Number)
  • Employee ID
  • Customer Account Number
  • Transfer Amount (show credit and debit)

 

The report must show data as follows:

 

  • Include all transactions and a Summarization by employee with the transaction net amount.
  • The report must be grouped in order by Employee ID
  • Order each transaction (showing all transactions) by Transaction Amount (or dollar amount) within each employee ID.
  • The end of the report must contain a Summarization of the Transaction Amount by each employee id and a Total count of Transactions for the day for each Employee ID and transaction type.
  • To effectively utilize this report, results must be provided in an excel format emailed to the users each day. The users must have the capability to restrict report results by Amount (regardless of sign -/+), Employee ID, Date Range (Default to current date), and Customer Account Number.

 

Justification

 

Needed for daily operations to facilitate monthly financial close.

 

Assumptions

 

  • Assume there is a controlled test system with fixed accounts to test the report.
  • Assume the Business Objects Enterprise environment and Universe Development is set up and completed
  • The following message will display when no data is found “No Data Available”.

 

Security Requirements

 

Security Levels 

  1. Revenue Admin

Manager

Power User

User

  1. Credit & Collections

Manager

Power User

  1. Call Center

Manager

Power User

 

Requirements Summary

 

Functional Requirements Ref #  BR001
Business Owner/User Jane Smith
Report User Group(s) Call Center
Report Title CL0704 – Cash Payments
Description Report is created after cash is posted for the day.  This report lists all cash transactions performed by call center representatives by employee (Tender Source) order so all related transactions will be together.
Priority 095
Output fields Date Range , Employee ID, Customer Account Number, Transfer Amount (show credit/debit), Summarize and show transaction net amount.
Sort Order Group by UserGroup , Order so all related Transactions are Together by Userid (X1) within Usergroup, then by Date and Time (X2), Amount (X3).
Calculated Columns /Algorithms Summarize Transaction Amount, Total Transactions for the previous day.
Media (PDF / Excel /  Email/ etc) Excel, Email (Call Center Supervisors Group)
Frequency  Daily
Execution Method  Scheduled
Dependencies Cash must be posted for the day.
Legacy Name Cash Payments
Parameters Amount, Tender Source  (Employee), Date Range (Default to Previous Business Day), Customer Account Number
Criteria Restrict to only include Call Center transactions.

 

Configuration Information

 

Note:  See the Reports chapter of the Admin guide for additional considerations on Defining New Reports

 

Application Service

 

Note: To create an application service for the new report, navigate to the Admin Menu, Application Service.  After creating the application service, define which users may access this report using the information provided below.

 

Application Service Description Access Mode
CL0704 Cash Payments Submit/View Report

 

Report Definition

 

Note:  To create a report definition for the new report, navigate to the Admin Menu, Report Definition and specify the report parameters, labels, description, etc.

 

Field Name Value
Report Code CL0704
Description Cash Payments
External Reference ID CL0704
Application Service CL0704
Validation Algorithm N/A
Long Description The client requires a report that will monitor cash postings each day.  This report is created after cash is posted each day.  The report lists all cash transactions performed by call center representatives (use deposit control to identify call center location by employee number order so related transactions are together.
Report Font Arial
Report Font Size 12pt

 

Technical Specifications

 

Report Parameters

 

Define a unique parameter entry for each parameter sent to Crystal Enterprises.  The sequence of the parameters must match the sequence defined in Crystal.

 

Seq Parameter Code Required Char Type Default Value Short Description Long Description
1 P_Transaction_Amount N $ All Transaction Amount Transaction Amount
2 P_Customer_Account_Nbr N Char All Customer Account Number Customer Account Number
3 P_Employee_ID N Char All Employee ID Employee ID
4 P_Transaction_Date Y Date Previous Business Day Date Range Date Range

 

Note:  For each label or other type of verbiage used by the report, you must first define a field to store the text used for the verbiage.  Navigate to Admin Menu, Report Definition Parameters tab to add these new fields (prefix with CM)

 

Processing Functionality / Pseudo Code

 

When necessary create a stored procedure for the report prefixing the name with CM.  The following outlines the structure of the new procedure:

 

Data Extract Logic Overview

 

Requirement 1:

  1. Transaction Date would be input. This is the date on which the payment was ‘transferred’ from one account to another. If the report is run late in the evening after the last user signs off, then the Transaction Date (FREEZE_DTTM) of CI_FT should be equal to the System Date. If the report is run the next day, then the Transaction date should be System Date minus 1.

Requirement 2: Other parameters are optional.

Assumption 1: Report would be created at the end of the business day.

 

Tables affected are:

  1. CI_FT
  2. CI_PAY
  3. CI_PAY_EVENT
  4. SC_USER
  5. SC_USR_GRP_USR
  6. SC_USER_GROUP

 

Data Extract should be based on the following criteria:

 

  1. Select all transactions from the CI_FT table where Transaction Date (FREEZE_DTTM) is equal to the System Date.
  2. Select only those transactions from CI_FT where the FREEZE_SW = ‘Y’
  3. Select only those transactions from CI_FT where FREEZE_USER_ID = USER_ID of SC_USER (This is currently an assumption. However, this report is going to be run only for users that are part of the Bellingham Call Center which means the USERIDS for the Bellingham Call Center have to be identified and hardcoded as part of the selection criteria)

 

FREEZE_USER_ID of CI_FT = USER_ID of SC_USER and

USER_ID of SC_USER = USER_ID of SC_USR_GRP_USR and

USR_GRP_ID of SC_USR_GRP_USR = USR_GRP_ID of SC_USER_GROUP and

USR_GRP_ID of SC_USER_GROUP = XXXXXX where

XXXXX will be the identified User-group for the Bellingham Call Center.

 

  1. Select only those transactions from CI_FT where the FT_TYPE_FLG = ‘PS’ (Pay Segment) or ‘PX’ (Pay cancellation).

 

The following is a sample of how data would be stored and extracted.

Assume the following transactions:

Account No         Payment Date   Tran Amt             UserID

77212                    06-01-2008          100                         BATCH

78883                    06-01-2008          225                         BATCH

Lets say that the above postings were incorrect and someone identified that the payments need to be cancelled and posted to the correct accounts.

 

Assume the following actions were completed on 06-05-2008

 

Account No         Transfer Acct      Tran Amt             Transfer Date     User ID  Payment Event ID

77212                    90899                    100                         06-05-2008          XYZ25    22324223

78883                    90552                    225                         06-05-2008          XYZ30    55342553

The Financial Transaction table would have the following records.

 

FT_ID                    FREEZE_DTTM                   CUR_AMT           FREEZE_USER_ID             FT_TYPE_FLG

9999299                06-05-2008                          100                         XYZ25                                    PX

3993993                06-05-2008                          100                         XYZ25                                    PS

8843434                06-05-2008                          225                         XYZ30                                    PX 

4838744                06-05-2008                          225                         XYZ30                                    PS

The FT table would have 4 records (2 for cancellations ‘ PX’ and 2 for the new payment postings ’PS’). The Payment event ID would be the same for the cancellation and posting of every set of accounts (in this case 1 payment event id for accts 77212 and 90899 AND another payment event id for the accounts 7883 and 90552) as CNGC would be using a payment transfer screen to transfer the amount that was posted incorrectly.

 

Data Mapping

 

The following fields are to be utilized:

 

Table Field Business Name
CI_FT FREEZE_USER_ID Employee ID
CI_FT CUR_AMT Transaction Amount
CI_FT FT_TYPE_FLG Transaction Type
CI_PAY ACCT_ID Customer Account Number
CI_FT FREEZE_DTTM Transaction Date:
SC_USER FIRST_NAME First Name
SC_USER LAST_NAME Last Name

 

Data Sorting & Grouping

 

Group By – Employee ID, Payment Event ID.

 

Primary Sort – Order Transactions Together By what ever will group related transactions together. Sorting by Employee ID (FREEZE_USER_ID) first and then sorting it further by PAY_EVENT_ID of CI_PAY. The FT table is connected to CI_PAY using the foreign Key PARENT_ID of CI_FT which will be the PAY_ID of CI_PAY.

 

Sample Output

 

See CL0704 Cash Payments Sample Output.xls for sample document.

 

Note:  Remember to grant Select privileges for CIS_READ and CIS_USER

 

Testing Criteria

 

No special testing criteria needed for this report.

 

Customer Sign-Off

 

Business Owner Date
Specifications Author Date
Project Manager Date

 End Document