Dynamic Shipping Cost Calculator

Quotes start from seven flat fields: shippingType, weight, the length, width, and height dimensions, distance, and customerTier. The graph fans this out to the base-rate and season tables in parallel before merging everything into the final price.

A nine-row matrix crosses shippingType against weight brackets under a first hit policy, writing the result to baseRate. Each service has three bands, under 20kg, [20..50], and above 50kg: 'standard' runs 10, 15, 25, 'express' runs 20, 30, 45, and 'priority' runs 35, 50, 75.

Bracketed base rates like this mirror how published carrier rate cards work, where a handful of weight breaks keep quoting predictable instead of pricing every kilogram continuously. The roughly 2x step from standard to express and again to priority within each band is a business choice that keeps the speed premium consistent across weights.

Season detection reads dayOfYear('now') rather than any request field: days below 80 or above 355 map to 'winter', days between 172 and 265 map to 'summer', and the blank catch-all returns 'regular'. First hit ordering means the two winter rows cover both ends of the calendar before the summer band is checked.

Those cutoffs approximate the northern-hemisphere solstice-to-equinox calendar, so the surcharge windows track the periods when winter weather disruption and summer peak demand genuinely raise operating cost. Because the clock is evaluated at run time, the same request prices differently across the year with no caller input, which is exactly how seasonal tariffs behave in practice.

Three pricing factors are derived before the rate table runs: dimensionalWeight as (length * width * height) / 5000, effectiveWeight as max([weight, $.dimensionalWeight]), and distanceFactor as distance / 100. The 5000 divisor is the dimensional-weight convention parcel carriers use so light but bulky boxes are billed for the space they consume, and normalizing distance per 100km keeps the downstream multiplier small and legible.

Pricing crosses customerTier with currentSeason across twelve first-hit rows, all sharing the same backbone formula, baseRate * (effectiveWeight / weight) * (1 + distanceFactor * 0.1), then layering tier and season multipliers. 'platinum' pays 0.8 in every season, 'gold' pays 0.9 with a 1.1 winter or 1.05 summer factor, 'silver' pays 0.95 with the same seasonal factors, and the tierless rows at the bottom apply only the seasonal 1.1 or 1.05, or nothing. The tierDiscount output records which multiplier applied.

Two realistic pricing ideas are encoded here: seasonal surcharges cover the genuinely higher cost of winter weather handling and summer peak volume, and loyalty tiers buy those surcharges down, with platinum insulated from them entirely since its rows carry no seasonal factor. The specific 5, 10, and 20 percent steps are calibration choices, but the structure, a stable formula with stacked multipliers, is how carriers keep dynamic pricing explainable on an invoice.