Hi Kannan
A change request is a document containing a call for an adjustment of a system; it is of great importance in the change management process.
A change request is declarative, i.e. it states what needs to be accomplished, but leaves out how the change should be carried out. Important elements of a change request are an ID, the customer (ID), the deadline (if applicable), an indication whether the change is required or optional, the change type (often chosen from a domain-specific ontology) and a change abstract, which is a piece of narrative (Keller, 2005). An example of a change request can be found in Figure 1 on the right.
Change requests typically originate from one of five sources: problem reports that identify bugs that must be fixed, which forms the most common source, (ii) system enhancement requests from users, (iii) events in the development of other systems, (iv) changes in underlying structure and or standards (e.g. in software development this could be a new operating system) and (v) demands from senior management (Dennis, Wixom & Tegarden, 2002).
Change requests have many different names, which essentially describe the same concept:
Engineering Change (EC) by Huang and Mak (1999);
Engineering Change Request (ECR) at Aero (Helms, 2002);
Engineering Change Order (ECO) by Loch and Terwiesch (1999) and Pikosz and Malmqvist (1998). Engineering Change Order is a separate step after ECR. After ECR is approved by Engineering Department then an ECO is made for making the change;
Change Notice at Chemical (Helms, 2002);
Action Request (AR) at ABB Robotics AB (Kajko-Mattson, 1999);
Request For Change (RFC) by Rajlich (1999); RFC is also a common term in ITIL (Keller, 2005) and PRINCE2 (Onna & Koning, 2003);
Change Request (CR) is, among others, used by Lam (1998), Mäkäräinen (2000), Dennis, et al. (2002), Crnkovic, Asklund and Persson-Dahlqvist (2003) and at ABB Automation Products AB (Kajko-Mattsson, 1999).
TASK
Tasks
For regular monitoring of your system landscape, use the SAP CCMS Technical Operations Templates monitor set. This monitor set consists of the following monitors. You can use each of them to monitor one aspect of your landscape:
· Availability
· Availability of Monitoring Architecture
· ABAP Critical Messages
· ABAP Key Performance Indicators
· Java Critical Messages
· Java Key Performance Indicators
· Space Management
Check these monitors regularly for alerts. To call these monitors, proceed as follows:
1. Start the alert monitor by entering the transaction code RZ20.
You can display the monitors listed from the SAP NetWeaver Administrator. Although the operation and display is different from that of the Alert Monitor, the displayed monitoring data and monitors are identical.
2. On the CCMS Monitor Sets screen, expand the SAP CCMS Technical Operations Templates set.
3. Start the various monitors from the list, and check them for alerts. To do this, switch to the Open Alerts view to ensure that all alerts are displayed.
You should also monitor the Space Management monitor and the Syslog Messages and Database subtrees of the ABAP Critical Messages monitor regularly, irrespective of whether there are alerts.
4. In most cases, each node is assigned an analysis method, that is, you start an appropriate transaction to investigate the alerts by double-clicking the corresponding node.
For more information about how to proceed if alerts occur, see the descriptions of the individual monitors and tasks:
Monitor
Task
Availability
Monitoring Availability
Availability of Monitoring Architecture
Monitoring the Monitoring Architecture
ABAP Critical Messages
Monitoring ABAP Error Messages
ABAP Key Performance Indicators
Monitoring the ABAP Performance
Java Critical Messages
Monitoring Java Error Messages
Java Key Performance Indicators
Monitoring the Java Performance
Space Management
Monitoring Space Managementsapurl_link_0004_0009_0001
5. If you have corrected the cause of the alert, select the alert and choose the Complete Alerts button.
Transport Request
The transport request process ensures software development is successfully applied to the appropriate SAP environments. This process involves the release of SAP transports containing the software changes and the submission of the transport request using MIT's custom request program, ZUTTREQ. An ABAP code review is needed if this is new custom development. A completed ZUTTREQ with the necessary approval from the Business Process Owner is required for all modifications or changes transported between SAP environments. See MIT SAP Transport Request Process.
All changes you make to a calculation rule must be transported from your Customizing client into the other clients for your SAP System. If your Customizing client has been set up accordingly, the system can automatically include all changes in a transport request. If this is not the case, you must include each rule that you have changed in a transport request to ensure they are transported.
The behaviour of Ek02 is to get the planned cost and then you can mark up the price using PR00 or other condition types. Ek02 is the cost condition catagory
Condition Types for Pricing
Condition Type
Meaning
EK01
Cost of goods manufactured (CGM)
EK02
CGM (statistical)
EK03
Fixed CGM (statistical)
Condition type EK01 is mainly used for cost-plus contracts in which the sales price depends on the expected costs.
Condition type EK02 is mainly used when the sales price is a market price and the expected costs are only used for informational purposes.
Condition type EK03 offers the capability of transferring the fixed costs of a cost estimate into the conditions.
The costs are transferred from the cost component view Cost of goods sold into the condition type.
The above-mentioned condition types must be of category Q. Whether a condition type of category Q is only used in pricing as a statistical value or for price calculation is controlled in the pricing procedure.
The condition type is created in Customizing for Sales.
The condition type can be selected as follows:
Through the sales document type
Condition types EK01 and EK02 are specified in the CndTypLineItems field in the sales document type.
Through the requirements class
This enables you to define different condition types for different sales document items of a sales document.
Condition types EK01 or EK02 are specified in the CndTypLineItems field in the requirements class.
Condition type EK03 is specified in the CondTypLinItFix field. You can only use condition type EK03 in conjunction with the requirements class.
Planned Revenues
Revenue elements from the SD pricing procedure that are not statistical are updated as planned revenue on the sales order item that carries costs and revenues, and can be viewed in the Product Cost Controlling Information System. Sales deductions can also be assigned to revenue elements through account determination, and updated on the CO object for the sales order item.
The condition type is selected through the sales document type.
Condition type EK01 is selected for sales document type TA (standard order). This means that the value from the cost estimate goes directly into pricing. A surcharge is calculated from this value and the net value for the sales order item is calculated.
Condition type EK02 is selected for sales document type TA (standard order). Pricing is carried out on the basis of condition type PR00. To maintain this price, choose Logistics --- Sales/distribution -
-
Sales --- Master data -
-
Prices --- Material prices and enter a material price. The material price is updated under condition type PR00, while the values from the cost estimate are updated under condition type EK02 and can be used for informational purposes.
Reward if useful to u
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.