M3 Reference
CRS610
InteractiveCustomer maintenance — where customers are created and their OCUSMA terms managed
Tables vs APIs
This program works over the tables below. For analytics at scale, land the raw tables — the SQL further down reads them directly, joined on their keys and CONO. When to land tables vs call MI APIs
Boilerplate SQL
Databricks SQLStarting point for reading the tables behind CRS610 from landed data — the backing tables joined on their keys and CONO. Set your Unity Catalog location, company, and filter values below.
Query parameters
3 parameters not filled: <catalog>, <schema>, <company>
-- ============================================================
-- Program: CRS610 — Customer maintenance — where customers are created and their OCUSMA terms managed
-- Purpose: Read the tables behind program CRS610 — auto-generated from program-table-map
-- Grain : One row per OCUSMA record
-- Tables : OCUSMA
-- Notes : Auto-generated skeleton for a prefixed physical M3 schema or a landing schema normalized to the prefixed names in this catalog. Raw Data Lake property names vary with the published object: map them through Data Catalog before running this SQL. Dates are numeric YYYYMMDD (0 = none, mapped to NULL); all curated status values are decoded inline; company-partitioned tables are joined on CONO to prevent cross-company fan-out. Audit columns (RGDT/RGTM/LMDT/CHNO/CHID) omitted — see the quirks guide.
-- ============================================================
SELECT
c.OKCONO AS "Company",
c.OKCUNO AS "Customer number — the natural key order headers join on",
c.OKSTAT AS "Customer status — whether the customer is active for new business", -- status: decode c.OKSTAT against your configuration — see quirks guide #statuses
c.OKCUNM AS "Customer name"
FROM <catalog>.<schema>.OCUSMA c
WHERE
c.OKCONO = <company>
ORDER BY c.OKCUNO;