Operations catalog
The catalog at /operations/catalog is a global reference for staff with Operations access. It has Offerings and Specifications: a specification describes a product or service, while an offering is its commercial package.
In some locales, catalog labels for stages, filters, statuses, counts, Show more, loading, and errors may remain in English until native messages are deployed. Do not treat such a frame as localized screenshot evidence; the catalog rules and state meanings do not change.
List and filters
Switch between Offerings and Specifications, then choose a state: active, draft, or archived. The tab number is only an orientation aid; the full list may load in parts. If the list does not open, use Retry and wait for it to finish.
Archived means withdrawn from sale, not that history was deleted. Treat a count as exact only when the portal marks the total complete; with a lower bound, use Show more, which appends the next rows. An empty stage result, loading, and an error with Retry are different states.
Check the clear name, code, offering role or specification kind, and current version in each row. The price must match the agreed terms; do not reconstruct it from a code or name. If a name, price, or profile is missing, preserve the empty state and ask the catalog owner.
Details and versions
Open an offering or specification from the list. The page shows the code and role/kind, current version, description, unit, and related terms. The version history is below; a published version is immutable.
For a new or draft root, the working version may be the latest draft even when no published version exists. Do not call a draft published or use it as a ready offering in an order.
Create
Select Create for a specification. Enter its name, kind, base quantity and unit, fulfillment profile, description, and code. Choose the profile and unit from the current lists; if a list is empty or unavailable, postpone saving. Retry the read once if the unavailability appears transient. If the profile directory remains unavailable or the error returns, do not choose a substitute, change permissions, or try to save: specification creation is unavailable. Give the portal owner the route, time, and readable interface message—without a technical code—and wait for recovery.
Select Create for an offering. Choose a published specification, then enter the customer-facing name, price, currency, pricing basis (per unit or flat), and code. Verify price and currency against the agreement and do not mix currencies.
The current form source still limits the currency picker to RUB/USD/EUR/KZT and resets the draft to RUB; portal locale alone therefore does not guarantee CNY (ZH), KGS (KY), or AED (AR). Until the source is fixed, do not claim that the local currency is available: planned screenshot/evidence must record currency.expected and currency.observed, and money-bearing frames remain blocked.
Validation, publishing, and editing
A draft is sent for validation with a required reference or business basis. Only a validated version can be published. Publishing may require a second person; when separation of duties is enabled, the person who validated the version cannot publish it themselves.
Use Edit on a draft specification to create its next version while keeping the record's code and kind. A published version cannot be edited. For offerings, create a new commercial record or follow the current process; do not promise an in-place price change in the card.
If an action is unavailable, check your role and the separation-of-duties rule. If the card is stale, reload it and decide only after checking the current state. If a transition no longer applies, return to the record's current state.
For a root in draft, active, or suspended, the card may offer Withdraw. This is not deletion of history: provide a multiline reason, the current revision, and confirmation; the record disappears from selection lists while already-sold history remains. If the revision is stale or the action is forbidden, reload the card and check access instead of retrying blindly.
Versions, approval, and fulfillment profile
The card shows the published version and the current draft separately. If nothing is published yet, continue with the draft and check its state in the history; do not call it published.
The approval rule is set in portal settings. With separation of duties, the person who sent a version for review does not publish it themselves; wait for a colleague to act. Enter the review and publication basis in the required dialog; canceling or submitting a blank value does nothing. If the card changed, reload it before deciding.
Choose a fulfillment profile from the available list and only one that fits the selected kind. An empty, unavailable, or incomplete list is a distinct state, not a reason to guess. An offering can be created only from a published specification; if its pricing terms are not shown, confirm them with the responsible owner first. The displayed amount must match the agreed terms.
Access, data, and demos
The catalog is shared across the organisation, but actions depend on your role, approval rule, and directory availability. Empty, unavailable, invalid-data, and temporary-error states are different; show them honestly and use Retry when available.
Use synthetic names, profiles, clients, and prices in training material. Never publish real price lists, agreements, customer data, internal identifiers, or tokens. For Arabic UI, separately verify RTL direction, labels, and currency formatting before publishing an image.
Related pages
Delivery rules
/operations/catalog has a separate Delivery rules tab. It explains how an item is fulfilled, accepted, and billed; it is not another Offerings or Specifications filter. Distinguish In progress, In force, and Archive stages, exact versions, and empty/loading/error states. Use human-readable names such as Retail without acceptance and Stocked goods; never expose raw profile keys.
New rule
At /operations/catalog/fulfillment-profiles/new, answer seven business questions: what is sold (service, goods, digital good, or kit), where it comes from, whether the customer accepts it, whether there is a periodic allowance, what happens above the allowance, whether unused value carries over, and when to invoice. The portal derives the handler, stock policy, allowance, acceptance, and billing basis; keep What the portal sets up itself collapsed. Use Retail without acceptance for a synthetic demo, not a machine key.
Editing a draft and checking what was saved
A draft uses the same questionnaire for edits. If the server drops an answer, the page must show the values actually stored and name the discarded settings; do not call the action fully successful. A published version cannot be rewritten: an edit creates the next version of the same rule.
Checking, putting in force, and versions
At /operations/catalog/fulfillment-profiles/<profileKey>/<schemaVersion>, open the exact key/version pair, not “the latest”. Distinguish Draft → Checked → In force → Replaced/Withdrawn. Putting a rule in force may require a second person; after publication its name and terms are frozen, and a new version affects future sales only. Use Stocked goods with versions 1–3 and Waiting to be put in force as synthetic version data.
Boundaries and refusal states
The server may reject incompatible acceptance, allowance, and billing answers; separate overage sales are not enabled yet and must remain visible as a disabled option. Distinguish permission, stale-revision, unsupported-setting, and temporary-unavailable errors, and reread before retrying. Do not confirm, publish, or withdraw a rule in a screenshot scene: this is planned-only, read-only proof with no real actors, customers, money, or raw IDs.
Mobile review
At a narrow 390px viewport, review the same list and editor: all seven questions, the summary, and actions must remain readable without horizontal overflow. Arabic stays private pending RTL review; every locale requires a matching build and same-locale evidence.