Skip to main content
An order group never stores its own total. The seller_count and total fields are computed from the child orders each time you read the group, and the read workflows derive each child order’s payment and fulfillment status the same way. This keeps the group in step with its orders after edits, returns, and refunds, with no denormalized column to keep in sync.

​
Computed fields hold no value

Both fields are declared with .computed() on the model, so the order_group table has no column for them:
You can’t write them through createOrderGroups or updateOrderGroups. They only exist on the records the Seller module reads back.

​
How the Seller module fills them

The Seller module reads groups through a custom OrderGroupRepository. Its query joins each group to its child orders and sums them:
  • seller_count: the number of distinct sellers linked to the group’s orders through order_order_seller_seller
  • total: the sum of current_order_total from each order’s summary at its current version, or 0 for a group with no orders
Every list, count, and retrieve call on order groups runs through this repository, including query.graph on the order_group entity. Deleted orders and deleted links are left out.
For a group with a 47.00 order from ACME and a 40.00 order from GLOBEX, group.seller_count is 2 and group.total is 87. The repository converts total to a JavaScript number, which matches the OrderGroupDTO type.

​
Filters pick groups, not orders

Order-level filters such as seller_id, status, payment_status, and sales_channel_id decide which groups match. They don’t trim the sums. A group that matches seller_id: "sel_01JD8Q1234567" still reports the seller_count and total of every order in it.
To show one seller’s share of a group, read the group’s orders and sum the ones that belong to that seller. The list workflow’s sellerId input trims orders for you.

​
Child order statuses

getOrderGroupDetailWorkflow and getOrderGroupsListWorkflow set payment_status and fulfillment_status on every child order they return. Medusa’s Order model doesn’t store these, so the workflows compute them from the order’s data: The group has no status of its own. Read the child statuses to show where each seller’s part of the purchase stands.