Membership Package

What It Models

A package describes the membership effect of buying an Accounting product. Its extension selects the program and classification, term dates, renewal settings, additional grants and structural requirements. Change policies are retained configuration for processing that has not been implemented.

Identity and Attributes

Product and package share one identity. Accounting supplies the public description, availability and pricing data; Membership supplies the membership effect. Fixed ends and unit rules use composite keys, whereas replacing grants allocates new generated identities.

Relationships

The extension refers to its Accounting product, program, classification and optional policy set. Requirements name unit kinds, and local dues extensions may refer to the package. The memberships purchase participant reads these settings and asks the term engine for dates.

Invariants

Invariant rows distinguish product validation at creation from checks performed on later package updates. Database references enforce program compatibility; service validation checks the complete term rule and submitted grants.

How It Is Stored and Shared

Configuration owns the extension and its lists. A save is atomic within Membership, but the documented offering process saves the Accounting product separately first. History capture records package and policy-set revisions, and lifecycle exports expose both.

Open Design Questions

Product must settle inactive-product preparation, absent reinstatement allowances and fresh purchases after fixed windows close. Retained-grant revalidation and the future application of change policies also need explicit decisions.