Part 024 — Quote States, Transitions, Guards, and Terminal Outcomes

Positioning

Quote lifecycle sering dimodelkan sebagai satu field:

status = DRAFT | APPROVED | ACCEPTED | REJECTED

Model ini terlalu sederhana untuk enterprise CPQ karena Quote juga mengalami:

• validation;
• pricing;
• approval;
• document generation;
• customer presentation;
• waiting;
• expiry;
• withdrawal;
• revision;
• acceptance;
• conversion;
• cancellation;
• and correction.

Jika business state, processing state, approval state, dan integration state dicampur dalam satu enum, state explosion akan terjadi.

Core thesis: Quote lifecycle harus memiliki business state machine yang eksplisit, transition guards yang authoritative, orthogonal process states, deterministic timer behavior, dan terminal outcomes yang menjaga historical evidence.

1. Quote Business Lifecycle

A representative business lifecycle may include:

DRAFT
-> READY_FOR_APPROVAL
-> PENDING_APPROVAL
-> APPROVED
-> PRESENTED
-> ACCEPTED

Alternative terminal outcomes:

REJECTED
EXPIRED
WITHDRAWN
CANCELLED

Actual states must reflect internal semantics.

2. State versus Status

State

Controls allowed behavior and transition.

Status

May be a UI/reporting projection.

Prefer explicit domain state.

3. Business State

Describes commercial meaning.

Examples:

• Draft;
• Pending Approval;
• Approved;
• Presented;
• Accepted;
• Rejected;
• Expired;
• Withdrawn;
• Cancelled.

4. Processing State

Describes ongoing technical work.

Examples:

• Repricing;
• Validating;
• Generating Proposal;
• Converting to Order;
• Synchronizing CRM.

5. Approval State

May be separate workflow:

• Not Required;
• Required;
• Requested;
• In Review;
• Approved;
• Rejected;
• Expired;
• Superseded.

6. Document State

May be:

• Not Generated;
• Generating;
• Generated;
• Delivered;
• Failed;
• Superseded.

7. Integration State

May be:

• Not Sent;
• Sent;
• Acknowledged;
• Retry Pending;
• Failed.

8. Why Orthogonal States Matter

Combining all dimensions produces states such as:

APPROVED_DOCUMENT_FAILED_CRM_PENDING

This is unmanageable.

9. Quote State Machine Scope

The state machine should govern:

• commercial lifecycle;
• not every asynchronous sub-process.

10. State Machine Components

For each transition define:

• command;
• current state;
• actor;
• authority;
• guard;
• atomic changes;
• emitted event;
• side effects;
• idempotency;
• and failure reason.

11. Candidate Business States

Illustrative set:

• DRAFT;
• VALIDATING;
• READY;
• PENDING_APPROVAL;
• APPROVED;
• PRESENTED;
• ACCEPTED;
• REJECTED;
• EXPIRED;
• WITHDRAWN;
• CANCELLED;
• SUPERSEDED.

Avoid using processing states as business states unless behavior requires.

12. Draft

A Draft can be edited.

It may be:

• incomplete;
• invalid;
• unpriced;
• and unqualified.

13. Ready

Ready means the quote satisfies prerequisites for a target transition.

It may be a derived readiness projection rather than persisted business state.

14. Pending Approval

The quote revision awaits required commercial/legal approval.

15. Approved

Required approvals are valid for exact revision and evidence.

Approved does not necessarily mean customer-visible.

16. Presented

A specific revision/proposal has been delivered to customer.

17. Accepted

Customer or authorized party accepted exact revision.

18. Rejected

Customer or approver rejected the quote depending on local semantics.

Avoid overloading one state for two different actors.

19. Customer Declined

A more precise state than generic Rejected when customer declines.

20. Approval Rejected

Could remain approval workflow state while Quote returns to Draft or becomes Closed.

21. Expired

Validity period ended without acceptance.

22. Withdrawn

Seller withdraws a presented proposal.

23. Cancelled

Quote is intentionally terminated before normal completion.

24. Superseded

A newer revision or quote replaces the previous customer-facing revision.

25. Terminal State

A terminal state ends normal lifecycle progression.

Possible terminal states:

• Accepted;
• Customer Declined;
• Expired;
• Withdrawn;
• Cancelled;
• Superseded.

Accepted may initiate downstream order process but remains terminal for quote editing.

26. Soft Terminal State

A state may permit follow-up through:

• clone;
• new revision;
• amendment;
• or replacement quote.

That is not the same as reopening in place.

27. State Hierarchy

Possible grouping:

OPEN
- Draft
- Pending Approval
- Approved
- Presented

CLOSED
- Accepted
- Declined
- Expired
- Withdrawn
- Cancelled
- Superseded

28. Transition Table

29. Create Quote

Command:

CreateQuote

Result:

• QuoteCreated;
• state Draft;
• revision initialized;
• context recorded.

30. Edit Quote

Allowed primarily in Draft.

Editing Approved or Presented quote should create new revision or invalidate state according to policy.

31. Validate Quote

Validation can be:

• synchronous;
• asynchronous;
• full;
• or incremental.

Validation result does not necessarily change business state.

32. Mark Ready

Ready may be derived from current validation/readiness snapshot.

Avoid manual status assignment without evidence.

33. Submit for Approval

Command:

SubmitQuoteForApproval

Guards may include:

• quote complete;
• configuration valid;
• qualification current;
• pricing complete;
• profitability calculated;
• and no unresolved blocking issue.

34. Approval Not Required

If policy says no approval is required, transition may move directly to Approved/Ready-to-Present.

35. Request Approval

Approval request should bind to exact:

• quote revision;
• price snapshot;
• cost/margin evidence;
• and policy version.

36. Approve Quote

Approval decision should be separate authoritative fact.

Quote transition verifies valid decision.

37. Reject Approval

Possible outcomes:

• return to Draft;
• create new revision;
• or close.

Do not use same semantics as customer rejection.

38. Conditional Approval

Quote remains approved only while conditions hold.

39. Approval Expiry

Expired approval invalidates present/accept transition according to policy.

40. Reapproval

Repricing or commercial change may return quote to Draft/Pending Approval.

41. Generate Proposal

Document generation is a process.

It should use exact revision and snapshot.

42. Proposal Generation Failure

Should not necessarily change Quote business state.

Document state becomes Failed.

43. Present Quote

Command:

PresentQuote

Guards:

• exact revision finalized;
• approval valid;
• proposal generated;
• price valid;
• terms complete;
• and actor authorized.

44. Presented Revision

Record:

• revision;
• proposal ID;
• presentedAt;
• recipient;
• channel;
• and delivery evidence.

45. Re-Present Quote

A new delivery of same revision may not create new commercial revision.

Record delivery event.

46. Change after Presentation

Material change should create new revision and supersede/withdraw prior proposal.

47. Accept Quote

Command:

AcceptQuote

Must identify:

• quote;
• revision;
• proposal;
• accepter;
• authority;
• and idempotency key.

48. Acceptance Guard

Check:

• state Presented or otherwise acceptable;
• revision matches;
• not expired;
• not withdrawn;
• price/approval valid;
• accepter authorized;
• and no newer superseding revision.

49. Acceptance Evidence

Store:

• actor/party;
• role;
• timestamp;
• channel;
• accepted revision;
• proposal checksum;
• signature/reference;
• and terms.

50. Authorized Accepter

Possible:

• customer signatory;
• buyer;
• delegated user;
• partner acting under authority;
• or internal operator with evidence.

51. Acceptance Is Not a Boolean

A boolean loses:

• who;
• what;
• when;
• which revision;
• and evidence.

52. Acceptance Idempotency

Repeated same acceptance should return original outcome.

53. Duplicate Acceptance

Do not:

• create duplicate acceptance records;
• duplicate orders;
• or send duplicate irreversible effects.

54. Acceptance Race

Two parties accept concurrently.

Use atomic transition and idempotency.

55. Acceptance versus Expiry Race

Use authoritative clock and atomic guard.

56. Acceptance versus Withdrawal Race

Only one transition should win based on version and command ordering.

57. Acceptance versus New Revision Race

Acceptance references exact presented revision.

A draft newer revision does not automatically invalidate the old presented revision unless policy says so.

58. Customer Decline

Command:

DeclineQuote

Store:

• reason;
• party;
• time;
• and revision.

59. Decline Reason

Possible:

• price;
• product fit;
• timing;
• competitor;
• no budget;
• and other.

Use stable code plus optional detail.

60. Decline Is Terminal for Revision

A new negotiation should create:

• new revision;
• clone;
• or new quote

according to policy.

61. Withdraw Quote

Seller withdraws an offer.

Reasons:

• error;
• no longer available;
• commercial risk;
• compliance;
• and duplicate quote.

62. Withdrawal Authority

Not every editor should withdraw a customer-facing offer.

63. Withdrawal Notification

Customer may need notification.

Notification failure should not necessarily roll back withdrawal.

64. Cancel Quote

Cancellation may apply to:

• draft;
• pre-presentation;
• or abandoned workflow.

Distinguish from withdrawal of a presented offer.

65. Cancel Reason

Examples:

• duplicate;
• customer request;
• opportunity closed;
• invalid context;
• and administrative cleanup.

66. Expire Quote

Expiry is a business transition triggered by time.

67. Validity Instant

Define:

• validUntil;
• timezone;
• inclusivity;
• and authoritative clock.

68. Interval Convention

Prefer explicit convention such as:

[validFrom, validUntil)

69. Scheduler

Expiry may be implemented by:

• scheduler;
• delayed message;
• workflow timer;
• or periodic scan.

70. Timer Idempotency

Expiry timer may fire more than once.

Transition must be idempotent.

71. Late Timer

If scheduler runs late, effective expiry still occurs according to business time.

72. Missed Timer

Periodic reconciliation should find open quotes past validity.

73. Timer versus Derived Expiry

A quote can be considered expired by guard even before persisted transition job runs.

74. Expiry Event

Emit once authoritative state transition is persisted.

75. Expiry Notification

Separate process.

76. Extend Validity

Extending validity may require:

• repricing;
• reapproval;
• new revision;
• and customer re-presentation.

77. Renew Quote Validity

Do not update validUntil on presented revision silently.

78. Reopen Quote

Reopening terminal quote in place is risky.

Alternatives:

• CreateRevision;
• CloneQuote;
• CreateReplacementQuote;
• or Amendment.

79. Reopen Draft after Approval Rejection

This can be valid if the same quote revision returns to Draft with approval invalidated.

80. Reopen after Customer Decline

Usually create new commercial revision or new quote.

Preserve decline evidence.

81. Reopen after Expiry

Possible:

• new revision with refreshed price/validity;
• clone;
• or explicit renewal operation.

82. Reopen after Acceptance

Do not reopen accepted revision.

Use amendment/change order.

83. Reopen after Cancellation

Only with explicit administrative recovery policy.

Often clone is safer.

84. Supersede Revision

A newer presented revision supersedes older one.

Older revision remains immutable and non-acceptable.

85. Supersession Guard

Check exact relationship and no existing acceptance.

86. Withdraw versus Supersede

Withdraw

Offer removed without replacement.

Supersede

Replacement revision/quote exists.

87. Correct Quote

Correction addresses recording or calculation defect.

It should preserve original evidence.

88. Correct Draft

Ordinary edit.

89. Correct Presented Quote

Create new revision and withdraw/supersede old proposal.

90. Correct Accepted Quote

Requires explicit legal/commercial correction or amendment process.

91. Quote-to-Order Conversion

Acceptance may trigger order conversion.

This is a separate long-running process.

92. Conversion State

Keep separate from quote business state:

• Not Started;
• Running;
• Completed;
• Failed;
• Manual Review.

Quote remains Accepted.

93. Conversion Failure

Do not revert accepted quote to Presented.

The commercial acceptance remains true.

94. Retry Conversion

Use idempotency and unique accepted-revision reference.

95. Conversion Terminal Outcome

Every accepted quote should eventually have:

• Product Order reference;
• explicit no-order outcome;
• or final conversion failure.

96. Business State versus Order State

Quote Accepted does not mean Product Order Completed.

97. State Transition Ownership

Examples:

• Sales creates/edits/submits.
• Approver decides exception.
• Seller presents/withdraws.
• Customer accepts/declines.
• Timer expires.
• System coordinates conversion.

98. Authority

Every transition must enforce role and context authority server-side.

99. UI Button Is Not Authority

Hidden/disabled button is not security control.

100. Transition Guard

A guard is evaluated atomically with transition where possible.

101. Guard Categories

• state guard;
• version guard;
• actor guard;
• readiness guard;
• temporal guard;
• approval guard;
• and uniqueness/idempotency guard.

102. State Guard

Current state must allow command.

103. Version Guard

Expected aggregate/revision version must match.

104. Actor Guard

Actor has permission and party authority.

105. Readiness Guard

Quote is complete, valid, priced, and qualified.

106. Temporal Guard

Quote and dependent evidence are not expired.

107. Approval Guard

Required approval is valid and conditions hold.

108. Idempotency Guard

Command is not a duplicate or can replay prior result.

109. Illegal Transition

Return:

• current state;
• attempted command;
• reason code;
• allowed commands;
• and remediation.

110. Reason Codes

Examples:

• QUOTE_NOT_READY;
• APPROVAL_REQUIRED;
• APPROVAL_EXPIRED;
• PRICE_STALE;
• QUOTE_EXPIRED;
• REVISION_SUPERSEDED;
• ACCEPTANCE_ALREADY_RECORDED;
• INVALID_CURRENT_STATE;
• ACTOR_NOT_AUTHORIZED.

111. HTTP Semantics

Possible mapping:

• 409 Conflict for state/version conflict;
• 422 Unprocessable Entity for business-readiness failure;
• 403 for authorization;
• 404 for inaccessible/nonexistent resource.

Internal API strategy must be verified.

112. Duplicate Command

A duplicate can return:

• original result;
• already-completed status;
• or conflict.

Define by command.

113. Out-of-Order Command

Example:

• acceptance callback arrives after withdrawal.

Use state/version and evidence to decide.

114. Delayed External Callback

Do not blindly apply late result.

115. Command Correlation

Store:

• command ID;
• correlation ID;
• and causation ID.

116. Transition Atomicity

Persist atomically:

• new state;
• state history;
• business evidence;
• and outbox record.

117. Transactional Outbox

Ensures state transition event is not lost.

118. State History

Record:

fromState
toState
command
actor
reason
effectiveAt
recordedAt
revision
version
correlation

119. Effective Time versus Recorded Time

Customer acceptance may occur at one time and be recorded later.

Preserve both.

120. Backdated Transition

Use only under explicit correction policy.

121. Event Time

When business transition occurred.

122. Processing Time

When system processed it.

123. State History Immutability

Do not update old transition records in place.

124. State Machine Implementation

Options:

• explicit domain code;
• state-machine library;
• workflow engine;
• event-sourced aggregate;
• or hybrid.

125. Explicit Domain Code

Benefits:

• transparent;
• testable;
• and domain language friendly.

126. State-Machine Library

Benefits:

• formal transitions;
• reusable guards.

Risks:

• generic callbacks;
• and framework leakage.

127. Workflow Engine

Useful for:

• approval;
• timers;
• human tasks;
• and long-running process.

Do not let it become sole owner of Quote business truth accidentally.

128. Event Sourcing

Can preserve full lifecycle history.

Adds:

• schema evolution;
• projection;
• and operational complexity.

129. Database Constraint

Can protect state values and conditional update.

It should complement domain guards.

130. Compare-and-Set

Example:

UPDATE quote
SET state = 'ACCEPTED', version = version + 1
WHERE id = ?
  AND revision = ?
  AND state = 'PRESENTED'
  AND version = ?

Domain conditions must still be validated.

131. State Explosion

Avoid combined states for:

• approval;
• document;
• integration;
• conversion;
• and customer lifecycle.

132. Boolean Flag Explosion

Avoid:

isApproved
isPresented
isAccepted
isExpired
isCancelled

Impossible combinations arise.

133. Derived Status

UI may show:

Awaiting Customer

derived from:

• business state Presented;
• proposal delivered;
• no acceptance.

134. Status Projection

Projection can simplify user experience.

It must not become command authority.

135. Allowed Actions Projection

API can expose currently allowed actions based on authoritative evaluation.

Client still cannot rely on stale allowed-actions response for command success.

136. State Compatibility

Adding a new state can break consumers.

137. Unknown State

External clients should handle unknown state safely.

138. State Versioning

A lifecycle contract may require versioning when semantics change.

139. Migration

Changing state model requires mapping existing quotes.

140. Legacy State Mapping

Document:

• old state;
• new state;
• and ambiguity.

141. Migration Safety

Do not infer Accepted from unrelated flags without evidence.

142. State Machine Test

Test every:

• allowed transition;
• illegal transition;
• guard;
• terminal behavior;
• and state projection.

143. Transition Table Test

Generate tests from transition matrix.

144. Model-Based Testing

Generate command sequences and verify invariants.

145. Property-Based Testing

Properties:

• accepted revision never becomes editable;
• no quote is both accepted and expired;
• duplicate acceptance creates one effect;
• terminal state does not transition without explicit recovery process;
• and state history remains ordered.

146. Temporal Testing

Test:

• just before expiry;
• exactly at boundary;
• just after;
• timezone;
• and delayed timer.

147. Concurrency Testing

Test:

• accept versus expire;
• accept versus withdraw;
• reprice versus present;
• new revision versus accept;
• and duplicate conversion.

148. Retry Testing

Test repeated:

• presentation;
• acceptance;
• expiry timer;
• and conversion command.

149. Failure Testing

Test:

• outbox publication failure;
• document failure;
• approval service timeout;
• and order conversion timeout.

150. Recovery Testing

Test:

• process restart;
• stale command;
• manual correction;
• and timer reconciliation.

151. State Metrics

Useful metrics:

• count by state;
• age by state;
• transition rate;
• illegal transition rate;
• and terminal outcome distribution.

152. State Age

Track time in:

• Draft;
• Pending Approval;
• Approved;
• Presented;
• and Conversion Failed.

153. Quote Cycle Time

Possible intervals:

• create to present;
• present to accept;
• accept to order;
• and create to terminal outcome.

154. Expiry Rate

High expiry rate may indicate:

• pricing delay;
• approval bottleneck;
• or customer follow-up issue.

155. Withdrawal Rate

Analyze reasons and affected products.

156. Illegal Transition Rate

May reveal:

• stale clients;
• workflow confusion;
• or integration retry defect.

157. Stuck Quote

Examples:

• Pending Approval beyond SLA;
• Approved but no proposal;
• Presented beyond validity with no expiry transition;
• Accepted with no conversion result.

158. Stuck Detection

Use:

• state age;
• expected next action;
• owner;
• and timer.

159. Reconciliation Job

Find:

• presented quotes past expiry;
• accepted quotes without order process;
• terminal quotes with active timers;
• and superseded revisions still accept-enabled.

160. Manual Recovery

Use explicit commands:

• ReconcileExpiry;
• ReissueProposal;
• RetryOrderConversion;
• CorrectAcceptanceEvidence;
• SupersedeRevision.

161. Direct Database Update Risk

Bypasses:

• guards;
• events;
• history;
• and downstream consistency.

162. Recovery Authority

Manual recovery needs:

• elevated role;
• reason;
• evidence;
• and audit.

163. Quote Lifecycle SLI

Examples:

• 99.9% expiry transitions reflected within policy window;
• zero accepted revision mutations;
• zero duplicate order creations per accepted revision;
• and all terminal transitions auditable.

Internal targets must be verified.

164. Event Model

Representative events:

• QuoteCreated;
• QuoteSubmittedForApproval;
• QuoteApproved;
• QuoteApprovalRejected;
• QuotePresented;
• QuoteAccepted;
• QuoteDeclined;
• QuoteExpired;
• QuoteWithdrawn;
• QuoteCancelled;
• QuoteSuperseded.

165. Event Naming

Use past-tense business facts.

Avoid:

• QuoteStatusChanged;
• EntityUpdated.

166. Event Payload

Include:

• quote;
• revision;
• previous/new state;
• effective/recorded time;
• actor/party;
• reason;
• and evidence reference where appropriate.

167. Sensitive Event Data

Do not broadcast:

• full proposal;
• signature;
• personal data;
• price trace;
• or confidential approval detail.

168. Consumer Idempotency

Each consumer handles duplicate events.

169. Event Ordering

Use quote/revision key.

170. Event Replay

State consumers must support historical schema versions.

171. Notification Process

Notifications consume lifecycle events.

Failure does not necessarily reverse business transition.

172. CRM Synchronization

CRM is a projection/integration.

CRM failure should not mutate authoritative quote state casually.

173. Search Index

Update from events.

Projection lag must be understood.

174. Customer Portal

Portal displays state projection and allowed next action.

175. Approval Integration

Quote references approval outcome.

Avoid dual ownership of Quote state.

176. Document Integration

Proposal state is orthogonal.

177. Order Integration

Accepted event initiates idempotent conversion.

178. Agreement Integration

Acceptance may create or reference Agreement.

Boundary depends on domain model.

179. Audit and Legal Evidence

For Presented and Accepted transitions, preserve:

• exact revision;
• exact proposal;
• terms;
• parties;
• timestamps;
• and delivery/acceptance evidence.

180. Lifecycle Security

Transition permissions may differ:

• edit;
• submit;
• approve;
• present;
• accept;
• withdraw;
• cancel;
• and recover.

181. Customer Acceptance Authorization

Validate customer-party authority, not only authenticated user.

182. Internal Acceptance Proxy

If internal operator records offline acceptance:

• require evidence;
• record original accepter;
• and distinguish recorder from accepter.

183. Replay Attack

Acceptance endpoint should protect against:

• repeated token;
• expired link;
• wrong revision;
• and tampered proposal.

184. Acceptance Token

If used, bind to:

• quote;
• revision;
• recipient;
• expiry;
• and nonce.

185. Link Expiry versus Quote Expiry

These are separate.

186. Signature Evidence

May include:

• digital signature;
• signed document;
• authenticated click;
• or external agreement reference.

187. State Machine Smells

• one generic status;
• booleans for lifecycle;
• approval and customer rejection conflated;
• and conversion failure resets Accepted.

188. Transition Smells

• state changed by generic update endpoint;
• no guard;
• no expected version;
• and UI decides legality.

189. Expiry Smells

• server timezone implicit;
• read-time expiry with no event;
• timer non-idempotent;
• and accepted quote later marked expired.

190. Reopen Smells

• accepted quote moved back to Draft;
• decline evidence overwritten;
• and terminal state history deleted.

191. Integration Smells

• CRM status treated as authority;
• document failure blocks unrelated state forever;
• and duplicate accepted event creates duplicate order.

192. Anti-Patterns

Status as Free Text

No valid-transition semantics.

One Mega Enum

Business, processing, approval, and integration combined.

Reopen Everything

Historical truth becomes mutable.

Timer as Best Effort Only

Expired quotes remain actionable.

Acceptance without Revision

Wrong proposal can be accepted.

Conversion Failure Reverts Acceptance

Commercial fact is lost.

193. Quote State Machine Template

## States

## State Meaning

## Commands

## Actors and Authority

## Transition Table

## Guards

## Timers

## Terminal States

## Re-entry / Revision Policy

## Approval Integration

## Document Integration

## Order Conversion Integration

## Audit Events

## Recovery Commands

## Metrics

194. Transition Specification Template

Transition:
Command:
Current states:
Actor/authority:
Expected revision/version:
Guards:
Atomic changes:
Evidence:
Next state:
Event:
External effects:
Idempotency:
Failure reasons:
Recovery:

195. Expiry Policy Template

Validity start:
Validity end:
Timezone:
Boundary convention:
Authoritative clock:
Timer mechanism:
Late timer policy:
Acceptance race policy:
Extension policy:
Notification:
Reconciliation:

196. Acceptance Evidence Template

Quote:
Revision:
Proposal/document:
Accepter party:
Accepter role/authority:
Recorder:
Channel:
Effective time:
Recorded time:
Signature/evidence:
Idempotency key:
Checksum:

197. Terminal Outcome Template

State:
Effective time:
Actor:
Reason:
Related revision:
Evidence:
Allowed follow-up:
Downstream process:
Retention:

198. Worked Example: Straight-Through Quote

Draft
-> Valid
-> No Approval Required
-> Presented
-> Accepted

Acceptance triggers idempotent order conversion.

199. Worked Example: Approval Rejection

Draft
-> Pending Approval
-> Approval Rejected
-> Draft New Revision

The rejected decision remains immutable.

200. Worked Example: Presented Quote Repricing

Presented Revision 4 becomes stale due to customer-requested quantity change.

System creates Revision 5.

Revision 4 is superseded/withdrawn.

Revision 5 is repriced, reapproved, and presented.

201. Worked Example: Expiry Race

At exact validity boundary:

• acceptance command and expiry timer race.

Atomic guard and interval convention determine one winner.

202. Worked Example: Duplicate Acceptance

Customer double-clicks acceptance.

Same idempotency key returns original acceptance and one order-conversion process.

203. Worked Example: Conversion Failure

Quote is Accepted.

Order service unavailable.

Conversion state becomes Failed/Retry Pending.

Quote remains Accepted.

204. Worked Example: Customer Decline

Customer declines Revision 3 due to price.

Sales creates Revision 4 with different configuration.

Decline evidence for Revision 3 remains.

205. Worked Example: Seller Withdrawal

A product defect requires withdrawal.

Seller withdraws all active proposals for affected offering through explicit governed process.

206. Worked Example: Offline Signature

Customer signs PDF offline.

Internal operator records acceptance with:

• signed document;
• original customer signatory;
• recorder identity;
• and evidence checksum.

207. Worked Example: Expiry Reconciliation

Scheduler outage lasts two hours.

Reconciliation marks past-due Presented quotes Expired using effective business time and emits idempotent events.

208. Senior Engineer Operating Model

Separate state dimensions

Business, approval, document, integration, and conversion.

Define every transition

Command, actor, guard, evidence, and event.

Protect terminal history

Use revision/amendment rather than reopening accepted state.

Treat time as domain behavior

Expiry needs timezone, interval, timer, and race policy.

Bind acceptance to exact revision

Never accept “the current quote” ambiguously.

Keep conversion separate

Accepted remains true despite downstream failure.

Make commands idempotent

Especially acceptance, expiry, and conversion.

Build recovery as domain operations

No direct data fixes.

Measure state age and stuck processes

Lifecycle is operational.

209. Internal Verification Checklist

Official states

• What are the official business states?
• Are processing, approval, document, integration, and conversion states separate?
• Which states are terminal?
• Are UI statuses derived or authoritative?

Transitions

• What commands drive each transition?
• Which actors/parties may execute them?
• Are guards server-side and atomic?
• Are reason codes stable?

Approval

• Is approval embedded or a separate workflow?
• How does Quote verify approval?
• What changes cause reapproval?
• What does approval rejection do to Quote state?

Presentation and acceptance

• Is presentation tied to exact revision/proposal?
• What acceptance evidence is stored?
• How is customer authority verified?
• Are duplicate/replayed acceptances idempotent?

Expiry and time

• What timezone and interval convention apply?
• How is expiry scheduled?
• What happens during timer delay/outage?
• How are accept/expire and withdraw/accept races resolved?

Re-entry

• Can rejected, expired, withdrawn, cancelled, or accepted quotes reopen?
• When is a new revision required?
• When is a new quote required?
• How are superseded revisions made non-acceptable?

Conversion

• Is quote-to-order conversion separate from Quote state?
• Is it idempotent?
• Can conversion failure revert acceptance?
• How are stuck accepted quotes detected?

Operations and audit

• Are transition history and outbox atomic?
• Can support inspect state, guard failures, and evidence?
• Are state age and illegal transitions measured?
• What explicit recovery commands exist?

210. Practical Exercises

Exercise 1 — State taxonomy

Separate current quote statuses into business, process, approval, document, and integration dimensions.

Exercise 2 — Transition table

Define every command, guard, actor, event, and failure reason.

Exercise 3 — Race analysis

Model accept-versus-expire, accept-versus-withdraw, and accept-versus-new-revision.

Exercise 4 — Re-entry policy

Define follow-up behavior for each terminal state.

Exercise 5 — Conversion process

Design idempotent accepted-quote-to-order flow with retry.

Exercise 6 — Recovery

Replace direct database status updates with explicit commands.

211. Part Completion Checklist

You are done if you can:

• define authoritative Quote business states;
• separate orthogonal process states;
• model guarded transitions;
• bind approval and acceptance to exact revision;
• design deterministic expiry;
• handle duplicate commands and races;
• protect terminal history;
• distinguish withdrawal, cancellation, rejection, expiry, and supersession;
• separate order conversion from quote state;
• operate and recover the lifecycle safely;
• and create an internal Quote state-machine verification backlog.

212. Key Takeaways

1. Quote lifecycle needs a formal state machine.
2. Business state must be separated from processing state.
3. Approval rejection and customer decline are different.
4. Presented and accepted transitions require exact revision evidence.
5. Expiry is a business transition, not only a computed label.
6. Acceptance, expiry, and withdrawal races need atomic guards.
7. Terminal history should not be reopened casually.
8. Quote acceptance and order conversion are separate truths.
9. Duplicate commands must be idempotent.
10. Internal CSG Quote states and transition policies must be verified.

213. References

Conceptual baseline:

• General CPQ quote lifecycle, approval, presentation, acceptance, expiry, withdrawal, and cancellation practices.
• Finite-state machines, guarded transitions, hierarchical/orthogonal states, and temporal modeling.
• Domain-Driven Design commands, events, aggregates, invariants, and immutable evidence.
• Distributed systems idempotency, outbox, retries, race conditions, and long-running order conversion.

These references do not define internal CSG Quote lifecycle states or workflow implementation.