Record the follow-up work a purchase needs

Purpose

Staff describe the work that should follow a purchase in task instructions.

How It Works

Staff describe the work that should follow a purchase in task instructions. Each instruction identifies a CRM task type and may select a queue or assignee. A due interval makes the intended timing explicit. The console uses a dialog and a user chooser to capture those choices. Accounting checks task types and queues against the workspace’s CRM configuration. It preserves inactive references already held by the product. Assignee existence remains unchecked beyond identity format. Saving replaces the instructions together. Actual CRM task creation belongs to Orders and is still a separate proof obligation.

Relationships

This outcome uses create a product with a permanent identity.

Show evidence (sources, provenance, origins, pinned commits)

The Formal Contract

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

Outcomes: Follow-up instructions remain attached to the purchased product.
Surfaces: consoleapi
Intent sources: services-accounting:docs/milestones/ACCT-M1-books-and-invoices.md#R22

Controls

25 controls apply, from the corpus control catalogue.

TC-IAM-001 TC-IAM-002 TC-IAM-004 TC-IAM-005 TC-IAM-006 TC-AZ-001 TC-AZ-002 TC-AZ-003 TC-AZ-004 TC-AZ-005 TC-AZ-006 TC-TEN-001 TC-TEN-002 TC-TEN-003 TC-TEN-004 TC-DAT-001 TC-LOG-001 TC-LOG-002 TC-LOG-003 TC-LOG-004 TC-LOG-005 TC-PI-001 TC-PI-002 TC-PI-003 TC-PI-005

Permissions

Key	Checked at	Scope
`accounting.products.update`	api	tenant

Business Rules

6 rules, 3 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.

Id	Rule	Kind	Enforced at	Provenance
`01` Proposed	A task instruction requires a name and CRM task type and may include description, queue, assignee and a nonnegative delay in days, weeks or months. proved by `ATS-ACC-PRD-013-04`, `TST-ACC-PRD-039`	validation	api, database	test services-accounting:modules/products/tests/integration/services/persistence/products.features.integration.spec.js#answers every feature as written, the lists in the order sent
`02`must prove Proposed	Task types and queues must exist in the workspace and be active when newly assigned, while previously held inactive choices remain acceptable. proved by `ATS-ACC-PRD-013-01`, `TST-ACC-PRD-039`	validation	service	test services-accounting:modules/products/tests/integration/services/persistence/products.features.integration.spec.js#keeps a task type and a queue that became inactive while the product held them
`03`must prove Proposed	Assignee values must match the Rhythm user identity format, with no check that a user exists. proved by `ATS-ACC-PRD-013-02`, `TST-ACC-PRD-027`, `TST-ACC-PRD-039`	validation	api, database	test services-accounting:modules/products/tests/e2e/product-features.e2e.spec.js#refuses an assignee that is not a Platform user id
`04`must prove Proposed	A product stores at most twenty task instructions and replaces or clears the whole collection on save. origin: services-accounting:docs/milestones/ACCT-M1-books-and-invoices.md#D12 proved by `ATS-ACC-PRD-013-03`, `ATS-ACC-PRD-013-05`, `TST-ACC-PRD-006`, `TST-ACC-PRD-039`	validation	api, service	test services-accounting:modules/products/tests/integration/services/persistence/products.features.integration.spec.js#refuses more than 20 tasks to generate
`05` Proposed	Documented responsibility assigns task creation at purchase to Orders and excludes staff task instructions from the portal projection.	policy		documented services-accounting:docs/accounting/products.md#Features (2026-10-16)
`06` Proposed	The console edits task instructions in a dialog and selects assignees from a user chooser. origin: services-accounting:docs/milestones/ACCT-M1-books-and-invoices.md#R22	policy	console	documented services-accounting:docs/milestones/ACCT-M1-books-and-invoices.md#R22

Scenarios

Id	Given	When	Then	Provenance
`01`	A certification product needs fulfillment follow-up.	Staff store a certificate-mailing instruction due seven days after purchase.	The product returns those instructions, while purchase-time task creation remains an Orders responsibility.	observed services-accounting:modules/products/services/persistence/products.ts:normalizedFeatures

Edge Cases

Id	Given	When	Then	Provenance
`02`	CRM deactivates a type already used by a product’s task instructions.	Staff correct only the product description.	The held type remains, while a new assignment of that inactive type fails.	test services-accounting:modules/products/tests/integration/services/persistence/products.features.integration.spec.js#keeps a task type and a queue that became inactive while the product held them

Planning

Implementation

Record the follow-up work a purchase needs ​

Purpose ​

How It Works ​

Relationships ​