DiscountModules

DiscountModules are the mechanism for registering percentage discounts during the course of a transaction and determining the customer's total percent discount. Using DiscountModules rather than updating localtemptrans.percentDiscount directly lets POS keep track of which discounts are in effect.

DiscountModules have the following restrictions:

• The percentage discount applies to all discountable items. This rule probably won't budge. Allowing individual registered DiscountModules to apply to different subsets of items makes the potential rules governing interactions between DiscountModules effectively infinite.
• Discounts can currently operate in either stacking or non-stacking mode. If there are currently two DiscountModules registered for 5% and 10%:
  • In stacking mode the discount will be 15% (5 + 10)
  • In non-stacking mode the discount will be 10% (5 < 10)
  • More modes could be added in theory but I think would generally be unwise as the increasing number of permutations gets difficult to keep track of (for both customers and staff)

Registering a DiscountModule

$mod = new DiscountModule(10, 'custdata');
DiscountModule::updateDiscount($mod);

This creates (or updates) a 10% discount named 'custdata'. Discounts are registered by name so future calls to DiscountModule::updateDiscount with a module named 'custdata' will change that discount's percentage. There's no explicit remove or unregister call; passing in a 0% discount is the recommended approach. All discounts are automatically unregistered at the end of a transaction.

Built-in DiscountModules

Since discounts are identified by name it's important to avoid collisions. POS currently uses the following named discounts:

• custdata is the customer's discount as defined in custdata.Discount.
• HouseCoupon is used by houseCoupons.discountType 'PD'.