Workflow implementation for Audit Plan in SAP Audit Management involves both Customizing and Development work. Following blog takes you through the process of Audit Management Workflow definition for Audit Plan. There are not much relevant information available related to the workflow so we implemented the same from scratch.
The workflow needs to be triggered at the time user saves a new Audit Plan. Following Tcodes are provided for the purpose: PLMD_AUDIT(For creating New Audit Plan, Question List, Audit, etc.) and PLMD_AUDITMONITOR (for edit/display exisiting objects).
User creates a new Audit Plan (Tcode PLMD_AUDIT) with Contact Person Tab filled with Roles:
50 for Approver
51 for Person Responsible
65 for Auditee
Relevant Business Partners needs to be created/assigned to the Roles for triggering workflow. Details of Business Partner maintenance will be discussed below.
The workflow goes to the inbox(Business Workplace, SBWP) of Audit Plan Approver. Approver can either approve or reject the Workflow.
Once approved, user has to enter the mandatory approval comments on the screen. The screen looks like :
The workflow, along with the comments, goes to Auditee for its acceptance.
When accepted, an acceptance mail get triggered informing all involved personnel of the acceptance of Audit Plan.
Status of Audit Plan changes to Approved.
OBJECTS PROVIDED BY SAP:
Following Business Objects are available by SAP related to Audit Management module:
BUS20300 – Audit Plan
BUS20350 – Audit
BUS20360 – Question list/reply
BUS20370 – Corrective actions
Business Object BUS20300 is the most suitable in our case as it is related to Audit Plan where we want to trigger our workflow We can either develop the scenario using this object or can also develop from scratch. We developed it independently for more flexibility and control.
STEPS IN DETAILS:
(A) Customizing / Functional steps:
1.Maintain Identification Tab with Personnel Number(Employee Number/PERNR) in Business Partner Role BUP003-Employee (Tcode used here is BP). This is used to identify the SAPID of personnel for workflow triggering and mailing.
(B) Workbench / Developer Steps:
1.BADI PLM_AUDIT_STATUS implemented (Method GET_PERMITTED_CHANGES) for triggering Workflow event. It is the initiation point of the workflow. [Code attached below]
2.Create custom table for storing rejection reasons(say, ZFA_WF_REASON_DE). The fields can be anything, depending upon your data capturing requirements.
3.Create Custom Business Object or delegated business object (with Key fields, methods, Events; lets say ZBUS20300N).[Program attached below]
4.Custom Workflow to be triggered. [Workflow XML attached below]
Custom Workflow gets triggered from the new BADI Implementation. Event EVE_CREATOR of Business Object ZBUS2030N is triggered passing on the parameter IV_OBJNR (Type PLMM_AUDITPLAN-GUID).
Lets walk-through some of the important steps in this workflow development:
(a) From BADI PLM_AUDIT_STATUS implemented above, the data Object IV_OBNJR is passed to the Workflow calling Workflow Event (EVE_CREATOR). Binding is done as shown below to pass the Audit Plan details.
(b) A While Loop is created for checking whether the Audit Plan is released or not. If released, it marks the Workflow completion. If Rejected, it is sent back to Initiator for corrections.
(c) Get Audit Plan Details Task – used for fetching Audit Plan details based on data IV_OBNJR. The binding includes passing IV_OBJNR to the task and calling Method GET_DETAILS in Background of Object Type ZBUS20300N and returning all relevant data ( like AUDITPLAN, PARTNER, STATUS, AUDITPLANS, RETURN, APPROVER, AUDITEE, APPROVER_NAME, AUDITEE_NAME).
(d) User Decision Step (for Approver) – used to capture the user decision of Approval or Rejection made by the Approver (Agent Determination is from local variable passed fetched from last step). If Rejected, mail gets triggered to Initiator for necessary corrections.
(e) Enter Approval / Rejection Remarks Tasks – used to capture Approval and Rejection remarks of the user. It uses Method RECORD_REMARKS_LOG of ZBUS20300N. Remarks can either be saved in a custom table or can be send as a comment in the subsequent mail or both.
(f) Approver Updation Task – The task is used to update the status of Audit Plan in background. The status changes from Being Created / To be Approved to Approved. We have to update relevant System Status by passing Status Indicator flag, and calling FM CRM_STATUS_CHANGE_INTERN for the updation. In binding it takes the input IV_OBJNR. Relevant System Statuses and texts are shown below in the blog.
(g) User Decision Step (for Auditee) – Similar to UD Step of Approver. The decision step goes to Auditee (retrieved from step c) for Acceptance or Rejection. Based on Auditee decision, the Workflow first captures the Approval and Rejection comments. It then updates the Audit Plan status (back to ‘Being Created / To be Approved’ in case of Rejection and ‘Complete’ in case of Auditee Approval).
(h) Container Operation – for setting RELEASED flag, so that the looping condition set in step (b) can be skipped and workflow gets completed after final approval.
(i ) Mail Step – both on Approval and Rejection of Audit Plan. The mail notification is sent to the Initiator in both cases, informing about the final action taken on the Audit Plan.
On Rejection, the whole progress gets triggered again (due to while loop), asking the initiator to make necessary changes in the Audit Plan. Once changes are done, the same steps gets repeated following all the necessary approval steps.
NOTE: For this example, it is a two step approval process that can be scaled as per your requirement and customer directives.
[[ System Statuses for module Audit Management :
|I1805||AM05||To Be Archived|
|I1807||AM07||To Be Approved|
|I1813||AM13||Question List(s) Assigned|
|I1820||AM20||Completed w. Outstanding Actns|
|I1826||AM25||Signature for Completion Prov.|
|I1827||AM26||Part. Signature for Completion|