Configuration Tips - Logics
Dos and Don’ts
Topic | Tip | Details |
---|---|---|
Checking data dependencies | Avoid any complex logic/fetches from the database. Ideally, you should never need more that a single | |
Placing input parameters in logic | Place input parameters high up in the logic, with no or as little as possible dependencies / conditional logic on them. | |
Format Type ‘Money’ | Do not count on the Format Type ‘Money’ to do any currency conversions. It is only a format. | |
Inherited elements should not be changed | When using a parent logic, do not delete or change the order of inherited elements (this is not enforced by the application). |
Tips and Notes
Topic | Tip | Details |
---|---|---|
Order of elements in logic | The order of elements (with the function definition) in the logic is important because the function will be visible only to later elements. E.g. a function defined in the 2nd element will be visible to 3rd, 4th, … element, but it will not be visible to the 1st element. | |
Display Mode ‘Never’ | The setting Never affects also warning messages from | |
Syntax check mode specifics | Beware that in the syntax check mode, some things do not work the same way as in regular execution, e.g. result values of elements return mock values, and some API calls (e.g. | |
Change of default logic | When you set or change the default calculation logic in Configuration, it has no impact on existing Price Lists or Live Price Grids. | |
Calculation Context for Rebate Agreements logics | If you do not specify particular groups (contexts) in Calculation Context of a Rebate Agreement, the logic of this element will be executed in ALL contexts. |
See also performance related recommendations on logics:
Found an issue in documentation? Write to us.