Video chapters
- 0:00 Welcome
- 0:11 Overview: how discounts work
- 0:47 Part 1 · A code, start to finish: explained
- 1:02 Create the Mug Lovers code as a draft
- 1:55 Sam tries it while it is a draft
- 2:30 Activate it, apply it, pay
- 3:19 Part 2 · Four kinds of offer: explained
- 3:32 Fixed, free shipping and category codes
- 4:46 One code per order at the checkout
- 5:34 Part 3 · Conditions and limits: explained
- 5:49 Minimum cart value and one use per customer
- 6:03 Priya's checkout: refused, applied, used
- 7:08 Part 4 · Automatic offers: explained
- 7:26 Members Weekend, a code-free offer
- 7:44 A member sees it in price and cart
- 8:02 Priority: Tableware Week goes first
- 8:35 Stackable offers and a code that cannot join
- 9:12 Part 5 · Switch off, expire, correct: explained
- 9:21 Deactivate, expire, read the reason, fix the rule
- 11:06 Wrap-up
Written guide
Overview
Create an offer, test it on the real basket and explain why the qualifying and nonqualifying cases differ.
Before you start
Use one known product and customer basket so the discount is the only changing input. The historical example applies PRINT10 to Cedar Botanical Print, A3 price $35, with $5 delivery. It demonstrates a product-scoped coupon, not customer-group, rental or stacking eligibility. Those alternatives remain covered below with separate verification targets.
01. Create the offer
Why this matters
A discount’s name identifies the record; its coupon code is what the buyer enters. An empty code can represent automatic application.
Follow these steps
Open Storefront → Discounts and create the record. Enter name and optional code, select Draft while preparing it, then the offered discount type and value. Inspect percentage cap and, for buy/get offers, Buy quantity, Get quantity and percentage off. Set priority and whether the discount can combine with others. Save and reopen.
Check the result
Do not call every percentage field a price. A 100% get-item discount affects the configured get quantity, not necessarily the entire cart.
Create the PRINT10 exercise
- Open Storefront → Discounts → Discounts → Create Discount. Enter Name
course-print-tenand CodePRINT10. Reopen the existing record if repeating this exercise. - Keep Status → Draft. Choose Type → Percent and Value → 10. Leave Max Discount blank unless the offer needs a monetary cap.
- Change Apply To from Cart to Products and select the actual Cedar Botanical Print record. A product scope keeps the offer attached to that item rather than assuming it discounts delivery.
- Review exclusions, dates and usage restrictions below the visible fields. Keep Can combine with other discounts off for the first isolated test.
- Choose Create once. Reload the list and reopen the saved name/code before activation.
Historical blank form. Its Cart default must be changed for the product-only exercise. Placeholders and a typed code are not yet a saved discount.
02. Set scope and conditions
Why this matters
The condition determines who and what qualifies, while the amount determines the benefit.
Follow these steps
Choose scope: cart, products, categories, rentals, rental fees or the offered supported alternative. Select included and excluded products/categories and customer groups/customers. For rental fees choose the actual fee names. Set minimum cart value, minimum items, first-time customer, required products, maximum total uses and per-customer uses. Set the intended active dates and status.
Check the result
A first-time or group restriction needs authenticated customer evidence. Empty inclusions and explicit exclusions have different effects; review both before activation.
03. Apply, remove and compare
Why this matters
The real basket is the test of the rule.
Follow these steps
Activate the discount and open the customer cart with the intended items. Enter the code, apply it and inspect line/total changes. Remove it and confirm the original calculation returns. Repeat below a threshold, with an excluded item and with the wrong customer group. Read the actual rejection rather than predicting a generic error.
Check the result
Reload or recalculate after configuration changes. Do not alter a second rule while trying to identify the first failure.
Follow the customer's apply and remove controls
- Activate the saved discount from its list actions, then open the customer shop and add the intended A3 print.
- At checkout enter
PRINT10under Promo Code and choose Apply Coupon. Wait for Applied Discounts to name the saved rule. - Check the product amount, discount, delivery and final total separately. The recorded result is $35 − $3.50 + $5 = $36.50.
Historical checkout after reload. It proves the displayed coupon result, not successful payment: online payment is unavailable in this frame.
- Select the × on the applied discount to remove it. Confirm the undiscounted $40 total returns before trying another code.
- Enter a code that does not exist and choose Apply Coupon. Read the inline result instead of assuming every rejection means the discount expired.
This negative case demonstrates lookup failure only. Group, date and minimum-quantity rejections need their own controlled cases.
- Restore the exercise discount to its intended inactive/draft state after testing. Refresh the same checkout to check it is no longer offered; an old browser view can retain stale calculations.
04. Stacking, expiry and recovery
Why this matters
Two offers can interact through priority and combinability.
Follow these steps
Test the first offer alone, then introduce the second intended offer and compare the actual combined result. Inspect priority and stacking configuration if only one applies. Deactivate or expire one rule, save and repeat the same customer basket. Reopen the discount record to inspect usage and dates.
Check the result
A checkout attempt is not automatically a completed usage. Usage enforcement and rental-fee consumption require an actual controlled consumer outcome.
Detailed instructions
The following retained material documents earlier local work. Its pending checks remain pending; historical successful outcomes are not claims of a fresh execution. Use the source-authored instructions above to prepare the new recording, and preserve these references for comparison.
A01: A promotion that affects the item
Worked example
Cedar and Form wants ten percent off this print, without discounting delivery. Open Discounts, the Discounts tab and Create Discount. Use course-print-ten, code PRINT10, Draft, Percent and ten. Under Apply To, choose Products and Cedar Botanical Print. Create, reload and check the Draft row, then Activate from its actions. At checkout, enter PRINT10 and Apply Coupon. The item discount is three dollars fifty: ten percent of thirty-five. Shipping remains five, so the total is thirty-six fifty. Reload to check the code and deduction remain.
Included controls: Dashboard, Discounts, Manage, Create Discount, Name/Code, Draft, Percent, value, Products scope, Activate, Apply Coupon, reload.
Check the result: PRINT10 actual−3.50 and36.50 after reload; not payment evidence.
Retained evidence: capture/SF11-discount-code.webm, capture/SF18-coupon-final-retake.webm.
Implementation reference: detail.tsx.
A02: Diagnose why an offer does not apply
Worked example
A success toast is not the calculation check; inspect the deduction and total. A nonexistent code gives Discount code not found. Correct the entered code before changing the offer. When a training promotion is finished, return to its row actions and Deactivate. Reload checkout with PRINT10: Discount is inactive appears, the deduction is removed and the total returns to forty dollars. An inactive offer needs a deliberate status decision, not repeated clicks on Apply Coupon.
Included controls: unknown coupon, inactive coupon, Deactivate, eligibility inspection, cleanup, negative result.
Check the result: Unknown-code/inactive errors; final couponInactive and total40.
Retained evidence: capture/SF19-coupon-deactivation-check.webm.
Implementation reference: discount.service.ts.
A05: Extend discounts without surprising buyers
Learner draft — pending demonstration:
Use the kind of offer that matches the promise. Money off a print, free shipping and a rental fee waiver change different lines of a bill. Automatic offers remove the code-entry step; code offers let the buyer claim a named promotion. When two offers overlap, check their combined result rather than assuming both apply. Test the intended basket, a basket that fails the conditions and the offer after its end condition.
Included controls: automatic versus code, fixed amount, free shipping, free deposit, free delivery, waive fee, buy X get Y, priority/stacking, dates/use limits, eligibility, categories/rental/cart, exclusions.
Limitations and checks: Enumerate actual runtime schema types/eligibility/limits/stack controls. Demonstrate each materially different supported deduction on controlled product/category/cart/rental fixtures. Show exclusion and use-limit/date failures; do not invent numeric results from schema labels.
Check the result: Every exposed discount family has actual affected line and qualification/failure check.
Implementation reference: detail.tsx, discount.service.ts.
Limitations and checks
Current UI entry and editor: . Corresponding SDK storefront schemas and the retained AppEngine references define fields and consumer boundaries. Provider calls, external delivery, payments and financial mutations were not performed for this writing task.
Next steps
You can now follow the module from its configuration to the record that proves the result. Use the relevant chapter to revisit an alternative or troubleshoot the exact failed handoff.
BusinessMade Discounts — supporting guide
Overview
Create an offer, test it on the real basket and explain why the qualifying and nonqualifying cases differ.
BusinessMade entry and scope
Open Storefront → Discounts at /storefront/discounts in BusinessMade. This route mounts the shared Discounts module; the surrounding menus are BusinessMade’s. Use Operations → Contacts for customer details, Operations → Customers & Benefits for group eligibility, Admin → Business locations for branches, and Operations → POS / Order entry for counter sales. Keep the organization and record identity consistent across those screens.
The location selector governs the venue-specific POS, but does not establish that every shared Storefront module filters its data by that selection. Inspect the record’s own location and currency. Payments are under Storefront → Payments, while delivery rules and shipments are under Storefront → Shipping; creating this module’s record is not payment or shipping-provider configuration.
01. Create the offer
Why this matters
A discount’s name identifies the record; its coupon code is what the buyer enters. An empty code can represent automatic application.
Follow these steps
- Open Storefront → Discounts and create a discount. Enter a unique Name, such as
bm-course-ten, and CodeBMCOURSE10for a code-required example. Reuse your own existing record if that name is already present. - Keep Status as Draft. Choose Type → Percent and enter Value
10. This means ten percent, not a ten-currency-unit reduction. - Leave Can combine with other discounts off for the first isolated comparison. Review Priority; higher values are applied first.
- Under Apply To, choose the intended scope and finish the eligibility fields in the next section before activation. Do not leave broad Cart scope accidentally if the offer is meant for only one product.
- Choose Create, locate the saved name/code in the list, reopen it and confirm type, value, status and scope. Saving a Draft does not make it redeemable.
Historical Appmint capture of the shared editor used by BusinessMade. Draft, Percent, Apply To and exclusions are visible; it is not a new BusinessMade redemption demonstration. The existing PRINT10 row behind the form belongs to that earlier example.
Check the result
Do not call every percentage field a price. A 100% get-item discount affects the configured get quantity, not necessarily the entire cart.
02. Set scope and conditions
Why this matters
The condition determines who and what qualifies, while the amount determines the benefit.
Follow these steps
Choose scope: cart, products, categories, rentals, rental fees or the offered supported alternative. Select included and excluded products/categories and customer groups/customers. For rental fees choose the actual fee names. Set minimum cart value, minimum items, first-time customer, required products, maximum total uses and per-customer uses. Set the intended active dates and status.
Check the result
A first-time or group restriction needs authenticated customer evidence. Empty inclusions and explicit exclusions have different effects; review both before activation.
03. Apply, remove and compare
Why this matters
The real basket is the test of the rule.
Follow these steps
Use an isolated training offer and a checkout that actually exposes coupon redemption.
- Save the offer as Active, reopen it and check the dates before testing.
- In the buyer's cart, add the intended product and note its undiscounted item subtotal. Enter the exact saved code into the checkout's coupon control and apply it.
- Compare the discount line, shipping, tax and total separately. For a $20 eligible item and a simple10% rule, the item reduction would be$2; this arithmetic is an illustration, not a claimed BusinessMade receipt.
- Remove the code and recalculate. Confirm the reduction disappears without changing product, quantity or customer.
- Repeat with one disqualifying condition at a time: quantity below the threshold, excluded product, then the wrong authenticated customer. Read the actual result and keep the failed condition visible.
For Operations → POS / Order entry, inspect the calculated Discount row but do not assume the website coupon input is available. The source reviewed here exposes a breakdown Discount row; it does not establish a counter code-entry workflow. Leave that branch unverified until the actual supported input and result are demonstrated.
Check the result
Reload or recalculate after configuration changes. Do not alter a second rule while trying to identify the first failure.
04. Stacking, expiry and recovery
Why this matters
Two offers can interact through priority and combinability.
Follow these steps
Test the first offer alone, then introduce the second intended offer and compare the actual combined result. Inspect priority and stacking configuration if only one applies. Deactivate or expire one rule, save and repeat the same customer basket. Reopen the discount record to inspect usage and dates.
Check the result
A checkout attempt is not automatically a completed usage. Usage enforcement and rental-fee consumption require an actual controlled consumer outcome.
BusinessMade operational handoff — Separate discount configuration from the observed receipt
Why this matters
Discounts connects to the saved customer, product or transaction. Follow that identity through the BusinessMade operation rather than creating a second record to illustrate a result.
Follow these steps
Create the scoped discount with its actual validity and eligibility rules, save and reopen it. Use a controlled purchase through a checkout that exposes that discount’s redemption mechanism. In BusinessMade POS inspect the server-calculated Pricing/Discount row and final tab totals; do not assume a website code-entry field also exists at the counter. Open the resulting Storefront → Orders record and compare the same subtotal, discount, tax and paid balance. Repeat with an excluded product or outside-quantity case to verify rejection.
Recovery and implementation boundary
A saved discount code does not prove POS supports its redemption input. If the counter does not expose the required input, teach the supported website checkout branch and record POS redemption as unavailable/unverified, rather than inventing a button.
Limitations and checks
Substantive pending work: A saved discount code does not prove POS supports its redemption input. If the counter does not expose the required input, teach the supported website checkout branch and record POS redemption as unavailable/unverified, rather than inventing a button. Runtime evidence for the taught handoff remains separate from authored coverage. Do not mark the course production-ready until the intended branch’s saved result, failure recovery and customer/provider outcome have been checked.
Next steps
You can return directly to the chapter for the change you need. Keep the saved record and its operational result together: the same customer, product, location and transaction should remain identifiable through each handoff.