Asset Data Migration
Asset Data Migration
Document reference Document type (e.g. GAP IP Functional X) Owner (company) Last edited by Last edited on
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
page 5 of 80
1 General Information
This document has been created within the framework of the GRP@AGA project. According to the Global Reporting Program (GRP) running since 2002, several GRP rollout projects have been performed by different operational units (OE) in the past in order to enhance the reporting speed, quality and efficiency. Currently the to-be solution is represented by the GRP kernel solution in order to meet those targets. 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.A. (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). Realisation of the project will be conducted in several steps. The GoLive of the pilot project rollout on Mondial Assistance France (MAF) is planned for the 2012-01-01. It will be followed by rollins on the different OEs, which will have to adhere in general to already accepted GRP solution for MAF based on the GRP kernel solution. 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.g. SERVANTISSIMO Document Change History) to SAP CAP.
1.1
Chapters changed
All 1 and 2
08.07.2011 18.07.2011
1.2
This document describes from a business perspective the purpose of the required migration. It should also provide the developer with a logical overview of what data has to be migrated using BDC/LSMW. Moreover, the document is used to provide him with all relevant details on functional requirements (function and features), information on GAPs, and the technical description for a development in SAP or SAS needed. The migration focus is on asset master data. There are two different ways of migrating data from feeder systems. This document will discuss loading fixed assets using two methods.
IP_FD <IP Number> <IP Name> page 6 of 80
1.3
A fixed asset is an object, a right, or another item owned by an enterprise that is intended for longterm use and can be individually identified in the balance sheet. Maintaining fixed assets involves creating, changing, and displaying asset master records. Please refer to IP 320336_IP_FC_WS1_Customizing_ FIAA_Fully_New for further information on the customizing of FI-AA for AGA. 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, maintain, and evaluate master data. Each asset master record consists of two parts that are described below. 1. General Master Data / Organizational Assignments This part of the master record contains general information about the fixed asset. 2. Valuation Parameters In the valuation section of an asset master record is defined, how a fixed asset is valuated for each depreciation area. Example: In the valuation section for a machine, it was specified to be written off in depreciation area 20 (cost-accounting depreciation) within a period of three years. The machine is to be written off using straight-line depreciation.
page 7 of 80
1. Asset Master data of Allianz Global Assistance has to be provided. 2. Identifying the tool (whether LSMW or BDS) to migrate the legacy data
page 8 of 80
2 Functional Description
2) 3) 4) 5)
6)
7) 8)
page 9 of 80
10) Take Over values: These are filled depending on the Customization and Depreciation areas.
2.2.4 Specify Last Period Posted in Previous System (Transf. During FY)
This step is only necessary if you want to perform an old assets data takeover during the fiscal year. In this case, you must specify the period up to which depreciation was posted in the previous system. This period refers to the posted depreciation that is to be transferred during old assets data takeover. Allianz Global Assistance is going live on 1st January, 2012. In this case we specify that depreciation was posted up to 31st December 2011 in the previous (legacy) system.
page 11 of 80
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. What are the consequences of using one or the other way?
page 12 of 80
Text
FF_AA.xlsx
page 13 of 80
page 14 of 80
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
page 15 of 80
Comments
page 16 of 80
All major checking should be specified, such as whether the internal table is empty, or if SYSUBRC is equal to zero. > END OF GUIDANCE TEXT
page 17 of 80
Project
Enhancement
Component
Includes
3.1.6.3 Field Exits Main Program Name Function Module Name Screen Field Name
Enhancement
Field Exit Id
Screen Number
Enhancement
3.1.6.6 Search Help Exits Field Name Field Description Import / Export Key Field Data Element Type (CHAR, Length Default Value
page 18 of 80
(I/E)
(Y/N)
NUMC)
3.1.6.7 Search Help Assignment Standard Search Help Collective Search Help Elementary Search Help
TEXT TO BE REMOVED. 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. > END OF GUIDANCE TEXT
3.1.6.10 Menu/Submenu Routine number Business logic required Requirement routine
3.1.6.11
TEXT TO BE REMOVED. 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.1.6.12 Substitution
TEXT TO BE REMOVED. GUIDANCE ONLY <For FI related transaction specifically > END OF GUIDANCE TEXT
IP_FD <IP Number> <IP Name> page 19 of 80
Validation Description
Point of Validation
Business Rules
Substituted Field
Business Rules
3.1.6.13
Screen Details
Processing Functionality
page 20 of 80
page 21 of 80
page 22 of 80
(Table access diagram to be attached) Insert Image Here - To insert TAD (or other OLE object): 1. Open your previously created Excel TAD spreadsheet from disk and select the area covered by the TAD. 2. Press Ctrl-C to copy TAD to clipboard. 3. Without closing Excel, switch back to this word document and position cursor where you'd like to insert the TAD. 4. From the menu, select TDS Insert TAD (do not use standard paste) 5. Resize the diagram. 6. Delete these instructions, example, and extra lines in this section to avoid printing an extra page. 7. 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, Word may insert the spreadsheet as a protected object. You will not be able to edit or delete it. You should create your TAD excel files on disk and not as embedded icon files. To insert graphics within the document (non-OLE objects): 1. Copy the bitmap image to the clipboard 2. From the menu, select TDS Insert Graphic (do not use standard paste) 3. Resize the image. 4. Delete these instructions and extra lines in the section. 5. You're done! > END OF GUIDANCE TEXT
page 24 of 80
File Name
Location
Description
File Delimiter
Comments
System Diagram:
page 25 of 80
3.2.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). This program copies the Asset master data and asset transaction in FI Asset Accounting systems. The steps
1)
2) 3)
Create a flat structure for input data in step 2. Maintain fields in step 3 for the input structure.
Most of the fields are available in header structure provided by SAP. While running the transaction online, SAP automatically fills the Depreciation areas based on the Asset Class. But with this program, Depreciation Area and Depreciation Keys MUST be provided. In addition to this, if you want to change the Useful life in Years/Periods, please include them in the source fields as well. The field for Depreciation Key is AFASLXX. 'XX' depends on how many depreciation areas. For e.g. AFASL01 for Book Depreciation, AFASL02 for Group Depreciation etc. Similarly, field for Depreciation Area is AFABEXX. Take Over values are also present in the header structure and should be mapped with Depreciation areas. E.g. of source structure is as shown below:
page 26 of 80
4) Maintain structure relations: Since we have a flat structure, relate only header level to input structure. 5) Maintain Field mapping and conversion rules: create the source fields for all target fields and give transaction as constant 'AS01'. 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, this step creates a batch input session which can run using SM35. But, this is the case with this LSMW program.
page 27 of 80
3.2.15.1
&
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. IDoc Type Structure TEXT TO BE REMOVED GUIDANCE ONLY
IP_FD <IP Number> <IP Name> page 28 of 80
2. Assignment of FM to Logical message and IDoc type Function Module Obj type FctTyp Directn BasicTyp Extension Log message type MsgCode MsgFunct
3. Characteristics of inbound function modules Function Module Input type Dialog allowed
5. Link type and serialisation type of message type Message type Serialisation object type Object type link
page 29 of 80
Field Type
Length
Decimal
Format
1. 2. 3. Volume of data:
3.2.19 Dependency
TEXT TO BE REMOVED. GUIDANCE ONLY <Dependency on other programs / external applications (if any)> END OF GUIDANCE TEXT
page 30 of 80
All parameters of a function call should be specified > END OF GUIDANCE TEXT
page 31 of 80
Menu Path for transaction: Values to be used and output type: Actions to be taken:
Output type(s): Form Types: Transmission medium: Legal requirements: Type of printer: Paper Size: Orientation: Portrait/Landscape: Special stationary to be used:
Output Type
Navigation Path:
page 32 of 80
Name
Default Value
TEXT TO BE REMOVED GUIDANCE ONLY < Logical flow of the execution of the form > END OF GUIDANCE TEXT
3.3.3.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. Logic should be detailed enough so that any developer can be able to code the object without significant effort on logic redesign. Data declarations should not be included in pseudo-code, unless the data declaration will impact the logic. Format the pseudo-code into logical processing units. Begin each section of pseudo-code with a heading that clearly describes the logic to follow. (i.e. Validate user input, gather the inventories) Each main step needs to start with description of the process, in functional language.
All major checking should be specified, such as whether the internal table is empty, or if SYSUBRC is equal to zero. > END OF GUIDANCE TEXT
page 33 of 80
TEXT TO BE REMOVED. GUIDANCE ONLY < Attachment giving the look of the layout of the form to be developed > END OF GUIDANCE TEXT
3.3.3.4 Print Program
TEXT TO BE REMOVED. GUIDANCE ONLY < Details of custom print program can be incorporated here. If it is a SAP print program add the information what the print program does > END OF GUIDANCE TEXT
3.3.3.5 SAP script
TEXT TO BE REMOVED. GUIDANCE ONLY < Details of SAP script can be incorporated here. > END OF GUIDANCE TEXT
3.3.3.6 Smart form
TEXT TO BE REMOVED. GUIDANCE ONLY < Details of Smart form can be incorporated here. > END OF GUIDANCE TEXT
3.3.3.7 Windows
TEXT TO BE REMOVED. GUIDANCE ONLY <Details of the windows used in the layout > END OF GUIDANCE TEXT Reference W1 ...... WN Print on page All Pages Label Position X Y
Reference
Print on page
Label Position
Font
Output Format
Font Format
If a logo is to be printed, specify the standard text ID in the Standard/Application Text(s) table above.
IP_FD <IP Number> <IP Name> page 34 of 80
Logo: Yes/No Barcodes Yes / No Barcode Field Name: Verification of Barcode Printing Capability:
3.3.3.9 Field Mapping
Field
Field Description
Functionality
Logic
Print on page
Font
Font Format
Window
3.3.3.10
Translation
Reference
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.3.3.12
Styles
TEXT TO BE REMOVED. GUIDANCE ONLY < Provide styles used > END OF GUIDANCE TEXT
3.3.3.13 Paragraph formats
3.3.3.14
Character formats
TEXT TO BE REMOVED. GUIDANCE ONLY < Provide Character formats used > END OF GUIDANCE TEXT Character format Description Standard settings Font
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
page 36 of 80
Comments
page 37 of 80
Interface Type
Batch One-way transfer of accumulated data set; Usually done by scheduled file transfer. Near Real-Time One-way message-based transfer of data; Usually triggered by event. Real-Time Immediate transfer of small data set; Usually triggered by event. Excel Upload Manually invoked from SAP session; Local spreadsheet file uploaded from PC. Other Specify:
Interface Frequency
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)
page 38 of 80
TEXT TO BE REMOVED. GUIDANCE ONLY < Describe any filtering rules that may apply for this Interface > END OF GUIDANCE TEXT
TEXT TO BE REMOVED. GUIDANCE ONLY < Provide any business rules that are applicable for the transformation between the source and the target. You can also attach a separate spreadsheet. > END OF GUIDANCE TEXT
TEXT TO BE REMOVED. GUIDANCE ONLY < Capture the interface process flow and/or data flow. Include not only interface steps, but also the steps immediately before and/or after the interface to establish context. Include diagram(s) if it will help the explanation, and clearly indicate scope of the interface within the flow. For the steps that occur within the interface scope indicate who does what, when, how, and all related error conditions. > END OF GUIDANCE TEXT
TEXT TO BE REMOVED. GUIDANCE ONLY: < List the data elements that will be provided by the source system for this interface. Do not make any assumptions about how the data will be accessed, and instead provide all methods that are available to access the data. For example, your data may be available from both a database and a file. > END OF GUIDANCE TEXT Source data is available as (Type X for all that apply):
page 39 of 80
Database File
< Provide Table Name> <e.g. Comma Delimited, Fixed Position, Excel> XML file <List function, transaction, or other procedure call that can provide this data set>
If indicated Database above, 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, provide the fields of the result set here: Field Name Field Description Data Type Length
If you have preferences or concerns on the information in this section, mention them here:
TEXT TO BE REMOVED. GUIDANCE ONLY: < List the data elements that are required by the target system for this interface. Do not make any assumptions about how the data will be delivered, and instead provide all methods that are available to accommodate the data. For example, your data may be deliverable as both a file and a transaction call. > END OF GUIDANCE TEXT Target data can be delivered as (Type X for all that apply):
Database File Table Name(s): Type: <e.g. ABC0001, VENDOR Number> <List function, transaction, or other procedure call that can provide this data set> Development team will decide
page 40 of 80
If indicated File above, provide the fields here (preserve order): Field # Field Description Data Type Length
If indicated Procedure above, provide the fields of the result set here: Field Name Field Description Data Type Length
If you have preferences or concerns on the information in this section, mention them here:
TEXT TO BE REMOVED. GUIDANCE ONLY: < Complete the list. Other mapping documents can be attached in this section as supporting documentation, but this MUST be populated with all of the data elements used in this interface. > END OF GUIDANCE TEXT Source Element Transformation Target Element Comments
TEXT TO BE REMOVED. GUIDANCE ONLY: < Provide two attachments of sample source data with the expected target data after this interface is executed. Supply the sample data in the native format or .csv, and preferably zipped. > END OF GUIDANCE TEXT
3.4.3.6
TEXT TO BE REMOVED. GUIDANCE ONLY: < If you know this interface will be a bi-directional real-time interface (i.e. the Source system sends and receives data in the same execution), then a second data mapping is required. If applicable, duplicate the table from section (insert source link) and capture the return data mapping rules for the Source system. > END OF GUIDANCE TEXT
page 42 of 80
TEXT TO BE REMOVED. GUIDANCE ONLY: < Describe what initiates the execution of this interface. > > END OF GUIDANCE TEXT
3.4.6.2 SAP Transaction
If the interface uses an SAP transaction to extract or insert data, capture the details here.
Custom SAP Transaction (New) Custom SAP Transaction (Existing) Standard SAP Transaction None Name: Name: Name:
3.4.6.3
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.4.6.4
TEXT TO BE REMOVED. GUIDANCE ONLY: < Describe any requirements around the timing of this interface. > END OF GUIDANCE TEXT
page 43 of 80
TEXT TO BE REMOVED. GUIDANCE ONLY: < Provide any system requirements that are applicable for SAP. Information like data retrieval logic, detail functionality, data retrieval logic diagram can be mentioned here. > END OF GUIDANCE TEXT
TEXT TO BE REMOVED. GUIDANCE ONLY: <This section should contain an outline of the chosen middleware solution and the processes involved. > END OF GUIDANCE TEXT
3.4.7.2 Mapping Rules & Conversion Criteria
TEXT TO BE REMOVED. GUIDANCE ONLY: < This section should contain a high level outline of the mapping rules and conversion criteria. > END OF GUIDANCE TEXT
TEXT TO BE REMOVED. GUIDANCE ONLY: < Provide the following information on the Legacy System. > 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.g. SAP Cost Centers, Legacy Employee Numbers> Other Specify: Conversion of customer number from Legacy to SAP. Business Team will be responsible for one time update. <Project > team is responsible for providing full file of all partner types and the SAP customer with reference to legacy customer number.
<Application Name>
page 44 of 80
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
3.4.8.2
TEXT TO BE REMOVED. GUIDANCE ONLY: < Describe what initiates the execution of this interface. If time-based, capture the day and time requirements. > END OF GUIDANCE TEXT
3.4.8.3 Legacy Scheduling / Performance Requirements / Service Level Agreement
page 45 of 80
TEXT TO BE REMOVED. GUIDANCE ONLY: < Provide any system requirements that are applicable for the legacy system. > END OF GUIDANCE TEXT
3.4.8.5 Legacy Initial Processing
File Name
Location
Description
File Delimiter
Comments
page 46 of 80
TEXT TO BE REMOVED. GUIDANCE ONLY < This section needs to be filled if the development is of type LSMW. Write the Objects Attributes, Source Structures, Source Fields, Structure Relations here STEP1: Initial Screen Give the project name/description, subproject/description and object name/description of the LSMW object. STEP 2: Maintain Object Attributes Give an overview of the object type and import technique set up in order to upload the data. STEP 3: Maintain Source Structures Give an overview of the source structures defined within LSMW. STEP 4: Maintain Source Fields Give an overview of the source fields. STEP 5: Maintain Structure Relations Source structure
SAP structures
STEP 6: Maintain field mappings and conversion rules Describe the conversion rules required. STEP 7: Specify Files Give a list of the files needed, together with their properties for: file contents, delimiter, file structure, file type and code page. 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
Input files
Source structure
STEP 9: Read Data STEP 10: Display read data STEP 11: Convert Data
STEP 12: Display converted data etc. > END OF GUIDANCE TEXT
Length
Decimal
Format
3.4.12 Dependency
TEXT TO BE REMOVED. GUIDANCE ONLY <Dependency on other programs / external applications (if any) > END OF GUIDANCE TEXT
All parameters of a function call should be specified > END OF GUIDANCE TEXT
Partner Profile Target System & Client or Logical System Name Message Type Basic IDoc Type IDoc Extension Business Object / Methods Process Code / Function Module 1. 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
2. Assignment of FM to Logical message and IDoc type Function Module Obj type FctTyp Directn BasicTyp Extension Log message type MsgCode MsgFunct
3. Characteristics of inbound function modules Function Module Input type Dialog allowed
5. Link type and serialization type of message type Message type Serialisation object type Object type link
TEXT TO BE REMOVED. 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. 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, 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.4.18.2
Accuracy Control
TEXT TO BE REMOVED. 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. 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
page 51 of 80
3.4.18.3
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
3.4.18.5
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
page 52 of 80
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
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
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
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
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
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
page 54 of 80
page 55 of 80
page 56 of 80
< The purpose of the diagram is to show the database tables that contain the relevant data for the report and the relationships between them. Drawing the diagram removes out many of the main design issues of the program at both the business and the technical levels. Diagram Guidelines The diagram should show all the SAP tables that the program will extract data from. The relationships between tables should also be illustrated in the form of crows feet (one to one, 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. Database tables using keys F1 and F9.) Note when structures are included in the diagram, the notes section will become much more complicated.
TEXT TO BE REMOVED. GUIDANCE ONLY: < A screen dump of a prototype of the selection screen should be included, showing the way the fields are ordered, frames, titles, etc. This will allow QA review at an early stage. > END OF GUIDANCE TEXT For Example:
page 57 of 80
3.5.2.3 Details
TEXT TO BE REMOVED. GUIDANCE ONLY: < In this section, 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. Etc.
3.5.4.1
3.5.4.2
Report Example
page 59 of 80
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
page 60 of 80
TEXT TO BE REMOVED. GUIDANCE ONLY: < The diagram should show the processing triggered by the selection screen. Example:
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 . 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
S e t p ro g ra m m o d e t o te s t
TEXT TO BE REMOVED. 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. They should link the input and output format to the data. Each database table will roughly equate to each subroutine. The file layout diagram will roughly equate to the final output internal table to be created in the code. The diagram should not be a simple copy and paste of the diagrams from the function specification. The programmer should investigate efficient ways of coding the program. For example, 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. Eg you are to produce a customer report for all the customers that have outstanding invoices for over 30 days. Through program validations and calculations the number of valid customers is greatly reduced. 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. 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). This should be illustrated, as it will have an impact on where the selects in the code
page 61 of 80
Example:
page 62 of 80
page 63 of 80
page 64 of 80
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
TEXT TO BE REMOVED. GUIDANCE ONLY: < The final processing section will differ depending on the type of program being designed. 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). Example 1:
page 65 of 80
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
C om pany
A m ount
D ays O v e rd u e
page 66 of 80
TEXT TO BE REMOVED. GUIDANCE ONLY: < The notes should complement the detail logic diagrams. They should include all the error messages (ID and Class), as well as the complete SQL statements (all fields and selection criteria) and the function modules used. 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. Note 2 Etc > END OF GUIDANCE TEXT Retrieve the following fields from BSID (Customer open documents table)
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. The CF_UT_UNIT_CONVERSION function module can be used to calculate this value. > END OF GUIDANCE TEXT
Comments
page 69 of 80
page 70 of 80
Column
Description/Formula
Characteristic
Characteristic value
Key figure
Field Name
page 71 of 80
Field Name
page 72 of 80
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. Example: If approver does not approve for 3 business days notify his supervisor
page 74 of 80
Substitution
Key Fields
Element Description Dictionary Field
A1
A2
A1: A2:
M1
page 75 of 80
Dictionary Field
Function Module API Transaction Dialog Module Reports Others
M2
Pseudo logic: Mention Logic for custom methods only. M1 Pseudo logic: Imp Parameter List EXP Parameter List Mutiline
Exception M2 Pseudo logic: Imp Parameter List EXP Parameter List Mutiline
Exception
Workflow Container: Element Description Import (Y/N) Export (Y/N) Multiple Values (Y/N) Mandatory (Y/N) Dictionary Field Object Type
page 76 of 80
Binding Workflow Container/Event Container: (Indicate in the middle column below as to the direction of the parameters - or ) Workflow Container Element Event Container Element
Domain
Typ e
Length
Check TableField
Key Field
Foreig n Key
Descriptio n
Comments
Server:
Activity T-Code
Client:
Screen shot
page 78 of 80
page 79 of 80
5.Attachments
page 80 of 80