Form - Revenue Engine - Revision history

Philip Lacey at 19:39, 27 August 2017

2017-08-27T19:39:27Z

Philip Lacey at 19:27, 27 August 2017

2017-08-27T19:27:53Z

Philip Lacey at 17:34, 27 August 2017

2017-08-27T17:34:06Z

Philip Lacey: /* Configuration Options */

2017-08-27T17:25:04Z

‎Configuration Options

Philip Lacey: Created page with "= 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 provide..."

2017-08-27T17:20:46Z

Created page with "= 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 provide..."

New page

= 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]]

= Configuration Options =

== 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.

== 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.

== 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.

== 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.

== Outcomes ==

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

== 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.

← Older revision		Revision as of 19:39, 27 August 2017
Line 167:		Line 167:
	* field name (the field will read the values from that field)		* field name (the field will read the values from that field)
	* comma separated values ( must match the products, vales, etc. )		* comma separated values ( must match the products, vales, etc. )
		+
		+
		+
		+	== Storage Options ==
		+
		+
		+	The storage options are used to specify, if using the CDA model, where the values are stored. With a CCL the fields are part of the CCL structure and do not need to be set.
		+
		+
		+
		+	[[Category:Module Specific:Form Management]]

← Older revision		Revision as of 19:27, 27 August 2017
Line 108:		Line 108:

	=== Product Field ===		=== 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.
		+
		+
		+
		+	=== 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.
		+
		+
		+
		+	=== 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.
		+
		+
		+
		+	=== 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.
		+
		+
		+
		+	=== 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. )
		+
		+
		+
		+	=== 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. )

@@ Line 14: / Line 14: @@
 == Model ==
@@ Line 34: / Line 36: @@
-== Challenges ==
+=== Challenges ===
@@ Line 41: / Line 43: @@
-== CDA Config ==
+=== CDA Config ===
@@ Line 54: / Line 56: @@
-== CCL Config ==
+=== CCL Config ===
@@ Line 70: / Line 72: @@
-== Outcomes ==
+=== Outcomes ===
@@ Line 77: / Line 79: @@
-== Margin Report ==
+=== Margin Report ===
@@ Line 95: / Line 97: @@
 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.

← Older revision		Revision as of 17:25, 27 August 2017
Line 9:		Line 9:

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