Siebel - Potential VPN Solution

1 Abstract 3
2 Potential solutions 4
2.1 Different VPN and VPN Item products & Agreement-Entitlement approach 4
2.1.1 Dual Billing – Several Billing Accounts 5
2.1.2 Dual Billing – Several Order Items with Billing Accounts 7
2.1.3 Dual billing resolution 7
2.2 Different VPN and VPN Item products plus Network approach 7
2.2.1 Dual Billing – Several Billing Accounts 9
2.2.2 Dual Billing – Several Order Items with Billing Accounts 9
3 Conclusion 9
3.1 Potential Risks 1 0
3.1.1 Ability of multi participating of given MSISDN in several VPNs 1 0
3.1.2 Ability of cross compound products validation 10
3.1.3 Potential user's experience complexity 10

Table/Diagrams
Table ‎2‑1: ERD of VPN-Agreement-Entiltlement solution. 4
Table ‎2‑2: ERD of appropriate Account entity instances and their relationships. 6
Table ‎2‑3: ERD of VPN - Network solution. 8
Table ‎2‑4: Schematic diagram of Compound product verification mechanism.. 9

1 Abstract
The main course of the document is analysis of possible solutions for a VPN implementation in Siebel environment, when emphasize is on full contiguity to a customer requirements:
* Root VPN
* VPN's line item
* Dual Billing[1]
* Appropriate pricing
* Activation ability[2]
* Participation to existed VPN ability[3]
* Inactivation ability[4]
* Elimination from existed VPN ability[5]
* Asynchronous processing support (order status)
The further analysis assumes the following assumptions:
* Root VPN is product[6]
* VPN's line item is product
* Dual Billing ability may be achieved by several different approaches
* Activation, participation, inactivation abilities are achieved by application's internal functionality
* Asynchronous processing achieved by application's internal functionality
Two different approaches are deliberated below, when the main difference is in a way of VPN items cross-relationship. Both of those approaches uses oob[7] entities and as consequence oob data model, the point is very important in matter of staying in oob data model and an ability of oob functionality usage at least as skeleton for different functional points.
2 Potential solutions
2.1 Different VPN and VPN Item products & Agreement-Entitlement approach
The following ERD diagram defines relationships between the following entities: Order, Order Items, Asset, Account, Agreement, Entitlement, and Product.
Table ‎2‑1: ERD of VPN-Agreement-Entiltlement solution

The main idea in this approach is consolidating VPN's line items by Agreement and Entitlement entities concept, when an Entitlement entity indirectly represents a VPN by related Asset/Product. Agreement entity represents a contract against some account and the entitlement represents its consequence (indirectly VPN). The approach allows easy population of appropriate fields in every order item by default values that potentially can come from previously defined and activated VPN[8], in addition the approach allows easy monitoring and as consequence validation of order, order item, asset statuses etc.
* Root VPN – treated by the order item in an order with root corporate account as service account, when as consequence of success during the activation process the VPN will be associated with an Agreement that has been previously set up and activated
* VPN's line item – treated by the order item in an order with root corporate or subscriber account as service account, when per each order item an Entitlement will represent the VPN in which the current VPN's line items has been participated
* Dual Billing[9] - treated by changing an billing account for an order
* Appropriate pricing – treated by usage of price list and different pricing mechanism assembled by Siebel Pricer
* Activation ability[10] - treated by usage of Action field at Order item's level and common order submission process
* Participation to existed VPN ability[11]- - treated by usage of Action field at Order item's level and common order submission process
* Inactivation ability[12] - treated by usage Asset's entity Modify functionality, Action field at Order item's level and common order submission process[13]
* Elimination from existed VPN ability[14] - treated by usage Asset's entity Modify functionality, Action field at Order item's level and common order submission process
* Asynchronous processing support (order status) – treated by several gate points for a process[15]
2.1.1 Dual Billing – Several Billing Accounts
The ability of "dual billing" may be provided by standard Siebel's data model but without the boundaries of oob application. The following ERD diagram shows related entities and their relationships.
Table ‎2‑2: ERD of appropriate Account entity instances and their relationships

The solution states that the new field underlied by Siebel's data model illustrated above will provide an ability of holding several Billing Accounts per each given Service Account. In each given Service Account there will be primary Billing Account (one of these who are connected to it through S_ORG_REL[16] intersection table).
The statement mentioned above supports an ability of multiple Billing Accounts per each VPN's line item[17].
2.1.1.1 Advantages
* Prevents possible mistakes in Billing Account pick up action by previously defined relationship[18]
* Allows unlimited number of Billing Account per each Order item, without any representative action
* Prevents undesired database growth[19]
* Efficient when allows selection of Billing Account just by choosing Service Account (functionality based on primary billing account field)
2.1.1.2 Disadvantages
* No presence of such a field in Siebel's oob application
2.1.2 Dual Billing – Several Order Items with Billing Accounts
The ability of "dual billing" may be provided by standard Siebel's data model within boundaries of oob application.
The case states that per each Billing Account, the new order item will be created. The diagram for this case is useless, because no relationships are used and there is simple field's population at the Order's line items level.
2.1.2.1 Advantages
* Supported by oob application
* Efficient when allows powerful restriction ability applied on retrieved record set
2.1.2.2 Disadvantages
* Causes to undesired additional step of Billing Account selection
* Causes to undesired multiplication of order items in order to achieve a multiple Billing Account
* Permits only hierarchical forward only search based on database foreign keys
2.1.3 Dual billing implementation proposition
Common solution must be considered. The solution states that the multi value field will be used by side with original Billing Account Is field, when the last one will represent a primary Billing Account among available Billing Accounts which are related to a given Service Account through described above S_ORG_REL intersection table.
2.2 Different VPN and VPN Item products plus Network approach
The following ERD diagram defines relationships between the following entities: Order, Order Items, Asset, and Product
Table ‎2‑3: ERD of VPN - Network solution

The main idea of the solution is simple classification of existed product by using Network Element Type field[20], in addition to the classification the Premises entity may be used in order to populate fields like CLLI[21], LATA[22] as consequence of Service Address field population at Order's line item level.
The main disadvantage of this approach is definition of network, node and connection as different products and as consequence undesired creation of order items that represents node products.
The mechanism allows usage of Compound products verification, as shown in following diagram.
Table ‎2‑4: Schematic diagram of Compound product verification mechanism

The Compound Product Validation Engine allows you to create rules that operate on a projected future state of a compound product that includes the current quote and any open orders on the existing assets. This future state is created and stored in the Projected Asset Cache object.
The Compound Product Validation Engine operates independently of a customizable product definition. Furthermore, the engine only validates the top level component and its immediate attributes. This point will affect modeling of Network products.
2.2.1 Dual Billing – Several Billing Accounts
The implementation the same as described in ‎2.1.1
2.2.2 Dual Billing – Several Order Items with Billing Accounts
The implementation the same as described in ‎2.1.2
3 Conclusion
As the preferred solution among described above is VPN & Agreement – Entitlement concept the following risks must be considered[23]
3.1 Potential Risks
3.1.1 Ability of multi participating of given MSISDN in several VPNs
The implementation of such ability is problematic due to the fact that the MSISDN is property of order item, when the last one represents VPN's line item and MSIDN may be activated at the same time only for one product instance (order item, asset).
3.1.2 Ability of cross compound products validation
The implementation of such ability is problematic due to indirect relationship between VPN and its participants[24].
3.1.3 Potential user's experience complexity

4 Indexes
Account, 2, 4, 6, 7
Agreement, 2, 4, 5, 10
Asset, 4, 5, 8, 9
Asynchronous, 3, 5
diagram, 2, 4, 6, 7, 8, 9
Dual Billing, 2, 3, 5, 6, 7, 9
Entitlement, 2, 4, 5, 10
ERD, 2, 4, 6, 8
functionality, 3, 5, 7, 10
intersection table, 6, 8
mechanism, 2, 5, 8, 9, 10
oob, 3, 6, 7
Order, 2, 4, 5, 7, 8, 9, 10
Order Items, 4, 8
Product, 4, 8, 9, 10
skeleton, 4
solution, 1, 2, 4, 6, 7, 8, 10
VPN, 1, 2, 3, 4, 5, 6, 8, 10

[1] An ability of dividing recurring charge between several associated accounts (billing accounts)
[2] An ability to activate a new VPN
[3] An ability to participate to previously defined/activated VPN
[4] An ability of VPN deactivation
[5] An ability of VPN's subscriber deletion
[6] There is ability in addition to regular definition create a network and define the root VPN as network compound product, see the following analysis
[7] Out of the box
[8] The values can be treated as properties or as attributes of order item
[9] An ability of dividing recurring charge between several associated accounts (billing accounts)
[10] An ability to activate a new VPN
[11] An ability to participate to previously defined/activated VPN
[12] An ability of VPN deactivation
[13] The main idea is definition and design of common submit process, that will be used by in every possible case
[14] An ability of VPN's subscriber deletion
[15] The Submit process potentially asynchronous one, the fact leads to a several possible gates to a process from different points.
[16] The intersection table of Account entity base table S_ORG_EXT
[17] The intention is for a multi value field usage, when in fact the field is only in business layer and its data retrieval underlied by Siebel's data model
[18] Actually there is no need for any interference, the Billing Account will be retrieved automatically just by previously defined Siebel's data model
[19] The growth occurs when billing account associated by foreign key with order item and order item must be multiplied in order to achieve a multiple billing account
[20] For further information look at Siebel Tools, Internal Product business component
[21] Common Language Location Identifier
[22] Local Access and Transport Area
[23] No technical risks (out of CRM) have been observed
[24] The functionality still can be achieved by using previously described Compound Product verification mechanism which is activated during Order verification process.