Hello All    


I am pleased to announce first ever CRM Community Event in Delhi , India on 23, November,2013(Saturday).

Idea is to meet with all SCN CRM Delhi region community members in person and to discuss about various topics on CRM like

CRM on HANA, CRM EHP3,Social media integration and many more.



Hasan Rafiq already published a blog http://scn.sap.com/community/events/blog/2013/09/26/sap-crm-event-delhi--india . We would like to know the interest of community members who would be interested to attend this event. Based on the response we will be deciding the location of the event.



my request to all community members who would like to attend this event or want to present any session please register at the link below




We are planning to organize similar event at other locations also. Please keep following this space for more details.


You can reach to following volunteers if you need any further info or if  you have any suggestion.


hasan rafiq(rafiqhasan@gmail.com) or Kumar Akshat(kumar.akshat@sap.com) or Naresh Kumar Malik(naresh.kumar.malik@sap.com)



Agenda :

CRM Webclient UI improvements via Customer Connection - Gregor Wolf Gregor Wolf

CRM  with HANA -  an Overview   - Naresh Kumar Malik Naresh Kumar Malik

SAP CRM - Social Inegration - Hasan Rafiq Hasan Rafiq


Sap Connect link: You can join sessions remotely via* *https://sap.apj.pgiconnect.com/I056579

Participant Passcode:



Venue :  SAP Labs India Pvt. Ltd. - Gurgaon , Vatika Towers , Sector 54, Golf Course Road , Gurgaon, Haryana - 122002, India

Since SAP CRM 6.0, a billing transaction type is alwasy displayed in the follow up transacton type slection list for an sales document.


It is a functionality change, that is intended for the convenience of creating billing document, the billing document appears as an default entry in the follow up transaction type selection list.


If there is the business requirement to get rid of this option, you need to enhance the view and deactive the relevant codings in the enhanced class CL_BT115H_S_SOHOVERVIEW_IMPL method EH_ONFOLLOWUP
... ...

*** Add billing on popup

    lr_context_node = gr_proctype_bo_popup->get_context_node(

iv_cnode_name = 'PROCTYPE' ).

    IF lr_context_node IS BOUND AND me->is_template( ) = abap_false.

      CREATE DATA ls_struct_ref.

... ...

As a developer in my daily life I always need to quickly locate the source code where raises a given message in webclient ui.

(If you would like to know how to quickly find the source code which raises message in SAP GUI environment, please refer to this blog of mine instead. )

Here below are four approaches using which almost all messages I meet with so far could be located:


1. If some invalid data is input which blocks the account save, the generic message saying "data contains error" without dedicated errorous field is not helpful. Suppose I would like to find the exact code which raises error message. You can observe that if I put the mouse onto the error message, there would be a tooltip poped up with message technical information like message id and message number. By default this behavior is not activated for your user. You can manually activate it via:




go to transaction code SU3 and maintain user parameter BSPWD_USER_LEVEL = 6




6 means "Experienced user". You can find the description of all possible value in domain BSPWD_MSGLEVEL.




Now we know the message id is CRM_BUPA_BOL and number is 036. Go to transaction code SE91 and search code via where use list:




we get 2 hits: double click on one of them. Why there is if 1 = 2 whose condition will never be met?



actually the red code below is just what we look for. The above code in line 86 is just simply written in order to enable itself to be found by where use list,

since where used list in abap workbench would only find the static message usage like keyword MESSAGE + <message type like e,i,w><message number>

(<message id>). The red code does not really raise message via keyword MESSAGE but just put the given message into an internal table via global message service and thus would not be found by where use list.







2. In IC agent inbox, if an unsupported search attribute is specified, the search could not be performed and the corresponding message is raised in ui.



unfortunately now if I follow approach1, no hit in where use list.




so I try to use report RS_ABAP_SOURCE_SCAN, use 559 as search key, and maintain CRM_IC_APPL_INBOX as package. The report will scan 559 within all abap source codes which are stored in that package.




So how can I get the package name CRM_IC_APPL_INBOX? Just click F2 on UI, I can know the view name ICCMP_INBOX/InboxSearch.


in its event handler for event SEARCH, I can know that the search implementation is actually provided by class CL_CRM_AUI_QUERY_SERVICE.




so now I can ensure that the code which raises the information message is definitly inside that package.



after a while the report runs over and I can simply double click the result to jump into the source code.



3. When it comes to product area, it is pretty easy to find the source code of given message. Almost all underlying messages in product application is raised by utility function module COM_PRODUCT_ADD_MESSAGE. In example below I input an invalid item category group WWW and would like to find which code does validation check and raise error message. All I have to do is just to set a breakpoint in that function module, and re-save in ui:




breakpoint is hit as I expect after I click save button again:



the sy-subrc indicates that there is some exception raised, and just above the FM COM_PRODUCT_ADD_MESSAGE, we can find the FM

COM_PRODUCT_CHECK_FIELD_ENTRY complains that the input WWW is not valid.



4. This is the most powerful debugging method. Suppose I need to find which line of code raises this message below:


Use F2 button I know that the current search page is built on BP_HEAD_SEARCH/MainSearch:


So I set a break point on search event handler:



The breakpoint is hit when I click search again. However I will not debug it line by line. Click tab "Break./Watchpoints", and create a dynamic breakpoint for abap command MESSAGE. As a result the breakpoint will be triggered wherever the keyword MESSAGE is written in abap code.




I just click F8, and debugger automatically stops in the line below, which is just what we are looking for.






all the four methods above makes my trouble shooting life easier. If you have any other approaches to achieve the same, welcome to share with us

Disciplined Approach To Solution Scoping


Organization’s business imperatives have more often a mutually-inclusive impact on how it leads its strategic IT initiatives. In other words, aligning IT strategy closely with business strategy and mobilizing the right resources to effort instigates collaboration and collective teamwork those once would have been in parallel existence.

Effective alignment can happen only when IT and business strategy are anchored in clearly articulated scope of capabilities in juxtaposition. Such collaborative capabilities are dynamic and give the organization an ability to adapt to changing market environment especially while implementing enterprise systems that hold strategic importance and hence needs to be anchored to clearly defined scope of   business and IT capabilities.

Here is an illustration of a traditional methodology in its simplistic view on various characteristic activities across the life-cycle of an implementation project (See Figure 1). It essentially links and binds together a set of collective activities into a well-defined and distinctive transition plan.

Traditional Methodology - A Simplistic View - FINAL.jpeg

A disciplined scoping holds a paramount importance at the beginning and lays the groundwork for more effectual designing and to subsequent steps of the project. Incoherent and messy scoping leads to unnecessary complexities, since high-profile IT projects are particularly prone to drifting. We need to be vigilant against scope tiptoe, which can cause projects to deviate from their original objectives.

In the planning process, we should clearly articulate and reinforce the project’s business objectives long before the actual transformation. Here are critical guidelines and few success factors that go-a-long-way in scoping the solution to realization.


  • In the initial stage of the project, we really need to understand the business imperatives, objectives and the challenges – this clear understanding will lead us to scope, approach and timelines and in essence provides a foundation to plan subsequent steps.
  • Scoping in most of the scenarios, are conducted through business blueprint workshops with the specific process or functional emphasis along with the targeted audience to maximize the effectiveness. At this point, the audience should be expanded to include all of the employees who will use the system with the designated leads.
  • Client specific scoping templates – functional and business process flows, scoping of requirements, requirements fit-gap, and workshop take aways etc. – drafted well in advance are exceedingly effective. They help us in systematic and organized scoping of requirements and also reduce time overall to accelerate the process.
  • Solution walk-through process flows can be of great help in mapping client-specific functional and business process requirements to the functionality and we should maximize the usage of the off-the-self solutions for they would accomplish most of the project’s objectives at lower cost. With this approach we can identify gaps and customizing, recommend potential workarounds for gaps, and suggest enhancements and improvement opportunities.
  • Consolidate the scoping requirements, prioritize requirements, solution gaps/enhancements and present the findings of the workshops to reassure clear alignment between proposed IT capability, business measures addressing key pain-points and desired outcomes.
  • All the customization's should be reflected on the costs to build and support them over the project’s lifetime. In all, we should limit customization's to no more than 20% of the standard, and those modifications should focus on central capabilities that are essential to business imperatives and its success. Customization beyond these levels can make future upgrades too costly and time consuming, undermining a fundamental benefit of packaged solution.
  • The scoping schedule should always include the freezing time. However, some addition in scope may be justifiable to stay up-to-date with market and competitive demands. But in general, clarity of scoping that defines what the project will and won’t accomplish reduces the likelihood of inconveniences and its impact on the overall project scope and timeline.
  • In practicality, often users request new features during testing phase of the project and we should be prepared to evaluate those requests in the context of the project’s original objectives and accordingly accommodate with the necessary approvals. The scoping issues should always be discussed in its objectivity separating the issues from the people.
  • The needs of the organization will change over time and its capabilities must keep pace with them. This requires constant coordination between IT and the business units, on-going assessment and reviews of the IT priorities, timely scoping and allocation of resources. However, the essential capabilities remain relatively stable. Once the new system has been rolled out, it’s important to continue to measure the operational and behavioral changes that will lead to the sought-after benefits.


As IT capabilities become aligned with business imperatives and strategies, its relationship to the business matures and deepens over time. The IT organization’s ultimate objective is to function seamlessly as part of the business and then evolve into a trusted partner.

Disciplined scoping of solution makes way for a complete and all-inclusive methodology, ensuring that the requirements are identified, summarized, prioritized and documented with the necessary approvals during the scoping phase of the project. Whilst, governance is the bridge between promise and delivery – there always is a better way, however – it’s the people who make the difference.

When we collectively work together, as a team with the shared values and the simplicity of virtues, we can bring about business-transformations through successful implementations of projects that truly deliver on value and desired outcome with the lasting impact.

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 http://scn.sap.com/community/gui/blog/2013/05/29/sap-gui-730-download.

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 http://scn.sap.com/community/crm/blog/2013/08/12/introduction-to-sap-grantor-management--part-iii. 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 ( http://scn.sap.com/community/crm/blog/2013/08/13/introduction-to-sap-grantor-management--part-ii ). 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 includes the following steps:

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.






Filter Blog

By author:
By date:
By tag: