Oracle® Application Integration Architecture Oracle Communications Order to Cash Integration Pack Implementation Guide for Siebel CRM, Oracle Order and Service Management, and Oracle Billing and Revenue Management Release 11.2 Part Number E26501-02 |
|
|
PDF · Mobi · ePub |
This appendix describes three example scenarios for changing the paying parent on subordinate accounts.
This appendix contains the following sections:
Table E-1 provides descriptions for the abbreviations used in the example scenarios.
Abbreviation | Description |
---|---|
S |
Service |
SA |
Service Account |
BA |
Billing Account |
BG |
Balance Group |
BP |
Billing Profile |
DBP |
Dummy Bill Info |
Table E-2 is the base scenario.
Figure E-1 shows the scenario results after the order is processed to billing.
Table E-3 shows reparenting the subordinate to a different parent.
Table E-3 Reparenting subordinate to a different parent - Example 1
Action | # |
SA | BA | BP |
---|---|---|---|---|
UPD |
S1 |
SA1 |
BA2 |
BA2-BP2 |
UPD |
S2 |
SA1 |
BA2 |
BA2-BP2 |
This works even if S2 is not included on the order. However, to keep Siebel Customer Relationship Management (Siebel CRM) assets synchronized, S2 should also be updated. Or as shown in Table E-4.
Table E-4 Reparenting subordinate to a different parent - Example 2
Action | # |
SA | BA | BP |
---|---|---|---|---|
UPD |
S1 |
SA1 |
BA2 |
BA2-BP2 |
UPD |
S2 |
SA1 |
BA2 |
BA2-BP2 |
ADD |
S3 |
SA1 |
BA2 |
BA2-BP2 |
Figure E-2 shows the results for the preceding scenario.
Table E-5 is the base scenario:
A parent using different billing profiles to pay for their account and not each of the child accounts.
Note:
A parent cannot use multiple billing profile to pay for services of the same child account because the child account can have only one balance group, which can point to only one bill-info.
Action | # |
SA | BA | BP |
---|---|---|---|---|
ADD |
S1 |
BA1 |
BA1 |
BA1-BP1 |
ADD |
S2 |
SA1 |
BA1 |
BA1-BP2 |
ADD |
S3 |
SA2 |
BA1 |
BA1-BP3 |
Figure E-3 shows the scenario results after the order is processed to billing.:
Note:
The account-level balance group for the parent account (BA1) references the first billing profile that is created for that account. In the previous scenario it is BP1. If the ADD line for the service purchase for the parent account (BA1) is not the first line on the order, then the account-level balance group references billing profile BP2, and the purchase of S1 fails because it is using BP1.
Table E-6 shows that the change order is processed, which reparents both the subordinate accounts to a new parent, and the same billing profile under the new parent.
Table E-6 Change order processed
Action | # |
SA | BA | BP |
---|---|---|---|---|
UPDATE |
S1 |
SA1 |
BA2 |
BA2-BP4 |
UPDATE |
S2 |
SA2 |
BA2 |
BA2-BP4 |
Figure E-4 shows what is visible in Oracle Communications Billing and Revenue Management (Oracle BRM):
The repointing of the dummy bill-infos to the new billing profile is handled by the services that interface customer data to billing.
Alternates:
A variant in which two different billing profiles under BA2 are used to pay for the different child accounts is also supported.
A variant in which the billing profile changes but not the paying parent (such as in the base scenario, updating S3 to be paid for by BA1-BP2) is not supported. It fails in order billing integration because that involves repointing the balance group to a new dummy bill-info (pointing to BA1-BP2), which Oracle BRM does not allow.
Figure E-5 shows how S1 remains unchanged.
Table E-7 is the base scenario.
After customer sync, the integration creates two dummy bill-infos:
SA1-DBP1 pointing to BA1-BP1
SA1-DBP2 pointing to BA1-BP2
The default account-level balance group points to BA1-BP1. (It points to the billing profile referenced on the first line on the order).
However, depending on which lines are sent for processing, the order billing integration behaves in one of two ways:
Both service bundles are sent for order billing integration at the same time (In the same call):
Since out-of-the-box (OOTB), the integration supports a single balance group (and therefore only a single bill-info for a self-paying account), for a given service account, Oracle AIA uses billing account and billing profile on the first service bundle purchase for all the remaining service bundles in the incoming request. The data in Oracle BRM appears the same as the example shown in Figure E-6.
Even though this transaction is processed successfully it results in a mis-match between Siebel CRM assets and Oracle BRM in terms of the billing profile and bill-info used to pay for a given service. It is therefore recommended that if you are using OOTB functionality regarding balance group support, you ensure that orders in Siebel CRM follow the constraints (of single billing profile for a self-paying account).
The two service bundles are sent for order billing integration at different times (Different calls):
Irrespective of whether service bundle S1 is sent first or second, it is successfully processed. However order billing integration fails in attempting to re-point the default account-level balance group to SA1-DBP2 when purchasing service bundle S2.
Resubmit the order (using a revision), as shown in Table E-8.
Figure E-7 shows what occurs after the order is processed to billing.
You still have the hanging subordinate bill-info SA1-DBP2 that is not used by any service. It causes a problem in the future (customer sync fails; it has validation that finds that a dummy bill profile is not being reparented). If any attempts are made to reparent SA1, because no asset is using SA1-DBP2, it cannot be repointed as part of any reparenting operation.
Caution:
No automated workaround is available for this issue. You must manually move SA1 to be under the new parent (thereby repointing all the subordinate dummy bill-infos) and then process the order to have assets reflect the new state.