Product
What It Is
A product is the continuing catalogue record for something the organization charges for or needs to identify in its financial work. A publication, a parking permit, a donation and a membership package can all use this common record. Finance creates the general-purpose kinds in Accounting. Other applications keep their own kinds on the same base, so a sale can refer to the product without knowing how that application describes it.
The product brings together a recognizable name, a stable Code, its kind, its owning business unit and the configuration needed by selling and accounting processes. Staff can correct the name without replacing the identity. The kind and business unit are fixed once the record exists. This gives later references a continuing meaning even when the description or price changes.
The shared base separates common financial information from application-specific information. Membership describes package rules beside the product; Commerce describes merchandise beside it. Those extensions do not create competing financial identities.
What It Is Not
A product is distinct from a particular sale. An invoice line records what was charged in a transaction, while the catalogue supplies configuration for later work. A membership package’s eligibility or a merchandise item’s retail presentation belongs to its domain extension. The product also does not grant customer access or establish that a purchase is permitted.
Selling settings are facets of the product. Bundles, task instructions and confirmation choices have no independent lifecycle that would make each a separate broad business concept.
How It Is Used
An administrator chooses the appropriate product kind and business unit, supplies its identity and name, and configures its prices. Finance can separately add accounting treatment. Readers search and inspect the catalogue without receiving authority to change it. Staff withdraw obsolete products while keeping references available, then restore them if the offer returns.
Corrections need the version staff read. Another writer’s save can make that version stale. The console also saves product information separately from accounting information, so a setup refusal may leave the product already saved. Domain applications can instead place their product and extension writes within a shared transaction.
Its Facets
Kind and ownership. The release-managed register describes pricing and supported features. Accounting, Donation and Legacy kinds serve different purposes; domain kinds identify their owning application.
Identity and unit. A readable Code distinguishes the product across all kinds in the workspace. Its fixed unit supplies the accounting context and available currencies. Older generated identities remain usable as references but cannot be corrected.
Status and protection. Active, inactive and retired distinguish current use from withdrawal. Retirement blocks correction until restoration. Separate locks protect deletion or both replacement and deletion.
Availability, visibility and remarks. The record carries sale boundaries, portal visibility, fees and staff notes. Some stored choices have no controls in the current console.
Bundles and quantity incentives. Component allocations describe included products and their quantities. Discount bands describe reductions for quantity purchases. These settings are checked when stored rather than proving purchase-time execution.
Purchase ceilings and follow-up. Customer ceilings describe an all-time or rolling maximum. Task instructions describe staff work after a purchase, including type, queue, assignee and timing.
Confirmation content. A product selects shared content or owns content held by Platform. Storing that selection does not establish that an order sends it.
How It Relates
Prices describe the product’s audience, currency and period choices. Accounting setup describes where its revenue belongs and when it is recognized. Books owns the referenced units and accounts; transactions and orders consume product information. CRM owns task configuration, Platform owns communication content, and domain applications own their extensions.
What It Could Become
The product should keep the common identity dependable as more domain kinds become active. Before design, Product needs to settle omission differences between API and database replacement and the intended purchase-time use of stored features. Restoring hidden console controls also needs an explicit decision about which staff outcome they serve.