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.


The GDC is a set of objects stored in the Global Memory of your session. For instance, the CURRENTCUSTOMER is occupied when the business partner in the IC Webclient is confirmed.

GDC is a virtual, central data storage area in the Interaction Center (IC) WebClient.

The GDC stores data that may be used by different views. It does not store random data such as hit list results. It can contain references to Business Object Layer (BOL) objects or to Business Object Repository (BOR) objects, provided that they are wrapped by a special BOL object. Programmers must predefine the objects they want to use in the context of the GDC. In their programs, they can only store or retrieve objects that are defined.

Functions such as scripting can use the GDC to copy data from the current interaction into various processes. The GDC can also be used during navigation to transfer the name of the source view and the selected object to the target view of a navigational link.

The lifetime of the GDC is linked to the interaction: The system refreshes the GDC after each interaction at end contact.


An agent confirms a customer name. The confirmed customer is stored in the GDC, and its attributes can be retrieved by scripts.

When the script was written, the text reads:

Good afternoon, [Customer Name], can I ask you a few questions?

When the agent runs the script, the system substitutes values from the GDC. The script appears on the agent's screen as follows:

Good afternoon, Mr. Harvey Smith, can I ask you a few questions?

How to do?

  1.   To use this GDC, we have to get the GDC object, which is type of IF_CRM_UI_DATA_CONTEXT.
  2.   We can get this Object ref By calling GET_INSTANCE( ) of CL_CRM_UI_DATA_CONTEXT_SRV by passing Controller class as importing parameter( It’s not mandatory ).
  3. After getting GDC object, You can set or get data/entity by calling setter and getter methods of IF_CRM_UI_DATA_CONTEXT.



Steps to follow

The objects in the GDC are defined in the IMG:

Customer Relationship Management --> UI Framework --> Technical Role Definition --> Define Global Data Context Parameters

Here ,you can maintain your custom attribute also.

Set the data to the GDC attribute(XXXXXXX = GDC Parameter declared in SPRO)

data: lr_gdc type ref to if_crm_ui_data_context,

        lr_entity type ref to CL_CRM_BOL_ENTITY.


lr_gdc ?= cl_crm_ui_data_context_srv=>get_instance( ).


  1. TRY.

****Get the entity********

*Your logic to get entity


       lr_entity ?= <entity from the your logic>.

lr_gdc->set_entity( name = 'XXXXXXX' value = lr_entity ).


Get the data to the GDC attribute(XXXXXXX = GDC Parameter declared in SPRO)

data: lr_gdc type ref to if_crm_ui_data_context,

        lr_entity type ref to CL_CRM_BOL_ENTITY.


lr_gdc ?= cl_crm_ui_data_context_srv=>get_instance( ).


lr_gdc->get_entity( exporting name = 'XXXXXXX'

  importing value = lr_entity ).

Date: June 20, 2013

Time: 9:00 a.m. - 4:30 p.m. (ET)

Location: Palo Alto, CA




Is it really possible to transform your approach to data, process, user experience, and change management without business disruption?  Protect existing investments and establish a road map for the future with middleware solutions from SAP that accelerate your business into real time.


Seamless middleware for the real-time enterprise


Join us at the Middleware Technology Forum in Palo Alto, California, to learn how to capitalize on the mobile, cloud, and Big Data opportunities in front of you and seamlessly integrate your infrastructure.


You’ll choose from three tracks – application development and integration, information management, and IT management – and explore the latest innovations that will help you:

  • Unify all your data, process, and users in one radically simplified middleware platform
  • Deliver accurate information to any application or user, anywhere – in the cloud, on premise, or to a mobile device
  • Analyze any volume or type of data - internal or external , operational or transactional, and structured or unstructured
  • Manage change within your lifecycle, improve testing, and reduce deployment risks
  • Get deeper insights with near-zero business process response time, for decisive action in the moment
  • Revitalize your current applications and unleash the potential of new ones with beautiful user experiences
  • Reduce TCO while protecting existing software investments and accelerating development

Join us on June 20, 2013, to discover how to fast-forward business insight and prepare to redefine the way you think about data.





Krishnendu Laha

Explore RAD in CRM

Posted by Krishnendu Laha May 21, 2013

Rapid Application Development in CRM


We are in demanding world to have CRM in place or ready to be use as soon as possible and RAD came as a breather for custom development requirement.

RAD is available from CRM 7.0 EHP 1 and is very useful in developing an application including search facility with RDBMS in place.


I got inspired by two Demo posted by Tzanko Stefanov :


These demo content most of steps to create a RAD application and it hosted with a simple example.

Here in this blog I would focus more on RDBMS concept and in-depth analysis and maintenance or enhancement of the component.


Necessary configuration:

In your business role CT-ADMIN (Administration) work center with AXT_RAPP_S (Manage Rapid Applications) should be assigned / visible.


Scenario for this example:

Let's build an application of Employee Header, Employee Monthly Salary and Salary Wages.

Below are structures:


So here you can see there is a relation ship between three tables 1: N : N

Please create an application ZEMP through wizard (demo contain video links, please follow that) and 1) select ZEMP_HEADER at the time adding ZEMP_MSALARY, 2) select ZEMP_MSALARY when adding ZEMP_MSALARYWG.


After you finish with RAD wizard, please check status is green or not -> yellow means 'In Progress' status and red means error.

After it got green status, the application ZEMP is ready for testing in BSP_WD_CMPWB transaction.



What happens in background?

SAP uses AXT_CA component and component set as a Model to host any application been created following RAD process.

It also add entry for component ZEMP in 'Working Context Repository' and create Logical links for Create, Search and Display.


It also create four structures for each tables used in wizard with different usability:

1. Z*ATTR - Attrbiutes from table

2. Z*WORK - Runtime structure

3. Z*LOGKEY - Key fields from table

4. Z*DYN_QUER - Structure for searching records dynamically in table


It also create entries in below tables for Root, Access, Dynamic Query nodes and their fields (wherever applicable):










It creates different function modules for each table as ZFUNC* under function group ZFUGR00000 for handling of database operations like Insert, Update and Delete.



How request / event handles in component?

Classes under package AXT_RUNTIME and AXT_COMMON are used for request and event handling.


For example process flow happens for event handling in view of component:

Class CL_WCF_BSP_EVENTS_HANDLER called -> navigate proper event handling -> CL_WCF_BSP_NEW_COMMAND (New) / CL_WCF_BSP_EDIT_COMMAND (Edit) / CL_WCF_BSP_SAVE_COMMAND (Save) / CL_WCF_BSP_CANCEL_COMMAND (Cancel).



Enhancement of component:

I would suggest to use component workbench for configuring views not AET; because if AET used in one view and another component workbench sometimes it does supersede later one due to metadata selection (but it might be depend on EHP).


In execution mode component navigation is same like in transaction GENIL_BOL_BROWSER, whcih is Search -> Root node -> Access node -> Details -> Access node -> Details based on relation ship.


You can create some extra Overview page to have some different user interface or skip Details section but please do not delete anything rather hide in OVP page.



Adding an extra parameter in search criteria:

If you want to add an extra search criteria then that field should be available in Z*ATTR, Z*WORK and add that field in Z*DYN_QUER with an related entry in table AXT_RUN_QUERYMAP (please add the entry in transport request also).


Also that field should be added in search view manually to make that available in search list.


Adding an extra view with a new bol entity:

After creating a table, structures like *ATTR / *WORK (as I mentioned above) should be created keeping in mind the relation maintained already!

For example if we want to add monthly leave plan then the table would look like below:


Then proper entry should be added in require tables as I mentioned above (please use already added entry as a reference).

A new FM should be created (as per entry in AXT_RUN_TAB_DEF table) to handle database operation.


Now add an extra view with table type (if require) in component, add proper hierarchy BOL entities and change the below properties:

1. Change super class of Controller Implementation from CL_BSP_WD_VIEW_CONTROLLER -> CL_AXT_BASE_TABLE_VIEW

2. Change super class of Table node from CL_BSP_WD_CONTEXT_NODE_TV -> CL_WCF_BSP_BASE_TV_CN


Please assign the view in Runtime Repository Editor to be viewed in proper place.



Adding / deleting primary key combination of base table:

If you want to add / delete key field from base table then apart from changing the table related structures which are Z*ATTR, Z*WORK, Z*LOG_KEY, Z*DYN_QUER should be changed.


Also we need to make sure related bol entity is also effected by adding / deleting entries in table AXT_RUN_KEY_MAP (please add the entry in transport request also).


Related FM ZFUNC* under function group ZFUGR00000 should also be changed to reflect the changes in key fields.




Please finalize the database design before going for application creation through RAD wizard as it would be really complex to change the relation after it generated. Please use custom data elements in table as it would be useful for length / data type changes in modification phase.


Courtesy: To my colleague Shashi Jha for referring to interesting world of RAD.

I have recently found that HP had released the much awaited Unified Functional Testing(UFT) software to replace their flagship offering QTP. I'm sharing my experience of run test on CRM UI with you  and hope to hear back on your experiences with similar products that you may have used.


I was able to download the trial version of UFT from HP website with 30 day demo licence. Installation went smoothly without any hiccups.


After initial settings the UFT was ready to be discovered.




Like in QTP, UFT presents screen to select addins required for Application Under Test(AUT)


I have choose SAP and Web addins. (Note: You need to install addins during initial installation, to be available at this stage)


UFT has a different interface and menu layout than QTP.



Select "Test" to create new test.







This view shows number of actions associated with the test. Being a simple test I have just one action. There can be multiple actions if required and they can be defined as re-use able to save development effort.



Some settings were required to connect to SAP.


Setting required for SAP GUI.


Settings required for CRM web portal



Once I had recorded the some basic steps of the process the script in expert view looked like the following screen-shot:



Please watch the video where I have played the script to see if the test was successful.



I found UFT can help in building a strong regression suite and can help in building confidence before transports are moved across the environment.

Automation helps in providing regression testing capabilities which can be further help build stronger change management and release management in an organisation.


There are many tutorials for QTP available on the web.

Application and Agreement transactions of Grantor Management by default transfer Precommitment/Commitment documents to ECC on each save event. In case user want to replicate when certain tasks are completed, then this can be controlled through status management. Grantor Management has INPR, RELE as system status. User status should not be maaped to INPR until application is ready to be transferred to ECC.


Create Status profile in SPRO->Img->Customer Relationship Management->Transactions->Basic Settings->Status Management->Define status profile for User Status




Associate User status to System status and leave the Draft status transaction empty.



Select Draft click on DETAILS and click on NEW ENTRIES



Set radio buttons of To be distributed to forbidden and no action



Business transactions will not be transferred to ECC and precommitment/commitment is not created.



Application as a business transaction in CRM Grantor Management has different features compared to other business transactions like sales order, service order in SAP. It is created with reference to grantor program which in turn integrates with ECC for budgeting and funds management and defines the master data attributes for the lifecycle. Application can be created standalone or from application form based on web request process, which provides the user to gather information about the grantee and mainly used for eligibility assessment and calculating award amounts helping the potential grantee to receive information about the grantor program and apply for a grant.


Web Request is used in the creation of application will be based on request category, XML structure is defined in the configuration and is integrated with the BSP/Webdynpro UI. This will be displayed as a reference in the assignment block of the application and serves as a place to know the information provided by the grantee for the grant.


Design of the Grantor Application for Public Sector in CRM


Application like other business transactions consists of basic data at header and item like Status management to control the lifecycle, Organization management for sales and service org determination, Partner data for parties involved, apart from the one order framework components references to the form in an assignment block in case application is created based on the web request.


Program is linked to the header from which application inherits predefined data for ECC integration, linked document types for process, validity dates and funding rules.


Item list contains the payment type as a key and these are specific to grantor process which defines whether it is payment (GPOU), advance (GADV), repayment (GPIN) holdback (GHBK) associated with item category to distinguish one time, periodic, claim based or milestone payments. Expense types are used to define the expenses paid as part of the grant which is a subset of payment type. Billing request items are linked to each item which is integrated with ECC upon released status. Unlike other transactions there is no product associated in the item.


Pricing is determined based on payment types which fill requested amount, authorized amount and eligible amount in the application header and item data. Product like other business transaction is not associated with the pricing determination.


Funds pre commitment document is created in ERP as soon as application is created in CRM and updated each time application is saved unless controlled through status management.



Enhancements in creating an Application from Web Request


Web Request badi CRM_WEBREQ is triggered during the application form process –


  1. FORM_ON_CREATE is triggered when the
    application form process is started and used for verifications and defaulting
    the data.
  2. FORM_ONEVENT captures the event and
    communicates to grantor framework; SUBMIT event triggers the application
    creation process.




Grantor management transactions are different to other transactions in CRM, It follows one order framework and integrated with web request framework to leverage requirements of public sector management and can be integrated to PSCD or AR/AP in ECC.



Grantor Management provides a solution for providing financial assistance to Government organizations. Grantor supports end-to-end process of collecting data from grantee and disbursing funds based on rules. Key features of grantor process include Program management, Application, Assessment, Agreement, Change Request, Claims and Payments. Application and change request uses web request form to capture data specific to grantee. Application is generated from application form (web request) automatically, form can be filled either by an applicant externally or internally by a processor. As soon as application form is submitted the application is generated based on form data.


Web Request is a form based interface in CRM to support request of specific services in a web browser using internet. The requestor fills the data and submits back to the CRM system which generates a transaction with the attribute web request in the CRM system. The transaction related data is managed in the transaction and request-specific XML data is linked to the transaction as request.  XML data structure holds data throughout the session of the application form process which increases the performance of the application. Limitation of XML web request is on holding table data on the form, and the data will not be retained in stateless application. CRM should use shared memory or server cookies to store the data or implement enhancement to insert rows into XML data structure.


Web Request framework


Web request is configured in CRM->E-Commerce->E-Service->Web request-> Define Request categories. Under request category, data structure with fields used in the form will be defined. Request category implementation will be defined to link form values to one order object fields. Views on request category can be defined with BSP or ADOBE forms.  Link between the Request category and transaction type is defined in process assignment block of Program. Data stored in request category structure will be available throughout the process of capturing data from form until the creation of application.


Below diagram illustrates how the web request is called during runtime. HTML page built in the web browser is based on the HTML formatting defined in the BSP layout as well as the attributes of the input fields defined in the request data structure. The data on the request data structure is derived using the server page scripting. The relationship between an input field of the HTML layout and the field content is created through XPATH.


Implementation of CRM_SERVICE_WEBREQ badi plays a major role in data exchange during server events. To access and set the data in the XML structure in runtime, class CL_UXS_XML_SERVICES is used. Method GET_VALUE_VIA_XPATH is used to get data from the form fields and SET_VALUE_VIA_XPATH is used to set data to the form fields.


XML request data is stored in content repository. SAP presets the content category CRM_WEBREQ for web requests and corresponding content category CRM_WEBREQ in the SAP database.




Tables enhancement in Web Request


Standard grantor process doesn’t support tables in web request. Projects need tables on the form to capture multi line data.


1. Method changes for adding Tables to Web Request -

       a. Insert Path – A static method of class CL_UXS_XML_SERVICES=>XSLT_INSERT_PATH is enhanced to insert a new child node into the XML if a new

           line should be added.

       b. Delete Path –A static method of class CL_UXS_XML_SERVICES=>DELETE_ELEMENT_VIA_XPATH is needed to delete a node from the XML if a line   

           should be deleted.

       c. Reading lines on BSP Layout – Add the method GET_NUMBER_OF_LINES to class CL_UWS_FORM_RUNTIME_BSP_SCR.

2. BSP application changes –

       a. Create a page attribute index with type I.

       b. In Event handler add additional rows.

       c. Add/delete button to handle the event in layout.

          For rendering data on views include code changes in layout to get number of lines using           

          CL_UWS_FORM_RUNTIME_BSP_SCR=>GET_NUMBER_OF_LINES and getting data from request category structure.

3. BADI changes - To update data in tables implement the BADI CRM_SERVICE_WEBREQ, methods FORM_ON_CREATION, FORM_ON_INITIALIZATION, 





By including tables feature in web request, data stored in tables will be carried forward throughout the screens, and enhancements related to changing the form data from application life cycle will be minimized.


Filter Blog

By author:
By date:
By tag: