Author Archives: sbhansen

C4C Utilities – Creating the MDT for Guided Move-in

by ,

This is just a set of screenshots of the MDT used in the blog describing how to activate the BADI for calling your own MDT.

Any coding or configuration examples provided in this document are only examples and are NOT intended for use in a productive system. The example is only done to better explain and visualize the topic.

It is possible to create many variants, but this one was tested and does work, so maybe it can be used as a reference when creating your own.

HINT – the Contract Account node is made ‘Dynamic’. This is to enable that we only have one MDT defined for creating both the Business Partner and the Contract Account. In the situation where the Business Partner ‘Create’ is selected from step 1 in the guided move-in procedure, only data for the Business Partner is passed to the MDT. If the Contract Account was not defined as ‘Dynamic’ the MDT would fail and that case.

If you would like to avoid configuring the MDT as dynamic, it would be possible to choose different MDT’s in the BADI based on what data is passed to the MDT.

Below just screen shot of the MDT used for the Enhancement implementation in my earlier blog.

The template category selected is ‘NEWCUST’.


What is selected for the Business Partner node.



What is selected for the Address Independent node.


Business Partner Address node.


Contract Account node.



That is, it.


C4C Utilities – Activate BADI in Guided Procedure for Move-in

by ,

 

The objective here is to implement the BADI for the call to create Business Partner and Contract Account.

Any coding or configuration examples provided in this document are only examples and are NOT intended for use in a productive system. The example is only done to better explain and visualize the topic.

In general, all service calls have an associated Function Module in ERP, and they have a pre-BADI and a post-BADI, where it is possible to change data before processing, or change the data after processing before it is returned to C4C. For some of those there are also ‘skip’ flags – to suppress the execution of the standard logic completely and implement our own logic.

The function module used for creating the Business Partner and the Contract Account is COD_UTLITIES_MDT_MVI_CREATE.

 

Open the function module using transaction SE37 and double click on the ‘Call BADI line’.


 

In (1) is the name of the Enhancement Spot, and there is two methods available here (2). In order to implement the Enhancement Spot click on the small icon in the red box (3).

This will create an Enhancement Implementation.


 

In the pop-up enter the name and a short text for the enhancement implementation and then select OK (red arrow).


 

 

The enter BADI name, description and name of the Class where the implementation of the methods will take place. Select OK (red arrow).

 

 


 

 

Click on the ‘Implementation Class’ line.


 

 

Here we have the methods. Click on the ‘MDT_MVI_CREATE_PRE’ method.


 

 

It will ask for confirmation that we want to create the implementation. Select ‘Yes’.


 


 

The method comes up and the only thing for this example is that we set the MDT template name to ‘SBH_C4C_BPCA_1′. The variable x_prodid’ is the one holding the MDT name.

Then select activate.


 

This will provide all objects that needs activating. Select OK.


 

Now the implementation is active.


 

 

For this example, there is only logic needed for the pre-BADI – BUT – in order for the implementation to work the post-BADI have to be implemented as well.

 

Go to SE80 and select the class created – here ‘ZCL_BP_CA_CREATE1’. Click on the second method ‘MDT_MVI_CREATE_POST’.

 


 

 

Select ‘Yes’ to implement the method.

 


 

Then select ‘Activate’, and the implementation of the BADI is complete.


 

The function module will now call the pre-BADI. It will use the MDT(SBH_C4C_BPCA_1) passed by the BADI implementation for creating Business Partner and Contract Account.

 


 


 

Project Extensions for the Guided Move-in/out and transfer

by ,

We are here trying to show an example of how to add custom fields and additional logic to the guided move-in process. The logic added will include evaluation of fields added by the KUT (Key User Tools), so we will also see how to use those fields in the SDK.

Any coding or configuration examples provided in this document are only examples and are NOT intended for use in a productive system. The example is only done to better explain and visualize the topic.

With the 1702 release of Utility industry extension of C4C the guided process for move-in, move-out and transfer was introduced. While still being a web service call to IS-U, this is implemented using a business object (BO) in C4C as the ‘reference’. The name of the business objects is: UtilitiesActionBO. It is the same BO used for all of the processes and no data is materialized in C4C.

The technical benefit of using a BO, is that several of the standard SDK options becomes available, even though it still ends up as a web service call to IS-U.

In the following the examples will be based on the move-in.

Below is a short visual of the process. In short the 4 steps are:

  1. Selecting the premise, customer for and move-in date.
  2. Selecting what services that should be activated for the customer
  3. Selecting security deposit and possible mailing address if different from move-in address
  4. Review of all information entered for the prior steps

2 fields have already been added using the KUT:

  • A field for credit check required
  • Field to enter Social Security Number when creating a new customer

If you would like to see how this was performed – have a look at this blog: REFERENCE TO KUT BLOG

Below is the end result we are looking for – the ‘Credit Check Required’ is flagged.

We achieve this in 3 easy steps:

  1. Create a solution in PDI
  2. Make fields created by the KUT available for the PDI
  3. Write logic to control the field created by the KUT

1. Creating a solution in PDI

1.1. Login to the C4C system as PDI developer in the SDK studio. Create a new solution

1.2 Add new item to the solution “GAF Custom1”

2. Make fields created by the KUT available for the PDI

2.1. Right Click on the solution GAFCustom1 and Add New Item to include CustomerObjectReferences.

( Hint: CustomerObjectReferences is essential to access key user extension fields in the PDI custom logic )

2.2 Select Extension –> Reference to Customer Specific Fields and add CustomerObjectReference to the solution

2.3. Select key user fields which needs to be referenced in the SDK implementation.

In this example: Four fields in the Business Object UtilitiesActionBO is selected. We are only using one of the fields in this example, but these four are the ones created by the KUT.

Hint: Look at the node name – when we add this to the BO, we need to know where it belongs. In this case where we are adding the ‘Credit Check Required’ this needs to be added to the ‘Contract’ node. We will see this later.

2.4. Save and Activate the CustomerObjectReference in the solution.

3. Write logic to control the field created by the KUT

3.1 Add a new Item to the solution –> Business Object Extension ( ActionBOExtension.xbo)

3.2. Select namespace http://sap.com/xi/AP/CRM/Global and BO UtilitiesActionBO to extend the Business Object for Move In/MoveOut/Transfer GAF

3.3. Save and Activate the BO extension.

 

In this BO specific for Move In /MoveOut/Transfer Guided Process, the following nodes are extensible ( Contracts, Contract Account Details, Installation and Customer ) . New PDI extension fields, custom Bo action can be defined here.

3.4. Right Click on the ActionBOExtension.xbo and Create Script Files

3.5. Selecting Trigger Points

There are different trigger points to write the SDK logic. In this example , we will use the Event  “After Modify”  for Contracts Node to set the Credit Check Required field to true.

( Hint:  Please note to uncheck the mass enable check box for flat structure . If mass enable is checked then the input to the script files is a table and get row and get count needs to be used for accessing the data of every row. This can be avoided for flat data structures )

3.6 Add code to the event

In the  Event After Modify , Please insert the code to default Credit Check to true.

this.CreditCheckRequired = true;

One can access KUT field thru this.CreditCheckRequired as shown in the screenshot. This wouldn’t be possible if the Customer Object References is not created.

3.7. Launch the Move In Floorplan to see the results. Credit Check Required will be defaulted on Launch

SAP C4C– Simple Control of your screen with the Rule Editor

by ,

 

One of the newer features of the Key User Tool (KUT) in C4C is the rule editor.  The purpose of the rule editor is support the control of fields on the view based on simple configuration. The controls that are currently available:

  1. Display a field based on rules
  2. Make a  field Mandatory based on rules
  3. Make a  field ‘Read only’ based on rules

The rules are based on JavaScript, so if you are familiar with this then looking at the generated rule should be easy to understand.

The JavaScript code runes locally on the desktop, so performance should be good as it  is only limited to the performance of your computer. Another feature of this is that the rules will also work in off-line mode, as there are no communication to the backend.

Let’s look at an examples using each of the above rules.

 

We will create a rule that if the ABC Classification of a customer is ‘A’ – then we will make it possible for the agent to enter how the we can best reach the customer. On the screen below we have the ABC Classification and the ‘Best Reached By’ field displayed. Using the configuration we will hide ‘Best Reached By’ unless the ABC Classification is entered as ‘A’.

image

 

 

How are rules configured?

Configuration of the rule is done via adaptation mode.

 

image

 

 

In Adaptation mode, when hovering over a field, we have the option of adding a rule:

 

image

 

Clicking on the rule icon we get the option for providing a rule, here we select ‘Visible’.

 

image

 

For this case we will provide a rule for when this field will be visible. Only if the customer is classified as an ‘A-Account’ will we ask the agent for this information.  When clicking on the ‘Rule’ the editor screen will open:

 

image

 

1) Is where we enter the name of the rule

2) Here we have all fields available when creating the rule

3) These are all the operations that can be used in the rule

4) Here we will see the code being built for the rule

 

Please see this short video, where I show how to create the rule as well as seeing the result.

 

 

As seen by the video, it is a very simple process to add a rule.

 

One thing to keep in mind is, that while you can create a very complex rule, the only thing you can control are the 3 behaviors, Display, Mandatory and Read Only of a field.