When a customer wants to use an Optimization accelerator, they may need some customizations. How can this be compatible with the benefits of a new accelerator version? This page is relevant for any of the following accelerators:

• Accelerate Clustering

• Accelerate List Price Optimization

• Accelerate Markdown Optimization

• Accelerate Multifactor Elasticity Optimization

• Accelerate Negotiation Guidance

• Accelerate Price List Impact Simulation Package

• Accelerate Price Waterfall Optimization

• Accelerate Product Recommendation

• https://pricefx.atlassian.net/wiki/x/LwABSwE

• Accelerate Shelf Prices Optimization

It provides tips about versioning control, coding, and responsibilities to make the customized accelerators' maintenance and evolution easier.

Typical Optimization Accelerator Elements

The Optimization accelerators are mainly composed of:

• A Model Class: a JSON file defining a calculation process and a list of dashboards

• Some logics, calls by the Model Class, including a library logic

• the preferences defining the dashboard appearance

Git Setup

First, use Git to keep your project history. It is recommended to use the same repository as the other configuration work, generally: https://gitlab.pricefx.eu/logic/<customer-name>>-logic

You can fetch the Logics, Model Class, and preferences corresponding to the accelerator from the partition where you deployed the accelerator. Or you can fetch them from the Gitlab repository of the accelerator if you have access to it. In this last case, take care of fetching the right version (there are tags in Gitlab) or the master branch version. Don't start from the develop version: it is not a stable version.

There are some tips for the pricing scientists to work on their Gitlab projects here: https://pricefx.atlassian.net/wiki/spaces/CUST/pages/4747493552.

Responsibility

You need to be aware that your changes are done on your responsibility. It means that we cannot assure a new version of the accelerator will not create a conflict with your own changes. But we try to make the improvements the best way for you to be able to update the accelerators and keeps your own changes.

To help this, there are some rules:

1. Some changes are very straightforward and don't hesitate to do them:

   • you can have your own display preferences and don't get the default ones

   • all the labeling is stored in the library, in the element LabelsUtils. Change the labels in this place to match your company naming conventions

2. Consider the size and the interest of the change you want to implement. If it is something complicated, or if you think that it may be something interesting for other customers, the Engineering team can maybe include the improvement in the standard accelerator? Then we would take responsibility for the piece of code.

3. For the other changes, follow the best practices below.

Modification best practices

Be Aware of the Code Structure

First, you need to understand which logics correspond to which part of the accelerator. It is much easier to work on them if you know the basics about model classes: Model Classes and Models Overview. An added step or an added tab are easy to follow: they correspond to new files and a small change in the Model Class JSON file. You can also remove a tab by a single change in the Model Class file.

Then, each accelerator documentation contains a section called Technical User Reference where the structure of the accelerator is described:

• Which Logics correspond to which step, calculation, dashboard;

• The main goals of each Logic;

• The main outputs of each Logic;

• The common reasons that could lead to modify any Logic.

Code in the Right Places

An important point is to try not to make changes in too many different places. Each accelerator has its own library. Use the library: add utils, modify utils to fit your expectations.

All the naming conventions and the labels are in the accelerator library, called <prefix of the accelerator>_Lib. Use it to change the labels to display (user entries, keywords in the charts…)

If you want not to display an element, better removing it, or returning at the start of the file, rather than commenting all the lines. The diff is easier to understand, at the update if you are not polluted by the comment characters at the start of each line.

If you want to change totally a tab (dashboard) and you are not interested in the changes on it, you would rather create a new tab, with a new name, and remove the previous one. This way, when you update the accelerator, you don’t compare your custom tab with a standard one. Removing a tab is a change in the ModelClass JSON file only. You don’t need to change anything in the logic, if the model class does not refer to it anymore.

Update to a New Version

When there is a new version of the accelerator, the following steps will help you to apply your changes to it.

1. On your repository, create a new branch, called for instance version-XXX.

2. Replace the Model Class file, the accelerator Logics files, and potentially the preferences file, with the ones corresponding to the accelerator’s new version.

3. Move to your work branch and rebase on the branch version-XXX. You may have some conflicts to solve, only on the files changed in both the official new version and your customized version.