Process of selling products or services to customer usually involves offer document in document’s flow. Typical process is starting with lead, contact activity with customer, through sales offer, ending with sales order.
Depending on type of product or service being sold by our company, offer needs to be more or less flexible. Flexibility is most important in selling services, where almost every sales is different. Sales representatives need to convince potential customers to their products. This happens usually by offering better price or better conditions than competition, etc.
If there are few sales reps creating few offers a day, this is not a problem for sales manager to accept these conditions with e-mail or telephone. But if we are dealing with big company, where few hundred sales reps are working every day, this way will not be effective. Company will need system solution that will support the process of accepting offers.
This solution should firstly check while creating new offer whether it is an unusual and needs to be accepted, later inform sales manager or managers about new offers waiting to be accepted. The same solution should support the process of accepting or declining offers. Offer that is accepted should have possibility to be released, and declined one should be blocked for it, unless its parameters will be changed and it will be finally accepted.
In case of companies with many sales reps and many sales managers we can determine appropriate manager that should accept the offer using for example organizational structure.
SAP Workflow idea
With SAP ERP or SAP CRM systems the functionality of SAP Workflow is also delivered. So we can without other costs except our work, develop new process flows. This functionality allows to create schemas of process flows including sending internet e-mails, sending internal messages or decision tasks to SAP users, and even automatic execution of ABAP code, etc. Process will be executed in background without or with users’ participation – depending on the way we will create our process.
The functionality of SAP Workflow allows to create schemas in graphical mode, which means to drag and drop elements and later configure them individually in order to suit process flow. We can also configure data flows between these elements in order to provide data to next steps of our process (eg. we can search for user’s e-mail address and later transfer this data to task that will send e-mail to that address).
In SAP ERP or SAP CRM systems there are many workflow schemas already delivered by SAP. Some of them are being activated at the beginning of system’s life cycle. Some of them are waiting in repository to be used when we need to create new process in system. Before creating a new schema we should always look whether a similar one already exists.
Defining workflow schema for accepting offer
I described business need in first subsection of this blog. Now we will create our workflow schema for supporting the process of accepting sales offers. Workflow process should be started when new offer that is to be accepted appears. In workflow environment it will be raising the event on saving the offer. We need to start with creating new event in business object of sales offer (called also BOR – Business Object Repository). This object represents sales document, its attributes, methods that can be used with this object, etc. Because we need to have new event we will need to create the subtype of BOR, change new object to suit our needs, and final create delegation of SAP standard object to the new one in SWO1 transaction. We will create a subtype of BOR BUS2000115 as ZUS2000115. Now everytime system will refer to BUS2000115 object, all attributes, events or methods from object ZUS2000115 will also be available. Next we will create new event “To_be_accepted”. It will be created in transaction SWO1 for our new business object ZUS2000115. We can see this event in the bottom of the next picture:
We have to remember to change the status of event on object to “Released” after successful creation.
Event has to be raised somewhere. If it will be raised we will be able to automatically start our workflow schema. We can raise event by simple coding. For example we can insert the call of function module SWE_EVENT_CREATE, with the name of our new event as parameter, in BAdi for postprocessing of saved document. In case we don’t want to call workflow for each offer, we can check while saving the offer (eg. In BAdi ORDER_SAVE) some of its parameters, like total value, payment terms, etc., and if wanted, raise event to start acceptance workflow. This way we will start acceptance process only for unusual offers.
Below is the example code for raising the event:
call function ‘SWE_EVENT_CREATE’
objtype = lv_object_type “BOR eg. BUS2000115
objkey = lv_object_key “our offer’s guid
event = lv_event “name of event, eg. ‘To_be_accepted’
creator = lv_creator “user that raises event
event_container = lt_event_container
objtype_not_found = 1
others = 2.
Now we need to create workflow schema and point in it that it has to be launched when event “To_be_accepted” will appear in system. We can create the schema in SWDD transaction. In workflow’s header in “Events” tab we choose our BOR (“BUS2000115”) and event “To_be_accepted” as start conditions.
Now we should create the body of workflow schema. We need to drag and drop “User Decision” step. This step will send message to Business Workplace (Business Workplace is a SAP application launched by SBWP transaction. Here we can check internal messages sent to our user or check our calendar) of responsible manager. As task we can choose from search help already existing task that sends message or we can create new one as copy of existing one. If we decide to make a new one, we will be able to change the text that will be sending message, to inform manager what he should do. To properly configure “Decision” step we also have to define to whom the message will be send. In order to do this we should create rule in transaction PFAC that will determine sales manager responsible for accepting our offer. This rule will have to be pointed in “UserDecision” step in “Agents” section.
When creating rule that will point an appropriate sales manager we can use ‘F’ rule type (“Agent Determination:Function to be executed”). This way we will be able to connect rule with function module where we will write whole logic for determining manager. Rule should have its container created where we will pass to the rule from workflow container the “guid” of sales offer (its unique identifier), for reading in rule’s function module all parameters from offer needed for determination (eg. Sales rep, country, city). In our example we will use organizational structure for determination.
For example our organizational structure could look like on a picture below:
In department responsible for sales there are 5 subdepartments located in different countries. In each country there is Sales Manager and Sales reps. Sales reps are Sales managers’ subordinates, and Sales Managers are Sales Director’s subordinates. Here rule should read sales department where sales rep, which is responsible for the offer, is assigned. We can use in rule ‘CRM_ORDER_READ’ function module to read partners from sales offer in partner function “Sales Representative”, and then check in which of Sales subdepartments he is assigned. We can use here ‘CRM_EMPLOYEE_GETORGUNIT’ function module. Later we have to check which sales manager is assigned in the same subdepartment. We can do it using for eg. function module ‘CRM_ORGUNIT_GETEMPLOYEES’ or select data from HRP1000 and HRP1001 tables. With this function module we can read manager’s objid number, later we will have to check its user name, because we need SAP username as receiver of users decision task. For this search we can use function module ‘CRM_CENTRALPERSON_GET’.
Going back to creation of workflow schema, the purpose of “User Decision” step is to send message to manager. The manager will see in his Business workplace message with text and buttons. Pressing appropriate button will communicate the decision to workflow engine. We need two buttons: Accept and Decline, which we have to create in “User Decision” step in “Decision Options” section. After creating these two steps we will see in graphical view that there are now two possible ways for the process after “Decision” step. These are “Accept” and “Decline”.
Next we have to create workflow step that will change the status of our offer to Accepted or Declined, due to manager’s decision made in Business Workplace. We need to drag and drop “Activity” element to our schema on “Accept” line after “Decision” step. We can call the step “Change status”. In this step we need to point task made in PFTC transaction. This transaction allows to create or change tasks that we can use in workflow schemas. Here we need to define a new one and point in it BOR object ‘BUS2000115’ and its method ‘userstatusset’ (this is standard method for changing document’s status). In workflow schema in step definition we will have to write down the parameters that will be used by ‘userstatusset’ method. This will be user status profile of sales offer and user status ‘Accepted’. If we would like to write our own method for changing status, please remember to assure that document is not locked (eg. by other user who is editing document). In other way our workflow process will fail in case someone is editing document at the same moment. We can do it by using special function modules eg. ‘CRM_ORDER_ENQUEUE’ before calling function module for changing document’s status.
If this function module returns sy-subrc <> 0 it means we cannot make change of sales offer. Workflow process should then make a loop and try to change document later. After user decision “Decline” we should create similar step for status change, that will set offer’s status “Declined”.
Our workflow schema looks like below:
Now we need to send message to sales rep, who created the offer, about new offer’s status. We will drag and drop “Send e-mail” step after “Accept offer” and “Decline offer” steps. In this step we need to write down the text of e-mail (eg. Your offer no & has been accepted) and point the receiver of message. In this step receiver can be pointed eg. as BOR’s object attribute. In this case we will need to add custom attribute to BOR object ‘ZUS2000115’ and read in it sales rep from document. Usually we can just use workflow container value “WF_INITIATOR” for pointing message receiver.
Right now our workflow schema looks like below:
After all we just need to activate new workflow schema. Please check in transaction SWETYPV if new workflow schema is properly connected to BOR object ‘BUS2000115’ and event “To_be_accepted”.
Our workflow is ready to use. We can also enhance it for second acceptance level for offers with eg. total value bigger than 100.000 USD. These offers should be accepted by appropriate Sales Manager, and later by Sales Director. We should enhance process flow after Sales Manager’s acceptance. As in first part we should also do the steps: determine Sales Director and its username (organizational structure can be changed in future so we cannot hardcode this username, although there is only one Sales Director at the moment), send him “User decision” task and later process changing status to accepted and declined.
Maintenance of solution
SAP Workflow is a tool working in background and it should be monitored. It has a lot of logs where we can read what exactly happened with each flow of process. As every tool it can, in some situations, lead to errors. That is why it is important to analyze logs and look for behavior we did not take into account while writing solution.
I will lister few transaction codes useful for analyzing workflow.
Transaction SWEL shows logs of raised events. Here we can find information whether event was properly raised or not. This is especially useful while creating workflow process for checking whether event was raised.
The flow of workflow schema can be monitored in transaction SWIA. Graphical view will show how the workflow did run. Here we can read data processed by the workflow, especially container values, check which users has been determined for accepting the offer.
Workflow logs can also be found in sales offer’s header where we can find button “Workflow”.