Product

What It Models

A product is the shared catalogue record used to identify an offer or an accounting reference. Accounting keeps the common fields for every registered kind; the application that owns a kind keeps its specialized extension. Prices and selling instructions belong to the common record, while finance maintains its accounting setup separately.

Identity and Attributes

Creation fixes the readable identity, kind and business unit. Product reads combine stored settings with price and component lists, a financial summary and the resolved tax class. Ordinary HTTP saving replaces the supplied configuration and advances its version; confirmation is preserved when omitted.

Relationships

A product owns its prices, selling collections and optional accounting setup. Bundle entries point to other products in the same business unit. Financial documents and domain extensions can also reference the product, so removing it depends on those references.

Invariants

Enforcement varies by entry point. Table constraints keep identities and references consistent, while service validation checks collection totals and the bundle graph it reads. The product lock does not protect the entire graph from concurrent edits to different bundles.

How It Is Stored and Shared

Products maintains the common tables and registers their standard fields as read-only metadata. No custom-field storage is declared. Other applications read the tables under workspace restrictions; domains save their common records through Accounting's database functions. Platform commits owned confirmation content independently. Products declares neither revision history nor change events.

Open Design Questions

Product must settle omission and audience admission differences between the write paths, recovery after a remote template change, and the required audit trail. Quick status actions also need an implementation correction because their incomplete replacement drops hidden availability values.