Dear Friend,
The Following can be your help....
Service Notifications
Purpose
This process is based on requirements of the US State of Texas. The basic process flow is generally valid. The Texan requirements are apparent, for the most part, in the specifications of the templates for communication: the accompanying IDoc and the functions for data mapping are based on the message formats EDI 650-01, EDI 650-02 and EDI 650-03.
The standard templates are only for the party requesting the service, in other words, they cover the functions for sending service notifications and for processing confirmations of service notifications. No functions are available for the recipient and the party who executes the service notification. You must implement these functions yourself as part of the implementation project.
To simplify matters, the following sections are based on a typical scenario in which the requesting party is a supplier and the executing party is a distributor.
Process Flow
From the supplieru2019s perspective, the process includes the following steps:
The customer calls the supplieru2019s Customer Service department and requests a service.
The supplier sends the distributor the service notification as an electronic message.
The distributor sends the supplier a confirmation.
Notification completed successfully
Notification rejected
Notification could not be completed
If the customer calls and reports that the problem has been solved, the supplier informs the distributor of this.
Communication between the supplier and the distributor is based on the service notification. The service notification is created in the supplieru2019s system by a front office process and sent to the distributor via IDoc. If the distributor sends the supplier a service confirmation, the service notification is automatically refreshed in the supplieru2019s system.
Recording the service notification
The service requested by the customer can be recorded using a front office process (FOP).
You can use the front office process (FOP) SNOT650 to create service notifications.
FOP SNOT650 comprises:
Front office process SNOT650S
Editor step SNOT6501
Editor step SNOT6502
The FOP is integrated in the data environment configuration ISU (transaction ENVD). This means that you can start the FOP by clicking with the right mouse button on the installation, premise or device. If you start the FOP by clicking on the installation or premise, the connection object is taken as the reference object for the service notification. If you start it by clicking on the device, the device/equipment is taken as the reference object.
The FOP gathers the data required in order to create a service notification.
The FOP is processed as follows:
Selection of service code in accordance with the codes in code group ISU650SO (catalog type 😎
You maintain the catalogs and code groups in Customizing under Plant Maintenance and Customer Service ® Maintenance and Service Processing ® Maintenance and Service Notifications ® Notification Creation ® Notification Content ® Maintain Catalogs.
You must not change the notification codes while you are still using the standard SAP function modules in your process.
The code groups are defined in the include IEIDESREQ_CODEGROUPS_CODES.
Additional information on notification creation
You can specify additional information (for example, planned start date, device information record, long text) or specify rules on the admissibility of weekend, night and public holiday work. An item is created in the service notification for each permission. The codes for the permission are taken from code group ISU650YN (catalog type C).
Installation lock
You can specify whether an installation may be locked. An item is created for this purpose in the service notification. The codes are taken from code group ISU650SU (catalog type 8).
Information on contact person
In addition to the contract partner for whom the service is requested, you can also enter data on a contact person. These entries include a one-time customer as a partner in the service notification. To include a one-time customer in the service notification, you must specify a partner role with an account group for one-time customers. The partner role is specified in the FOP as a constant in the data flow for method ISUSMNOTIF.ADDONETIMEPARTNER in step 80. The number of the one-time customer must also be specified there.
The FOP creates a service notification that contains the data required for creating the IDoc that is sent from the requesting party to the receiving (executing) party. The installation or device information record is linked to the service notification by means of an object link.
You can display the link in the service notification by means of the menu path Extras ® Documents for notification ® Utilities industry document flow. The point of delivery can be determined from the installation during runtime.
The service notification is created using a notification code. The FOP creates the notification code by linking the literal SO with the code chosen in step 1 from code group ISU650SO.
If you choose code 13 (Investigation) as the service category, the FOP attempts to create the service notification using code SO13.
Communication
The system uses an IDoc of the category ISU_MAINTENANCE_SERVICE_ORDER as a template for communication.
The supplier sends the distributor an IDoc:
to request a service
to cancel a service request sent previously
The distributor sends an IDoc to the supplier:
to confirm that the service has been performed successfully
to reject a requested service
to cancel a requested service
SND_SRVREQ is used as the trigger communication event for sending the service request from the supplieru2019s system. Start report RESERVICEREQUEST_DEREG. Service notifications are selected in the system based on the criteria you specify. An IDoc of the category ISU_MAINTENANCE_SERVICE_ORDER is then sent to the distributor for each service notification.
An incoming IDoc of the category ISU_MAINTENANCE_SERVICE_ORDER triggers the event REC_SRVREQ. The IDoc is then analyzed in order to determine one of the three business transactions described above.
Processing the Confirmation
The service notification is refreshed in the requesting partyu2019s system according to the business transaction. The service notification is completed in all cases.
The system also uses codes in code groups ISU6501P and ISU6507G to note the reason why a service was rejected or not performed as an item in the service notification.
You maintain the catalogs and code groups in Customizing under Plant Maintenance and Customer Service ® Maintenance and Service Processing ® Maintenance and Service Notifications ® Notification Creation ® Notification Content ® Maintain Catalogs.
You must not change the notification codes while you are still using the standard SAP function modules in your process.
All the codes are defined in the include INCLUDE IEIDESREQ_CODEGROUPS_CODES.
http://help.sap.com/saphelp_utilities472/helpdata/en/11/99cd3b0991a179e10000000a11402f/content.htm
reward points if helpful,
regards,
Amlan Sarkar
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.