UD Fields within rebates Module and their uses

Rebates
1

Hi,

Discussions are underway with Phocas regarding this, however considering the capabilities this would bring to the base system, I thought it important for other rebate users to be aware.

The business require the ability to capture more information regarding the agreements than the set fields currently available. Elements such as (not exhaustive):

Description fields
Large text fields to capture the english full working out of the rebates.
Additional grouping fields.
Currently fixed to 2 fields in standard rebates, having the option to have more fields to allow filtering either within the rebates module or database are imperative for easier use.
Fields for additional calculations
We require to perform additional calculations on the Phocas rebate value once calculated. Having UD fields which allow us to store a value (for example percentage) which can then be used in the database designer to generate additional calculations on the rebate results would be a game changer.

Regards,

Jon

2

Agreed, Jon.

We’re currently achieving this via back-end scripts to calculate new measures. I agree that this functionality requirement is common among users. Users would benefit by “surfacing” these variables in order to self-manage and maintain - particularly because these variables are subject to change at least on annual basis.

Thanks for the update.

1 Like
3

Hello @JonKemp and @KPaquette.
Thank you for starting this conversation. This is very much something which we will aim to address in a coming release and are in the planning stage.
I do have a few questions :

  • How many fields and which types of fields would you say are the most relevant to yourselves?

  • Concerning the description fields, would the existing comments help you? How important are these fields for analysis ?

  • Can you plase elaborate on the sort of calculations that you carry out ? How important is it that you carry out these calculations in Rebates vs a field in your analysis database for example?

  • Assuming this would be in Rebates, could we solve this problem by integrating additional calculations in the UI or at calculation time for example, rather than simply creating additional custom fields ?
    I am sure there will be a lot more conversations on this subject but I look forward to hearing back.

Many thanks
Nicolas

4

Hi @nicolas.servouse,

As we have met and discussed my clients needs for grouping and further narative fields in depth, I will just expand on the point regarding calculations.

Within rebates, although Phocas provides accurate numbers for us, one element that we now have to achieve is applying a forecast percentage value against the sales value/quantity.

The aim is to have the accurate rebate amount (provided by Phocas) and a sales forecast rebate amount (which uses this new percentage UD field). This is a double whammy for the business as it provides a projected rebate amounts and identifies if any sales forecasts need ammendment.

For us to achieve this without considerable back end excel file imports and some creative database work, having a UD field which is stored in the feed results will allow us to perform a line by line calculation of the forecast percentage amounts.

The challenge is with the Excel upload approach we loose granularity as we can only pin at the agreement/rebate level. We want to use these forecast percentages on each rebate line.

Consider the following:

  1. Rebate created called “Amazon CY” which is applied to a group field which consists of 10 customers, now lets say a 0.05% forecast is expected on Products 1,2 & 3.
  2. Phocas calculations will peform the inital filtering of the sales data and specific SKUs in question. This will provide the total amount of sales which are to have rebates applied.
  3. The business want to see how this forecast percent would appear across all of the results of that rebate.

In the above scenario, we cannot rely on an Excel spreadsheet as we cannot connect the rebate to apply across all the individual lines in the rebate results feed.

i.e. we need to do 0.05% of “transaction amount” (sales filtered before rebate). We can get the overall forecast value at the rebate level, but loose granularity when viewing at the customer and part level (or any other way wish to slice).

A picture paints a thousand words:

Showing forecast at rebate level:

image
image1260Ă—143 26.5 KB

You should see that the “CY Differences” is showing a variance between what they actually are entitled to versus the sales forecast on Rebate 3.

Now lets say I want to dig into Rebate 3 to review where the differences are, switching to the customer or the SKU:

image
image1263Ă—118 12.2 KB

Notice we now have lost granualarity, we now have two lines as the percentage is not mapped to the customer, only the agreement.

Making use of the UD fields within the results feeds would provide great flexibility as businesses can apply all manner of customised calculations which will be granular.

As my colleague Steve sent you an email regarding this, you are more than welcome to give either of us a call to discuss futher.

Regards,

Jon