rmancinasandClaude Opus 5
7df928c3ab
Implements docs/RECEIPT_CAPTURE_SPEC.md §1, the legacy "Editor" replacement, on top of the single-movement capture from plan step 6. No new abilities: batching and resolving are both capturing. - outstanding (legacy NOPAGO): capture flag, ?outstanding= filter, and POST /billing/:id/resolve-outstanding (gated ledger:create, not ledger:void — resolving completes a capture rather than reversing one). Outstanding rows are excluded from every balance aggregate, matching the legacy SALDOS ULTIMO 0 query's HAVING NOPAGO = 0, but still count in the movement browser's filtered totals. - POST /billing/batch: many customers' receipts against one check, in one $transaction. Deliberately not a persisted batch entity — checkNumber is already a column and grouping by it answers every legacy by-check query. - GET /billing/by-check + a cheque-count report, replacing REPORTE CHEQUE COUNT / REPORTE POR CHEQUE / EDITA CHEQUE ALF|COUNT|NUM. Print, PDF, CSV and XLSX come free from the existing /reportes/:slug machinery. - Web: /estado-cuenta/lote (the Editor screen, with live reconciliation against the physical check amount), an "Estado de pago" filter, a "sin fondos" row tag and a Resolver dialog, plus a top-level "Captura" nav entry. Integration seam for the OCR auto-capture module (spec §2), which is required to post through createBatch rather than writing Transaction rows itself: items[i] maps to lines[i] so postedTransactionId can be zipped back on; opts.refs[i] stamps captureRef with a duplicate-post guard that a voided row deliberately does not block; opts.source is service-level only, so an HTTP client cannot label hand-keyed rows as machine-captured. captureSource/captureRef are nullable so the 40,136 migrated rows stay NULL rather than being mislabelled. Fixes two pre-existing bugs found while building this: - statement() filtered legacySourceTable with `notIn`, which compiles to SQL NOT IN — and `NULL NOT IN (...)` is NULL, so every app-captured movement was invisible on the customer statement (438 rows in the movement browser vs 392 on the statement) while showing everywhere else. This would have made the whole capture feature look broken. - The balances count query omitted the void filter its own page query applied, so the total disagreed with the rows. Nav highlighting now resolves by longest match; the previous first-startsWith logic lit up both the parent and any nested entry. Verified end-to-end against the dev DB, API and browser; all test rows removed afterwards. Also corrects RESUME.md, which documented the dev ports as :3001/:3000 — they are :4501/:4500, from the env files. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
86 lines
3.0 KiB
TypeScript
86 lines
3.0 KiB
TypeScript
import {
|
|
ArrayMaxSize,
|
|
ArrayMinSize,
|
|
IsArray,
|
|
IsBoolean,
|
|
IsEnum,
|
|
IsNumber,
|
|
IsOptional,
|
|
IsString,
|
|
MinLength,
|
|
ValidateNested,
|
|
} from "class-validator";
|
|
import { Type } from "class-transformer";
|
|
import { Currency, TransactionDomain } from "@jorgecuadros/database";
|
|
|
|
/**
|
|
* A new ledger movement. `amount` is signed: negative = cargo (charge),
|
|
* positive = abono (credit) — the module's sign convention. Booked movements
|
|
* are never edited; a mistake is corrected by voiding and re-capturing.
|
|
*/
|
|
export class CreateMovementDto {
|
|
@IsString() @MinLength(1) customerId!: string;
|
|
@IsEnum(TransactionDomain) domain!: TransactionDomain;
|
|
@IsNumber() amount!: number;
|
|
@IsString() @MinLength(1) transactionDate!: string;
|
|
|
|
@IsOptional() @IsEnum(Currency) currency?: Currency;
|
|
@IsOptional() @IsString() typeId?: string;
|
|
@IsOptional() @IsString() period?: string;
|
|
@IsOptional() @IsString() reference?: string;
|
|
@IsOptional() @IsString() checkNumber?: string;
|
|
@IsOptional() @IsString() message?: string;
|
|
/**
|
|
* Legacy "NOPAGO": the bill was captured but not actually paid (no funds).
|
|
* The row posts normally and stays visible, but is kept out of every balance
|
|
* aggregate until resolved — see BillingService's NOT_OUTSTANDING.
|
|
*/
|
|
@IsOptional() @IsBoolean() outstanding?: boolean;
|
|
}
|
|
|
|
/**
|
|
* Resolving an outstanding row: the check finally got cut, so the movement
|
|
* takes the resolution date and check number and starts counting toward the
|
|
* balance. Legacy behavior: "se actualiza registro con fecha del día y el
|
|
* cheque a pagar y quitas outstanding".
|
|
*/
|
|
export class ResolveOutstandingDto {
|
|
@IsString() @MinLength(1) checkNumber!: string;
|
|
@IsString() @MinLength(1) resolvedDate!: string;
|
|
}
|
|
|
|
/** One customer's line within a batch; check-level fields live on the parent. */
|
|
export class BatchLineDto {
|
|
@IsString() @MinLength(1) customerId!: string;
|
|
@IsNumber() amount!: number;
|
|
|
|
@IsOptional() @IsString() reference?: string;
|
|
@IsOptional() @IsString() period?: string;
|
|
@IsOptional() @IsString() message?: string;
|
|
@IsOptional() @IsBoolean() outstanding?: boolean;
|
|
}
|
|
|
|
/**
|
|
* Batch capture by check — the legacy "Editor" flow: key many customers'
|
|
* receipts against one check, then reconcile the captured total against the
|
|
* physical check. Deliberately NOT a persisted batch entity: `checkNumber` is
|
|
* already a column, and grouping by it answers every legacy by-check query.
|
|
*/
|
|
export class BatchCreateDto {
|
|
@IsEnum(TransactionDomain) domain!: TransactionDomain;
|
|
@IsString() @MinLength(1) transactionDate!: string;
|
|
@IsString() @MinLength(1) checkNumber!: string;
|
|
|
|
@IsOptional() @IsEnum(Currency) currency?: Currency;
|
|
@IsOptional() @IsString() typeId?: string;
|
|
|
|
// Capped so one request can't open a transaction over an unbounded row set;
|
|
// a physical check batch is tens of lines, not thousands.
|
|
@IsArray()
|
|
@ArrayMinSize(1)
|
|
@ArrayMaxSize(500)
|
|
@ValidateNested({ each: true })
|
|
@Type(() => BatchLineDto)
|
|
lines!: BatchLineDto[];
|
|
}
|