18 Understanding the Process Integration for Customer Management

About Account Status Synchronization

You can synchronize account status changes from Siebel CRM to BRM. Account status synchronization enhances the process integration for collections management, which is delivered by the Agent Assisted Billing Care pre-built integration. Oracle recommends that you enable account status synchronization only if you are also using the process integration for collections management.

The Agent Assisted Billing Care pre-built integration synchronizes collections actions generated by BRM as credit alerts in Siebel CRM, where a CSR can take actions on the customer's account such as suspending or canceling services.

You can suspend or cancel services with change orders that are either manually submitted by a CSR or automatically generated based on credit alerts. extend Siebel CRM to automatically generate change orders based on credit alerts. Using change orders ensure that service state changes are synchronized from Siebel CRM to BRM.

If you must inactivate a customer account due to continued delinquency, enabling account status synchronization ensures that account status change in Siebel CRM is synchronized to BRM.

Synchronizing account status to BRM is disabled by default. You can enable it by changing the value of the EnableAccountStatusSync property in the AIAConfigurationProperties.xml file. See "Configuring the Process Integration for Customer Management" for more information.

When inactivating accounts in Siebel CRM, Oracle recommends the following:

• Inactivate accounts in Siebel CRM only after canceling all the services and account-level subscription products for that account in Siebel CRM. When you inactivate an account in Siebel CRM, the status change is immediately synchronized to BRM. BRM cascades status changes from the account to all of its /billinfo objects, so the services and products in BRM are cancelled as well. If you inactivate the account before cancelling the services and products in Siebel CRM, they continue to appear active in Siebel CRM even after BRM cancels them.

• To avoid inadvertent inactivation of accounts with active services, Oracle recommends restricting the ability to inactivate accounts to particular Siebel CRM users and roles. Siebel CRM does not let you restrict account status changes in other ways.

See Oracle Application Integration Architecture Siebel CRM Integration Pack for Oracle Communications Billing and Revenue Management: Agent Assisted Billing Care Implementation Guide for more information about the process integration for collections management.

Synchronizing Hierarchies for New Corporate Accounts

To synchronize account hierarchies for new corporate accounts, submit an order from the customer account for the service accounts in the account hierarchy. The integration synchronizes the account hierarchy of only the accounts included on the order, not those in the entire account hierarchy.

For example, assume you create the corporate account hierarchy in Siebel CRM or the OSM account repository shown in Figure 18-3. You then submit an order for Amelia's account from the corporate account, as shown in Table 18-2.

The integration retrieves the linear hierarchy for Amelia's account and creates hierarchical account groups for each account in BRM. Acme Networks' group includes the accounting department as a child, the accounting department's group includes the marketing department as a child, and the marketing department's group includes Amelia as a child. Likewise, each group includes an association with its parent account. Amelia's group includes the marketing department as a parent, the marketing departments group includes the accounting department as a parent, and the accounting department's group includes Acme Networks as a parent.

The integration does not create hierarchical account groups for the other accounts from the account hierarchy until you submit orders for those accounts.

You can create an account hierarchy using a combination of new accounts and existing accounts but you must always submit an order to synchronize any new accounts.

For example, using the corporate account hierarchy in Figure 18-3 again, after submitting the order in Table 18-2, you create a service account for Jacob and set the parent on Jacob's account to the marketing department. To synchronize this addition to the hierarchy, you must submit an order that includes Jacob's account. When you submit the order, the integration creates a hierarchical account group for Jacob with the marketing department as a parent. It also adds Jacob as a child in the marketing department's hierarchical group.

Synchronizing Hierarchies for Existing Corporate Accounts

You synchronize account hierarchies for existing corporate accounts by setting the parent on the accounts in Siebel CRM.

The integration synchronizes the immediate parent and child in the Siebel CRM account hierarchy of only the accounts that you update, not those in the entire hierarchy.

For example, assume you have already created accounts and submitted orders for Acme Networks, the accounting department, the IT department, and Jennifer, but no hierarchical relationship exists between them. To create the corporate account hierarchy shown in Figure 18-3:

1. Set Jennifer's parent to the IT department account.

   Siebel CRM initiates the Update Customer Account integration flow and the integration creates hierarchical account groups for Jennifer and the IT department.

2. Set the IT department's parent to the accounting department.

   Siebel CRM initiates the Update Customer Account integration flow and the integration creates a hierarchical account group for the accounting department, and updates the hierarchical account group for the IT department.

3. Set the accounting department's parent to Acme Networks.

   Siebel CRM initiates the Update Customer Account integration flow and the integration creates a hierarchical account group for Acme Networks, and updates the hierarchical account group for the accounting department.

For more information about hierarchical account groups in BRM, see BRM Managing Accounts Receivable.

Adding Accounts to Existing Corporate Account Hierarchies

To add an account to an existing corporate account hierarchy, set the parent of the account you are adding to the account immediately above it in the hierarchy, and change the parent of any accounts immediately below it in the hierarchy.

For example, the integration has already synchronized the account hierarchy shown in Figure 18-4 to BRM, and Acme Networks wants to add Charles' manager Jennifer and his coworker Lily to the hierarchy. Jennifer's account has already been synchronized to BRM, but Lily's account is new.

Figure 18-4 Example Corporate Account Hierarchy Updates: Base Hierarchy

Description of ''Figure 18-4 Example Corporate Account Hierarchy Updates: Base Hierarchy''

To add Jennifer and Lily's accounts to the hierarchy:

1. Set Jennifer's parent to the IT department account.

   The integration creates a hierarchical account group for Jennifer and updates the hierarchical account group for the IT department using the Update Customer Account integration flow.

2. Set Charles' parent to Jennifer's account.

   The integration updates the hierarchical account groups for Jennifer, Charles, and the IT department using the Update Customer Account integration flow.

3. Set Lily's parent to Jennifer's account.

4. Submit an order from Acme Networks for Jennifer with the accounting department as the billing account.

   The integration creates a hierarchical account group for Lily using the Create/Sync Customer Account integration flow and updates the hierarchical account group for Jennifer using the Update Customer Account integration flow.

Figure 18-5 shows the new account hierarchy.

Figure 18-5 Example Corporate Account Hierarchy: Added Accounts

Description of ''Figure 18-5 Example Corporate Account Hierarchy: Added Accounts''

Removing Accounts from Corporate Account Hierarchies

To remove an account from a corporate account hierarchy, remove the value of the parent of the account, leaving it blank. If you want to keep any accounts under the account you are removing in the hierarchy, change the parent on those accounts to the parent account one level above the account you are removing.

For example, Jennifer leaves Acme Networks. To remove Jennifer from the hierarchy shown in Figure 18-5, while keeping Charles and Lily in the hierarchy, set the parents on the accounts as follows:

1. Set Charles and Lily's parent to the IT department account.

2. Set Jennifer's parent to no parent, removing the IT department account.

   The integration updates the hierarchical account groups for Charles, Lily, Jennifer, and the IT department using the Update Customer Account integration flow.

If you simply remove Jennifer's parent, Charles and Lily remain under Jennifer and are no longer part of the corporate hierarchy under Acme Networks.

Moving Accounts to Different Corporate Account Hierarchies

To move an account to a different corporate account hierarchy, change the parent on the account you want to move.

For example, beginning with the account hierarchy in Figure 18-5, Jennifer, Charles, and Lily transfer to the marketing department, which is a sibling of the IT department in the corporate account hierarchy under Acme Networks. To move their accounts to the new hierarchy, set Jennifer's parent to the marketing department account. The integration updates the hierarchical account groups for Jennifer, the IT department, and the marketing department using the Update Customer Account integration flow. Because hierarchical account groups only track the immediate parent, and Charles and Lily remain under Jennifer, the integration does not need to update Charles and Lily's groups.

To move only Jennifer's account, set Jennifer's parent to the marketing department account and set Charles and Lily's parents to the IT department account.

If you move an account to a place in the hierarchy under a new billing account, the integration transfers the services to the new billing account and updates the billing hierarchy. It does not remove the original account from the billing hierarchy. In BRM, you must either remove it manually or suppress this relationship in reports.

Example of Legal Hierarchies

Table 18-3 shows an example order line that would create a collections sharing group. In the example, Helen is a minor who wants to pay for her own mobile service. Her mother, Lisa, is an existing customer with her primary billing profile set to LisaBP. Lisa agrees to be the legal owner of Helen's charges.

To create the hierarchy, you set the parent on Helen's account to Lisa's account and submit an order including the account details shown in Table 18-3.

The integration creates Helen's account and the associated HelenBP billing profile. Because the integration detects that the billing account and owner account on the order line are different, it then creates a collections sharing group in BRM. The collections sharing group consists of the /billinfo created for LisaBP as the parent and the /billinfo created for HelenBP as a child.

You could also include a service for Lisa's son Alex on the same order, as shown in Table 18-4.

In this order, the integration would include the /billinfo created for both AlexBP and HelenBP as members of LisaBP's collections sharing group.

You must ensure that any subsequent services for Helen and Alex also specify Lisa as the owner account.

For more information about collections sharing groups, see BRM Collections Manager.

Adding New Members to Legal Hierarchies

You can add new members to existing legal hierarchies using new accounts or existing accounts. In the order capture and account management applications, there is no difference between creating and synchronizing a hierarchy for the first time and adding a new member to an existing hierarchy. In both cases, you submit an order where the billing account and owner or customer account on the order lines are different.

After creating any new accounts on the order, the integration calls the PCM_OP_COLLECTIONS_GROUP_ADD_MEMBER opcode. This opcode adds the /billinfo for the billing profile on the order line as a member of the collections sharing group that belongs to the /billinfo of the primary billing profile on the owner or customer account.

Changing the Legal Owner of a Child Account

To change the legal owner of a child account:

1. Change the parent on the child account in the Siebel CRM hierarchy.

2. Submit a change order for the services in the child account that includes the new parent as the owner account on the order lines and order header.

For example, after you have submitted the order shown in Table 18-3, Helen's father, David, offers to be the legal owner of her charges. To make this change, you change the parent on Helen's account to David's account and submit a change order with the account details shown in Table 18-5.

Siebel CRM includes both the old and new owner accounts on the order.

The integration does the following:

1. Removes the /billinfo for HelenBP from Lisa's collections sharing group.

2. Deletes Lisa's collections sharing group.

   The integration deletes the collections sharing group only if Helen was the only member. If the collections sharing group has other members, the integration does not delete the group.

3. Creates a collections sharing group with David as the owner and the /billinfo for HelenBP as a member.

   The integration creates a new collections sharing group only if David is not already the owner of a collections sharing group. If David is already the owner of a collections sharing group, the /billinfo for HelenBP is added as a member of the existing group.

Removing the Legal Owner from a Child Account

To remove the legal owner of a child account, submit a change order for the services in the child account that includes the child account as the owner account.

You are not required to change the account hierarchy in Siebel CRM.

For example, Helen reaches the age of majority and can be held legally responsible for her bills. To mark this change in BRM, you submit a change order based on the order in Table 18-5 with the account details shown in Table 18-6.

The integration does one of the following:

• If Helen is the only member of David's collections sharing group, the integration deletes the entire group.

• If Helen is not the only member of David's collections sharing group, the integration removes her from the group.