Matrices

Overview

Matrices are a mechanism for automatically deriving and applying a price/charge for a chargeable service that TOT provides to a customer

They are currently used in the following areas :-

Dimensions

Matrices are typically multi- dimensional - that is they are defined on multiple data fields

For example, production costs matrices are composed based on

• Process (i.e. Screen Print Print)

• Position (front, sleeve etc)

• Department Specific Information (i.e number of colours)

• Quantity

The unique combination of these elements forms a "price rung" on the matrix.

When an order is received and processed with the requisite source elements the matrix is called and automatically derives and populates the price field.

Consider the following extract of rungs on a production matrix.

Note the commonality is they are all for a 13 colour print , with the uniqueness based on quantity

You can see that as the number of prints increases , the price per print decreases.

Application

Once defined a Matrix can be applied to a client.

Note that the requirement exists to define multiple matrices for a given area - although the relationship is a single matrix is associated to a client

Allowing multiple matrices to be defined per chargeable area allows differing matrices to be associated to differing clients.

In this way, TOT can offer differential pricing to its clients - for example, higher volume, high worth clients can be offered preferential; pricing.

Application Hierarchy

Hierarchy is also used in price matrices and work in the following manner

1. A matrix can be set at a system level default and will be applied
   1. to any client who has not been associated to a specific matrix
   2. to return a price should the matrix applied to a client not return a price
      
2. The matrix associated to a  client (company) level will supersede the system level matrix, with the exception of situations outlined in b) above
   
3. For clients who have webstores - matrices can be applied at the webstore level - and these will supercede the matrix associated at the parent client level. If a matix is not associated to a webstore, the matrix associated to the parent client will apply (if it exists), else the system level

Considerations for the Future

Charges without Matrices

Matrices do not exist for other areas that TOT charges customers for

Handling Charges

These are currently manually added and manually populated

These charges could be defined in a matrix.

These charges are typically based on a per/hr basis with the user manually recording their time and cost.

This could be automated by applying handling charges by default (or configuring the client record to exclude them)and using start stop triggers on the record in question to derive the process time and thus cost

Currently these charges are manually added / calculated so subject to omission and error.

This is a lost revenue opportunity for TOT

Storage Charges

Storage Charges are calculated on a flat basis and levied on those customers who have a flag set on their customer record

There is a disconnect between customers flagged as such and the population of clients who have stored goods

There is a revenue opportunity to base the charge levy upon the client base with stored goods as opposed to the "opted in" customers

Updating Matrices

Current Matrices are not easily updated to account for price changes

This is especially pertinent for matrices with numerous "rungs"

Serious consideration needs to be given to ability to

• Insert a matrix via file import

• Update a matrix via file import