Home > Tech Writers Hub > Knowledge Services Sandbox > Aria Media Publishing Suite > Aria Media and Publishing Suite (AMPS) - Conceptual Product Model and Capabilities

Aria Media and Publishing Suite (AMPS) - Conceptual Product Model and Capabilities

Overview

The Aria Media and Publishing Suite (AMPS) product and account model are flexible and extendable as requirements grow. The solution will manage both digital products as well as the traditional printed media. The solution may also be extended to other products offered by prospective client or third-party partners. Aria is considered the master for both product catalog and billable accounts. 

An AMPS solution can consist of many individual brands, which operate completely independently. The current AMPS design assumes that revenue sharing between the individual titles and any partners is managed in an ERP system based on information received from this solution. This allows for products from varied brands to be billed and managed together.
Brand 1.jpg

The figure above shows the conceptual product model used in the AMPS implementation. The model uses standard ARIA functionality and is comprised of the following components:

  • Plan Groups – an Aria object used to group products together under a single brand. In the above this is represented by “Brand #1”. Is used only during product maintenance as the offerings are determined using other methods. 
  • Master Plans – an Aria object used to define sellable products. Master plans consists of one or more services and one or more rate schedules. The rate schedule is used to drive the currency, price of each service and the billing frequency. In the above this is represented by “Brand Product #1”, “Brand Product #2” and “Brand Product #3”. The customer may buy any or all these products. 
  • Supplemental Plans – an Aria object used to define add-ons to the sellable products. Supplemental plans are defined in the same way as master plans but can be reused across multiple master plans or brands. In the above this is represented by “Addon Product #1” which is an add-on to “Brand Product #1” and “Brand Product #2”. “Shared Add-on #1” is an add-on to “Brand Product #1”, “Brand Product #2” and “Brand Product #3”.


There is no technical limitation to the dept of the product hierarchy, but for practical reasons it is usually limit¬ed to three or four levels. ARIA provides some functionality to ensure that mutually exclusive products cannot be purchased at the same time. More features, however, will require additional configuration of the products and require specific implementation in the systems using the products. 

The conceptual model shown is also used to support the special AMPS functionality of campaigns (“5 weeks for 5 Kroner”, “10 kroner until Christmas”, etc.) and bund¬les (“Norway Package”, etc.). For campaigns, additional details (campaign start and end date as well as identification of the campaign) are stored with the product once it is purchased by the customer. For bundles, additional details (references between products in the bundle as well as to and from the bundle product itself) are stored with the product once it is purchased by the customer.  

As part of the description of the individual components of the product model, the AMPS extensions are also described. For the full description of the product model extensions please refer to “Aria Media Suite - Aria Core Configuration". 
 

Product Model Elements

Usage Types

Usage Types are used to support products which are priced based on actual consumption, for example number of article-clicks, time spent on website, etc. Usage types are used when external solutions need to feed Aria with the actual consumption to Aria to bill or simply report on the usage. 

The usage types must be configured with a usage type name, and a client defined identifier. The client defined identifier should adhere to the naming standards agreed for client identifiable elements. The client defined identifier is used by external systems to define what usage is being loaded. 

Usage Types.jpg

The red rectangle in the above figure shows the usage type and its location in the product model. The usage type is defined as a separate object and used by one or more services. Each usage type has a unit associated, for example “Count”, “Seats”, “Clicks”, “Gigabyte”, “Megabyte”, “Attachments”, “Downloads”, etc.

Usage types may be created at the onset to support product needs, or be added later via configuration.
 

Services

Services define the lowest level of the Aria product model and is used to build the content of a master or supplemental plan (products) or non-subscription offering. A single master or supplemental plan may contain many different services, each with the own characteristic and price. However, some services are allowed only once per master or supplemental plan. A non-subscription offering (NSO) may contain only a single service. The following Aria service types are supported:

  • Recurring – charges are generated with the specified interval and covers pre-paid services, i.e. covering the future (next) billing period. A single master/supplemental plan may contain multiple services of this type. 
  • Recurring Arrears – charges are generated with the specified interval and covers post-paid services, i.e. covering the previous billing period. A single master/supplemental plan may contain multiple services of this type.
  • Activation – charges are generated by Aria when the master plan or supplemental plan is first activated or, if configured, re-activated. A single master/supplemental plan may contain only one service of this type.
  • Cancellation – charges are generated by Aria when the master plan or supplemental plan instance is cancelled prior to the agreed period. A single master/supplemental plan may contain only one service of this type.
  • Minimum-fee – charges are generated by Aria with the specified interval and covers usage and recurring charges. The fee is charged if the sum of usage and recurring services in the same plan instance is less than the amount specified. A single master/supplemental plan may contain only one service of this type.
  • Usage-based – charges are based on the actual usage consumption reported and loaded into Aria by external solutions. When defining a usage-based service a usage type must also be configured. A single master/supplemental plan may contain multiple services of this type.
  • Order-based – charges are considered one-off charges and is billed only once. Non-subscription offerings must use an order-based service when being configured. The service cannot be used with master/supplemental plans. 
    Services.jpg


The red rectangle in the above figure shows the services and their location in the product model. The service is defined as a separate object and can be re-used by different master/supplemental plans. The definition of a service drives the following functionality:

  • Taxation – each service is defined as taxable or not. If the service is taxable, a tax group is assigned to define the percentage to be used. The percentage used depends on the jurisdiction of the customer, i.e. resident in Norway, Sweden, etc. 
  • GL Codes – each service is defined with a GL code used when transferring revenue and other details to the ERP system. In general, the GL code drives the account to be used in the GL, and when transferring the information, it will be enhanced with additional information from the customer and products. 

In the current AMPS implementation design several extensions to the service has been made to control different capabilities. The extensions are:

  • ChargeType – a product field used to indicate whether the service is a chargeable service or whether the service is used to control the customer’s access to different services, for example digital content or printed media. If the product is a combination product with access to both digital and printed media, then the master/supplemental plan must be assigned a service with each ChargeType.
  • ChargeGroup – a product field used to group services of a similar type together. Is used to correctly allocate payments against invoice charges, for example ensuring that subscription charges are considered paid before fees and surcharges. 
  • AccessFeature – a product field used to define what feature an “Access” service provide access to. Each service covers a single feature only. 
  • TaxGroupID – a product field used to hold the tax group assigned to the service. As the tax group defined on the service is unavailable in most API calls, the supplemental field is required. The tax group assigned must match the tax group defined on the actual service. 


Rate Schedules

The rate schedules defined for each master/supplemental plan is used to define the price/cost of the services included in the master/supplemental plan. A rate schedule must exist for each combination of billing period and currency that is supported. If, for example Monthly, Quarterly and Annual billing is supported for Norwegian Kroner (NOK), Swedish Krona (SEK) and British Pounds (GBP) then a total of 9 (nine) rate schedules must be defined each with their own prices. With this feature it is possible to re-use the same product across different geographies with different prices. 

Some products (master/supplemental plans) may have additional rate schedules, for example to be able to handle different pricing points and/or to include additional services, for example delivery charges. The rate schedules for the additional price points and the rate schedules for the individual products are found on each product defined. The rate schedule for the additional price point is assigned when required. 

Rate Schedules.jpg

The red dotted rectangle in the above figure shows the rate schedules and their location in the product model. The rate schedule is defined as part of the master/supplemental plan and cannot be re-used outside of the master/ supplemental plan. 

At least one rate schedule must be defined for each master/supplemental plan. The rate schedule is selected automatically by the solution when adding new subscriptions or when updating existing subscriptions. The selection is based on the chosen billing frequency for the product as well as other optional criteria. The following criteria is used to select the rate schedule:

  • Currency – the currency in which the customer is billed is used to select the appropriate rate schedule. 
  • Billing frequency – the frequency with which the customer is billed for a given master/supplemental plan is used to select the appropriate rate schedule. 
  • Delivery option – if special delivery charges apply, then the delivery option is also used to select the rate schedule to apply. 
     

Non-Subscription Offerings (NSOs)

Non-subscription offerings are considered one-time purchases, for example to provide access to a specific article in a title the customer does not have any active subscriptions on. The non-subscription offerings are defined independently of the master/supplemental plan and can in general be used to charge the customer for any one-time purchase he or she may select, for example purchasing access to live-streaming of a single football match.

Non Subscription Offerings.jpg

The red dotted circle in the above figure shows the non-subscription offering and its location in the product model. The non-subscription offering (or NSO) can be re-used as the price of the offering can be overridden when the NSO is ordered. NSO’s can also be invoiced and billed immediately outside the normal recurring billing frequency. However, the NSO’s can also be included on the next anniversary invoice/bill.

Currently the NSO’s are used to support the following capabilities:

  • Campaigns – NSO’s are used to charge the customer for the initial period of a given campaign, for example the first 5 weeks of a “5 weeks for 5 kroner” campaign. This charge is billed immediately when the subscription is created. The subscription itself is created with a billing start date matching the end of the campaign. 


Master / Supplemental Plans

The master plan describes the main products available for sale to end-customers, while supplemental plans are add-ons to the master plans or other supplemental plans. With this it is possible to create a hierarchy of pro­ducts and services, so the correct offer can be presented to the customer.

In Aria, a master or supplemental plan consists of several services and rate schedules. The rate schedules define the price of each service for each billing frequency and currency supported, for example monthly, quarterly and annual for NOK (Norwegian Kroner) and monthly and quarterly for SEK (Swedish Krona). The price defined for each service may be zero, if the element is not charged. It is also possible to define tiered pricing for each of the services in a rate schedule.

To support the business requirements identified to date, the concept of product types has been introduced, each having special characteristics. The product type is defined by product field ProductType which must be set for all master plans. It is not required on supplemental plans. The following product types are currently supported:

  • SPECIAL – the special products are used to manage certain special functionality or requirement. The special products are not sellable to the end-customer, even though they are defined as master plans.
  • BUNDLE – the bundle products are used to represent the bundles enabled when the customer has purchased a specific number of subscriptions or the value of the subscriptions exceed a given value. Bundle products are not directly sellable to the end-customer but will be offered when applicable.
  • DIGITAL – the product is defined as a digital product offering services to the end customer via the internet. The product is directly sellable to the end-customer.
  • PRINT – the product is defined as a print media product offering services to the end-customer via published papers. The product is directly sellable to the end-customer.
  • COMBO – the product is defined as a combined digital and print media product offering services to the end-customer both via the internet and via published papers. The product is directly sellable to the end-customer.

Other product types may be added as required.

Master Plan.jpg

The red dotted rectangle in the above figure shows the master/supplemental plan and its location in the product model. Master plans define the top-level of the product hierarchy and cannot be linked. Supplemental plans must be linked to a parent plan to be useable. The same supplemental plan can be assigned to several other supplemental plans or master plans as a child product. This allows the re-use of supplemental plans across all titles and plans. 

To support the current implementation design and requirements, the master/supplemental plan definition has also been extended with additional capabilities, namely:

  • Title Management – to manage the individual titles, it is possible to assign a title code to each master plan. The title code is stored in product field TitleCode, and in most situations a master plan is assigned a single title code. However, bundle products may have multiple title codes assigned. Title management is part of the Aria Publishing Suite. 
  • Payment Management – to ensure that certain products are available only when using certain payment methods, product field PaymentMethodReqd is defined. This field contains a code indicating the payment methods required for a given product. If the field contains “ANY” then any payment method is allowed. 
  • Conditional purchase – to ensure that certain products are sold only if the customer also has several other active subscriptions has been added and is defined by product fields PrerequisiteCount and PrerequisiteType in combination. This functionality is used when a product can be sold only if the customer has another active subscription at the time of purchase. If PrerequisiteType contains “NONE”, then no restrictions apply. 
  • Bundle Eligibility – to ensure that only eligible products are included in bundles, the product field EligibleForBundles has been introduced. If this field contains TRUE, the master plan is eligible for inclusion in bundles as defined by the bundle definition. 
  • Campaign Eligibility – to ensure that only eligible products are included in discount calculations, the product field EligibleForDiscounts has been introduced. If this field contains TRUE, the master plan is eligible for inclusion in discount calculations. 
  • Sharing Eligibility – to ensure that only eligible products can be shared among all members of the group, the product field EligibleForSharing has been introduced. If this field contains TRUE, the master plan is eligible for sharing. Details on the sharing capabilities are transferred to the external access control management system for enforcement.
  • Max No. Of Shares – in order to control the number of members that can be included in a sharing group it is possible to define a maximum number between 0 and 9999. This setting will be transferred to the external access control management system for enforcement.
     

Key Details for AMPS

Usage Types

Key Attributes

The following attributes of the usage type must be set according to the current AMPS implementation design:

Attribute (Field) Name Description
Usage Type Name This attribute (field) defines the name assigned to the usage type. The usage type must be unique across the Aria client.
Client-Defined ID This attribute (field) contains the unique client defined ID of the usage type. The identifier is built as described later in this section. The client defined can be used to identify the usage when loading the usage into Aria.
Display Name This attribute (field) defines the name of the usage type that will be used in reports and on Aria generated invoices/receipts.
Usage Type Description This attribute defines the brief description of the usage type.
Usage Unit Type This attribute defines the type of usage being defined. Any of the predefined usage types can be selected, for example gigabyte, megabyte, kilobyte, minutes, hours, seconds, etc.

Client-Defined ID Format

The client defined identifier for the usage types should be defined as [gggg-sssssssss] where:

  • gggg - represents the usage type group, for example STR for streaming, CNT for content, CLK for clicks, SPC for special services, etc.
  • sssssss - represents the name of the usage type, for example “ARTICLE”, “SPORTS”, “NEWS”, etc. The name of the usage type and associated service are traditionally the same. 

The following are typical AMPS usage types defined in Aria: 

Service Name Client-Defined ID Usage Type Description
Clicks - News Articles CLK-ARTICLES-NEWS A usage type that allows capture of clicks on individual news articles.
Clicks - Sports Articles CLK-ARTICLES-SPORTS A usage type that allows capture of clicks on individual sports articles.
Streaming - Sport minutes STR-MINUTES-SPORT A usage type that allows capture of the number of minutes spent by the customer streaming sports clips.

Note: For information on creating Usage Types in Aria, see Create a Usage Type.


Services

In the current AMPS implementation design several extensions to the service have been made to control different capabilities. The extensions are:

  • ChargeType – a product field used to indicate whether the service is a chargeable service or whether the service is used to control the customer’s access to different services, for example digital content or printed media. If the product is a combination product with access to both digital and printed media, then the master/supplemental plan must be assigned a service with each ChargeType. The following are charge types currently supported:
    • CHARGE, CHARGE-DEL-AIRMAIL, CHARGE-DEL-POST
    • ACCESS-DIGITAL, ACCESS-PRINT, ACCESS-PRINT-WD, ACCESS-PRINT-WE
  • ChargeGroup – a product field used to group similar services into a single unit. The charge group is used when allocating payments against invoiced charges to ensure that important charges are matched before lesser charges, for example fees and surcharges. The charges are allocated in the sequence identified by the charge group, with services having GROUP-01 assigned being allocated before GROUP-02 and so on. The following codes are currently supported:
    • GROUP-01, GROUP-02, GROUP-03, GROUP-04, GROUP-05, GROUP-06, GROUP-07, GROUP-08, GROUP-09, GROUP-10
  • AccessFeature – a product field used to define what feature an “Access” service provides access to. Each service covers a single feature only. The access features are primarily defined in the external access control system and by the client, when putting up articles and stories on the web site for digital use. Currently the following codes are supported: 
    • NEWSPAPER, ECONOMICS, SPORT
  • TaxGroupID – a product field used to hold the tax group assigned to the service. As the tax group defined on the service is unavailable in most API calls, the supplemental field is required. The tax group assigned must match the tax group defined on the actual service. 
    • STANDARD, ZERO, REDUCED, REDUCED-LOW and EXEMPT

Note: For more information on Product Fields associated to AMPS services, see Aria Media and Publishing Suite - Aria Core Configuration. For information on creating Product Fields in Aria, see Create Product Fields.

Key Attributes

The following attributes of the service must be set in the current AMPS implementation:

Attribute (Field) Name  Description / Notes
Service Name This attribute defines the logical name of the service. The service name is seen throughout the application, and the translated values are available for display to the end-customer for example on the portal. 
Client-Defined ID This attribute contains the unique client defined ID of the service. The identifier is built as described later in this section. The client defined identifier can be used to identify the service when registering it in Aria. 
Service Type This attribute defines the type of service being configured. Is set depending on requirements and must be either "Recurring", "Recurring Arrears", "Activation", "Order-based", "Usage-Based", "Cancellation" or "Minimum-fee".
Taxable Set if the service is taxable and VAT needs to be calculated. When selected a TAX Group must also be selected. 
Tax Group

If the service is taxable, then the appropriate Tax Group must be selected. The tax group will together with the customer's home address define the tax that is applied to this service.

Note: the tax group must also be configured in the TaxGroupID product field for this service.
Revenue Account GL Code This attribute contains the GL account assigned to revenue reported by Aria. In the current AMPS solution design this is used to represent the earned revenue code "3000" which will be further processed when the details are generated. 
ChargeType (Product Field) This product field defines the type of charges applied by this service. "CHARGE", "CHARGE-DEL-AIRMAIL", or "CHARGE-DEL-POST" indicates that the service is a subscription or delivery charge, while "ACCESS-DIGITAL", "ACCESS-PRINT", "ACCESS-PRINT-WD" or "ACCESS-PRINT-WE" are used to control access to digital or printed media. 
ChargeGroup (Product Field) This product field defines the group to which the service belongs. The charge group is used to determine in what sequence invoiced charges are matched against payments. Services with a low charge group are allocated before those with a higher group. 
AccessFeature (Product Field) This product field defines what the service provides access to via the external access control system. Is used only if ChargeType contains "ACCESS-DIGITAL". 
TaxGroupID (Product Field)

This product field defines the tax group assigned to the service. It must contain the same value of the Tax Group field defined earlier.

Note: the Tax Group ID must be set to the same value as the Tax Group defined above. The value is the client defined identifier of the tax group

 Client-Defined ID Format

The client-defined identifier for the services should be defined as [ggg-sssssssss] where:

  • gggg - represents the service group, for example SVC for recurring services, CNT for usage-based services, CLK for usage-based services, ACC for access services, SPC for special services, etc.
  • sssssss - represents the name of the service, for example “ARTICLE”, “SPORTS”, “NEWS”, etc. The name of the usage type and associated service are traditionally the same. 

The following are typical AMPS services defined in Aria: 

Service Name Client-Defined ID Service Description Service Type
Subscription - Normal SVC-SUBSC-NORMAL A service that defines the subscription charge for a given title. Zero % VAT is calculated on this service. Recurring
Subscription - Normal - (Vatable) SVC-SUBSC-NORMAL-STANDARD A service that defines the subscription charge for a given title. Standard VAT (25%) is calculated on this service. Recurring
Access - Digital All Days ACC-DIGITAL-ALL A service that defines that the product provide access to the full digital content of a given title. Recurring
Access - Print All Days ACC-PRINT-ALL A service that defines that the product provides a daily printed newspaper to the customer. Whether the title is published daily is dependent on the title itself. Recurring
Usage - Clicks News Articles CLK-ARTICLES-NEWS A service that defines the charging for consumption of clicks on news articles for a given title. Usage-based
Subscription - Campaign Charge SVC-CAMPAIGN-CHARGE A service that defines the initial charge for a campaign. The actual charge is defined by the campaign. Order-based

Note: For information on creating Services in Aria, See Create a Service.

 

Rate Schedules

Key Attributes

The following attributes of the rate schedule must be set in the current AMPS implementation:

Attribute (Field) Name Description / Notes
Rate Schedule Name This attribute contains the logical name of the rate schedule. This value is presented to the end-customer (incl. translations) when the offerings are presented allowing the end-customer to select the appropriate rate schedule.
 
If requested by the caller, then only a subset of the rate schedules will be returned. In this case the solution will check for the request source ID (requestSourceID) in the start of the rate schedule name and if a match is found, it will be returned. The translated rate schedule name is not checked and should not contain the request source. 

Note:
The following are sample rate schedule names:
  • "Monthly Subscription" – a rate schedule representing the monthly subscription
  • "Quarterly Subscription" – a rate schedule representing the quarterly subscription
  • "Annual Subscription" – a rate schedule representing the annual subscription. 
Client-Defined Identifier

This attribute contains the unique client defined ID of the rate schedule. The client defined ID must be unique across all plans, not only the current plan. The identifier is built as described below. 

Note: As the identifier is automatically generated depending on the scenario, the proposed format must be strictly adhered to. For example, RB-C-DIGITAL-FULL-NOK-03
Currency This attribute defines the currency for which the rate schedule applies. The currency code is also made part of the client defined rate schedule ID defined above. For example, NOK
Available Start Date This attribute defines the date from which the rates are applicable. The start date cannot be backdated and is automatically filled with the current date when a new rate schedule is added. 
Available End Date

This attribute defined the date to which the rates are applicable. After this date, the rate schedule can no longer be assigned to a customer.

Note: The date is the overall end date of the rate schedule, and any future rate changes should be valid before this overall end date. 
Billing Interval

This attribute defines the frequency with which the recurring services of the plan are billed. The frequency can be either "Monthly", "Quarterly", "Semi-annually", "Annually" or "Custom". When using the "Custom" option the number of months must also be specified. 

Note: The Billing and Usage interval does not have to use the same frequency allowing the product to be billed with different intervals. It is critical that the billing frequency of the master plan is the most frequent billing interval compared to any supplemental plans assigned. For example, it is not possible to have a monthly billing frequency on the supplemental plan while the master plan uses annual billing. 
Usage Interval

This attribute defines the frequency with which the usage-based services of the plan are billed to the end-customer. The frequency can be either "Monthly", "Quarterly", "Semi-annually", "Annually" or "Custom". When using the "Custom" option the number of months must also be specified.

Note: The Billing and Usage interval does not have to use the same frequency allowing the product to be billed with different intervals.
Schedule Future Rate Change When selected, the user can register a future rate change for each service in the plan. The future rate becomes the current rate on the date given in the "Future Rate Change Start Date".
Future Rate Change Start Date This attribute contains the date from which the future rate should apply. Is used only if a rate change is scheduled.

The initial rate schedule added for a given currency will always be set as the default rate schedule. This rate schedule is used when creating subscriptions and no rate schedule is provided. The user can later change the default rate schedule per currency based on the requirements. 

Client Defined ID Format

The client defined identifier for the rate schedules should be defined as [tttt-pppppp-ccc-fff-xxxxx] where:

  • tttt - represents the title code, for example ABC, BCD, CDE, etc.
  • pppppp - represents the name of the plan excluding the title code, for example “C-DIGITAL-FULL”, “C-DIGITAL-SPORT”, “C-DIGITAL-ECONOMICS”, etc. 
  • ccc - represents the currency in the which the current rate schedule is billed, for example “NOK” for Norwegian Kroner, USD for US Dollar, etc. 
  • fff - represents the frequency with which the current rate schedule is billed, for example “01” for monthly, “03” for Quarterly, “12” for annual. 
  • xxxxx - represents the additional qualifier for the rate schedule. Allows multiple rate schedules to be defined for the same plan, currency and frequency, for example for use with delivery charges and/or other special pricing arrangements. 

The following are typical AMPS rate schedules defined in Aria: 

Client-Defined ID Rate Schedule Description
ABC-C-DIGITAL-FULL-NOK-01 A rate schedule that bills the customer for the product monthly in Norwegian Kroner.
ABC-C-DIGITAL-FULL-NOK-03 A rate schedule that bills the customer for the product quarterly in Norwegian Kroner.
ABC-C-COMBO-FULL-NOK-03 A rate schedule that bills the customer for the product quarterly in Norwegian Kroner.
ABC-C-CONBO-FULL-NOK-12 A rate schedule that bills the customer for the product annually in Norwegian Kroner.
ABC-C-COMBO-FULL-NOK-03-POST A rate schedule that bills the customer for the product and delivery by post quarterly in Norwegian Kroner.
ABC-C-COMBO-FULL-NOK-12-TRANS A rate schedule that bills the customer for the product and includes a transportation fee charge annually in Norwegian Kroner.

Note: For information on creating Rate Schedules in Aria, see Add Rates to a Plan.

 

Non-Subscription Offerings (NSOs)

Key Attributes

Attribute (Field) Name Description / Notes
Non-subscription Offering Name

This attribute contains the logical name of the non-subscription offering.

Note: The attribute is translatable.
Client-Defined Identifier This attribute contains the unique client-defined ID of the non-subscription offering. For example, ABC-C-DIGITAL-FULL-NOK-03
Description

This attribute contains the brief description of the non-subscription offering.

Note: The attribute is translatable.
SKU

This attribute contains the SKU of the non-subscription offering. The SKU is used when registering the order of one-time products.

Note: The SKU is registered in the Campaign definition and will be used to charge for the initial period of the campaign.
Type This attribute defines the type of non-subscription offering. Will always contain "Inventory Item".
GLDimensionN (Product Field)

These product fields contain the additional GL dimensions used when reporting revenue into the ERP system. The values to be used are defined by the Finance department. 

Note: Note that GLDimension5 is not used and is instead defined by the ERP GL Code defined for each title code. 

Note: For more information on Product Fields associated to AMPS Non-Subscription Offerings, see Aria Media and Publishing Suite - Aria Core Configuration. For information on creating Product Fields in Aria, see Create Product Fields. 

Client Defined ID format

The client defined identifier for the plans should be defined as [ttttt-sssssssss] where:

  • tttt - represents the title code, for example ABC, BCD, CDE, etc. Use CMP for non-subscription offerings that are related to campaigns and not to a specific title. 
  • sssssss - represents the name of the non-subscription offering, for example “5FOR5NOK”, “10FOR100NOK”, etc. 

The following are typical AMPS non-subscription offerings defined in Aria where the campaign IS related to a specific title:

NSO Name Client_Defined ID Description
1 Month for NOK 49 ADR-1MFOR49 A non-subscription offering used with the campaign "1 Month for 49 Kroner". Is used to bill the customer for the full campaign period. Can be used with title code 'ADR' only.
10 Weeks for NOK 100 BLA-10WFOR100 A non-subscription offering used with the campaign "10 Weeks for 100 Kronr". Is used to bill the customer for the full campaign period. Can be used with title code 'BLA' only.
Until Xmas for NOK 50 AND-XMAS-FOR-50 A non-subscription offering used with the campaign "Until Xmas for 50 Kroner". Is used to bill the customer for the full campaign period. Can be used with title code 'AND' only.

The following are typical AMPS non-subscription offerings defined in Aria where the campaign IS NOT related to a specific title:

NSO Name Client_Defined ID Description
1 Month for NOK 49 CMP-1MFOR49 A non-subscription offering used with the campaign "1 Month for 49 Kroner". Is used to bill the customer for the full campaign period. Can be used with ANY title.
10 Weeks for NOK 100 CMP-10WFOR100 A non-subscription offering used with the campaign "10 Weeks for 100 Kroner". Is used to bill the customer for the full campaign period. Can be used with ANY title.
Until Xmas for NOK 50 CMP-XMAS-FOR-50 A non-subscription offering used with the campaign "Until Xmas for 50 Kroner". Is used to bill the customer for the full campaign period. Can be used with ANY title.

For information on creating Non-Subscription Offerings in Aria, see Create Non-Subscription Offerings. 

 

Master / Supplemental Plans

Key Attributes

The following attributes of the master / supplemental plans must be set in the current AMPS implementation:

Attribute (Field) Name Description / Notes
Plan Name

This attribute contains the logical name of the master/supplemental plan.

Note: The attribute is translatable and will be displayable to the end-customer on portals and receipts.
Client-Defined Identifier

This attributes contains the unique client-defined ID of the master/supplemental plan.

Note: The attribute is translatable.
Description

This attribute contains a brief description of the plan.

Note: The attribute is translatable.
Plan Type This attribute defines the type of plan being defined. "Master Plan" indicates a master plan, while "Supplemental Plan" indicates a supplemental plan.
DeliveryChargeIntl (Product Field)

Contains one or more entries where each entry specifies a range of international country codes and associated rate schedule identifier. If the customer is resident within the range of country codes (both included), then the delivery charge identified by the rate schedule identifier is also billed to the customer. Each row contains one range of country codes and a single rate schedule iden¬tifier. No overlaps are allowed in country codes.

The following are the specification of the format of this field:

  • <start>/<end>/<suffix> – if the product must be delivered to a customer living in a country code between <start> and <end> (both included) the customer will be assigned the rate schedule associated with <suffix> with the same frequency as the main subscription. 
DeliveryChargeNat (Product Field)

Contains one or more entries where each entry specifies a range of national postal codes and associated rate schedule suffix. If the customer is resident within the range of postal codes (both included), then the delivery charge identified by the rate schedule suffix is also billed to the customer. Each row contains one range of postal codes and a single rate schedule identifier. No overlaps are allowed in postal codes. 

The following are the speci¬fication of the format of this field: 

  • <start>/<end>/<suffix> – if the product must be delivered to a customer living in a postal code between <start> and <end> (both included) the customer will be assigned the rate schedule associated with <suffix> with the same frequency as the main subscription.
DeliveryRestIntl (Product Field)

Contains one or more entries where each entry specifies a range of international country codes where the current product cannot be delivered. If the field is empty, there are no restrictions on delivery. Is used only for printed media that needs delivery to the end-customer. Each row contains one range of countries.

The following samples apply:

  • <start>/<end> – if the product must be delivered to a customer living in a country code between <start> and <end> (both included) the customer cannot purchase the current product.
DeliveryRestNat (Product Field)

Contains one or more entries where each entry specifies a range of national postal codes where the current product cannot be delivered. If the field is empty, there are no restrictions on delivery. Is used only for printed media that needs delivery to the end-customer. Each row contains one range of postal codes.

The following samples apply: 

  • <start>/<end> – if the product must be delivered to a customer living in a postal code between <start> and <end> (both included) the customer cannot purchase the current product.
EligibleForBundles (Product Field)

Contains a code indicating if the product is eligible for inclusion in product bundles. Only products that qualify for given bundles will be considered for inclusion in said bundle.

The following codes are proposed: 

  • FALSE – the current product will never be included in any bundles, unless specifically invited.
  • TRUE – the current product will potentially be included in any bundle defined by the client. The product will be priced individually, but the bundle may add an additional subscription covering other titles.
EligibleForDiscounts (Product Field)

Contains a code indicating if the plan is eligible for in¬clu-sion in the discount selection process.

The following options exist:

  • FALSE – the current product will never be included in any discount processing, unless specifically selected.
  • TRUE – the current product will potentially be included in any discount processing.
EligibleForSharing (Product Field)

Contains a code indicating if the plan is eligible for sharing with other family members or whether it is purely for use by the subscriber.

The following options exist: 

  • FALSE – the current product will never be shared among family members.
  • TRUE – the current product will potentially be shared among family members.
GLDimensionN (Product Field)

These product fields contain the additional GL dimensions used when reporting revenue into the ERP system. The values to be used are defined by the Finance department.

Note: GLDimension5 is not used and is instead defined by the ERP GL Code defined for each title code.
MaxNoOfShares (Product Field) This product field contains the max number of additional accounts that can share the digital access element of the specific plan. Values must be between 0 and 9999.
PaymentMethodReqd (Product Field)

Contains a code indicating the payment methods sup¬port-ed for the current product. Applies only to master plans.

The following codes are supported: 

  • ANY – any of the payment methods supported by the client is allowed for this product.
  • CREDITCARD – only credit cards can be used with this product.
  • DIRECTDEBIT – only direct debit can be used with this product.
  • NETTERM – only net terms billing can be used with this product.
  • VIPPS – only VIPPS billing can be used with this product. 

Multiple entries are supported so it is possible to specify that, for example, both CREDITCARD and DIRECTDEBIT are acceptable payment methods for a given product. A billing group representing the selected payment method must be added to the account, and then assigned to the respective master plan instance. When assigning a billing group to a master plan instance. New codes will be added as required.

Note: The specific payment methods that apply to the client will be defined as part of the implementation analysis and design and can be configured within Aria. The end to end process for managing the payment method must also be discussed and agreed as part of the solution design and subsequent implementation tasks.
PrerequisiteCount (Product Field)

Used in conjunction with PrerequisiteType. If that field contains:

  • SUBSCRIPTION – then this field contains the total number of active subscriptions (of any type) the customer must have to qualify for the current product. 
  • SUBSCRIPTION-DIGITAL – then this field contains the total number of active subscriptions (DIGITAL products only) the customer must have to qualify for the current product. 
  • SUBSCRIPTION-PRINT – then this field contains the total number of active subscriptions (PRINT products only) the customer must have to qualify for the current product.
PrerequisiteType (Product Field)

Contains a code indicating the type of prerequisite that is defined for the current product. The prerequisite deter-mines the conditions under which the plan can be purchased.

The following codes apply: 

  • NONE – the product does not have any prerequisite and can be purchased at any time.
  • SUBSCRIPTION - the current product can be purchased only if the customer has one or more other subscriptions active at the time of purchase. Any type of product is allowed.
  • SUBSCRIPTION-DIGITAL – the current product can be purchased only if the customer has one or more other DIGITAL subscriptions active at the time of purchase
  • SUBSCRIPTION-PRINT – the current product can be purchased only if the customer has one or more other PRINT subscriptions active at the time of purchase.
ProductType (Product Field)

Contains a code indicating the type of product managed by the plan instance (subscription).

The following codes are used: 

  • DIGITAL – the product is a digital product priced individually. The customer may choose this product for purchase. For this product type, a single title code is assigned
  • PRINT – the product is a print-media product priced individually. The customer may choose this product for purchase. For this product type, a single title code is assigned
  • COMBO – the product is a combined digital and print-media product priced individually. The customer may choose this product for purchase. For this product type, a single title code is assigned
  • BUNDLE – the product is part of a bundle that covers multiple plan instances and priced accordingly. Products with this this product type cannot be selected for purchase by the customer. Instead it will be assigned once the bundle has been checked and the customer is eligible for the bundle. For this product type multiple title codes may be assigned
  • SPECIAL - the product is a special product used for certain scenarios. The customer cannot directly select this product for purchase. For this product type no title codes are assigned.
ProductTypeVariant (Product Field)

Contains a code that defines the variant of the product as determined by ProductType.

The following codes apply: 

  • STANDARD – indicates that this is the default variant of the product
  • FLEX-DAYS – indicates that the product is a flex product, allowing (requiring) the customer to select which days the print media is delivered. ProductTypeVariantCnt defines the number of days the customer must chose during the sales process. Used only with the PRINT and COMBO product types. Other codes will be added when required.
  • SHARING – indicates that the product is a sharing product and contains digital services that may be shared within a group
  • INDV-DELIVERY – the variant describes a business product where the customer (the business) can choose to purchase several subscriptions, and then have it delivered to each registered individual (employee). The delivery address is usually at the employee's home address, but it is the employee decision where the paper is delivered. The customer is charged only for the number of individuals (employees) registered in the system. This product applies only to printed products.
  • INDV-REGISTRATION – the variant describes a business product where the customer (the business) can choose to purchase several subscriptions, and then have it delivered to the business office. Each employee to receive the paper must be registered in the solution. The customer is charged only for the number of individuals (employees) registered in the system. This product applies only to printed products.
ProductTypeVariantCnt (Product Field)

Contains the count associated with the product variant. The value has the following meaning depending on the ProductTypeVariant value:

  • STANDARD – count is not used.
  • FLEX-DAYS – count defines how many delivery days the customer must chose when purchasing this product. 1 indicates that the customer must chose 1 day of the title publishing days, 2 indicates that the customer must chose 2 days of the title publishing days and so on.
  • SHARED – count is not used.
ProductPriceModel (Product Field)

Contains a code indicating how the product is priced. The following codes are supported: 

  • STANDARD – Standard pricing is used.
  • PRICE-ADJUST – pricing takes into consideration any price changes that may have been registered at the time of billing. The price will be set as a custom rate and adjusted with the billing frequency interval.
Segmentation (Product Field) Contains a code indicating the segment in which the current product can be purchased. Applies only to master plans. If a product can be sold across multiple segments, several codes may be provided with one code in each row. The following codes currently apply: 
  • ANY – the product can be sold to customers in any segment
  • B2B – the product can be sold only to customer designated as B2B customers.
  • B2C – the product can be sold only to customer designated as B2C customer.
TitleCode (Product Field)

Contains one or more entries each holding the identi¬fi-cation of titles to which the end-customer will be given digital access when subscribing to this product. The title information is not used to determine if the end-customer is eligible for the product during the sales-cycle. 

If the field contains, for example ABC, BCD and CDE then the end-customer will be given access to the ABC, BCD and CDE titles and covering the features defined by the services. All titles will be given the same feature access when integrating with the external access management system.
TitleCodeOffering (Product Field)

Contains one or more entries each holding the identification of titles where the product should be included in the list of eligible products. The title information is not used to determine what titles the end-customer will have access to on the websites, only whether it should be presented as an eligible offering during the sales-cycle. 

If the field contains, for example ABC and BCD (and TitleCode contains ABC, BCD and CDE) then the end-customer will see the product presented as an eligible offering when using the ABC and BCD websites only. The product will, however, also provide access to the CDE website.

Note: For more information on Product Fields associated to AMPS Master and Supplemental Plans, see Aria Media and Publishing Suite - Aria Core Configuration. For information on creating Plans in Aria, see Create a Plan.

 

Client-Defined ID Format 

The client-defined identiier for the plans should be defined as [ttttt-sss-ppppppppp] where:

  • tttt - represents the title code, for example ABC, BCD, CDE, etc.
  • sss – represents the segment for which the product is defined, for example "C" for Consumer, "B" for Business and "S" for Student. May be omitted by certain types of products.
  • pppppp - represents the name of the plan, for example “FULL-DIGITAL”, “SPORT-DIGITAL”, “NEWS-DIGITAL”, etc. The name of the plan is also used as part of the rate schedule naming. 

The following are typical AMPS plans defined in Aria:

Plan Name Client-Defined ID Plan Description Plan Type
National News - Full Digital ABC-C-DIGITAL-FULL A plan that provides digital access to all articles on the titles website and charge the customer accordingly. Master (Digital)
National News - Sport Digital ABC-C-DIGITAL-SPORT A plan that provides digital access to sports articles on the titles website and charges the customer accordingly. Master (Digital)
National News - Full Print ABC-C-PRINT-FULL A plan that provides and delivers printed 'National News' newspaper to the customer. The print papers are delivered every day the newspaper is published. Master (Print)
National News (Weekend Print) ABC-C-PRINT-WEEKEND A plan that provides and delivers printed 'National News' newspaper to the customer. The print papers are delivered every weekend day the newspaper is published. Master (Print)
Regional Package REGPACKAGE A plan that provides the charge for the 'Regional Package' if that bundle was applicable for a customer. Master (Bundle)
National News - Full Combo ABC-C-COMBO-FULL A plan that provides and delivers printed ‘National News’ newspaper to the customer as well as full access via the internet. The print papers are delivered every day the newspaper is published. Master (Combo)

AMPS Product Models

In the current implementation design of Aria it is possible to define various products (plans), each with their own set of services and prices. The Aria product catalog holds the products as they are designed, and these products gets instantiated when they are assigned to a customer account. To support the AMPS requirements several extensions have been made both to the product catalog and the specific subscription (instance) for a given customer account. For the full description of the extensions please refer to the “ARIA MS Solution Design – General ARIA System Configuration for AMPS” document. Is this "Aria Media and Publishing Suite - Aria Core Configuration"?

Product Types

The current implementation design operates with several different product types. The product type is defined on the master/supplemental plan using product field ProductType. The product determines how the implementation manages the subscription as well as the capabilities provided. The following options exist:

  • Special Products (SPECIAL) – special products are products used for certain scenarios in the implementation. Products defined as “SPECIAL” cannot be selected directly by the customer during the sales process and subscriptions on this kind of product is never made available to end-customers. Instead it will be assigned automatically by the solution. 
  • Bundle Products (BUNDLE) – bundle products are a product assigned to an account because the customer is eligible for the bundle, for example due to the number of active eligible subscriptions or value of the eligible subscriptions. When assigning a bundle, the subscriptions that form the basis of the bundle are retained, and an additional subscription is assigned just for the bundle (i.e. Norway Package). The overall price of the bundle is the normal subscription value of the existing subscriptions plus the price of the bundle itself. Once a bundle has been assigned, the customer generally has access to all titles, at least digitally.  
  • Digital (DIGITAL), Print (PRINT) and Combination (COMBO) Products – digital, print and combination products are products selected and purchased by the customer covering access to the digital services , printed media or a combination of these for a given title. Each product is charged separately. A product may have a campaign assigned when it is first created. A digital, print or combination product can act as a prerequisite for a bundle product, i.e. the customer must purchase three eligible products to be eligible for a given bundle. 

Other type of products may be added at a later stage. Additional details about each product type is given in the following sections. 
 

Special Products (SPECIAL)

In the current implementation design some special products are required. The special products are used to handle certain cases as described below. Special products are defined in the same manner as other products, but they will always have a value of “SPECIAL” in product field ProductType. Special products will never be made visible to the end-customer or the customer service applications. Once configured this plan should not be changed unless directed by Aria Solution Architects. 

Currently the following special products are defined:

  • Account Plan [SPC-ACCOUNT-PLAN] - the account plan is assigned to the account when it is first created. At this time, it is the only plan assigned to the account. The product is created in status “Active – Non-billable” as it will never be charged. The account plan product is assigned to an account when the account is first created. The product cannot be chosen by the customer during the sales process (as ProductType is defined as SPECIAL). Each account will always have an account plan pro¬duct assigned. 

The following figure shows the configuration of the special account plan product:

Special Product.jpg

The one-time purchase product consists of the following elements:

  • A usage type “Special – Service Count 1” with ID [SPC-SPECIAL-CNT1]. The usage type is defined using “COUNT” as the usage unit. Usage will never be received from external solutions on this usage type even though it is potentially possible. 
  • A service “Special – Service Count 1” with ID [SPC-SERVICE-CNT1]. The service is defined as a usage-based service referencing the above usage type. 
  • A master plan “Special – Account Plan” with ID [SPC-ACCOUNT-PLAN]. The master plan is linked to the plan group “Special Products”. A single rate schedule [SPC-ACCOUNT-PLAN-NOK-01] is defined, linking the plan with the service and providing monthly billing. The cost is set to 0 for all units. 
     
Bundle Products (BUNDLE)

In the current implementation design several bundle products might be required. The bundle products are used to charge the customer for digital access to all titles not explicitly subscribed to already. An example of this is where the customer has an active subscription to title T1, T2 and T3, and adding a fourth subscription may make the customer eligible for a bundle. When this happens the bundle product is assigned, providing access to all titles specified on the bundle product. 

A bundle product is not directly offered as a sellable product, but if the eligibility requirements are met, it will be offered as an alternative to the product originally requested by the customer. When defining the bundle product, the user must define which titles that a given bundle product applies to. This is done by adding an entry for each of the title codes eligible for the bundle. If it applies to all titles, then all title codes must be selected and assigned in product field TitleCode.

When the bundle is added to an account as an active subscription, several product fields are set to assist in linking of the bundle subscription and the individual subscriptions that form the foundation of the bundle. 

On the bundle subscription (plan instance) itself the following product fields are set:

  • BundleRef – a product field maintained on the bundle subscription referencing the identification of the bundle itself. The bundle is defined in the Bundle Management component. 
  • BundlePIRef – a product field maintained on the bundle subscription referencing the master plan in¬stance of the subscriptions that form the foundation of the bundle. The client defined plan instance ID is used as the reference. The reference is maintained as multiple entries in the product field. 

On the individual subscriptions (plan instance) the following product fields are set:

  • BundleLinkRef – a product field maintained on the individual subscriptions referencing the identi¬fi¬ca¬tion of the bundle in which it forms the foundation. The bundle is defined in the Bundle Management component.
  • BundleLinkPIRef – a product field maintained on the individual subscriptions referencing back to the bundle subscription (plan instance). The client defined plan instance ID is used as the reference. Only a single reference is provided, as a subscription cannot partake in several different bundles at the same time. 

Whenever a change is made to the active subscriptions that form part of a bundle, the eligibility for the bundle is rechecked. If the customer is no longer eligible for the bundle, the bundle subscription is cancelled, and the references are removed.

Bundle products are defined in the same manner as other chargeable products, but they will always have a value of “BUNDLE” in product field ProductType. The figure below shows a typical bundle product. 

Bundle Products.jpg


The bundle product consists of the following elements:

  • A charge service for the bundle. The service is defined as a recurring service with a ChargeType of “CHARGE”. GL code is set as required. No AccessFeature is defined for this service. 
  • An access service for the bundle. The service is defined as a recurring service with a ChargeType of “ACCESS-DIGITAL” (or another relevant value depending on the requirements. TitleCode must be set for each title to which the bundle applies. The AccessFeature is set to “NEWSPAPER” or another relevant value for the bundle. 
  • A master plan for the bundle. The master plan is linked to the plan group of the titles for which the product applies. The ProductType is always set to “BUNDLE”.  One or more rate schedules are defined as required by the currency and billing frequency. The cost for each rate schedule and charge service is set as required. 
     
Digital (DIGITAL), Print (PRINT) and Combination (COMBO) Products

Digital (DIGITAL), Print (PRINT) and Combination (COMBO) products are all similar in structure and is in gene¬ral offered to the customer during the sales process. The product field ProductType defines which of the three types a given product is.

If a product is defined as a digital (DIGITAL) or combination (COMBO) product then information about the subscription is transferred to the external access control system to give the end-customer access to the digital features applicable to that product. If the product is defined as a print (PRINT) or combination (COMBO) product then information about the delivery of the subscription is transferred to an external delivery company to be able to deliver the physical paper to the end-customer.

The products are defined in Aria as Master Plans and may have one or more add-ons (Supplemental Plans). The product type (ProductType) is always set to DIGITAL, PRINT or COMBO depending on the type of product. The add-ons can be shared among all other products, if necessary. The figure below shows a typical DIGITAL product. 

Digital-Print-Combination Products.jpg

The figure below shows a typical print product.

Typical Print Product.jpg

The figure below shows a typical combination product.

Typical Combination Product.jpg

As can be seen the products are similar in structure, and they always contain the following elements:

  • A charge service for the product. The service is defined as a recurring service with a ChargeType of “CHARGE”. GL code is set as required. No AccessFeature is defined for this service. 
  • For digital (DIGITAL) or combination (COMBO) products an access service is required. This service must be defined as a recurring service with a ChargeType of “ACCESS-DIGITAL”. TitleCode must be set to the title (or list of titles) for which the product applies. The AccessFeature is set to “NEWSPAPER” or another relevant value for the product. 
  • For print (PRINT) or combination (COMBO) products an access service is also required. This service must be defined as a recurring service with a ChargeType of “ACCESS-PRINT”, "ACCESS-PRINT-WD" or "ACCESS-PRINT-WE" depending on the requirements of the product. TitleCode must be set to the title (or list of titles) for which the product applies. The AccessFeature is set to “NEWSPAPER” or another relevant value for the product.
  • A master plan for the product. The master plan is linked to the plan group of the titles for which the bundle applies. The ProductType is always set to either “DIGITAL”, "PRINT" or "COMBO" as required.  One or more rate schedules are defined as required by the currency and billing frequency. The cost for each rate schedule and charge service is set as required. 

The following capabilities apply to all three types of products:

  • Bundling – if product field EligibleForBundles is set to TRUE, the product will be included in the check for bundles. Otherwise it cannot be part of a bundle. 
  • Discounts – if product field EligibleForDiscounts is set to TRUE, the product will be included in the check for discounts. Otherwise it is not possible to provide discounts on the product. 
  • Campaigns – based on the configuration of campaigns it is always possible for a product to be included in a campaign. 
  • Purchase restrictions – if product field PrerequisiteType is set to SUBSCRIPTION or SUBSCRIPTION-DIGITAL purchase restrictions apply. The product field PrerequisiteCount defines how many active subscriptions that must exist before the current product is created.
  • Segmentation – if product field Segmentation is set to ANY or is blank, the product can be sold to any segment
  • Payment Method Restrictions – using the product field PaymentMethodReqd it is possible to define the set of payment methods required by the current product. If the customer does not have one of these methods enabled, it is not possible to add the product subscription.
     

In addition to the above capabilities the following capabilities apply to "DIGITAL" and "COMBO" products only:

  • Access Control – details on subscriptions on "DIGITAL" and "COMBO" products are distributed to an external access control system, whenever the subscription is assigned, cancelled or otherwise updated.  
  • Sharing – if required, the digital subscription can be shared among multiple members of the family or other grouping. Details on the sharing is returned to the external access control system to manage the sharing. 

In addition to the above capabilities the following capabilities apply to "PRINT" and "COMBO" products only:

  • Distribution – distribution of the physical newspapers is handled according to the addresses registered by the customer. Address changes are communicated to the distribution system in due time for the change to take effect. 
  • Delivery options – product field ProductTypeVariant (set to FLEX-DAYS) is used to define whether the standard delivery schedule is followed, or whether the customer can choose the days of the week the publication is delivered. Only the number of editions specified by ProductTypeVariantCnt can be selected by the end-customer. 
  • Delivery Restrictions – product field DeliveryRestNat is used to define one or more postcode ranges for which the newspaper cannot be delivered in Norway. Product field DeliveryRestIntl is used to define one or more country code ranges for which the newspaper cannot be delivered outside of Norway. 
  • Delivery Charges – product field DeliveryChargeNat is used to define if the newspaper can be delivered to the range of postcodes given for a product. Multiple ranges may apply each having a separate de¬livery charge. Product field DeliveryChargeIntl is used to define if the newspaper can be delivered to the range of countries given for a product. Multiple ranges may apply each having a separate delivery charge. Both the national and international delivery charge follows the same billing frequency as the main charge. If the customer makes a temporary address change to an area where delivery charges apply, they will be applied for the period the temporary address change is in effect. 
     

Further details on the product capabilities are found later in this section.

When creating the subscription based on the product, and the product was eligible for a campaign, and the customer chose that campaign, the following product fields are set when the subscription on this product is created. 

  • CampaignIDRef – a product field maintained on the product subscription referencing the identification of the campaign itself. The campaign is defined in the Campaign Management component of the overall solution and will remain even when the campaign is over. 
  • CampaignDateStart – a product field maintained on the product subscription defining the date the campaign was started. The start date will remain even after the campaign is over. 
  • CampaignDateEnd – a product field maintained on the product subscription defining the date the campaign ends. On the date immediately after this end date, the normal billing of the subscription will commence. The end date will remain even after the campaign is over. 

 

Product Variants

The product field ProductTypeVariant defines specific capabilities of the product. The following options currently exists:

  • STANDARD – the variant describes the standard capabilities of a product, usually defined by a single master plan. This variant can be applied to both digital and printed products. 
  • SHARING – indicates that the product is a sharing product and contains digital services that may be shared within a group. 
  • FLEX-DAYS – the variant describes a product where the end-customer can select which days to receive the newspaper. The customer can choose only delivery days were the newspaper is published. If, for example the newspaper is published on every day of the week, and the product allows the customer to select three delivery days, then the customer can choose any day of the week. The customer can change the delivery days as they require.  This product applies only to printed products.
  • INDV-DELIVERY – the variant describes a business product where the customer (the business) can choose to purchase several subscriptions, and then have it delivered to each registered individual (employee). The delivery address is usually at the employee's home address, but it is the employee decision where the paper is delivered. The customer is charged only for the number of individuals (employees) registered in the system. This product applies only to printed products.
  • INDV-REGISTRATION – the variant describes a business product where the customer (the business) can choose to purchase several subscriptions, and then have it delivered to the business office. Each employee to receive the paper must be registered in the solution. The customer is charged only for the number of individuals (employees) registered in the system. This product applies only to printed products.

Each of the above product variants are described in more detail later in this section. Other variants may be added as required.

Product Variant – "STANDARD"

The STANDARD product variant describes the default product behavior and consists of a master plan with one or more attached services and one or more rate schedules. The product field ProductTypeVariantCnt is not used for this variant.

The figure below shows a typical STANDARD product. 

Product Variant - Standard.jpg
 

The product variant is offered to end-customers via the normal offering process, where the product is offered based on several criteria, and if selected and purchased by the customer a single subscription is created based on the product. The subscription is then billed according to the billing frequency selected by the customer. The subscription continues until cancelled.

Product Variant – “Sharing”

The SHARING product variant describes the scenario where POLARIS have defined the Digital element(s) of a plan to be shared within a group. There are two product fields that must be set against the plans, there are; EligibleForSharing must be set to ‘TRUE’ and the MaxNoOfShares field be equal to or greater than 1. These will be used by the external access control solution to issue and manage invites to group members so they can join the group as well as the AMPS Subscription Management component to record and manage access control requests within the group. The figure below shows a typical SHARING product.

NEED TO ADD DIAGRAM INLINE WITH DOCUMENT STANDARD
 

Product Variant – "FLEX-DAYS"

The FLEX-DAYS product variant describes the scenario where a customer may choose the delivery days according to the definition of the product. The product field ProductTypeVariantCnt defines the number of weekly editions the customer can choose, for example 3 allowing the customer to choose three editions to be deliver¬ed every week out of all the editions published by the title. As with the STANDARD the product consists of a master plan with one or more attached services and one or more rate schedules. The figure below shows a typical FLEX-DAYS product. 

Product Variant - Flex Days.jpg
 

The product variant is offered to end-customers via the normal offering process, where the product is offered based on several criteria, and if selected and purchased by the customer a single subscription is created based on the product. Before completing the purchase, the customer must choose the delivery days based on the days the title is published. The subscription is then billed according to the billing frequency selected by the customer. The subscription continues until cancelled. The customer may change the selected delivery days at any time. A change in the delivery days does not impact the pricing of the product. As with all print-media products, the customer must also define and choose the delivery address for the product.

Product Variant – "INDV-DELIVERY"

The INDV-DELIVERY product variant describes the scenario where a business customer may choose to purchase several subscriptions on the same product and have it delivered directly to the address chosen by the employees. The product field ProductTypeVariantCnt defines the maximum number of subscribers (employees) that can be active at any point in time, i.e. if the number is 100 then only 100 employees can be active and have the paper delivered at the same time. The figure below shows a type INDV-DELIVERY product. 

Product Variant - INDV-DELIVERY.jpg

As can be seen in the above figure, the product variant is modeled in Aria as a master plan and a supplemental plan. The master plan (ABC-B-COMBO-UNITS) is the overall product which is assigned to the business customer. The supplemental plan (ABC-B-COMBO-EMPL) is the product assigned to each employee that is registered to have the paper delivered. With the model, the client may choose to bill the product on master plan or supplemental plan level or both as described below:

  • Billed on Employee level – if prices are defined on the employee level (supplemental plan), the customer is charged only for registered employees, i.e. if 100 units were purchases and only 50 employees have registered, the customer is billed only for the 50 employees. In this scenario no prices are charged at the business level (master plan).
  • Billed on Business level – if prices are defined on the business level (master plan), the customer is charged for the number of units purchased, irrespective of the number of employees registered, i.e. if 100 units were purchased and only 50 employees have registered, the customer is billed for the 100 units purchased. No prices are charged on the employee level, but the employee must still be registered to have the newspaper delivered. 
  • Billed on both Business and Employee level – if prices are defined on both the business level (master plan) and employee level (supplemental plan) then the customer is charged on both levels. The charges on the business level is charged based on the number of units purchased, while the charges on the employee level is charged based on the registered employees. With this model the client can charge the customer for a base amount (based on the number of units) and for actual deliveries (based on the number of employees). 

The product variant is offered to end-customers via an offering process split in two, where the overall product is offered to the customer, and if selected and purchased by the customer a single subscription is created based on the business product (master plan). At this point in time, no employees have been registered. Once the product is active, the employees can be registered by the business customer. During this process the employee product (supplemental plan) is assigned and prorated according to the sign-up date. 

During the registration process, the employee must provide the necessary details to have the newspaper delivered to their preferred address. This address is maintained on the supplemental plan level per employee. The employee can change their delivery address as required, for example redirecting the delivery during their holidays. 

The client implementing Aria and AMPS must provide a mechanism that allows the end-customer to register and re-register employees as required. 
 

Product Variant – "INDV-REGISTRATION"

The INDV-REGISTRATION product variant is identical to the INDV-DELIVERY variant described earlier, with the exception that for this variant, the newspaper is not delivered to the employee, but rather to the primary business address of the business. 
 

Price Models

The primary price model in use is the standard Aria price model. The price model used is defined by product field ProductPriceModel assigned to the product whether it is "DIGITAL", "PRINT" or a "COMBO" product. The price model is not used with "SPECIAL" and "BUNDLE" products. 

Price Model – "STANDARD"

If the ProductPriceModel is set to "STANDARD" then the standard ARIA pricing model applies. In this scenario the price defined on the subscription is billed according to the billing frequency selected. If a service is charged NOK 200 per month and NOK 600 per quarter, then NOK 200 or NOK 600 is billed to the customer irrespective of any future price changes that may be available. Changing the price within the product itself, will make the new price effective for all customers assigned that product. The new price will be used for billing at the next anniversary day. 

Price Model – "PRICE-ADJUST"

If the ProductPriceModel is set to "PRICE-ADJUST" then the special flexible media pricing model applies. In this scenario, the price defined on the product including any future price changes are considered when the product is assigned as a subscription, and just before any future billing dates. At this point in time the price the customer is required to pay is calculated based on any future price changes and taking the current billing dates into consideration. 

Assume that the customer subscribes to an annually billed product on August 1st, 2019. The current price of the product is NOK 1200 per annum, with a future price change to take effect on January 1st, 2020 increasing the price to NOK 1500 per annum. This setting will result in the customer being billed NOK 1374,25 on August 1st, 2019. The specification is shown below:

  • Period from 2019/08/01 thru 2019/12/31 covering 153 days = 503,01
  • Period from 2020/01/01 thru 2020/07/31 covering 212 days = 871,23
  • Charge for period from 2019/08/01 thru 2020/07/31 = 1374,25

Details on the calculation are stored with the subscription for inclusion on the invoice/receipt presented to the end-customer. A few days before the next renewal the prices are revisited, and likely updated if a new price change has been configured. 
 

Product Capabilities

The table below shows the different capabilities and to which type of product they apply. GREEN squares indicate that the capability is available for the product type while RED indicates that it is not.

Capability

Product Type
SPECIAL

 Product Type
BUNDLE		 Product Type
DIGITAL		 Product Type
PRINT		 Product Type
COMBO
Access Control          
Bundles          
Campaigns          
Delivery Charges          
Delivery Management          
Delivery Restrictions          
Discounts          
Invoice Formatting          
Payment Method Restrictions          
Purchase Restrictions          
Segmentation          
Access Control

The Aria solution pushes information on subscriptions and the titles and features it provide access to, to an external access control system. Based on the information received, the external system can then determine what articles or stories a customer can have access to. If the customer does not have access to a given article, then the customer is offered to buy an additional subscription to provide the required access. The external access control system is also able to request details on what titles and features a given customer has access to at any time. A single subscription may provide access to multiple titles and features. 

Key parameters for Access Control are:

  • AccessFeature – a product supplemental field found on the service and via the service included in the product. The access feature is used to determine what features on the website a given service provides access to. The default "NEWSPAPER" provides full access to all articles for the titles in question. It can also contain other values like "SPORT", "ECONOMICS", etc. in which case the end-customer is provided access to only articles with that access feature. 
  • TitleCode – a product supplemental field found on the product. The field defines what titles a given product provides access too. What kind of access that is given, depends on the AccessFeature. On one plan, multiple titles can be provided, and the end-customer will then get access to all those titles. 
     
Bundles

Bundles are a mechanism of offering customers access to multiple titles without paying the full price of the digital subscriptions. An example offering could be the “Regional Package” where the client offers customers who subscribe to 3 or more titles and the value of these subscriptions exceed a certain value (e.g. NOK 378) access to the remaining titles for a fixed low monthly price (e.g. NOK 49). The customer is eligible for the bundle when assigning the third title. Other bundles are likely to be added to the solution once the capabilities have been made available. 

When creating a bundle, the client product manager defines the criteria that the customer must meet to be eligible for the bundle. The criteria available are:

  1. Number of customer’s existing subscriptions on products that are eligible for a bundle must exceed a given value, for example 2. 
  2. Value of customer’s existing subscriptions on products that are eligible for a bundle must exceed a given value, for example NOK 378. 
  3. Customer must have an existing (and active) subscription on one or more products to be considered for a bundle. 

The user may configure the bundle to require that all criteria is true or only a single criterion must be true for the bundle to be selected as eligible. 

When creating bundles, the user must select the Aria product (master plan) to be added as a subscription when the bundle is enabled. The bundle is also assigned a status which indicates whether it is being defined, under test, active, deprecated or closed. Each bundle is also assigned a validity period.  

When determining whether a bundle applies, the following rules are adhered to: 

  1. The bundle must have a status indicating that it is active and available for use
  2. The bundle must have a validity period spanning the date on which the bundle is to be applied. Customers remain on the bundle even after the validity period is over, however, if changes are made to the subscriptions, the new check may remove the customer from the bundle.

The bundles are checked in the sequence defined by the client, and once a bundle is found to be eligible, checking is terminated. It is therefore only possible to apply a single bundle at any given time. Only products having a plan product field EligibleForBundles set to true will be checked for eligibility unless, the product is specifically mentioned in the bundle configuration.

When a bundle is assigned to an eligible customer, the master plan identified by the product is added as a subscription for the customer using the rate schedule selected. The bundle remains active until changes are made to the subscriptions for a customer. If changes are made the bundles are checked again, and the current bundle may be removed and replaced with another bundle. 
 

Campaigns

Campaigns are a mechanism for offering individual products for a limited period, usually as intro¬duc¬tory offers, for example sign up for a subscription on a given title and get the first 5 weeks for NOK 5. Once the campaign period is over, the subscription continues with the normal rate until cancelled by the customer. During the transition from campaign to normal subscription, the customer maybe eligible for a bundle. If so, this will automatically be assigned by the solution. A campaign cannot currently be assigned automatically by the solution. Customer or user interaction is required. 

When creating a campaign, the client product manager defines the criteria that the customer must meet to be eligible for the campaign. The criteria available are:

  1. The customer must have certain products as active subscriptions to be eligible for the campaign. The user can define that just one of the subscriptions are required or that all listed subscriptions are required to be eligible for the plan 
  2. The customer must be requesting a title which the campaign covers 
  3. The campaign must have a status indicating that it is active and available for use
  4. The campaign must have a validity period spanning the date on which the campaign is to be applied. 
  5. The customer must not have had the subscription covered by the campaign assigned within a given period. If so, an alternate price of the subscription may be offered, or a completely different campaign is offered. 

When creating campaigns, the user must select the ARIA product (master plan) to be added as a subscription for each title covered by the campaign. During the configuration, the user also configured the one-time product used to cover the initial period of the campaign and the associated cost. 

During configuration it is also possible to define restrictions which are used to prevent “campaign riders” from taking advantage of the campaign. If restrictions are in place, the will prevent the customer from signing-up to the campaign within a given period, for example 6 months. If that restriction is violated, the customer may be offered the same campaign, but a different price or the customer may be offered a completely new campaign. 

The bundles are checked in the sequence defined by the client, and once a campaign is found to be eligible, checking is terminated. However, if restrictions are in place, the current campaign may reference another campaign in which case that campaign is used. 

Delivery Charges

During the sales process the external sales platform is notified if any delivery charges may apply for a given product. Before the purchase is completed, a check is made to see what the delivery charge will be for a given address, and the customer is then allowed to confirm or decline the offer. With the charges it is possible for the client to define that certain products are not charged extra for delivery in certain areas. If delivery charges apply, the customer is assigned the appropriate rate and is then charged both the subscription and the delivery charge. The delivery charge is split into two areas, namely:

  • DeliveryRestNat – a product supplemental field used to specify if any domestic or national delivery charges must be applied. The delivery charges are provided as a set of postal code ranges, for example "0000/0999/POSTAL" which would require any customer living in a postal code between 0000 and 0999 pay the delivery charge identified by the rate schedule as identified by the third field (POSTAL). The value "POSTAL" is appended to the rate schedule ID to determine the delivery charge. 

As with restrictions, it is possible to define multiple delivery charges for the same product, for example "0000/0999/POSTAL1" and "3000/9999/POSTAL2" which would require customers living in postal codes from 0000 to 0999 to pay the delivery charges identified by "POSTAL1" and when living in postal codes from 3000 to 9999 to pay the delivery charges identified by "POSTAL2". Note the delivery charge may also be identical for each range. 

  • DeliveryRestIntl – a product supplemental field used to specify if any international delivery charges must be applied. The delivery charges are provided as a set of country code ranges, for example "AA/AZ/POSTAL" which would require any customer living in a country with a code between "AA" and "AZ" to pay the delivery charge identified by the rate schedule as identified by the third field (POSTAL). The value "POSTAL" is appended to the rate schedule ID to determine the delivery charge. 

As with restrictions, it is possible to define multiple delivery charges for the same product, for example "AA/AZ/POSTAL1" and "IA/ZZ/POSTAL2" which would require customers living in countries with a country code from "AA" to "AZ" to pay the delivery charges identified by "POSTAL1" and when living in countries with a country code from "IA" to "ZZ" to pay the delivery charges identified by "POSTAL2". Note the delivery charge may also be identical for each range.
 

Delivery Management

For products having a product type of "PRINT" or "COMBO" the solution allows the customer to define a delivery address and have the subscription sent to this address for a specified set of delivery days. The delivery address is maintained per subscription, though the actual address can be shared among all subscriptions. If required, the customer can also choose to split delivery between two or more delivery addresses over the course of a week, for example:

  • Deliver the newspaper to address #1 on Mondays and Tuesdays.
  • Deliver the newspaper to address #2 on Wednesdays, Thursdays and Fridays.
  • Deliver the newspaper to address #3 on Saturdays and Sundays.

Note that it is not possible to overlap the delivery days, for example having the Tuesday edition delivered to both address #1 and address #2 at the same time. Changing an address to be valid from a certain date and indefinitely will cause all future address changes to be removed.  

 

Delivery Restrictions

During the sales process the external sales platform, can check if there are any delivery restrictions in place for a given product. With the restrictions it is possible for the client to define that certain products are not delivered in certain areas, or rather the delivery is confined to a specific area. If the delivery restriction is applied, the customer cannot purchase the subscription.

Key parameters for Access Control are:

  • DeliveryRestNat – a product supplemental field used to specify if any domestic or national delivery restrictions must be enforced. The restrictions are provided as a set of postal code ranges, for example "0000/0999" which would prevent any customer living in a postal code between 0000 and 0999 to order the subscription. It is possible to define multiple restrictions for the same product, for example "0000/0999" and "3000/9999" which would prevent customer living in postal codes from 0000 to 0999 and from 3000 to 9999 from purchasing the subscription. 
  • DeliveryRestIntl – a product supplemental field used to specify if any international delivery restrictions must be enforced. The restrictions are provided as a set of country code ranges, for example "AA/AZ" which would prevent any customer living in a country with a country code between AA and AZ from ordering the subscription. As with domestic restrictions, it is possible to define multiple restrictions for the same product, for example "AA/AZ" and "IA/ZZ" which would prevent customer living in countries with country codes from AA to AZ and from IA to ZZ from purchasing the subscription.
     
Discounts

The client uses discounts as incentives to get existing customers to buy additional subscriptions and products. Subscriptions on BUNDLE or SPECIAL products are not eligible for this incentive-based discounts. The rules supported by the solution are:

  1. A discount (percentage) is given to customers who subscribe to X number of eligible products. When creating a product, it is possible for the client to define that a product is or is not eligible for discounts under this rule. Only products where plan product field EligibleForDiscounts is true are considered. The discount can be applied only to new subscriptions. 
  2. A discount (percentage) is given to customers who subscribe to a set of specific products. When specific products are used, the product field EligibleForDiscounts is not considered. To be eligible for the discount, the customer must have all the listed subscriptions active. The discount can be applied only to new subscriptions. 

When determining whether a discount rule applies, the following rules are adhered to: 

  1. The discount rule must have a status indicating that it is active
  2. The discount rule must have a validity period spanning the date on which the discount rule is to be applied. 

The discount rules are checked in the sequence defined by the client, and once a discount rule is found to be eligible, checking is terminated. It is therefore only possible to apply a single discount rule at any given time. 

The customer service representative may assign other discounts at their own discretion, for example if there have been complaints. 
 

Invoice Formatting

On the master plan level, it is possible to define how the subscription and any underlying add-ons are format¬ted by the external invoice formatting engine. The codes assigned to each subscription (master plan) must be agreed with the provider of the formatting, as they will need to react on it when received in the document file transferred to them. A blank indicates that no special formatting is required. 

Payment Method Restrictions

The client can define that a given product can be purchased using specific payment methods only. For example, it is possible to define that digital products can be purchased only using credit cards. Other products may allow any kind of payment method or may extend the choice of payment methods. 
 

Purchase Restrictions

The solution can apply purchase restrictions on individual products. The purchases restrictions are checked right before the subscription is purchased by the customer, and in some cases also with regular intervals. The following types of purchase restrictions are supported:

  • Age restrictions – the age of the customer is used to determine if it possible to purchase a given product, for example students can buy a student subscription only if they are younger than 30 years. If the age restriction is fulfilled at the time purchase the customer can purchase the product. If the subscription is active, regular checks will be performed to validate if the customer is still eligible for the product. If not, the subscription reverts to the normal product. An example configuration for an agreed restriction of under 33 would be ‘AGE|<|33’.
  • Product restrictions – it is possible to define that for the customer to buy a given product, he/she must already have active subscriptions to one or more specific products. For example, the customer can buy the SPORT product only if he/she has also purchased the PRINT edition of the newspaper. 
     
Segmentation

Each product can be assigned one or more market segments. When requesting eligible offerings, the external applications can request products that match the segment provided. Only the segments that match are returned and offered to the end-customer. This provides the ability to define where and how offerings are made. If, for example a product is assigned to segment "B2C", and the external application requests offerings related to segment "B2B", then the product will not be offered. 

Key parameters for Segmentation are:

  • Segmentation – a product supplemental field found on the product which determines what segment a given product belongs to. A specific product can belong to multiple segments at the same time. To be offered to the end-customer only one of the segments must match the criteria provided. 
     

Product Offerings

Any sales platform supported by the client, may request a list of products to which a customer is eligible. When requesting the list of products, the external system must provide the following details:

  • Account ID/Account Number – is passed if the customer is known, the external system must provide the identification of the customer. 
  • Title Code/Title Domain – the external system must provide a list of title codes or title domains must be provided. At least one title code or title domain is required.
  • Access Feature – the external system must provide a list of access features to which access is required. At least one access feature must be provided. 
  • Product Type – the external system must provide a product type, of either ANY, PRINT, COMBO or DIGITAL
  • Product Segment – the external system must provide a segment of either ANY, B2B or B2C. 

The above information is used to determine the offerings to be returned. Each offering (product) returned Is checked for the following:

  • The product must have at least one of the title codes assigned in the TitleCodeOffering product field
  • The product must have at least one or the access features assigned in the list of services on the product
  • The product must have the appropriate segment assigned in product field Segmentation. If ANY segment is requested all products are eligible.  
  • The product must have the appropriate product type assigned in product field ProductType. If ANY product type is requested all products are eligible. 

In addition, a check is made to see if bundles, campaigns or discounts apply for the offering. 
 

Subtopics 

Hyperlinked text

Last modified

Tags

This page has no custom tags.

Classifications

This page has no classifications.
Powered by MindTouch ®