Part 021 — Quoted Price Immutability, Provenance, Staleness, and Repricing

Positioning

Harga dalam CPQ melewati beberapa bentuk:

catalog definition
-> interactive price preview
-> calculated quote price
-> approved commercial price
-> presented price
-> accepted commercial commitment
-> order monetary intent
-> billing charge

Setiap tahap memiliki tingkat authority dan mutability yang berbeda.

Masalah muncul ketika sistem tidak membedakan:

• live price;
• cached price;
• preview;
• snapshot;
• approved price;
• accepted price;
• dan billed amount.

Core thesis: sebuah quoted price harus membawa calculation evidence yang cukup untuk direproduksi, tetapi accepted commercial commitment tidak boleh berubah hanya karena catalog, contract, exchange rate, atau pricing engine telah berubah.

1. Price Definition versus Price Snapshot

Price Definition

Reusable definition or rule used to calculate a price.

Price Snapshot

Transaction-specific monetary result captured for a quote revision.

A snapshot should preserve:

• components;
• adjustments;
• totals;
• currencies;
• periods;
• source references;
• rule versions;
• calculation context;
• and validity.

2. Why Snapshotting Matters

Without a snapshot:

• catalog changes alter historical display;
• pricing-rule changes alter accepted terms;
• support cannot explain old totals;
• order conversion may use a new price;
• and billing reconciliation becomes speculative.

3. Snapshot Is Not a Screenshot

A screenshot or proposal PDF preserves presentation.

A pricing snapshot preserves structured commercial evidence.

Both may be useful, but they serve different purposes.

4. Live Reference

A live reference resolves current price from an authoritative source.

Benefits:

• always current;
• smaller transaction payload;
• centralized policy.

Risks:

• historical transaction cannot be reproduced;
• old quote changes when viewed;
• current rule may not support old configuration.

5. Reference-Only Model

Example:

quoteItem.priceDefinitionId = PRICE-123

This is insufficient if definition is mutable or historical versions are unavailable.

6. Snapshot-Only Model

Stores final monetary breakdown but no source references.

Benefits:

• preserves displayed amount.

Risks:

• cannot explain why;
• cannot compare rule changes;
• weak audit and diagnostics.

7. Hybrid Snapshot + Provenance

Recommended general pattern:

• store immutable calculated result;
• retain source IDs and versions;
• preserve relevant context;
• retain calculation/pipeline version;
• retain trace or trace reference.

8. Snapshot Granularity

Possible levels:

1. Final total only.
2. Per-item summary.
3. Full component breakdown.
4. Full adjustment sequence.
5. Full calculation trace.
6. Input and output snapshot.

The correct level depends on:

• legal evidence;
• supportability;
• storage;
• privacy;
• and replay needs.

9. Minimum Commercial Snapshot

A minimum serious snapshot should often include:

quote ID and revision
price calculation ID
component IDs
amounts and currencies
charge types and periods
quantities and units
adjustments and basis
tax estimate status
validity
source definitions and versions
calculated at
pipeline/engine version

10. Price Component Identity

Each price component needs transaction identity.

It supports:

• adjustment targeting;
• quote revision diff;
• order transformation;
• billing mapping;
• reversal;
• and reconciliation.

11. Stable Component Identity across Repricing

When repricing the same logical component, decide whether:

• preserve logical component ID and increment result version;
• create new component ID linked to previous;
• or create entirely new snapshot tree.

Do not overwrite accepted history.

12. Price Calculation Identity

A Pricing Calculation should have its own identity.

Example:

calculationId = CALC-2026-000123

A quote revision may reference one or several calculation results.

13. Calculation Version

Calculation version distinguishes repeated calculation attempts or outputs.

14. Pipeline Version

Identifies stage ordering and pricing semantics.

15. Engine Version

Identifies implementation interpreting catalog and pricing rules.

16. Rule Version

Identifies business decision logic.

17. Catalog Publication

Identifies product, price, relationship, and characteristic definitions.

18. Contract Version

Identifies negotiated commercial input.

19. External Data Version

Potential sources:

• exchange rate;
• tax response;
• customer segment;
• cost estimate;
• inventory snapshot;
• feasibility result.

20. Provenance

Price provenance answers:

Where did this number come from?
Which rule selected it?
Which context applied?
Which adjustments changed it?
Which version was used?

21. Provenance Fields

Representative fields:

sourceType
sourceId
sourceVersion
ruleId
ruleVersion
pipelineVersion
engineVersion
catalogPublication
contextHash
calculatedAt

22. Provenance Chain

Example:

Market price list v8
-> contract override CONTRACT-77 v3
-> volume rule VOL-20 v2
-> approved discount ADJ-14
-> recurring amount 810 USD/month

23. Calculation Trace

A trace records significant evaluation steps.

It may include:

• candidates considered;
• candidates excluded;
• selected base;
• quantity/term changes;
• discounts;
• floors/caps;
• currency conversion;
• tax;
• rounding;
• and totals.

24. Full Trace versus Summary Trace

Full Trace

Useful for deep audit and debugging.

Summary Trace

Useful for support and routine explanation.

Store based on retention and sensitivity policy.

25. Trace Reference

Large traces may be stored separately.

Quote snapshot keeps:

• trace ID;
• checksum;
• and retention class.

26. Trace Security

Trace may contain:

• margin;
• cost;
• contract details;
• approval thresholds;
• and internal policy.

Use role-based access.

27. Price Validity

Price validity defines when a calculated result may be used.

Possible fields:

validFrom
validUntil
timezone
validityReason
revalidationPolicy

28. Definition Validity versus Result Validity

Definition validity

When a price rule or source can be used.

Result validity

How long the calculated output remains acceptable for this quote.

They can differ.

29. Quote Validity versus Price Validity

A quote may be valid until August 31.

A tax estimate or capacity-sensitive surcharge may be valid only for 24 hours.

The effective commercial validity may be constrained by the shortest mandatory dependency.

30. Approval Validity versus Price Validity

An approval may expire before the price result.

Or repricing may invalidate approval immediately.

31. External Dependency Validity

Examples:

• exchange rate valid for one day;
• feasibility valid for 24 hours;
• cost estimate valid for seven days;
• promotion valid until redemption limit reached.

32. Staleness

A price is stale when it no longer satisfies required freshness or context assumptions.

33. Stale Is Not Incorrect

A stale price may still equal the current result.

Staleness means it requires review or revalidation.

34. Invalid Price

A price is invalid when:

• context is no longer allowed;
• source expired;
• rule violated;
• component missing;
• or monetary invariants fail.

35. Superseded Price

A newer calculation replaces an earlier result for the same quote revision or working branch.

36. Locked Price

A locked price cannot be changed by ordinary repricing.

It may still be superseded through:

• new quote revision;
• amendment;
• correction;
• or explicit commercial process.

37. Accepted Price

An accepted price is part of a commercial commitment.

Changing it requires a new business action, not a background refresh.

38. Price State Taxonomy

Possible states:

• PREVIEW;
• CALCULATED;
• COMPLETE;
• STALE;
• APPROVED;
• PRESENTED;
• LOCKED;
• ACCEPTED;
• SUPERSEDED;
• CORRECTED.

Use internal states only after verification.

39. Preview Price

Interactive and non-binding.

It may use assumptions or partial context.

40. Calculated Price

Produced successfully but not necessarily complete for quote presentation.

41. Complete Price

All required components and validations exist.

42. Approved Price

Commercial exception, if any, has valid approval.

43. Presented Price

Delivered to customer in a specific proposal/revision.

44. Accepted Price

Customer accepted the exact quote revision.

45. Corrected Price

A correction addresses a recording/calculation defect.

It must preserve previous evidence and downstream impact.

46. Staleness Causes

Common causes:

• price-definition change;
• catalog publication change;
• customer context change;
• contract change;
• quantity change;
• term change;
• configuration change;
• promotion expiry;
• exchange-rate expiry;
• tax result expiry;
• cost change;
• or engine policy change.

47. Cosmetic Change

A cosmetic quote change should not trigger repricing.

Examples:

• internal note;
• display ordering;
• proposal styling;
• non-price-relevant description.

48. Price-Relevant Change

Examples:

• offering;
• selected characteristic;
• quantity;
• term;
• customer/account;
• market;
• channel;
• effective date;
• and requested action.

49. Repricing Trigger Matrix

50. Explicit Repricing

Repricing should be an explicit command or operation.

Example:

RepriceQuoteRevision

Avoid invisible price mutation during read.

51. Repricing Command

Should include:

• quote/revision;
• expected version;
• reason;
• pricing context;
• requested scope;
• actor;
• and idempotency key.

52. Repricing Reason

Possible reason codes:

• CUSTOMER_CHANGED;
• QUANTITY_CHANGED;
• PRICE_EXPIRED;
• CATALOG_UPGRADE;
• CONTRACT_UPDATED;
• MANUAL_REFRESH;
• CORRECTION;
• ORDER_READINESS_CHECK.

53. Full Repricing

Recalculates all price components.

Use when:

• dependency graph uncertain;
• major context changed;
• before critical transition;
• or policy requires.

54. Partial Repricing

Recalculates only affected components.

Needs:

• dependency graph;
• stable component identity;
• and reconciliation.

55. Item-Level Repricing

Only selected quote items are recalculated.

Quote-level discounts may still require broader recomputation.

56. Stage-Level Repricing

Example:

• rerun tax only;
• rerun currency conversion only;
• rerun promotion stage only.

57. Partial Repricing Risk

A quote-level dependency can be missed.

Example:

• one site quantity change alters global volume discount.

58. Incremental versus Full Consistency

Periodic full recalculation should confirm incremental result.

59. Repricing Preview

A preview can show expected changes before commitment.

60. Repricing Diff

A semantic diff should show:

• old/new component;
• amount delta;
• adjustment delta;
• validity delta;
• source/version change;
• and approval impact.

61. User Confirmation

Material repricing should not silently overwrite customer-visible amount.

62. Repricing Outcome

Possible outcomes:

• NO_CHANGE;
• UPDATED;
• REQUIRES_APPROVAL;
• REQUIRES_CUSTOMER_REVIEW;
• FAILED;
• INCOMPLETE;
• CONFLICT.

63. No-Change Repricing

Even when amount unchanged, provenance or validity may change.

Decide whether new snapshot is created.

64. Material Change

Define threshold or semantic rule for materiality.

Examples:

• any customer amount change;
• currency change;
• charge-period change;
• term change;
• or newly introduced fee.

65. Non-Monetary Material Change

A rate may remain same but:

• allowance;
• duration;
• or charge trigger

changes.

This is commercially material.

66. Reapproval Trigger

Possible triggers:

• effective discount changes;
• margin falls below threshold;
• manual override no longer applicable;
• cost changes;
• price floor breached;
• or adjustment scope changes.

67. Customer Reacceptance Trigger

Possible triggers:

• total changes;
• recurring schedule changes;
• currency changes;
• term changes;
• new fee;
• or product scope changes.

68. Repricing Approved Quote

Options:

• invalidate approval;
• retain if change is within approved condition;
• or create new approval request.

69. Repricing Presented Quote

Customer-facing offer should become:

• superseded;
• withdrawn;
• or new revision.

70. Repricing Accepted Quote

Ordinary repricing should not mutate accepted quote.

Possible processes:

• amendment;
• correction;
• change order;
• cancellation and replacement;
• or new agreement.

71. Accepted Commitment Conflict

Current market price may differ from accepted price.

The accepted commitment remains authoritative for the contracted transaction unless legal/commercial policy permits change.

72. Price Correction after Acceptance

If a defect is discovered:

• preserve original accepted evidence;
• determine legal/commercial remedy;
• create correction/amendment;
• notify affected parties;
• update order/billing through explicit process;
• and audit.

73. Underpriced Accepted Quote

Possible responses:

• honor;
• renegotiate;
• cancel under policy;
• or obtain exception.

Architecture cannot decide legal/commercial policy alone.

74. Overpriced Accepted Quote

May require:

• correction;
• credit;
• amendment;
• or billing adjustment.

75. Grandfathering

Grandfathering allows historical price or policy to continue for:

• existing quote;
• existing agreement;
• renewal;
• or installed product.

76. Grandfathering Scope

Define whether it applies to:

• amount;
• rate;
• discount;
• tax treatment;
• allowance;
• or full price schedule.

77. Grandfathering Identity

Reference:

• original price definition;
• entitlement;
• effective period;
• and customer/product scope.

78. Grandfathered Modification

Changing an installed product may:

• retain grandfathered price;
• partially retain;
• or reprice to current offering.

Policy must be explicit.

79. Renewal and Grandfathering

Renewal may end grandfathering or continue it under agreement.

80. Migration Price

A successor product may use a migration-specific price.

81. Price Lock

A price lock may hold:

• amount;
• rate;
• exchange rate;
• discount;
• or full schedule.

82. Lock Duration

Define:

• start;
• end;
• event trigger;
• and expiration.

83. Lock Scope

Possible:

• quote revision;
• customer/account;
• offering;
• or agreement.

84. Lock Violation

If live recalculation differs from locked result, preserve lock and raise diagnostic rather than overwrite.

85. Price Reservation

A reservation may hold scarce price/promotion benefit.

It is a state-changing operation.

86. Reservation Expiry

Expired reservation may make quote price stale.

87. Reservation Release

Release on:

• quote expiry;
• supersession;
• cancellation;
• or explicit action.

88. Price Snapshot and Quote Revision

Each quote revision should identify the snapshot it uses.

89. Revision Immutability

A finalized/presented revision should not have its price snapshot mutated in place.

90. Draft Revision

A draft revision can replace working price snapshot while preserving history as policy requires.

91. Quote Alternative

Different alternatives need independent pricing snapshots.

92. Snapshot Deduplication

Identical immutable components may be content-addressed or shared internally.

Do not weaken transaction identity or audit.

93. Snapshot Storage

Possible approaches:

• normalized relational tables;
• immutable JSON document;
• event-sourced history;
• object storage with hash;
• or hybrid.

94. Structured Document

An immutable structured document can preserve:

• hierarchy;
• trace;
• and schema version.

95. Normalized Tables

Useful for:

• query;
• reporting;
• and component-level reconciliation.

96. Hybrid Storage

Store authoritative immutable snapshot plus indexed projections.

97. Snapshot Schema Version

Needed for long-term interpretation.

98. Schema Migration

Do not rewrite historical snapshot meaning silently.

Use readers/adapters for old versions.

99. Snapshot Checksum

A checksum can detect corruption or unintended mutation.

100. Digital Evidence

For high-assurance workflows, preserve:

• proposal checksum;
• price snapshot checksum;
• accepted revision reference;
• and acceptance evidence.

101. Proposal Consistency

Generated proposal totals must match structured price snapshot.

102. Proposal Generation Race

Price can change while document is generated.

Use:

• exact revision;
• exact snapshot;
• and version check.

103. Acceptance Race

Customer accepts while repricing occurs.

The acceptance command must reference exact revision and expected version.

104. Expiry Race

Acceptance and price expiry occur concurrently.

Use authoritative clock and atomic guard.

105. Repricing Concurrency

Two repricing commands can race.

Use:

• expected quote version;
• calculation idempotency;
• and supersession rules.

106. Idempotent Repricing

Repeated request with same context/reason/idempotency key should return same committed outcome.

107. Calculation Retry

A technical retry should not create multiple quote revisions.

108. Async Repricing

Large quote repricing may be asynchronous.

Need states:

• REQUESTED;
• RUNNING;
• PARTIAL;
• COMPLETED;
• FAILED;
• CANCELLED;
• SUPERSEDED.

109. Partial Async Result

Do not publish partial calculation as final quote price.

110. Cancellation

Cancelling a calculation should not corrupt current valid snapshot.

111. Superseding Calculation

A newer repricing request can supersede an older running job.

Need deterministic winner.

112. Price Freshness SLI

Example:

99% of quote prices used for acceptance are within their required validity windows.

Internal targets must be verified.

113. Repricing Latency SLI

Measure by quote size and calculation mode.

114. Stale Quote Count

Operational metric:

• stale drafts;
• stale approved quotes;
• stale presented quotes;
• and stale but accepted anomalies.

115. Repricing Frequency

High frequency may indicate:

• unstable context;
• over-sensitive triggers;
• poor caching;
• or user workflow friction.

116. Repricing Failure Rate

Break down by:

• missing price;
• contract service;
• tax;
• currency;
• rule conflict;
• and technical defect.

117. Snapshot Reproduction Test

Given snapshot provenance, replay historical calculation and compare within exact or policy tolerance.

118. Replay Limitation

Exact replay may be impossible if:

• external system did not retain version;
• nondeterministic input was not snapshotted;
• or engine version unavailable.

Record limitations honestly.

119. Replay Result Categories

• EXACT_MATCH;
• EXPECTED_POLICY_VARIANCE;
• NON_REPRODUCIBLE;
• DEFECT;
• MISSING_EVIDENCE.

120. Price Reconciliation

Compare:

calculated snapshot
-> presented proposal
-> accepted revision
-> order monetary intent
-> billing charge
-> invoice

121. Quote-to-Order Reconciliation

Verify:

• component identity;
• amount;
• currency;
• period;
• adjustment;
• and validity.

122. Order-to-Billing Reconciliation

Verify transformation and activation.

123. Allowed Variance

Possible legitimate differences:

• final tax;
• actual usage;
• activation-based proration;
• and policy-approved currency conversion.

124. Unexplained Variance

Examples:

• missing discount;
• changed rate;
• duplicate fee;
• wrong period;
• and currency mismatch.

125. Correction Workflow

A mismatch should create:

• discrepancy record;
• severity;
• owner;
• investigation;
• correction/amendment;
• and audit.

126. Price Snapshot API

A read contract may expose:

• snapshot identity;
• state;
• components;
• totals;
• validity;
• provenance summary;
• and version.

Sensitive trace should be separate.

127. Repricing API

Command contract should include:

quoteId
revision
expectedVersion
scope
reason
effectiveAt
context overrides
idempotencyKey

128. Stale Price API Response

Use conflict/domain status that tells client:

• why stale;
• what changed;
• whether repricing is required;
• and which transitions are blocked.

129. Event Model

Representative events:

• QuotePriceCalculated;
• QuotePriceMarkedStale;
• QuoteRepricingRequested;
• QuoteRepriced;
• QuotePriceApproved;
• QuotePriceLocked;
• QuotePriceAccepted;
• QuotePriceCorrectionCreated.

Names must be verified internally.

130. Event Payload

Include:

• quote/revision;
• snapshot ID;
• prior snapshot;
• reason;
• version;
• and relevant validity.

Avoid giant sensitive traces in broad events.

131. Event Ordering

Use quote/revision or aggregate key to preserve ordering where needed.

132. Duplicate Event Handling

Consumers must be idempotent.

133. Event Replay

Consumers should handle historical snapshots and schema versions.

134. Security

Price snapshots may expose:

• customer-specific rate;
• partner economics;
• internal discount;
• cost/margin;
• and approval evidence.

135. Field-Level Visibility

Customer-facing consumers may see:

• charge and discount.

Internal approvers may see:

• basis and margin.

Support may see:

• explanation without confidential cost.

136. Tenant Isolation

Snapshot, trace, cache, event, and search indexes must be tenant-scoped.

137. Retention

Retention should cover:

• accepted quotes;
• calculation traces;
• approval evidence;
• and idempotency records.

138. Redaction

Privacy redaction must preserve commercial and audit integrity where legally required.

139. Data Residency

On-prem or regional deployments may constrain trace storage.

140. Observability

Useful dimensions:

• tenant;
• quote size;
• pipeline version;
• source version;
• stale reason;
• and calculation mode.

141. Support Diagnostic

Support should answer:

Which price snapshot is active?
Why is it stale?
What changed?
Can it be repriced?
Will approval or customer acceptance be invalidated?

142. Price Incident

Examples:

• accepted quote reads current price;
• repricing overwrites presented revision;
• snapshot misses recurring period;
• stale tax silently accepted;
• and partial calculation published as complete.

143. Incident Containment

Possible actions:

• disable automatic repricing;
• lock affected revisions;
• stop order conversion;
• roll back pricing rules;
• identify impacted quotes;
• and create correction workflow.

144. Impact Analysis

Identify affected:

• sessions;
• draft quotes;
• approved quotes;
• presented quotes;
• accepted quotes;
• product orders;
• and billing charges.

145. Price Snapshot Smells

• total only;
• current source reference only;
• no rule versions;
• no validity;
• and mutable rows for accepted quote.

146. Repricing Smells

• repricing on read;
• UI triggers without command;
• no reason code;
• partial recalculation without dependency model;
• and accepted quote automatically updated.

147. Provenance Smells

• no calculation ID;
• current catalog used for explanation;
• no context hash;
• and external data timestamp missing.

148. Validity Smells

• one generic expiry for all dependencies;
• timezone absent;
• stale treated as invalid without policy;
• and no revalidation trigger.

149. Anti-Patterns

Live Price on Historical Quote

Commercial evidence changes over time.

Reprice Everything Automatically

User and customer intent become unstable.

Snapshot without Provenance

Amount preserved but unexplained.

Provenance without Snapshot

Historical result not preserved.

Accepted Quote Recalculation

Commitment is silently changed.

Price Lock as Boolean

No scope, period, or reason.

150. Price Snapshot Template

## Snapshot Identity

## Quote / Revision

## State

## Calculation Identity and Version

## Context Snapshot

## Components

For each:
- Component identity
- Source definition/version
- Charge type
- Quantity/unit
- Amount/currency
- Period
- Adjustments
- Tax status
- Validity

## Totals

## Provenance

## Trace Reference

## Validity

## Checksum

## Audit

151. Repricing Command Template

Command ID:
Quote/revision:
Expected version:
Current snapshot:
Scope:
Reason:
Effective time:
Context changes:
Full or partial:
Idempotency key:
Requested by:

152. Price Diff Template

Old snapshot:
New snapshot:
Changed components:
Added/removed charges:
Adjustment changes:
Currency/period changes:
Total delta:
Validity changes:
Provenance changes:
Approval impact:
Customer reacceptance impact:

153. Staleness Record Template

Snapshot:
Stale reason:
Detected at:
Affected dependency:
Previous version:
Current version:
Blocked transitions:
Required action:
Owner:

154. Reconciliation Record Template

Quote component:
Order component:
Billing charge:
Invoice line:
Expected:
Actual:
Variance:
Allowed policy:
Classification:
Owner:
Resolution:

155. Price Snapshot Invariants

Representative invariants:

• accepted snapshot is immutable;
• every component has currency;
• every recurring component has period;
• every adjustment references basis/scope;
• snapshot references calculation and source versions;
• displayed totals reconcile;
• and order conversion references exact accepted revision.

156. Worked Example: Catalog Price Change

Quote revision 3 uses price definition v10.

Catalog activates v11.

Policy:

• draft revision marked stale;
• user explicitly reprices;
• accepted revision remains unchanged.

157. Worked Example: Contract Change

Customer contract changes from 10% to 15% discount.

Open draft can refresh.

Presented quote requires new revision.

Accepted quote remains committed unless amendment occurs.

158. Worked Example: Tax Expiry

Base price remains valid.

Tax estimate expires.

System marks:

• tax stage stale;
• quote presentation policy decides whether tax-only refresh is allowed.

159. Worked Example: Partial Repricing

One site changes from 500 Mbps to 1 Gbps.

Recalculate:

• site access charge;
• site router charge;
• quote-level volume adjustment;
• margin/approval.

Do not reprice unrelated immutable accepted alternative.

160. Worked Example: Accepted Price Conflict

Market price rises after acceptance.

Order conversion uses accepted snapshot.

Current list price is retained only for comparison, not substitution.

161. Worked Example: Price Correction

A rounding defect made accepted total 0.01 too high.

System preserves original acceptance, creates correction evidence, and drives explicit order/billing remedy.

162. Worked Example: Repricing Race

Two users trigger repricing.

Both start from version 12.

First commits version 13.

Second is rejected or superseded because expected version is stale.

163. Worked Example: Async Supersession

Calculation A runs for old quantity.

User changes quantity and starts Calculation B.

B supersedes A.

A completion cannot overwrite B result.

164. Worked Example: Historical Replay

Replay uses:

• catalog publication 21;
• pipeline v5;
• engine 3.2;
• contract v7;
• exchange rate RATE-99.

Result matches snapshot exactly.

165. Senior Engineer Operating Model

Separate live definitions from transaction snapshots

Do not make old quotes depend on current data.

Preserve provenance and calculation identity

Totals alone are insufficient.

Model price state

Preview, complete, stale, approved, accepted, and corrected.

Make repricing explicit

Use commands and reason codes.

Protect accepted commitments

Use amendments or corrections.

Build dependency-aware partial repricing

Then reconcile with full calculation.

Design concurrency and race behavior

Repricing, expiry, document generation, and acceptance.

Operate price freshness

Metrics, diagnostics, and reconciliation.

Retain evidence securely

Trace sensitivity matters.

166. Internal Verification Checklist

Snapshot content

• Does quote store item/component breakdown?
• Are quantity, unit, currency, period, adjustment, and tax status retained?
• Are calculation, catalog, rule, pipeline, and engine versions stored?
• Is a checksum or immutable store used?

Validity and staleness

• What validity dimensions exist?
• What makes price stale?
• Are stale and invalid distinguished?
• Which transitions are blocked?

Repricing

• Is repricing explicit?
• What events trigger it?
• Is partial repricing supported?
• How is incremental/full consistency verified?

Approval and acceptance

• What repricing invalidates approval?
• When is customer reacceptance required?
• Can a presented quote be overwritten?
• Can an accepted quote ever be repriced directly?

Grandfathering and locks

• What can be locked?
• What is the scope and duration?
• How are existing products and renewals handled?
• How are migration prices represented?

Concurrency

• How are repricing races handled?
• Is calculation idempotent?
• Can async jobs be superseded?
• How are acceptance/expiry races resolved?

Reconciliation and operations

• Can quote price be traced to order and billing?
• What variances are legitimate?
• Can historical calculations be replayed?
• What stale-price metrics and support tools exist?

167. Practical Exercises

Exercise 1 — Snapshot inventory

List every field required to reproduce one accepted quote.

Exercise 2 — Trigger matrix

Map quote changes to repricing, reapproval, and reacceptance.

Exercise 3 — Partial repricing

Design dependency-aware repricing for one site in a multi-site quote.

Exercise 4 — Race analysis

Model repricing versus acceptance and repricing versus expiry.

Exercise 5 — Grandfathering

Define behavior for add, modify, upgrade, and renewal.

Exercise 6 — Reconciliation

Trace one accepted recurring component through invoice.

168. Part Completion Checklist

You are done if you can:

• distinguish live price definitions from quote snapshots;
• define minimum pricing provenance;
• model preview, stale, locked, and accepted states;
• define validity dimensions;
• make repricing explicit;
• design partial and full repricing;
• protect accepted commitment;
• handle price locks and grandfathering;
• resolve repricing concurrency;
• replay and reconcile historical pricing;
• and create an internal snapshot/repricing verification backlog.

169. Key Takeaways

1. A quoted price is a structured snapshot, not only a total.
2. Snapshot and provenance must coexist.
3. Result validity differs from definition validity.
4. Stale does not automatically mean incorrect.
5. Repricing must be explicit.
6. Partial repricing requires dependency awareness.
7. Presented and accepted revisions cannot be silently overwritten.
8. Accepted price changes require a business process.
9. Historical replay requires versioned external inputs.
10. Internal CSG snapshot, repricing, and validity policies must be verified.

170. References

Conceptual baseline:

• General enterprise CPQ price-snapshot, repricing, validity, and grandfathering practices.
• Domain-Driven Design immutable transaction snapshots, provenance, commands, and concurrency.
• Distributed systems idempotency, asynchronous jobs, supersession, and race-condition handling.
• Quote-to-order and quote-to-billing monetary reconciliation practices.

These references do not define internal CSG pricing snapshot or repricing implementation.