Академический Документы
Профессиональный Документы
Культура Документы
Table of contents
1 General .........................................................................................................................2
2 Blueprint Reference.........................................................................................................2
3 Master Data required .......................................................................................................2
4 Functional Specification ...................................................................................................2
4.1 Input definition .........................................................................................................2
4.2 Output definition.......................................................................................................2
4.3 Input definition .........................................................................................................3
4.4 Output definition.......................................................................................................3
4.5 Input definition .........................................................................................................3
4.6 Output definition.......................................................................................................3
4.7 User interface ..........................................................................................................3
4.8 Device to be used for accessing the program................................................................3
4.9 Assumptions............................................................................................................3
4.10 Preconditions...........................................................................................................3
4.11 Authorisation ...........................................................................................................3
4.12 Transaction code definition ........................................................................................3
5 Open points in Business/User specification .........................................................................3
6 Appendix ............................................................................ Error! Bookmark not defined.
Page 1 of 3
1 GENERAL
The PRS (Project Requirement Sheet, referred hereinafter as PRS), is used for collecting the
project site requirements for the supply items & placing orders for the factory production. Thus, the
PRS document undergoes a complete life cycle (from creation till execution). Tracking of the PRS
document status, is required for facilitating business decisions.
(This FS must be read in concurrence with the FS PS-001-PRS).
2 BLUEPRINT REFERENCE
MPR.08.01
4 FUNCTIONAL SPECIFICATION
In case user enters specific PRS number, specific PRS status will be displayed to the user. If
user does not select PRS number, all the existing PRS for the project along with status should
be displayed to the user.
Multiple selection option will be provided to the user, for “Project ID”. User should be able to run
the program, for group of projects and should be able to view all the PRS documents, against
the selected list of projects.
** Note – Number of days will not be calculated for the status number 20.
The report should display only the live PRS. Set the default layout for the report, along with the filter.
The filter should display all the statuses except for the PRS, where the status value is 20.
Please find below the status number and status values to be used for the ZPRSTATR.
Page 2 of 3
4.3 Input definition
For storing the PRS document status values, create a custom table ZPRSTAT and store the
values of the statuses in this table.
The PRS is a project specific document and should be available to project managers, Regional
managers & PCH. Depending on management level, the PRS documents will be made
accessible. Due to dynamic nature of the business, the access should be flexible. Hence, a
custom table will be maintained, as below.
Custom table will have only first two columns and will be maintained by the administrator (basis),
in consultation with business.
The level based authorisation will be controlled based on the values in above table.
4.9 Assumptions
Program is able to record the status value and date, on real time basis.
4.10 Preconditions
Custom tables (referred in section 4.4) are available and populated.
4.11 Authorisation
Authorisation object (PROJ_PRCTR) is required for accessing the custom report (ZPRSTATR).
Page 3 of 3