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.

Aim of this blog is to promote the Interactive reporting functionality of CRM Analytics.



Interactive Reporting works in the following way:


First, the user should be a BP and proper org assignment must be done


The report displays only transactions that the current user has created. The user cannot see transactions from other users.


If the user is a manager, then they can see their transactions and the transactions created by their team.


Here, by transactions I mean documents and by user I mean the user executing the report.


Quota Planning


The quota planning page allows sales managers to define quota values for each quarter for directly assigned employees and organizational units. Sales managers can then define the quotas for the next lowest level and transfer the planning to the sales manager on the next lowest level of the organizational hierarchy. Sales managers can also plan quota at a detailed level, or set monthly quota distribution.

Sales quotas are shown as target lines in the following pages:

  • Target to Date
  • Closing Date
  • Sales Pipeline

The totals are calculated for the year.


Configuration for management


The Quota Planning is done in such a way that the quota for a particular organizational unit is set by the Manager who owns this
org unit.

The target value shows in "Target to Date" is the quota value set by higher manager and not the value accumulate from lower
org units.


Suppose there exist following org structure:


Org O1
      Manager M1
     Org O2
        Manager M2
Org O3
        Org 04


M1 and M2 are marked as "Head of own organisational unit" in PPOMA_CRM and they have the authorization to set quota value for their subsequent own org units.


If M1 set quota value for O2, this will appear as O2's target value, the quota value set by M2 (manager of O2) for O2's subsequent org unit
(O3 and O4) will sum up to the line "total" as the accumulate value.


If you logon system with M2, you will see the target value set by M1 shown in the first line of the quota planning form, also the "target"
value beside the chart.


To sum up, the target shown in the "Target To Date" is the quota set by the manager of the upper org unit.


Vikas Gautam

beginners blog to SAP CRM

Posted by Vikas Gautam Apr 16, 2013




SAP CRM Marketing: Campaign Management, Lead Management


SAP CRM Sales: Sales Planning, Sales Order Management:

                  Sales: Opportunity -> Inquiry/Quotation -> Contract -> Order 


SAP CRM Service: Service Order Management : Complaint -> Service Request


Advantages:   Improve customer service, Assess and motivate employees, Optimize Organization,

                      Reduced expenses,Effective processes, Improved turn-around-time.                       





1.   1. SAP CRM Marketing: The Marketing module helps you introduce a new product to existing and new customers and

        engage them through campaigns.

        After we identify a prospective customer (i.e. lead) group that would be interested in the product,

        we can automatically convert the prospect to an opportunity.

        We can use the Sales module to create the opportunity and generate a sales quotation for the customer.

        If the customer agrees with the quotation, we can then create a sales order.


1.   2.  SAP CRM Marketing: Using Segmentation tool, we can identify customers with similar interests and attributes

             and form customer segment groups or customer groups and the  process of grouping is known as Segmentation.

             for e.g. working class, students or retired people.

       With Segmentation  we can create more effective marketing campaigns and we can address

       the needs of customers better. It also helps in gathering data for analysis purpose.


3. SAP CRM Marketing: The Marketing programs, activities that are plan, run and tested to generate awareness

              among potential customers are defined as Campaigns. We can create campaigns to promote a product or

              service to your customers. These marketing activities include identifying customers, drafting the information

              we want to communicate and selecting the medium to transfer the information.

              We can run campaigns by using telephone, advertisements, e-mail or SMS.

        Apart from promotion of product,we also get feedback from customers.


4. Organizational Data: represents Internal view of organization

      As we have in ECC, Sales structure: Sales Organization, Distribution channel, division

      CRM side, we have Organization attributes:

      Sales Organization, Sales office, Sales Group, Service Organization

      General attributes:

      Country, Division, Distribution channel, Postal code, Region.




3.   5. Business Partner: contains relationship mapping:

  •   Employee, Vendor, Customer, associated parties 

  •   Can be an individual or organization

  •   Sold-to-party, Ship-to-party, Bill-to-party, Payer

  •   Contact Person, Employee/Personnel responsible or (Field Sales Representative).

  •   A Contact/Prospect may or may not be a Customer.

•       Picture3.png


4.    6. Territories:  Reflects Market View of an organization

  •  are defined w.r.to business unit, business partner, product, field sales representative, region, country

  •  Territory Management can be used to distribute or classify data correctly.

  •  Reporting is done on Customer/Product/Region.

  •  Reporting is also done on ORU/MRU(Organization reporting unit or Management reporting unit – structure or hierarchy).


7.  Master data: e.g.  

Organizational mapping data, Territory information, Region information , Business Partner Information, Material or Product, Address, Region

Territory(0CRM_TR), Business Partner(0BPARTNER), Business Partner: CRM Sales View (0CRM_BP_SAL),

Sales Office(0CRM_SALOFF or 0SALES_OFF), CRM Sales Group(0CRM_SALGRP), Region(0Region),

Organizational Unit(0ORG_UNIT or 0CRM_SALORG), Product(0CRM_PROD), Prospect(0CRM_PROSPE),

Origin Opportunity/Lead(0CRM_SOURCE).


Transaction data: e.g. Sales data, Stock data, Billing, Deliveries .



thanks & regards,




You might have picked up the news: SAP’s own CRM system now runs productively on the SAP HANA platform. In this blog, you will learn how SAP’s IT organization managed to migrate one of the world’s largest CRM systems to the SAP HANA platform in only 2.5 months. 


So how was this change managed? And what are the lessons learned? 


General Information

From a technical point of view, migration to the SAP HANA platform involves two steps:  Both of these steps are well-known SAP practice and both have to be performed on one cutover weekend. However, some special preparations are required.


Prerequisites and Preparation

Before making any significant system change, it is important to do your housekeeping thoroughly, such as re-enforcing your archiving system and deleting unnecessary data (for example, change documents). This will keep your system lean and reduces the migration downtime.
Based on test upgrades and migration rehearsals, you can figure out how to deal with the largest tables during the migration. The largest tables can be split during the export, which will significantly reduce the migration runtime. Testing is always very important, namely functional tests of the upgraded system, backup/restore tests, and failover tests of the SAP HANA high availability solution (depending on the SAP HANA hardware vendor). For the SAP HANA migration, you need to focus on load and performance testing. This allows you to optimize the system for SAP HANA before going live. Some tables  perform better in column or row store, and some expensive statements need to be optimized.
Finally, you should consider performing at least two rehearsals of the entire procedure before production cutover.

Production Cutover

The ramp-down procedure is a standard process: unscheduled long running jobs, block-out the end users, clean up queues, isolate the system, and finally shut down the system. Cutting the high availability cluster at this stage has some significant advantage: One side is used for the actual upgrade and migration while the other side remains original. This original system can be used as a quick failback in case something goes wrong. After successful migration, this original system can be used as a reference system (for audits, for example).
The next step is the “upgrade” installation of the EHP2 for SAP CRM 7.0 on SAP HANA (technical CRM 7.12 based on SAP NetWeaver 7.40). Since this is only a minor EHP upgrade, the EHP2 installation only took 3 hours.
The actual migration consists of a DB export followed by a SAP HANA 1.0 SP5 import (in the meanwhile export and import can run in parallel). Large tables are split during the export and cluster tables are de-clustered since SAP HANA does not support cluster tables. The export of 3 TB took us 7 hours, and the import to SAP HANA 12 hours including the declustering. During the migration runtime, the application servers can be upgraded for SAP HANA.
After successfully migrating, it is essential to carry out some checks to verify that all tables and rows have been migrated properly and the dictionary is consistent (package checker, table checker). It also makes sense to perform additional content checks for the most important data (such as your sales pipeline).  
The ramp-up requires minimal effort as there is hardly any post-processing. Before opening the system, a spot check allows you to check whether everything in the migrated system is correct. End users should be ramped up with the assistance of a support team.

Lessons Learned

The original row-compressed database size of 3 TB converts to 1.1 TB on SAP HANA. About 15,500 business users are supported, of which 5000 are “active” users with more than 400 steps each week. The entire OS/DB-migration project took 2.5 months.
Performance is key. Start early with load testing to optimize the performance. During testing, we found that SAP HANA is on average significant faster (search improved up to a factor of 250). However, some transactions should be optimized for the SAP HANA platform. During the first week of production with SAP HANA, it is advisable to have a support team of SAP HANA and SAP CRM experts to help fine-tune the system.
To conclude, the entire SAP HANA migration can easily be performed on a weekend. If this is not sufficient time, you should consider the nearly zero downtime option using SLT replication

References and Further Information


Best regards, Peter Boegler, Enterprise Architect and
Cutover Manager, SAP CRM on HANA

Preliminary note: this project was developed on SAP Netweaver 7.02 SP11 with GW 2.0 SP04 Developer edition available here... so actually there's no need for a CRM system to be able to play with it (despite the title of this blog), as soon as component WEBCUIF is present in your system.


If you do not know BMDG (Bol Master Data Generator) yet, you might want to take a look at the following links:

CRM7.01: what if you could create complex master data models in one click?

CRM7.01: bol master data generator

CRM7.01: secret weapon for data model creation


The great news it that, as of version 3.00, not only can the Bol Master Data Generator helps you create master data, but it can also change existing ones! Indeed you will now be granted the ability to change any kind of data by using bol query objects (or dynamic query objects) to retrieve what you need to modify. For more details about how it works you can check this video I created with an example based, as usual, on the FLIGHT model:



I will probably include one last thing to make it complete when time allows: a file upload functionality... I believe this will make it the perfect tool to manipulate master data: I know SAP delivered the Data Import Tool in CRM EhP2 for Utilities, but, unlike BMDG, it is sad to see that this standard solution is Industry-specific and I've been told that some coding is required to make it work for any kind of object...


So in case you're interested in saving a lot of time when creating/importing data into your system, feel free to join BMDG project on SAP code exchange.

SAP has been building and expanding its In-Memory application portfolio ever since the introduction of SAP HANA in 2008. SAP Global IT has been the partner for the internal HANA adoption starting day one. The internal adoption followed the four steps of product evolution since then. If you start your HANA roadmap today, you might start with any of these steps.


[picture: 4 phases]


First came the SAP HANA Accelerators. Accelerators were a perfect way to introduce SAP HANA into the market as they provided a quick and easy way to leverage in-memory technology to speed up existing reports in the SAP Business Suite. For SAP Global IT, this became a double starting point: The IT Application Services team made first consulting and project experience with the product SAP HANA. IT Infrastructure Services started to setup first HANA appliances for the business projects, as well as for an increasing demand within the SAP development organization.

Technically data was replicated out of the SAP Business Suite Database into SAP HANA, computations were then done inside the SAP HANA platform, and results were pushed back out into the SAP Business Suite. In this model, the casual user wouldn’t notice any difference in terms of functionality for user interface except for the fact that the reports came back at significantly improved speed. The SAP COPA Accelerator is an example of one of these HANA
Accelerators and has created a high business value for the controlling department.


[picture: SAP and HPI share the passion for Design Thinking to create business value]


It was time to make SAP HANA the primary data store for an application and SAP NetWeaver Business Warehouse was the perfect candidate. For the SAP internal adoption the New BI program built the framework (and created some confusion on customer side, if this might be a new product name) for the initial technical setup and identification of business value projects to showcase the new analytical possibilities. Deployment of Planning powered by SAP HANA, the infrastructure move to a scale-out architecture including high-availability and an alerting and monitoring with SAP Solution Manager have been subsequent steps. This system has been live for more than 12 months. The reduced data layer complexity, the minimal data latency time, and the much lower TCO (compared to run a BWA and a classic DB in parallel before) are still fascinating.


[picture: HANA Appliance Hardware]


SAP then started building new applications natively on top of the HANA platform. These applications all focused on helping companies leverage their growing data to solve specific business problems in ways that were not possible using existing technologies because of speed, cost and complexity related issues. These applications accelerated the adoption of the HANA platform by providing enterprises with very focused use cases to leverage In-Memory technology to harvest the power of their Big Data.

One of the most impressive internal examples is the Environmental Resource Management application build for SAP Global Facility Management, it is able to consume Smart Meter information from all SAP Office buildings every 15 minutes and able to provide operational transparency on real-time data and calculated information via SAP UI5 dashboards.


[picture: Oliver Bussmann announcing CRM on Hana go-live at CeBIT 2013]


SAP announced CRM on HANA at SAPPHIRE NOW Madrid. So, this was the next logical step for the SAP Runs SAP initiative. SAP Global IT in close collaboration with all other functions and teams migrated our business-critical CRM system to SAP CRM powered by SAP HANA through a project that was completed in record time, making us the first customer to go live with the new solution on March 5 (see announcement).

This is the voice of Robert Enslin, CRM user, president of Global Customer Operations, and member of Global Managing Board of SAP AG: “Real-time access to our customer pipeline allows us the ability to consistently analyze our business and know exactly where to focus additional resources and planning efforts. SAP Global Customer Operations is a vocal advocate of how SAP constantly delivers innovative business applications based on SAP HANA, in addition to serving as a highly-active internal customer. With the migration of our own CRM system to SAP CRM powered by SAP HANA, we now benefit from accelerating the solution non-disruptively and providing decision-making insights from the account level through senior management, anytime, anyplace.”


This is a great statement and a good reason to celebrate. So what’s next?


Expect a series of blogs and papers for our CRM on HANA project with details for project best practices, performance improvements,hardware setup and much more in the next weeks. Meet the SAP Runs SAP experts at the SAP Global IT booth at SAPPHIRE NOW in Orlando in May.


The internal HANA adoption program moves on full speed with further new applications, the SAP HANA Analytics Framework and – of course – ERP on HANA. This will be an exciting year!


Now available: The CRM on HANA Cookbook


Best regards,

Matthias Wild - proud to be part of SAP Global IT where SAP runs SAP.

Preliminary note: this project was developed on SAP Netweaver 7.02 SP11 with GW 2.0 SP04 Developer edition available here... so actually there's no need for a CRM system to be able to play with it (despite the title of this blog), as soon as component WEBCUIF is present in your system.


If you do not know BMDG (Bol Master Data Generator) yet, you might want to take a look at the following links:

CRM7.01: what if you could create complex master data models in one click?

CRM7.01: bol master data generator


To sum it up very quickly, it's a tool that allows me to create any kind of master data more easily than any other tool I had my hands on. And only too prerequisites are required:

1) The data to be created should exist as BOL object (ex.: "BuilHeader" for Business partner).

2) A "Template" describing how the bol objects will be created should be stored in a customizing view cluster.


When both prerequisites are met, it's only a matter of copy/paste to create any data model, as much complex as you like (see the video included in one of my previous blog post).


But: until now the "template" creation could be quite long depending on the number of objects to be created (ex.: 2 business partners with one sales order each), and the number of rules to be implemented (ex.: name of the second BP should be the same as the first BP + "_COPY" as suffix), etc.


I believe this period is over.

BMDG is now shipped with a complete WebUI application (component name is "ZBMDG_MAIN") that let's you:

  • Search for existing templates
  • Create new templates with a nice tree view where all parent/child relationships are determined automatically between bol objects
  • Edit templates
  • Delete templates
  • Copy existing templates
  • Execute templates to see the results
  • Etc.


So in case you're interested in saving a lot of time when creating/importing data into your system, feel free to join BMDG project on SAP code exchange.


Here are a few short videos showing how it works:


In a previous blog I http://scn.sap.com/community/crm/blog/2013/02/07/crmorderread-simple-example-for-those-new-to-crm-andor-abap gave a very simple example of how to read an order using CRM_ORDER_READ.


Then in another blog I explained how to UPDATE an order: http://scn.sap.com/community/crm/blog/2013/02/07/crmordermaintain-simple-example-to-update-an-order-for-those-new-to-crm-andor-abap
Now I’ll give a simple example of how to create an order using CRM_ORDER_MAINTAIN.


This blog will show you how to CREATE an order from scratch using ABAP.
I’ve tried to make this as simple as possible but while including the most important (useful) information.
For this example I will create an order with two tables populated: orderadm_h and opport_h (which signifies that this is an OPPORTUNITY that I’m creating)


include crm_object_names_con.
*      All the tables to be created
  lt_orderadm_h      type  crmt_orderadm_h_comt,
  ls_orderadm_h      type  crmt_orderadm_h_com,
  lt_opport_h        type crmt_opport_h_comt,
  ls_opport_h        type line of crmt_opport_h_comt,
* Other important things
  lt_input_fields    type  crmt_input_field_tab,
  ls_input_fields    type  crmt_input_field,
  lt_nametab         type  crmt_input_field_names_tab,
  ls_nametab         type  crmt_input_field_names,
  lt_save_guid       type  crmt_object_guid_tab,
  ls_save_guid       type  crmt_object_guid,
  lt_saved_objects   type  crmt_return_objects,
  ls_saved_objects   type  crmt_return_objects_struc,
  lv_lin             type   i,
  lv_order_object_id type  crmt_object_id,
  lv_order_object_guid  type  crmt_object_guid32.
* Calculate the “handle” that will join all these attributes together 
  call function 'CRM_INTLAY_GET_HANDLE'
      ev_handle = ls_input_fields-ref_handle.
* 1. Populate orderadm_h with the process type and description
  ls_orderadm_h-handle       = ls_input_fields-ref_handle.
  ls_orderadm_h-process_type = ‘process type string’.
  ls_orderadm_h-description = ‘this is a description’.
  ls_orderadm_h-mode         = 'A'.
  append ls_orderadm_h to lt_orderadm_h.
* 2. Prepare table first. 
* The lines you enter into table lt_nametab MUST be entered (appended) 
* in alphabetical order, as lt_nametab is sorted.
* See here that the 3 entried are the three attributes you populated in ls_orderadm_h above.
  ls_nametab = 'DESCRIPTION'.
  append ls_nametab to lt_nametab.
  ls_nametab = 'MODE'.
  append ls_nametab to lt_nametab.
  ls_nametab = 'PROCESS_TYPE'.
  append ls_nametab to lt_nametab.
* 3. Populate lt_input_fields now 
* You need to add this table that you want to create to the input fields.
  ls_input_fields-ref_kind = 'A'.
  ls_input_fields-objectname = 'ORDERADM_H'.
  ls_input_fields-field_names[] = lt_nametab[].
  insert ls_input_fields into table lt_input_fields.
* 4. Prepare the next table you want to create for this opportunity: opport_h
  clear: ls_nametab, lt_nametab[].
* 5. Populate ls_opport_h with appropriate values (see examples or attributes to populate)
  ls_opport_h-ref_handle      = ls_input_fields-ref_handle.
  ls_opport_h-exp_revenue     = iv_expt_sales.
  ls_opport_h-startdate       = iv_sc_sdate.
  ls_opport_h-expect_end      = iv_sc_cdate.
  ls_opport_h-curr_phase      = iv_sales_stage.
  ls_opport_h-probability     = iv_chanceofsuc.
  ls_opport_h-source          = iv_origin.
  ls_opport_h-type            = iv_serv_line.
  ls_opport_h-mode          = 'A'.
  append ls_opport_h to lt_opport_h.
* 6. Prepare the lt_nametab table – remember to be alphabetical again!
  ls_nametab = 'CURR_PHASE'.
  append ls_nametab to lt_nametab.
  ls_nametab = 'EXPECT_END'.
  append ls_nametab to lt_nametab.
  ls_nametab = 'EXP_REVENUE'.
  append ls_nametab to lt_nametab.
  ls_nametab = 'MODE'.
  append ls_nametab to lt_nametab.
  ls_nametab = 'PROBABILITY'.
  append ls_nametab to lt_nametab.
  ls_nametab = 'SOURCE'.
  append ls_nametab to lt_nametab.
  ls_nametab = 'STARTDATE'.
  append ls_nametab to lt_nametab.
  ls_nametab = 'TYPE'.
  append ls_nametab to lt_nametab.
* 7. Add to lt_input fields the new table you want to create.
  ls_input_fields-ref_kind = 'A'.
  ls_input_fields-objectname = 'OPPORT_H'.
  ls_input_fields-field_names[] = lt_nametab[].
  insert ls_input_fields into table lt_input_fields.
* 8. You’re ready to call crm_order_maintain now
call function 'CRM_ORDER_MAINTAIN'
        it_opport_h       = lt_opport_h
        ct_orderadm_h     = lt_orderadm_h
        ct_input_fields   = lt_input_fields
        error_occurred    = 1
        document_locked   = 2
        no_change_allowed = 3
        no_authority      = 4
        others            = 5. 
* 9. Read the table that has been changed and get the GUID that was created.
case sy-subrc.
      when '0'.
        read table lt_orderadm_h into ls_orderadm_h index 1.
        ls_save_guid = ls_orderadm_h-guid.
        append ls_save_guid to lt_save_guid.
* 10. SAVE the changes (all creations must be saved and committed before they exist in CRM)
    call function 'CRM_ORDER_SAVE'
        it_objects_to_save = lt_save_guid
        et_saved_objects   = lt_saved_objects
        document_not_saved = 1
        others             = 2.
    case sy-subrc.
      when '0'.
        clear lv_lin.
        describe table lt_saved_objects lines lv_lin.
        if lv_lin = 1.
          read table lt_saved_objects into ls_saved_objects index 1.
          lv_order_object_guid = ls_saved_objects-guid.
          lv_order_object_id   = ls_saved_objects-object_id.
* 11. Call the function to COMMIT the changes to CRM.
          call function 'BAPI_TRANSACTION_COMMIT'.
*Your new opportunity will now exist in CRM – use CRM_ORDER_READ to read it, using its GUID

In a previous blog http://scn.sap.com/community/crm/blog/2013/02/07/crmorderread-simple-example-for-those-new-to-crm-andor-abap I gave a very simple example of how to use CRM_ORDER_MAINTAIN to create a new order.


This blog will show you how to UPDATE an order in CRM using ABAP.
I’ve tried to make this as simple as possible but while including the most important (useful) information.
In this example I will only update the orderadm and opport (opportunity) tables.


include crm_object_names_con.
  lt_opport_h        type crmt_opport_h_comt,
  ls_opport_h        type line of crmt_opport_h_comt,
  lt_orderadm_h      type  crmt_orderadm_h_comt,
  ls_orderadm_h      type  crmt_orderadm_h_com,
*Other important things
   lt_input_fields    type  crmt_input_field_tab,
   ls_input_fields    type  crmt_input_field,
   lt_nametab         type  crmt_input_field_names_tab,
   ls_nametab         type  crmt_input_field_names,
   lt_save_guid       type  crmt_object_guid_tab,
   ls_save_guid       type  crmt_object_guid,
   lt_saved_objects   type  crmt_return_objects,
   ls_saved_objects   type  crmt_return_objects_struc,
   lv_lin             type   i,
   lv_order_object_id type  crmt_object_id,
   lv_order_object_guid  type  crmt_object_guid32.
* 1. Update the description of the opportunity
clear: ls_nametab, lt_nametab[],
    ls_orderadm_h-description                = ‘this is the new description’.
    ls_nametab                               = 'DESCRIPTION'.
    append ls_nametab to lt_nametab.
*** for help on how to change a CHAR32 to a RAW16 see my CRM_ORDER_READ blog ***
    ls_orderadm_h-guid                    = ‘this is the GUID type RAW16’.
    append ls_orderadm_h to lt_orderadm_h.
    ls_input_fields-ref_kind = 'A'. 
    ls_input_fields-ref_guid = ‘this is the GUID again, in RAW16’. 
    ls_input_fields-objectname = 'ORDERADM_H'.
    ls_input_fields-field_names[] = lt_nametab[].
    insert ls_input_fields into table lt_input_fields.
* 2. Update the opportunity data in opport_h table – update the current phase and end date
  clear: ls_nametab, lt_nametab[], ls_input_fields.
    ls_opport_h-curr_phase                 = ‘code for new sales stage’.
    ls_nametab               = 'CURR_PHASE'.
    append ls_nametab to lt_nametab.
    ls_opport_h-expect_end                  = ‘new date for expected end date’.
    ls_nametab              = 'EXPECT_END'.
    append ls_nametab to lt_nametab.
ls_opport_h-ref_guid                    = ‘this is the GUID again, in RAW16’.
    append ls_opport_h to lt_opport_h.
    ls_input_fields-ref_guid        = ‘this is the GUID again, in RAW16’.
    ls_input_fields-ref_kind        = 'A'.
    ls_input_fields-objectname      = 'OPPORT_H'.
    ls_input_fields-field_names[]   = lt_nametab[].
    insert ls_input_fields into table lt_input_fields.
* 3. DONE, call CRM_ORDER_MAINTAIN on this information
call function 'CRM_ORDER_MAINTAIN'
        it_opport_h       = lt_opport_h
        et_exception      = lt_exception1
        ct_orderadm_h     = lt_orderadm_h
        ct_input_fields   = lt_input_fields
        error_occurred    = 1
        document_locked   = 2
        no_change_allowed = 3
        no_authority      = 4
        others            = 5.
    case sy-subrc.
      when 0.
        ls_save_guid = iv_guid.
        append ls_save_guid to lt_save_guid.
* 4. SAVE the changes (all updates must be saved and committed before they change in CRM)
    call function 'CRM_ORDER_SAVE'
        it_objects_to_save = lt_save_guid
        et_saved_objects   = lt_saved_objects
        document_not_saved = 1
        others             = 2.
    case sy-subrc.
      when '0'.
        clear lv_lin.
        describe table lt_saved_objects lines lv_lin.
        if lv_lin = 1.
          read table lt_saved_objects into ls_saved_objects index 1.
          lv_order_object_guid = ls_saved_objects-guid.
          lv_order_object_id   = ls_saved_objects-object_id.
* 5. Call the function to COMMIT the changes to CRM.
          call function 'BAPI_TRANSACTION_COMMIT'.
*DONE, your opportunity has now been updated.

When I first started writing ABAP in CRM I was confronted with CRM_ORDER_READ and CRM_ORDER_MAINTAIN, and learning how to use these took much longer that it should have due to lack of simple examples available. Looking back I don’t know where my confusion lay (it’s really simple!) but I know there was confusion and trouble, so I will try to be provide help to others that I wish I’d had.


The aim of this blog is to create a simple example for CRM_ORDER_READ and then I will write another blog for CRM_ORDER_MAINTAIN.

This blog will show you how to read an order, and read details about it such as and Notes, and Partners associated, the Status and all the other basic information.



include crm_object_names_con.
          lt_header_guids type crmt_object_guid_tab,
          ls_header_guids type crmt_object_guid,
          lt_orderadm_h type crmt_orderadm_h_wrkt,
          lt_opport_h type crmt_opport_h_wrkt,
          lt_status type crmt_status_wrkt,
          lt_text type crmt_text_wrkt,
          lt_partner type crmt_partner_external_wrkt,
          lt_service_os type crmt_srv_osset_wrkt,
          ls_orderadm_h like line of lt_orderadm_h,
          ls_opport_h like line of lt_opport_h,
          ls_status like line of lt_status,
          ls_text like line of lt_text,
          ls_partner like line of lt_partner,
          ls_service_os like line of lt_service_os,
          lt_request_objs type crmt_object_name_tab.
* 1. First you need to choose which tables you want to get back. 
* In this example I want to read 6 tables, so I need to add them into the “request_objs” table
  insert gc_object_name-orderadm_h into table lt_request_objs.
  insert gc_object_name-opport_h into table lt_request_objs.
  insert gc_object_name-status into table lt_request_objs.
  insert gc_object_name-texts into table lt_request_objs.
  insert gc_object_name-partner into table lt_request_objs.
  insert gc_object_name-service_os into table lt_request_objs.
* 2. Second you need to make a table “lt_header_guids” with all the guids in that you want to read
* These GUIDs are stored as RAW16 type, in the table, 
* so you may need to convert them from CHAR32
data: lv_guid_char type char32.
lv_guid_char = ’#32 char long GUID#’.
ls_header_guids = cl_ibase_service=>cl_convert_guid_32_16( lv_guid_char ).
append ls_header_guids to lt_header_guid.
*3. You’re now read to read! It’s that simple!
call function 'CRM_ORDER_READ'
      it_header_guid       = lt_header_guids
      it_requested_objects = lt_request_objs
      iv_no_auth_check     = 'X'
      et_orderadm_h        = lt_orderadm_h
      et_opport_h             = lt_opport_h
      et_text                     = lt_text
      et_partner                = lt_partner
      et_service_os          = lt_service_os
      et_status                  = lt_status
      document_not_found   = 1
      error_occurred       = 2
      document_locked      = 3
      no_change_authority  = 4
      no_display_authority = 5
      no_change_allowed    = 6.
* sy-subrc = 0 if the read was successful. 
* If the read wasn’t it can mean that the GUID you entered isn’t valid/doesn’t exist.

For help with crm_order_maintain see: http://scn.sap.com/community/crm/blog/2013/02/07/crmordermaintain-simple-example-to-create-an-order-for-those-new-to-crm-andor-abap



Preliminary note: this project was developed on SAP Netweaver 7.02 SP11 with GW 2.0 SP04 Developer edition available here... so actually there's no need for a CRM system to be able to play with it (despite the title of this blog), as soon as component WEBCUIF is present in your system.


Last year I wrote a blog post about a project that I created on code exchange: BMDG -- Bol Master Data Generator. It's a tool that allows me to create any kind of bol object. All I have to do is fill-in a customizing view with the expected rules: for example, if I need to create a business partner whose first name and last name are constant values together with address fields determined at runtime via importing parameters, I can do so by creating the corresponding "template", and then call BMDG with the template ID.

For more information kindly check the following links:

CRM7.01: what if you could create complex master data models in one click?

CRM7.01: secret weapon for data model creation


However, until now I was only providing the "engine". In other words, if you ever wanted to use BMDG you had to develop your own program and copy/paste the lines of code at the end of my previous blog post to make it work. And even if it represents only 7 lines of code, it was fair enough not to consider BMDG "plug-and-play".


Then last week a friend of mine asked me if I knew a tool to copy/paste marketing plans from Excel inside SAP CRM... I got no clue, but this rang a bell about BMDG: this tool is fully generic so any kind of bol object can be created with it. Also, as of SAP Netweaver 7.01 or 7.02, you can now copy/paste your data from Excel inside any WebUI table. Why not combine both worlds to be able to generate any data model out of a simple table view where users could paste values coming from flat files or Excel?


Sounded like something interesting to me. So I created a WebUI component, that is now shipped with BDMG (together with sample templates based on SFLIGHT model), to unveil the potential of this tool and finally make it "plug-and-play" compliant. Here is how it works:

1) Start WebUI component ZBMDG_UI:


2) Then select a template from the dropdown list:

Only those templates that contain values to be determined at runtime from an importing structure are displayed -- which means that if you created templates where all bol objects' attributes are filled-in with constant values for example, they won't be displayed in the list. As soon as a template is selected, the table is re-arranged automatically, so that you can now enter the values you need, or copy/paste them from Excel:



3) Click the "Import" button:

BMDG will run through each and every line of the table, to create the objects as per the corresponding template (of course there can be more than one object created per line depending on how the template has been customized). Once done, the result status is displayed in the first column, and you can click on the icon to display the complete log:



Here is a short video to show BMDG WebUI component in action:



If you're interested, feel free to join the project on code exchange, make comments, discuss about new features that could be implemented, and of course download everything free of charge:

BOL Master Data Generator

As a functional consultant, you probably write functional specifications now and then. Even though the SAP CRM solution offers many ways to customize processes, some enhancements are needed to fulfill the few business requirements that cannot be met by standard functionality. With help of business add-ins or the possibilty to link your own function modules in customizing, SAP CRM can of course also cater for that. But SAP CRM cannot ensure that these enhancements are built in a future-proof way.


Only too often I encounter developments that contain hardcoded values or that apply to the system as a whole. Before we go over the most important options to overcome this in more detail, let's first quickly look at the disadvantages a customer might encounter if enhancements are built in a rigid or hardcoded way. Examples of disadvantages are:


  • A change in customizing requires a change in coding
  • If new business units want to use the system, but do not want your specific enhancement,  a change in that coding is needed
  • Once-built logic tends to be forgotten, leading to additional costs when extending or upgrading the system later


So, how can we ensure that enhancements are controllable functionally? With this blog I aim to shed some light on the little-known yet highly powerful parameter options that are standard available in SAP CRM.



Parameters can be used to steer logic: programmers can check the value of a parameter before apart of the logic is processed. A parameter can be a simple on/off switch or it can contain a value that would be hard-coded otherwise.


Available parameter types


User parameters


If you want certain logic to be only available to certain users, this is the way to go. You can setup additional parameters to your own liking



Possible to switch on/off or adapt the logic on the lowest possible level: the user. More work to setup and maintain though.



You can create your own user parameters via SM30 in table TPARA. From then, you can set the value for a user through SU3 (your own user) or SU01 (any user).

0113-SU3_1.JPG 0113-SU3_2.JPG


What to put in the specification?

From the coding, the parameters and values of a user can be retrieved. Values are stored in table USR05.


Organizational attributes


You want certain logic, that might be executed in the background, only to apply to (e.g.) certain sales organizations.



Can be setup on high level and then inherited to the lowest, where it can be overwritten if wanted. Downside is that the organizational model should be maintained for this.



You setup your own attributes in table T77OMATTR through SM30. First enter your new attribute (see screenshot). If you enter a description and hit enter, the table and field names are defaulted (SAP delivers a standard table in which all these attributes are saved).


You then link the attribute to the scenario (Sales, Service, or Marketing) and to the object type (for instance O for Organizational Units). You can even setup inheritance from higher- to lower-level objects. This way can you also setup attributes for positions and have those defaulted from the sales organization to which they belong, and overwrite the value if needed. The new attribute is then available in the list of attributes.


What to put in the specification?

You can add the hint to use function module RH_OM_ATTRIBUTES_READ to retrieve all attributes, including your own (if maintained, of course).



WebUI parameters


Your end users work through the webUI and you would like specific logic to apply only to certain business roles.



You can assign parameter values to (big) groups of users rightaway. Needs to be customized and transported though, and only suitable for processes running or initiated in the webUI.



Parameters can be created through customizing (IMG > CRM > UI Framework > Technical Role Definition > Define Parameter). You assign the parameters and their values to a parameter profile. This profile can then be linked to one or more business roles as a function profile (ID = PARAMETERS, vallue = the parameter profile).




What to put in the specification?

There are standard possibilities to retrieve the business role that the user is logged on for.


Other parameters

Besides the parameter types discussed above, you can also think of other parameters in the system. Example include marketing attributes (freely definable fields in the account), and container parameters in action definitions (more information about actions can be found in my blogs). These will not be described in this blog.


Own table(s)


If you have more complex requirements, it can be an option to define your own 'customizing' table. Many customers have one in which they can dynamically add parameters to their coding.



Much more 'steering' possibilities, but has the risk of being hard to understand.



Often, these tables are really 'for insiders only', and you know what tends to happen with insiders: they leave the company, forget they ever built it, whatever... The best structure I've seen was a combination of two tables: one in which the link between the object (FM/report/class, for instance) and the parameter was given, and another table with the actual parameters and their values. All programmers were required to use the first table to retrieve the parameter, and this ensured the tables were filled correctly. This enables every new kid to quickly see where what parameters are used.


Which to pick, and how to use them?


Which option you decide to use for the enhancement that you want to have built depends on how you want to limit the logic now, or in the future. The more the SAP CRM solution is used, the more these parameter options will be used. As a company, you should consider setting up guidelines for projects and changes to only build enhancmenets using the parameter options you have chosen based on your company's roadmap (think of: future roll-outs or additional functionalities). By using these parameters in a wise and consequent way, companies can benefit from the enhancement possibilities SAP CRM offers without having the risk that they cannot be managed anymore.


Filter Blog

By author:
By date:
By tag: