Maintain dated pricing periods

Purpose

Administrators and future owning applications coordinate product price changes across dated periods.

How It Works

A schedule organizes named periods with a time zone. Products following it expose those periods in the grid. Saving a schedule reconciles retained, edited, added and omitted periods against its version. Historical use and elapsed time constrain what can change. Permitted current-end edits coordinate the next period without rewriting earlier charges. The implemented API still accepts ownerless schedules after the standalone console editor was removed. The product should settle the owner transition before adding schedule creation to a future design.

Relationships

The configure product purchasing and price adjustments capability supplies related configuration or assessment used in this work.

The calculate and explain a buyer’s item price capability supplies related configuration or assessment used in this work.

Show evidence (sources, provenance, origins, pinned commits)

The Formal Contract

The narrative above explains; the sections below are authoritative — the rules, scenarios and tests this document binds.

Outcomes: A price edits exactly at a period boundary.Each past charge stays explainable by the period that priced it.
Surfaces: api
Intent sources: services-commerce:docs/milestones/COMM-M1-set-up-what-you-sell.md#D2services-commerce:docs/milestones/COMM-M1-set-up-what-you-sell.md#D6services-commerce:docs/milestones/COMM-M1-set-up-what-you-sell.md#D4-F1services-commerce:docs/debt/pricing-schedules-owned-by-event.md

Controls

22 controls apply, from the corpus control catalogue.

TC-IAM-006 TC-AZ-001 TC-AZ-002 TC-AZ-003 TC-AZ-004 TC-AZ-005 TC-AZ-006 TC-TEN-001 TC-TEN-002 TC-TEN-003 TC-CRY-004 TC-DAT-004 TC-LOG-004 TC-AVL-004 TC-MON-001 TC-MON-002 TC-MON-004 TC-PI-001 TC-PI-002 TC-PI-003 TC-PI-004 TC-PI-005

Permissions

Key	Checked at	Scope
`commerce.pricing-schedules.read`	api	tenant
`commerce.pricing-schedules.create`	api	tenant
`commerce.pricing-schedules.update`	api	tenant
`commerce.pricing-schedules.delete`	api	tenant
`commerce.pricing-schedules.bulk`	api	tenant

Business Rules

11 rules, 10 to be proved before approval. A rule's product intent is derived from its origin: 0 confirmed by a product decision, the rest inheriting this capability's proposed.

Id	Rule	Kind	Enforced at	Provenance
`01`must prove Proposed	The implemented price schedule holds workspace periods without ownership and rejects an owner such as an event in its request. origin: COMM-M1 D2 (docs/milestones/COMM-M1-set-up-what-you-sell.md) no proof recorded yet	policy	api, database	test services-commerce:modules/pricing/tests/e2e/pricing-schedules.e2e.spec.js#answers 400 to an event owner (a schedule has none, COMM-M1 D2), to a property outside the contract and to a tenant_id other than the path’s
`02`must prove Proposed	A period includes its start boundary and excludes its end in the schedule’s time zone. origin: COMM-M1 D6 (docs/milestones/COMM-M1-set-up-what-you-sell.md) no proof recorded yet	calculation	service, database	test services-commerce:modules/pricing/tests/integration/services/persistence/pricing-schedules.queries.integration.spec.js#finds the period containing an instant: the open start, a boundary belonging to the period it starts, the open end
`03`must prove Proposed	Adjacent periods share boundaries without gaps or overlaps, with an open start permitted only first and an open end only last. origin: COMM-M1 D6 (docs/milestones/COMM-M1-set-up-what-you-sell.md) no proof recorded yet	invariant	service, database	test services-commerce:modules/pricing/tests/integration/db/member-pricing-tables.table.integration.spec.js#refuses an overlap, a second open end and an open start that is not first
`04`must prove Proposed	Elapsed or used periods retain their names and boundaries and prevent their own and their schedule’s deletion, except for the permitted current-end adjustment; the first-sale marker is permanent. origin: COMM-M1 D6 (docs/milestones/COMM-M1-set-up-what-you-sell.md) no proof recorded yet	invariant	service, database	test services-commerce:modules/pricing/tests/integration/db/member-pricing-tables.table.integration.spec.js#records the first sale once, never cleared or moved, after which the period keeps its name and is never deleted, nor its schedule
`05`must prove Proposed	Staff may adjust a current period’s end no earlier than now, shifting the next period’s start with it even after a sale, while preserving prior charges. origin: COMM-M1 D6 (docs/milestones/COMM-M1-set-up-what-you-sell.md) no proof recorded yet	lifecycle	service, database	test services-commerce:modules/pricing/tests/e2e/pricing-schedules.e2e.spec.js#extends the sold-in Early Bird by a week, Regular starting where it now ends, its first sale untouched
`06`must prove Proposed	A period identity belongs to one workspace schedule, and reuse by another schedule is refused with the identity identified. no proof recorded yet	validation	service, database	test services-commerce:modules/pricing/tests/e2e/pricing-schedules.e2e.spec.js#answers 400 with the problem code period_id_taken, naming the id, to a second schedule taking a period id, creating nothing
`07`must prove Proposed	Referenced schedules cannot be deactivated or deleted, with product counts and up to five product references reported; inactive schedules cannot be selected by products. origin: COMM-M1 D4-F1 (docs/milestones/COMM-M1-set-up-what-you-sell.md) no proof recorded yet	lifecycle	service, database	test services-commerce:modules/pricing/tests/integration/services/persistence/pricing-schedules.integration.spec.js#refuses with schedule_in_use, the count in the sentence, and the count and the first five product ids in the details
`08`must prove Proposed	A versioned schedule replacement retains unchanged periods, updates permitted changes, inserts additions and removes omitted periods where allowed. no proof recorded yet	invariant	service	test services-commerce:modules/pricing/tests/integration/services/persistence/pricing-schedules.integration.spec.js#answers the replaced record at version 2: the kept period at version 1, the changed one at version 2, the new one inserted, the one left out gone
`09` Proposed	Staff see a product’s schedule periods as pricing-grid columns, without a standalone schedules screen. origin: COMM-M1 walkthrough ruling R5 (docs/debt/pricing-schedules-owned-by-event.md)	policy	console	documented services-commerce:docs/debt/pricing-schedules-owned-by-event.md
`10`must prove Proposed	Schedule inspection requires read permission and schedule writes require administrator permissions. no proof recorded yet	permission	api	test services-commerce:modules/pricing/tests/e2e/pricing-configuration-security.e2e.spec.js#lists and reads the audiences and the schedules
`11`must prove Proposed	A full lock prevents replacing a schedule, and either full or deletion-only locking prevents removing it. no proof recorded yet	policy	service	observed services-commerce:modules/pricing/services/persistence/pricing-schedules.ts

Scenarios

Id	Given	When	Then	Provenance
`01`	Early Bird’s end is the following period’s start	Calculate just before and exactly at that boundary	The earlier instant selects Early Bird and the boundary selects Regular	documented services-commerce:docs/milestones/plans/COMM-M1-plan.md#D6. The price-period rules
`02`	Current Early Bird already has a first-sale marker	Extend its end by one week	Regular’s start moves with it and the earlier sale remains associated with Early Bird	test services-commerce:modules/pricing/tests/e2e/pricing-schedules.e2e.spec.js#still reads a sale made before the change in the same period, and now a day after the old end in Early Bird too

Planning

Maintain dated pricing periods ​

Purpose ​

How It Works ​

Relationships ​