Rhythm 2.0 Specifications

Appearance

CAP-MBR-STR-008Connect unit dues to products and settlement choices

Markdown

CAP-MBR-STR-008

Connect unit dues to products and settlement choices

Markdown
  • DocumentDraft
  • Product intentProposed
  • ImplementationObserved

Planning

Feature
FEAT-MBR-STR-02
Key concepts
CON-MBR-STR-002
Actors
ACT-MBR-001, ACT-MBR-002, ACT-MBR-005
Journeys
JNY-MBR-STR-001
Depends on
CAP-MBR-STR-006, CAP-MBR-STR-012
Related
CAP-MBR-STR-003, CAP-MBR-STR-009
Proved by
ATS-MBR-STR-008

KindCapabilityProduct areaMembershipModuleOrganizational Structure, Membership Configuration and TermsRevision1

Read atservices-membership 5994c270react-console baf6dae3

Connect unit dues to products and settlement choices ​

Purpose ​

Administrators connect local dues offerings to Accounting products and the unit’s Commerce settlement profile.

How It Works ​

Staff first prepare a chapter-dues product in Accounting. They extend it in Membership for the appropriate unit, optionally associating a membership package. A package-specific offering and a catch-all express different selling contexts. The extension keeps the product’s identity. Reads obtain shared product information live rather than maintaining a competing copy. Staff can replace the package association at the version read. Product retirement remains an Accounting action. Financial settings separately identify the Commerce profile for the unit’s dues. An omitted profile delegates to the documented inheritance choices. Saving those settings creates the first record or replaces the existing version. The product should make the unverified package and profile references clear when staff configure local finance.

Relationships ​

  • Unit records supply the owner of each local finance setting.
  • Membership packages identify the package-specific dues context.
  • Merging leaves local finance records for separate resolution.

The Formal Contract

The narrative above explains; the sections below are authoritative — the rules, scenarios and tests this document binds.

Outcomes
Accounting remains the source of shared dues-product information.A unit can express its own settlement choice or inherit one.
Surfaces
api
Intent sources
services-membership:docs/migrations/packages-as-products/README.md#D-1 (Andrew, 2026-10-18: the package is the product)services-membership:docs/migrations/packages-as-products/README.md#Ordering profiles (Commerce's decision approved by Andrew on 2026-10-18)

Controls

33 controls apply, from the corpus control catalogue.

TC-AVL-002 TC-AVL-003 TC-AZ-001 TC-AZ-002 TC-AZ-003 TC-AZ-004 TC-AZ-005 TC-AZ-006 TC-CHG-001 TC-CHG-002 TC-CHG-003 TC-CHG-004 TC-CRY-001 TC-CRY-002 TC-CRY-003 TC-DAT-001 TC-DAT-007 TC-IAM-001 TC-IAM-002 TC-IAM-004 TC-IAM-005 TC-LOG-001 TC-LOG-002 TC-LOG-003 TC-LOG-004 TC-PI-001 TC-PI-003 TC-PI-005 TC-SEC-001 TC-SEC-004 TC-TEN-001 TC-TEN-002 TC-TEN-003

Permissions

KeyChecked atScope
membership.structure.readapitenant
membership.structure.manageapitenant
membership.application.accessapitenant

Business Rules

9 rules, 6 to be proved before approval. A rule's product intent is derived from its origin: 0 confirmed by a product decision, the rest inheriting this capability's proposed.

IdRuleKindEnforced atProvenance
01must prove
Proposed
A dues extension uses the identity of an existing Accounting chapter-dues product and rejects missing products or other product types.
origin: services-membership:docs/migrations/packages-as-products/README.md#D-1 (Andrew, 2026-10-18: the package is the product)
no proof recorded yet
validationservicetest
services-membership:tests/e2e/packages-as-products.e2e.spec.ts#packages as products, through the API › extends a product of type chapter_dues as a unit’s dues product, under the product’s id, with the product’s name
02must prove
Proposed
Each unit has at most one dues extension per package and one extension without a package, and a product cannot extend dues for multiple units.
no proof recorded yet
invariantservice, databaseobserved
services-membership:modules/structure/services/persistence/organizational-unit-dues-products.ts:createDuesProduct
03must prove
Proposed
Dues reads obtain name, status, visibility, business unit and sale dates from Accounting; a missing product returns its identifier with inactive and hidden defaults.
origin: services-membership:docs/migrations/packages-as-products/README.md#D-1 (Andrew, 2026-10-18: the package is the product)
no proof recorded yet
calculationservicetest
services-membership:modules/structure/tests/unit/accounting-products.spec.ts#the Accounting products port › answers a product Accounting no longer has as its id, inactive, hidden, with no product status
04must prove
Proposed
A dues extension can change its package at the version read, while retirement and deletion are unavailable in Membership because product status belongs to Accounting.
origin: services-membership:docs/migrations/packages-as-products/README.md#D-1 (Andrew, 2026-10-18: the package is the product)
no proof recorded yet
lifecycleservicetest
services-membership:tests/e2e/packages-as-products.e2e.spec.ts#packages as products, through the API › re-points a unit’s dues product at another package at the version just read, 200 with the next version
05
Proposed
A dues extension’s package reference is not verified against the workspace’s package catalogue.
validationserviceobserved
services-membership:modules/structure/services/persistence/organizational-unit-dues-products.ts:createDuesProduct
06must prove
Proposed
Financial settings are created without a version, then require the current version for replacement; a premature version fails and absent settings read as not found.
no proof recorded yet
policyserviceobserved
services-membership:modules/structure/services/persistence/organizational-unit-financial-settings.ts:setFinancialSettings
07must prove
Proposed
A unit stores only an ordering-profile reference checked for shape, with an absent choice inheriting the program, application and workspace defaults.
origin: services-membership:docs/migrations/packages-as-products/README.md#Ordering profiles (Commerce's decision approved by Andrew on 2026-10-18)
no proof recorded yet
policydocumented
services-membership:docs/migrations/packages-as-products/README.md#Ordering profiles (added the same day, from Commerce's decision Andrew approved at about 15:45 UTC)
08
Proposed
The stored default dues-product reference is checked for shape and has no consumer.
validationserviceobserved
services-membership:modules/structure/services/finance/accounting-references.ts:checkAccountingReferenceShapes
09
Proposed
Inactive and merged units permit financial-setting saves and dues-extension creation.
policyserviceobserved
services-membership:modules/structure/services/persistence/organizational-unit-dues-products.ts:createDuesProduct

Scenarios

IdGivenWhenThenProvenance
01Accounting contains the chapter-dues product intended for Atlanta.Staff create its unit extension without a package-specific association.The returned dues offering uses the Accounting product’s shared fields.test
services-membership:tests/e2e/packages-as-products.e2e.spec.ts#packages as products, through the API › extends a product of type chapter_dues as a unit’s dues product, under the product’s id, with the product’s name

Edge Cases

IdGivenWhenThenProvenance
02The product behind Atlanta’s dues becomes inactive.The dues extension is read again.Its returned product fields identify it as inactive and hidden.test
services-membership:modules/structure/tests/unit/accounting-products.spec.ts#the Accounting products port › answers the product’s common fields under the names the package wire kept: inactive is not active and not portal visible

The Markdown files under specs/ in rhythmsoftware/rhythm-v2-docs are the canonical source of truth. This reader is a generated, read-only projection of them.

Rhythm Software