Relationships define the migration paths that are valid between different Plans in a Plan Family. Creating these relationships allows you to have a fine level of control over which types of migration path are allowed. For example, you may only want to provide valid upgrade and downgrade paths, but no frequency change paths.
Each relationship is uniquely defined by the following:
- Source Plan and frequency
- Destination Plan and frequency
For each migration path you want to support, you will need to define a Relationship. For example, for a Family with two Plans each with a monthly and yearly frequency, you would need to define 8 different Relationships to provide a complete migration map if you want to support all possible combinations.
When you click the Relationships button on a Plan Family, you will see the Relationships grid.
- Click Rules to go directly to the Rules configuration for an existing Relationship (step 2 of the wizard described below).
- Click Edit to edit an existing Relationship. You will be taken to the Relationship wizard as described below. Note that you cannot change the source and destination plan of an existing relationship; you must remove it and create a new one.
- Click Remove to remove an existing Relationship. New migrations will no longer be able to use this path.
Click Create Relationship to create a new migration path between two plan-frequencies (a combination of a plan and a frequency that uniquely identifies the source and the destination). The Create Relationship wizard is displayed.
In Step 1, you will choose the following:
|Source Plan Frequency||The plan and frequency that this migration path will apply to.|
|Destination Plan Frequency||The plan and frequency that the source plan will move to when a migration occurs.|
You can specify one of 5 different options to allow you to categorize the relationship and the migration for reporting purposes. Keep in mind that the system cannot automatically tell whether a migration path results in additional charges (which could be an "upgrade") or a reversal of charges or reduction in services (which would be a "downgrade"), nor can it necessarily differentiate these from other types of migration. Therefore, you can control this by choosing one of these types which can then later be used in reporting.
The supported migration types are:
|Pre-Existing Subscription Financials||
This option controls what will happen with unearned portions of the source subscription. From an accounting point of view, the source subscription's earnings must be accounted for properly and the destination subscription's earnings will then begin as of the date of the migration.
Note that the Relationship will inherit the default setting that you configured on the Plan Family which helps to enforce consistent accounting across the entire family. You can, however, override it for an individual Relationship if you wish.
|Subscription Level Field Mappings||
This section allows you to define the default behavior for these fields when a migration occurs. Each of these fields can be automatically transferred over to the new subscription or not, depending on your choices. By default, these settings inherit the configuration that you provided when you created the Plan Family.
If you choose "Family Default" as the setting, then the Relationship will always inherit the Family's default, and will change if the Family's default changes. Otherwise, you can choose "Transfer" or "Do Not Transfer" to override them at the Relationship level here.
Click Next to move to Step 2 of the wizard, where you will define the Rules that govern what happens to each of the individual Products in the Plans when the migration occurs.
When you create a new Relationship, Stax Bill will automatically attempt to map Products with the same Product Code between the Source and Destination plans and set up default Rules for them. If a Source Plan product has no equivalent in the Destination Plan (as with the Free Trial product above), then there will be no default mapping.
- To map a source product to a different product in the destination plan, click Change. The existing product mapping will be replaced by a dropdown selection of all available (unmapped) products in the Destination Plan. Choose one of the other products in the dropdown or click Cancel to leave the product unmapped.
You can remove one or more mappings by checking the boxes at the left of the grid and clicking Remove Mapping. This will leave all selected products unmapped.
What does "Unmapped" Mean? What happens to source products that are not mapped to any destination products? Essentially, they are treated as if they are "cancelled" or "expired" in the old subscription when a migration occurs, and the new products in the destination plan are configured as if they were brand new. For example, an unmapped usage meter would simply have its usage removed from the system and the new usage meter in the destination plan would start from zero. No transfer of data would happen between the source and destination products in this case.
In many cases, there will be products in the source plan that do not appear in the destination plan, and vice versa. For instance, there could be a "Premium Support" option that is included in the Silver Plan but is not available to Bronze Plan customers. All of this is handled by configuring the mappings correctly for each scenario.
- Click Rules to view and manage the individual settings that govern what will happen when the source product is moved to the destination product.
The Display settings indicate whether or not to transfer the product's Name and Description overrides to the new product or not. Unless you commonly override product names, you may want to choose "Do not transfer" for these settings so that the Destination product names are used in the new subscription.
The Quantity section governs how quantities are transferred between the products. These settings should be carefully set to ensure that quantities and charges are managed properly.
Use Source Value - the destination product will be included if the mapped source product was included; otherwise it will be excluded.
Use Catalog Settings - the destination product will inherit its inclusion settings from its Plan template. For example, if the Plan sets the destination product to "Included by default", then the destination product will have this setting.
Include Product - the destination product will be included regardless of the source plan setting.
Exclude Product - the destination product will be excluded regardless of the source plan setting.
Transfer - moves the source subscription product's current quantity to the destination product's quantity. If both products are using tracked items, these will automatically be transferred as well. (See "Important Notes" below for additional information.)
Do not transfer - the destination product's quantity will be given its default/start quantity, as set in the Catalog.
Important Notes about Quantity Transfers!
Quantities can be tricky to move between two Products that are configured differently. Generally speaking, if both products have no restrictions on them, then there should be an exact match between the source and destination after the migration. However, there are some special cases where this will not happen:
|Source quantity is "open" but Destination quantity is "fixed"||
The Destination quantity will always be set to its Fixed value, regardless of the Source product's value.
|Source's quantity is greater than the Destination's maximum quantity||The Destination quantity will be set to its maximum, regardless of the Source product's value.|
|Tracked item quantity in Source is greater than a fixed or max tracked item quantity in Destination||
If the Destination product has a fixed or max quantity and the Source has more quantity than will fit into the limits, AND the product is tracking items, then only the first [n] tracked items will be transferred, where [n] is either the fixed or max quantity of the Destination.
The tracked items are transferred in the order they were added to the system; ie. in chronological/ID order. You cannot specify which individual tracked items are transferrred.
|Source product does not have tracked items enabled, but Destination product does have tracked items enabled.||The system will give an error in this case. You cannot transfer quantity from a non-tracked items product to a tracked-items product during a migration.|
|Source product has tracked items enabled, but Destination product does not.||The source product's quantity value will be transferred but the tracked items will not. They will be marked as "deleted" in the migrated plan product.|
|Source and Destination products both have tracked items with no maximums set||All tracked items will be moved from the Source to the Destination. They will be marked as "deleted" in the old subscription product and "active" in the new subscription product.|
The Pricing section provides settings to handle how price adjustments will be transferred between the source and destination products.
- Uplifts - If you transfer a price uplift, the Destination product will inherit the current uplift schedule of the Source product. Note that only future uplift schedules will be transferred, not those which have occurred in the past. (The price uplift itself is not executed by the migration, and the "Uplift before recharge" option is ignored.)
- Discounts - If there are existing discounts (including coupons) on the Source product, these are transferred to the Destination product along with their expiry and eligibility properties. For example, if the Source product has a 20% discount on it with 3 remaining periods before it expires, this will be transferred directly to the Destination product including the 3 remaining periods. Note that past/expired discounts are not transferred.
The Other section contains some additional miscellaneous settings that can be transferred during the migration.
- Expiry - if the Source product has an expiry set, this can be transferred to the Destination product.
- Custom Fields - any custom fields that exist on both the Source and Destination products will have their values transferred. Custom fields that do not exist in both places are ignored. You cannot specify the migration of values between custom fields that do not match.
- Scheduled Date - if the Source product has a scheduled date in the future, this can be transferred to the Destination product.