@mercurjs/docs 2.3.8-canary.3 → 2.3.8-canary.4

package/content/platform/offer/guides/create-an-offer.mdx

@@ -1,83 +1,135 @@
 ---
-title: "Create an offer"
+title: "Create an offer from your server code"
 sidebarTitle: "Create an offer"
-description: "Create a single offer programmatically with createOffersWorkflow."
+description: "Run createOffersWorkflow to list a master variant for a store with a SKU, price, stock, and shipping profile."
 ---
 
-In this guide, you'll learn how to create an offer from your own server code,
-for example in a custom API route, a seed script, or an import flow.
+Create an offer with `createOffersWorkflow` when you list products for a store outside the Vendor panel, for example in a custom route, a seed script, or an import job.
 
-Mercur exposes a `createOffersWorkflow` that creates the `Offer` record, its
-inventory items, and its price rows, and wires up every link in one run. Run it
-from any place that has access to the Medusa container.
+## Before you begin
 
-## Run the workflow
+You need these records in place:
 
-```ts title="src/api/custom/route.ts"
-import type { MedusaRequest, MedusaResponse } from "@medusajs/framework/http"
-import { createOffersWorkflow } from "@mercurjs/core/workflows"
+- **A store**: its `seller_id` and the id of a member to record as `created_by`
+- **A master variant**: the `variant_id` the store will sell
+- **A shipping profile**: one that belongs to the store
+- **A stock location**: where the starting stock is held
+
+## Create the offer
+
+<Steps>
+  <Step title="Add a route that runs the workflow">
+    Create an API route that runs `createOffersWorkflow` with one offer.
 
-export async function POST(req: MedusaRequest, res: MedusaResponse) {
-  const { result } = await createOffersWorkflow(req.scope).run({
-    input: {
-      offers: [
-        {
-          seller_id: "sel_123",
-          created_by: "mem_123",
-          variant_id: "variant_123",
-          shipping_profile_id: "sp_123",
-          sku: "ACME-WIDGET-01",
-          prices: [{ amount: 2500, currency_code: "usd" }],
-          inventory_items: [
+    ```ts title="src/api/admin/custom/offers/route.ts"
+    import type { MedusaRequest, MedusaResponse } from "@medusajs/framework/http"
+    import { createOffersWorkflow } from "@mercurjs/core/workflows"
+
+    const stock = [{ location_id: "sloc_01JD8Q1234567", stocked_quantity: 50 }]
+
+    export async function POST(req: MedusaRequest, res: MedusaResponse) {
+      const { result } = await createOffersWorkflow(req.scope).run({
+        input: {
+          offers: [
             {
-              stock_levels: [{ location_id: "sloc_1", stocked_quantity: 50 }],
+              seller_id: "sel_01JD8Q1234567",
+              created_by: "mem_01JD8Q1234567",
+              variant_id: "variant_01JD8Q1234567",
+              shipping_profile_id: "sp_01JD8Q1234567",
+              sku: "ACME-LS-M",
+              prices: [{ amount: 4700, currency_code: "eur" }],
+              inventory_items: [{ stock_levels: stock }],
             },
           ],
         },
+      })
+
+      res.status(201).json({ offer: result[0] })
+    }
+    ```
+
+    The workflow returns the created `Offer` rows. The one `inventory_items` entry becomes a new inventory item with 50 units at the location.
+  </Step>
+  <Step title="Know what the run wires up">
+    One run does more than insert the row:
+
+    - **Inventory**: creates an `InventoryItem` per entry, links it to the offer with its `required_quantity`, and links it to the store
+    - **Prices**: adds each price to the variant’s price set with an `offer_id` rule and links it to the offer
+    - **Barcodes**: copies `ean` and `upc` from the variant when you leave them out
+    - **Shipping**: links the master product to the shipping profile if the product has none
+    - **Event**: emits `offer.created` with `{ id, product_id }`
+  </Step>
+  <Step title="Read the offer back with its links">
+    Query the offer with its prices and stock to confirm the result.
+
+    ```ts
+    const { data: [offer] } = await query.graph({
+      entity: "offer",
+      fields: [
+        "id",
+        "sku",
+        "prices.amount",
+        "prices.currency_code",
+        "inventory_item_link.required_quantity",
+        "inventory_item_link.inventory_item.location_levels.*",
       ],
-    },
-  })
+      filters: { id: result[0].id },
+    })
+    ```
+
+    `prices` reads the offer’s own rows on the shared price set. `inventory_item_link` returns the pivot rows, so you get `required_quantity` with each item.
+  </Step>
+</Steps>
+
+## Set selling terms and a condition
 
-  res.status(201).json({ offer: result[0] })
+The offer accepts optional fields beyond the required ones. Add them to the same entry:
+
+```ts
+{
+  sku: "ACME-LS-M-RF",
+  condition_id: "ofcond_01JD8Q1234567",
+  manage_inventory: true,
+  allow_backorder: false,
+  leadtime_to_ship: 3,
+  metadata: { source: "erp" },
 }
 ```
 
-<Note>
-  Each offer must reference an existing master `variant_id` and include at least
-  one `inventory_items` entry. The SKU must be unique within the store.
-  Reusing an existing `(seller_id, sku)` pair is rejected.
-</Note>
+`condition_id` must point at an active offer condition. `manage_inventory` defaults to `true`, `allow_backorder` to `false`, and `leadtime_to_ship` to `null`.
 
-## What the workflow wires up
+## Attach custom data with additional_data
 
-A single run does more than insert a row:
+Pass `additional_data` to the run to hand extra values to the `offersCreated` hook. Use it to store data from your own module next to the offer.
 
-- Creates a new `InventoryItem` per `inventory_items` entry (with any `stock_levels`) and links each to the offer. Remember, inventory links to the **offer**, not the variant.
-- Writes each price onto the master variant's shared price set, stamped with an `offer_id` rule, and links the price rows to the offer.
-- Links the offer to its store, product, variant, and shipping profile.
-- Emits `offer.created`.
+```ts title="src/workflows/hooks/offers-created.ts"
+import { createOffersWorkflow } from "@mercurjs/core/workflows"
 
-## Attach custom data
+createOffersWorkflow.hooks.offersCreated(
+  async ({ offers, additional_data }, { container }) => {
+    const logger = container.resolve("logger")
+    for (const offer of offers) {
+      logger.info(`${offer.sku}: ${additional_data?.source ?? "api"}`)
+    }
+  }
+)
+```
 
-The workflow accepts an `additional_data` payload that is passed to its
-`offersCreated` hook, letting you persist marketplace-specific data alongside the
-offer without forking the workflow.
+The hook receives the created offers with their `prices` loaded. Run the workflow with `additional_data: { source: "erp" }` to see the value in the handler.
 
-```ts
-await createOffersWorkflow(req.scope).run({
-  input: {
-    offers: [
-      {
-        seller_id: "sel_123",
-        created_by: "mem_123",
-        variant_id: "variant_123",
-        shipping_profile_id: "sp_123",
-        sku: "ACME-WIDGET-01",
-        prices: [{ amount: 2500, currency_code: "usd" }],
-        inventory_items: [{ stock_levels: [{ location_id: "sloc_1", stocked_quantity: 50 }] }],
-      },
-    ],
-    additional_data: { source: "csv-import" },
-  },
-})
-```
+## Handle a failed run
+
+The workflow validates the whole input and rolls back on failure. Compensation removes the inventory items, prices, and links it already created.
+
+A run fails when:
+
+- **A variant doesn’t exist**: `Variant with id … was not found`
+- **An offer has no inventory items**: `Offer must have at least one inventory item`
+- **A condition is unknown or inactive**: `Offer condition … is not active` or not found
+- **A SKU is taken in the store**: the `(seller_id, sku)` unique index rejects the insert
+
+## Next steps
+
+- [Bulk-create offers](/platform/offer/guides/bulk-create-offers)
+- [Manage offer inventory](/platform/offer/guides/manage-offer-inventory)
+- [createOffersWorkflow reference](/platform/offer/reference/workflows)

package/content/platform/offer/guides/manage-offer-inventory.mdx

@@ -1,53 +1,93 @@
 ---
-title: "Manage offer inventory"
+title: "Change the inventory items behind an offer"
 sidebarTitle: "Manage offer inventory"
-description: "Attach, update, and detach inventory items on an existing offer."
+description: "Use batchOfferInventoryItemsWorkflow to link, relink, and unlink existing inventory items on an offer."
 ---
 
-In this guide, you'll learn how to change the inventory items linked to an
-existing offer from your own server code.
+Run `batchOfferInventoryItemsWorkflow` when an existing offer needs different stock behind it, for example to turn it into a kit or to swap a component. The workflow changes the `offer ↔ inventory_item` links and their `required_quantity` in one run.
 
-Because inventory links to the **offer** (not the variant), the set of inventory
-items backing an offer is managed through the `offer ↔ inventory_item` link.
-`batchOfferInventoryItemsWorkflow` applies creates, updates, and deletes to that
-link in a single run.
+## Before you begin
 
-## Run the batch workflow
+You need these records in place:
 
-```ts title="src/api/custom/offer-inventory/route.ts"
-import type { MedusaRequest, MedusaResponse } from "@medusajs/framework/http"
-import { batchOfferInventoryItemsWorkflow } from "@mercurjs/core/workflows"
+- **An offer**: the `offer_id` whose stock you change
+- **Existing inventory items**: the workflow links items that already exist and doesn’t create new ones
 
-export async function POST(req: MedusaRequest, res: MedusaResponse) {
-  const { result } = await batchOfferInventoryItemsWorkflow(req.scope).run({
-    input: {
-      offer_id: "offer_123",
-      create: [{ inventory_item_id: "iitem_new", required_quantity: 2 }],
-      update: [{ inventory_item_id: "iitem_existing", required_quantity: 5 }],
-      delete: ["iitem_stale"],
-    },
-  })
-
-  res.json(result)
-}
-```
+## Change the links
+
+<Steps>
+  <Step title="Add a route that runs the batch">
+    Pass the offer and the three optional lists: `create`, `update`, and `delete`.
+
+    ```ts title="src/api/admin/custom/offers/[id]/inventory/route.ts"
+    import type { MedusaRequest, MedusaResponse } from "@medusajs/framework/http"
+    import { batchOfferInventoryItemsWorkflow } from "@mercurjs/core/workflows"
+
+    export async function POST(req: MedusaRequest, res: MedusaResponse) {
+      const { result } = await batchOfferInventoryItemsWorkflow(req.scope).run({
+        input: {
+          offer_id: req.params.id,
+          create: [
+            { inventory_item_id: "iitem_01JD8Q1234567", required_quantity: 2 },
+          ],
+          update: [
+            { inventory_item_id: "iitem_01JD8Q1234568", required_quantity: 1 },
+          ],
+          delete: ["iitem_01JD8Q1234569"],
+        },
+      })
+
+      res.json(result)
+    }
+    ```
+
+    `create` links a new item, `update` changes the `required_quantity` of a linked item, and `delete` unlinks an item. The inventory item itself stays in place after an unlink.
+  </Step>
+  <Step title="Read the result">
+    The workflow returns what changed:
+
+    - **`created`**: the link definitions it added
+    - **`updated`**: the link definitions it rewrote
+    - **`deleted`**: the inventory item ids it unlinked
+
+    It also emits `offer.updated` with `{ id }` for the offer.
+  </Step>
+</Steps>
 
-The result reports the links that were `created`, `updated`, and `deleted`.
+## Rules the batch enforces
 
-## Rules the workflow enforces
+The workflow checks the whole payload before it writes anything. Any broken rule fails the run:
 
-- Items in `create` must **not** already be linked to the offer; items in `update` and `delete` **must** already be linked.
-- An `inventory_item_id` can't appear in more than one section, and can't be duplicated within a section.
-- `create` items must reference existing `InventoryItem` records; `required_quantity` defaults to `1`.
-- Deleting an item that isn't linked to the offer surfaces a 404 rather than silently no-op'ing.
+- **Unknown offer**: `Offer with id: … was not found`
+- **Unknown item in `create`**: the inventory item must exist
+- **Item not linked, in `delete`**: fails with not found instead of a silent no-op
+- **Same id twice**: an id can appear once per list and in only one of the three lists
+
+`required_quantity` defaults to `1` in `create` and is required in `update`.
 
 <Note>
-  This workflow manages the **links** between an offer and existing inventory
-  items and their `required_quantity`. To create brand-new inventory items with
-  starting stock as part of listing an offer, pass `inventory_items` to
-  [`createOffersWorkflow`](/platform/offer/guides/create-an-offer) instead.
+  The workflow doesn’t check that an item in `create` is already linked or that an item in `update` is linked, and it doesn’t check which store owns an item. Read the offer’s `inventory_item_link` and the item’s store first when your input comes from a seller.
 </Note>
 
-The workflow emits `offer.updated` and exposes an `offerInventoryItemsBatched`
-hook carrying the `offer_id`, the batch result, and any `additional_data` you
-passed in.
+## Run code after the batch
+
+The workflow exposes an `offerInventoryItemsBatched` hook. It receives the `offer_id`, the `result`, and any `additional_data` you passed.
+
+```ts title="src/workflows/hooks/offer-inventory-batched.ts"
+import { batchOfferInventoryItemsWorkflow } from "@mercurjs/core/workflows"
+
+batchOfferInventoryItemsWorkflow.hooks.offerInventoryItemsBatched(
+  async ({ offer_id, result }, { container }) => {
+    const logger = container.resolve("logger")
+    logger.info(`${offer_id}: ${result.deleted.length} items unlinked`)
+  }
+)
+```
+
+A `validate` hook runs first with the raw `input`, so you can reject a batch with your own rules before any link changes.
+
+## Next steps
+
+- [How offer stock works](/platform/offer/concepts/pricing-and-inventory)
+- [The offer to inventory item link](/platform/offer/reference/links)
+- [batchOfferInventoryItemsWorkflow reference](/platform/offer/reference/workflows)

package/content/platform/offer/overview.mdx

@@ -1,60 +1,67 @@
 ---
-title: "Offer"
+title: "Offers"
 sidebarTitle: "Overview"
-description: "How a store sells against the shared master catalog, with its own SKU, price, inventory, and shipping."
+description: "Let every store sell a shared catalog product with its own SKU, price, stock, condition, and shipping profile."
 ---
 
-Use offers to let each store sell against Mercur's shared master catalog on its
-own terms.
+Use offers to let several stores sell the same catalog product, each on its own terms.
 
-The offer is the central concept of the marketplace. Products live in a single
-**master catalog** that no store owns; an offer is the record that connects a
-store to a master product variant. It carries everything that makes that listing
-the store's own: its SKU, its price, its inventory, and its shipping profile.
-Cart and order line items link back to the exact offer that was purchased, so the
-whole order lifecycle knows which store fulfills and gets paid.
+Products in Mercur live in one shared master catalog that no store owns. An offer is the record that connects a store to one master variant. It carries everything that makes the listing the store’s own: its SKU, price, inventory, condition, and shipping profile. The Offer module holds the offer and its conditions, and links reach out to the store, the catalog, pricing, inventory, fulfillment, and the cart and order line items that buy it.
+
+<img className="block dark:hidden" src="/images/figures/offer-overview-light.svg" alt="The Linen shirt master product sits behind an Offers list for its M variant: ACME, GLOBEX, and INITECH each list the same variant with their own SKU, condition, price, and stock." />
+<img className="hidden dark:block" src="/images/figures/offer-overview-dark.svg" alt="The Linen shirt master product sits behind an Offers list for its M variant: ACME, GLOBEX, and INITECH each list the same variant with their own SKU, condition, price, and stock." />
 
 <Note>
-  **Products are shared; offers are owned.** A store never owns a product. It
-  publishes an offer against a master product variant. Two stores selling the
-  same product each have their own offer, with their own SKU, price, and stock.
+  The data model is `Offer` (id prefix `offer`), resolved with `MercurModules.OFFER` from `@mercurjs/types`. A store never owns a product. Two stores selling the same variant each hold their own offer.
 </Note>
 
 ## Key features
 
-- **Per-store listings:** one offer per store per variant, each with its own SKU (unique within a store).
-- **Offer-scoped pricing:** prices live on the master variant's shared price set, scoped by an `offer_id` rule so every store prices independently.
-- **Offer-scoped inventory:** inventory items link to the **offer**, not the variant, so stock never leaks between stores.
-- **Per-offer shipping:** each offer points at the store's own shipping profile.
-- **Order attribution:** cart and order line items link to the purchased offer, driving fulfillment, commission, and payouts.
-- **Bulk operations:** create and update many offers, and batch an offer's inventory links, in a single workflow run.
+The Offer module covers everything a store needs to sell a catalog variant:
+
+- **Per-store listings**: an offer points at one master variant, with a SKU that’s unique within its store
+- **Offer-scoped pricing**: price rows sit on the variant’s shared price set, each tagged with an `offer_id` price rule
+- **Offer-scoped inventory**: inventory items link to the offer, not the variant, so stock never mixes between stores
+- **Conditions**: operators define conditions such as `new` or `refurbished`, and stores list offers under the active ones
+- **Per-offer shipping**: each offer names the store’s own shipping profile
+- **Order attribution**: cart and order line items link to the offer that was bought
+- **Hooks and events**: every workflow exposes hooks and emits `offer.*` events for your own side effects
+
+## How it works
+
+An offer moves through the marketplace in four steps:
+
+1. A store runs `createOffersWorkflow` against a master variant, with a SKU, prices, inventory items, and a shipping profile.
+2. The workflow writes the prices onto the variant’s price set with an `offer_id` rule and creates inventory items linked to the offer.
+3. When a shopper adds the offer to a cart, the line item links to the offer and pricing resolves the offer’s own rows.
+4. At checkout the order line item keeps the offer link, so the right store fulfills the item and gets paid.
 
 ## Get started
 
-Learn how the domain fits together:
+Learn how offers, prices, stock, and shipping fit together.
 
 <CardGroup cols={2}>
   <Card title="What is an offer" icon="tag" href="/platform/offer/concepts/what-is-an-offer">
-    The offer record, how it points at a master variant, and its SKU.
+    The offer record, its SKU rules, and offer conditions.
   </Card>
   <Card title="Pricing & inventory" icon="coins" href="/platform/offer/concepts/pricing-and-inventory">
-    Offer-scoped prices on the shared price set and offer-linked inventory.
+    Prices on the shared price set and stock linked to the offer.
   </Card>
   <Card title="Shipping" icon="truck" href="/platform/offer/concepts/shipping">
-    How an offer carries its own shipping profile.
+    How an offer ships with its store’s shipping profile.
   </Card>
 </CardGroup>
 
 ## Examples
 
-Build against the Offer domain in your own code:
+Build against offers in your own server code.
 
 <CardGroup cols={2}>
   <Card title="Create an offer" icon="plus" href="/platform/offer/guides/create-an-offer">
-    Run `createOffersWorkflow` with a price and inventory.
+    Run `createOffersWorkflow` from an API route.
   </Card>
   <Card title="Bulk-create offers" icon="layer-group" href="/platform/offer/guides/bulk-create-offers">
-    List many offers against the catalog in one run.
+    List a store’s catalog in a single run.
   </Card>
   <Card title="Manage offer inventory" icon="boxes-stacked" href="/platform/offer/guides/manage-offer-inventory">
     Attach, update, and detach inventory items on an offer.
@@ -63,22 +70,22 @@ Build against the Offer domain in your own code:
 
 ## Resources
 
-Data models, workflows, service methods, and events for the Offer domain:
+The data models, links, workflows, service methods, and events behind offers.
 
 <CardGroup cols={2}>
   <Card title="Data models" icon="table" href="/platform/offer/reference/data-models">
-    The `Offer` entity and its fields.
+    `Offer` and `OfferCondition`, field by field.
   </Card>
   <Card title="Links" icon="link" href="/platform/offer/reference/links">
-    How the Offer domain links to other modules.
+    How offers link to stores, catalog, pricing, inventory, and orders.
   </Card>
   <Card title="Workflows" icon="diagram-project" href="/platform/offer/reference/workflows">
-    Create, update, delete, and inventory-batch workflows.
+    Offer, price, inventory, and condition workflows with their hooks.
   </Card>
   <Card title="Service" icon="gear" href="/platform/offer/reference/service">
-    Module service methods for working with records directly.
+    Module service methods for reading and writing records directly.
   </Card>
   <Card title="Events" icon="bell" href="/platform/offer/reference/events">
-    Events emitted as offers change.
+    Events emitted as offers and conditions change.
   </Card>
 </CardGroup>

package/content/platform/offer/reference/data-models.mdx

@@ -1,56 +1,86 @@
 ---
-title: "Data models"
+title: "Offer data models"
 sidebarTitle: "Data models"
-description: "The data models owned by the Offer domain."
+description: "Every field of the Offer and OfferCondition data models in the Offer module."
 ---
 
-The Offer domain is owned by the **Offer module**. This reference lists its data
-model and fields. For the full module overview, see the
-[Offer overview](/platform/offer/overview).
+The Offer module owns two data models: `Offer` and `OfferCondition`. Prices, inventory, the store, and catalog records aren’t columns on these models. They attach through [module links](/platform/offer/reference/links).
 
 ## Offer
 
-Table `offer`, id prefix `offer`. A store's listing against a master product
-variant. Price and inventory are attached through links rather than stored on the
-row.
+A store’s listing of one master product variant. Table `offer`, id prefix `offer`.
 
-| Field | Type | Notes |
+| Field | Type | Description |
 | --- | --- | --- |
-| `id` | text | Primary key |
-| `seller_id` | text | The store that owns the offer (read-only link) |
-| `variant_id` | text | The master `ProductVariant` the offer points at |
-| `product_id` | text | The master `Product` the variant belongs to |
-| `shipping_profile_id` | text | The store's shipping profile for this offer |
-| `sku` | text | Searchable; unique within a store (see below) |
-| `ean` | text | Nullable, searchable; snapshotted off the variant when omitted |
-| `upc` | text | Nullable, searchable; snapshotted off the variant when omitted |
-| `created_by` | text | The member that created the offer |
-| `variant_count` | number | Computed; only set when grouping by store |
-| `metadata` | json | Nullable |
-
-Uniqueness: `(seller_id, sku)` is unique while `deleted_at IS NULL`, so a store
-can't reuse a SKU across its live offers, but different stores may share SKU
-strings. Indexes also cover `variant_id`, `product_id`, `seller_id`,
-`shipping_profile_id`, `ean`, and `upc`.
-
-## Linked data
-
-The offer's price ladder, inventory, and related records aren't columns on the
-`offer` table. They're joined through links and only present when requested:
-
-| Relation | Source |
-| --- | --- |
-| `prices` | Offer-owned rows on the master variant's shared price set (`offer ↔ price` list-link) |
-| `inventory_items` | `offer ↔ inventory_item` list-link; each row carries `required_quantity` |
-| `seller` | Read-only `offer ↔ seller` link |
-| `product` / `product_variant` | Read-only `offer ↔ product` / `offer ↔ variant` links |
-| `shipping_profile` | Read-only `offer ↔ shipping_profile` link |
-
-<Note>
-  `variant_count` (and the companion `offer_ids` list) are computed only when
-  offers are listed grouped by store (`group_by_seller`). On ungrouped reads they
-  are absent.
-</Note>
-
-See the [Links reference](/platform/offer/reference/links) for the full set of
-module links.
+| `id` | `text` | Primary key, prefixed `offer_` |
+| `seller_id` | `text` | The store that owns the offer |
+| `variant_id` | `text` | The master `ProductVariant` the offer sells |
+| `product_id` | `text` | The master `Product`, read from the variant on create |
+| `shipping_profile_id` | `text` | The store’s shipping profile for this offer |
+| `sku` | `text` | Searchable. Unique per store among live offers |
+| `ean` | `text \| null` | Searchable. Copied from the variant when omitted on create |
+| `upc` | `text \| null` | Searchable. Copied from the variant when omitted on create |
+| `manage_inventory` | `boolean` | Default `true`. Whether stock is checked for the offer |
+| `allow_backorder` | `boolean` | Default `false`. Whether the offer sells past its stock |
+| `leadtime_to_ship` | `number \| null` | Lead time before the offer ships |
+| `created_by` | `text` | The member who created the offer |
+| `condition_id` | `text \| null` | Foreign key to `OfferCondition` |
+| `variant_count` | `number` | Computed, not stored. Set only by `group_by_seller` reads |
+| `metadata` | `json \| null` | Custom key-value data |
+| `created_at` | `timestamp` | Set on create |
+| `updated_at` | `timestamp` | Set on every write |
+| `deleted_at` | `timestamp \| null` | Set when the offer is soft-deleted |
+
+`OfferDTO` also has `offer_ids`, the list of offer ids in a `group_by_seller` group. It isn’t a model field.
+
+### Offer relations
+
+The offer has one relation inside the module:
+
+- **`condition`**: belongs to one `OfferCondition`, nullable
+
+### Offer indexes
+
+Every index applies only to rows where `deleted_at IS NULL`:
+
+| Index | Columns | Notes |
+| --- | --- | --- |
+| `IDX_offer_seller_sku_unique` | `seller_id`, `sku` | Unique |
+| `IDX_offer_variant_id` | `variant_id` | |
+| `IDX_offer_product_id` | `product_id` | |
+| `IDX_offer_seller_id` | `seller_id` | |
+| `IDX_offer_shipping_profile_id` | `shipping_profile_id` | |
+| `IDX_offer_ean` | `ean` | Only where `ean IS NOT NULL` |
+| `IDX_offer_upc` | `upc` | Only where `upc IS NOT NULL` |
+| `IDX_offer_condition_id` | `condition_id` | Only where `condition_id IS NOT NULL` |
+| `IDX_offer_seller_id_created_at` | `seller_id`, `created_at` | |
+| `IDX_offer_product_id_seller_id_created_at` | `product_id`, `seller_id`, `created_at` | |
+
+## OfferCondition
+
+A physical condition an offer can be listed under, such as `new` or `refurbished`. Operators manage the list. Id prefix `ofcond`.
+
+| Field | Type | Description |
+| --- | --- | --- |
+| `id` | `text` | Primary key, prefixed `ofcond_` |
+| `code` | `text` | Searchable. Unique among live conditions |
+| `label` | `text` | Searchable. Display name |
+| `is_active` | `boolean` | Default `true`. Inactive conditions can’t be assigned |
+| `rank` | `number` | Default `0`. Sort order of the list |
+| `metadata` | `json \| null` | Custom key-value data |
+| `created_at` | `timestamp` | Set on create |
+| `updated_at` | `timestamp` | Set on every write |
+| `deleted_at` | `timestamp \| null` | Set when the condition is soft-deleted |
+
+### OfferCondition relations
+
+The condition has one relation inside the module:
+
+- **`offers`**: has many `Offer` records, mapped by `condition`
+
+The index `IDX_offer_condition_code_unique` keeps `code` unique while `deleted_at IS NULL`.
+
+## Related
+
+- [Links to other modules](/platform/offer/reference/links)
+- [What is an offer](/platform/offer/concepts/what-is-an-offer)