Master data (ingested)
Catalog and transactional entities are populated by the data platform’s ETL from POS systems (Polaris, Kezia) and are read-only in the app. They are organization-scoped.Analytics layers
The data platform exposes these as silver (cleaned/normalized) and gold (business-ready) tables — e.g.fact_sales_lines, fact_order_lines,
fact_movement_lines, stock_ledger, stock_snapshot, the dim_* dimensions,
*_shop_analytics summaries, sales_forecasts, and decision_vector. The app reads
these for dashboards, KPIs, search, alerts, and recommendations.
Because catalog data is ingested, you don’t create shops/products/variants in the app —
they arrive through ingestion. See the Data layer.
App-managed data (created in Solya)
Everything you create lives in PostgreSQL and is org-scoped: inventory plans and their items, business rules and rulesets, budget envelopes, size curves, markdown calendars, supplier constraints, approval/return policies, org lists, alerts, tags and tagging rules, workflows, settings, navigation templates, and the audit log. Each new table documents how its data is populated, modified, and access-controlled.Plan status enumerations
The exact statuses per plan type (used by the API and surfaced in the UI):
Plan item status is shared:
TO_REVIEW and READY_FOR_ORDER. Supplier-side plans
carry extra enumerations — return reason codes (e.g. defect, transit damage, wrong
SKU/quantity, recall, QC fail, other), return source types (restock, pre-season), and
exchange sides (return, receive).
These status values are stable identifiers you can branch on. The conceptual lifecycle
(reversible transitions, decision moments, approvals) is described in
Inventory plans → lifecycle.