mirror of
https://github.com/Tria-plc/edr-platform.git
synced 2026-08-26 18:42:49 +00:00
c8b44d4d04
A station target's plan is per station AND per cargo type; the other two dimensions already carry the category inside dimension_key. update() kept whatever was stored whenever the payload omitted the key, and the admin form builds its payload from visible fields only — so switching "Plan by" away from Station left the old category behind on a row that no longer has any use for one. That row is not merely untidy. It survives the COALESCE(cargo_category,'') unique index alongside the legitimate null-category row for the same key, plannedRowsSql groups by the column, and the two plan rows then join the same operated row through the FULL OUTER JOIN: the category lists twice, each line carrying the full operated tonnage, while the summary tiles are computed separately and stay correct — so the table disagrees with its own totals and nothing says why. create() and update() now resolve the slot through one place, which is the point: the two paths cannot drift again. cargoCategory is derived from the effective dimension rather than carried over, and a station target without one is rejected instead of stored as a plan the report can never match. dimensionKey is checked against the vocabulary the reports actually emit — CARGO_CATEGORIES / CONTAINER_CLASSES, or live yards.code for stations. An unknown key used to store fine, list fine and fall back to showing the raw key, while being a plan no report would ever find. Also drops @Global from the module. Nothing outside it injects either service; the reports read both tables in raw SQL, so the docstring's stated reason for being global was not true.
28 lines
1.3 KiB
TypeScript
28 lines
1.3 KiB
TypeScript
import { Module } from '@nestjs/common';
|
|
import { TypeOrmModule } from '@nestjs/typeorm';
|
|
|
|
import { OperationsStandard } from './entities/operations-standard.entity';
|
|
import { OperationsTarget } from './entities/operations-target.entity';
|
|
import { OperationsStandardsController } from './operations-standards.controller';
|
|
import { OperationsStandardsService } from './operations-standards.service';
|
|
import { OperationsTargetsController } from './operations-targets.controller';
|
|
import { OperationsTargetsService } from './operations-targets.service';
|
|
|
|
/**
|
|
* Reference data behind the operations reports: the railway's operating
|
|
* standards (one settings row) and the planned targets the reports compare
|
|
* actuals against.
|
|
*
|
|
* Not global, and deliberately so: nothing outside this module injects either
|
|
* service. The reports read both tables in raw SQL — `STANDARDS_JOIN` and
|
|
* `plannedRowsSql` in `reports/operations-classification.ts` — so the exports
|
|
* below are for future callers, not current ones.
|
|
*/
|
|
@Module({
|
|
imports: [TypeOrmModule.forFeature([OperationsStandard, OperationsTarget])],
|
|
controllers: [OperationsStandardsController, OperationsTargetsController],
|
|
providers: [OperationsStandardsService, OperationsTargetsService],
|
|
exports: [OperationsStandardsService, OperationsTargetsService],
|
|
})
|
|
export class OperationsReportingModule {}
|