@fiado/type-kit 3.239.0 → 3.241.0

package/_test_/unit/retailOrg/dtos/validation/validationDtos.test.ts

@@ -27,6 +27,7 @@ describe('ValidationDtos (shapes mínimos de endpoints privados)', () => {
             storeId: 'store_001',
             retailerId: 'ret_001',
             zoneId: null,
+            zoneName: null,
             code: 'MTY-001',
             name: 'Sucursal Centro',
             status: StoreStatusEnum.ACTIVE,
@@ -41,6 +42,7 @@ describe('ValidationDtos (shapes mínimos de endpoints privados)', () => {
             cognitoSub: '5f7c8a90-1234-4abc-9def-0123456789ab',
             retailerId: 'ret_001',
             homeStoreId: 'store_001',
+            displayName: 'Vendedor Uno',
             employmentType: EmploymentTypeEnum.EMPLOYEE,
             commissionTier: 'TIER_A',
             status: RetailUserStatusEnum.ACTIVE,

package/bin/retailWizard/dtos/WizardBeneficiary.d.ts

@@ -3,9 +3,24 @@ import { BeneficiaryRelationEnum } from '../enums/BeneficiaryRelationEnum';
  * Beneficiario capturado en el paso 10 (bienvenida N2). Se envía a `IAccountBeneficiaryApi.create`
  * (expediente wallet Fiado). El cliente puede NO dar beneficiario (opcional en régimen simplificado N1).
  * SureKeep Fase 2 — pista Retail.
+ *
+ * 2026-07-28 (aditivo, retrocompatible): el front captura nombre/apellidos POR SEPARADO y el esquema
+ * del expediente (`beneficiary-business`) EXIGE `paternalLastName` — con solo `fullName` la
+ * información se perdía justo antes de donde se necesita (400 BULK_GROUP_CREATION_FAILED). Los
+ * campos separados son opcionales: un caller viejo que mande solo `fullName` sigue validando, y el
+ * adapter del wizard degrada con heurística documentada (DEC-BENEF-001).
  */
 export declare class WizardBeneficiary {
     fullName: string;
+    /** Nombre(s) de pila, sin apellidos. Preferir SIEMPRE sobre partir `fullName`. */
+    firstName?: string;
+    /** Apellido paterno — el esquema del expediente wallet lo exige. */
+    paternalLastName?: string;
+    maternalLastName?: string;
+    /** Fecha de nacimiento ISO (YYYY-MM-DD). */
+    dateOfBirth?: string;
+    /** Teléfono del beneficiario (el front ofrece "mismo teléfono que el titular"). */
+    phoneNumber?: string;
     relation: BeneficiaryRelationEnum;
     /** Porcentaje de asignación (1-100). Si hay un solo beneficiario, típicamente 100. */
     percentage?: number;

package/bin/retailWizard/dtos/WizardBeneficiary.js

@@ -17,6 +17,12 @@ const BeneficiaryRelationEnum_1 = require("../enums/BeneficiaryRelationEnum");
  * Beneficiario capturado en el paso 10 (bienvenida N2). Se envía a `IAccountBeneficiaryApi.create`
  * (expediente wallet Fiado). El cliente puede NO dar beneficiario (opcional en régimen simplificado N1).
  * SureKeep Fase 2 — pista Retail.
+ *
+ * 2026-07-28 (aditivo, retrocompatible): el front captura nombre/apellidos POR SEPARADO y el esquema
+ * del expediente (`beneficiary-business`) EXIGE `paternalLastName` — con solo `fullName` la
+ * información se perdía justo antes de donde se necesita (400 BULK_GROUP_CREATION_FAILED). Los
+ * campos separados son opcionales: un caller viejo que mande solo `fullName` sigue validando, y el
+ * adapter del wizard degrada con heurística documentada (DEC-BENEF-001).
  */
 class WizardBeneficiary {
 }
@@ -26,6 +32,36 @@ __decorate([
     (0, class_validator_1.IsString)(),
     __metadata("design:type", String)
 ], WizardBeneficiary.prototype, "fullName", void 0);
+__decorate([
+    (0, class_transformer_1.Expose)(),
+    (0, class_validator_1.IsOptional)(),
+    (0, class_validator_1.IsString)(),
+    __metadata("design:type", String)
+], WizardBeneficiary.prototype, "firstName", void 0);
+__decorate([
+    (0, class_transformer_1.Expose)(),
+    (0, class_validator_1.IsOptional)(),
+    (0, class_validator_1.IsString)(),
+    __metadata("design:type", String)
+], WizardBeneficiary.prototype, "paternalLastName", void 0);
+__decorate([
+    (0, class_transformer_1.Expose)(),
+    (0, class_validator_1.IsOptional)(),
+    (0, class_validator_1.IsString)(),
+    __metadata("design:type", String)
+], WizardBeneficiary.prototype, "maternalLastName", void 0);
+__decorate([
+    (0, class_transformer_1.Expose)(),
+    (0, class_validator_1.IsOptional)(),
+    (0, class_validator_1.IsISO8601)(),
+    __metadata("design:type", String)
+], WizardBeneficiary.prototype, "dateOfBirth", void 0);
+__decorate([
+    (0, class_transformer_1.Expose)(),
+    (0, class_validator_1.IsOptional)(),
+    (0, class_validator_1.IsString)(),
+    __metadata("design:type", String)
+], WizardBeneficiary.prototype, "phoneNumber", void 0);
 __decorate([
     (0, class_transformer_1.Expose)(),
     (0, class_validator_1.IsEnum)(BeneficiaryRelationEnum_1.BeneficiaryRelationEnum),

package/bin/retailWizard/events/SaleCompletedV1.d.ts

@@ -1,3 +1,4 @@
+import type { SaleTypeEnum } from '../enums/SaleTypeEnum';
 /**
  * Emitido al cerrar una venta (flujo 09). Se escribe al outbox transaccional en la MISMA
  * `TransactWriteItems` del cierre; drena a la cola Central + datalake. Solo identificadores
@@ -11,7 +12,23 @@ export interface SaleCompletedV1 {
     retailCustomerId: string;
     sku: string;
     imei: string | null;
+    /**
+     * Lo COBRADO en caja al cerrar (contrato histórico — La Central y comisión F4 lo asumen así).
+     * En contado == precio del equipo; en CREDIT es SOLO el enganche: desambiguar con `type` +
+     * `equipmentPriceCents`, NUNCA redefinir este campo.
+     */
     amountCents: number;
+    /**
+     * Eje financiero (aditivos 2026-07-28, opcionales para consumidores/eventos previos):
+     * sin `type` un crédito con $1,300 de enganche era indistinguible de un contado de $1,300.
+     */
+    type?: SaleTypeEnum;
+    /** Precio de lista del equipo; en contado coincide con `amountCents`. */
+    equipmentPriceCents?: number;
+    /** Enganche cobrado (solo `type=CREDIT`). */
+    downPaymentCents?: number;
+    /** Puntero al crédito SOFOM en loan-credit (solo `type=CREDIT`). */
+    creditId?: string;
     soldAt: string;
     occurredAt: string;
 }

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@fiado/type-kit",
-  "version": "3.239.0",
+  "version": "3.241.0",
   "description": "",
   "main": "bin/index.js",
   "types": "bin/index.d.ts",

package/src/retailWizard/dtos/WizardBeneficiary.ts

@@ -1,17 +1,52 @@
 import { Expose } from 'class-transformer';
-import { IsEnum, IsInt, IsOptional, IsString, Max, Min } from 'class-validator';
+import { IsEnum, IsInt, IsISO8601, IsOptional, IsString, Max, Min } from 'class-validator';
 import { BeneficiaryRelationEnum } from '../enums/BeneficiaryRelationEnum';
 
 /**
  * Beneficiario capturado en el paso 10 (bienvenida N2). Se envía a `IAccountBeneficiaryApi.create`
  * (expediente wallet Fiado). El cliente puede NO dar beneficiario (opcional en régimen simplificado N1).
  * SureKeep Fase 2 — pista Retail.
+ *
+ * 2026-07-28 (aditivo, retrocompatible): el front captura nombre/apellidos POR SEPARADO y el esquema
+ * del expediente (`beneficiary-business`) EXIGE `paternalLastName` — con solo `fullName` la
+ * información se perdía justo antes de donde se necesita (400 BULK_GROUP_CREATION_FAILED). Los
+ * campos separados son opcionales: un caller viejo que mande solo `fullName` sigue validando, y el
+ * adapter del wizard degrada con heurística documentada (DEC-BENEF-001).
  */
 export class WizardBeneficiary {
     @Expose()
     @IsString()
     fullName!: string;
 
+    /** Nombre(s) de pila, sin apellidos. Preferir SIEMPRE sobre partir `fullName`. */
+    @Expose()
+    @IsOptional()
+    @IsString()
+    firstName?: string;
+
+    /** Apellido paterno — el esquema del expediente wallet lo exige. */
+    @Expose()
+    @IsOptional()
+    @IsString()
+    paternalLastName?: string;
+
+    @Expose()
+    @IsOptional()
+    @IsString()
+    maternalLastName?: string;
+
+    /** Fecha de nacimiento ISO (YYYY-MM-DD). */
+    @Expose()
+    @IsOptional()
+    @IsISO8601()
+    dateOfBirth?: string;
+
+    /** Teléfono del beneficiario (el front ofrece "mismo teléfono que el titular"). */
+    @Expose()
+    @IsOptional()
+    @IsString()
+    phoneNumber?: string;
+
     @Expose()
     @IsEnum(BeneficiaryRelationEnum)
     relation!: BeneficiaryRelationEnum;

package/src/retailWizard/events/SaleCompletedV1.ts

@@ -1,3 +1,5 @@
+import type { SaleTypeEnum } from '../enums/SaleTypeEnum';
+
 /**
  * Emitido al cerrar una venta (flujo 09). Se escribe al outbox transaccional en la MISMA
  * `TransactWriteItems` del cierre; drena a la cola Central + datalake. Solo identificadores
@@ -11,7 +13,23 @@ export interface SaleCompletedV1 {
   retailCustomerId: string;
   sku: string;
   imei: string | null;
+  /**
+   * Lo COBRADO en caja al cerrar (contrato histórico — La Central y comisión F4 lo asumen así).
+   * En contado == precio del equipo; en CREDIT es SOLO el enganche: desambiguar con `type` +
+   * `equipmentPriceCents`, NUNCA redefinir este campo.
+   */
   amountCents: number;
+  /**
+   * Eje financiero (aditivos 2026-07-28, opcionales para consumidores/eventos previos):
+   * sin `type` un crédito con $1,300 de enganche era indistinguible de un contado de $1,300.
+   */
+  type?: SaleTypeEnum;
+  /** Precio de lista del equipo; en contado coincide con `amountCents`. */
+  equipmentPriceCents?: number;
+  /** Enganche cobrado (solo `type=CREDIT`). */
+  downPaymentCents?: number;
+  /** Puntero al crédito SOFOM en loan-credit (solo `type=CREDIT`). */
+  creditId?: string;
   soldAt: string;
   occurredAt: string;
 }