284313f908
Some checks are pending
Bidi Control Character Guard / bidi-control-guard (push) Waiting to run
Circular Dependency Check / Check for new circular dependencies (push) Waiting to run
Citus Migration Smoke / Combined migrations on single-node Citus (push) Waiting to run
E2E Fresh Install Tests / fresh-install-e2e (push) Waiting to run
ext-v2 guardrails / Run ext-v2 guard and ESLint (push) Waiting to run
Integration Tests / Check for relevant changes (push) Waiting to run
Integration Tests / ${{ (github.event_name == 'schedule' || github.event.inputs.suite == 'full') && 'Full integration suite' || 'Tier-1 integration subset' }} (push) Blocked by required conditions
Mobile checks / Mobile lint + typecheck (push) Waiting to run
Mobile checks / Mobile unit tests (push) Waiting to run
Mobile checks / Mobile dependency audit (report) (push) Waiting to run
Mobile checks / Mobile reproducibility checks (push) Waiting to run
Secrets guard (env backups) / Ensure no tracked env backup files (push) Waiting to run
Temporal Readiness / fast-readiness (push) Waiting to run
Temporal Readiness / docker-parity (push) Waiting to run
TypeScript Type Check / Nx affected typecheck (push) Waiting to run
Unit Tests / Skipped-test budget (push) Waiting to run
Unit Tests / Nx affected unit tests (push) Waiting to run
Unit Tests / Server unit coverage (informational) (push) Waiting to run
Validate Tenant Management Schema / Check for relevant changes (push) Waiting to run
Validate Tenant Management Schema / Validate Tenant Management Schema (push) Blocked by required conditions
EE Workflows Build Guard / ee-workflows-build-guard (push) Waiting to run
Excluded: .git, node_modules, secrets/, compose.env, assemblyscript tgz Source: /opt/alga-psa on psa.joliet.tech
2433 lines
78 KiB
JSON
2433 lines
78 KiB
JSON
[
|
|
{
|
|
"id": "F001",
|
|
"description": "Document the architecture thesis that recurring billing truth flows from cadence owner to service periods to due invoice windows to persisted invoice detail metadata",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Architecture Thesis",
|
|
"Summary"
|
|
]
|
|
},
|
|
{
|
|
"id": "F002",
|
|
"description": "Document an explicit system-surface matrix covering runtime billing, invoice generation, credits, APIs, UI, portal, exports, reporting, migrations, and cleanup",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"System Surfaces In Scope",
|
|
"Summary"
|
|
]
|
|
},
|
|
{
|
|
"id": "F003",
|
|
"description": "Inventory every recurring timing control currently in use, including billing frequency, client anchors, assignment dates, billing_timing, enable_proration, and billing_cycle_alignment",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Implementation Sequence",
|
|
"Detailed Requirements"
|
|
]
|
|
},
|
|
{
|
|
"id": "F004",
|
|
"description": "Inventory every persisted date/period field that participates in recurring billing or billed-through semantics across invoices, invoice details, and client billing cycles",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Implementation Sequence",
|
|
"System Surfaces In Scope"
|
|
]
|
|
},
|
|
{
|
|
"id": "F005",
|
|
"description": "Inventory every consumer of service period metadata, including exports, portal views, reporting, credits, and invoice detail readers",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Implementation Sequence",
|
|
"System Surfaces In Scope"
|
|
]
|
|
},
|
|
{
|
|
"id": "F006",
|
|
"description": "Explicitly mark time, usage, materials, and manual-only non-recurring flows as outside the first hard cut while documenting their compatibility boundaries",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Scope",
|
|
"Non-goals"
|
|
]
|
|
},
|
|
{
|
|
"id": "F007",
|
|
"description": "Build a recurring-billing parity matrix spanning frequency, timing mode, start/end boundaries, pricing schedules, discounts, credits, and charge families",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Implementation Sequence",
|
|
"Detailed Requirements"
|
|
]
|
|
},
|
|
{
|
|
"id": "F008",
|
|
"description": "Build parity harness infrastructure that can compare legacy and service-period-first outputs for client-cadence recurring scenarios before cutover",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Implementation Sequence",
|
|
"Detailed Requirements"
|
|
]
|
|
},
|
|
{
|
|
"id": "F009",
|
|
"description": "Define cutover-blocking parity regressions separately from acceptable metadata-shape changes so rollout decisions are deterministic",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Implementation Sequence",
|
|
"Risks"
|
|
]
|
|
},
|
|
{
|
|
"id": "F010",
|
|
"description": "Define representative recurring fixture builders that cover monthly, quarterly, semi-annual, annual, advance, arrears, mid-period starts, mid-period ends, and mixed overlays",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Detailed Requirements",
|
|
"Implementation Sequence"
|
|
]
|
|
},
|
|
{
|
|
"id": "F011",
|
|
"description": "Define a canonical service-period data structure with explicit start, end, cadence owner, source obligation, and timing metadata",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Detailed Requirements",
|
|
"Architecture Thesis"
|
|
]
|
|
},
|
|
{
|
|
"id": "F012",
|
|
"description": "Define a canonical invoice-window or due-window data structure separate from service periods",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Detailed Requirements",
|
|
"Architecture Thesis"
|
|
]
|
|
},
|
|
{
|
|
"id": "F013",
|
|
"description": "Define cadence-owner semantics and lifecycle defaults for recurring obligations",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Detailed Requirements",
|
|
"Architecture Thesis"
|
|
]
|
|
},
|
|
{
|
|
"id": "F014",
|
|
"description": "Define a cadence-boundary generator interface with pluggable client-cadence and contract-cadence implementations",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Detailed Requirements",
|
|
"Implementation Sequence"
|
|
]
|
|
},
|
|
{
|
|
"id": "F015",
|
|
"description": "Define activity-window intersection rules that combine generated service periods with assignment start and end dates",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Detailed Requirements",
|
|
"Architecture Thesis"
|
|
]
|
|
},
|
|
{
|
|
"id": "F016",
|
|
"description": "Define partial-period settlement rules that replace duplicated proration math with one recurring coverage model",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Detailed Requirements",
|
|
"Architecture Thesis"
|
|
]
|
|
},
|
|
{
|
|
"id": "F017",
|
|
"description": "Define due-position rules that map service periods to invoice windows for advance and arrears timing",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Detailed Requirements",
|
|
"Architecture Thesis"
|
|
]
|
|
},
|
|
{
|
|
"id": "F018",
|
|
"description": "Define one inclusive/exclusive date semantic model across client billing cycles, service periods, assignment dates, and invoice detail persistence",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Detailed Requirements",
|
|
"Architecture Thesis"
|
|
]
|
|
},
|
|
{
|
|
"id": "F019",
|
|
"description": "Define a shared persistence contract for invoice detail rows produced from canonical recurring service periods",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Detailed Requirements",
|
|
"System Surfaces In Scope"
|
|
]
|
|
},
|
|
{
|
|
"id": "F020",
|
|
"description": "Add shared recurring timing test utilities and factories that can assert canonical service-period behavior independently of invoice creation",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Detailed Requirements",
|
|
"Implementation Sequence"
|
|
]
|
|
},
|
|
{
|
|
"id": "F021",
|
|
"description": "Implement monthly client-cadence service-period boundary generation using current client anchor-day behavior",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Implementation Sequence",
|
|
"Detailed Requirements"
|
|
]
|
|
},
|
|
{
|
|
"id": "F022",
|
|
"description": "Implement quarterly client-cadence service-period boundary generation using current anchor month/day behavior",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Implementation Sequence",
|
|
"Detailed Requirements"
|
|
]
|
|
},
|
|
{
|
|
"id": "F023",
|
|
"description": "Implement semi-annual client-cadence service-period boundary generation using current anchor month/day behavior",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Implementation Sequence",
|
|
"Detailed Requirements"
|
|
]
|
|
},
|
|
{
|
|
"id": "F024",
|
|
"description": "Implement annual client-cadence service-period boundary generation using current anchor month/day behavior",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Implementation Sequence",
|
|
"Detailed Requirements"
|
|
]
|
|
},
|
|
{
|
|
"id": "F025",
|
|
"description": "Implement weekly client-cadence service-period boundary generation with explicit [start, end) semantics",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Implementation Sequence",
|
|
"Detailed Requirements"
|
|
]
|
|
},
|
|
{
|
|
"id": "F026",
|
|
"description": "Implement bi-weekly client-cadence service-period boundary generation with explicit [start, end) semantics",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Implementation Sequence",
|
|
"Detailed Requirements"
|
|
]
|
|
},
|
|
{
|
|
"id": "F027",
|
|
"description": "Preserve current transition-period behavior when client billing anchors change on future non-invoiced cycles",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Implementation Sequence",
|
|
"Detailed Requirements"
|
|
]
|
|
},
|
|
{
|
|
"id": "F028",
|
|
"description": "Preserve current [start, end) client billing cycle semantics when translating billing cycles into canonical service periods",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Detailed Requirements",
|
|
"Architecture Thesis"
|
|
]
|
|
},
|
|
{
|
|
"id": "F029",
|
|
"description": "Define deterministic client-cadence service-period behavior when historical billing cycles exist but client billing settings changed later",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Implementation Sequence",
|
|
"Risks"
|
|
]
|
|
},
|
|
{
|
|
"id": "F030",
|
|
"description": "Define safe fallback behavior when legacy or partial client billing cycle data is encountered during service-period generation",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Detailed Requirements",
|
|
"Risks"
|
|
]
|
|
},
|
|
{
|
|
"id": "F031",
|
|
"description": "Map advance timing to the current service period on the current invoice window without separate service-period logic",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Detailed Requirements",
|
|
"Implementation Sequence"
|
|
]
|
|
},
|
|
{
|
|
"id": "F032",
|
|
"description": "Map arrears timing to the previous service period on the current invoice window without separate service-period logic",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Detailed Requirements",
|
|
"Implementation Sequence"
|
|
]
|
|
},
|
|
{
|
|
"id": "F033",
|
|
"description": "Replace mid-period start handling with activity-window intersection against generated service periods",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Detailed Requirements",
|
|
"Architecture Thesis"
|
|
]
|
|
},
|
|
{
|
|
"id": "F034",
|
|
"description": "Replace mid-period end handling with activity-window intersection against generated service periods",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Detailed Requirements",
|
|
"Architecture Thesis"
|
|
]
|
|
},
|
|
{
|
|
"id": "F035",
|
|
"description": "Replace fixed-charge proration factor logic with partial-period settlement derived from actual service-period coverage",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Detailed Requirements",
|
|
"Implementation Sequence"
|
|
]
|
|
},
|
|
{
|
|
"id": "F036",
|
|
"description": "Replace product and license proration factor logic with the same partial-period settlement model",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Detailed Requirements",
|
|
"Implementation Sequence"
|
|
]
|
|
},
|
|
{
|
|
"id": "F037",
|
|
"description": "Define first-period behavior for newly activated recurring lines under both advance and arrears timing",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Detailed Requirements",
|
|
"Risks"
|
|
]
|
|
},
|
|
{
|
|
"id": "F038",
|
|
"description": "Define final-period behavior for terminated recurring lines under both advance and arrears timing",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Detailed Requirements",
|
|
"Risks"
|
|
]
|
|
},
|
|
{
|
|
"id": "F039",
|
|
"description": "Define no-coverage and zero-length behavior so unsupported or empty service periods never create duplicate or spurious recurring charges",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Detailed Requirements",
|
|
"Risks"
|
|
]
|
|
},
|
|
{
|
|
"id": "F040",
|
|
"description": "Centralize recurring timing resolution so fixed, product, and license charge families no longer implement their own date math",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Architecture Thesis",
|
|
"Detailed Requirements"
|
|
]
|
|
},
|
|
{
|
|
"id": "F041",
|
|
"description": "Refactor fixed recurring charge entry points in BillingEngine to consume canonical service periods",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Implementation Sequence",
|
|
"System Surfaces In Scope"
|
|
]
|
|
},
|
|
{
|
|
"id": "F042",
|
|
"description": "Remove direct dependency on resolveServicePeriod for fixed recurring charges",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Implementation Sequence",
|
|
"Detailed Requirements"
|
|
]
|
|
},
|
|
{
|
|
"id": "F043",
|
|
"description": "Remove arrears-specific skip branches in fixed recurring billing once service-period eligibility exists",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Implementation Sequence",
|
|
"Detailed Requirements"
|
|
]
|
|
},
|
|
{
|
|
"id": "F044",
|
|
"description": "Replace advance termination credit special casing with canonical partial-period settlement for fixed recurring charges",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Implementation Sequence",
|
|
"Detailed Requirements"
|
|
]
|
|
},
|
|
{
|
|
"id": "F045",
|
|
"description": "Preserve FMV allocation behavior while changing only the timing source for fixed recurring charges",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Detailed Requirements",
|
|
"Risks"
|
|
]
|
|
},
|
|
{
|
|
"id": "F046",
|
|
"description": "Preserve pricing-schedule override precedence for fixed recurring charges under service-period-first timing",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Detailed Requirements",
|
|
"System Surfaces In Scope"
|
|
]
|
|
},
|
|
{
|
|
"id": "F047",
|
|
"description": "Preserve contract-level custom rate behavior for fixed recurring lines under service-period-first timing",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Detailed Requirements",
|
|
"System Surfaces In Scope"
|
|
]
|
|
},
|
|
{
|
|
"id": "F048",
|
|
"description": "Preserve tax allocation and tax-region behavior for fixed recurring charges while timing semantics change",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Detailed Requirements",
|
|
"System Surfaces In Scope"
|
|
]
|
|
},
|
|
{
|
|
"id": "F049",
|
|
"description": "Preserve purchase-order and assignment metadata behavior for fixed recurring charges after service-period-first cutover",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"System Surfaces In Scope",
|
|
"Detailed Requirements"
|
|
]
|
|
},
|
|
{
|
|
"id": "F050",
|
|
"description": "Persist fixed recurring invoice detail rows with canonical service-period metadata and parity-check them against legacy behavior",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Implementation Sequence",
|
|
"Detailed Requirements"
|
|
]
|
|
},
|
|
{
|
|
"id": "F051",
|
|
"description": "Define how bucket or allowance periods map onto canonical recurring service periods for recurring bucket contract lines",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Detailed Requirements",
|
|
"System Surfaces In Scope"
|
|
]
|
|
},
|
|
{
|
|
"id": "F052",
|
|
"description": "Align remaining-bucket and rollover calculations with canonical service-period boundaries where recurring timing currently matters",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Detailed Requirements",
|
|
"Risks"
|
|
]
|
|
},
|
|
{
|
|
"id": "F053",
|
|
"description": "Preserve bucket overage charging behavior when bucket plans move onto service-period-first timing semantics",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Detailed Requirements",
|
|
"System Surfaces In Scope"
|
|
]
|
|
},
|
|
{
|
|
"id": "F054",
|
|
"description": "Preserve discount applicability evaluation when recurring line timing is driven by canonical service periods",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Detailed Requirements",
|
|
"System Surfaces In Scope"
|
|
]
|
|
},
|
|
{
|
|
"id": "F055",
|
|
"description": "Preserve pricing schedule effective-date evaluation when service periods, not ad hoc billing windows, drive recurring charges",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Detailed Requirements",
|
|
"System Surfaces In Scope"
|
|
]
|
|
},
|
|
{
|
|
"id": "F056",
|
|
"description": "Preserve tax date-selection semantics when recurring charges are produced from canonical service periods",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Detailed Requirements",
|
|
"System Surfaces In Scope"
|
|
]
|
|
},
|
|
{
|
|
"id": "F057",
|
|
"description": "Define behavior for negative recurring totals and credit-generating service allocations under canonical service periods",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Detailed Requirements",
|
|
"Risks"
|
|
]
|
|
},
|
|
{
|
|
"id": "F058",
|
|
"description": "Ensure prepayment and prepaid-invoice flows consume canonical recurring service-period metadata where they currently depend on recurring timing",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"System Surfaces In Scope",
|
|
"Detailed Requirements"
|
|
]
|
|
},
|
|
{
|
|
"id": "F059",
|
|
"description": "Ensure purchase-order support and PO banners continue to interpret recurring timing correctly after service-period cutover",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"System Surfaces In Scope",
|
|
"Detailed Requirements"
|
|
]
|
|
},
|
|
{
|
|
"id": "F060",
|
|
"description": "Explicitly document which bucket, time, and usage behaviors remain outside the first recurring service-period implementation",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Scope",
|
|
"Detailed Requirements"
|
|
]
|
|
},
|
|
{
|
|
"id": "F061",
|
|
"description": "Identify recurring product charge paths that currently rely on late-stage proration adjustment",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"System Surfaces In Scope",
|
|
"Implementation Sequence"
|
|
]
|
|
},
|
|
{
|
|
"id": "F062",
|
|
"description": "Refactor recurring product charges to derive timing entirely from canonical service periods",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Implementation Sequence",
|
|
"Detailed Requirements"
|
|
]
|
|
},
|
|
{
|
|
"id": "F063",
|
|
"description": "Preserve catalog price lookup versus contract override precedence for recurring product charges under the new timing model",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Detailed Requirements",
|
|
"Risks"
|
|
]
|
|
},
|
|
{
|
|
"id": "F064",
|
|
"description": "Preserve recurring product tax behavior while moving products onto canonical service periods",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Detailed Requirements",
|
|
"System Surfaces In Scope"
|
|
]
|
|
},
|
|
{
|
|
"id": "F065",
|
|
"description": "Identify recurring license charge paths that currently rely on late-stage proration adjustment",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"System Surfaces In Scope",
|
|
"Implementation Sequence"
|
|
]
|
|
},
|
|
{
|
|
"id": "F066",
|
|
"description": "Refactor recurring license charges to derive timing entirely from canonical service periods",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Implementation Sequence",
|
|
"Detailed Requirements"
|
|
]
|
|
},
|
|
{
|
|
"id": "F067",
|
|
"description": "Preserve recurring license quantity, price, and renewal-related behavior while timing semantics change",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Detailed Requirements",
|
|
"Risks"
|
|
]
|
|
},
|
|
{
|
|
"id": "F068",
|
|
"description": "Preserve recurring license tax behavior while moving licenses onto canonical service periods",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Detailed Requirements",
|
|
"System Surfaces In Scope"
|
|
]
|
|
},
|
|
{
|
|
"id": "F069",
|
|
"description": "Persist product invoice detail rows with canonical service-period metadata",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Detailed Requirements",
|
|
"System Surfaces In Scope"
|
|
]
|
|
},
|
|
{
|
|
"id": "F070",
|
|
"description": "Persist license invoice detail rows with canonical service-period metadata",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Detailed Requirements",
|
|
"System Surfaces In Scope"
|
|
]
|
|
},
|
|
{
|
|
"id": "F071",
|
|
"description": "Refactor invoice generation to select due recurring service periods for a billing cycle window instead of deriving recurring service periods inside each charge path",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Implementation Sequence",
|
|
"Detailed Requirements"
|
|
]
|
|
},
|
|
{
|
|
"id": "F072",
|
|
"description": "Preserve invoice header billing_period_start and billing_period_end semantics while recurring line details adopt canonical service periods",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Detailed Requirements",
|
|
"System Surfaces In Scope"
|
|
]
|
|
},
|
|
{
|
|
"id": "F073",
|
|
"description": "Preserve createInvoiceFromBillingResult and downstream invoice finalization behavior when recurring charges are service-period-first",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"System Surfaces In Scope",
|
|
"Risks"
|
|
]
|
|
},
|
|
{
|
|
"id": "F074",
|
|
"description": "Update recurring billing run actions and automatic invoice generation flows to use the new recurring period selection model",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Implementation Sequence",
|
|
"System Surfaces In Scope"
|
|
]
|
|
},
|
|
{
|
|
"id": "F075",
|
|
"description": "Update preview and generate-one-cycle actions to compare and display recurring charges sourced from canonical service periods",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Implementation Sequence",
|
|
"System Surfaces In Scope"
|
|
]
|
|
},
|
|
{
|
|
"id": "F076",
|
|
"description": "Ensure manual invoice creation and editing flows continue to coexist with recurring service-period metadata without accidental coupling",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Scope",
|
|
"System Surfaces In Scope"
|
|
]
|
|
},
|
|
{
|
|
"id": "F077",
|
|
"description": "Preserve negative-invoice and credit-application flows when recurring charge timing changes underneath invoice generation",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"System Surfaces In Scope",
|
|
"Risks"
|
|
]
|
|
},
|
|
{
|
|
"id": "F078",
|
|
"description": "Preserve credit expiration and reconciliation behavior when recurring invoice detail periods become canonical and more explicit",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"System Surfaces In Scope",
|
|
"Risks"
|
|
]
|
|
},
|
|
{
|
|
"id": "F079",
|
|
"description": "Ensure invoice workflow events and audit metadata remain correct when recurring charges derive from canonical service periods",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"System Surfaces In Scope",
|
|
"Detailed Requirements"
|
|
]
|
|
},
|
|
{
|
|
"id": "F080",
|
|
"description": "Ensure duplicate-invoice prevention and billed-through calculations still work when recurring selection is driven by due service periods",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Detailed Requirements",
|
|
"Risks"
|
|
]
|
|
},
|
|
{
|
|
"id": "F081",
|
|
"description": "Decide and implement the v1 persistence location for cadence_owner",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Open Questions",
|
|
"Detailed Requirements"
|
|
]
|
|
},
|
|
{
|
|
"id": "F082",
|
|
"description": "Add cadence_owner to database schema with safe defaults and backfill for existing recurring records",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Implementation Sequence",
|
|
"Detailed Requirements"
|
|
]
|
|
},
|
|
{
|
|
"id": "F083",
|
|
"description": "Update shared, server, and package interfaces to add cadence_owner and service-period-first recurring terminology",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Detailed Requirements",
|
|
"System Surfaces In Scope"
|
|
]
|
|
},
|
|
{
|
|
"id": "F084",
|
|
"description": "Update repositories and models that read or write contract line billing config to surface cadence_owner and de-emphasize billing_cycle_alignment",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Detailed Requirements",
|
|
"System Surfaces In Scope"
|
|
]
|
|
},
|
|
{
|
|
"id": "F085",
|
|
"description": "Update server API schemas and services that create or update contract lines, templates, or billing settings to accept cadence_owner safely",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Detailed Requirements",
|
|
"System Surfaces In Scope"
|
|
]
|
|
},
|
|
{
|
|
"id": "F086",
|
|
"description": "Update package actions that create or update recurring contract lines, presets, templates, and wizards to persist cadence_owner",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"System Surfaces In Scope",
|
|
"Detailed Requirements"
|
|
]
|
|
},
|
|
{
|
|
"id": "F087",
|
|
"description": "Update test utilities and fixture builders to generate service-period-first recurring scenarios across timing modes and cadence owners",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Implementation Sequence",
|
|
"Detailed Requirements"
|
|
]
|
|
},
|
|
{
|
|
"id": "F088",
|
|
"description": "Add validation rules preventing unsupported cadence-owner and timing combinations during staged rollout",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Detailed Requirements",
|
|
"Risks"
|
|
]
|
|
},
|
|
{
|
|
"id": "F089",
|
|
"description": "Add compatibility readers and writers so existing records lacking cadence_owner continue to behave as client cadence until migrated",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Implementation Sequence",
|
|
"Risks"
|
|
]
|
|
},
|
|
{
|
|
"id": "F090",
|
|
"description": "Prepare a staged deprecation path for billing_cycle_alignment in repositories, models, and API payloads without breaking rollout",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Implementation Sequence",
|
|
"Detailed Requirements"
|
|
]
|
|
},
|
|
{
|
|
"id": "F091",
|
|
"description": "Update recurring contract line configuration UI to present cadence owner in business terms",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"System Surfaces In Scope",
|
|
"Detailed Requirements"
|
|
]
|
|
},
|
|
{
|
|
"id": "F092",
|
|
"description": "Update contract wizard and resume flows to capture cadence owner for newly created recurring lines",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"System Surfaces In Scope",
|
|
"Detailed Requirements"
|
|
]
|
|
},
|
|
{
|
|
"id": "F093",
|
|
"description": "Update template detail and template wizard recurring configuration UI to capture cadence-owner defaults for template-authored lines",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"System Surfaces In Scope",
|
|
"Detailed Requirements"
|
|
]
|
|
},
|
|
{
|
|
"id": "F094",
|
|
"description": "Update fixed recurring configuration panels to explain partial-period settlement instead of proration-as-workaround",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Detailed Requirements",
|
|
"Architecture Thesis"
|
|
]
|
|
},
|
|
{
|
|
"id": "F095",
|
|
"description": "Update billing dashboard copy, quick-start guidance, and settings descriptions to reflect service-period-first semantics",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"System Surfaces In Scope",
|
|
"Detailed Requirements"
|
|
]
|
|
},
|
|
{
|
|
"id": "F096",
|
|
"description": "Update client billing schedule UI and preview flows to clarify that client cadence is one possible recurring service-period owner, not the only source of timing",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"System Surfaces In Scope",
|
|
"Detailed Requirements"
|
|
]
|
|
},
|
|
{
|
|
"id": "F097",
|
|
"description": "Update client portal invoice, contract-line, and billing-detail views to display canonical service-period metadata accurately",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"System Surfaces In Scope",
|
|
"Detailed Requirements"
|
|
]
|
|
},
|
|
{
|
|
"id": "F098",
|
|
"description": "Update reporting actions and report definitions that summarize recurring invoices or contract billing periods to interpret canonical service periods correctly",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"System Surfaces In Scope",
|
|
"Detailed Requirements"
|
|
]
|
|
},
|
|
{
|
|
"id": "F099",
|
|
"description": "Update accounting export repositories and adapters to continue mapping stable service-period fields after cutover",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"System Surfaces In Scope",
|
|
"Detailed Requirements"
|
|
]
|
|
},
|
|
{
|
|
"id": "F100",
|
|
"description": "Update internal docs, help text, and architecture references to describe the new recurring timing model and rollout defaults",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Detailed Requirements",
|
|
"Acceptance Criteria"
|
|
]
|
|
},
|
|
{
|
|
"id": "F101",
|
|
"description": "Define monthly contract-cadence semantics anchored to assignment start date",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Open Questions",
|
|
"Detailed Requirements"
|
|
]
|
|
},
|
|
{
|
|
"id": "F102",
|
|
"description": "Define quarterly contract-cadence semantics anchored to assignment start date",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Open Questions",
|
|
"Detailed Requirements"
|
|
]
|
|
},
|
|
{
|
|
"id": "F103",
|
|
"description": "Define semi-annual contract-cadence semantics anchored to assignment start date",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Open Questions",
|
|
"Detailed Requirements"
|
|
]
|
|
},
|
|
{
|
|
"id": "F104",
|
|
"description": "Define annual contract-cadence semantics anchored to assignment start date",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Open Questions",
|
|
"Detailed Requirements"
|
|
]
|
|
},
|
|
{
|
|
"id": "F105",
|
|
"description": "Define contract-cadence behavior for future-start assignments, renew-in-place, and renewed contracts",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Detailed Requirements",
|
|
"Risks"
|
|
]
|
|
},
|
|
{
|
|
"id": "F106",
|
|
"description": "Define first-invoice behavior for contract-cadence lines that start in the middle of an existing client billing cycle",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Detailed Requirements",
|
|
"Open Questions"
|
|
]
|
|
},
|
|
{
|
|
"id": "F107",
|
|
"description": "Define final-invoice behavior for contract-cadence lines that end in the middle of a generated contract-owned period",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Detailed Requirements",
|
|
"Open Questions"
|
|
]
|
|
},
|
|
{
|
|
"id": "F108",
|
|
"description": "Define invoice grouping rules when a client has both client-cadence and contract-cadence recurring lines due in the same window",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Detailed Requirements",
|
|
"Open Questions"
|
|
]
|
|
},
|
|
{
|
|
"id": "F109",
|
|
"description": "Define invoice grouping rules when mixed cadence-owner recurring lines are due in different windows or at different frequencies",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Detailed Requirements",
|
|
"Open Questions"
|
|
]
|
|
},
|
|
{
|
|
"id": "F110",
|
|
"description": "Update recurring billing selection and run logic to handle mixed cadence owners deterministically",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Implementation Sequence",
|
|
"Detailed Requirements"
|
|
]
|
|
},
|
|
{
|
|
"id": "F111",
|
|
"description": "Build a staged rollout plan that enables client-cadence parity before contract cadence",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Implementation Sequence",
|
|
"Risks"
|
|
]
|
|
},
|
|
{
|
|
"id": "F112",
|
|
"description": "Add DB-backed pre-cutover validation proving existing client-cadence recurring invoices remain unchanged under the new engine",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Implementation Sequence",
|
|
"Acceptance Criteria"
|
|
]
|
|
},
|
|
{
|
|
"id": "F113",
|
|
"description": "Add rollout controls or equivalent safety gates if needed to compare old and new recurring outputs before hard cutover",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Implementation Sequence",
|
|
"Risks"
|
|
]
|
|
},
|
|
{
|
|
"id": "F114",
|
|
"description": "Document and implement migration and backfill for cadence_owner defaults on existing recurring records",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Implementation Sequence",
|
|
"Detailed Requirements"
|
|
]
|
|
},
|
|
{
|
|
"id": "F115",
|
|
"description": "Add regression guardrails to keep time, usage, materials, and manual-only flows outside the first hard cutover",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Scope",
|
|
"Risks"
|
|
]
|
|
},
|
|
{
|
|
"id": "F116",
|
|
"description": "Remove live execution dependence on billing_cycle_alignment once parity and contract-cadence rollout are complete",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Implementation Sequence",
|
|
"Acceptance Criteria"
|
|
]
|
|
},
|
|
{
|
|
"id": "F117",
|
|
"description": "Remove obsolete recurring timing helpers, dead branches, and duplicated proration code after cutover",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Implementation Sequence",
|
|
"Acceptance Criteria"
|
|
]
|
|
},
|
|
{
|
|
"id": "F118",
|
|
"description": "Add source and DB-backed post-cutover validation proving recurring timing now flows through the canonical service-period model",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Acceptance Criteria",
|
|
"Implementation Sequence"
|
|
]
|
|
},
|
|
{
|
|
"id": "F119",
|
|
"description": "Add operator and developer runbooks for parity checks, mixed-cadence troubleshooting, and rollback posture",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Implementation Sequence",
|
|
"Acceptance Criteria"
|
|
]
|
|
},
|
|
{
|
|
"id": "F120",
|
|
"description": "Capture follow-on plan boundaries for full time-and-usage unification once materialized recurring service periods are established in v1",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Open Questions",
|
|
"Acceptance Criteria"
|
|
]
|
|
},
|
|
{
|
|
"id": "F121",
|
|
"description": "Update billing settings actions and types to surface cadence-owner defaults, rollout semantics, and compatibility boundaries where recurring defaults are configured",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"System Surfaces In Scope",
|
|
"Detailed Requirements"
|
|
]
|
|
},
|
|
{
|
|
"id": "F122",
|
|
"description": "Update billing cycle anchor actions and schedule-preview flows to coexist cleanly with explicit cadence ownership without implying that client cadence is universal",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"System Surfaces In Scope",
|
|
"Detailed Requirements"
|
|
]
|
|
},
|
|
{
|
|
"id": "F123",
|
|
"description": "Update contract line preset actions and preset models to persist cadence-owner defaults independently from billing_cycle_alignment",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"System Surfaces In Scope",
|
|
"Detailed Requirements"
|
|
]
|
|
},
|
|
{
|
|
"id": "F124",
|
|
"description": "Audit contract line mapping and disambiguation helpers so no recurring timing assumptions are inferred from legacy config flags after cutover",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"System Surfaces In Scope",
|
|
"Detailed Requirements"
|
|
]
|
|
},
|
|
{
|
|
"id": "F125",
|
|
"description": "Update invoice models, services, and repository readers so full invoice detail APIs expose canonical service-period data consistently",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"System Surfaces In Scope",
|
|
"Detailed Requirements"
|
|
]
|
|
},
|
|
{
|
|
"id": "F126",
|
|
"description": "Update invoice query and read actions used by dashboard and portal flows to preserve stable rendering semantics for canonical service periods",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"System Surfaces In Scope",
|
|
"Detailed Requirements"
|
|
]
|
|
},
|
|
{
|
|
"id": "F127",
|
|
"description": "Update accounting export repositories and mapping schemas to consume canonical service-period metadata directly rather than legacy recurring timing assumptions",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"System Surfaces In Scope",
|
|
"Detailed Requirements"
|
|
]
|
|
},
|
|
{
|
|
"id": "F128",
|
|
"description": "Update event schemas and billing workflow events that carry recurring invoice or billing detail so service-period-first semantics remain explicit and stable",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"System Surfaces In Scope",
|
|
"Detailed Requirements"
|
|
]
|
|
},
|
|
{
|
|
"id": "F129",
|
|
"description": "Update contract revenue, expiration, reconciliation, and invoice-summary reporting surfaces to use canonical service-period meaning where recurring timing matters",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"System Surfaces In Scope",
|
|
"Detailed Requirements"
|
|
]
|
|
},
|
|
{
|
|
"id": "F130",
|
|
"description": "Update client-portal billing metrics, remaining bucket unit actions, recent invoice readers, and line-detail actions to understand canonical service-period semantics",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"System Surfaces In Scope",
|
|
"Detailed Requirements"
|
|
]
|
|
},
|
|
{
|
|
"id": "F131",
|
|
"description": "Update purchase-order service and PO-related invoice selection behavior if recurring service-period changes affect PO-scoped invoice validation",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"System Surfaces In Scope",
|
|
"Detailed Requirements"
|
|
]
|
|
},
|
|
{
|
|
"id": "F132",
|
|
"description": "Update tax, external tax import, and tax reconciliation consumers if they rely on recurring service-period fields or charge timing assumptions",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"System Surfaces In Scope",
|
|
"Detailed Requirements"
|
|
]
|
|
},
|
|
{
|
|
"id": "F133",
|
|
"description": "Update invoice template preview, sample invoice data, and related demo data generation so canonical service-period fields render correctly during previews",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"System Surfaces In Scope",
|
|
"Detailed Requirements"
|
|
]
|
|
},
|
|
{
|
|
"id": "F134",
|
|
"description": "Update billing test helpers, pricing schedule helpers, and migration helpers to generate cadence-owner-aware recurring scenarios and parity fixtures",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Implementation Sequence",
|
|
"Detailed Requirements"
|
|
]
|
|
},
|
|
{
|
|
"id": "F135",
|
|
"description": "Add backfill verification that all existing recurring records receive client cadence defaults without mutating current invoice behavior",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Implementation Sequence",
|
|
"Acceptance Criteria"
|
|
]
|
|
},
|
|
{
|
|
"id": "F136",
|
|
"description": "Add explicit mixed-cadence validation at action, API, and UI layers for unsupported combinations during phased rollout",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Detailed Requirements",
|
|
"Risks"
|
|
]
|
|
},
|
|
{
|
|
"id": "F137",
|
|
"description": "Update contract line fixed-config models and services to stage billing_cycle_alignment deprecation in favor of cadence-owner and partial-period semantics",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"System Surfaces In Scope",
|
|
"Detailed Requirements"
|
|
]
|
|
},
|
|
{
|
|
"id": "F138",
|
|
"description": "Update template-authored recurring defaults and instantiation flows so cadence-owner defaults clone safely into instantiated contract lines",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"System Surfaces In Scope",
|
|
"Detailed Requirements"
|
|
]
|
|
},
|
|
{
|
|
"id": "F139",
|
|
"description": "Update billing dashboard overview, automatic invoices, prepayment invoices, and manual invoices tabs to explain and surface the new recurring semantics consistently",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"System Surfaces In Scope",
|
|
"Detailed Requirements"
|
|
]
|
|
},
|
|
{
|
|
"id": "F140",
|
|
"description": "Update client-portal payment and billing overview dialogs to render canonical service periods independently of old proration assumptions",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"System Surfaces In Scope",
|
|
"Detailed Requirements"
|
|
]
|
|
},
|
|
{
|
|
"id": "F141",
|
|
"description": "Audit company-sync, accounting mapping, and export validation services for service-period field assumptions affected by recurring timing changes",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"System Surfaces In Scope",
|
|
"Detailed Requirements"
|
|
]
|
|
},
|
|
{
|
|
"id": "F142",
|
|
"description": "Add systematic source cleanup for obsolete recurring timing terms in UI copy, docs, and implementation comments after cutover",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Implementation Sequence",
|
|
"Acceptance Criteria"
|
|
]
|
|
},
|
|
{
|
|
"id": "F143",
|
|
"description": "Add runtime guardrails preventing partial rollout states where some recurring charge families use new timing and others still use old timing on the same execution path",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Risks",
|
|
"Implementation Sequence"
|
|
]
|
|
},
|
|
{
|
|
"id": "F144",
|
|
"description": "Add regression protection for contract wizard resume and draft flows so cadence-owner and recurring timing defaults survive draft save and resume",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"System Surfaces In Scope",
|
|
"Risks"
|
|
]
|
|
},
|
|
{
|
|
"id": "F145",
|
|
"description": "Preserve end-exclusive query behavior and overlap semantics in billing-engine selection logic when service-period-first timing replaces legacy helper logic",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Detailed Requirements",
|
|
"Risks"
|
|
]
|
|
},
|
|
{
|
|
"id": "F146",
|
|
"description": "Add post-cutover source and database validation proving recurring outputs no longer depend on resolveServicePeriod or billing_cycle_alignment in live paths",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Acceptance Criteria",
|
|
"Implementation Sequence"
|
|
]
|
|
},
|
|
{
|
|
"id": "F147",
|
|
"description": "Capture explicit follow-on work for advanced service-period ledger extensions such as long-range materialization, archival, or performance-oriented denormalization if v1 materialization proves insufficient",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Open Questions",
|
|
"Risks"
|
|
]
|
|
},
|
|
{
|
|
"id": "F148",
|
|
"description": "Capture explicit follow-on work for time and usage unification if future product direction requires canonical service periods beyond recurring contract-backed charges",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Open Questions",
|
|
"Scope"
|
|
]
|
|
},
|
|
{
|
|
"id": "F149",
|
|
"description": "Document an operational runbook for investigating cadence-owner disputes, service-period mismatches, and mixed-cadence invoice questions",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Implementation Sequence",
|
|
"Acceptance Criteria"
|
|
]
|
|
},
|
|
{
|
|
"id": "F150",
|
|
"description": "Add a feature-to-subsystem mapping discipline in the plan artifacts so implementation progress stays traceable across runtime, invoices, APIs, UI, and downstream consumers",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Implementation Sequence",
|
|
"Acceptance Criteria"
|
|
]
|
|
},
|
|
{
|
|
"id": "F151",
|
|
"description": "Define a recurring-run execution identity separate from raw billingCycleId so client-cadence and contract-cadence work can both be scheduled deterministically",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Pass 5",
|
|
"Invoice and billing-flow requirements"
|
|
]
|
|
},
|
|
{
|
|
"id": "F152",
|
|
"description": "Define the job payload schema and selector inputs for choosing due recurring service periods in background invoice-generation flows",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Pass 5",
|
|
"Invoice and billing-flow requirements"
|
|
]
|
|
},
|
|
{
|
|
"id": "F153",
|
|
"description": "Define idempotency keys and retry semantics for recurring runs once due service periods rather than billingCycleId drive execution",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Pass 5",
|
|
"Invoice and billing-flow requirements"
|
|
]
|
|
},
|
|
{
|
|
"id": "F154",
|
|
"description": "Define comparison-mode execution identity and parity-trace metadata so legacy and canonical recurring outputs can be compared safely during rollout",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Implementation Sequence",
|
|
"Inventory and parity requirements"
|
|
]
|
|
},
|
|
{
|
|
"id": "F155",
|
|
"description": "Define schedulable due-work selection for client-cadence recurring obligations without assuming client cadence is the only recurring clock",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Pass 5",
|
|
"Invoice and billing-flow requirements"
|
|
]
|
|
},
|
|
{
|
|
"id": "F156",
|
|
"description": "Define schedulable due-work selection for contract-cadence recurring obligations before they enter invoice grouping",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Pass 7",
|
|
"Contract-cadence requirements"
|
|
]
|
|
},
|
|
{
|
|
"id": "F157",
|
|
"description": "Define invoice grouping rules that preserve single-contract invoice constraints when multiple due service periods are selected together",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Pass 5",
|
|
"Invoice and billing-flow requirements"
|
|
]
|
|
},
|
|
{
|
|
"id": "F158",
|
|
"description": "Define invoice grouping and split rules for purchase-order constrained recurring charges when due service periods coincide",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Pass 5",
|
|
"Invoice and billing-flow requirements"
|
|
]
|
|
},
|
|
{
|
|
"id": "F159",
|
|
"description": "Define invoice grouping and split rules for tax-source, currency, or export-shape constraints that prevent otherwise coincident recurring work from sharing one invoice",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Pass 5",
|
|
"Invoice and billing-flow requirements"
|
|
]
|
|
},
|
|
{
|
|
"id": "F160",
|
|
"description": "Define the operator-visible split policy and explainability metadata when one due window produces multiple invoices by design",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"UI and downstream-consumer requirements",
|
|
"Acceptance Criteria"
|
|
]
|
|
},
|
|
{
|
|
"id": "F161",
|
|
"description": "Define a stable projection contract between invoice parent charges and canonical invoice_charge_details for recurring lines",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Invoice and billing-flow requirements",
|
|
"Read-model and post-persist lifecycle requirements"
|
|
]
|
|
},
|
|
{
|
|
"id": "F162",
|
|
"description": "Update invoice model hydration paths to read and preserve canonical recurring detail periods instead of only parent invoice charge rows",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Read-model and post-persist lifecycle requirements",
|
|
"System Surfaces In Scope"
|
|
]
|
|
},
|
|
{
|
|
"id": "F163",
|
|
"description": "Update invoice query actions and API readers to expose canonical recurring detail periods without breaking existing invoice consumers",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Read-model and post-persist lifecycle requirements",
|
|
"Data model and API requirements"
|
|
]
|
|
},
|
|
{
|
|
"id": "F164",
|
|
"description": "Define fallback hydration behavior for historical invoices that lack canonical recurring detail rows",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Read-model and post-persist lifecycle requirements",
|
|
"Risks"
|
|
]
|
|
},
|
|
{
|
|
"id": "F165",
|
|
"description": "Define preview-row contracts for one charge mapping to one or many canonical recurring detail periods",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Pass 5",
|
|
"Read-model and post-persist lifecycle requirements"
|
|
]
|
|
},
|
|
{
|
|
"id": "F166",
|
|
"description": "Define invoice rendering-adapter flattening or expansion rules when canonical recurring detail periods cannot be shown one-to-one in the rendered output",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"UI and downstream-consumer requirements",
|
|
"Read-model and post-persist lifecycle requirements"
|
|
]
|
|
},
|
|
{
|
|
"id": "F167",
|
|
"description": "Define client-portal invoice detail projection rules for canonical recurring periods, including omission and flattening behavior where appropriate",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"UI and downstream-consumer requirements",
|
|
"Read-model and post-persist lifecycle requirements"
|
|
]
|
|
},
|
|
{
|
|
"id": "F168",
|
|
"description": "Define ordering, aggregation, and display rules when multiple canonical recurring periods contribute to one invoice charge or invoice view",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Read-model and post-persist lifecycle requirements",
|
|
"UI and downstream-consumer requirements"
|
|
]
|
|
},
|
|
{
|
|
"id": "F169",
|
|
"description": "Define invoice schema compatibility rules for old flat invoices and new detail-backed recurring invoices across shared interfaces and APIs",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Read-model and post-persist lifecycle requirements",
|
|
"Data model and API requirements"
|
|
]
|
|
},
|
|
{
|
|
"id": "F170",
|
|
"description": "Define workflow-event and audit-log payload updates needed when recurring truth lives on canonical detail periods instead of invoice headers alone",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Pass 5",
|
|
"Read-model and post-persist lifecycle requirements"
|
|
]
|
|
},
|
|
{
|
|
"id": "F171",
|
|
"description": "Replace header-period billed-through readers with detail-period billed-through readers for recurring invoice lifecycle enforcement",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Invoice and billing-flow requirements",
|
|
"Read-model and post-persist lifecycle requirements"
|
|
]
|
|
},
|
|
{
|
|
"id": "F172",
|
|
"description": "Define contract-line mutation guards against authoritative detail periods for edit, remove, pause, and replace operations",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Invoice and billing-flow requirements",
|
|
"Read-model and post-persist lifecycle requirements"
|
|
]
|
|
},
|
|
{
|
|
"id": "F173",
|
|
"description": "Define renewal and replacement behavior when historical recurring detail periods exist for the contract line being renewed or superseded",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Read-model and post-persist lifecycle requirements",
|
|
"Contract-cadence requirements"
|
|
]
|
|
},
|
|
{
|
|
"id": "F174",
|
|
"description": "Define end-date shortening and mid-cycle termination behavior against canonical due or partially covered service periods",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Runtime engine requirements",
|
|
"Read-model and post-persist lifecycle requirements"
|
|
]
|
|
},
|
|
{
|
|
"id": "F175",
|
|
"description": "Define deletion and cancellation safeguards when recurring detail periods already exist for not-yet-finalized or finalized invoices",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Read-model and post-persist lifecycle requirements",
|
|
"Risks"
|
|
]
|
|
},
|
|
{
|
|
"id": "F176",
|
|
"description": "Define how invoice recalculation preserves canonical recurring detail periods instead of treating them as derivable from invoice headers after persistence",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Read-model and post-persist lifecycle requirements",
|
|
"Invoice and billing-flow requirements"
|
|
]
|
|
},
|
|
{
|
|
"id": "F177",
|
|
"description": "Define how manual edits to recurring invoice charges preserve, merge, or invalidate canonical detail-period provenance",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Read-model and post-persist lifecycle requirements",
|
|
"Invoice and billing-flow requirements"
|
|
]
|
|
},
|
|
{
|
|
"id": "F178",
|
|
"description": "Define rerender, preview-refresh, and invoice-summary flows that consume canonical recurring detail periods after invoice persistence",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Read-model and post-persist lifecycle requirements",
|
|
"UI and downstream-consumer requirements"
|
|
]
|
|
},
|
|
{
|
|
"id": "F179",
|
|
"description": "Define percentage-discount and net-total recalculation semantics when recurring invoice lines are backed by canonical detail periods",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Dependent recurring behavior requirements",
|
|
"Read-model and post-persist lifecycle requirements"
|
|
]
|
|
},
|
|
{
|
|
"id": "F180",
|
|
"description": "Define zero-dollar invoice finalization behavior under service-period-first billing so recurring edge cases do not bypass canonical persistence rules",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Invoice and billing-flow requirements",
|
|
"Risks"
|
|
]
|
|
},
|
|
{
|
|
"id": "F181",
|
|
"description": "Define the manual-invoice policy for service-period fields, including whether manually entered lines remain intentionally periodless or can carry canonical periods",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Invoice and billing-flow requirements",
|
|
"Open Questions"
|
|
]
|
|
},
|
|
{
|
|
"id": "F182",
|
|
"description": "Define optional provenance rules when a manual invoice line is tied to a recurring contract line or service-period-backed obligation",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Invoice and billing-flow requirements",
|
|
"Read-model and post-persist lifecycle requirements"
|
|
]
|
|
},
|
|
{
|
|
"id": "F183",
|
|
"description": "Define prepayment invoice service-period semantics and whether prepayment artifacts carry null periods, financial-date periods, or explicit non-service markers",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Invoice and billing-flow requirements",
|
|
"Open Questions"
|
|
]
|
|
},
|
|
{
|
|
"id": "F184",
|
|
"description": "Define negative-invoice offset semantics relative to canonical recurring service periods when reversals affect future or prior recurring work",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Invoice and billing-flow requirements",
|
|
"Dependent recurring behavior requirements"
|
|
]
|
|
},
|
|
{
|
|
"id": "F185",
|
|
"description": "Define credit memo issuance metadata and date basis when source recurring invoices are detail-period-backed",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Invoice and billing-flow requirements",
|
|
"UI and downstream-consumer requirements"
|
|
]
|
|
},
|
|
{
|
|
"id": "F186",
|
|
"description": "Define credit application behavior and invariants when applied-to invoices or source invoices use canonical recurring detail periods",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Invoice and billing-flow requirements",
|
|
"Read-model and post-persist lifecycle requirements"
|
|
]
|
|
},
|
|
{
|
|
"id": "F187",
|
|
"description": "Define credit expiration and credit reconciliation date-basis rules after recurring timing no longer relies on invoice header periods alone",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Invoice and billing-flow requirements",
|
|
"UI and downstream-consumer requirements"
|
|
]
|
|
},
|
|
{
|
|
"id": "F188",
|
|
"description": "Define credit transfer, reporting, and audit behavior when credit lineage originates from canonical recurring detail periods",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"UI and downstream-consumer requirements",
|
|
"Read-model and post-persist lifecycle requirements"
|
|
]
|
|
},
|
|
{
|
|
"id": "F189",
|
|
"description": "Define dashboard and portal display policy for non-service financial artifacts so they remain understandable alongside canonical recurring service periods",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"UI and downstream-consumer requirements",
|
|
"Invoice and billing-flow requirements"
|
|
]
|
|
},
|
|
{
|
|
"id": "F190",
|
|
"description": "Define failure-handling and fallback semantics when financial artifacts lack canonical service-period metadata during staged coexistence",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Risks",
|
|
"Invoice and billing-flow requirements"
|
|
]
|
|
},
|
|
{
|
|
"id": "F191",
|
|
"description": "Define report-date-basis policy for each billing and finance reporting family, distinguishing invoice-header dates from canonical recurring service-period dates",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"UI and downstream-consumer requirements",
|
|
"Acceptance Criteria"
|
|
]
|
|
},
|
|
{
|
|
"id": "F192",
|
|
"description": "Split billing overview, analytics, and dashboard summary surfaces by their intended date basis so service-period-first cutover does not silently change meaning",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"UI and downstream-consumer requirements",
|
|
"Risks"
|
|
]
|
|
},
|
|
{
|
|
"id": "F193",
|
|
"description": "Define contract revenue, expiration, reconciliation, and invoice-summary reporting semantics when recurring periods come from canonical detail rows",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"UI and downstream-consumer requirements",
|
|
"Contract-cadence requirements"
|
|
]
|
|
},
|
|
{
|
|
"id": "F194",
|
|
"description": "Define financial analytics and service-metrics semantics when invoice dates and service-period dates diverge more often under mixed cadence ownership",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"UI and downstream-consumer requirements",
|
|
"Risks"
|
|
]
|
|
},
|
|
{
|
|
"id": "F195",
|
|
"description": "Define the authoritative accounting-export repository read contract for canonical recurring detail periods and legacy fallback invoices",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"UI and downstream-consumer requirements",
|
|
"Read-model and post-persist lifecycle requirements"
|
|
]
|
|
},
|
|
{
|
|
"id": "F196",
|
|
"description": "Define stored export-batch persistence semantics when batches contain historical flat invoices and new detail-backed recurring invoices",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"UI and downstream-consumer requirements",
|
|
"Read-model and post-persist lifecycle requirements"
|
|
]
|
|
},
|
|
{
|
|
"id": "F197",
|
|
"description": "Define export-batch replay, retry, reread, and dashboard-inspection behavior after canonical recurring detail periods become authoritative",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"UI and downstream-consumer requirements",
|
|
"Pass 8"
|
|
]
|
|
},
|
|
{
|
|
"id": "F198",
|
|
"description": "Define QuickBooks adapter rules for canonical recurring period ranges, single service dates, and null-period fallbacks",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"UI and downstream-consumer requirements",
|
|
"Acceptance Criteria"
|
|
]
|
|
},
|
|
{
|
|
"id": "F199",
|
|
"description": "Define Xero adapter rules for canonical recurring period ranges, description flattening, and null-period fallbacks",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"UI and downstream-consumer requirements",
|
|
"Acceptance Criteria"
|
|
]
|
|
},
|
|
{
|
|
"id": "F200",
|
|
"description": "Define internal tax, external tax import, and reconciliation consumer behavior when canonical recurring detail periods become available",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Dependent recurring behavior requirements",
|
|
"UI and downstream-consumer requirements"
|
|
]
|
|
},
|
|
{
|
|
"id": "F201",
|
|
"description": "Define one authoritative cadence-owner and timing-default policy across every recurring authoring path",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Authoring-path and storage-reconciliation requirements",
|
|
"Data model and API requirements"
|
|
]
|
|
},
|
|
{
|
|
"id": "F202",
|
|
"description": "Update contract-wizard write paths so cadence-owner and timing semantics persist consistently with the canonical recurring model",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Authoring-path and storage-reconciliation requirements",
|
|
"UI and downstream-consumer requirements"
|
|
]
|
|
},
|
|
{
|
|
"id": "F203",
|
|
"description": "Update contract-line dialog write paths so inline recurring edits persist cadence-owner and timing semantics consistently",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Authoring-path and storage-reconciliation requirements",
|
|
"UI and downstream-consumer requirements"
|
|
]
|
|
},
|
|
{
|
|
"id": "F204",
|
|
"description": "Update custom recurring-line creation flows so cadence-owner and timing defaults match all other authoring paths",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Authoring-path and storage-reconciliation requirements",
|
|
"UI and downstream-consumer requirements"
|
|
]
|
|
},
|
|
{
|
|
"id": "F205",
|
|
"description": "Update preset creation, preset editing, and preset reuse flows so they persist and replay canonical recurring cadence semantics",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Authoring-path and storage-reconciliation requirements",
|
|
"Data model and API requirements"
|
|
]
|
|
},
|
|
{
|
|
"id": "F206",
|
|
"description": "Update template-line authoring flows so cadence-owner, timing, and first-invoice semantics are authored explicitly at the template level when supported",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Authoring-path and storage-reconciliation requirements",
|
|
"UI and downstream-consumer requirements"
|
|
]
|
|
},
|
|
{
|
|
"id": "F207",
|
|
"description": "Update template-to-contract cloning so cadence-owner and recurring timing semantics propagate explicitly rather than through incidental field copies",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Authoring-path and storage-reconciliation requirements",
|
|
"Pass 6"
|
|
]
|
|
},
|
|
{
|
|
"id": "F208",
|
|
"description": "Define template-derived contract editing semantics after clone so future template edits do not create ambiguity about recurring cadence ownership on live lines",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Authoring-path and storage-reconciliation requirements",
|
|
"Risks"
|
|
]
|
|
},
|
|
{
|
|
"id": "F209",
|
|
"description": "Define authoring preview and explainer behavior for first invoice, proration replacement, and cadence-owner outcomes before the contract is saved",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"UI and downstream-consumer requirements",
|
|
"Authoring-path and storage-reconciliation requirements"
|
|
]
|
|
},
|
|
{
|
|
"id": "F210",
|
|
"description": "Define unsupported authoring combinations by line type, billing frequency, cadence owner, and timing mode with clear validation boundaries",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Data model and API requirements",
|
|
"Authoring-path and storage-reconciliation requirements"
|
|
]
|
|
},
|
|
{
|
|
"id": "F211",
|
|
"description": "Reconcile the authoritative recurrence-storage model across live contract lines, template lines, preset-backed flows, and shared billing interfaces",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Authoring-path and storage-reconciliation requirements",
|
|
"Data model and API requirements"
|
|
]
|
|
},
|
|
{
|
|
"id": "F212",
|
|
"description": "Add cadence_owner schema and backfill coverage for template-line storage surfaces if template authoring supports canonical recurrence semantics in v1",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Data model and API requirements",
|
|
"Authoring-path and storage-reconciliation requirements"
|
|
]
|
|
},
|
|
{
|
|
"id": "F213",
|
|
"description": "Add cadence_owner schema and backfill coverage for preset-backed or shared recurrence-default surfaces where those defaults must survive create-time propagation",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Data model and API requirements",
|
|
"Authoring-path and storage-reconciliation requirements"
|
|
]
|
|
},
|
|
{
|
|
"id": "F214",
|
|
"description": "Normalize billing_timing defaults across all recurring write paths before layering cadence-owner defaults on top",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Data model and API requirements",
|
|
"Risks"
|
|
]
|
|
},
|
|
{
|
|
"id": "F215",
|
|
"description": "Normalize legacy billing_cycle_alignment default mapping across all recurring write paths before deprecating it from execution",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Data model and API requirements",
|
|
"Cleanup requirements"
|
|
]
|
|
},
|
|
{
|
|
"id": "F216",
|
|
"description": "Remove repository and model write-path behavior that silently drops or inconsistently normalizes recurring cadence fields",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Authoring-path and storage-reconciliation requirements",
|
|
"Cleanup requirements"
|
|
]
|
|
},
|
|
{
|
|
"id": "F217",
|
|
"description": "Remove stale joins or reads against dropped recurrence-related tables before service-period-first implementation assumes a clean storage baseline",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Authoring-path and storage-reconciliation requirements",
|
|
"Cleanup requirements"
|
|
]
|
|
},
|
|
{
|
|
"id": "F218",
|
|
"description": "Remove stale documentation and model references to dropped term-storage tables or superseded recurrence-storage assumptions",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Authoring-path and storage-reconciliation requirements",
|
|
"Cleanup requirements"
|
|
]
|
|
},
|
|
{
|
|
"id": "F219",
|
|
"description": "Add compatibility readers and writers for partially migrated recurrence records across all authoring and read-model surfaces",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Data model and API requirements",
|
|
"Read-model and post-persist lifecycle requirements"
|
|
]
|
|
},
|
|
{
|
|
"id": "F220",
|
|
"description": "Document a source-of-truth matrix for every recurrence field across tables, repositories, actions, APIs, and UI surfaces",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Authoring-path and storage-reconciliation requirements",
|
|
"Acceptance Criteria"
|
|
]
|
|
},
|
|
{
|
|
"id": "F221",
|
|
"description": "Add source and DB validation proving live runtime no longer depends on dropped recurrence-related tables after cleanup lands",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Cleanup requirements",
|
|
"Acceptance Criteria"
|
|
]
|
|
},
|
|
{
|
|
"id": "F222",
|
|
"description": "Add source and DB validation proving authoritative recurring readers no longer fall back to invoice header periods when canonical detail periods exist",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Cleanup requirements",
|
|
"Acceptance Criteria"
|
|
]
|
|
},
|
|
{
|
|
"id": "F223",
|
|
"description": "Add source and DB validation proving contract-cadence execution paths are no longer blocked on billingCycleId-only scheduler assumptions",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Cleanup requirements",
|
|
"Contract-cadence requirements"
|
|
]
|
|
},
|
|
{
|
|
"id": "F224",
|
|
"description": "Define the staged cutover order for readers, writers, scheduler identity, and grouping rules so coexistence phases are explicit and safe",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Implementation Sequence",
|
|
"Risks"
|
|
]
|
|
},
|
|
{
|
|
"id": "F225",
|
|
"description": "Define the staged cutover order for reporting, portal, and accounting exports after the canonical recurring read-model contract lands",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Implementation Sequence",
|
|
"UI and downstream-consumer requirements"
|
|
]
|
|
},
|
|
{
|
|
"id": "F226",
|
|
"description": "Define rollback posture and coexistence expectations when historical flat invoices and canonical detail-backed invoices both remain queryable for a long period",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Risks",
|
|
"Open Questions"
|
|
]
|
|
},
|
|
{
|
|
"id": "F227",
|
|
"description": "Document an operational runbook for diagnosing projection mismatches between invoice header periods and canonical recurring detail periods",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Pass 8",
|
|
"Acceptance Criteria"
|
|
]
|
|
},
|
|
{
|
|
"id": "F228",
|
|
"description": "Document an operational runbook for diagnosing authoring-default drift across templates, presets, wizard flows, and custom recurring lines",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Pass 8",
|
|
"Authoring-path and storage-reconciliation requirements"
|
|
]
|
|
},
|
|
{
|
|
"id": "F229",
|
|
"description": "Capture a follow-on boundary for persisted recurring execution records if scheduler identity, retries, and operational traceability prove too implicit after v1 materialization",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Open Questions",
|
|
"Risks"
|
|
]
|
|
},
|
|
{
|
|
"id": "F230",
|
|
"description": "Capture a follow-on boundary for invoice-schema versioning if dual old-shape and new-shape invoice support becomes long-lived after rollout",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Open Questions",
|
|
"Read-model and post-persist lifecycle requirements"
|
|
]
|
|
},
|
|
{
|
|
"id": "F231",
|
|
"description": "Define the authoritative persisted service-period record shape for recurring billing, including identifiers, obligation linkage, cadence owner, boundaries, provenance, and lifecycle state",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Materialized service-period requirements",
|
|
"Data model and API requirements"
|
|
]
|
|
},
|
|
{
|
|
"id": "F232",
|
|
"description": "Add database schema, indexes, and integrity constraints for persisted recurring service-period records",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Materialized service-period requirements",
|
|
"Data model and API requirements"
|
|
]
|
|
},
|
|
{
|
|
"id": "F233",
|
|
"description": "Define the service-period lifecycle state model, including generated, edited, skipped, locked, billed, superseded, and archived states as applicable",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Materialized service-period requirements",
|
|
"Acceptance Criteria"
|
|
]
|
|
},
|
|
{
|
|
"id": "F234",
|
|
"description": "Define the persisted provenance model that distinguishes generated periods from user-edited periods and records why a period differs from source cadence rules",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Materialized service-period requirements",
|
|
"UI and downstream-consumer requirements"
|
|
]
|
|
},
|
|
{
|
|
"id": "F235",
|
|
"description": "Define the generation horizon and replenishment policy for future persisted recurring service periods",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Materialized service-period requirements",
|
|
"Implementation Sequence"
|
|
]
|
|
},
|
|
{
|
|
"id": "F236",
|
|
"description": "Generate persisted client-cadence service periods from existing recurring obligations under parity rules before invoice cutover",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Pass 2",
|
|
"Pass 3"
|
|
]
|
|
},
|
|
{
|
|
"id": "F237",
|
|
"description": "Generate persisted contract-cadence service periods from recurring obligations once contract-owned cadence is enabled",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Pass 2",
|
|
"Pass 8"
|
|
]
|
|
},
|
|
{
|
|
"id": "F238",
|
|
"description": "Define and implement the regeneration algorithm that refreshes future unedited service periods when source recurrence rules change",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Materialized service-period requirements",
|
|
"Pass 2"
|
|
]
|
|
},
|
|
{
|
|
"id": "F239",
|
|
"description": "Define and implement override-preservation rules so user-edited future service periods are not silently overwritten by regeneration",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Materialized service-period requirements",
|
|
"Risks"
|
|
]
|
|
},
|
|
{
|
|
"id": "F240",
|
|
"description": "Define billed-period and locked-period immutability rules, including which corrective flows are allowed after invoice linkage exists",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Materialized service-period requirements",
|
|
"Read-model and post-persist lifecycle requirements"
|
|
]
|
|
},
|
|
{
|
|
"id": "F241",
|
|
"description": "Link persisted service periods to resulting invoice detail rows so billed history can be traced back to explicit period records",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Materialized service-period requirements",
|
|
"Read-model and post-persist lifecycle requirements"
|
|
]
|
|
},
|
|
{
|
|
"id": "F242",
|
|
"description": "Define the due-selection query contract so invoice generation reads due persisted service periods rather than deriving periods on demand",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Materialized service-period requirements",
|
|
"Invoice and billing-flow requirements"
|
|
]
|
|
},
|
|
{
|
|
"id": "F243",
|
|
"description": "Define parity comparison between legacy derived timing outputs and persisted service-period schedules during staged cutover",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Inventory and parity requirements",
|
|
"Materialized service-period requirements"
|
|
]
|
|
},
|
|
{
|
|
"id": "F244",
|
|
"description": "Define backfill rules for initializing persisted future service periods from existing recurring lines without mutating billed history",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Materialized service-period requirements",
|
|
"Implementation Sequence"
|
|
]
|
|
},
|
|
{
|
|
"id": "F245",
|
|
"description": "Define the minimal v1 service-period edit operations supported for billing admins, including boundary adjustments",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Materialized service-period requirements",
|
|
"Open Questions"
|
|
]
|
|
},
|
|
{
|
|
"id": "F246",
|
|
"description": "Define and implement skip or defer operations for future persisted service periods",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Materialized service-period requirements",
|
|
"UI and downstream-consumer requirements"
|
|
]
|
|
},
|
|
{
|
|
"id": "F247",
|
|
"description": "Define whether split and merge operations for future persisted service periods are supported in v1 and how they behave if supported",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Materialized service-period requirements",
|
|
"Open Questions"
|
|
]
|
|
},
|
|
{
|
|
"id": "F248",
|
|
"description": "Define overlap, gap, and continuity validation rules when a user edits future persisted service periods",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Materialized service-period requirements",
|
|
"Data model and API requirements"
|
|
]
|
|
},
|
|
{
|
|
"id": "F249",
|
|
"description": "Define conflict handling when source-rule changes would invalidate or overlap user-edited future persisted service periods",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Materialized service-period requirements",
|
|
"Risks"
|
|
]
|
|
},
|
|
{
|
|
"id": "F250",
|
|
"description": "Define UI and API surfaces for listing persisted future service periods independently of invoice generation",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Materialized service-period requirements",
|
|
"UI and downstream-consumer requirements"
|
|
]
|
|
},
|
|
{
|
|
"id": "F251",
|
|
"description": "Define UI and API surfaces for editing future persisted service periods with explicit provenance and validation feedback",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Materialized service-period requirements",
|
|
"UI and downstream-consumer requirements"
|
|
]
|
|
},
|
|
{
|
|
"id": "F252",
|
|
"description": "Define UI affordances that show whether a persisted future service period is generated, edited, skipped, locked, billed, or superseded",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Materialized service-period requirements",
|
|
"UI and downstream-consumer requirements"
|
|
]
|
|
},
|
|
{
|
|
"id": "F253",
|
|
"description": "Define permissions and audit requirements for viewing, editing, skipping, regenerating, and correcting persisted service periods",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Materialized service-period requirements",
|
|
"Read-model and post-persist lifecycle requirements"
|
|
]
|
|
},
|
|
{
|
|
"id": "F254",
|
|
"description": "Define service-period regeneration triggers for contract-line edits, contract assignment edits, cadence-owner changes, and billing schedule changes",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Materialized service-period requirements",
|
|
"Authoring-path and storage-reconciliation requirements"
|
|
]
|
|
},
|
|
{
|
|
"id": "F255",
|
|
"description": "Define the cut line between source recurrence rules and materialized service-period overrides so product semantics stay understandable",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Materialized service-period requirements",
|
|
"Architecture Thesis"
|
|
]
|
|
},
|
|
{
|
|
"id": "F256",
|
|
"description": "Refactor recurring billing runtime to consume persisted service-period records as the authoritative schedule instead of deriving periods on demand in live paths",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Materialized service-period requirements",
|
|
"Runtime engine requirements"
|
|
]
|
|
},
|
|
{
|
|
"id": "F257",
|
|
"description": "Define dashboard and operational views that let billing staff inspect upcoming materialized service periods before invoice generation",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Materialized service-period requirements",
|
|
"UI and downstream-consumer requirements"
|
|
]
|
|
},
|
|
{
|
|
"id": "F258",
|
|
"description": "Define how materialized service periods participate in schedule previews and explainers before a contract line is saved",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Materialized service-period requirements",
|
|
"Authoring-path and storage-reconciliation requirements"
|
|
]
|
|
},
|
|
{
|
|
"id": "F259",
|
|
"description": "Define import, repair, or administrative regeneration flows for persisted service periods when data drift or failed generation occurs",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Materialized service-period requirements",
|
|
"Pass 9"
|
|
]
|
|
},
|
|
{
|
|
"id": "F260",
|
|
"description": "Define migration and coexistence rules for tenants that will have historical invoices without persisted period records and future schedules with them",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Materialized service-period requirements",
|
|
"Read-model and post-persist lifecycle requirements"
|
|
]
|
|
},
|
|
{
|
|
"id": "F261",
|
|
"description": "Define how recurring product, license, and fixed charge families each map onto persisted service-period records without diverging lifecycle semantics",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Materialized service-period requirements",
|
|
"Runtime engine requirements"
|
|
]
|
|
},
|
|
{
|
|
"id": "F262",
|
|
"description": "Define how bucket or allowance semantics interact with persisted service periods when users edit or skip future periods",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Materialized service-period requirements",
|
|
"Dependent recurring behavior requirements"
|
|
]
|
|
},
|
|
{
|
|
"id": "F263",
|
|
"description": "Define how materialized service periods affect billed-through, renewal, and replacement logic once due work no longer needs to be derived on demand",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Materialized service-period requirements",
|
|
"Read-model and post-persist lifecycle requirements"
|
|
]
|
|
},
|
|
{
|
|
"id": "F264",
|
|
"description": "Define how service-period editing interacts with contract templates, presets, and new recurring-line authoring so generated schedules remain predictable after creation",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Materialized service-period requirements",
|
|
"Authoring-path and storage-reconciliation requirements"
|
|
]
|
|
},
|
|
{
|
|
"id": "F265",
|
|
"description": "Define how invoice grouping and due selection respond when users edit future service periods in ways that move work across invoice windows",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Materialized service-period requirements",
|
|
"Invoice and billing-flow requirements"
|
|
]
|
|
},
|
|
{
|
|
"id": "F266",
|
|
"description": "Define how persisted service-period edits are surfaced in client-facing explanations, invoice detail provenance, and support tooling",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Materialized service-period requirements",
|
|
"UI and downstream-consumer requirements"
|
|
]
|
|
},
|
|
{
|
|
"id": "F267",
|
|
"description": "Add DB-backed validation proving persisted service-period generation, editing, regeneration, and invoice linkage remain coherent under staged rollout",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Materialized service-period requirements",
|
|
"Acceptance Criteria"
|
|
]
|
|
},
|
|
{
|
|
"id": "F268",
|
|
"description": "Document an operator runbook for materialized service-period generation failures, override conflicts, and regeneration troubleshooting",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Materialized service-period requirements",
|
|
"Pass 9"
|
|
]
|
|
},
|
|
{
|
|
"id": "F269",
|
|
"description": "Capture a follow-on boundary for richer service-period editing such as mass editing, advanced split and merge workflows, or bulk schedule transforms if v1 keeps edits narrower",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Open Questions",
|
|
"Materialized service-period requirements"
|
|
]
|
|
},
|
|
{
|
|
"id": "F270",
|
|
"description": "Capture a follow-on boundary for extending the materialized service-period ledger to time, usage, or other non-recurring billing domains after recurring cutover succeeds",
|
|
"implemented": true,
|
|
"prdRefs": [
|
|
"Open Questions",
|
|
"Scope"
|
|
]
|
|
}
|
|
]
|