PRD: Price & Fare Editing on the Product Screen

Module	Products	PRD ID	PRD-FAR-001
Status	Ready to dev	FEAT	FAR
Epic	—	Plane	BANA-1554
Date	2026-06-03	Version	v1.0
Packages	@nx/pricing · @nx/commerce	URD	FAR
Surface	Client · Owner/Mgr
Owner	Phát Nguyễn

What price & fare editing on the product screen is

A sellable variant needs a price, but owners have nowhere to set or edit that price except the product screen itself - where they already create and edit the variant's name, description, and options. If setting a price meant leaving the product screen for a separate pricing screen, pricing would drift apart from building the product and get skipped.

This PRD builds the pricing panel right inside the product edit screen on Client: owners set the default selling price, create a SALE or OVERRIDE parent fare with its child fares, and set an effective date range or quantity window for each fare - all in the same variant-edit flow. The actual pricing engine (winning-fare selection, tax, packaging the immutable pricing snapshot) belongs to the Pricing module, not this PRD - see PRD: Fare & Tax Pricing Engine.

Price and fare, who owns what

Where	What happens there
Product screen (this PRD)	Owner sets/edits the default selling price, creates a SALE/OVERRIDE parent fare and child fares, sets an effective window and a quantity window
Pricing module (engine)	Selects the winning fare at sale time, computes tax, packages the immutable pricing snapshot attached to the order

Saving the variant is enough - the price sync to the fare set in the Pricing module runs automatically, with nothing further for the owner to do.

One pricing pass, from the product screen to a sale

An owner opens the product edit screen for a variant → sets the default selling price and, if needed, creates a SALE or OVERRIDE parent fare with its child fares (amount, date range, quantity window) → saves the variant → the price change syncs to the fare set in the Pricing module, where the engine uses it to price the item at sale time.

Where this is easy to get wrong

This PRD does not decide which price wins at sale time

The pricing panel on the product screen is only where the selling price, parent fare, effective window, and quantity window are entered. The winning-fare selection algorithm, tax computation, and packaging the pricing snapshot at sale time do not run here - they belong entirely to the Pricing module's engine (PRD-FARE-001). Reading this PRD as where the final selling price gets decided misreads the UI/engine boundary.

1. Goals & Non-Goals

Goals

• Set or edit a variant's default selling price right on the product screen (URD-FAR-001).
• Create or edit a SALE or OVERRIDE parent fare and its child fares right on the product screen (URD-FAR-001).
• Set an effective date range and a min/max quantity window for a fare right on the product screen (URD-FAR-001).
• Saving the variant automatically syncs the price changes to the fare set in the Pricing module.

Non-Goals

• The winning-fare selection algorithm, tax computation, and packaging the pricing snapshot at sale time - owned by PRD: Fare & Tax Pricing Engine in the Pricing module.
• The order price preview and frequently-bought-together bundle pricing at sale time - also owned by the Pricing module's engine.
• Promotion discount calculation at pricing time (owned by Promotions).
• The unit-conversion engine and a standalone resolved-price read for a variant (URD-VAR-011/012).

2. Success Metrics

Metric	Target / signal
Price-editing UI coverage	100% of variants can have their selling price set/edited right on the product screen, with no need to leave it
Post-save sync	Saving a variant on the product screen always triggers a price sync to the fare set in the Pricing module
Price-editing experience	Owners complete setting the default price and tiered fares in a single variant-edit pass, without opening another screen

3. Personas & Use Cases

Persona	Goal in this feature
Owner	Set and edit the selling price, default fare, SALE/OVERRIDE parent fare, effective window, and quantity window right on the product screen
Product screen (system)	Push the price changes just saved to the fare set in the Pricing module

Core flow: an owner opens the product edit screen for a variant → sets the default selling price and, if needed, creates a SALE or OVERRIDE parent fare with its child fares (amount, date range, quantity window) → saves the variant → the price change syncs to the fare set in the Pricing module, where the engine uses it to price the item at sale time.

4. User Stories

#	As a	I want	So that
01	owner	set the default selling price right when I create or edit a variant on the product screen	I don't have to open another screen just to price it
02	owner	create a SALE or OVERRIDE parent fare with child fares that carry their own amounts, right on the product screen	I can configure tiered pricing while I build the variant
03	owner	set an effective date range or a min/max quantity window for a fare, right on the product screen	that fare only applies in the window I intend
04	owner	saving the variant to be enough for the price I just set to take effect at sale time	I don't have to manually sync it anywhere else

5. Functional Requirements

#	Requirement	Status	URD ref
FR-001	Owner can set or edit a variant's default selling price (default fare) right on the product screen.	✅	URD-FAR-001
FR-002	Owner can create or edit a SALE or OVERRIDE parent fare and add its child fares right on the product screen. • Create or edit a SALE or OVERRIDE parent fare right on the product screen. • Add child fares to that parent fare. • Each child fare carries its own amount and rule by channel, time, and quantity.	✅	URD-FAR-001
FR-003	Owner can set an effective date range and a min/max quantity window for a fare right on the product screen. • Set an effective date range (from/to) for the fare. • Set a min/max quantity window for the fare.	✅	URD-FAR-001
FR-004	Saving a variant on the product screen automatically syncs the price just set to the fare set in the Pricing module, where winning-fare selection, tax, and packaging the pricing snapshot at sale time take place. • Saving a variant on the product screen automatically syncs the price just set to the fare set in the Pricing module. • Winning-fare selection, tax, and packaging the pricing snapshot at sale time run in the Pricing module's engine.	✅	URD-FARE

5.1 Acceptance Criteria

• Open the product edit screen for a variant → enter a default selling price → save → the price is recorded, with no need to leave the screen or open a separate form.
• On the product screen, create a SALE or OVERRIDE parent fare and add a child fare with its own amount → save the variant → the parent fare and its child fares are saved attached to that exact variant.
• Set an effective date range (from/to) for a fare on the product screen → save → the fare only shows as effective within that exact range.
• Set a min/max quantity window for a fare on the product screen → save → the window is recorded for that fare.
• Save a variant whose price was just edited on the product screen → reopen the fare-set panel → every price change just saved is present, synced to the Pricing module.
• Enter a negative amount for a fare on the product screen → the form rejects the save.

6. Non-Functional Requirements

Area	Requirement
Data integrity	Prices entered on the product screen are validated before saving (amount zero or positive); the full set of constraints and data invariants belongs to the engine in the Pricing module
Tenancy & access	All operations confined to the user's own merchant; gated by product/pricing permissions
Precision	Price entry uses 4-decimal precision, matching the Pricing module's engine
Languages	Fare labels on the product screen are bilingual (English and Vietnamese)

7. UX & Flows

Key screens (Client app), all inside the product edit screen: fare-set panel, default-price wizard, tier/group editing, and rule selection (channel / time / service-duration).

8. Data & Domain

Concept	Role
Fare set	Pricing container linked one-to-one to a variant; owners edit it right on the product screen
Fare	A price entry - the default fare, or a SALE/OVERRIDE child fare carrying its own amount and rule

The actual pricing engine (winning-fare selection, tax, pricing snapshot) and the full domain model belong to the Pricing module - see PRD: Fare & Tax Pricing Engine and the pricing fares domain model.

9. Dependencies & Assumptions

Depends on

#	Feature	What it depends on
01	Variants (URD-VAR)	the product screen edits the fare set attached to the variant being edited.
02	Catalogue → pricing sync	saving a variant on the product screen triggers the fare-set sync.
03	PRD: Fare & Tax Pricing Engine in the Pricing module	owns winning-fare selection, tax, and the pricing snapshot used at sale time.

Assumptions

#	Assumption	If wrong
01	A variant exists in the catalogue before an owner edits its price on the product screen.	With no variant to attach a fare set to, the pricing panel on the product screen has nothing to edit - the owner must create the variant before it can be priced.
02	The Pricing module is always ready to receive the sync right after the variant is saved.	If the Pricing module is not ready, the price just saved on the product screen lags behind the real fare set, so the sale engine keeps pricing off the old amount until the sync completes.

10. Release Plan & Launch Criteria

Aspect	Plan
Phase	P2 - see URD feature catalog
Rollout	All merchants; no feature flag
Migration	None
Launch criteria	Owner can set/edit the selling price, a SALE/OVERRIDE parent fare, effective window, and quantity window right on the product screen; saving a variant always syncs to the Pricing module
Monitoring	Rate of variant saves that fail to sync their fare set (tracked in the Pricing module)

References

• URD: Product - Fares / Pricing
• Builds on: Variants
• Engine: PRD: Fare & Tax Pricing Engine · URD: Pricing - Fare & Fare Set
• Module: Product - URD
• Developer: pricing fares · @nx/pricing · @nx/commerce

Risks & Open Questions

#	Risk / question	Mitigation / status
01	The price sync could lag behind the moment the variant is saved	The sync runs in the background after saving, outside the same transaction; detail in the Pricing module's engine PRD
02	The UI/engine boundary can be confusing when reading older docs	This PRD only describes the price-editing UI on the product screen; all pricing behavior lives in the Pricing module's engine PRD

Frequently Asked Questions

#	Question	Answer
01	Where is the selling price set?	Right inside the product edit screen on Client - there is no separate pricing screen.
02	What's the difference between SALE and OVERRIDE?	These are the two parent-fare kinds an owner picks when building tiered pricing on the product screen; how the engine chooses between them at sale time is owned by the Pricing module's engine PRD.
03	Where does pricing run at sale time?	Not in this PRD - see PRD: Fare & Tax Pricing Engine in the Pricing module.
04	Are promotions applied at pricing time?	Out of scope for this PRD; see Promotions.