Repository navigation
feat(food): add discount extension specification and schema - #992
niranjanmanjunath wants to merge 2 commits into
Conversation
| "each", | ||
| "across" | ||
| ], | ||
| "description": "Allocation method. 'each' = applied independently per dish. 'across' = split proportionally by value." |
There was a problem hiding this comment.
is this description accurate for BOGO's where that type of discount is triggered by other dishes (e.g. not fully independent per dish?)
| | `discount_code_already_applied` | Code is already applied | | ||
| | `discount_code_combination_disallowed` | Cannot combine with another active discount | | ||
| | `discount_code_user_not_logged_in` | Code requires authenticated user | | ||
| | `discount_code_user_ineligible` | User does not meet eligibility criteria | |
There was a problem hiding this comment.
other types of error codes/scenarios to consider here (from Toast perspective). it really depends on how granular we want to get with these i suppose:
- Minimum order / subtotal not met
- No qualifying dish in the cart
- Not valid for this fulfillment method
- Not valid at this time: happy hour, day-part, and scheduled orders, where the promo window has to be checked against the promised time, not when the order was placed
- Usage limit reached / single-use / already redeemed by this guest
- perhaps could be user inelegible?
There was a problem hiding this comment.
id love the agent to have enough granularity so that it can steer the buyer out of an error: "add $8 more" or "switch to pickup."
|
|
||
| **Determining the type:** If a discount has `allocations` pointing to line | ||
| items, it contributes to `items_discount`. Discounts without allocations, or | ||
| with allocations to delivery/fees, contribute to `discount`. |
There was a problem hiding this comment.
Allocations describe where the dollars landed, not whether a discount is item-level or order-level. Toast spreads order-level promos across items so each item is taxed on its discounted price. For example, $10 off a $30 pizza (8% tax) plus a $20 beer (10% tax) lands as $6/$4, and tax is $3.52. With this rule, a business that reports that split has to present an order promo as items_discount, which contradicts Pattern 3 (Promo WELCOME10 → discount).
Suggest: allocations are informational only, and the business picks items_discount vs discount based on how the promo is presented to the buyer.
|
also curious how platforms should be communicating what the max number of discounts an order can apply.... Toast online ordering typically allows one promo code per order, but platforms can't learn this from the profile. They'll only hit combination_disallowed after trying. An optional |
Description
Stacked on top of #897 (
food/checkout).Summary
dev.ucp.food.discount) specification atdocs/specification/food/extensions/discount.mdwith Food domain examples (dish-based line items,BOGOPIZZA, delivery fee discounts, and stacked loyalty/promo allocations).dev.ucp.food.discountJSON Schema atsource/schemas/food/discount.jsonextendingdev.ucp.food.cartanddev.ucp.food.checkout.DiscountsunderSpecification -> Food -> Extensionsandplugins.llmstxt.sections.Food Extensionsinmkdocs.yml.Category (Required)
Please select one or more categories that apply to this change.
ucp-schematool (resolver, linter, validator). (Requires Maintainer approval)Related Issues
Checklist
!for breaking changes).Screenshots / Logs (if applicable)