Revision as of 20:27, 27 August 2017

1 Overview

Even within a bxp form there is the ability to add prices and revenues to the form. Choosing the right model and storage approach varies greatly but bxp provides a number of models and options to facilitate the model needed.

The model requires you to understand the different between a form CDA and a CCL. CC-1-3_Introduction_to_the_Blended_Form_Structure

2 Configuration Options

All these options are configurable for a form through Main Menu > Form Management > Form - Primary Management > Form - Advanced Settings > Revenue Engine

2.1 Primary Model Options

2.1.1 Model

Revenue Model. Do we use None, CDA, CCL or Both?

None means engine not used, the default for all existing forms.

If it’s a CDA, then each record has a value. This perfect for CRM, Outbound Debt Collection and Membership Management. Each record has a potential set value which is worked out. If we have 100 records. Each record owes €100, the universe is €10,000 potential and you can work out the rest from there.

If it’s a CCL, then each contact has a potential value. So this is like a sales process or shopping cart type approach. You can no longer easily predict how much is coming in, but you can sum it up as it does. This is better for a "till" type scenario.

If it's both then CDA and CCL are used. This can be useful for a membership form where you have an annual renewal. the CDA keeps the current amount and the CCLs keep a history of what the Member has paid to date.

2.1.2 Challenges

So when you’re dealing with Money in bxp, the challenge is lots of contacts. I have a potential of X revenue from a record, I contact the record multiple times. Which one gets the kudos for the sale? What if an agent uses the wrong outcome twice. That kind of thing.

2.1.3 CDA Config

For CDAs, are we using a Replace or Ignore model.

When a second contact is made which would result in a sale / amount update, to we ignore the new numbers, as the value has already been historically added, or do we replace the value. This allows the builder decide what works best.

With Ignore, as soon as it’s in, it’s in. With Replace, totals will move depending on the date.

2.1.4 CCL Config

For CCLs, One only, Update or All.

One Only, will check all historic CCLs and if there’s a billing in there already, then don’t add another. This preserves reporting to historic first only.

Update, will mean that any figure updates will be pushed into the historic CCL still keeping only one CCL with billing.

All, means a second, third, fourth CCL with billing all get added.

2.1.5 Outcomes

This is the values of the Outcomes, separated by commas, which will trigger the revenue engine to kick off.

2.1.6 Margin Report

So the basic of selling something... Amount, VAT and Total.

bxp can also store a Cost amount. Marrying what the sale cost with the revenue generated can provide better analytics.

So do you take the cost away from the Amount or the Total. Different scenarios require different approaches and different days require different perspectives. So we have a Net and a Gross total.

Net means the cost is subtracted from the Amount. Gross means the Amount is subtract from the Total.

This option also changes the reports dynamically as it will choose this option to display, use the Net or the Gross, or Both when displaying revenue reports for this form.

2.2 Calculation Values

So when a process is to kick off the engine needs to know where to look for the values to do the calculation and storage.

2.2.1 Product Field

This field is where the system chan find the different types of items sold. The premise here is that there is a field which contains a closed question type field listing the product sold.

If the form is a till then the field will not serve much value. If the form is used for Membership, this field would be the membership type.

2.2.2 Products Value

This field will contain one of two things. If the contents are a field name, e.g. strCDA_X_field_Y_Z the system will use this field to create a list of the products. Otherwise it will contain a list of comma separated products. These values will be matched against the Product Field.

2.2.3 Price Values

This field needs to be a perfect match for the Products Value field. If there are 10 values in the Products Value field, there needs to be 10 prices in the Price Values field.

Similar to the Products Value field you can use a field name or comma separated values.

The amount of values must match or the engine won't process.

2.2.4 VAT Values

This field is a smart field. It needs the same amount of values as products and prices. If there is a % value in the string, then it will be calculated. If not it will be treated as a set amount.

If it is a field name then the field will be loaded instead.

The amount of values must match or the engine won't process.

2.2.5 Cost Values

So working out the cost of the activity is either a

• single value (0 is a very easy way of saying... nope, don't want to work out costs)
• field name (the field will read the values from that field)
• comma separated values ( must match the products, vales, etc. )

2.2.6 Cost Currency Values and Price Currency Values

Like Cost values the codes here are three letter representative codes for currencies:

• single value (EUR is a very easy way of saying... nope, don't want to work out currencies they're all EURO)
• field name (the field will read the values from that field)
• comma separated values ( must match the products, vales, etc. )