This document separates confirmed business behavior from decisions that are still open. It exists so code changes do not silently invent pricing policy.
orderDesi <= 0 is rejected and no order is persisted.
When multiple active carrier configurations contain the requested desi, the configuration with the lowest CarrierCost is selected.
Example:
Order desi: 5
Carrier A range: 1–10, price 40
Carrier B range: 1–10, price 32
Selected: Carrier B, 32 TRY
When no range matches and the selected closest configuration has a maximum below the order desi, the current documented formula is:
finalPrice = carrierPrice + (carrierPlusDesiCost × (orderDesi - carrierMaxDesi))
Example:
Order desi: 13
Max desi: 10
Base price: 32 TRY
Extra-desi price: 4 TRY
Final: 32 + (4 × 3) = 44 TRY
If no applicable/closest active configuration can be returned, order creation fails and nothing is persisted.
The current implementation finds the closest CarrierMaxDesi using absolute distance and also uses an absolute difference in fallback pricing.
That leaves two cases that need explicit product/business policy:
- the order is below every configured range,
- the order falls in a gap between ranges.
The repository intentionally tracks this as an open issue instead of changing the behavior from engineering intuition alone.
Any resolution should add tests for:
- exact lower boundary,
- exact upper boundary,
- overlapping ranges,
- above-all-ranges order,
- below-all-ranges order,
- gap between two ranges,
- equal-price tie behavior if relevant,
- inactive carrier configurations,
- no active configuration.
Business policy should be explicit in documentation and tests before implementation is changed.