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 | |
Data Collection Document Tech Specs | Ed Putnam | |
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:
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:
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’
|
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:
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: 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:
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’
· wtLinkType = Inventory Report, , GWPR Report (GSLA), CWPR Report (ESLA) · wtDnLdFileName, The name of the file being downloaded.
|
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:
- Events initiated by the customer (action events)
- 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:
- Account Group ID <meta name = ‘DCSext.wtAccntGrp’ content = ‘AccntGrpValue’>
- Agreement Number <meta name = ‘DCSext.wtAgreementNum’ content = ‘Agreement Number from Base’>
- Agreement Status <meta name = ‘wtAgreementStatus’ content = ‘Agreement Status from Base’>
- BAN Number <meta name = ‘DCSext.wtBAN’ content =‘ BANNumberValue’>
- Consolidator Type <meta name = ‘DCSext.wtConsolidatorType’ content = ‘BillingConsolidatorTypeValue’>
- Contract Type <meta name = ‘DCSext.wtContractType’ content = ‘ContractTypeValue’> Extract for contract name
- CSR Login ID <meta name =‘wtCSRLoginID’ content=’CSRLoginID’>
- CTN Number <meta name = ‘DCSext.wtCTN‘ content = ‘CTNNumberValue’>
- 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.
- FAN Number <meta name = ‘DCSext.wtFAN’ content = ‘FANValue’>
- Impersonator Type <meta name = ‘DCSext.wtImpersonatorType’ content=‘Impersonator type’> Expected Values Telesales, CSR maybe other values
- IP address is for user, not the load balancer, Akamai’s site. <meta name = ‘DCSext.wtIpAddress’ content = ‘IPAddressValue’> of the visitor
- 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
- Liability Type <meta name = ‘DCSext.wtLiabilityType’ content = ‘LiabilityValue’>
- LOSG (Buy Flow Type) <meta name = ‘DCSext.wtBuyFlowType’ content = ‘BFTValue’>
- 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’>
- Order ID <meta name = ‘DCSext.wtOrderID’ content = ‘OrderIDValue’>
- 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).
- Role <meta name = ‘DCSext.wtRole’ content = ‘RoleTypeValue’>
- 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.
- SBS Invoice Count <meta name=‘DCSext.wtSBSInvoiceCnt’ content = ‘the count of SBS Invoices based off the Contract id and Login>
- SBS Service Location Count <meta name=‘DCSext.wtSBSServiceLocCnt’content = ‘the count of SBS FANs based off the Login>
- Session ID < meta name = ‘DCSext.sessionid’ content = ‘TheSessionValue’>
- User ID / Login ID < meta name = ‘DCSext.wtLoginID’ content = ‘LoginValue’>
- 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
- Document History 5
- Related Documents 5
- Document Approvals 6
- Approvals 6
- Reviewers 6
II. Introduction 6
- Existing System 6
- To-Be Process 6
- Advantages of implementing 7
- Assumptions 7
- Scope Statement 7
- In Scope 7
- Out of Scope 8
- Risks/Issues 9
- Key Dependencies 9
III. The Existing and To-Be System Specifications: 9
- Existing System 9
- To-Be System 9
- System Modification Summary for POS 9
- Data Elements, POSLog file Changes 9
IV. POS UI Changes 10
- Use Cases 10
- Definitions 27
- Business Requirement 27
- Business Requirements Document 27
- Functional Requirement 27
- End-to-End Functional Requirements Document 27
- 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
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.”
- 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:
- Defective Handset
- Service Cancellation
- Retention/Customer Loyalty
- Customer Escalation
- System Error
- Price Adjustment
- 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:
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 | |
Sean Peterson | Architect – Retail | |
Brent Koons | EPO BSA | |
Dave Crum | EIT Business Solutions – SA | |
Ravi Ramalingam | Retail Testing Lead | |
Jason Siegel | Customer Delivery |
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:
- Reduced management headcount
- Reduced staffing for opening and closing
- Flexible staffing across co-located facilities
Assumptions
- All reports available thru the POS Menu will continue to report with the Original Store Location ID.
- No impacts are expected to the POS Book File and its supporting processes.
- 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:
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
- Orientation – Default to landscape.
- Margins – minimum ½ inch on top, bottom, left and right side
- Color – B&W standard. Color if requested.
- Parameters –
- Use business name for field names in prompts (e.g. Billing Date).
- Use format MM/DD/YYYY for dates.
- Specify date format in parenthesis on date parameters (e.g. Billing Date (MM/DD/YYYY)).
- Display run parameters as report subtitle: e.g. “Beginning Billing Date mm/dd/yyyy Ending Billing Date mm/dd/yyyy”
- Font: Default to Times New Roman or Arial
- Suggested Alignment (use as appropriate):
- Title, and Subtitle if any – center
- Column Headers – Use Business Name centered above column contents
- Detail Lines –
- Numbers – Negative numbers – shown with “-” in front of numbers.
- For reports with no data, display column headings only Title Line, Subtitle Line(s), along with “No Data Found” in the detail line.
- Use the Crystal layout templates for all reports.
- Report Title, Requesting User ID, Report Data Date, Page of Pages, Report File Location, and Report Parameters.
- 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.
- Begin separate lines for each SQL phase, including SELECT, FROM, WHERE, ORDER BY, etc.
- Within a phrase, list the first field name after 3 spaces and on the same line as the key word.
- Start each AND on a new line and as needed to align the field name with the field name above it.
- Place commas at beginning of lines as shown in the example.
- Place the semicolon on the end of the last line.
- To continue a line that doesn’t fit on a single line, indent 3 additional spaces from the first line.
- Table aliases should be meaningful.
- 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
- Revenue Admin
Manager
Power User
User
- Credit & Collections
Manager
Power User
- 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:
- 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:
- CI_FT
- CI_PAY
- CI_PAY_EVENT
- SC_USER
- SC_USR_GRP_USR
- SC_USER_GROUP
Data Extract should be based on the following criteria:
- Select all transactions from the CI_FT table where Transaction Date (FREEZE_DTTM) is equal to the System Date.
- Select only those transactions from CI_FT where the FREEZE_SW = ‘Y’
- 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.
- 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