Skip to main content

Business logic — advanced

This page covers the deeper business logic options. They let you express complex pricing — time-based fees, "either/or" conditions, and rules that depend on other tariffs. They're powerful, so test changes in a real calculation afterwards.

Combining conditions: evaluation sets​

By default, all of a tariff's conditions must be true (an and). An evaluation set lets you express or logic:

  • Conditions that share the same evaluation set name are combined with or — any one of them passing satisfies the set.
  • Different evaluation sets must all pass (they're combined with and).

So to say "applies to tankers or gas carriers, and only when GT > 5,000", put the two ship-type conditions in one evaluation set and the GT condition in another.

More condition kinds​

Beyond the basic numeric/string/boolean/date conditions:

  • Array — check a value against a list. Choose an array operator (such as in / not in) and enter the values (one per line).
  • Date — between — choose the between operator and provide a second value for the end of the range. (Numeric conditions likewise offer between / not between with a second value.)
  • Schedule — match against time windows. You add schedule items, each with a from and to (a value plus a schedule type), and a schedule operator. Use it for day/night or opening-hours pricing. A source field min/max picks the times to test.
  • Timespan — compare a duration: a value plus a period (e.g. hours, days) with a timespan operator. Use it for "longer than 24 hours".

Period calculations​

A period calculation charges per unit of time and is the most configurable calculation:

  • Period + period quantity — the unit of time and how many of them (e.g. per 1 day).
  • Source field min / max — the start and end times to measure between (for example arrival and departure).
  • Interval quantity — how the measured time is stepped into chargeable units.
  • Min quantity / max quantity — a floor and a cap on the number of units charged (e.g. at least 1 day, at most 30).

This is how "berth dues per started day, minimum one day" is built.

Calculation order​

When a tariff has more than one calculation, calculation order (a number) sets the sequence they run in — important when one calculation builds on the result of another. Lower numbers run first.

Dependencies​

Dependencies make a tariff's behaviour depend on something else:

  • Tariff dependency — refer to another tariff by its tariff system code (for example only apply this fee when another tariff was applied).
  • Tariff group dependency — the same, but referring to a whole tariff group system code.
  • Address dependency — drive behaviour from an address (with an address type and additional data).

This is why system codes matter: dependencies find their target by code, so renaming or changing a code can break a dependency.

VAT conditions​

The VAT conditions tab lets the VAT treatment vary by condition, so the right VAT code is chosen automatically based on the data — rather than a single fixed VAT code for the tariff.

Customer filters​

The Customer filter logic type (introduced in the basics) restricts a rule to a specific customer, customer financial record, or debtor number — a quick way to make a tariff (or condition) apply to just one debtor.

Line grouping​

Line grouping controls how resulting amounts are combined onto invoice lines (for example "apply once per call"). It has no editable form in this screen and is configured separately — if you need it, check with your administrator.

caution

Advanced business logic changes what gets charged. After any change, run a real calculation (or use the cost calculator's test run) and confirm the numbers before relying on it.