Calculator Capabilities

Fulfillment service can provide fulfillment options at the fulfillment group or item level. By group is the simplest model where an application presents a single fulfillment option for the entire group (which is synonymous with the cart for simple applications).

Options by item is useful for applications that want customers to choose the fulfillment method for each item instead of as a group.

Calculators can be configured to calculate the fulfillment price by item price or weight. When pricing by weight, a unit of measure will be required. Broadleaf ships sample units of measure conversions. Additional conversions and unit of measures can be supported by extending the WeightCalculationHelper.

Calculators are typically configured to use the total weight or total price based on the Eligible Items which refers to the specific items being priced.

For some implementations, it may be desired to use the entire cart price or the entire fulfillment group price as the base value for some calculators.

Calculators can be configured to support certain origin and destination pairs. For example, if an implementation had a Europe warehouse and a US warehouse, the price to ship items from US to US would typically be lower than the price to ship from Europe to US and vice-versa.

Configuring the origin and destination restrictions for calculators is useful for these scenarios.

Calculators can be configured to use a rate or a fixed amount. If using a rate, the total item weight or price will be multiplied by the rate value to calculate the fulfillment price.

If using fixed amount, that amount will be used as the fulfillment price.

In both cases, the source total is used to determine the correct "band" or "FulfillmentPricingTier" to use for the calculation.

The order that calculators run is important. For DB calculators, a priority can be set. If priority is left unset (e.g. null) it will run after DB calculators with a priority set.

Note, there are two priority concepts that allow control of calculator ordering. One via code and one via the DB priority field. Code calculators can utilize the calculatorTypePriority to control whether code calculators operate within the same priorities as user specified DB calculator priorities or to control them always running before or after the admin maintained priorities.

Code calculators can by setting them to inactive via code.

For a DB calculator to be active, it must have a start date before now and a blank end date or an end date after now. A DB calculator can also be disabled by setting it’s active setting to NO.

Each calculator can configure an estimated min and max days for delivery.