A catalog price answers what the business currently offers. A quoted or accepted order price may answer what applied to a particular customer decision. Those values can legitimately differ. A database-backed sales service needs to preserve the pricing basis that the business intended, rather than reconstruct every historical order from the current catalog.
The important selection question is how an application maintains that distinction through changes. This is especially relevant to negotiated sales and approval workflows that continue while product prices change elsewhere in the business.
Define when the price is fixed or recalculated
The business should specify which event fixes the price, if any, and when recalculation is allowed. A saved draft, an issued quote, and an accepted order may have different rules. These are commercial-process decisions that need to be reflected in the application.
Shopify’s B2B draft-order guide provides a specific example. It documents price locking to preserve a quoted price despite later catalog changes. It also describes different defaults in different draft and invoice contexts, so buyers should not assume all drafts are automatically locked. The guide excludes price locks for product bundles.
The broader lesson is to make the intended behavior explicit. A price lock in this example is an application pricing choice; it is not an instruction to hold a database lock open while a customer considers the offer.
Keep the accepted basis explainable
When a business intends an accepted price to remain fixed, the order needs enough information to explain that price later. Merely storing a product identifier and looking up its newest price can lose the original basis.
An illustrative order might use a negotiated line price while the catalog changes the next day. A customer-service employee should be able to explain the accepted amount without treating either value as an error. The current catalog can remain correct for new sales while the earlier order remains correct for its agreed scope.
This example does not determine whether a particular quote is legally binding or which pricing policy a merchant must adopt. It identifies the information the application needs once the organization has chosen its policy.
Distinguish an edit from a silent repricing
An order or quote can change after its initial creation. Adding a product, increasing a quantity, or reopening a discussion may require a new pricing decision. The application should identify what is being reconsidered and what remains under the earlier basis.
For evaluation, change the catalog while leaving the sales record untouched, then make an authorized change to the sales record. Ask the team to explain which values change in each case and why. The same update should not have different meanings depending on which screen happens to save it.
Also examine corrections. If a staff member fixes an incorrect amount, retain enough context to distinguish a correction from a newly negotiated offer. The objective is an understandable commercial history, not a prohibition on legitimate changes.
Review the information at each stage
Use a small map to connect the pricing decision with the record that explains it.
| Sales stage | Question for the application | Evidence to inspect |
|---|---|---|
| Catalog offer | What applies to a new purchase now? | The current pricing context |
| Quote or draft | Is this price fixed or subject to recalculation? | The chosen rule and relevant quote state |
| Accepted order | What basis was accepted for this scope? | The applicable line values and decision context |
| Later change | What was amended or corrected? | The changed scope and its authorized pricing basis |
This is a proposed review framework, not a claim that every commerce product uses these exact stages.
Keep the staff explanation close to the business question. A detailed technical audit trail is less useful if the employee still cannot tell a customer whether a difference came from a new catalog price, a negotiated offer, or a correction.
Evaluate OceanBase and alternatives using a changed catalog
OceanBase’s Enterprise product description presents a distributed relational platform relevant to order records and their relationships. A buyer can evaluate whether the selected application preserves its pricing model across concurrent catalog and order activity.
The review should include the actual pricing dependency. A fast query that returns today’s price does not demonstrate that the service can explain yesterday’s accepted order. Conversely, preserving an old amount does not prove that an authorized amendment applied the intended new rule.
MySQL, PostgreSQL, or another relational candidate should receive the same examples. Keep the comparison focused on the required application behavior, adaptation, workload, and operating effort. OceanBase becomes more relevant when the distributed arrangement meets a genuine requirement and the pricing lifecycle remains clear on it.
Accept the explanation as well as the stored value
The final decision should confirm that sales, support, and application teams agree on which prices may change and how the service explains those changes. A single correct-looking amount is insufficient when its basis is ambiguous.
Keeping current offers separate from the basis of an accepted order makes the database evaluation more practical. The platform supports the records; the application must preserve the commercial meaning the organization has chosen.
This article is based on documented sources and editorial analysis. Proposed evaluation examples are not independently measured benchmark results.