Customers created in the staff UI had no NUMid and so could not log in to my.jorgecuadros.com at all: the id is a CustomerLegacyRef row, not a column, and create() deliberately writes none. Allocation is a staff action (POST /customers/:id/portal-access, MANAGER) rather than part of create, because insurance is expected to move to the platform before utilities and an insurance-only customer has no reason to spend a utilities id. The audit that decides which ids are reusable took three passes. "Owns no rows" matches nobody -- migration gave all 1,171 NUMids a property and a transaction. "No transaction in N years" also matches nobody -- every customer carries a synthetic Jan-1 opening-balance row, so everyone looks active this year. Subtracting that row is what makes dormancy measurable, and it leaves 4 never-used ids and 10 dormant ones on dev. Two further traps are encoded in the queries: insurance/DATGRAL is a separate id space that reuses the sourceTable name and runs past 4,000, and ACCOUNT CANCELED is a transaction line type, not an account state -- all 8 customers carrying it have current-year activity. Recycling ships switched off (numid.recycleEmpty, default false). Every reusable id still exists in Access DATGRAL, and a --sync run reassigns refs with ON DUPLICATE KEY UPDATE customerId, so an id recycled before the utilities cutover is silently handed back to its Access owner. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
14 lines
456 B
TypeScript
14 lines
456 B
TypeScript
import { Module } from "@nestjs/common";
|
|
import { SettingsModule } from "../settings/settings.module";
|
|
import { CustomersController } from "./customers.controller";
|
|
import { CustomersService } from "./customers.service";
|
|
import { NumidService } from "./numid.service";
|
|
|
|
@Module({
|
|
imports: [SettingsModule],
|
|
controllers: [CustomersController],
|
|
providers: [CustomersService, NumidService],
|
|
exports: [NumidService],
|
|
})
|
|
export class CustomersModule {}
|