Skip to end of metadata
Go to start of metadata

Owner Allocation Process in SAP CRM 7.0 

Applies to:

SAP CRM 7.0

Summary

Owner Allocation process provides an automated means of placing the service into the landlord/owners name between tenants.  The “Owner” is the Business Partner linked to the premise. In the current system, the Property object is the object used to link an owner/landlord to a premise. This wiki basically supports Call Center Users to create multiple allocations.

Author(s):  

   
Company:     Deloitte
Created on:    01/24/2012
Author(s) Bio

I am Saurabh Garg working with Deloitte Gurgaon as SAP CRM Technical Consultant having close to 5 years of experience. 
Table of Contents1           Introduction.
2           Owner Allocation Process in CRM 7.0.
3           CRM Views for Owner Allocation Process.
3.1        Search and Confirm Business Partner View.
3.1.1     Search Business Partner View
3.1.2     Business Partner Hit List View.
3.2        Owner Allocation Maintenance Views
3.2.1     Launch Owner Allocation Maintenance Process.
3.2.2     List Properties / Select for Premise View.
3.2.3     Technical Approach
3.2.4     Select Premise/s and Duration View
3.2.5     Design Considerations
3.2.6     Exception Handling.

1               Introduction

Owner Allocation process provides an automated means of placing the service into the landlord/owners name between tenants.  The “Owner” is the Business Partner linked to the premise. In the current system, the Property object is the object used to link an owner/landlord to a premise. This development basically supports Call Center Users to create multiple allocations.

A Property is an SAP object created in order to provide time dependent maintenance of the owner and installation. A Property will be created for each premise that the owner requests an Agreement be established for.  Each Property will have a contract account specified and this contract account will be used each time the owner is moved into the specified premise.  This way the owner’s contract accounts and contracts, will be more easily managed.  A key date field is also provided for selection according to time related validity. 

The business requirement is to have the ability to create, transfer ownership from one BP to another, reverse or update multiple properties on Owner Allocation without having to enroll each property separately.  Large apartment complexes typically enroll on this program. 

Current system does not have the ability to create or update owner allocation records related to multiple premises. Users can only create / update a single owner allocation record at a time. Additionally, system currently does not warn the user that there is an existing owner allocation. This is a significant pain point in the current system as owner allocation records are often created for multiple premises. These functionalities do exist in ECC-Utilities, but we are providing a front end to IC WEB Client for performing the operations effectively.

The owner allocation process in CRM 7.0 will be enhanced to support creation, changes and reversals of owner allocations to multiple premises. This document presents the CRM 7.0 user interface design to support this process. The views necessary to complete the owner allocation process in CRM 7.0 will be custom developed.

In As-Is environment, user enter the transaction codes as

ES51                      Owner Allocation Create

ES52                      Owner Allocation Change

ES53                      Owner Allocation Display

ES54                      Owner Allocation Reverse

In the redesign to Web Client 7.0, user will be able to get all the screens in a single view from navigation.

2              Owner Allocation Process in CRM 7.0

Documented in this section is a high level description of how the owner allocation process will work in CRM 7.0.

The process for maintaining owner allocation in CRM is the same for single as well as multiple properties.

1              CRM Views for Owner Allocation Process

It should be noted that the user interface design and screen flows presented in this section are actual screens to help understand how the owner allocation process will work in CRM 7.0.

The enhancement is to create a new custom view to perform Owner allocation from the front end SAP CRM Web UI 7.0, which was previously done from transactions ES51, ES52, ES53 and ES54. The scope of this enhancement is limited to search, create, and transfer and reversal of property records only and displaying them in the web UI.

In order to improve the Current Occupant process, an enhancement was done in order to

Create a custom view to accommodate single or multiple property searches in relation to Current Occupant accounts. This view will provide users the ability to search for all owner allocation properties associated with the confirmed Business Partner, and to search for additional owner allocation properties using a Premise Address or a Business Partner Number. This enhancement will also provide a check for call centre agents and roles using the Owner Allocation Maintenance. This check will essentially force users to confirm the business partner before maintaining the owner allocation.

Eventually, Background creation of Business Agreement is also a part of this document. After searching the premises for confirmed BP, it deals with property records creation and updating.

The process of owner allocation maintenance starts with the display of search results from the query generated from Property search.Current Owner will be filtered to records with an End Date of 12/31/9999. This covers situations where there is a pending ownership change by showing the newest owner. A new View for result needs to be created.This view will be used for create, transfer, reverse and update the owner allocation in relation to the earlier confirmed BP.

1.1       Search and Confirm Business Partner View

1.1.1      Search Business Partner View

The first step in the owner allocation maintenance process is to identify and confirm the business partner in question. Even in the case of transferring ownership from business partner “A” to business partner “B” for a given range of properties, business partner “B” has to be searched and confirmed in the system. If business partner “B” does not exist in the system, a new business partner “B” must be created and confirmed before proceeding onto the owner allocation maintenance process.

Business Partner Hit List View:-

 
 
It should be noted that the BP search and hit list shown above will be configured based on the user interface requirements provided in the CRM Searching workshop. Therefore, the views that each user group will see when searching and confirm a BP will be different based on their requirements.

1.1       Owner Allocation Maintenance Views

1.1.1      Launch Owner Allocation Maintenance Process

After the business partner is confirmed, the owner allocation maintenance process can be launched from the navigation bar as shown in the mock up below. Clicking on this “Owner Allocation Maintenance” work centre will open a premise search view.

If the ‘Owner Allocation Maintenance’ work centre is invoked without confirming a business partner, system will display an error message in the messages areas. A business partner must be confirmed to perform owner allocation maintenance.

 
 
1.1.1     List Properties / Select for Premise View

Search using Premise Address

 
 
Search using BP Number
 

 

  • The search view shown above provides the ability to list all properties for the confirmed BP or search for properties using a premise address or a BP number.
  • The functionality to list all properties for the confirmed BP is useful if the customer is calling about maintenance of his existing properties.
  • The search view will dynamically display field/s related to the BP number search or Premise search based on the radio button selected as shown in the mock up views above.
  • Street and City fields will be mandatory to perform a search using premise address so the search is always efficient.
  • The BP number search will bring up all premises currently owned by the BP input in the search criteria and not the confirmed BP. To display properties for the confirmed BP, the user simply needs to hit the ‘List All Properties’ button. The search help (F4 function) is supported for the BP number search. This search can be useful if properties currently owned by one BP needs to be transferred to another BP. It should be noted that only one of the two search options can be used (either a premise address search or a BP number search).
  • System will perform owner allocation maintenance functions such as create or reverse or update for the confirmed business partner

1.1.1   Technical Approach

For creating the BP and Premise Search screens first we need to create 2 structures, 1 for Search and 1 for Result.

 Search Structure

 

Result Structure 


 
Then, we need to create an entry in SPRO for SEARCH and RESULT genil component. But prior to that we create a custom search implementation class inherited from 

(CL_CRM_GENIL_ABSTR_COMPONENT) in SE24 ZCL_FO_PROP_SEARCH_QUERY.

 
 
Moreover we also need to create a custom implementation class for root object and search result object.
 

SPRO:-

 
 
Also we need to add the above created genil component in IUICALL component set.

 
 
Then we hit transaction SM30 and maintain view CRMVC_IUIL_OBJPR for the above created genil component ZFOPRP.

 
 
And we also maintain view CRMVC_IUIL_RELDE for the above created BOL objects. So that we identify as to for the SEARCH BOL Object what will be the SEARCH RESULT Object.

 
 
Eventually when you hit transaction genil_model_browser u will see the below screen:-
 

 

  1. In transaction bsp_wd_cmpwb create a component ZFOPROP_SEARCH for owner allocation SEARCH and RESULT view and add the Model as IUICALL since we added the genil component ZFOPRP in IUICALL component set.
  2. Make an inbound plug IP_DEAFULT in the Main Window and create a target id in spro for creating the work center Owner Allocation and navigating to the Property Search View.
  3. In the Inbound Plug IP_DEFAULT check whether user has confirmed a BP or not and if not then populate the error message.
  4. Then create a custom controller and create 2 context node in it 1 for Search and 1 for Result.
  5. Then create a view set in which we will add 2 View Areas one for Search and another for Result.
  6. Also redefine the .htm of MAINVS view to show both the views accordingly and also add the MAINVS to the Main Window in Runtime Repository.
  7. Then create a result view  and create 2 context node in it. One named as SHUFFLER and another as SEARCHRESULT. SHUFFLER will be a value node containing a field Category on the basis of which we will differentiate whether user is searching for BP or for Premise.Also Bind the SEARCHRESULT context node with the custom controller.
  8. Then create the last view in the component  and create 3 context node i.e. SEARCH, SHUFFLER, SEARCHRESULT and redefine the DO_INIT_CONTEXT method to create an empty entity for SEARCH. Also bind the Result context node with the custom controller. Create 2 methods EH_ONSEARCH and EH_ONCLEAR which will respectively be triggered when user clicks on SEARCH or CLEAR button.
     
     
    1.1.1    Select Premise/s and Duration View
     
    System will perform owner allocation maintenance functions such as create or reverse or update for the confirmed business partner. As shown in the mock up above, the premise address, the current owner's (if any) name, the current tenant’s name, created on (start dates of the owner allocation record if any), and the ability to set the valid dates (all year - winter only) will be shown for the returned premises.  Current Owner will be filtered to records with an End Date of 12/31/9999. This covers situations where there is a pending ownership change by showing the newest owner.

Owner Allocation maintenance actions (Create, Reverse or Update) will be performed against rows with a selection.

Immediate Updates

  • All new property assignments (CREATE), reversals and updates will take place "online" with the result shown in the UI.
  • i.e. The new property owner and the user/date from the update will be shown against each premise that was assigned.
  • Example: The initial search results may present more properties than the user actually needs to maintain. After the maintenance is done, the "confirmation" view could include only the properties which were selected for maintenance. An icon (Pass/Fail) may be displayed against each row with specific error messages stored in the message area when appropriate. All records with an error will be sorted to display at the top.
  • Update confirmation will be provided with the specific details.
  • Creation of a Business Agreement will take place at the same time as the Property record.

Create/Transfer Allocation:- After selecting the premises to be changed, the user can create or transfer the allocation. Creating an allocation happens if there is no owner present for the selected premises. The blank field in the owner column of the search result view will be replaced by the confirmed BP. The landlord/owner (Confirmed BP) will be moved into the premise upon the creation of a new Owner Allocation record, according to the validity dates identified (i.e. all year or winter only). On selecting Create, system will create an owner allocation record with a start date in the time slice of today’s date with an end date of 12-31-9999 for selected rows. CREATE is invalid if a selection is already assigned to the same BP. Upon creating a new Owner Allocation record a seasonality indicator must default to 'all year' with the option to select 'winter only' (i.e. Nov 1 - Mar 31).

In case the owner field is not blank, a transfer will take place which will replace the current owner with the confirmed BP. In the back ground the move out of current owner will take place and at the same time move in for the confirmed BP will take place. When the Create button is hit for a premise with an existing owner, system will transfer the ownership of the selected premise to the business partner confirmed.  Transfer will end the owner allocation (Owner A) time slice as of yesterday’s date and begin the owner allocation (Confirmed BP) time slice as of today and an end date of 12-31-9999.  In a transfer, the outgoing owner should be moved out of any property where they are also the tenant and there is no pending move-in, though Move in and Move out are not a part of this enhancement, they will be a part of background updates.

While creating and transferring of Owner Allocation, user must be given the flexibility to change the start date of owner allocation, the best design is to provide the date field input help In the mailing address popup screen. One start date field for adding the owner allocation must be added in the Mailing address popup window from where the user should be able to select the start date of owner allocation, the date should be defaulted to today’s date. We call FM BAPI_ISUACCOUNT_CREATEFROMDATA, at first to create the business agreement for the BP and Premise chosen, then for creating the property object we use FM BAPI_ISUPROP_CREATEFROMDATA.



 
Update Seasonality:- After selecting the premises to be changed, the user can update the seasonality to either ‘All year’ or ‘winter’ for each selected premise individually. This is the only editable field in the owner allocation view. While creation of a new Owner allocation where property is new or there is no owner and a CURRENT OCCUPANT, a seasonality indicator field should show up with ‘all year’ as the defaulting value and ‘winter only’ as other value option available. While update functionality does require “Fixed mailing address” popup, where user can fix the mailing address. After mailing address fix, user must be taken to confirmation view. We call FM BAPI_ISUPROP_CHANGE for making changes to the property object.

Reverse Allocation:- Reverse allocation function will be triggered when user clicks the reverse button. This will end the current owner allocation for the selected premises. Reverse will perform no other function. We call an RFC FM Z_REVERSE_PROPERTY which reverses the property. In the ECC FM we call FM BAPI_ISUPROP_CANCEL and pass the Property Number in to the FM and the property gets reversed and we call the confirmation view as shown in the below screen.

 
 
Business Agreement:- Application should create a new business agreement (in the background)  for every new Owner Allocation enrolment with appropriate (determined by the system) default values for Contract Account category and Account Determination ID. The contract account should be created in ECC the same way as it is being created in As-Is system.

Confirmation View:- The initial search results may present more properties than the user actually needs to maintain. After the maintenance is done, the new "confirmation" view should include only the properties which were selected for maintenance. A new column should be added to this view which heads as Pass/Fail. An icon (Pass/Fail) will be displayed against each row with specific error messages displayed in the message area. All records with an error will be sorted to display at the top in the message area. The new property owner and the user/date from the update will be shown against each premise. The three buttons for Create, Reverse and Update will be disabled. An ‘OK’ Button will be available to navigate user back to property search screen.

Background Updates

  • Secondary updates will occur in background (i.e. workflow) as appropriate.
  • Move Out will be triggered where the previous property owner is the occupant for the premise. This indirectly transfers occupancy to the new property owner.
  • Move Out will be triggered where the premise is occupied by CURRENT OCCUPANT. This indirectly transfers occupancy to the new property owner.
  • Premises occupied by a tenant will require no action beyond the online creation of a Property record and Owner Business Agreement. These will be the case for approx 85-90% of the cases.
  • If no pending Move Out exists, a workflow is triggered for the premise/installations. Any workflow errors will be resolved using the existing support process.
  • The entire list of background updates will be initially passed to ECC as one unit of work to be split later. Each "list" of entries will be time stamped for processing in the order received.
  • A new process will check the "list" and determine which premises require a Move Out.
  • Properties which do require a Move Out will be checked to see if a pending (future) Move Out already exists for the premise.



 

  1. Go to the Genil Class ZCL_FO_PROP_SEARCH_QUERY and redefine the methods GET_OBJECTS, MODIFY_OBJECTS and LOCK_OBJECTS and GET_QUERY_RESULT for implementing the BOL object ZPropRT. In the method LOCK_OBJECTS, call the FM Z_OPEN_PROPERTY to create a lock on a property in ECC.
  2. Go to Search Result view; create an event handler for the event ‘CREATE’. In method EH_ONCREATE, open the address view as a popup.
  3. Go to Search Result view; create an event handler for the event ‘REVERSE’. In method EH_ONREVERSE, call the FM in ECC to reverse a property.
  4. Go to Search Result view; create an event handler for the event ‘UPDATE’. In method EH_ONUPDATE, create an event handler for method UPD_ADDR_CLOSE. In the event UPD_ADDR_CLOSE call the FM to update the seasonality of the property in ECC
  5. Go to Search Result view, Context Node SEARCHRESULT,  method EH_ON_ROW_SELECTION implement the code to lock  a row when a row is selected and unlock a row when the row is deselected.
  6. In the component ZFOPROP_SEARCH, create a new table view ZAddressPopup with context node ZADDRESS. The context node ZADDRESS should be a value node with structure BAPIBUS1006_ADDRESS. Also create a new value node ADDITIONALDATA with one attribute i.e. STRTDATE. Now do .htm changes in the view to display the Start Date field on the Address Popup.
  7. Go to Address Popup View, Context Node ZADDRESS, method IF_BSP_MODEL~INIT, calls FM to get the addresses of the confirmed BP from ECC and populate them in the Select address Popup table view.
  8. Go to Address Popup View; create an event handler for the OK button. In method EH_ONOK, gets the address number corresponding to the address selected by the user on the Select Address popup.
  9. Go to Search Result view; create an event handler for the event ADDR_POPUP_CLOSED. In the method EH_ONADDR_POPUP_CLOSED, call the FM in ECC to create/transfer properties. The FM creates a contract account and a property in case of Create Scenario. In Transfer scenario, it reverses the old property before creating a new contract account and the new property. The contract account will be created with the confirmed BP and user selected address as mailing address. The property will be created with the selected premise and the confirmed BP.
  10. In the component ZFOPROP_SEARCH, create a new table view ZPropertyLog with context node ZPROPCREATELOG. The context node ZPROPCREATELOG should be a value node with structure ZSFO_PROPERTY_UPDATE_LOG.
  11. Go to Property Log View create an inbound plug FROMSEARCHRESULTLIST. In the method IP_FROMSEARCHRESULTLIST, get the results of property create/transfer process and set the context node ZPROPCREATELOG. Depending upon the results of the property create/transfer process, create suitable message and add them to the message container.
  12. Go to Property Log View; create an event handler for the OK button. In method EH_ONOK, navigate back to the search result view.
  13. Go to Search Result, Context Node SEARCHRESULT, Method DESTROY, implement the logic to delete all the created locks in ECC for the selected rows in the property search result list.
  14. Go to Search view, view controller create method UNLOCK_LOCKED_ROWS and implement the logic to delete all the locks in ECC for all the selected rows in the property search result.
  15. Go to Search view, view controller, call the method UNLOCK_LOCKED_ROWS in event handlers EH_ONSEARCH, EH_ONCLEAR and EH_ONCATEGORY_CHANGED to delete all the locks in ECC for all the selected rows in the property search result.

1.1.1   Design Considerations

The following are some key considerations for the owner allocation maintenance process in CRM 7.0.

  • Actions such as Create, Update or Reverse are performed only against rows with a selection
  • On selecting Create, system will create an owner allocation record with a start date in the time slice of today’s date with an end date of 12-31-9999 for selected rows. CREATE is invalid if a selection is already assigned to the same BP.
  • The Create button will also handle Transfer of ownership if there is an existing owner. When the Create button is selected for a premise with an existing owner, system will transfer the ownership of the selected premise to the business partner confirmed.
  • Transfer will end the owner allocation (Owner A) time slice as of yesterday’s date and begin the owner allocation (Owner B) time slice as of today and an end date of 12-31-9999.  In a transfer, the outgoing owner will be moved out of any property where they are also the tenant and there is no pending move-in.
  • Reverse will end the owner allocation as of today in the time slice range of the owner allocation record. Reverse will have no other secondary action.
  • "Seasonality" is required for all selected rows. All Year option will be defaulted. However, an ability to set winter only will also be provided.
  • The only fields updatable on an existing owner allocation record are the seasonality periods.
  • The business agreement (contract account) with appropriate account class and account determination ID will be created in the background for any new property assignments.
  • System will update the Interaction Record upon completion of the owner allocation maintenance process. This record will include all relevant details of the owner allocation maintenance that was performed as part of that interaction.

1.1.6    Exception Handling

The following are some examples of when exceptions could occur and how they will be handled in CRM 7.0.

  • For property updates where the previous property owner or the current occupant need to be Moved Out, if there is a scheduled Move Out date for the premise, the Move Out will not be attempted. These will be identified and reported (excel) to the Call Center via email.
    • i.e. "Previous Owner Move Out was not processed due to a Pending Move In"
    • i.e. "Current Occupant Move Out was not processed due to a Pending Move In"
    • A system message will be displayed in the messages area for an invalid row selection in the Premise selection screen. The message will read ‘BP “ABC” is already an owner for the property “xyz”’.
    • Specific error messages with all relevant details of any records that had an error during the online property update process will be stored in the message area when appropriate.
    • For items that are still in process, a status of “pending” in the created by field will be displayed and these rows will be unavailable for selection as shown in the mock up above. This is to avoid creation of duplicates.
    • One exception report per day (versus one per submission) will be generated and emailed to a PO Box as business requirements. This exception report will include the following:
      • Any pending Move Out that exist for the properties that were maintained
      • Any records that had an error during the online property update process.
        $generalUtil.escapeXMLCharacters($body)