IMPLEMENTATION PAPER_FUNCTIONAL AND DEVELOPMENT (IP_FD) ♦ IP DATA MIGRATION ASSETS IP-NUMBER:<NUMBER>

Document reference Document type (e.g. GAP IP Functional X) Owner (company) Last edited by Last edited on

<IP Number>_IP_FD_<IP Name> GAP IP Functional Development AMOS SE GRP@AGA <yyyy-mm-dd>

Development Functional and Technical Specification

Table of Content
1 General Information.......................................................................................................................................6 1.1 Document Change History.......................................................................................................................6 1.2 Purpose of this document.........................................................................................................................6 1.3 Business Needs and Requirements.........................................................................................................7 1.4 Open Issues.............................................................................................................................................8 2 Functional Description...................................................................................................................................9 2.1 Solution Overview....................................................................................................................................9 2.2 Legacy Asset Data Transfer..................................................................................................................10

2.2.1 Set Company Code Status....................................................................................................................10 2.2.2 Specify Sequence of depreciation areas...............................................................................................10 2.2.3 Specify Transfer Date / Last Closed Fiscal Year...................................................................................11 2.2.4 Specify Last Period Posted in Previous System (Transf. During FY)....................................................11 2.2.5 Transfer Foreign Currency Values........................................................................................................11 2.2.6 Recalculate Depreciation for Previous Years........................................................................................12 2.2.7 Set Reconciliation Accounts (Manually)................................................................................................12 2.3 Impacted business process ...................................................................................................................13 2.4 Impacted sub-process............................................................................................................................13 2.5 Data Requirements................................................................................................................................13 3. Technical Description – Development Types.............................................................................................14 3.1 SAP Enhancement.................................................................................................................................15 3.1.1 Table Access Diagram..........................................................................................................................15 3.1.2 Custom Tables / Structure in SAP.........................................................................................................15 3.1.3 Data Validation......................................................................................................................................16 3.1.4 Data Flow Diagram................................................................................................................................16 3.1.5 Pseudo Code.........................................................................................................................................17 3.1.6 Technical details....................................................................................................................................17 3.2 SAP Conversion.....................................................................................................................................22 3.2.1 Data Cleaning Requirements................................................................................................................22 3.2.2 Extract Logic .........................................................................................................................................22 3.2.3 Currency and Units of Measure ............................................................................................................22 3.2.4 Language of Texts ................................................................................................................................22
IP_FD <IP Number> <IP Name> page 2 of 80

Development Functional and Technical Specification
3.2.5 File Layout (In Sequence).....................................................................................................................23 3.2.6 Selection Screen Details (if applicable) ................................................................................................23 3.2.7 Starting Condition (Optional) ................................................................................................................23 3.2.8 Business Rules (Optional) ....................................................................................................................23 3.2.9 Table Access Diagram..........................................................................................................................23 3.2.10 Selection Criteria.................................................................................................................................24 3.2.11 Data Conversion & Interface Definition...............................................................................................24 3.2.12 Data Mapping Matrix...........................................................................................................................25 3.2.13 BDC Method........................................................................................................................................25 3.2.14 LSMW ................................................................................................................................................26 3.2.15 ALE Configuration (optional)...............................................................................................................28 3.2.16 Custom Dictionary Objects (optional)..................................................................................................30 3.2.17 File Layout...........................................................................................................................................30 3.2.18 Performance Considerations (optional)...............................................................................................30 3.2.19 Dependency........................................................................................................................................30 3.2.20 Relevant Function Modules.................................................................................................................30 3.2.21 Pseudo Code.......................................................................................................................................30 3.3 SAP Forms.............................................................................................................................................32 3.3.1 SAP Script/Forms..................................................................................................................................32 3.3.2 Execution Mode Details.........................................................................................................................32 3.3.3 Technical Details...................................................................................................................................33 3.3.4 Table Access Diagram..........................................................................................................................36 3.3.5 Custom Tables / Structure in SAP.........................................................................................................37 3.4 SAP Interface.........................................................................................................................................38 3.4.1 Interface Classification..........................................................................................................................38 3.4.2 Interface Functionalities........................................................................................................................39 3.4.3 Interface Data Requirements.................................................................................................................39 3.4.4 Table Access Diagram..........................................................................................................................42 3.4.5 Selection Criteria...................................................................................................................................42 3.4.6 SAP Requirements................................................................................................................................43 3.4.7 Middleware Solution..............................................................................................................................44 3.4.8 Legacy System Requirements...............................................................................................................44 3.4.9 Data Conversion & Interface Definition.................................................................................................46
IP_FD <IP Number> <IP Name> page 3 of 80

Development Functional and Technical Specification
3.4.10 Data Mapping Matrix...........................................................................................................................47 3.4.11 File Layout...........................................................................................................................................48 3.4.12 Dependency........................................................................................................................................48 3.4.13 Relevant Function Modules.................................................................................................................48 3.4.14 Pseudo Code.......................................................................................................................................48 3.4.15 ALE Configuration (optional)...............................................................................................................49 3.4.16 Custom Data Dictionary Objects (Optional).........................................................................................50 3.4.17 Performance Consideration (Optional)................................................................................................51 3.4.18 Interface Controls................................................................................................................................51 3.4.19 Compliance.........................................................................................................................................53 3.4.20 Miscellaneous Data Capture (Optional)...............................................................................................54 3.5 SAP ECC Report....................................................................................................................................56 3.5.1 Technical Solution.................................................................................................................................56 3.5.2 Selection Screen...................................................................................................................................56 3.5.3 Starting Condition..................................................................................................................................58 3.5.4 Data Mapping Tables............................................................................................................................59 3.5.5 Detail Logic Diagrams...........................................................................................................................60 3.5.6 Interactive Report Flow.........................................................................................................................68 3.5.7 Sort Criteria Details...............................................................................................................................68 3.5.8 Calculations and Page Break related information..................................................................................68 3.5.9 Custom Tables / Structure in SAP.........................................................................................................69 3.5.10 Recovery and Restart..........................................................................................................................69 3.5.11 Language of texts................................................................................................................................70 3.5.12 Currency and Units of Measure...........................................................................................................70 3.6 SAP BW Report .....................................................................................................................................71 3.6.1 Report Description: ...............................................................................................................................71 3.6.2 Report Layout........................................................................................................................................71 3.6.3 Report Selections and Navigation.........................................................................................................71 3.7 SAP Workflow........................................................................................................................................73 3.7.1 SAP Workflow Diagram.........................................................................................................................73 3.7.2 Technical description.............................................................................................................................74 3.7.3 Business Object Information..................................................................................................................75 3.7.4 Workflow Definition................................................................................................................................76
IP_FD <IP Number> <IP Name> page 4 of 80

...............................................6 Reporting / Form Requirements..........................................77 3.....................................7....................................................78 3.. Security and Authorization Requirements....8 Custom Tables / Structure in SAP............................................................................79 5...................................7.........................................................80 IP_FD <IP Number> <IP Name> page 5 of 80 ........................................................................................................................Development Functional and Technical Specification 3.7.............................78 3.............................................................. Attachments.....78 4......................10 Configuration Information....................................................9 User Exit / Enhancement Detailed Description............................................................77 3............5 Deadline Monitoring Requirements........77 3...........................................77 3...................7..................7..........................................................................................................................7 Custom screen design....................................................................7..8 SAS Developments...............................

Currently the to-be solution is represented by the GRP kernel solution in order to meet those targets. several GRP rollout projects have been performed by different operational units (OE) in the past in order to enhance the reporting speed. According to the Global Reporting Program (GRP) running since 2002. the document is used to provide him with all relevant details on functional requirements (function and features).2011 1.2011 18.Development Functional and Technical Specification 1 General Information This document has been created within the framework of the GRP@AGA project. SERVANTISSIMO Document Change History) to SAP CAP.07. IP_FD <IP Number> <IP Name> page 6 of 80 .2 Purpose of this document This document describes from a business perspective the purpose of the required migration. In order to meet the business requirements of asset accounting there is a need to migrate the asset master data records from the feeder systems (e. The GoLive of the pilot project – rollout on Mondial Assistance France (MAF) – is planned for the 2012-01-01. The core aim of the GRP@AGA project is to deliver homogeneous system platform (SAP ERP) for all insurance and non-insurance related finance departments at OEs belonging to AGA INTERNATIONAL S. (AGA Group). This will align AGA Group with the rest of the Allianz business globally through the implementation of a global template (GRP kernel solution). Moreover. There are two different ways of migrating data from feeder systems. The migration focus is on asset master data. This document will discuss loading fixed assets using two methods.g. information on GAPs.07. 1. which will have to adhere in general to already accepted GRP solution for MAF based on the GRP kernel solution. It will be followed by rollins on the different OEs. and the technical description for a development in SAP or SAS needed.A. Realisation of the project will be conducted in several steps. It should also provide the developer with a logical overview of what data has to be migrated using BDC/LSMW. quality and efficiency.1 Document Change History Date Changed by Yagna Reddy Michel Schneider Chapters changed All 1 and 2 Reason for update Creation of file Feedback of internal review 08.

it was specified to be written off in depreciation area 20 (cost-accounting depreciation) within a period of three years. 4. Standard Mapping is done in LSMW and data validation is done implicitly by SAP whereas in BDC we have to do it explicitly. a right. LSMW doesn't supports whereas in BDC. Example: In the valuation section for a machine. maintain.3 Business Needs and Requirements A fixed asset is an object. 1. 2. 2. but rather updating one field in fixed assets which already exist in the system then this might be the right approach. For a one-time conversion into SAP. IP_FD <IP Number> <IP Name> page 7 of 80 . Batch Input. General Master Data / Organizational Assignments This part of the master record contains general information about the fixed asset. 3. we use LSMW tool. 1. LSMW is used for SAP standard applications whereas BDC is for customized applications. BDC recording This is suitable for a very basic upload. and evaluate master data. Valuation Parameters In the valuation section of an asset master record is defined. The machine is to be written off using straight-line depreciation. we can do it manually. or another item owned by an enterprise that is intended for longterm use and can be individually identified in the balance sheet. Difference between LSMW and BDC are 1. Recording. yet it does a lot of the file management and processing work automatically.Development Functional and Technical Specification 1. Please refer to IP 320336_IP_FC_WS1_Customizing_ FIAA_Fully_New for further information on the customizing of FI-AA for AGA. Direct input. how a fixed asset is valuated for each depreciation area. It allows you to leverage the full power of ABAP while using standard SAP processing functions. changing. But it is not flexible enough to be used for the creation of fixed asset data. and displaying asset master records. LSMW internally might well in using IDOCs. 2. If for example you are not creating fixed assets in SAP. The different items of information are structured according to area of use and functions in the system to make it easier for users to create. Maintaining fixed assets involves creating. Each asset master record consists of two parts that are described below. For any data complexity. A new LSMW for AGA on client 780 will have to be written for the data migration.

Identifying the tool (whether LSMW or BDS) to migrate the legacy data IP_FD <IP Number> <IP Name> page 8 of 80 . 2.4 Open Issues 1.Development Functional and Technical Specification 1. Asset Master data of Allianz Global Assistance has to be provided.

balance sheets for tax purposes. in asset accounting the day to day transactions is posted with values through FI bookings and at the same time the asset reconciliation is updated online realtime. Company Code: One Fixed Asset is assigned to one company code. Normally.Development Functional and Technical Specification 2 Functional Description 2. However. SERVANTISSIMO) with the respective master data on SAP FI module using data migration. Depreciation area: An area showing the valuation of a fixed asset for a particular purpose (for example. Old Fixed Asset Number: You can enter Legacy Asset number in this field to keep a track of the old numbers. Data migration is slightly different from a normal transaction which happens in Asset accounting module. but only to this date being the default for the asset value date when the first acquisition is posted. The reconciliation accounts are updated manually through another transaction code called OASV.1 Solution Overview The functionality of the migration is aimed at the synchronisation of the feeder systems (e. So it will be uploaded into SAP through flat file. or management accounting values). then this check box has to be checked. depreciation area and other master data are associated with the Asset Class. The reconciliation GL account is not automatically updated at this point of time. 2) 3) 4) 5) 6) 7) 8) IP_FD <IP Number> <IP Name> page 9 of 80 . Creating a Legacy Asset needs following information to be uploaded: 1) Asset Class: Each asset master record must be assigned to one asset class. this does not lead to the asset being capitalized. Asset Class can be determined based on legal or management requirements. Normally.g. Description: Description of the Fixed Asset Manage Historically: If it is legacy Asset and using transaction AS91. Capitalization Date: The capitalization date is the value date of an asset. Cost Center: The SAP system uses the cost center assignment in the asset master record to determine the cost center affected when fixed asset depreciation or Gain/loss from asset sales type of postings are done. Whereas in data migration the asset master is updated with values through a transaction code called as AS91. for individual financial statements. You can also enter this date manually when creating an asset.

Before the system goes live. If there are additional depreciation areas for local /fiscal purposes.1 Set Company Code Status Test status . Production status . it is essential that you set the system status to "production" (not test).We can change values by transferring asset data from a previous system. 10) Take Over values: These are filled depending on the Customization and Depreciation areas.2. In this step. 2. You can only change values by posting.The asset data transfer is complete. Transfer status . During the transfer of legacy data. the sequence of the depreciation areas for the data takeover transaction is specified. After completion of migration company code status must be changed to ‘0’ to avoid inconsistencies in depreciation calculations.2. the sequence for the depreciation areas may be impacted.Development Functional and Technical Specification 9) Depreciation Key: The depreciation key (valuation key) controls the valuation of the asset in the particular depreciation areas. or by posting.We can enter and change values by transferring asset data From a previous system.e 2 till asset master data is transferred using Transaction Code AS91and balances are updated in transaction code OASV.reporting allowed Company code status is set to Test i. IP_FD <IP Number> <IP Name> page 10 of 80 .2 Legacy Asset Data Transfer 2. Categories of Status 0 Asset data transfer completed 1 Asset data transfer not yet completed 2 Test company code with data transfer always allowed 3 Company code deactivated . but posting is not possible. the first depreciation area to be transferred is generally the book depreciation area.2 Specify Sequence of depreciation areas In this field we define the order in which you want to update depreciation areas with values during legacy data transfer. You determine this sequence by entering a relative number in this field. Which status will we use when? 2.

01. In this step. 2. you must specify the period up to which depreciation was posted in the previous system. We can only make an entry in this field for an area which is managed in foreign currency. with no changes allowed) as it normally would. and the transactions in the current fiscal year (the second is only possible for transfer during the fiscal year). Allianz Global Assistance is going live on 1st January.01. 2011 Last closed fiscal year 2011 Specify the take over date as 31. In this case. determine that foreign currency areas can receive values during old assets data takeover. the legacy data will be transferred on 31. In this case we specify that depreciation was posted up to 31st December 2011 in the previous (legacy) system. This period refers to the posted depreciation that is to be transferred during old assets data takeover. If the transfer date is not the last day of the fiscal year (according to the fiscal year variant in FI). Then the depreciation areas are not supplied with values from another area by the system. 2011. This specification can only be made for areas that are managed in foreign currency.2. IP_FD <IP Number> <IP Name> page 11 of 80 .2012 To make it simple. The company is going live with SAP on 01.2012 2. you specify that you will provide values for the foreign currency area during the legacy data transfer.2. During FY) This step is only necessary if you want to perform an old assets data takeover during the fiscal year.12.12.5 Transfer Foreign Currency Values This is important to that carry out this step if you manage depreciation areas in foreign Currencies.3 Specify Transfer Date / Last Closed Fiscal Year Here we specify the transfer date for the Allianz Global Assistance asset data transfer.4 Specify Last Period Posted in Previous System (Transf. although they are defined as dependent areas by the Customizing settings.Development Functional and Technical Specification 2. Using this indicator. the system interprets this as transfer during the fiscal year. The system then does not provide values itself for the area (by taking over values from another area. Posting up to this date will be included in the transfer. This specification also determines whether we want to perform the transfer during the fiscal year (with transfer of posted transactions/depreciation in the current fiscal year) or at the end of the fiscal year (without transactions).2011. Example: Transfer date is last day of the fiscal year • • • • • Transfer date – December 31. This date determines the status of posting to be used for the transfer.2. 2012. It can only transfer cumulative values from the end of the last fiscal year. The system cannot transfer any historical transactions. -> Does that mean it will be technically migrated into SAP CAP only on the 31st December? System will start calculating depreciation from 01.

This is maintainable in each client except production where this step is managed by the cutover strategy. the flag is removed from the GL accounts per asset class per company code. that the manually input flag will change position and will require updating. the takeover values for this depreciation area is calculated manually/automation tool. Is that really clear already? Up to now I thought we would load the assets data into SAP CAP at their original value and then depreciate them in SAP using the depreciation run. OAMK allows this to be carried out manually. What are the consequences of using one or the other way? 2.6 Recalculate Depreciation for Previous Years If you need system to recalculate depreciation for the previous year up to the date of the transfer there is an option available to calculate depreciation.2. Do we need to transfer assets in foreign currencies? 2. By default the relevant GL accounts will have been created as reconciliation accounts. Normally this step is not done. Carried out directly in client during cutover. the system will only post to them via Asset Accounting from this point onwards. Please note that if any change to depreciation area sequence is undertaken. Once they are set as reconciliation accounts. As part of the conversion. since the depreciation calculation by SAP might differ due to some rounding difference.Development Functional and Technical Specification For any Depreciation area with foreign currency values fixed at the Group Rate as at the takeover date.7 Set Reconciliation Accounts (Manually) This step is required for conversion purposes. the reconciliation flag is reset.2. timing difference as compared to the legacy system. After the balances have been loaded. IP_FD <IP Number> <IP Name> page 12 of 80 .

IP_FD <IP Number> <IP Name> page 13 of 80 .xlsx The format of this file needs to be described. GUIDANCE ONLY: < Provide the high level description of the impacted sub .business process at transaction level.3 Impacted business process TEXT TO BE REMOVED.5 Data Requirements Require flat file for migrating the data from legacy system to SAP. GUIDANCE ONLY: < Please provide the high level description of the impacted business process > END OF GUIDANCE TEXT Text 2. FF_AA.Development Functional and Technical Specification 2. > END OF GUIDANCE TEXT • Impacted Sub-process 1 Text • Impacted Sub-process 2 Text 2.4 Impacted sub-process TEXT TO BE REMOVED.

GUIDANCE ONLY < This chapter is used to describe all relevant technical details for SAS or SAP developments implemented.3 SAP Forms 3. > END OF GUIDANCE TEXT In the following chapters are described the following (mark the line in the middle with an “x”) – the text in the 3rd column is a link to the chapter within the document SAP Enhancement SAP Conversion SAP Forms SAP Interface SAP ECC Reports SAP BW Reports SAP Workflow SAS Developments 3 SAP Enhancement 3.7 SAP Workflow 3.5SAP ECC Report 3.7. besides the chapters marked as optional.5 3.Development Functional and Technical Specification 3.2 SAP Conversion 3.6 SAP BW Report 3.Technical Description – Development Types TEXT TO BE REMOVED. In some chapters are provided examples and guidance on what content is expected.4 SAP Interface 3. Fill in all sub chapters of the relevant development type.10 SAS Developments IP_FD <IP Number> <IP Name> page 14 of 80 .

in order to avoid unnecessary typos.1.1 SAP Enhancement 3. GUIDANCE ONLY: < This section should detail the attributes of any custom table used.De s cr ip tio n KEY 1 Des c KEY 2 Des c KEY 3 Des c KEY 4 Des c KEY 5 Des c KEY 6 Des c KEY 7 Des c FIELD 1 FIELD 2 Des c Des c FIELD 3 Des c FIELD 4 FIELD 5 Des c Des c FIELD 6 FIELD 7 Des c Des c FIELD 8 Des c Ty pe/Len Ty pe/Len Ty pe/Len Ty pe/Len Ty pe/LenTy pe/Len Ty pe/Len pe/Len pe/Len Ty pe/Len Ty pe/Len Ty pe/Len Ty pe/Len pe/Len Ty pe/Len Ty Ty Ty T ab le 2 Nam e .De s cr ip tio n KEY 1 Des c KEY 2 Des c s y -f ield FIELD 1 Des c T ab le 3 Nam e . In this instance. >END OF GUIDANCE TEXT Table Name Short text Size category IP_FD <IP Number> <IP Name> page 15 of 80 .2 Custom Tables / Structure in SAP TEXT TO BE REMOVED.Development Functional and Technical Specification 3. NB: Existing SAP Data Elements and/or Domains should be used whenever possible when creating custom table fields. the data table row for that field should not be completed beyond ‘Domain’. as the remaining attributes will be default values for the selected Domain.De s cr ip tio n KEY 1 Des c KEY 2 Des c s y -f ield FIELD 1 Des c Ty pe/Len Ty pe/Len Ty pe/Len Ty pe/LenTy pe/Len Ty pe/Len Ty pe/Len Ty pe/Len Ty pe/Len Ty pe/Len pe/Len Ty pe/Len Ty 3.De s cr ip tio n KEY 1 Des c KEY 2 Des c s y -f ield FIELD 1 Des c T ab le 5 Nam e .1.De s cr ip tio n KEY 1 Des c KEY 2 Des c s y -f ield FIELD 1 Des c T ab le 4 Nam e . and the properties of its fields.1 Table Access Diagram T ab le 1 Nam e .

3 Data Validation TEXT TO BE REMOVED.4 Data Flow Diagram IP_FD <IP Number> <IP Name> page 16 of 80 . GUIDANCE ONLY < Provide the data validation rules > END OF GUIDANCE TEXT Table Field Name Validation Rule 3.1.1.Development Functional and Technical Specification Table maintenance allowed Data class Buffering Table maintenance generation Authorization Group Field Name Data Element Domain Type Length Check TableField Key Field Foreign Description Key Comments 3.

Begin each section of pseudo-code with a heading that clearly describes the logic to follow.1. Validate user input.5 Pseudo Code TEXT TO BE REMOVED GUIDANCE ONLY < • • • • • • • Pseudo-code should describe the main steps that will be performed in a program with easy to follow logic and select statements. > END OF GUIDANCE TEXT 3.e. in functional language. gather the inventories) Each main step needs to start with description of the process. unless the data declaration will impact the logic. Logic should be detailed enough so that any developer can be able to code the object without significant effort on logic redesign.6 Technical details TEXT TO BE REMOVED GUIDANCE ONLY < IP_FD <IP Number> <IP Name> page 17 of 80 . such as whether the internal table is empty.1. Format the pseudo-code into logical processing units.Development Functional and Technical Specification 3. or if SYSUBRC is equal to zero. All major checking should be specified. Data declarations should not be included in pseudo-code. (i.

4 Menu Exits Enhancement Menu/Path Function/Transaction Code 3. only those ones which are needed needs to be filled in.1.6.5 Screen Exits Screen Number Enhancement Main Program Name Program Name & Sub-Screen Number 3.Development Functional and Technical Specification All chapters are optional. Length Default Value IP_FD <IP Number> <IP Name> page 18 of 80 .6.6.1.6. For all chapters below also separate Excel sheets can be attached per chapter > END OF GUIDANCE TEXT 3.3 Field Exits Main Program Name Function Module Name Screen Field Name Enhancement Field Exit Id Screen Number Conditions for execution 3.1 SAP User-Exits Enhancement Main Program Includes Form Routines 3.1.6.1.2 Function Exits Main Program Logical trigger Point Project Enhancement Component Function Module Name Includes 3.1.6 Search Help Exits Field Name Field Description Import / Export Key Field Data Element Type (CHAR.6.1.

9 Custom Transaction TEXT TO BE REMOVED.1.6.6.10 Menu/Submenu Routine number Business logic required Requirement routine 3. GUIDANCE ONLY <For FI related transaction specifically > END OF GUIDANCE TEXT IP_FD <IP Number> <IP Name> page 19 of 80 . GUIDANCE ONLY < Provide the details of the Business transaction Event if some specific config required that can be mentioned here > END OF GUIDANCE TEXT 3. > END OF GUIDANCE TEXT 3.1.Development Functional and Technical Specification (I/E) (Y/N) NUMC) 3.11 Business Transaction event TEXT TO BE REMOVED.6.1. GUIDANCE ONLY < Functional details of custom transaction can be incorporated here: Number of screens required and flow diagram can be included and provide the selection screen screen shot along with the table name and field name and screen shot for the required output.1.7 Search Help Assignment Standard Search Help Collective Search Help Elementary Search Help 3.6.8 BADI BADI Definition Implementation name Methods Comments 3.1.12 Substitution TEXT TO BE REMOVED.6.1.6.

etc. padding requirements. (if any)       Processing Functionality IP_FD <IP Number> <IP Name> page 20 of 80 . Necessary field validations and sorting logic.6.1.13 Screen Details Screen Number:       Screen Layout: (type or attach details of screen layout)       Screen Field Mapping: Fie ld #* Field Descrip tion Fiel d Typ e SAP Refere nce Field Scr een Fiel d Len gth Inp ut/ Out put Fiel d Mand atory/ Optio nal Defau lt value s Get Value (G) Set Value (S) Or Both (B)) Match codes used (if any) Other field formatting requirement s ** * Number the fields sequentially for referencing. invisible / visible.Development Functional and Technical Specification Validation Description Fields required for validation Point of Validation Table used in validation Business Rules Substituted Field Derived from Field Table used in Substitution Business Rules 3. bright. ** Other formatting requirements – left or right justification.

Development Functional and Technical Specification Pre-screen display processing: Screen Processing Pseudo code: Screen Flow Diagram IP_FD <IP Number> <IP Name> page 21 of 80 .

summarizing (e.2 Extract Logic TEXT TO BE REMOVED.g. GUIDANCE ONLY: < The texts of the report may be different in different countries. GUIDANCE ONLY < Specify how data cleansing will be handled. > END OF GUIDANCE TEXT 3. GUIDANCE ONLY < Are all the units of measure and currency details in the data mapping tables correct? Will the report work for different currencies? What about the EURO? What happens to the report if the common measure of weight used on client’s sites is changed to tones instead of kilograms? Or to stones and pounds? > END OF GUIDANCE TEXT 3. GUIDANCE ONLY < Describe the extract logic: filtering (e. Identify the key contacts responsible for this process.Development Functional and Technical Specification 3.3 Currency and Units of Measure TEXT TO BE REMOVED.2.4 Language of Texts TEXT TO BE REMOVED.2. last two fiscal years). active vendors only.2.2 SAP Conversion 3.2.g. size of the documents) > END OF GUIDANCE TEXT 3. monthly balances.1 Data Cleaning Requirements TEXT TO BE REMOVED. What language should be used to derive these texts? The login language or another? > END OF GUIDANCE TEXT IP_FD <IP Number> <IP Name> page 22 of 80 .

6 Selection Screen Details (if applicable) TEXT TO BE REMOVED. Some SAP technical knowledge will be needed for the complete production of this table. Single/Multiple selection.2.Development Functional and Technical Specification 3. Patterns. Mandatory etc.2.) Default Value Desired screen design (selection possibilities): (use attachment if possible): 3. Not necessary if calling transaction(s) to update SAP tables IP_FD <IP Number> <IP Name> page 23 of 80 .2. > END OF GUIDANCE TEXT Name Table-Field / Check Box / Radio Button – with group Parameter (P) / Selectoption (S) Comments (Range.2. GUIDANCE ONLY < Provide any business rules that are applicable for the transformation. GUIDANCE ONLY: < When should the conversion be run? Does another conversion need to be run before this one is triggered? Should it be a batch only program (with added security) or is it needed on-line as well? Will the program automatically start a batch session or should someone be in place to trigger these? > END OF GUIDANCE TEXT 3.7 Starting Condition (Optional) TEXT TO BE REMOVED.9 Table Access Diagram TEXT TO BE REMOVED. GUIDANCE ONLY <Table Access Diagram with primary key relationships between tables. You can also add a separate spreadsheet > END OF GUIDANCE TEXT 3.2.5 File Layout (In Sequence) 3. The programmer will be able to construct the screen directly from the details in this table.8 Business Rules (Optional) TEXT TO BE REMOVED. GUIDANCE ONLY: < Detail exactly what is needed at the selection screen by using this table.

Without closing Excel. You're done! Note: If you create your TAD in an embedded excel spreadsheet and then copy and paste from the embedded object and not from an excel spreadsheet on disk. Delete these instructions and extra lines in the section. Resize the image.Development Functional and Technical Specification (Table access diagram to be attached) Insert Image Here . select TDS  Insert Graphic (do not use standard paste) 3.2. 4. 3. Copy the bitmap image to the clipboard 2. Word may insert the spreadsheet as a protected object. example. switch back to this word document and position cursor where you'd like to insert the TAD.11 Data Conversion & Interface Definition TEXT TO BE REMOVED GUIDANCE ONLY IP_FD <IP Number> <IP Name> page 24 of 80 . 4. Press Ctrl-C to copy TAD to clipboard. 5. and extra lines in this section to avoid printing an extra page. To insert graphics within the document (non-OLE objects): 1. 7. Mandatory.2.) Default Value Variants: Attach selection screen shot here 3. select TDS  Insert TAD (do not use standard paste) 5. You should create your TAD excel files on disk and not as embedded icon files.To insert TAD (or other OLE object): 1. From the menu. Patterns. Single/Multiple Selection. Delete these instructions.10 Selection Criteria Name Table Field/ Check box/ Radio button Select-option (S) or Parameter (P) S or P Comments (Range. You will not be able to edit or delete it. Resize the diagram. You're done! > END OF GUIDANCE TEXT 3. etc. 2. Open your previously created Excel TAD spreadsheet from disk and select the area covered by the TAD. 6. From the menu.

IP_FD <IP Number> <IP Name> page 25 of 80 .12 Data Mapping Matrix 3.13 BDC Method Batch Data Communication or BDC is a batch interfacing technique that SAP developed. Trap all the errors in the program 5. In this method. It is a common data transportation method and is especially useful in large data communication scenario. One is using statement ‘Call Transaction’ directly. The other method is to create a BDC session. > END OF GUIDANCE TEXT File Name Inbound / Outbound I/O File Type (ASCII. Rectify the errors if found and same process will follow. if the material exists. MM02 is called. the screen is simulated directly but difficult for error processing. for materials. Excel file.2. Mapping fields of the flat file to SAP asset master record fields 3.) Location Description Logical File Name File Delimiter Comments Source System: Target System:             System Diagram:       3.Development Functional and Technical Specification < For inbound interfaces. There are two methods to run BDC program. whereas for materials not already established in SAP. The migration consists of seven steps in BDC 1. MM01 is called). etc. EBCDIC. Call the transaction of Asset master AS91 4.2.e. Creation of flat file 2. Actual data transportation is executed when running this BDC session. indicate any relevant transaction codes and a description of the dynamic transaction call (i.

The field for Depreciation Key is AFASLXX. The steps 1) Maintain Object attributes Object . Take Over values are also present in the header structure and should be mapped with Depreciation areas.0160 Method . E.g. For e.14 LSMW The migration of data using LSMW consists of following steps SAP provides Standard LSMW to upload legacy Fixed Assets as a whole or its parts (Sub Numbers). Similarly. of source structure is as shown below: IP_FD <IP Number> <IP Name> page 26 of 80 .2.1 For BDC/Call Transaction DMM for BDC Call Transaction.0001 (Batch Input) 2) 3) Create a flat structure for input data in step 2. Most of the fields are available in header structure provided by SAP. 3. 'XX' depends on how many depreciation areas. In addition to this. Maintain fields in step 3 for the input structure. Depreciation Area and Depreciation Keys MUST be provided.13. if you want to change the Useful life in Years/Periods.2. This program copies the Asset master data and asset transaction in FI Asset Accounting systems. AFASL01 for Book Depreciation.g.Development Functional and Technical Specification 3. While running the transaction online.xls This file is not filled. But with this program. AFASL02 for Group Depreciation etc. field for Depreciation Area is AFABEXX. please include them in the source fields as well. SAP automatically fills the Depreciation areas based on the Asset Class.

IP_FD <IP Number> <IP Name> page 27 of 80 . 5) Maintain Field mapping and conversion rules: create the source fields for all target fields and give transaction as constant 'AS01'. this is the case with this LSMW program. relate only header level to input structure. this step creates a batch input session which can run using SM35.Development Functional and Technical Specification 4) Maintain structure relations: Since we have a flat structure. But. 6) 7) 8) 9) Specify Files: provide the path of the file in this step. Assign files to the target structure Read file Convert File 10) Create Batch Input session: Normally.

2.15 ALE Configuration (optional) TEXT TO BE REMOVED GUIDANCE ONLY < The following tables should be used to document all ALE/EDI configurations.15. > END OF GUIDANCE TEXT 3. then the information in the following section should be repeated in multiple tables. IDoc Type Structure TEXT TO BE REMOVED GUIDANCE ONLY IP_FD <IP Number> <IP Name> page 28 of 80 .2. If Configuration exists in more than one SAP system.Development Functional and Technical Specification 3.1 For ALE/IDOC/BAPI/Direct Input DMM For ALE/IDOC/ BAPI/Direct Input Source System System name & Client or Logical Partner Profile Target System & Client or Logical System Name Message Type Basic IDoc Type IDoc Extension Business Object / Methods Process Code / Function Module 1.

Inbound process codes Process Code Process Code description 5. Workflow event linkages to be activated Object type Event Receiver type IP_FD <IP Number> <IP Name> page 29 of 80 . Characteristics of inbound function modules Function Module Input type Dialog allowed 4. Assignment of FM to Logical message and IDoc type Function Module Obj type FctTyp Directn BasicTyp Extension Log message type MsgCode MsgFunct 3. Link type and serialisation type of message type Message type Serialisation object type Object type link 6.Development Functional and Technical Specification < This table documents the exact IDoc type structure of a customized IDoc > END OF GUIDANCE TEXT SAP IDoc Type: IDoc Extension: Parent Segment: New Child Segment: IDoc Field Field Name Data Element/Type Format/Length Comments 2.

19 Dependency TEXT TO BE REMOVED. Table-View Structure and Search Help to be attached > END OF GUIDANCE TEXT 3. GUIDANCE ONLY <Performance considerations (if any).Development Functional and Technical Specification 3.21 Pseudo Code TEXT TO BE REMOVED GUIDANCE ONLY < IP_FD <IP Number> <IP Name> page 30 of 80 .2.16 Custom Dictionary Objects (optional) TEXT TO BE REMOVED GUIDANCE ONL < Use an appropriate attachment. 2. else write N/A> END OF GUIDANCE TEXT 3.2.2.20 Relevant Function Modules TEXT TO BE REMOVED.2.17 File Layout Input / Output File Name Ref. GUIDANCE ONLY <Dependency on other programs / external applications (if any)> END OF GUIDANCE TEXT 3. Volume of data:       3. GUIDANCE ONLY <List the function modules used in the program> END OF GUIDANCE TEXT 3.2.2. Field Name Field Type Starting Position / Delimiter Length Decimal Format Mandatory (M) / Optional (O) 1.18 Performance Considerations (optional) TEXT TO BE REMOVED. 3.

• All parameters of a function call should be specified > END OF GUIDANCE TEXT IP_FD <IP Number> <IP Name> page 31 of 80 . (i. Format the pseudo-code into logical processing units. All major checking should be specified such as whether the internal table is empty. Logic should be detailed enough so that any developer can be able to code the object without significant effort on logic redesign. gather the inventories) Each main step needs to start with description of the process.e. in functional language. Data declarations should not be included in pseudo-code.Development Functional and Technical Specification • • • • • • • Pseudo-code should describe the main steps that will be performed in a program with easy to follow logic and select statements. or if SYSUBRC is equal to zero. Validate user input. Begin each section of pseudo-code with a heading that clearly describes the logic to follow. unless the data declaration will impact the logic.

1.2 Desired functionality Output type(s): Form Types: Transmission medium: Legal requirements: Type of printer: Paper Size: Orientation: Portrait/Landscape: Special stationary to be used: 3.3.3.3.2 Execution Mode Details TEXT TO BE REMOVED GUIDANCE ONLY < Specify the execution mode details whether the execution mode is transactional or stand alone mode > END OF GUIDANCE TEXT Transactional: • Output Determination: Print Program Layout Set Output Type • Navigation Path: page 32 of 80 IP_FD <IP Number> <IP Name> .1 SAP Script/Forms Customizing requirements for the form have to be added to the customizing chapter of this template.1.Development Functional and Technical Specification 3.3.1 Printing Existing Solution Menu Path for transaction: Values to be used and output type: Actions to be taken: 3. 3.3 SAP Forms 3.

GUIDANCE ONLY < Mention the technical details of the development.) Default Value Selection Screen Layout: (insert attachment if applicable): 3.3.3. Data declarations should not be included in pseudo-code. Mandatory. etc. All major checking should be specified.3. Single/Multiple Selection. Format the pseudo-code into logical processing units. > END OF GUIDANCE TEXT IP_FD <IP Number> <IP Name> page 33 of 80 . • • • • • • Logic should be detailed enough so that any developer can be able to code the object without significant effort on logic redesign. Patterns. gather the inventories) Each main step needs to start with description of the process. (i.2 Pseudo Code TEXT TO BE REMOVED GUIDANCE ONLY < Pseudo-code should describe the main steps that will be performed in a program with easy to follow logic and select statements. such as whether the internal table is empty.e. or if SYSUBRC is equal to zero. Begin each section of pseudo-code with a heading that clearly describes the logic to follow.Development Functional and Technical Specification • Batch Job Name: Stand Alone: Select-Options: Name Table Field/ Check box/ Radio button Select-option (S) or Parameter (P) S or P Comments (Range.3. Validate user input. in functional language.3. unless the data declaration will impact the logic.3 Technical Details TEXT TO BE REMOVED.1 Flow Diagrams TEXT TO BE REMOVED GUIDANCE ONLY < Logical flow of the execution of the form > END OF GUIDANCE TEXT 3. Fill the appropriate section > END OF GUIDANCE TEXT 3.

..3.8 Standards Texts / Text Modules Reference Text / Field Name Print on page Label Position Font Output Format Font Format If a logo is to be printed. GUIDANCE ONLY < Details of custom print program can be incorporated here. WN Print on page All Pages Label Position X Y 3..3.4 Print Program TEXT TO BE REMOVED. > END OF GUIDANCE TEXT 3.5 SAP script TEXT TO BE REMOVED. If it is a SAP print program add the information what the print program does > END OF GUIDANCE TEXT 3.3.3.3. > END OF GUIDANCE TEXT 3. GUIDANCE ONLY < Details of Smart form can be incorporated here..3.3.. IP_FD <IP Number> <IP Name> page 34 of 80 .7 Windows TEXT TO BE REMOVED.3.3 Form Layout TEXT TO BE REMOVED.3. GUIDANCE ONLY < Details of SAP script can be incorporated here.6 Smart form TEXT TO BE REMOVED.3.3. GUIDANCE ONLY <Details of the windows used in the layout > END OF GUIDANCE TEXT Reference W1 .Development Functional and Technical Specification 3. GUIDANCE ONLY < Attachment giving the look of the layout of the form to be developed > END OF GUIDANCE TEXT 3. specify the standard text ID in the Standard/Application Text(s) table above.3.

9 Field Mapping Field Field Description Functionality Logic Print on page Font Font Format Window 3.3.10 Translation Reference Description of use (in Language1) Description of use (in Language2) Description of use (in Language3) Text module Name Notes 3.3.3.11 Layout Details Position of Left Margin (Specify Unit) Position of Right Margin (Specify Unit) Position of Logo (Specify Unit) Logo (Specify Logo) Position of Main Window (Specify Unit) 3.13 Paragraph formats TEXT TO BE REMOVED.3.3.3.3.3. GUIDANCE ONLY < Provide styles used > END OF GUIDANCE TEXT 3.12 Styles TEXT TO BE REMOVED. GUIDANCE ONLY < Provide Paragraph formats used IP_FD <IP Number> <IP Name> page 35 of 80 .3.Development Functional and Technical Specification Logo: Yes/No Barcodes Yes / No Barcode Field Name:      Verification of Barcode Printing Capability:       3.3.

De s cr ip tio n KEY 1 Des c KEY 2 Des c s y -f ield FIELD 1 Des c T ab le 3 Nam e .De s cr ip tio n KEY 1 Des c KEY 2 Des c s y -f ield FIELD 1 Des c Ty pe/Len Ty pe/Len Ty pe/Len Ty pe/LenTy pe/Len Ty pe/Len Ty pe/Len Ty pe/Len Ty pe/Len Ty pe/Len pe/Len Ty pe/Len Ty IP_FD <IP Number> <IP Name> page 36 of 80 .14 Character formats TEXT TO BE REMOVED.3.3. GUIDANCE ONLY < Provide Character formats used > END OF GUIDANCE TEXT Character format Description Standard settings Font 3.4 Table Access Diagram T ab le 1 Nam e .De s cr ip tio n KEY 1 Des c KEY 2 Des c s y -f ield FIELD 1 Des c T ab le 5 Nam e .3.De s cr ip tio n KEY 1 Des c KEY 2 Des c s y -f ield FIELD 1 Des c T ab le 4 Nam e .De s cr ip tio n KEY 1 Des c KEY 2 Des c KEY 3 Des c KEY 4 Des c KEY 5 Des c KEY 6 Des c KEY 7 Des c FIELD 1 FIELD 2 Des c Des c FIELD 3 Des c FIELD 4 FIELD 5 Des c Des c FIELD 6 FIELD 7 Des c Des c FIELD 8 Des c Ty pe/Len Ty pe/Len Ty pe/Len Ty pe/Len Ty pe/LenTy pe/Len Ty pe/Len pe/Len pe/Len Ty pe/Len Ty pe/Len Ty pe/Len Ty pe/Len pe/Len Ty pe/Len Ty Ty Ty T ab le 2 Nam e .Development Functional and Technical Specification > END OF GUIDANCE TEXT Paragraph Format Description Indents and spacing Font Tabs Numbering and outline 3.

Development Functional and Technical Specification 3. GUIDANCE ONLY: < This section should detail the attributes of any custom table used. In this instance. >END OF GUIDANCE TEXT Table Name Short text Size category Table maintenance allowed Data class Buffering Table maintenance generation Authorization Group Field Name Data Element Domain Type Length Check TableField Key Field Foreign Description Key Comments IP_FD <IP Number> <IP Name> page 37 of 80 . the data table row for that field should not be completed beyond ‘Domain’. as the remaining attributes will be default values for the selected Domain.5 Custom Tables / Structure in SAP TEXT TO BE REMOVED.3. NB: Existing SAP Data Elements and/or Domains should be used whenever possible when creating custom table fields. and the properties of its fields. in order to avoid unnecessary typos.

> END OF GUIDANCE TEXT Interface Number Interface Name Direction (with respect to SAP R/3) <Interface Number> <Interface Name> Inbound Outbound Other Interface data flows inbound to SAP R/3 Interface data flows outbound from SAP R/3 Specify: Interface Type Batch One-way transfer of “accumulated” data set. Other Specify: Interface Frequency Hourly Daily Weekly Monthly Quarterly Yearly On-Demand Other Details: Details: Details: Details: Details: Details: How often: Specify: Type of Records Sent Full record load Send all records every time interface is executed Delta full records Only send records where one or more fields have changed since previous execution Delta records Only send fields (and keys) that changed since previous interface execution Other Specify: Volume (per single execution) Average Volume: Peak Volume: <Volume> records per interface execution <Lower Volume – Upper Volume> IP_FD <IP Number> <IP Name> page 38 of 80 . Near Real-Time One-way message-based transfer of data. Usually triggered by event. Usually triggered by event. Local spreadsheet file uploaded from PC.4 SAP Interface 3. Usually done by scheduled file transfer. GUIDANCE ONLY < Enter the requested information and type one “X” in each checkbox group.Development Functional and Technical Specification 3. Excel Upload Manually invoked from SAP session. Real-Time Immediate transfer of small data set.4.1 Interface Classification TEXT TO BE REMOVED.

3 Interface Data Requirements 3. For the steps that occur within the interface scope indicate who does what.2.2.2. > END OF GUIDANCE TEXT Source data is available as (Type “X” for all that apply): IP_FD <IP Number> <IP Name> page 39 of 80 . Do not make any assumptions about how the data will be accessed. GUIDANCE ONLY < Capture the interface process flow and/or data flow. your data may be available from both a database and a file. For example. > END OF GUIDANCE TEXT 3.1 Source Interface Data Layout TEXT TO BE REMOVED. GUIDANCE ONLY: < List the data elements that will be provided by the source system for this interface.4. > END OF GUIDANCE TEXT 3. and instead provide all methods that are available to access the data.4.4.2 Other Business Rules TEXT TO BE REMOVED. Include not only interface steps.4.3. and clearly indicate scope of the interface within the flow. and all related error conditions. how. Include diagram(s) if it will help the explanation. GUIDANCE ONLY < Describe any filtering rules that may apply for this Interface > END OF GUIDANCE TEXT 3.3 Process Flow / Data Flow TEXT TO BE REMOVED. but also the steps immediately before and/or after the interface to establish context.4.Development Functional and Technical Specification 3. You can also attach a separate spreadsheet. when.4.2 Interface Functionalities 3. GUIDANCE ONLY < Provide any business rules that are applicable for the transformation between the source and the target.1 Data Filter Rules TEXT TO BE REMOVED.

transaction. list field detail here: If you have preferences or concerns on the information in this section. and instead provide all methods that are available to accommodate the data. transaction. mention them here: 3. provide the table columns necessary for this interface: Table Column Element Description Data Type Length If indicated “File” above. provide the fields here (preserve order): Field # Field Description Data Type Length If indicated “Procedure” above. For example. “Excel”> XML file <List function. > END OF GUIDANCE TEXT Target data can be delivered as (Type “X” for all that apply): Database File Table Name(s): Type: <e.3. “VENDOR Number”> <List function.2 Target Interface Data Layout TEXT TO BE REMOVED. “Comma Delimited”. or other procedure call that can provide this data set> If indicated “Database” above. “Fixed Position”. “ABC0001”.g.g. Do not make any assumptions about how the data will be delivered.4. or other procedure call that can provide this data set> Development team will decide Procedure Name: Method: Other IP_FD <IP Number> <IP Name> page 40 of 80 . GUIDANCE ONLY: < List the data elements that are required by the target system for this interface. provide the fields of the result set here: Field Name Field Description Data Type Length If indicated “Other” above. your data may be deliverable as both a file and a transaction call.Development Functional and Technical Specification Table Name(s): Type: Database File Procedure Name: Method: Other < Provide Table Name> <e.

GUIDANCE ONLY: < Complete the list.csv. Other mapping documents can be attached in this section as supporting documentation. list field detail here: If you have preferences or concerns on the information in this section.4.3. but this MUST be populated with all of the data elements used in this interface. > END OF GUIDANCE TEXT 3. mention them here: 3. provide the fields of the result set here: Field Name Field Description Data Type Length If indicated “Other” above. Supply the sample data in the native format or . provide the table columns necessary for this interface: Table Column Element Description Data Type Length If indicated “File” above.Development Functional and Technical Specification If indicated “Database” above.3. > END OF GUIDANCE TEXT Source Element Transformation Target Element Comments 3. and preferably zipped. provide the fields here (preserve order): Field # Field Description Data Type Length If indicated “Procedure” above.4.5 Data Retention TEXT TO BE REMOVED.4 Sample Data TEXT TO BE REMOVED. GUIDANCE ONLY: IP_FD <IP Number> <IP Name> page 41 of 80 .3 Source / Target Data Mapping TEXT TO BE REMOVED. GUIDANCE ONLY: < Provide two attachments of sample source data with the expected target data after this interface is executed.4.3.

If applicable. Patterns. Parameter (P) Single/Multiple Selection. duplicate the table from section (insert source link) and capture the “return data” mapping rules for the “Source” system.Development Functional and Technical Specification < In file based interfaces a “backup” copy of interface data can be retained in the middleware for each execution. then the source or target system must fill any data retention requirements. Not necessary if calling transaction(s) to update SAP tables > END OF GUIDANCE TEXT 3.6 Special Case: Bi-Directional Real Time Interface TEXT TO BE REMOVED. GUIDANCE ONLY: < If you know this interface will be a bi-directional real-time interface (i.4. > END OF GUIDANCE TEXT None 7 days 15 days 30 days Other Data retention is not necessary for this interface (default) Specify : 3. Indicate the retention period for this interface. GUIDANCE ONLY <Table Access Diagram with primary key relationships between tables. the “Source” system sends and receives data in the same execution). etc. If not file based. This can be useful for reconciliation purposes.3. Mandatory.4 Table Access Diagram TEXT TO BE REMOVED. then a second data mapping is required.4.e.4. > END OF GUIDANCE TEXT 3.) S or P Default Value Variants: Attach selection screen shot here IP_FD <IP Number> <IP Name> page 42 of 80 .5 Selection Criteria Name Table Field/ Check box/ Radio button Select-option (S) or Comments (Range.

2 SAP Transaction If the interface uses an SAP transaction to extract or insert data.6.4.4. GUIDANCE ONLY: < Describe any requirements around the timing of this interface. > > END OF GUIDANCE TEXT 3. Custom SAP Transaction (New) Custom SAP Transaction (Existing) Standard SAP Transaction None Name: Name: Name: 3. capture the details here.6.4.6 SAP Requirements 3.1 Interface Trigger in SAP and/or Middleware TEXT TO BE REMOVED.4.4 SAP Scheduling / Performance Requirements / Service Level Agreement TEXT TO BE REMOVED.4.Development Functional and Technical Specification 3. > END OF GUIDANCE TEXT IP_FD <IP Number> <IP Name> page 43 of 80 .6.3 ALE and IDOC specific information ( if any ) Field/Parameter Source System & Client or Logical System Name Target System & Client or Logical System Name Sender Partner Number Sender Partner Type Receiver Partner Number Receiver Partner Type Message Type IDoc Type Extension Name Business Object Values 3.6. GUIDANCE ONLY: < Describe what initiates the execution of this interface.

<Project > team is responsible for providing full file of all partner types and the SAP customer with reference to legacy customer number. Business Team will be responsible for one time update.1 Solution Description TEXT TO BE REMOVED. detail functionality.4. > END OF GUIDANCE TEXT 3. <Application Name> Legacy Application Conversion Strategy IP_FD <IP Number> <IP Name> page 44 of 80 . > END OF GUIDANCE TEXT Application Name Name Abbreviation Primary Contact SAP Values All historical data will be converted to or is already compatible with SAP values Legacy ValuesApplication will not be converted and requires ongoing translation to SAP values Mixture Specify: <e.4. GUIDANCE ONLY: < This section should contain a high level outline of the mapping rules and conversion criteria. Legacy Employee Numbers”> Other Specify: Conversion of customer number from Legacy to SAP.1 Legacy System Details TEXT TO BE REMOVED.7.8 Legacy System Requirements 3.4. GUIDANCE ONLY: < Provide the following information on the Legacy System.2 Mapping Rules & Conversion Criteria TEXT TO BE REMOVED. GUIDANCE ONLY: <This section should contain an outline of the chosen middleware solution and the processes involved.g. “SAP Cost Centers.Development Functional and Technical Specification 3.4.7 Middleware Solution 3. Information like data retrieval logic.7.8.4.6.4. > END OF GUIDANCE TEXT 3. > END OF GUIDANCE TEXT 3.5 SAP Special Requirements TEXT TO BE REMOVED. GUIDANCE ONLY: < Provide any system requirements that are applicable for SAP. data retrieval logic diagram can be mentioned here.

Development Functional and Technical Specification None application <Project> <Project >: Date Fall 2007. Q4 2006. …> Other There are currently no plans to decommission this This application will be decommissioned after go-live <N> This application will be decommissioned in <e. If time-based. > END OF GUIDANCE TEXT IP_FD <IP Number> <IP Name> page 45 of 80 . Specify: Legacy Application Decommission What system will replace the legacy functionality after it is decommissioned? Application’s Relationship To Interface Source Target elsewhere Both application Other Interface data originates from this application Interface data is delivered to this application from Interface data is communicated both to and from this Specify: Server / IP Directory Test Database Password Capture Server / IP Directory Prod Database Password Capture <Provide the server /IP details> Same as above Same as above Test environment passwords have been emailed to “<mail Id>” mailbox Test environment is N/A Reason: <Provide the server /IP details> Same as above Same as above Prod environment passwords have been emailed to “<mail Id>” mailbox Prod environment is N/A Reason: 3.g. GUIDANCE ONLY: < Describe what initiates the execution of this interface. capture the day and time requirements.4. GUIDANCE ONLY: < Describe any requirements around the timing of this interface.8.8.3 Legacy Scheduling / Performance Requirements / Service Level Agreement TEXT TO BE REMOVED.4. > END OF GUIDANCE TEXT 3.2 Interface Trigger on Legacy System TEXT TO BE REMOVED.

indicate any relevant transaction codes and a description of the dynamic transaction call (i.4. > END OF GUIDANCE TEXT 3. GUIDANCE ONLY: < Describe any pre-processing the legacy system must perform on interface data before loading. if the material exists.5 Legacy Initial Processing TEXT TO BE REMOVED. Excel etc. > END OF GUIDANCE TEXT 3. whereas for materials not already established in SAP.e.4. MM02 is called.Development Functional and Technical Specification 3.4 Legacy Special Requirements TEXT TO BE REMOVED. > END OF GUIDANCE TEXT File Name Inbound / Outbound I/O File Type (ASCII. GUIDANCE ONLY: < Provide any system requirements that are applicable for the legacy system. EBCDIC.8.8.) Location Description Logical File Name File Delimiter Comments Source System: Target System: System Diagram:                   IP_FD <IP Number> <IP Name> page 46 of 80 .9 Data Conversion & Interface Definition TEXT TO BE REMOVED GUIDANCE ONLY <For inbound interfaces.4. for materials. MM01 is called).

4. file type and code page. delimiter. • STEP 2: Maintain Object Attributes Give an overview of the object type and import technique set up in order to upload the data. • STEP 7: Specify Files Give a list of the files needed.3 For LSMW TEXT TO BE REMOVED.Development Functional and Technical Specification 3. Source Structures. • STEP 4: Maintain Source Fields Give an overview of the source fields. Write the Objects Attributes.10.10 Data Mapping Matrix 3. Structure Relations here • STEP1: Initial Screen Give the project name/description. GUIDANCE ONLY < This section needs to be filled if the development is of type LSMW. • STEP 3: Maintain Source Structures Give an overview of the source structures defined within LSMW. • STEP 5: Maintain Structure Relations Source structure SAP structures • STEP 6: Maintain field mappings and conversion rules Describe the conversion rules required. subproject/description and object name/description of the LSMW object.4.10.4. • STEP 8: Assign Files Assign the respective files defined in Step 7 to the source structures IP_FD <IP Number> <IP Name> page 47 of 80 . file structure.1 For BDC/Call Transaction DMM for BDC/Call Transaction 3.10. Source Fields.4.2 For ALE/IDOC/BAPI/Direct Input DMM For ALE/IDOC/ BAPI/Direct Input 3. together with their properties for: file contents.

GUIDANCE ONLY <List the function modules used in the program > END OF GUIDANCE TEXT 3.12 Dependency TEXT TO BE REMOVED.14 Pseudo Code TEXT TO BE REMOVED GUIDANCE ONLY < IP_FD <IP Number> <IP Name> page 48 of 80 .4. 2.13 Relevant Function Modules TEXT TO BE REMOVED.4. Volume of data:       Starting Position / Delimiter Length Decimal Format Mandatory (M) / Optional (O) 3.4. > END OF GUIDANCE TEXT 3.11 File Layout Input / Output File Name Ref. GUIDANCE ONLY <Dependency on other programs / external applications (if any) > END OF GUIDANCE TEXT 3.Development Functional and Technical Specification Input files • • • Source structure STEP 9: Read Data STEP 10: Display read data STEP 11: Convert Data • STEP 12: Display converted data etc. Field Name Field Type 1.4. 3.

then the information in the following section should be repeated in multiple tables.4. Begin each section of pseudo-code with a heading that clearly describes the logic to follow. unless the data declaration will impact the logic. If Configuration exists in more than one SAP system.15 ALE Configuration (optional) TEXT TO BE REMOVED GUIDANCE ONLY < The following tables should be used to document all ALE/EDI configurations.e. All major checking should be specified such as whether the internal table is empty. or if SYSUBRC is equal to zero.Development Functional and Technical Specification • • • • • • • Pseudo-code should describe the main steps that will be performed in a program with easy to follow logic and select statements. IDoc Type Structure TEXT TO BE REMOVED GUIDANCE ONLY < This table documents the exact IDoc type structure of a Customized IDoc > END OF GUIDANCE TEXT SAP IDoc Type: IDoc Extension: Parent Segment: IP_FD <IP Number> <IP Name> page 49 of 80 . Format the pseudo-code into logical processing units. Logic should be detailed enough so that any developer can be able to code the object without significant effort on logic redesign. • All parameters of a function call should be specified > END OF GUIDANCE TEXT 3. Validate user input. gather the inventories) Each main step needs to start with description of the process. in functional language. (i. Data declarations should not be included in pseudo-code. > END OF GUIDANCE TEXT Source System System name & Client or Logical Partner Profile Target System & Client or Logical System Name Message Type Basic IDoc Type IDoc Extension Business Object / Methods Process Code / Function Module 1.

Development Functional and Technical Specification New Child Segment: IDoc Field Field Name Data Element/Type Format/Length Comments 2. Characteristics of inbound function modules Function Module Input type Dialog allowed 4. Inbound process codes Process Code Process Code description 5. Workflow event linkages to be activated Object type Event Receiver type 3.4. Link type and serialization type of message type Message type Serialisation object type Object type link 6.16 Custom Data Dictionary Objects (Optional) TEXT TO BE REMOVED GUIDANCE ONLY < Use an appropriate attachment IP_FD <IP Number> <IP Name> page 50 of 80 . Assignment of FM to Logical message and IDoc type Function Module Obj type FctTyp Directn BasicTyp Extension Log message type MsgCode MsgFunct 3.

4. Example controls: • How will the receiving system ensure they have the complete data values? • How will the receiving system ensure that source records were accurately converted or transformed? > END OF GUIDANCE TEXT Control Control Addressed IP_FD <IP Number> <IP Name> page 51 of 80 .18 Interface Controls 3. GUIDANCE ONLY <Performance considerations (if any).2 Accuracy Control TEXT TO BE REMOVED.4. GUIDANCE ONLY: < Interface functionality includes automated processes or manually captured results that will occur for each execution that verify the data uploaded to the receiving system is the same data that was transmitted by the source system. else write N/A > END OF GUIDANCE TEXT 3.4. what values are expected in the trailer record? • Are interface hash totals expected? • How will completeness be verified and validated? > END OF GUIDANCE TEXT Control Control Addressed 3.18.1 Completeness Control TEXT TO BE REMOVED.Development Functional and Technical Specification > END OF GUIDANCE TEXT 3. Example controls: • How will the receiving system ensure that they have received all the data intended for their application? • Is a trailer record expected? If yes.18. GUIDANCE ONLY: < Interface functionality includes automated processes or manually captured results that will occur for each execution that verify all the data transmitted by the source system has been uploaded to the receiving system.17 Performance Consideration (Optional) TEXT TO BE REMOVED.4.

Development Functional and Technical Specification
Control Control Addressed

3.4.18.3

Duplicate Records Control

TEXT TO BE REMOVED. GUIDANCE ONLY: < Interface functionality includes processes to handle duplicate records. If the receiving system cannot “handle” duplicate records, this interface includes a process to insure that duplicate records are not transmitted to the receiving system. If the receiving system can “handle” duplicate records, the logic exists to process duplicate records appropriately (i.e. Initiating an update, discard process etc. • Are corresponding key values available in the source system and the receiving system to insure that duplicates do not occur? • Does the receiving system have logic in place to avoid duplicate records from being processed? If no, are duplicate records possible from the sending system? If yes, does this interface require the logic to process duplicate records according to receiving system business rules? > END OF GUIDANCE TEXT Control Control Addressed

3.4.18.4

Error Detection and Communication Control

3.4.18.5

Integrity of Data Transformation Control

TEXT TO BE REMOVED. GUIDANCE ONLY: < Automated processes or manual result procedures that will execute for each interface execution will be used to verify that the data that is summarized, translated, reformatted, or converted remains accurate and complete during processing. Example controls: • What source values are transformed by Middleware? • How will the validation between the source and receiving system values occur to insure success? • Are cross reference tables used in this interface? How will this transformation be validated? > END OF GUIDANCE TEXT Control Control Addressed

IP_FD <IP Number> <IP Name>

page 52 of 80

Development Functional and Technical Specification
3.4.18.6 Standard File Format Control

TEXT TO BE REMOVED. GUIDANCE ONLY: < Automated processes or manual result procedures that will be executed for each interface execution to verify that the data being transmitted by the source system and uploaded to the receiving system is accomplished by using a defined file layout that is not intended to be changed each time the interface is run. Example controls: • What is the format of the data that is sent from the sending system to the receiving system? • How is this format insured? > END OF GUIDANCE TEXT Control Control Addressed

3.4.18.7

Interface Data Security

TEXT TO BE REMOVED. GUIDANCE ONLY: < Automated processes or manual result procedures that will be executed for each interface execution to verify that the path used to transmit data from the source system to the receiving system either cannot be accessed other than by certain electronic means (i.e. programs, transactions, etc.) or that access path is limited to a few appropriate people. Example controls: • What controls the data security? • How is the security defined? • What enforces this security? > END OF GUIDANCE TEXT Control Control Addressed

3.4.19 Compliance
3.4.19.1 Compliance Team Classification

TEXT TO BE REMOVED. GUIDANCE ONLY: < Indicate which Compliance Team member has determined the relevance of this interface. > END OF GUIDANCE TEXT
Determined by: Not yet determined
IP_FD <IP Number> <IP Name> page 53 of 80

Development Functional and Technical Specification

3.4.19.2

Relevant Regulations

TEXT TO BE REMOVED. GUIDANCE ONLY: < Indicate any regulations that govern the design and execution of this interface. > END OF GUIDANCE TEXT
SOX HIPAA Other Why?: Why?: Specify :

3.4.19.3

Other Regulatory Requirements

TEXT TO BE REMOVED. GUIDANCE ONLY: < Describe any additional regulatory requirements (e.g. non-HIPAA, non-SOX). Also include original text from requirement. This ensures that everyone will read the same version of the requirement, even if the official requirement changes over time. > END OF GUIDANCE TEXT

3.4.20 Miscellaneous Data Capture (Optional)
3.4.20.1 Interface referring Report Definition Document(s)

TEXT TO BE REMOVED. GUIDANCE ONLY: < List the report specification numbers that define the “non-interactive” reports used for monitoring, reconciliation, or logging purposes. Reports necessary to support this interface for monitoring, reconciliation, or logging will require a report specification to be populated. NOTE: The same report can satisfy the requirements for more than one interface specification. > END OF GUIDANCE TEXT
Report Specification Number Description

3.4.20.2

Other Pertinent Details

TEXT TO BE REMOVED. GUIDANCE ONLY: < If you feel that there is something that needs to be communicated or documented that you are unable to find the proper location in the above template, document it here. > END OF GUIDANCE TEXT

IP_FD <IP Number> <IP Name>

page 54 of 80

Development Functional and Technical Specification
Item Description Reported By Date

IP_FD <IP Number> <IP Name>

page 55 of 80

• Key process steps.Development Functional and Technical Specification 3.5.5. A series of bullet points summarizes the logic chosen for the program and the main technical difficulties.2 Selection Screen 3. GUIDANCE ONLY: < This section highlights the key design issues.5 SAP ECC Report 3. GUIDANCE ONLY: IP_FD <IP Number> <IP Name> page 56 of 80 . • What were the major technical problems with the design of the program.1 Extract Data Relationship Diagram TEXT TO BE REMOVED.2. • Why use a particular kind of logic for the main processing. > END OF GUIDANCE TEXT 3. • Why use multiple selects than just one. • Why a particular function module was chosen.5.1 Technical Solution TEXT TO BE REMOVED. For Example: • What assumptions are made in the technical specification and what they entail in technical terms. • Etc.

> END OF GUIDANCE TEXT For Example: IP_FD <IP Number> <IP Name> page 57 of 80 .2. showing the way the fields are ordered.) Note when structures are included in the diagram. • > END OF GUIDANCE TEXT 3. Diagram Guidelines • The diagram should show all the SAP tables that the program will extract data from. titles.2 Selection Prototype TEXT TO BE REMOVED. Database tables – using keys F1 and F9. the notes section will become much more complicated.Development Functional and Technical Specification < The purpose of the diagram is to show the database tables that contain the relevant data for the report and the relationships between them.5. Drawing the diagram removes out many of the main design issues of the program at both the business and the technical levels. one to many etc.) This is useful as it will show the developer whether they are expected to have multiple or single records for a chosen related record. etc. This will allow QA review at an early stage. frames. GUIDANCE ONLY: < A screen dump of a prototype of the selection screen should be included. • The relationships between tables should also be illustrated in the form of crows feet (one to one.

GUIDANCE ONLY: < In this section. should it be a batch only program (with added security) or is it needed on-line as well? Eg ‘This program will be run after month-end billing. GUIDANCE ONLY: < When should the report be run? Does an interface need to be run before the report is valid.5.5.3 Starting Condition TEXT TO BE REMOVED. Etc. all the error messages (ID and Classes) prompted by the validations executed at the selection screen will be detailed For Example: • • If an invalid Company Code is entered on the selection screen the message E001(ZF) ‘Company Code & is not valid’ should appear and the field is left open for input.Development Functional and Technical Specification 3.3 Details TEXT TO BE REMOVED. and (more commonly).’ Eg ‘This program will be run each time a sales order is saved > END OF GUIDANCE TEXT IP_FD <IP Number> <IP Name> page 58 of 80 . > END OF GUIDANCE TEXT 3.2.

5.Development Functional and Technical Specification 3.2 Report Example Use screen shot if possible IP_FD <IP Number> <IP Name> page 59 of 80 . > END OF GUIDANCE TEXT Field Name Field Desc Output Output Format Position SAP screen No./ field Length Type name 3.5. a desired report design can also be specified here. GUIDANCE ONLY: < List of all the fields along with their details are to be mentioned here. Look and feel wise.4.1 Desired Report Design/Layout Use screen shot if possible 3.4.5.4 Data Mapping Tables TEXT TO BE REMOVED.

They should include critical decision logic. GUIDANCE ONLY: < The diagrams.5. the database selects. complex conversions. and formatting and output. High Level Overview < P ro g ra m n a m e > S E L E C T I0 O N SC R EEN P R O C E S S IN G M A IN P R O C E S S IN G F IN A L P R O C E S S IN G 1 2 3 > END OF GUIDANCE TEXT IP_FD <IP Number> <IP Name> page 60 of 80 .Development Functional and Technical Specification 3. along with the notes associated to them should be the main structure of the program.5 Detail Logic Diagrams TEXT TO BE REMOVED. calculations.

often it is more efficient to perform selects on a database table from the data relationship diagram in the final part of the processing where the output is formatted. as it will have an impact on where the selects in the code page 61 of 80 • • • • IP_FD <IP Number> <IP Name> .5. Through program validations and calculations the number of valid customers is greatly reduced. If a ’many to one’ relationship exists between two tables because of the program flow (but does not appear in the functional specification as the database relationship is only ‘one to one’ or ‘one to many’). GUIDANCE ONLY: < • Detail logic diagrams will amalgamate the data relationship diagram and the report (or file) layout diagram from the functional specification to illustrate the flow of the program. This should be illustrated.1 Selection Screen TEXT TO BE REMOVED.Development Functional and Technical Specification 3. Only at this point would you retrieve the customer details from the database to be displayed. The data relationship should be considered in two ways in this diagram.2 Main Processing TEXT TO BE REMOVED. The programmer should investigate efficient ways of coding the program. For example.5. Each database table will roughly equate to each subroutine. They should link the input and output format to the data.5. Example: 1 S e l e c t io n S c r e e n P r o c e s s i n g P_C O M P Is s u e e r ro r m e s s a g e to s c r e e n . The file layout diagram will roughly equate to the final output internal table to be created in the code. L e a v e fi e l d o p e n fo r i n p u t R B_TES T Is c o m p a n y c o d e v a li d ? N o Is T e s t R a d i o b u t to n s e le c te d N o S e t p ro g ra m m o d e to l i v e Yes Yes A ccept com pany code S e t p ro g ra m m o d e t o te s t > END OF GUIDANCE TEXT 3.5. Eg you are to produce a customer report for all the customers that have outstanding invoices for over 30 days. The diagram should not be a simple copy and paste of the diagrams from the function specification. GUIDANCE ONLY: < The diagram should show the processing triggered by the selection screen.

Development Functional and Technical Specification appear. the functional specification may state that document headers are selected first and then the subsequent item lines are then selected afterwards. For example. • Direction arrows should be included in the diagram. Example: > END OF GUIDANCE TEXT IP_FD <IP Number> <IP Name> page 62 of 80 . However it may prove to be more efficient to select the item lines first and then get the corresponding header lines due to the information that the program has already accumulated. but it should not be a full on logic-flow diagram to avoid over complication. There should be no decision logic included in the diagram unless this impacts upon where the data is taken from or what the overall output is.

Development Functional and Technical Specification IP_FD <IP Number> <IP Name> page 63 of 80 .

Development Functional and Technical Specification IP_FD <IP Number> <IP Name> page 64 of 80 .

5. Example 1: IP_FD <IP Number> <IP Name> page 65 of 80 .3 Final Processing TEXT TO BE REMOVED. A report/outbound program should illustrate the final output of the program (example 1) while an inbound program should show the screens that are processed and the function codes that navigate between them (example 2).Development Functional and Technical Specification 2 M A IN P R O C E S S IN G Is R B _ O P E N s e le c te d ? N o Y es N o te 1 B S ID BS A D N o te 2 K N A 1 N o te 3 R e p o rt ta b le N o te 4 3.5. GUIDANCE ONLY: < The final processing section will differ depending on the type of program being designed.

Development Functional and Technical Specification 3 F IN A L P R O C E S S IN G R e p o rt to b e s e n t to th e s p o o l? I_ O U T P U T Yes S e t p rin t p a r a m e te r s H eader D e ta il L in e s S u m m a rie s C om pany C u s to m e r A c c o u n tin g C le rk A c c o u n ti n g C le rk D ocum ent N um ber C om pany A m ount D ays O v e rd u e IP_FD <IP Number> <IP Name> page 66 of 80 .

Development Functional and Technical Specification Example 2: > END OF GUIDANCE TEXT IP_FD <IP Number> <IP Name> page 67 of 80 .

Details of calculations or particular formatting should also be included here. Example: • Note 1 BUKRS (Company Code) BELNR (Document Number) KUNNR (Customer Number) DMBTR (Amount in local curreny) BLDAT (Document Date) By the following key BUKRS (Company Code) = P_COMP If no records are found issue an error message to the screen: E012(ZF) ‘No records found for company code P_COMP’ and return to the selection screen.4 Detail Logic Notes TEXT TO BE REMOVED. GUIDANCE ONLY < Mention the sorting criteria of the Report Output.5. as well as the complete SQL statements (all fields and selection criteria) and the function modules used. mention the flow of the navigation in details > END OF GUIDANCE TEXT 3. GUIDANCE ONLY < Mention the calculation logic in detail and the Page break information IP_FD <IP Number> <IP Name> page 68 of 80 .5. > END OF GUIDANCE TEXT 3.7 Sort Criteria Details TEXT TO BE REMOVED.8 Calculations and Page Break related information TEXT TO BE REMOVED.6 Interactive Report Flow TEXT TO BE REMOVED.5.5. GUIDANCE ONLY < If the report is an interactive report.Development Functional and Technical Specification 3.5. • Note 2 Etc… > END OF GUIDANCE TEXT Retrieve the following fields from BSID (Customer open documents table) 3. GUIDANCE ONLY: < The notes should complement the detail logic diagrams. Specify the field name at different level of sorting. They should include all the error messages (ID and Class).

GUIDANCE ONLY IP_FD <IP Number> <IP Name> page 69 of 80 .5. In this instance.Development Functional and Technical Specification Example: Calc 1 – Expected Production Cases This field is calculated by converting the number of Lals in the “Actual Syrup Used Lals” field to cases based on the alternative unit of measure that has been set up for the material.10 Recovery and Restart TEXT TO BE REMOVED.5. and the properties of its fields. the data table row for that field should not be completed beyond ‘Domain’. > END OF GUIDANCE TEXT 3. NB: Existing SAP Data Elements and/or Domains should be used whenever possible when creating custom table fields. as the remaining attributes will be default values for the selected Domain > END OF GUIDANCE TEXT Table Name Short text Size category Table maintenance allowed Data class Buffering Table maintenance generator Authorization Group Field Name Data Element Domain Type Length Check TableField Key Field Foreign Description Key Comments 3. in order to avoid unnecessary typos. The CF_UT_UNIT_CONVERSION function module can be used to calculate this value. GUIDANCE ONLY < This section should detail the attributes of any custom table used.9 Custom Tables / Structure in SAP TEXT TO BE REMOVED.

Development Functional and Technical Specification < If the program fails half way through will this have an impact on any programs to be run after its completion? Who will re-run the report if it does not function properly? Should anyone be alerted if certain validations fail? > END OF GUIDANCE TEXT 3. GUIDANCE ONLY: < Are all the units of measure and currency details in the data mapping tables correct? Will the report work for different currencies? What about the EURO? What happens to the report if the common measure of weight used on client’s sites is changed to tonnes instead of kilograms? Or to stones and pounds? > END OF GUIDANCE TEXT IP_FD <IP Number> <IP Name> page 70 of 80 .5. What language should be used to derive these texts? The login language or another? > END OF GUIDANCE TEXT 3.12 Currency and Units of Measure TEXT TO BE REMOVED. GUIDANCE ONLY: < The texts of the report may be different in different countries.5.11 Language of texts TEXT TO BE REMOVED.

Development Functional and Technical Specification 3.3 Report Selections and Navigation 3.6.2 Report Layout Original Layout (Original File to be attached) Data model to retrieve the above spreadsheets follows: Row Description/Formula Characteristic Characteristic Value Key figure Column Description/Formula Characteristic Characteristic value Key figure Notes (if any): 3.6.6.3.1 Report Selections (Filters) Field Name Other Selection Information IP_FD <IP Number> <IP Name> page 71 of 80 .6.6 SAP BW Report 3.1 Report Description: Who Why What When 3.

6.2 Report Navigation (Free Characteristics) Field Name Other Navigation Information IP_FD <IP Number> <IP Name> page 72 of 80 .3.Development Functional and Technical Specification 3.

Reject Path 8. 2. 9. This date will be used to send a notification to the supervisor of Approver#1 is no action was taken by Approver#1 for three business days. 10.1 SAP Workflow Diagram TEXT TO BE REMOVED. 7. Background Step: The document is reverted back to the original status. Exception Handling 13. Container Operation: The name of approver is added to a multi line container. 3.7. Background Step: Approver#1 is determined. The workflow ends. Escalation Handling IP_FD <IP Number> <IP Name> page 73 of 80 . Container Operation: The status container is set to “A”.7 SAP Workflow 3. Background Step: A mail is sent to the approver stating that the work item will be presented again for approval. There should be a one to one match between the process step & the workflow diagram. Activity (Dialog) Step: A window is presented to approver to enter the rejection comments. Background Step: A mail is sent to the workflow administrator. GUIDANCE ONLY: < Show the technical workflow diagram (One can use Visio or can even paste the diagram from the downloaded file from the workflow builder – Menu options: Workflow Print  Graphic) SAP Workflow Process Steps: Business Process Trigger: The process steps should describe the technical implementation done in the workflow template. 11. Background Step: A mail is sent to the initiator informing him/her about the rejection. 4. 5. 3A. Process Control Step: The workflow instance is terminated. for example: the date after eight business days is calculated. 12. Container Operation: Describe the operation taking place in the container. Thus if the workflow diagram had 12 boxes and each numbered from 1 to 12 – then there should be 12 process steps describing each step in the diagram. Activity (Dialog) Step: The work item is presented to the approver for necessary action (Approve/ Reject). 14. Condition Step: Describe the condition. See below for sample pseudo-code: 1.Development Functional and Technical Specification 3.Background Step: Describe the step. Workflow is started via transaction XYZ. Approve Path 6.

on creation of a purchase document. Purchase Requisition) In case of enhancement required for SAP delivery workflow is required Role Security Role Org Unit HR org structure.7. Other Specify: If the agent determination technique is different for each foreground step then repeat this section. 14B. Otherwise indicate the object in general terms (e. Background Step: Supervisor of Approver#1 is determined. else the workflow continues to the next approver. if possible. Background Step: A mail is sent to the Supervisor of Approver#1 informing that no action was taken by Approver#1. > END OF GUIDANCE TEXT 3. Loop: If the status container is not equal to “A” (Approved). work flow should start only if credit amount is greater than 250000 etc (Mention the SAP business object. Will provide detailed requirements in this doc. the work item is routed back to the approver.Development Functional and Technical Specification 14A. 15. batch program etc) Example – The workflow should start only for certain document type .g. Start Condition SAP business Object SAP Standard Workflow Task/Template Level of approval required Agent determination technique Mention logic for agent determination (if any) Notification destination Workflow notifications text Escalation handling (if any) Integration with portal Configuration dependencies (Example setting up a new organization structure) Internal SAP user SAP Inbox External E-mail Id Example Lotus notes If any specific work item text/work item subject to be used If any deadline monitoring is to be done..2 Technical description Enter the requested information and type one “X” in each checkbox group Trigger mechanism (Mention the start condition for the workflow. Example: If approver does not approve for 3 business days notify his supervisor IP_FD <IP Number> <IP Name> page 74 of 80 .g. Custom Table Agents maintained in custom table Distribution lists Unspecified To be decided in technical design. e.

Add attachment if necessary.3 Business Object Information Object Type: Description: Short Description: Program: SuperType: Application Key Fields Element Description Dictionary Field Attributes (only mention those used in the workflow template) Element Description Source Virtual Database Attribute Property Multiline Mandatory Instanceindependent Multiline Mandatory Instanceindependent Dictionary Field Pseudo logic Ref A1 Virtual Database Obj Status A2 Pseudo logic : Mention Logic for custom attributes only. no user is assigned to that position. Error handling (if any) Substitution 3.Development Functional and Technical Specification An exception situation could occur if workflow routes to a one position is vacant/not available (i. A1: A2: Method (only mention those used in the workflow template) Name Description Source Dialog Synchronous Result parameter Instance independent Result Type ABAP Function Module API Transaction Dialog Module Reports Others Pseudo logic Ref M1 IP_FD <IP Number> <IP Name> page 75 of 80 .e.) If a specific report or additional information is required.7.

4 Workflow Definition Abbreviation: Name: Triggering Events: Object Type: Event: Number: Workflow Container: Element Description Import (Y/N) Export (Y/N) Multiple Values (Y/N) Mandatory (Y/N) Dictionary Field Object Type IP_FD <IP Number> <IP Name> page 76 of 80 .7. M1 Pseudo logic: Imp Parameter List EXP Parameter List Mutiline Exception M2 Pseudo logic: Imp Parameter List EXP Parameter List Mutiline Exception Event (only mention those used in the workflow template) Name Description Parameter List Import Export 3.Development Functional and Technical Specification Key Fields Element Description Dialog Synchronous Result parameter Instance independent Dictionary Field Function Module API Transaction Dialog Module Reports Others M2 Pseudo logic: Mention Logic for custom methods only.

6 Reporting / Form Requirements Description SAP Tool Report Name Custom Requirements 3. > END OF GUIDANCE TEXT 3.8 Custom Tables / Structure in SAP Table Name Short text Size category Table maintenance allowed Data class Buffering Table maintenance generator Authorization IP_FD <IP Number> <IP Name> page 77 of 80 .7. or ) Workflow Container Element Event Container Element Responsibility Agents: Task Name Agent Deadline Notification 3.5 Deadline Monitoring Requirements Task Name Deadline Time Agent Type 3.7.7.7 Custom screen design TEXT TO BE REMOVED. GUIDANCE ONLY < Technical details of custom screen can be incorporated here.Development Functional and Technical Specification Binding Workflow Container/Event Container: (Indicate in the middle column below as to the direction of the parameters .7. Number of screens required and flow diagram can be included and provide the selection screen screen shot along with the table name and field name and screen shot for the required output.

GUIDANCE ONLY < If workflow to be triggered from user exit or if any modification required using user exit.7.7.10 Configuration Information TEXT TO BE REMOVED. Some commonly used examples are listed below > END OF GUIDANCE TEXT Server: Activity T-Code Client: Screen shot 3.8 SAS Developments Text IP_FD <IP Number> <IP Name> page 78 of 80 . GUIDANCE ONLY < List the configuration/custom objects that need to be maintained for this workflow to function. > END OF GUIDANCE TEXT 3.9 User Exit / Enhancement Detailed Description TEXT TO BE REMOVED.Development Functional and Technical Specification Group Field Data Name Element Domain Typ e Length Check TableField Key Field Foreig n Key Descriptio n Comments 3.

Security and Authorization Requirements TEXT TO BE REMOVED. > END OF GUIDANCE TEXT IP_FD <IP Number> <IP Name> page 79 of 80 . List Segregation of duty requirements. GUIDANCE ONLY: < Define the role matrix related with the objects and processes for the authorization objects.Development Functional and Technical Specification 4.

Development Functional and Technical Specification 5.Attachments IP_FD <IP Number> <IP Name> page 80 of 80 .

Sign up to vote on this title
UsefulNot useful