Skip to main content

​
SCM workspace (apps/scm)

apps/scm is the Next.js workspace where tenant organizations run Commerce Chain Optimization (CCO): inventory, planning, procurement, fulfillment, demand intelligence, orders, returns, gateway/registry operator flows, and billing. It is the primary hosted surface for the @betterdata/scm-* and @betterdata/dcm-* module families described in SCM packages and DCM packages.
Despite the repo folder name scm, the same application hosts both SCM (supply-side operations) and DCM (demand-side, channel, and customer-order flows). The split is a domain boundary and module ID prefix (scm.* vs dcm.*), not two separate web apps.

​
SCM vs DCM — what lives where

SCM (Supply Chain Management)DCM (Demand Chain Management)
FocusSupply and execution — what you hold, move, make, buy, and receiveDemand and promise — what customers and channels ask for, how orders and returns flow
Typical questionsWhere is stock? What should we reorder? Did we receive it? Ship it?What is demand telling us? Which orders need allocation or intervention? How do returns close?
Module ID prefixscm.* (e.g. scm.inventory, scm.procurement, scm.execution)dcm.* (e.g. dcm.demand, dcm.orders, dcm.returns)
OSS packages@betterdata/scm-inventory, scm-procurement, scm-execution, scm-catalog, …@betterdata/dcm-demand, dcm-orders, dcm-returns, dcm-channels, …
Example governed loopsscm.procurement, scm.fulfillment, scm.replenishment, scm.qualitydcm.demand, dcm.order, dcm.returns
In one sentence: SCM tightens physical and purchase-to-deliver operations; DCM tightens signal-to-cash loops on the demand side (forecast → order → return). Both participate in the same loop model and the same CCO navigation model (Sense → Decide → Execute → Improve → Govern) in apps/scm.

​
How this appears in the product UI

  • Service module cards on /welcome (e.g. Inventory & Operations, Commerce Gateway) group capabilities for onboarding; tier-2 rows like Procurement and Fulfillment are SCM operating domains under that card — not separate top-level “SCM vs DCM” tabs.
  • DCM surfaces are woven through the same workspace: for example forecasting, demand signals, orders, and returns routes align with DCM packages and dcm.* loop families.
  • Internal probes enumerate routed modules such as scm.inventory, scm.catalog, scm.procurement, scm.execution, dcm.demand, dcm.orders, and dcm.returns — reflecting one app routing both families.

​
Usage-based pricing (hosted)

Better Data’s hosted commercial model is usage-based around loop outcomes, not seat count. The canonical overview lives under How pricing works:
  • Loop completion — billable completions are counted when a loop instance reaches an eligible terminal state (e.g. procurement or return closed, order completed or cancelled per policy).
  • Committed volume — plans include a monthly committed loop completion allowance; overage is billed per your contract when you exceed that commitment.
  • Where to see usage — in apps/scm, open Settings → Billing to view commitment, current-period completion counts, utilization, and threshold / overage indicators.
Enterprise customers negotiate custom commitments, annual terms, and volume tiers; contact hello@betterdata.co for packaging aligned to your modules and regions.
Hosted Loop Engine describes outcome-based positioning for the loop runtime; apps/scm billing surfaces the same completion-based lens in product settings. For list-price style tiers on the public site, see your commercial docs and How pricing works.

​
Monorepo location

ItemPath
SCM workspace appapps/scm/ (bd-forge-main)
CCO-style navigation configapps/scm/app/(authenticated)/components/sidebar/navigation-cco.ts
Welcome module grid (Inventory & Operations groups)apps/scm/lib/welcome-modules-config.ts, apps/scm/lib/welcome-core-modules-config.ts