Create a product with a permanent identity

Purpose

An administrator chooses a kind and business unit, then enters the product name.

How It Works

An administrator chooses a kind and business unit, then enters the product name. The creation form proposes a readable Code that can be adjusted before saving. That reference remains fixed after creation. Pricing and selling settings are checked against the selected kind. The save also checks references and collection limits. Failure leaves the product’s own records unwritten. The console returns staff to their list after successful creation. Older records with generated identities require a replacement product if staff need to change them.

Relationships

This outcome uses understand the available product kinds.

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: Creation preserves a durable catalogue identity.
Surfaces: consoleapi
Preconditions: The workspace contains the selected business unit.
Postconditions: Creation stores the product and its owned configuration at the first version, or the local transaction writes nothing.
Intent sources: services-accounting:docs/milestones/ACCT-M1-books-and-invoices.md#D3services-accounting:docs/milestones/ACCT-M1-books-and-invoices.md#D4services-accounting:docs/milestones/ACCT-M1-books-and-invoices.md#D12services-accounting:docs/milestones/ACCT-M1-books-and-invoices.md#R10services-accounting:docs/milestones/ACCT-M1-books-and-invoices.md#Notes on the decisions:services-accounting:docs/milestones/ACCT-M1-books-and-invoices.md#R11

Controls

24 controls apply, from the corpus control catalogue.

TC-IAM-001 TC-IAM-002 TC-IAM-004 TC-IAM-005 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-DAT-004 TC-LOG-001 TC-LOG-002 TC-LOG-003 TC-LOG-004 TC-LOG-005 TC-PI-001 TC-PI-003 TC-PI-005

Permissions

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

Business Rules

15 rules, 13 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`must prove Proposed	A new product uses a supplied or name-derived configuration identity of at most 63 characters, starting with a lowercase letter and using lowercase letters, digits and single underscores without reserved words. ✓ The name Café Parking Permit (Annual) produces the readable Code cafe_parking_permit_annual.✗ A Code containing uppercase letters and a hyphen fails validation. proved by `ATS-ACC-PRD-002-01`, `TST-ACC-PRD-030`, `TST-ACC-PRD-031`, `TST-ACC-PRD-040`	validation	api, service, database	test services-accounting:modules/products/tests/integration/services/persistence/products.integration.spec.js#refuses an id that is not a configuration id, with the configuration-id sentence, and writes nothing
`02`must prove Proposed	Name-derived identities receive no automatic suffix: a collision or a name yielding no valid identity requires the caller to supply one. proved by `ATS-ACC-PRD-002-02`, `TST-ACC-PRD-040`	validation	service	test services-accounting:modules/products/tests/integration/services/persistence/products.integration.spec.js#refuses a second product whose name suggests a taken id, as other configuration does, naming the id
`03`must prove Proposed	Within a workspace, product identities are unique across product kinds. proved by `ATS-ACC-PRD-002-03`, `TST-ACC-PRD-030`, `TST-ACC-PRD-031`, `TST-ACC-PRD-040`	invariant	database	test services-accounting:modules/products/tests/e2e/products.e2e.spec.js#answers 400 to the same id under another type: a product id is unique across every type
`04`must prove Proposed	Creation requires an active registered kind, an existing business unit in the workspace and a nonblank name. origin: services-accounting:docs/milestones/ACCT-M1-books-and-invoices.md#D4 proved by `ATS-ACC-PRD-001-06`, `ATS-ACC-PRD-002-04`, `TST-ACC-PRD-029`, `TST-ACC-PRD-031`, `TST-ACC-PRD-040`	validation	service, database	test services-accounting:modules/products/tests/e2e/products-shared-base.e2e.spec.js#refuses a type registered inactive (an Events type), 400 with its sentence
`05`must prove Proposed	The server discards a submitted pricing model and uses the kind’s model, which the database also requires. proved by `ATS-ACC-PRD-002-05`, `TST-ACC-PRD-030`, `TST-ACC-PRD-031`	invariant	api, database	test services-accounting:modules/products/tests/integration/db/products.table.integration.spec.js#refuses a pricing model other than its type’s
`06`must prove Proposed	Creation fixes the product’s identity, kind and business unit, and both service and database reject later changes. proved by `ATS-ACC-PRD-002-06`, `ATS-ACC-PRD-007-10`, `TST-ACC-PRD-015`, `TST-ACC-PRD-031`	invariant	service, database	test services-accounting:modules/products/tests/integration/db/products.table.integration.spec.js#refuses a change of business_unit_id (RHF01)
`07` Proposed	Creation defaults to active and permits inactive, while ordinary creation and replacement requests cannot choose retired. origin: services-accounting:docs/milestones/ACCT-M1-books-and-invoices.md#D4 proved by `ATS-ACC-PRD-002-14`	lifecycle	api	observed services-accounting:modules/products/aws/api/products.schemas.ts:productShape
`08`must prove Proposed	A sale window with both boundaries requires its opening instant to precede its closing instant. proved by `ATS-ACC-PRD-002-07`, `TST-ACC-PRD-031`, `TST-ACC-PRD-040`	validation	service, database	test services-accounting:modules/products/tests/integration/services/persistence/products.integration.spec.js#refuses a sale window that ends before it starts
`09`must prove Proposed	Cancellation and restocking fees use nonnegative whole minor units of the business unit’s base currency. proved by `ATS-ACC-PRD-002-08`, `TST-ACC-PRD-031`	validation	api, database	test services-accounting:modules/products/tests/integration/db/products.table.integration.spec.js#refuses a negative cancellation fee
`10`must prove Proposed	Unsellable kinds reject fees and selling settings, while giver-priced kinds also reject quantity discounts and bundles. proved by `ATS-ACC-PRD-002-09`, `TST-ACC-PRD-039`, `TST-ACC-PRD-040`	validation	service	test services-accounting:modules/products/tests/integration/services/persistence/products.features.integration.spec.js#refuses a cancellation fee on a Legacy Product
`11`must prove Proposed	Product creation commits its record, pricing, components and feature collections together or retains none of those writes. proved by `ATS-ACC-PRD-002-10`, `ATS-ACC-PRD-002-15`, `TST-ACC-PRD-040`	invariant	service	test services-accounting:modules/products/tests/integration/services/persistence/products.integration.spec.js#leaves nothing behind after a refusal
`12`must prove Proposed	Products with older generated identities remain readable, referenceable and deletable, but replacement, retirement and reactivation fail. origin: services-accounting:docs/milestones/ACCT-M1-books-and-invoices.md#D12 proved by `ATS-ACC-PRD-002-11`, `TST-ACC-PRD-040`	lifecycle	database	test services-accounting:modules/products/tests/integration/services/persistence/products.integration.spec.js#refuses a replacement, 409, saying why, and leaves the product unchanged
`13`must prove Proposed	Products support no custom field values and reject requests containing them. origin: services-accounting:docs/milestones/ACCT-M1-books-and-invoices.md#Notes on the decisions: proved by `ATS-ACC-PRD-002-12`, `TST-ACC-PRD-029`, `TST-ACC-PRD-042`	validation	api	test services-accounting:modules/products/tests/e2e/products-shared-base.e2e.spec.js#refuses a body that names custom fields, 400 naming the property
`14`must prove Proposed	Product creation requires product create permission. origin: services-accounting:docs/milestones/ACCT-M1-books-and-invoices.md#D3 proved by `ATS-ACC-PRD-002-13`, `TST-ACC-PRD-028`	permission	api	test services-accounting:modules/products/tests/e2e/products-security.e2e.spec.js#is refused creating a product
`15` Proposed	The console derives an editable Code from Name during creation, selects the list’s unit or the working unit, and returns to the list after successful creation. origin: services-accounting:docs/milestones/ACCT-M1-books-and-invoices.md#R10; services-accounting:docs/milestones/ACCT-M1-books-and-invoices.md#R11; services-accounting:docs/milestones/ACCT-M1-books-and-invoices.md#R20	policy	console	observed react-console:components/accounting-config/products/use-products.ts:newProductPath

Scenarios

Id	Given	When	Then	Provenance
`01`	A chapter business unit uses US dollars.	A controller creates Parking Permit with a 25000-minor-unit standard price.	The saved product has a readable identity, active status, version one and a $250.00 price.	test services-accounting:modules/products/tests/e2e/products.e2e.spec.js#creates it under the id it was given, in the tenant of the path, at version 1
`02`	A donation already uses the identity gala.	An administrator creates an Accounting Product with that identity.	The collision is rejected across product kinds.	test services-accounting:modules/products/tests/e2e/products.e2e.spec.js#answers 400 to the same id under another type: a product id is unique across every type

Edge Cases

Id	Given	When	Then	Provenance
`03`	An older product retains its generated identity.	An administrator submits a new name.	The refusal explains that a readable-identity replacement product is needed.	test services-accounting:modules/products/tests/integration/services/persistence/products.integration.spec.js#refuses a replacement, 409, saying why, and leaves the product unchanged

Planning

Implementation

Create a product with a permanent identity ​

Purpose ​

How It Works ​

Relationships ​