In Territory Management , we can create rules for determination using the rule policy builder. The rules can be created based on standard attributes which would appear as drop or as F4 Help. But there are situations when we would need to add new Z -fields based on which new determination rules can be created. The process for creating Z fields for territory determination is as follows


  • Go to spro ->Customer Relationship Management ->Master Data ->Territory Attributes->Maintain Territory Attributes. The new attributes could be added in BP ( Account) , PR ( Product) , SA ( Sales Area)


  • To create a new attribute for determination in say in BP , select BP and press attributes and go to edit mode



  • Create new entry by pressing the new entry button and the following screen is presented


Fill in the details , Condition Attribute Id , Description , Help Type , Data type and F4 Help . Remember to choose the Applicable operators. If Dropdown is selected as Help type , then choose the operator '='.


  • And save the attribute


  • Now Implement the BADI CRM_TERRMAN_ATTRIB for additional attributes in Territory Management


  • Some of the methods, that needs to be implemented are

          IF_EX_CRM_TERRMAN_ATTRIB~FIELD_CHECK( ) -> This method is used for checking the value entered in the rule policy builder is valid or not.


          IF_EX_CRM_TERRMAN_ATTRIB~GET_F4_HELP_CUSATTR( ) -> The value of help is retrieved using this method.


          IF_EX_CRM_TERRMAN_ATTRIB~GET_CUSTOMER_ATTRVAL( ) -> This method provides all possible value of an attribute field.



  • An easy way to test this setup is to create additional attributes and then put a breakpoint in BADI methods. Then try to create a new rule from WebUI. The breakpoints would be hit.

I came across this scenario some time back where in the production system , we needed to update territories based on custom logic for existing opportunities. Actually the Territories were getting determined based on employee responsible while the logic needed to be based on sales organization and sold-to-party details. For this we created a program with input parameters - Transaction Type or Actual Object id for which territory updation needs to be done. But the question was how to update the territory data into business transactions.


The solution was much simpler than i thought. Actually if you check the partner Assignment Block in WebUI , the territory details are present there for employee responsible.The following steps and code snippets would help to understand better


  • The partner details could be easily from one order FM CRM_ORDER_READ by passing requested objects as partner.
insert ls_oppt-guid into table lt_header_guid.
insert gc_object_name-orgman into table lt_req_objects.
insert gc_object_name-partner into table lt_req_objects.
*   Read the Orgman and Partner Details
clear: lt_orgman , lt_partner.
call function 'CRM_ORDER_READ'
it_header_guid       = lt_header_guid
iv_mode              = gc_mode-display
it_requested_objects = lt_req_objects
et_orgman            = lt_orgman
et_partner           = lt_partner
document_not_found   = 1
error_occurred       = 2
document_locked      = 3
no_change_authority  = 4
no_display_authority = 5
no_change_allowed    = 6
others               = 7.
  • Retrieve the Sold-to-party details from the Partner. Remember to provide your own partner function in constant lc_partner_fct.
read table lt_partner into ls_partner with key partner_fct = lc_partner_fct.
  • Prepare your criteria for retrieving the Territory Details. In my case the criteria was based on Sales Area and Sold-to-party
read table lt_orgman into ls_orgman index 1.
   clear: ls_sales_area, lt_sales_area.
    ls_sales_area-dis_channel = ls_orgman-dis_channel.
    ls_sales_area-division    = ls_orgman-division.
    ls_sales_area-sales_org   = lv_r3_sales_org.
    append ls_sales_area to lt_sales_area.
*  Validate the Partner and Prepare for fetching the Territory Details
    clear lv_partner_guid.
    input  = ls_partner-partner_no
    output = lv_partner_id.
clear lv_partner_guid.
select single partner_guid from but000 into lv_partner_guid where partner = lv_partner_id .
lv_guid = lv_partner_guid.
    clear : lt_terrstruct , lt_terrstruct_indirect.
    call function 'CRM_TERRMAN_GET_TERR_BY_BUPA'
    iv_partner_guid        = lv_guid
    it_sales_area          = lt_sales_area
    et_terrstruct_direct   = lt_terrstruct
    et_terrstruct_indirect = lt_terrstruct_indirect
    internal_error         = 1
    others                 = 2.
  • You can retrieve the territory id in either of lt_terrstruct ( or lt_terrstruct_indirect ).


    clear: ls_terrstruct , lv_path_id.

    read table lt_terrstruct into ls_terrstruct index 1.

    lv_path_id = ls_terrstruct-path_id.


  • Fill the structure to maintain territory details
clear: ls_partner_attribute, lt_partner_attributes.
ls_partner_attribute-ref_guid = ls_oppt-guid.
ls_partner_attribute-ref_kind = 'A'.
ls_partner_attribute-ref_partner_fct    = '00000014'.
ls_partner_attribute-ref_partner_no     = ls_partner_empresp-partner_no.
ls_partner_attribute-ref_no_type        = 'BP'.
ls_partner_attribute-ref_display_type   = 'BP'.
ls_partner_attribute-semantic_key = 'TERRITORY'.
ls_partner_attribute-fieldname    = 'PATH_ID'." 'PATH_GUID'.
ls_partner_attribute-value = ls_terrstruct-path_id." 
append ls_partner_attribute to lt_partner_attributes .
  • Finally call the order maintain and order save FMs of the one order
call function 'CRM_ORDER_MAINTAIN'
ct_partner_attributes = lt_partner_attributes
error_occurred        = 1
document_locked       = 2
no_change_allowed     = 3
no_authority          = 4
others                = 5.
call function 'CRM_ORDER_SAVE'
it_objects_to_save   = lt_header_guid
et_saved_objects     = lt_saved_objects
document_not_saved   = 1
others               = 2.
*         Initailize the Transaction
call function 'CRM_ORDER_INITIALIZE'
it_guids_to_init = lt_header_guid
iv_keep_lock     = ''.


Now you can find that territory would be updated.

I want to share one problem which we faced when we upgraded to EHP2.

We came across a situation where we were not able to open SPRO in SAP CRM. Whenever we click on the IMG in Transaction Code 'SPRO' to maintain customizing settings then we were getting an Exception.

I want to share this because if someone facing the same problem then he will not have to worry about this.



We were using SAP GUI 7.10 version. That is why we are getting the exception because SAP GUI 7.10 do not support the SPRO in new EHP2 and higher versions.

So what we did to solve this is we simply upgrade our SAP GUI from SAP GUI 7.10 to SAP GUI 7.30 and the problem get resolved.

And now we are able to open SPRO in EHP2 version as well.


To upgrade your GUI with latest one you can go with the link

Here you will find the path to install or upgrade your SAP GUI to GUI 7.30


Hope this post will help  if someone is facing the same Issue.



Kumar Gaurav

I already covered the features around change request and claims In this final blog I am going to complete the cycle for the Grantor Management


8- Payment


Grantor financial execution interface is based on:

  • SAP ECC Public Sector Collection and Disbursement (PSCD)
  • or the Accounts Payable/Accounts Receivable (AP/AR).
  • The Funds Management (FM) component is optional and can be used for record and report on grant commitments and actuals.


FI AP AR.png

SAP Grantor Solution is integrated with SAP ERP:

  • Applications total  granted amount will create one Pre-Commitment item in SAP ERP, with different line items for payment type.
  • Agreement total granted amount will create one Commitment item in SAP ERP, with different line items for payment type.
  • Repayment will create a "Forecast of Revenue Document" in SAP ERP

The solution supports the billing/invoicing documents. System will create automatically billing documents in ERP for each agreement/claim in CRM (agreement or claims has to set to “Released”).


billing request.png


Billing document are displayed in SAP FI- AP/AR using transaction GTRBILL_DISP ( Display Grantor Billing Doc. (AP/AR))

billing transaction.png

Invoice document are generated for existing billing documents which have not been invoiced and which agreement “posting date“ is not older than the posting date in the invoicing transaction. System automatically creates an open item documents in ERP for each invoicing document. Open Item information is available in the “Grantor Agreement and Claim”.


agreement item open item2.png


Invoice Documents are generated using transaction GTRINV_S (Individual Grantor Invoicing) or GTRINV_MULTI_B_S (AP/AR Invoicing Run) in SAP FI-AP/AR.


Invoince document.png



In SAP ECC, program RFGTR_NOTIFICATION need to be scheduled to update the agreement open items with the “Invoice Information”.


open item.png

The execution of the payment run in SAP ECC clears open items for payment.  Transaction F110 (Parameters for Automatic Payment) is used to run the automatic payment.


payment transaction.png



In the overview page of the agreement will show the “Cleared Item (ERP)” amount and the reduction of the “Open Item (ERP) amount.


cleared item.png


After an open item document has successfully been cleared in SAP ECC, the information is stored in a table in SAP ECC. The report RFGTRFIDOC_ANALYZE clears the table and transfers the cleared amount of FI document which have been paid to CRM, which updates the corresponding Agreement Item.


agreement item  - clear item.png.




Grants audit are achieved by using standard CRM capabilities. By using workflow, status, actions and /or activities, audit activities could be registered in the system.

audit tasks.png


Generally, the Grant Agreement will detail any requirements / conditions for the grant. Maintain an electronic file with the supporting documents, will also help to reconcile the claims for reimbursement with the general agreement and and supporting documents. SAP offers CRM Case Management functionality as optional component that will provide a central place for all documents related to a single application and its follow-on transactions.


case management.png


The solution also offers a wide range of reporting options supported by SAP BI.

report options.png


10- Repayment:


A repayment is payment made from the grantee to the grantor if costs incurred were less than funds advanced. A repayment is required to balance the amount.

A repayment item in the agreement will create a "Forecast of Revenue Document" in SAP ERP


11-Year- End closing:


Solution supports all activities for year-end-closing. These include transferring open commitments (commitment carry forward) and a separate transfer of non-consumed budget (carry forward of residual budgets) from old fiscal years to the new.


By updating “Grant Start Date” in any application/agreement to the new financial year, system will automatically adjust the pre-commitments / commitments to the new financial year. Old commitment items will be set to “0” and new commitment item for the new date will be created automatically by the system.


roll over.png.


Overall, SAP Grantor Solution support all phases of Grantor Processing, helping organisation to  administers funds to provide financial assistance to a group of individuals or  organisations.


To start exploring the solution, you can use standard CRM UI Business Role "CRMGRMPRGMAN - Grantor Program Manager".

For some enhanced search fields, the wildcard search does not work. There is error "Expression &' with wildcard '*' is invalid here: Check search criterion" issued.


In WEBUI, the search with wildcard is only allowed when search operator "CP" is supported for the search field.

If wildcard search is required, do not forget to check on the search operation "CP" for the field in data model.

I have got several questions about partner address handling. For exaple:

Why the address is not displayed for a partner in parties involved assignment?

Why the BP's Name2 (not Name1) is displayed in WEBUI for Japanese users?

Why the addresses are diplayed differently for the same BP per differnt logon users?


The partner's address is displayed in a document as per the following logic:

Address type + sender country (usually the user's maintained country) + Partner number+address number

The above combination is sent to the address management which returns the address in a format that is dependent on the sender's country.


So, if a customer's own address format key is set in table T005 (field ADDRS) for a country, it is necessary to create a customer's own address format routine to make sure the address can be converted to correct display/print format.

For country JP, the formatting routine key for printing addresses is set to 013 by default. With this routine, the BP's Name2 is displayed as the partner's description in WEBUI.


The address type is also a factor to influnce the display of partner address.

There are 3 address types:



3=Contact person.


For address type 1 Organization, the value of line type "1" in the formated address (converted according to the formatting routine key for printing addresses) is displayed as the partner's description; for address types 2 Person and 3 Contact persion, the value of line type "N" in the formated address is displayed as the patner's description.


Maybe this goes to too detail.

To sum up, if there is address display problem, please check the address format key (T005-ADDRS) for the user's country first.

As I mentioned in my last entry, SAP Grantor Solution offers functionality to support the Application Assessment and Agreement ( ). In this blog I am going to explore what the solution could offer around change request and claim process.


6- Change Request:

A change request represents any changes of circumstances initiated by the grantee or the grantor organisation. An agreement amended may be created if changes are approved.


As well as grantor applications, change request could be received by any channel. Template models are supplied within the solution, or custom forms could be developed (HTML + BSP or Adobe Interactive Forms).


change request form.png

A workflow template is provided for change request approval process. When a grantee submits a change request, a workflow item notification is sent to the employee responsible for approve or decline the change.  On the effective date, agreement is changed and a hard copy of the previous version is attached as pdf document, automatically by the workflow.


7- Claim:


A Grant Claim represents a request from the applicant for payment of an amount specified in the grants agreement or reconciliation of payment based on accounting for incurred expenses or meeting other terms or conditions of the agreement.

claim menu.png


Templates forms are delivered within the solution. Forms could also be developed (HTML + BSP or Adobe Interactive Forms).


Grantor Claims are created with reference to an existing agreement; which should have at least one "claim-based" linte item. Claim submission is controlled by the Grantor Program (submission allowed, date restrictions...).

claim header.png

Individual claim items are assigned to agreement line items. Availability control ensures that the amounts claimed do not exceed the amount agreed to as define on the grantor agreement. Availability check is performed at header agreement level as well as item agreement level, to compare the sum of all claim based line items on the agreement with the sum of claim line items on claims.


If the clearance strategy is set to Manual, payments and outstanding advances could exceed the overall authorised payments and the grantee would receive more money than is supposed to be paid out.

claim items II.png


agreement claim integration.png


Business rules could be used for automatically claim assessment / approval. Manual approval could be supported by using CRM Surveys.

Once the claim is approved and released, a billing document is created in SAP ECC Financial.

billing request claim.png


Follow the next blog...

In my last blog I mentioned the features of Grantor Program, Budgeting and Application (Introduction to SAP Grantor Management - Part I). In this blog we are going to continue exploring the capabilities of the grantor assessment and agreement.


4- Assessment

Grantor application could be assessed using SAP CRM Surveys functionality and/or BRF+ Integration.

Application assessment is defined for each application in the Grantor Program.


Manual assessment is supported by CRM Surveys. By using checklist employees assess the application; and a score is assigned to each answer. When surveys are completed a evaluation result is presented. Application Form, notes and attachments are used to support the assessment process.





Automatic assessment is delivered with SAP Business Rules Framework (BRF). Using action profile for the application, the data contained in the application form is evaluated with rule set defined in the business rules framework.

In case of a positive assessment, an application line item with the calculated amount is created
In case of a negative assessment, the application header status is set to "Rejected". In case of a negative application assessment, the action "Print Letter of Rejection“ will be offered for execution.


SAP delivers models for Grantor Suveys and Grantor BRF rules, however each implementation will require to develop their assessment based on the Grantor Procedures.



5- Agreement

Approved applications becomes "agreements".  The agreement is used to define the conditions under which grantor awards a grant to a grantee.

Agreements could be created via follow-up transaction on the application or stand-alone.



agreement menu2.png


The Grantor Agreement will controls the payment statuses (authorised, requested, open and paid) for each payment type (payments, advances, repayments, holdbacks and payment recovery).



agreement header.png


  • Advances: A payment made in advance of actual work or costs incurred. An advance must be offset by a clearing payment.
  • Payments: Funds granted to a grantee for costs incurred.
  • Repayments: A grantee may be required to repay a grant payment as part of the terms of the agreement. A repayment is a payment made from the grantee to the grantor if cost incurred were less thatn the funds advanced.
  • Holdback Amount: The amount held back in a payment until all terms of an agreement are fulfilled.
  • Payment Recovery: Funds that must be recovered by the grantor if there is an overpayment to a grantee, or by the grantee if there is an underpayment by the grantor. This amount is not taken into account in the standard Funds Management Process while a Repayment is taken into account utilising the "Forecast of Revenue" vehicle.


agreement item.jpg

When the agreement is created, a funds commitment with reference to funds pre-commitment will be created.

agreements transaction hist.jpg


Availability  Control Notification message are displayed on the Grantor Agreement, based on the parameters on the Budget Control System.


agreement avc.png
Once the agreement or application status in CRM is set to  “Complete” the budget is released for any budget that has not been consumed on the earmarked funds document


Funds Commitment (transaction FMZ3)

Funds pre commiments.jpg

When the agreement status is set to Released, CRM sends the document to ERP for Billing (transaction GTRBILL_DISP).

grantor billing.jpg



Follow the next blog...

SAP Grantor Management solution is designed for public sector organisations that administers funds to provide financial assistance to a group of individuals or  organisations. Grants are financial assistance arrangements, where the grantee receives funds to carry out a program or provide services.


It is an end-to-end solutions that covers from the initial planning to the final payment and reconciliation.


In Grants Management, the public agency distributing the money is known as the Grantor, and  the receiving organisation/person that is recipient of the grants is known as the Grantee.


The business processes include the following:

Grantor Solution Overview.jpg


SAP Grantor Solution is based on SAP CRM 7 with SAP ECC Funds Management or SAP ECC Public Sector integration.


1 - Program Management:


The SAP Solutions offers the ability to administer the funds, using SAP Grantor Program.


SAP Grantor Program allows the definition of policies or regulations that are adopted by public sector organisations to deliver the external funding. The program defines how the grant activities are managed and funded, and controls how grants are delivered to grantee.


Basis features includes:

  • Allows definition of unique funding policies, applicant criteria and approval process; by unique assignment of forms, questionnaires, rules and process.
  • Can be represent in hierarchical structures.
  • Time-dependent activation of business process, controlling when the grantor characteristics are available to the public: application submission period, agreement period, claim period, change request period.
  • Master data integrated with SAP ECC Funds Management (Funds Programs).


program I.png







With SAP Funds Management integration, the program planning is controlled:

  • Grantor Program are represented as Funds Program allowing the account assignment determination (transaction FMMEASURE - Funded Program Maintain ). GTRDerive tool is used for derivation of the ERP account assignments


Funded program.jpg

In conclusion the Grantor Program allows to represent the different grants programs that are available to the public, e..g: sport, arts, science, community development, health; with their unique characteristics: eligibility, assessment, payment strategies. When some grantor programs don't change over time, the solution allows program to be defined with no end period (31.12.999) or the flexibility to have different program every certain period.


2- Budgeting

Grantor Solution integrates with SAP ERP Budget and Control System (BCS). The solution ensures that grants payments are managed within the operating budget to ensure approved funds are not exceeded, and the organisation mantains accountability for grants committed and paid.


Budget encumbrance can be triggered from an application (pre-commitment)  and/or agreement (commitment) in the form of an earmarked funds document.




program budget.png

Program budget are maintained in SAP ECC (transaction FMBB - Budgeting Workbench) .

Budget tx.jpg


3- Application:

Grantor Application defines how the application processing, eligibility assessment and award amounts are managed.

Grantor Program controls the differences between different applications eligibility period, application forms and Funds Integration. One big plus is a same application transaction could be used across different programs with the option to assign different assessment; giving flexibility to the organisation to implement new grantor programs with low new customizing.



application menu.png

Standard features available in CRM transaction types are available with SAP Grantor Application controlling the processing, such as:

  • Partner Management: The grantor, legal represents (contact person), external parties (external assessors,other governments agencies) and employees involved in the assessment are represented as business partner.
  • Dates Management: Application received on, application processing duration, application start, application end date and any other dates/milestone are managed using Date Management.
  • Status Management: All steps involved in the application processing could be represent as status: Draft, Received, In process, For Approval, Withdrawal/ Cancel, Approved, etc.
  • Notes: approval/rejections comments, internal comments, notes to print; could be managed by using Text.
  • Follow up documents, attachments, document templates...


application header.png


The use of applications is optional. A SAP agreement could be configured with status to represent that is in assessment. The advantage of having a grantor application is that funds pre-commitments are separated from the actual commitments (Agreements). For reporting purposes having different transaction types, facilitates the reporting of different metrics for applications/agreements.


Applications are submitted by different channels. SAP supports online applications forms (BSP+ HTML or Adobe Interactive Forms) by using SAP CRM Web Request functionality. A template model is delivered within the solution, but each implementations requires to develop their own template according to the grantor programs/characteristics.


application web form.jpg


SAP manages the following funding types, which are available to manage the financial aspects of the grant:

  • Requested Amount: the amount requested by the grantee.
  • Authorized Amount: the final application amount that is actually granted.
  • Eligible Amount: the amount to which the applicant is entitled determined by the program rules.



application item.png

Additionally, the solution allows to distinguish various payment terms:

  • Payment
  • Advance
  • Repayment
  • Holdback


The grantor application displays "Availability Control (AVC) message" from SAP ERP.


application budget.png


Application Total amounts are replicated to SAP ECC Funds Management as Funds Pre-commiment.


Transaction FMRP_RFFMEP1AX

Commiments pre commiments ECC.jpg


Funds Pre-commitment (Transaction FMY3)

pre commiment.jpg


As conclusion, the Grantor Application contains all data on application for a grant made by a potential grantee.


...To be continued

Dear SAP Users,


The following information is already well known to many of the users. However, I felt this is not aggregated at one place. So, I took this opportunity to document this simple process as a blog with an example.


In recent times, I had a requirement to fetch the Service Organization based on the Country Key in CRM. Hope this document solves the purpose for the users who are actually looking for the same requirement. Using this process, we can as well fetch many other details maintained in the Organizational model.



Begin of document:


The attributes for the Organization Unit are maintained through the transaction PPOMA. Based on the Attributes Maintenance Scenario that is selected at this level, the attributes differ. In the current discussion, we will concentrate on the SERVICE scenario. 


Transaction: PPOMA


For Ex, here the Service Organization is 0351, and the Country maintained is GB.



In the Attributes tab, select the ‘Attributes Maintenance Scenario’ as Service. Here, the Country key is specified as GB. 




Now, if we have the country key at some point of the code and want to fetch the Service Organization associated with it, we can use the below method:





Provide the following data as the input to the method

Scenario:          SERVICE

Search Values:

                            Attrib: COUNTRY

                            Value: GB




The same can be coded as,

CALL METHOD cl_crm_orgman_interface=>find_attributes
scenario           = ‘SERVICE’
search_values = i_search_values (Attrib = ‘COUNTRY’ and Value = Country Key)
hitlist                 = i_hitlist (Result list containing the Service Organization).



Just for the additional information,


To convert the HR Org Unit to R/3 Sales Org.






To convert the R/3 Sales Org to the HR Org Unit.






The class CL_CRM_ORGMAN_INTERFACE can be used to fetch other information as well, related to the service organization.




Thanks & Regards,

Narayana Raju.

Topic Introduction:


In Webclient UI, we are able to search different kinds of documents, such as sales orders, opportunities and activities, by search criteria "Belonging To". This blog will explain the application logic of "Belonging To = My Team" and "Belonging To = My Group".


"Belonging To = My Team"


  1. When searching with "Belonging To = My Team", the system will consider the logon user as the "head" of the team, and retrieve all documents that have one or more of his team members as involved parties (in assignment block Parties Invoveld).
  2. The logon user shall have been assigned to a valid position under an organization unit. This is a prerequisite.
  3. The logon user must be a manager. That is, this logon user must be assigned to a head unit position from technical perspective. In another word, the valid poisition in 2 shall be a head unit position.
  4. If 2 and 3 are met, all the employees under the same organizatoin unit and its sub organizational unit will be considered as a team members.
  5. All the documents will be included in the search result if one or more team members are involved in them.




We have such an organizational structure as below,


Organizational Unit XXX

   -> head unit position hup1

         -> employee A

   -> head unit position hup2

         -> employee ME

   -> position pos1

         -> employee B

   -> head unit position hup3

         -> employee C

   -> position pos2

         -> employee D

   -> Organizational Unit sub-XXX

         -> head unit position hup4

               -> employee E

         -> position pos3

               -> employee F


When we logon ME (logon user = ME), ME is assigned to head unit position hup2 under organizational unit XXX, thus all the business partners assigned to XXX will be considered as team members, which are ME, A, B, C, D, E, and F. Any document that involves one or more of these team members will be retrieved into the result list.


"Belonging To = My Group"


  1. Prerequisite: the logon user must have been assigned to a position under an organizational unit, regardless of head unit position or non-head unit position.
  2. When searching "Belonging To = My Group", all the employees assigned to this orgnizational unit will be considered as a group member except for the logon user itself. The logon user will be excluded from the group.
  3. All the documents that involve one or more group members will be included in the result list.




We use the same orgnizational structure above.


If ME is assigned any of the hup1, hup2, hup3, pos1 or pos2, A, B, C, D, E, and F under organizational unit XXX will be considered as group members. Any document that involves one or more of these group members will be retrieved into the result list.


If we move ME to position pos3, only E and F will be considered. The documents that has parties A B C D but not E F will not be included in the result list.





Triggering a work flow from CRM


Recently I came across a requirement to trigger a work flow from crm web ui component and would like to share within community, which can help others to achieve similar requirement.


Current example is based on CRM 7.0 EHP 2.


I have referred nice blogs written by Kiran Kumar Valluru:


Necessary configuration:

Necessary settings like RFC destination, Number ranges should be maintained in transaction SWU3


Scenario for this example:

User create / update an employee record and press on Submit button, it creates an workflow to his / her supervisor to approve.

Supervisor approve / reject the record and the decision conveyed to the user through mail.


First create a class (example: ZCL_WF_EMPLOYEE) which would trigger the workflow and would contain event, methods to process approve & reject decision.


The class should have interface IF_WORKFLOW assigned, which would automatically inherits BI* interfaces.

Please maintain necessary parameter in event, for example IV_EMPLOYEE_ID which you want to pass to work flow and can be linked to container. Event, methods should be public to be accessible from work flow.


Sample code to trigger workflow:

     Please find attached text file Raise work flow for RAISE_EMPLOYEE_EVENT.


Screen shot of sample Work Flow :





Please find referred blogs for creating work flow. Approve and Reject are two activities which calls method SET_APPROVAL and SET_REJECT method.

Here keep in mind that both APPROVAL and REJECT methods are static; you can have instance methods but then it is required to have another activity to take back instance for class ZCL_WF_EMPLOYEE.


What is happening in CRM:

After user click on Submit button, on event handler of the button we should call RAISE_EMPLOYEE_EVENT of that class to trigger work flow.


Please find below sample code:




This would trigger an workflow task to the approver which can be found under Work list work center in Web UI.

Approver can click on the item or choose decision from the front screen itself.


After the decision mail would flow to sap Inbox -> documents, transaction SBWP in GUI.


How can I see inbox mailing Web UI:

Unfortunately from sap crm 7.0, user can not see Inbox -> Documents in CRM Web UI !

To resolve the problem automatic forwarding should be enabled through transaction SO13 for each user; so that Inbox mail forwarded as external mail like outlook.


Tracing work flow progress:

If you want to trace how far the work flow has reached (which level) or errors, transaction SWEL is useful.

On selection screen give event name and execute, you would see results -> double click to see work item.

if you click on work item you can see hierarchical log, click on trace.pngList with technical details to see detail description of message and graphical log to see how far is the progress.



This blog is written on CRM point of view, please see refereed blog for workflow task creation and of course you can write to me anytime!

For viewing workflow task CT-WORKLST work center should be assigned to business role.




Courtesy: To my colleague Debdutta Dey for helping me to achieve the solution.


  Today I processed a customer message. This issue is when import BPs into a TG, the segmentation basis of this target group is not considered. This issue only happens when import relationship(BP and its contact person) from the file. I have never analysed this kind of issue before. After a long time debugging, I found out the BP import process happens in Function Module CRM_MKTTG_TG_JOB_PROCESSION. It is the master function module for the import. Here it checks if the partners exist in system already, if the relationship  typs is valid, if the relationship does exist. Then it will assign the BPs to the target group. So next time if you have problems for BP import, please set a breakpoint at this function module for troubleshooing. I think it will definitely save your time.

When I first heard that Stephen Johannes was working on a technical book about CRM I thought "do we really need another technical SAP CRM book?". After glancing the "Contents at a Glance" it was already obvious: "Yes, yes we do!"


Introduction - My SAP CRM books

The first SAP CRM book that I bought was Discover SAP CRM. To be honest I did not use it much as it is mostly a functional overview of your SAP CRM system. Do not see this is a criticism, it is just not the book for me The second CRM book that I bought was SAP CRM Web Client Customizing and Development. After the SAP course "CRM Web UI Deep Dive" this was an excellent reference book for developing in the SAP (CRM) Web Client 2007 (CRM 6.0). Then when SAP CRM 7.00/7.01 came out it brought some cool features which were perfectly explained in the third CRM book that I bought: SAP Web Client - A Comprehensive Guide for Developers. Its contents are still very relevant and I use it frequently. This book shines when you have to create a new Web Client application from scratch.



So the fourth SAP CRM book that I acquired is SAP CRM - Technical Principles and Programming. Like I wrote: only by looking at the "Contents at a Glance" alone you will see that this book fills a gap that the other books left. Where the Web Client books focus more or less solely on the Web Client and all its facets, this book deals with a lot of other gems that are present in your CRM system (much like the SAP Press book Next Generation ABAP Development deals with many gems inside your ABAP system).


On to the content!

The first two chapters deal with the basics of CRM in general and SAP CRM specifically. For me it contained a lot of aha-erlebnisses! For instance it explains why SAP CRM is a separate system and not an addon to SAP ERP and it explains the pillars of the SAP CRM system: Business Partners, Products, One Order (Business Transactions), etc. I would go as far as stating that these first 2 chapters are a mandatory read for every developer that has to work on a SAP CRM system.

The third chapter tells you what options SAP CRM offers with regards to enhancing the CRM Data Model with techniques like the Application Enhancement Tool (AET), Easy Enhancement Workbench (EEWB), Marketing Attributes & Product Master Attribute Sets.

The fourth chapter explains the great Business Transaction Events (BTE) framework. This powerful framework allows you to 'break in' into the various steps of a business transaction. Next to the customizing it also explains - by means of an example - how to develop custom functions that are called by the framework. In my opinion this chapter is not only for developers but should be mandatory knowledge for functional application owners/consultants as well. Whenever BAdIs are not available it is highly likely you can solve it by using Business Transaction Events.

Chapter 5 deals with data migration using the XIF adapter and the Legacy System Migration Workbench (LSMW). Useful for everyone (developer & non-developer) that needs to migrate data from a legacy system to SAP CRM.

The Post Processing Framework (PPF) is extensively covered in chapter 6. I could have used this chapter at one of my first CRM projects. I managed to get it to work back then but it took me quite some time. Also in this chapter the steps to create output with the PPF framework is illustrated with an example.

Chapters 7,8 & 9 present common enhancement requests in the various areas of SAP CRM, best practices if you will. From implementing common BAdIs to creating custom date rules to enhancing Interactive Reporting, configuring the Transaction Launcher and much much more. All with source code samples and good tips & tricks. I love these chapters! It should help developers making a well-informed decision on where to make certain enhancements.

To be complete Chapter 10 - When All Else Fails was added. When the techniques and frameworks described in the previous chapters do not suffice, you always have the option to make implicit enhancements or even (heaven forbids) core modifications.


The book ends with Community Resources where Stephen mentions the various options you have for connecting to community resources. He covers SCN in detail and references the Paying It Forward principle as well as the SAP Mentors program. Besides that he mentions user groups and social media.


My conclusion

This book is your backpack with the necessary tools to develop inside your SAP CRM system other than developments in the SAP Web Client (for that I recommend SAP Web Client - A Comprehensive Guide for Developers). Some of the referenced frameworks are easily overlooked when you start developing in a fresh SAP CRM system without much knowledge. Glance the book regularly to be aware of the various options you have and apply it when necessary. This is not only useful for CRM developers but also for functional application owners/consultants. The provided source code examples should help developers get started fairly quickly and the social media examples throughout the book greatly help in grasping the use of the various frameworks.


If I may take the liberty of speaking on behalf of the SAP Community Network, specifically the CRM developers: Thank you Stephen Johannes for the blood, sweat and tears that I know you put into writing this great book which will help me and surely a lot of other developers in making the right choices when it comes to developing in SAP CRM systems!

This Blog is to explain how to OverRide an Enhancement Set for a Component.


Steps to be followed:


1)Goto TCode SU01.




2)Enter the User Name for which you need to disable the Enhancement Set.


3)Press F7 Function Key.




4)Select the Parameters Tab.




5)Add the Parameter WCF_IGNORE_ENHANCEMT with Value 'A'.




This will ignore the Enhancement Set for the Component for that particular User.


Filter Blog

By author:
By date:
By tag: