Cutover Activity: 1.

You could have replied like this, As cutover activity is done in the final preparation stage of the ASAP methodology,while migrating the data from the legacy system to the sap systems,Billing will be stopped for that point of time for time being.YOU could have told that , I have assisted in finding out the data relating to the Open Orders,Contracts,Pricing activities and Billing Documents,for the same time data relating to the Material master of Book stock,physical stock.etc.You should reply in such a way that he should be convinced that you really worked on that.Answer slowly no problem. Actually the cut over plan anyway will be provided by the Implementation partner. All the other activities at this point of time will be stopped,what ever you want to modify will be done before or after this activity only.I am telling this for your Idea. Basically the following will be the roles & responsibilities of an SD consultant: 1. Creating the business blue print (BBP). The business blue print contains 2 parts - ASIS = This part contains the explanation of the current organizational structure, master data & processes, the *requirements* are mentioned below in the ASIS section. TOBE = This part contains the information as to how the organizational structure, master data & processes would be mapped in SAP. The solution for the requirements mentioned will be clearly specified in the TOBE section. GAPS if any will be mentioned in the TOBE section, GAP is the bridge between the ASIS & TOBE, like if requirement can be mapped in standard SAP, then GAP will be "A" and if requirement is to be fulfilled through some development , then GAP will be "C". To discuss about the ASIS part, you have to be thorough with the sales domain & ask the key users relevant questions so as to capture all the processes & masters. You have to give them a presentation of what SAP SD is all about so that at the time of actual discussion they have some idea about the offerings in SAP. The ASIS part is discussed with the key users & the TOBE part is prepared purely by the functional consultant. The BBP has to be in detail so that everyone in the project always has an idea as to what will the system look like after configuration. The BBP is signed off by the stakeholders involved in the project & after this the configuration will start. A BBP comprises of the following structure elements in a hierarchy: Organizational Units, Master data, Business Process, Business Scenarios, Process Steps 2.Realization - As an SD consultant you have to configure the system as per the BBP, then provide the Functional specifications to the ABAP developers for development of reports & layouts. 3. Testing - UAT & integration testing with the client. You have to issue the templates for the master data & open items data. Master data - Customer master, finished goods material master, pricing master, customer material information record, customer credit limit. Open items - open sales orders, open contracts. Get the sign off on all UATS & integration testing. 4. If any fine tuning is required after testing this will be done in the Final Preparation phase. In case you come across any new requirements which was not mentioned in the BBP, then such new requirements have to be addressed through the *Change Request Form*. The change request forms requires the approval from the steering committee members. Provide the request numbers in proper sequence to the Basis consultant so that the configuration can be moved in PRD server. Upload the master data & open items data in the PRD server through LSMW or BDC. 5. Go-Live = Running an entire sales cycle = sales order - delivery - invoice (accounting document has to be generated) will be go-live. Also the invoice print out has to be generated through SAP. Note: 1. Whatever meetings & discussions are there with the key users should be properly documented. These were some of the roles & responsibilities of an SD consultant Gap Analysis Let me share with you a requirement from one of our client. While we procure asset through requisition, the client requirement is that the system should propose the asset number by default. If we procure 100 assets then system need to give the asset number accordingly without users creation. But in standard we donot have such facility. User have to manually input the asset number while raising PR or he need to create the assets at that time. So this is a gap. To overcome this we need to do analysis for achieving the above. This is called Gap analysis. Hope the example gave u a fair idea In standard SAP there will be no Availability check done at Quotation Level. But client requests that

Availability check be done at Quotation level also so that that will give him an idea roughly when the delivery could me made (remember that doesnot transfer requirements). Accordingly his customer can proceed with placing an order or not as per his requirement. Once the functional guys collect the business requirements from the clients, for whatever development requirements identified they prepare a functional specification. It contains who the business process owners are, the developers, the functional guys involved, the proj manager names, version of the specification. Then what is the task, a pseudo logic for it, then how the desired result should be like and on what parameters the results are validated. Also the client needs approve the functional document thus prepared. Apart from these basic details there are some more details in a functional specification document. Now based on the functional spec, the technical guys prepare a technical specification which contains further explanation of how that particular is gonna be executed and how the logic is going to be validated, a code walk through. After the technical specification is okayed by the functional guy, they go throught with the actual development work. After it is done the fucntional guy tests it and asks for the clinet to check if it is as per his requirement. If some more modifications or minor changes are required, then the same specification can be used with a different version number. Like if they beginned it with ' 1 ' , this time it will be 1.1 for a minor change.

Functional Spec with Example XYZ LTD (Client Name) Development Request Form Functional Specification Details Dev Req. Ref No To Be Filled By Functional Lead Product / Module Requested By Reqd. By Date Business Case Sales / Purchase Report at Work-Shop. Requirement Priority Critical Selection Parameter Sales Organization: From (Mandatory) Plant From to (Mandatory) Period: From date, To date (Mandatory) WRT Service order Output Parameters: Header: Dealer's Name Plant : Address: Sales/Purchase Report From To Date Logic for Plant Address: Go to Table T001w & get NAME2, TRAS, PSTLZ, ORT01 Item Level: Sr.No Material Code (MATNR) Material Description (ARKTX) Sale Quantity Group Wise(Acessories/Oil/M&M,Local) Sale Value Vat Amount Unit Cost Cost Value Difference Logic for the report: Based on the combination of Sale Organization (VKORG), Plant(Werks), Data to be extracted from CAUFV(Service Order)- Data to be Extracted are as follows:Give Input as Erdat From To Get AUFNR(Service order No). Pass This Value(AUFNR) into Table RKPF Important Desirable FI XXXXXXXXXXXXX CO MM SD CS CRM BW EP BPS ABC (Consulting Firm)

Requested Date 12.06.2006

Functional Specs

With input ERDAT to get all Service orders done with Movement Type 261(BWART).Pass this Value (AUFNR) into VBAK to get VBELN(Sales Order No's.).Pass this values of VBELN into Table VBAP to get MATNR,ARKTX,MATKL,ZMENG. To get Sale Amount:Go to Table VBAK give Value VBELN, get KNUMV.Pass this KNUMV as input in KONV table & get KBETR & KAWRT Logic for Vat Amount: Based on the region of delivering plant and region of the customer A911. Hard code the values for Customer Tax Classification as '1'(Go to VBAP with in put VBELN & get TAXM1) and Material Tax Classification as '1'. Then pass the values of Region of delivering plant and region of customer along with the hard coded values for Customer Tax Classification and Material tax classification in table A911. Obtain the value for KNUMH for the period or duration provided as input. Pass the A911-KNUMH into KONV-KNUMH to obtain the values of KONV-KBETR. Convert the value in KBETR to tax rate in percentage by dividing it by a divisor of '10000'. This value is the percentage of Tax. Add the percentage tax to the amount obtained for the basic amount. To obtain the price after tax.If the condition not met , . Based on the region of delivering plant and region of the customer A909. Hard code the values for Customer Tax Classification as '1' and Material Tax Classification as '1'. Then pass the values of Region of delivering plant and region of customer along with the hard coded values for Customer Tax Classification and Material tax classification in table A909. Obtain the value for KNUMH for the period or duration provided as input. Pass the A909-KNUMH into KONVKNUMH to obtain the values of KONVKBETR. Convert the value in KBETR to tax rate in percentage by dividing it by a divisor of '10000'. This value is the percentage of Tax. Add the percentage tax to the amount obtained for the basic amount. To obtain the price after tax. Then pass this value into A920-KNUMH into KONV-KNUMH KONV-KNUMH to obtain the values of KONV-KBETR. Convert the value in KBETR to tax rate in percentage by dividing it by a divisor of '10000'. This value is the percentage of Tax. Add the percentage tax to the amount obtained for the basic amount. To obtain the price after tax. The validity of records from and to date to appear in the last two columns of the report. Logic for Unit Cost:Go to Table MBEW with input MATNR & get VERPR. Logic for Cost Value:Unit Cost * Sale Quantity.

Logic for Difference:Sale Amount(NETWRKONV) - Cost Value(MBEW-VERPR * Sale Quantity Usage Frequency Authorizations Performance Considerations Test Cases & Desired Output Formats for Input / Output / Forms etc. Sales Organization (mandatory) Period (mandatory) To Be Filled By Project Manager Req. Accepted YES Date Remarks Signature Impact Analysis Details To Be Filled By Technical Team Lead Dev Req. Ref No Impact Analysis Disposition Est. End Date Assigned To Remarks Signature Technical Specifications Details Dev Req. Ref No Tech Specialist Start Date Technical Specs Accepted On Hold Rejected NO From Output Format: Excel Sheet Attached Input Parameter High

From Date

To date

End Date To Be Filled By Technical Team Lead Specs Approved Date Remarks Signature Testing Report Development Details Dev Req. Ref No Tech Developer Start Date Object Name Request No Unit Test Report End Date Remarks Signature Transportation Details Dev Req. Ref No Trans. Req. No Trans. Req. Desc To QA Server To Prod Server Signature
Are you sure you Click to toggle the

YES

NO

Dev Req. Ref No

Test script - Sample for basic procurement process

view

SCENARIO: BUSINESS CASE: DESCRIPTION: EXPECTED RESULTS: SETUP DATA

Standard Procurement involving MM processes

OWNER: STATUS: To be tested

RUN NO.: 1 Generation of RFQ, Price comparison, creation of standard PO, Intercompany PO, Sub-contracting PO RUN DATE: 16-032007

DATA OBJECT Input parameters Purchase Organization Purchase Group Customer Plant

VALUE/CODE DESCRIPTION COMMENTS AND NOTES

TRANSACTIONAL STEPS

Link No.

BUSINESS PROCESS STEPS / Login to BQA-300 Sourcing

INPUT DATA / TRANS. CODE SPECIAL INFORMATION

OUTPUT DATA / RESULT

TESTED STATUS BY

1 A 1 2 3 4 B

Generate RFQ Maintain Quotation Compare Quotation Maintain Source List Procurement - Local Procurement

ME41 ME47 ME49 ME01

Purchase Requisition assignment BUSINESS PROCESS STEPS /

ME57

Link No.

INPUT DATA / TRANS. CODE SPECIAL INFORMATION ME9F also ME22N print preview / FAX ME22N

OUTPUT DATA / RESULT

TESTED STATUS BY

Print PO

Update Order acknowledgement Display of Info record created for the above PO Procurement - Sub Contracting

ME13

Display Material Master for viewing special MM03 procurement key Display Purchase Requisition Purchase Requisition assignment Update Order acknowledgement Display of the info record created for the above PO
Click to toggle the

ME53N

ME57

ME22N

ME13

Are you sure you

Building good test cases is very important to ensure that SAP is properly tested before go-live. Test cases include test conditions, test data and also the expected results to check the design and functionality of SAP. Test cases should be comprehensive enough to take into account all business scenarios. SAP test scenarios contains a number of test cases whereas a SAP test script lists down the steps that are needed to execute a test case. Tools are available in the market to develop test scenarios. SAP tests can be designed in spreadsheets or even text editors. So what makes up a good test case. SAP best practice test cases have the following characteristics: 1. Test cases should be reusable so that a test case once designed can be used in different testing. 2. Test cases should use the SAP role profile that will be used to test the condition. This will take care of access control testing as well. 3. Test cases should include a description of what exactly is being tested and how it will be tested. It is good to have a narrative in place for tests. 4. Tests should have valid data (transaction and master data) which can be related to the business process and technical and functional requirments. 5. Test cases should be reviewed and signed off once testing is complete. SAP's Transport management system represents the centralized change and transport system CTS for all R/3 systems. SAP introduced transport management systems TMS from version 4.0 onwards. One of the main

benefits of the new transport management system is that it enables the SAP administrator to manage all SAP R/3 change requests from one single SAP client. Centralization of change request results in streamlined change management. Earlier the transport of objects was done through transaction code SE06. With the introduction of transport management system, the movement of objects is now controlled through transaction code STMS. SAP TMS allows SAP administrators to define transport routes before hand. This minimizes human intervention in handling transport requests. As a segregation of duties best practice, access to transport management system transactions should only be restricted to the Basis team. Below, I have listed some of the important SAP transactions related to transport management. Important Transport Management TCodes SCC1, SCC4 - These are Client Administration transactions which enable user to create a new client SCC1 and copy data from an existing client to a target client. SE10 - SE10 represents the transport organizer. It is used to manage and verify transport requests. SE11 - SE11 is the ABAP dictionary and is used to manage and release transport requests. STMS - The transaction for transport management system, controls the movement of objects between various SAP systems. Landscape is like a server system or like a layout of the servers or some may even call it the architecture of the servers viz. SAP is divided into three different lanscape DEV, QAS and PROD. - DEV would have multiple clients for ex: 190- Sandbox, 100- Golden, 180- Unit Test. - QAS may again have mutiple clients for ex: 300- Integration Test, 700 to 710 Training. - PROD may have something like a 200 Production. These names and numbers are the implementer's discreet on how they want it or they have been using in their previous implementations or how is the client's business scenario. Now whatever you do in the Sandbox doesn't affect the other servers or clients. Whenever you think you are satisfied with your configuration and you think you can use it moving forward, you RE-DO it in the golden client (remember, this is a very neat and clean client and you cannot use it for rough usage). As you re-do everything that you had thought was important and usable, you get a transport request pop up upon saving everytime. You save it under a transport request and give your description to it. Thus the configuration is transported to the Unit Test client (180 in this example). You don't run any transaction or even use the SAP Easy Access screen on the 100 (golden) client. This is a configuration only client. Now upon a successful tranport by the Basis guy, you have all the configuration in the Testing client, just as it is in the Golden client. The configuration remains in sync between these two clients. But in the Testing client you can not even access SPRO (Display IMG) screen. It's a transaction only client where you perform the unit test. Upon a satisfactory unit test, you move the good configuration to the next SERVER (DEV). The incorrect or unsatisfactory configuration is corrected in Golden (may again as well be practised in the sandbox prior to Golden) and accordingly transported back to 180 (Unit Test) until the unit test affected by that particular config is satisfactory. The Golden client remains the 'database' (if you wanna call it that) or you may rather call it the 'ultimate' reference client for all the good, complete and final configuration that is being used in the implementation. In summary: Landscape : is the arrangement for the servers IDES : is purely for education purpose and is NOT INCLUDED in the landscape.

DEVELOPMENT ---> QUALITY ----> PRODUCTION DEVELOPMENT : is where the the consultants do the customization as per the company's requirement. QUALITY : is where the core team members and other members test the customization. PRODUCTION : is where the live data of the company is recorded. A request will flow from Dev->Qual->Prod and not backwards. 1. Sandbox server: In the initial stages of any implementation project, You are given a sandbox server where you do all the configuration/customization as per the companies business process. 2. Development Server: - Once the BBP gets signed off, the configuration is done is development server and saved in workbench requests, to be transported to Production server. 3. Production Server: This is the last/ most refined client where the user will work after project GO LIVE. Any changes/ new develpoment is done is development client and the request is transported to production. These three are landscape of any Company. They organised their office in these three way. Developer develop their program in Development server and then transport it to test server. In testing server tester check/test the program and then transport it to Production Server. Later it will deploy to client from production server. Presentaion Server- Where SAP GUI have. Application Server - Where SAP Installed. Database Server - Where Database installed. What is the meaning of "R" in R/3 systems? R/3 stands for realtime three tier architecture. This is the kind of architrecture SAP R/3 system has. R/3 means three layers are installed in Different system/server and they are connected with each other. 1) Presentation 2) Application 3) Database Why do we call client 000 as golden client? Golden client contains all the configuration data and master data so some extent. All the configuration settings are done in golden clients and then moved to other clients. Hence this client acts as a master record for all transaction settings, hence the name "Golden Client".

Unit Test Script

Test Case ID 1 Test Case Test to excute the test cases Expected Results Actual Results

Display of report header

Verify that report name is present at centre of report header. Verify that displayed in the top left corner of the report.

Report should be opened in infoview.

As perr the Funtional design section- page no.7 As per the Funtional design section-page no.7 As per the Funtional design section 2-page no.7 As per the Funtional design section 1-page no.7 As per the Funtional design section 1-page no.7 As per the Funtional design Report Parameter sectionpage no.3 As per the Funtional design section As per the Funtional design Major Report Features section-page no.4 As per the Funtional design Major Report Features section

Display of logo

Logo should be seen in the top left corner of the report. "Page N of M" should be displayed at right corner of the report footer Confidential should be displayed at middle of the report footer The Report output should be as per the design document The Report output should be as per the design document

Display Of "Page N of M"

Display of text " Confidential"

Verify that "Page N of M" is displayed at left corner of the report footer Verify that Confidential is displayed at the middle of the report footer Verify that Report Creater display on report

Report Creator/Owner Parameter

Verify that report parameter display in report

Report SQL

Verify that report sql is as per the sql given in DDD.Refer the SQL given in the attached object. Verify that Report is sorted in asc or desc order

The Report output should be as per the SQL query output

Sorting

The Report output should be as per the design document

Output of the report should be as per the mockup given in detail design document

Report Output

Verify that Report output is as per the mockup in detail design document.