Reports Functional Template
Company logo or project image here
Dont forget you can toggle the hidden help text on and off to
hide or show it!
Functional Specification for REPORTS
XXX-R-nnn Report NameThe Title page is a separate section. That
way, you can put any company logo or image on this front page in
the Header / footer section and it wont impact on the rest of the
document. If you want the same on all pages, then add it to the
header / footer of the next section also.
A common naming convention for RIEFs is usually put in place by
the project management. For instance, XXX here would be the three
letters symbolizing the team or module in which the report is to be
used. That is, FIN for Finance, DIS for Distribution, SAL for Sales
etc. Then R for Report, then nnn being the next consecutive number
assigned for Report RIEFs in this team. The Report Name should be
concise and relevant to what it does.
Date: Version:
Date. Should match the date for the revision number in Amendment
History and be updated each time accordinglyVersion number should
also match the Revision number in the Amendment History section. I
always send my document out for its first official review under
version 1.0 regardless of how many times I have worked on it before
then.
XXX-R-nnn Report Name goes in hereXXX-R-nnn Report Name can go
here or in headerPage 23 of 23ContentsHYPERLINK \l "_Toc323124945"
1Document semantics4HYPERLINK \l "_Toc323124946" 1.1Document
Properties4HYPERLINK \l "_Toc323124947" 1.2Amendment
History4HYPERLINK \l "_Toc323124948" 1.3Distribution5HYPERLINK \l
"_Toc323124949" 1.4Approval5HYPERLINK \l "_Toc323124950" 2QAs &
SIGNOFFS6HYPERLINK \l "_Toc323124951" 3Overview8HYPERLINK \l
"_Toc323124952" 4Functional Specification Overview9HYPERLINK \l
"_Toc323124953" 4.1General Information9HYPERLINK \l "_Toc323124954"
4.1.1Business Units Impacted9HYPERLINK \l "_Toc323124955"
4.1.2Reference Document9HYPERLINK \l "_Toc323124956" 4.1.3Model /
Process9HYPERLINK \l "_Toc323124957" 4.1.4Scope9HYPERLINK \l
"_Toc323124958" 4.2Controls9HYPERLINK \l "_Toc323124959"
4.2.1Report Description9HYPERLINK \l "_Toc323124960" 4.2.2Report
Controls9HYPERLINK \l "_Toc323124961" 4.2.3Dependencies9HYPERLINK
\l "_Toc323124962" 4.2.4Access Restrictions (Security)9HYPERLINK \l
"_Toc323124963" 4.3Processing10HYPERLINK \l "_Toc323124964"
4.3.1Starting Conditions10HYPERLINK \l "_Toc323124965"
4.3.2Frequency10HYPERLINK \l "_Toc323124966" 4.3.3Volume of
Data10HYPERLINK \l "_Toc323124967" 4.3.4Archiving10HYPERLINK \l
"_Toc323124968" 4.3.5Error Handling and Recovery Start10HYPERLINK
\l "_Toc323124969" 4.4Assumptions / Exclusions10HYPERLINK \l
"_Toc323124970" 5Report Functional Solution11HYPERLINK \l
"_Toc323124971" 5.1Distribution11HYPERLINK \l "_Toc323124972"
5.2Transaction Code11HYPERLINK \l "_Toc323124973" 5.3Selection
Screen11HYPERLINK \l "_Toc323124974" 5.3.1Criteria11HYPERLINK \l
"_Toc323124975" 5.3.2Attributes11HYPERLINK \l "_Toc323124976"
5.3.3Elements List11HYPERLINK \l "_Toc323124977" 5.4Data Extraction
Criteria11HYPERLINK \l "_Toc323124978" 5.4.1Fields in the
report11HYPERLINK \l "_Toc323124979" 5.4.2Error Handling11HYPERLINK
\l "_Toc323124980" 5.4.3Report Output Format11HYPERLINK \l
"_Toc323124981" 5.4.4Sorting Sequence.11HYPERLINK \l
"_Toc323124982" 6Testing Requirements12HYPERLINK \l "_Toc323124983"
6.1Selection Screen12HYPERLINK \l "_Toc323124984" 6.2Report
Execution and Layout12HYPERLINK \l "_Toc323124985" 6.3Report
Content12HYPERLINK \l "_Toc323124986" 6.4Custom Tables12HYPERLINK
\l "_Toc323124987" 6.5Authorisations12HYPERLINK \l "_Toc323124988"
6.6Test Data12HYPERLINK \l "_Toc323124989" 6.7Other Test
Cycles12HYPERLINK \l "_Toc323124990" 7Issues13HYPERLINK \l
"_Toc323124991" 7.1Technical Issues and Resolution13HYPERLINK \l
"_Toc323124992" 8Technical Specification14HYPERLINK \l
"_Toc323124993" 8.1Program Flow Logic (Pseudo Code)14HYPERLINK \l
"_Toc323124994" 9Implementation & Deploy16HYPERLINK \l
"_Toc323124995" 9.1User Instructions:16HYPERLINK \l "_Toc323124996"
9.1.1Procedures For Processing16HYPERLINK \l "_Toc323124997"
9.1.2Frequency16HYPERLINK \l "_Toc323124998" 9.1.3Manual
Processing16HYPERLINK \l "_Toc323124999" 9.1.4Error
Handling16HYPERLINK \l "_Toc323125000" 9.1.5Clearing Out
Directories16HYPERLINK \l "_Toc323125001" 9.1.6Problem
Reporting16HYPERLINK \l "_Toc323125002" 9.1.7SAP Programs and
Related Documents16HYPERLINK \l "_Toc323125003" 9.1.8Security
Checks:16HYPERLINK \l "_Toc323125004" 9.2SAP Job
Definitions16HYPERLINK \l "_Toc323125005" 9.3Issues16HYPERLINK \l
"_Toc323125006" 9.4Cross-reference documents16HYPERLINK \l
"_Toc323125007" Appendices17HYPERLINK \l "_Toc323125008" Appendix
A: Testing Plan17HYPERLINK \l "_Toc323125009" Appendix B: Text
Elements18HYPERLINK \l "_Toc323125010" Appendix C: TS Check
List19HYPERLINK \l "_Toc323125011" Appendix D: EPC and Code
Inspector19HYPERLINK \l "_Toc323125012" Appendix E: QA Check List
And Review Log19HYPERLINK \l "_Toc323125013" Appendix F: Object
List19Document semanticsDocument PropertiesOwner and contact
informationDocument Prepared by:
Authors name in hereProcess Owner:
The business owner name or business area in hereContact
Information:
A contact phone or email address for the process owner
Responsible Team:
This is the SAP project team responsible for producing this
specAmendment HistoryAmendment history for documentRevision
NoRevision DateAuthor(s)Comments/Major Changes
1.0
11-August-2011
Authors name
When its first issued for review, I call it Final Version. Any
changes made as a result of reviews by sign off points, can be made
as part of this same version. Then any subsequent changes to the
design after signoff will need a new revision number, V1.1, V1.2
and so on, and in this section a brief reason for the change such
as referring to the reason for the change such as a change request
number.
Summary of Changes since last revisionSection / TopicShort
Description of the Change
List the section of the report that has been changed. E.g. 3
Introduction4.1 Business Owners6 Testing Reqmts
Summarise concisely what changes were made in that section for
the version listed in the Amendment History above. E.g. V1.3
Section 3 Introduction changed to include additional distribution
channelsSection 4.1 Additional business owners addedSection 6
Testing cases and data sets expanded to include added business
areas
Distribution
List recipients for distribution of document
GroupRecipientRoleLevel of Involvement
e.g.Design Architect
Name here
Title or job role heree.g. Design Architect Distribution
What level of involvement does this role have? E.g. Approval for
Architects, maybe Input and Review for members of the design team,
maybe just Recipient for other roles just to keep them informed
Within the project the responsbile Design Team e.g
Distribution
e.g Sub-Team Lead
e.g.Review
e.g High Level Design Author
e.g Review
e.g Onshore Analyst
e.g Input / Review
e.g. Business Process Owner
Other impacted project teams such as other modules or the Deploy
Team or Support Team
e.g. Team Lead, Finance
e.g.Recipient
e.g Cutover Team, Analyst
e.g Recipient
e.g. Support Team Lead
e.g.Recipient
Any other groups you think need to review the spec?
ApprovalList of persons required for approval of
documentNameTitleDateSignature
e.g. Design Architect
Some projects will need a hard copy of the signed off spec held
on file
e.g Business Process Owner
QAs & SIGNOFFS
Design
Tech Design
Program Unit Test
DeployQA Date:
QA Date:
QA Date:
QA Date:
Author
Author
Developer
Author
Business Owner
Business Owner
Basis/DBA
Business Owner
Analyst
Analyst
Analyst
Analyst
Developer
Business Owner
Developer
Security
Security
Security
Basis/DBA
Basis/DBA
Basis/DBA
Support
Support
Support
The above table is a good way of keeping track where the QA
checks and signoffs are up to, if your project doesnt have a
separate method of tracking this. As each reviewer approves the
spec, they should add their name to the relevant box for the Design
column or the Tech Design column. Once unit testing is completed by
the developer, he / she should put their name in that field and the
date. Once QA checks are done with the Tech team and its handed
back to the Analyst for unit testing, the next boxes are filled in
with the appropriate names. Sometimes, this section may not be
relevant at all if that is the case for you, select the Table and
its heading and delete. If you do this, dont forget to update the
Table of Contents also .
Overview
Try and answer as many of these questions as possible to give a
clear, factual but brief overview of the report being defined:Who?
Which business units have requested the report? Is it country
specific or a global requirement? Is it just a single distribution
channel within this business area or will the report have wider
use?
What? Summarise what the report will contain and be used
for.
Why? Is it a legal requirement? Is it replacing a business
critical report from a legacy system? Why is the report needed?
What would the impact to the business be if this report was not
produced? E.g. would delays in deliveries or invoicing occur?
When? How often will the report be run and when? E.g. is it a
daily requirement or perhaps only at month end?
Where? Will this report be run locally at the business units or
centrally in a support area? Or will it be automated via a
background job? Where will the output be generated to a local
printer? A centralized printer? To nominated email accounts?
Remember: this is an overview and you will be covering the
detailed answers to these questions in the relevant sections of the
spec. Keep your answers in this section brief but clear.
Functional Specification Overview
General InformationBusiness Units Impacted
Who in the business is this report key to? Which business areas,
which distribution channels, which divisions? Summarise or list
these here.
Reference Document
If there is a high level design document or a change request
document, then provide links to those or insert the files. Model /
Process
In words, briefly describe the business process that this report
fits into.Then insert a simple process flow that shows the
consecutive steps in the business process and where the report is
triggered / run. Refer to Part 2 chapter 11 and Part 3 chapter
4.1.3 for examples and more details.Scope
Think about the use of the report by its business owners and key
users. Briefly describe its scope here. For instance, is it only to
include deliveries that have been post goods issued in the last
seven days; or Transportation Shipments of a certain status; or
products maintained within specific distribution channels?
Controls
Report Description
Describe in short understandable sentences what the report will
cover, when it will be used, by whom and why. Details should
include the starting point for the report, what options are
available in the selection screen, the type of data that the report
will extract, and whether there are any custom tables that the
report extraction will rely on.
Continue on to detail the report functionality.See Part 2
Chapter 11 for further detailsReport Controls
Consider any legal and fiscal control requirements that may be
relevant for the report. Will it display any sensitive corporate
data that only specific users should have access to such as pricing
structures? Is it country specific data that users of the same role
in other countries should not see? Refer to Part 2 Chapter 11 for
further details.Dependencies
Is the report dependant on any other development such as a form
or an enhancement or interface? If so, list enough detail here for
the technical team to realize that they need to co-ordinate this
development with the others in the dependant group.
Access Restrictions (Security)
Business Role Name:
Which business roles will need to run this report? Are new roles
required or will existing roles be extended?
Transaction:
Provide Technical name of new transaction if already known. Make
sure you follow the naming convention provided by your project
management. Part 2 Chapter 11 for further help
Transaction Type:
Outline the type of the transaction (e.g. Display, Update, Table
maintenance, upload, download). If it is a table maintenance
transaction also outline the table name.Restrictions /
Authorization Checks:
The security team will need to know if the report data should be
restricted to just specific enterprise objects like sales
organization or company code. If so, then you should detail the
authorization object to be checked here and any specific values
applicable.. See Part 2 Chapter 11 for further helpData
Classification (unrestricted/restricted/confidential):
How Is the report data to be classified? As Unrestricted,
Restricted (and in what way) or Confidential (to whom and why)
Processing
Starting Conditions
Are there conditions that must be met before the report is run?
What are they? Is there a pre-requisite step that must be completed
prior to running the report? Are there mandatory data requirements
that must be in place first? Frequency
How often will the report be run? Could multiple users execute
it at potentially the same time? What you detail here will help the
technical team consider performance issues if it is to be run
regularly during high use times on large volumes of data.
Volume of Data
Your business contact should be able to estimate fairly
accurately the volume of data that the report will need to extract
from. For instance, if it is a Sales Order report, how many sales
orders are being created per day? If it is a report on deliveries,
how many deliveries of this type will be processed daily?
Archiving
Will the volume of data and the method of report execution
require an archiving strategy in the future? Do the tables that the
report extracts from contain very high levels of data that may
impact on the report performance? See Part 2 Chapter 11 for reasons
why this is important even now when you are still drafting your
spec! Error Handling and Recovery Start
This section should briefly outline the process if there are
problems. Think of the different ways the report can be executed
online, by batch job and so on. If execution fails, what do you
want the user to be presented with? Should there be an error log
produced? If so, should it be communicated to someone? Should the
report be able to roll back and re-start? If the report is run in
the foreground and has problems, what should the user see? Detail
the answers to these questions here. Assumptions / Exclusions
If the report is to exclude certain types of transactions, then
list those here. If you have had to base your design on assumptions
then you must detail those here! If you have any unanswered
questions from your business contacts, then those are likely to be
relevant to the design and have meant assumptions on your part just
to progress so include those also.
Report Functional Solution Distribution
How will the report be distributed? Will it be only run to
screen? Can it be printed, and if so, will it be portrait or
landscape? What type of printer laser or dot matrix? Double sided
or single?Can it be emailed? Can it be downloaded to an Excel
spreadsheet? What other methods of distribution do the technical
team need to develop within the report?Transaction Code
List the report transaction code here. This should be the same
as what you have detailed in the Section 4.1.8 Access Security
section
Selection ScreenCriteria
Detail in words what the selection screen will contain. Will it
be in separate sections broken up by the type of data, or one block
of many fields? What are the field names, default values and are
they mandatory? See Part 2 Chapter 12 for further help.
Attributes
Describe the selection screen name and the languages to be used.
Provide a simple mock up of the selection screen showing the layout
that you want.
Elements List
In this section, put in a table that shows the field names,
field type, format, length, whether the field is input or output
only, mandatory or optional, any default values, texts, check table
and additional comments for every field to be shown on the
selection screen. See Part 2 Chapter 12 for further help.
Data Extraction Criteria
The data extraction for a report can be quite complex so it
often helps to show it in a diagram format in addition to
describing it in words. If possible, put a simple flow diagram of
the data extraction here. Also detail any new custom tables that
may be required to support this report, perhaps for validation
purposes. See Part 2 Chapter 12 for further help
Fields in the report
In this section, you need to be as clear and logical as
possible. Begin with thinking about the logical order of data in
the report. You know by now which fields are needed in the report
and in what order, so list the extraction criteria for each piece
of data in the same order. It often helps to number the extraction
criteria as you go, eg 1 extraction criteria for delivery number, 2
extraction criteria for determining plant and shipping point and so
on. Then if later data is dependant on earlier extraction criteria,
it is easy to be clear and refer to that step.
Be clear which aspects of the selection criteria should be used
and how, any other extraction logic required or validations such as
checking for certain statuses or processing dates. Include details
of any other filtering logic you need the Technical team to build
in to whittle down the extracted data to just what is required
within the report. You should never include code or actual logic
statements in your functional spec as that is the responsibility of
the Technical team but you should be able to detail the table and
field names for each of the data required and describe in words
what you want the developer to do with it. See Part 2 Chapter 12
for further help
Error Handling
Insert a simple table here that lists the Error condition on the
left and the error message that you want on the right of it. For
example, if the shipping point is a mandatory selection field and
has not been filled in, your error condition might be shipping
point not entered and your error message Enter shipping point. See
Part 2 Chapter 12 for further tips.
Report Output Format
In this section, make it clear what you require to be shown in
the report header, footer, screen title as well as the report item
level details. Include specific requirements such as the format on
the screen (e.g will it be an ALV report?), any colours to be used,
font sizes and so on.Include a mockup of the report (Excel is
useful for this) and a mockup of a screenshot if you want
(powerpoint is a quick and easy way of doing this).
Sorting Sequence.
How should the report results be sorted? Are there additional
sorting sequences to be used within columns of data?
Testing Requirements
There should be a Testing Requirements sub section in your spec
for each major area of your new report. Ive listed the common areas
below. You may need to copy, paste and rename to add extras or you
may decide that one of these is not relevant in which case you can
either put N/A for Not applicable, or you can delete that sub
section from your spec. For example, if your report development has
not needed any new custom tables to be defined then you would not
need that sub section in your spec.
For each testing requirement area, you need to list the key
aspects and functionality that must be unit tested. These are the
features and requirements of your report. I usually bullet point
these per section so that I can build my test plan around them. I
aim to have a unit test plan with many test cases for each testing
requirement area. I have provided some brief guidelines for each
testing requirement below but a fuller explanation can be found in
Chapter 13 of the book.Selection Screen
Everything about the selection screen must be unit tested. List
the key aspects here as follows so that you can incorporate them
easily into your test plan later:For Example:Layout of selection
screen is as per detailed design in section 5 of this specRadial
buttons can be activatedMultiple values can be entered for every
field
.and so onDont forget to test mandatory versus optional fields,
all possible types of values for each fields such as alpha,
numeric, sequential and non-sequential ranges, exclusions and so
on. Error messages should also be tested along with any other
functionality you have requested such as the ability to create,
change, retrieve and delete variants.Report Execution and
Layout
Working back through your detailed design section 5, make a list
of all of the functionality that you need to test such as executing
the report to screen, executing in background, executing and
sending to email, downloading to Excel, printing and so on. These
are the requirements that you need to make sure the developer has
accurately understood and provided in the new report.With regards
to layout, you will need to ensure that the layout in every method
of execution is fully tested. That means that the layout of the
download to Excel is as per your design and the User Requirements,
as well as the layout to screen, layout sent via email and so
on.Layout unit testing should include checking that every column of
data expected is shown, that when no valid data for a column is
extracted, that the displayed result is as you expect (i.e. blank
or with a zero or whatever)Report Content
Too often the only part of a report that is truly unit tested
when it should be is the report content. Making sure that every
piece of data extracted for the selection criteria entered matches
your expectations is very important. The test plan, test cases and
test data used are crucial to decent unit testing. In this section,
I would bullet point the key pointsFor example:All data extracted
for the selection criteria entered meets the extraction rules
defined in section 5 of this specWhen no valid data is extracted
for a column, the field content is blank (or whatever you have
specified)When no data is extracted at all, an error message to
that effect is displayedAnd so on, remembering to include tests on
all possible error messages and execution methods to ensure that
the report content is accurate and consistent across all of
them.Custom Tables
If you have requested a new custom table to be defined to
support this report, then you must test that a user can create new
entries in the table if applicable, change entries, delete entries,
and display entries. Any custom transaction defined for use with
the table should also be tested.If an existing custom table will be
used to hold data that your new report is reliant on, then you will
need to unit test that the report is accurately retrieving that
data as specified in section 5Authorizations
Provide a negative and positive test plan for the specific
roles. The Security team may not provide a test user id time for
your unit test of the development but detailing the testing
requirement in your spec means that it can be properly tested when
it is made available.Test Data
Specify what test data is available for the report and what is
necessary for a unit test by programmer, functional consultant
and/or key users in which environment. Do not be lazy here! Make
sure you provide more than one material of each type, at least one
customer / vendor / GL account of each type that is relevant, or
identify a number of transactional data that can be used. Use table
browsing to try and find relevant data and then list it here per
field in the selection screen so that the developer can quickly
enter the data to test what he needs to without coming back to you
with questions all the time. Think also about data dependencies
such as whether stock is in place for a goods issue, whether
standard texts have been defined and so on.
If test data does not exist please list the steps necessary to
create test data required to test the program(s). Please provide
valid data and paths necessary to execute the transaction. This
includes company codes, sales organizations, document types,
plants, G/L accounts, etc. An example is listed below.]
Transaction: Menu Path: Step 1: Step 2: Step 3:
Other Test Cycles
List the names of the integration test scripts or business
processes that this report will need to be included in for end to
end process testing
IssuesTechnical Issues and Resolution
This section is used after the development is in place for
listing change requests or issues that have resulted in a change to
the design. It may also be used during development if the proposed
design is not appropriate, for instance, performance issues have
arisen during testing or emails of the report cannot be triggered
in the method described. The technical issue and its reference
number should be briefly described and the resolution documented in
this section. Then the relevant sections of the functional spec
should be updated and hyperlinked from this section so that the
resulting spec clearly documents the end result. See Part 2 Chapter
14 for further details
Technical Specification
This section should outline in more detail the technical
solution. This will be completed by the technical analyst and
should contain information such as pseudo code, detailed database
selects, complex calculations and conversions, critical decision
logic etc. It should also outline performance considerations. Any
additional authorisation checks need to be included here. The
technical analyst should request assistance from the functional
analyst as required. This section should help to ensure that the
technical analyst has understood the functional design, and can
convey the development requirements to the developersIf additional
technical documentation is available but not included in this
document then cross-reference here.
Program Flow Logic (Pseudo Code)
Implementation & DeployUser Instructions:Procedures For
Processing
List the steps in running the report including transaction
codes, and program names plus any custom tables that require
maintenance to support the report. Any data or steps that must be
in place before the report can be successfully run should be
clearly identified here
Frequency
How often will the report be run and by what methods?
Manual Processing
If the report is business critical and is unavailable for any
reason, is there any other way that the Users can obtain the
information they need temporarily? For instance, table browses on
which tables? List the applicable steps and selection criteria to
be used
Error Handling
Summarise the error messages and the actions to be taken from
your detailed design in Section 5. A table listing potential
errors, actions and notification procedures where applicable would
be useful
Clearing Out Directories
If the report output is saved as a file output on a shared
directory, then list the details of that directory, and who is
responsible for archiving old reports from it and when. Otherwise
mark this section as Not Applicable
Problem Reporting
List who should be contacted or to which area in support that a
service center ticket needs to be generated.should problems develop
with the report after it has gone live
SAP Programs and Related Documents
List any other programs and their documents affiliated with this
report.
Security Checks:
List the names of any roles, authorizations (authorization
objects, values) or profiles that are being used to execute the
report.
SAP Job DefinitionsJob Name:________________________
Step #Program NameVariant UsedPrint RequirementsSubmitted
JobsSAP Updated(yes,no)
Name (Is any maintenance required of variant)
Printer Name, User, Title, who will receive the report
List any BDC, RFBIBL00, or other jobs submitted by this
step.
Does this step update SAP? For a report, this should always be
NO
Clearly note whether the Deploy team will need to set up the
report as a background job when it goes Live, with details of any
variants that would be required (i.e variant per sales organsation)
and the frequency the job would need to be run. The rest of these
details will be filled in by Deploy and used as reference by the
support teams after Go Live
Issues
Note any design points or questions which remain open.
Cross-reference documents
Attach any relevant documents or describe clearly where they are
kept on shared directories.
AppendicesThe appendix should cover any essential information
not already covered in the sections above, such as the detailed
testing plan .
Note, Appendices C, D, E and F are usually completed by the
Technical Team as part of their internal code reviews and handover
Appendix A: Testing Plan
No.Test Conditions and CasesTest DataExpected ResultsActual
ResultsPass/Fail
1
Selection Screen
A
Report is executed using selection data in all but one mandatory
field
Populate all other selection fields except the first mandatory
field (use sales orgn A101, company code A100, plant Z120, date
range today plus 7 days, radial not selected).Repeat for each
mandatory field
All mandatory fields generate error messages when not populated
with valid entries
B
Radial button can be selected to restrict report to current
months data only
use sales orgn A101, company code A100, plant Z120, date range
one month ago plus 37 days, radial selected.
Report executed. Radial button selected. Data returned for
current month only
Create a Test Condition for each of the Testing Requirements
areas that you identified in Section 6. Within each you will have
many test cases to test each of the aspects that you have
identified. Some of these aspects can be grouped together into the
same test case. For instance testing mandatory fields. The test
case can be repeated with differing test data to test each
mandatory field.This section must capture all of the key
requirements to be tested with sufficient detail in the test data
for the development team to use in their own unit testing before
signing it over for the formal Unit Test. Therefore, you MUST also
state the expected results so that they are clear what is required.
Refer to Part 2 Chapter 13 in the book for further details.
Appendix B: Text ElementsText ObjectText IDText typeReport
LocnLangText ValueRestrictive Criteria (please specify)
LegendText ObjectText IDSAP table object related to the text
field Example: VBBK.Identifier of the text field in SAP or the
Standard text name Example: Z900 or ZREPORT_HEAD_NNNN
Text TypeThe choices here would beDocument (i.e. Sales Order,
Delivery) ; Master Data (i.e. Customer) ; Static (i.e. Information
that is the same for every form that is not part of the title,
column headings, or a label for a given piece of data Example:
Privacy statement at footer of report) Standard Text (defined in
trxn SO10);
Report LocationThe choices here would be:HD Header;IT Item;FT
Footer;
LanguageThe language that the text element is to be printed in.
For example, FR for French, EN for English
text valueWhere possible, put the actual text value (if it is a
standard text element or static text), or expected examples if it
is a document or master data text type. If I have many entries or
the text values are too long to fit into this small table field,
then I refer to an Excel spreadsheet and then embed that document
just underneath the table.
Restrictive CriteriaAny specific exceptions, rules or special
situations that could occur can be added here.Example: Only print
the Terms of Conditions when the company code language is
English.
If the report can contain different text elements for different
report users, then you will need to clearly define the requirements
in Section 5 and summarise them here. For instance, if column
headings are to differ per company code being reported on, or if
the User Defined language differs from the default and the report
headings need to be retrieved in that language. If text elements
are not relevant for your report, then mark this section as Not
Applicable
Appendix C: TS Check List
Appendix D: EPC and Code Inspector
Appendix E: QA Check List And Review Log
Appendix F: Object ListDevelopment TypeName in
DevTransactions
Package
Revtrack
Programs
Tables
Data Element
