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

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

Overview

The figure below shows the overall account model as maintained within Aria and how it is used in the AMPS solution depicting each of the major components of the model. 

Overall Account Model.jpg 

It consists of 4 major components, namely: 

  • Account – defines the account which is either a business or consumer account. The account defines key attributes such as account address, billing address, currency, tax identifications, tax exemption levels, etc. If required, several accounts can be organized in a parent/child relationship.  
  • Payment Agreements – the term payment agreement is not explicitly defined by Aria, but rather by the solution built and implemented for AMPS clients. The current solution design for AMPS sees a payment agreement consisting of precisely one billing group and precisely one dunning group. The one-to-one relationship is enforced by the solution even though ARIA allows the elements to be split. In the solution, creating a billing group will automatically create a dunning group as well.  The customer may have multiple payment agreements in place at any given time.  
    • Billing Group - the billing group defines how the subscriptions linked to a billing group is billed and holds key attributes such as billing address, payment method, payment term, invoice templates, credit note templates, etc. A single invoice is produced for each billing group for any subscriptions billed on the same day. Billing combines Aria Core functionality with functionality developed in Aria Workflow specifically for AMPS. The payment terms assigned to a billing group is based on the selected payment option and the title for which the billing group has been set-up. 
    • Dunning Group - the dunning group defines how the subscriptions are processed if payment is not received in due time. The dunning group references a dunning process, which in turn defines the steps the dunning process goes through. Dunning combines Aria Core functionality with functionality developed in AMPS Workflow specifically for AMPS. The dunning process assigned to a dunning group is based on the selected payment option and the title for which the billing group has been set-up. 
  • Payment Methods – payment methods exist only if the customer uses one of the Aria built-in electronic payment methods, for example credit card. The payment method is created automatically when the customer registers a new credit card in the solution. The payment method is then assigned to a billing group as either the primary or backup payment method. Payment methods are not created when the customer selects Bankgiro, Avtalegiro, Efaktura, Elektronisk Handelsformat (EHF) or SPID Credit Card payment terms which are in scope for the Polaris Media Solution. 
  • Subscriptions – subscriptions are used to describe the products purchased by the customer and billed with regular intervals. A subscription always consists of a master plan instance and may have multiple or no supplemental plans assigned to it. The master plan instance is linked to the billing group under which it is billed, and to the dunning group under which it will be processed if payment is not received in time.  
    • A customer may have many subscriptions active at the same time, each having their own billing cycle. One subscription can be on an annual plan, while another is billed monthly. Supplemental plan instances under the master plan, may have different billing cycles, but the master plan instances must have the shortest billing cycle, i.e. it is not possible to have master plan instance on annual billing with the supplemental plan instance on quarterly billing.  

Each of the above components are described in more detail in the following sections.  

Accounts

The account is the cornerstone of the overall solution designed for AMPS. In most scenarios a customer is identical to an account, as one customer normally requires only a single account. Aria does support creating a parent/child relationship between accounts. 

The solution operates with two different kind of accounts, namely: 

  • Consumer – the account has been setup for a consumer customer, usually a person.
  • Business – the account has been setup for a business customer, usually a company or corporation.  

Within the implemented solution, there is not much differentiation between the two types of customers. The details on the kind of account is made available to external systems, for example the data warehouse. Instead the differentiation is found on the product level and will appear once the product has been purchased by the customer and created as a subscription.  

The account contains information on the following topics: 

  • Name and Address – contains details on the name and address as it relates to the customer account. These names and addresses will be used when sending communication to the end-customer, for example invoices. Three different addresses are maintained, namely account address, billing address and statement address.  
  • Status – contains details on the status of the account, including status change history. An account is by default active and will remain so until changed by the end-customer or client staff. An account will remain active if there are active subscriptions assigned to the account. A parameter driven number of days after the last subscription has been terminated or cancelled, the account will also be made inactive and eventually archived. Once an account has been archived it cannot be activated again. Instead the customer must have a new account created.  
  • Notes and Comments – contains details of notes and comments generated by the Aria application, for example when changing the status of a subscription, or assigning new billing / dunning groups. The notes and comments are always generated in English and is not suitable for presentation to the end-customer. Services in ARIA workflow also generate additional notes and comments, at appropriate times.  

To extend the account with additional information, account supplemental fields have been added to the account. These fields are used to store information on the customer for which no other logical place exists in Aria. The following fields have been added: 

  • Owner Title Code [OwnerTitleCode] – a field that holds the code identifying the title (newspaper) where the customer was first created. The owner title code is usually set based on the website from where the customer was setup and made his/her first purchase. For customers created via the CSR application, the CSR selects an appropriate title code.  
  • GL Dimension 1 – Profit Centre [GLDimension1] – a field that contains the profit center assigned to the customer. The profit center is transferred to the ERP systems during the revenue recognition process and is used by the ERP system to correctly report on the revenue.  
  • Migrated Customer ID [MigratedCustomerID] – a field that contains the identification of the customer as found in the source system from which it was migrated. When migrating from source systems to Aria, several customers in the source system may be combined into a single customer in Aria. In that case the Migrated Customer ID will contain multiple entries. The field is not set for accounts created directly in Aria.  
  • Reservation Code [ReservationCode] – a field that contains a code indicating the level of reservation the customer has defined. Values and use of this field are solely defined by the client. The reservation code is transferred to the data warehouse system for further use.  
  • Channel Code [ChannelCode] – field that contains a code indicating the channel from where the customer was first created. Values and use of this field are solely defined by the client. The channel code is transferred to the data warehouse system for further use.  
  • Source Code [SourceCode] – a field that contains a code indicating the source of the customer when it was first created. Values and use of this field are solely defined by the client. The source code is transferred to the data warehouse system for further use. 
  • Gender [Gender] – a failed that contains the gender for the customer as selected by the customer at point of sale. Values and use of this field are solely defined by the client. The source code is transferred to the data warehouse system for further use. 

Other fields may be added when requirements change and based on the specific needs of the Client.  
 

Payment Agreements

A payment agreement is a term used about the agreement between the client and the end-customer on how bills are issued, processed and paid. A customer may have multiple active payment agreements to best suit their needs, each with different subscriptions assigned. One payment agreement could allow the customer to pay by credit card, while another requires the customer to pay (for example) by Avtalegiro or Bankgiro. The customer will in general receive an invoice for each payment agreement with active subscriptions.  

In Aria a payment agreement is built using two standard elements, namely: 

  • Billing Group – an element used to describe how a selection of subscriptions are billed as a single unit. Though the billing day is driven by the individual subscriptions, any subscriptions billed on the same day, will be included on the same invoice. The billing group defines attributes such as payment method, invoice templates, credit note templates, statement contacts, etc. 
  • Dunning Group – an element used to describe how subscriptions that are not paid in due time is processed, for example by sending reminders, posting additional fees and eventually suspending the subscriptions. The dunning group defines attributes such as dunning process, dunning steps, dunning fees, etc.  

In the current AMPS solution, there is a one-to-one relationship between the billing group and dunning group. The solution generated ID for the billing group is prefixed with "BG-" while the dunning group is prefixed with "DG-". The remainder of the identifier is built using the same UUID, for example "e720c676-f89e-4e79-a63e-bcef62b18aed". This would result in the billing group being named "BG-e720c676-f89e-4e79-a63e-bcef62b18aed" and the dunning group named "DG-e720c676-f89e-4e79-a63e-bcef62b18aed".  

The description of the billing group and dunning group is automatically generated by the solution and MUST not be altered or amended with by the end-user. The solution requires the description to be formatted in a certain way. The description which looks like: 

"BANKGIRO [TitleCode=XX]/[Option=BANKGIRO]/[Variant=STANDARD]" 

As can be seen above, the description contains details on the current title code, payment option and payment option variant.

When creating or updating the billing group the form of payment is determined by the choice made by the customer, or by actions made by the customer in his/her internet bank. The form of payment is determined by the payment option, which from the outset can be one of the following: 

  • BANKGIRO – the customer has chosen to receive an invoice and pay by registering the KID number provided in his/her internet bank. The banks then send details on the payment to the clients AMPS solution and the invoice is matched and considered paid. When setting the precise payment terms for BANKGIRO, the title code is used to determine to precise payment terms. 
  • SPID CREDITCARD – the customer has chosen to receive an invoice and immediately pay the invoice by charging their credit card. The credit card is kept on-file in ARIA core as part of a payment method, and then linked to the billing group. The same payment method can be used by multiple payment agreements. Again, the title code is used to determine the precise payment terms.  
  • EHF – the customer has chosen to receive an invoice and be informed of this invoice via the EHF (Electronic Trading Format) solution, which is primarily used by public or government institutions. When registering the agreement, the customer must provide an organization number (EAN/GLN Number) and an optional requisition number (EAN/GLN Requisition Number). These two values determine where the invoice is sent and what project the charge covers.   

Via the banking systems, the customer has the option to registered for other payment options, namely: 

  • AVTALEGIRO – a direct debit scheme operated by the banks in Norway. When paying a bill, the customer can register for Avtalegiro and all future payments will go via this solution. The banks notify the client solution that a customer has chosen to pay by Avtalegiro and when this notification is received by the solution the payment option on the payment agreement is changed accordingly. During the update, the payment terms are changed (and potentially so is any invoice fees). The agreement remains in effect until cancelled by the customer 
  • EFAKTURA – a notification scheme operated by the banks in Norway. The customer will receive a copy of the invoice electronically, once they have signed up for it. The customer still pays via traditional BANKGIRO payments (OCR payments). When the customer signs-up for EFAKTURA the banks notifies the solution about the agreement, and the payment terms on the payment agreement is changed accordingly.  
  • EFAKTURA / AVTALEGIRO – this payment option is a combination of EFAKTURA and AVTALEGIRO. The customer is notified electronically via the EFAKTURA solution, but payment flows through the AVTALEGIRO solution. If the customer is already on EFAKTURA, and then signs up for AVTALEGIRO this is the payment option chosen. If the customer was on BANKGIRO and then signs up for AVTALEGIRO, the AVTALEGIRO option is set. If the customer cancels the AVTALEGIRO part, the payment option reverts to EFAKTURA as future payment option. If the customer cancels the EFAKTURA part, the payment option reverts to AVTALEGIRO as the future payment option.  

The above options cannot be set directly by the customer via the solution. During migration any of the above payment options can be set directly for a new payment agreement. 

When setting the payment option, the title code of the first subscription on a payment agreement is used to determine the payment terms and dunning process. If the customer assigns more subscriptions to the same payment agreement, the terms are not changed as such. However, if the customer cancels or otherwise removes the subscription that drove the title code, a check is made to see if the terms need to be changed as the title code has changed. This happens automatically when the change happens.  

When creating or modifying a dunning group, a dunning process is assigned automatically based on the title code determined by the subscription and payment option chosen by the customer. Cancelling subscriptions and adding new ones and/or changing the payment option, may see the dunning process change automatically. The dunning process is used to determine what happens if the customer does not pay the invoice, either partially or fully, before the due date. As an example, the dunning set up may consist of three dunning steps, namely: 

  • Dunning Notice 1 – dunning notice 1 is sent to the customer after a configurable number of days. A dunning fee may have been charged depending on the configuration. Dunning fees will not be configured by Polaris Media as part of the initial implementation.  The KID number used for the dunning notice, is identical to the number issued with the invoice, allowing the customer to pay either.  
  • Dunning Notice 2 – dunning notice 2 is sent to the customer after a configurable number of days from the first dunning notice. The client can configure the dunning process to charge a new dunning fee and remove the dunning fee charged by the first dunning notice. Dunning fees will not be configured by Polaris Media as part of the initial implementation. Again, the KID number used for the dunning notice, is identical to the number issued with the invoice and first dunning notice, allowing the customer to pay either. 
  • Final Dunning Notice – the final dunning notice is sent to the customer after a configurable number of days from the second dunning notice. The client can configure the dunning process to handle the final dunning notice in a special manner. The final dunning notice is most likely sent after the subscription period is started, and therefore the client has delivered newspapers for which no payment has been received. As part of the final dunning notice, the solution will create an invoice covering the period where newspapers were delivered but not paid for.  

As with the other dunning notices, the final notice is issued with the same KID number as the original invoice and any preceding dunning notices, allowing the customer to pay for either. If the customer pays for the original invoice (or one of the first 2 dunning notices), the subscription is kept active, and relevant dunning fees are cancelled, and everything continues as if no dunning had taken place. If the customer pays the final invoice, then the payment is matched, and the original invoice is cancelled (voided) as if it was never issued. Details are transferred to the ERP system on the invoice that was actually paid. 

Polaris Media will configure specific dunning processes in line with their commercial credit policies.   

Payment Methods

When the customer registers a credit card in the solution, a payment method is updated to store this information according to PCI and other compliance rule sets. When the payment method has been created it is assigned to an existing payment agreement (via the billing group). A single payment method can be assigned to different billing groups and thereby reused across multiple payment agreements. The customer will see a credit card charge for each billing group to which it is assigned. Charges are not combined.  

Certain details on the credit card is made available for inclusion on invoices and/or other communication. The following details are available: 

  • CC Type – the type of credit card registered, for example VISA, Mastercard, Amex, Diners Club, etc.  
  • CC Expiry Month – the month to which the credit card is valid.
  • CC Expiry Year – the year to which the credit card is valid. 
  • CC Suffix – the last 4 digits of the credit card number is also available.  

Subscriptions

Subscriptions cover the products that the customer has purchased on a recurring basis. The customer may also order one-time products, but these orders are always linked to an existing subscription. A subscription consists of two different components, namely: 

  • Master Plan Instances – this is the highest level of the subscription and is the level that drives the overall billing of the subscription. A subscription will always have one master plan instance created referencing a master plan. Each master plan consists of one or more chargeable services, though a charge is not required to create a master plan instance.  
  • Supplemental Plan Instances – this is the lower level of the subscription and primarily defines additional charges the customer may choose when purchasing the subscription. A supplemental plan instance will always link to another supplemental plan instance or to a master plan instance. It is not possible to assign a supplemental plan to a master plan or other supplemental plan unless the product catalog reflects that link.  

Note: See "Aria Media and Publishing Suite (AMPS) - Conceptual Product Model and Capabilities" for details on the target product model defined for AMPS.

 

AMPS Account Models

This section contains a brief description of the account models used in the current solution. The following models are covered: 

  • Migrated Account – shows the typical migrated customer account, with a customer having two subscriptions on different titles.  

  • Business Account shows a typical business account, with the owner responsible for payment, but still with individual employees registered for delivery of a physical newspaper.  

  • Consumer Account shows the typical consumer account, created directly in the new solution, i.e. it has not been migrated to the solution.  

  • Complex Account shows the overall capabilities of the account model the solution supports. The account has several different payment agreements, different subscriptions and different payment methods.  

Each of the above models are described in detail in the following sections. 

Migrated Account Model

The figure below shows three customers migrated from three different titles in the source system into a single customer account in Aria. Though the customer previously existed for three different titles, they were in fact the same customer.  Each of the customer's subscriptions are migrated to a separate subscription in Aria, each having their own payment agreement and using the payment terms migrated from the source system. 

Migrated Account Model.jpg

With the above model the customer will receive three individual invoices, one for each title. One of the subscriptions are paid with the credit card on file, while the second and third are paid using their respective Avtalegiro payment term.  

Business Model Account

The figure below shows a business account with two subscriptions. Each subscription allows up to 100 employees to be assigned, and the supplemental plans represent the employees currently in existence. Both subscriptions are paid by Bankgiro / OCR and combined, if possible, into a single bill.  

Business Account.jpg

The customer can add or remove employees as required, as long as the total number of active employees does not exceed the limit of 100 for each of the subscription. 

Whilst the above business model is available for use within the Polaris Media implementation it is not planned to mix titles within a single invoice as they are currently managed separately with regards to finance processes. 

Consumer Account Model

The figure below shows a simple and straightforward consumer account with a single subscription paid by Bankgiro / OCR and for a single title.  

Consumer Account Model.jpg

If the customer purchases a second subscription, he/she can decide to create a new payment agreement, for example because payment should be by credit card, or the second subscription could be linked to the existing payment agreement, and thereby receive a single bill for two subscriptions. 


Complex Account Model

The model shown below is more complex with several subscriptions, several payment agreements and a shared payment method. Two subscriptions (DT and RB) are billed as a group using a credit card. One subscription (AS) is billed alone but using the same credit card as the first two subscriptions. The last two subscriptions (AF and AP) are also billed together but paid via Avtalegiro.  

 Complex Account Model.jpg

During the life-cycle of a customer subscription, payment agreements and payment methods can be added as required, and existing subscriptions can be reassigned to another payment agreement if that requirement should arise.  

 


Subtopics 

Hyperlinked text

Last modified

Tags

This page has no custom tags.

Classifications

This page has no classifications.