Accounting Setup

What It Models

An accounting setup tells finance how a product's money is routed, recognized and shared. It contains account and dimension references, recognition dates or ranges, revenue shares and accounts for other business units. A product may have no setup; the documented posting policy then uses its unit's defaults. Product-kind tax defaults remain a facet here pending the approved transfer to Commerce.

Identity and Attributes

The product identifies its optional setup, which has its own version and lock. A setup write replaces the row and four child collections together. The API can preserve supplied revenue-share identities, but the current console does not return them when saving.

Relationships

The setup belongs to its product and retains that product's business unit. Ordinary accounts and dimensions resolve in that unit, tax classes in the workspace, and inter-entity accounts in their named other unit. Validation obtains the product lock before reading the standard price used to bound fixed shares.

Invariants

Allocation totals are checked during setup writes. A subsequent product edit does not check existing shares against a reduced price. The posting record's account preservation is documented downstream behavior and is not enforced by this setup service.

How It Is Stored and Shared

Products owns setup persistence under permissions independent of catalogue editing. Consumers read the configuration needed for their financial work. The tax transfer changes future ownership; until that cutover, Accounting retains setup assignments and kind defaults and resolves their precedence.

Open Design Questions

Existing tax assignments need a migration and cutover plan. Product must decide the history requirement and whether staged console saving needs an atomic option. Browser validation differences, regenerated share identities and the absent setup-delete action remain implementation findings.