---
id: AREA-COM
title: Commerce
product_area: commerce
revision: 1
status: draft
product_intent: proposed
source_sha:
  rhythm-v2-docs: 544f9999b78ad4b6f1abbbaf59c4320dc015df3c
  services-commerce: c8b66a98e2490617aec38ba5c8165dd9bd0a8f9b
  react-console: baf6dae382d6f41dce976c7f848667ccc37e076f
  macroservice-libraries: 54536a441935c6e09fdb7f96f0bec71c52ba4e03
modules:
  - MOD-COM-CAT
  - MOD-COM-ORD
  - MOD-COM-FUL
owns:
  - The offering and selling arrangements around products
  - The customer purchase and its retained commercial history
  - Purchased rights and application participation in selling
  - 'Delivery coordination, warehouse handling and physical stock'
  - Vendor purchasing and acquisition cost under the current registered boundary
does_not_own:
  - 'Accounting owns product definitions, financial documents and payment execution.'
  - 'CRM owns people, organizations, affiliations and addresses.'
  - Membership and other product-owning applications own their delivered results.
  - 'Platform owns identity, authorization, eligibility, integrations and shared job infrastructure.'
  - Billing is the proposed future owner of installment orchestration.
handoffs:
  - to: Accounting
    what: 'Product and financial facts, financial execution requests and their results'
  - to: CRM
    what: 'Purchasing parties, organization authority and address references'
  - to: Platform
    what: 'Verified access, qualification, carrier execution and shared infrastructure'
  - to: Membership and other selling applications
    what: 'Purchase context, delivery instructions and application-owned outcomes'
  - to: Billing
    what: Proposed transfer of installment orchestration and collection
invariants:
  - Commercial coordination retains a distinct owner from financial execution.
  - Each module uses the purchasing parties and qualification supplied by their owning areas.
  - Workspace context and operation authority apply across the area.
  - Local transaction guarantees do not imply one transaction across external applications.
provenance: documented
source: 'rhythm-v2-docs:specs/commerce/RESPONSIBILITIES.md'
open_questions:
  - OQ-COM-CAT-001
  - OQ-COM-CAT-002
  - OQ-COM-FUL-002
  - OQ-COM-FUL-003
  - OQ-COM-FUL-006
evidence:
  - 'rhythm-v2-docs:specs/PRODUCT-AREAS.md#Commerce'
  - 'rhythm-v2-docs:specs/commerce/ACTORS.md'
  - 'rhythm-v2-docs:specs/commerce/RESPONSIBILITIES.md'
  - 'rhythm-v2-docs:specs/commerce/catalog/MODULE.md'
  - 'rhythm-v2-docs:specs/commerce/orders/MODULE.md'
  - 'rhythm-v2-docs:specs/commerce/fulfillment/MODULE.md'
---

# Commerce

## Purpose and Outcomes

Commerce connects a customer's offering to the purchase and the work that follows it. It gives selling staff, administrators and warehouse teams a shared commercial record while preserving the responsibilities of the applications that define products, move money and deliver services. A purchase therefore has a commercial home even when several applications contribute to its outcome.

The area brings together preparation of the offering, the customer's sale, purchased rights, delivery coordination and physical stock. Administrators work with selling arrangements; clerks work with purchases; reviewers and operations staff explain what remains outstanding; warehouse staff work with goods. Buyers and participating applications enter through their own access boundaries. These working groups help readers find the relevant module without implying that everyone receives the same authority.

The product should make a purchase understandable from preparation through later changes and delivery, with accountable exceptions when work cannot finish. The specifications separate the local guarantees from dependencies on financial execution, qualification, carrier services and application delivery. They also preserve unresolved ownership choices so a reader can distinguish today's registered boundary from a proposed future arrangement. This overview is the starting map; each module contains the contracts and evidence for its own responsibilities.

## Scope and Boundaries

Commerce owns the commercial coordination of selling, purchasing and delivery. Its scope includes offering presentation and selling arrangements, customer purchases and purchased rights, delivery coordination, physical stock, and the currently registered vendor-purchasing and acquisition-cost responsibilities.

Accounting owns the underlying products and financial execution. CRM owns purchasing identities and their relationships. Membership and other participating applications own the results they deliver. Commerce exchanges references, requests and outcomes with these owners rather than taking over their records. Platform supplies access evaluation, qualification, integrations and shared infrastructure. Installment orchestration has a proposed handoff to Billing that remains an ownership question.

## How the Area Is Divided

Catalog and Selling Configuration explains the offering around Accounting products and the arrangements under which it is sold. Open it when the question concerns what appears for sale, how the offering is configured or how selling assessments obtain their context.

Orders explains the commercial purchase, its purchased rights and its relationships with selling applications and Accounting. Open it when the question concerns the retained sale or a later commercial change. The current registry also places vendor purchasing and acquisition cost here; that placement remains under review.

Fulfillment, Shipping and Inventory explains delivery coordination and the physical handling and accounting of stock quantities. Open it when the question concerns outstanding delivery work, warehouse activity or operational attention. It currently hosts collection imports whose final specification ownership is still open.

## Area-Level Invariants

Financial execution and application-owned delivery retain their separate owners. The area's modules obtain purchasing identities and qualification from the areas responsible for those facts. Workspace context and operation authority apply throughout Commerce. A local guarantee covers its declared transaction boundary; the product should not present a sequence of external calls as one atomic purchase-to-delivery process.

## Open Ownership Questions

Product still needs to settle the home of purchasing and acquisition cost, the division of collection imports, and the owner and permitted writers of shared intervention history. The ownership of dated pricing periods and interim tax configuration also remains unresolved. Installment realignment and the transition from local audit handling to shared infrastructure need a consistent boundary before those responsibilities move. The owning modules retain the questions and their evidence.
