@fiado/type-kit 3.392.0 → 3.394.0

package/bin/account/dtos/BankAccountPocketTransferRequest.d.ts

@@ -1,5 +1,12 @@
 import { OperationEnum } from "../../transaction";
 import { PocketOperationTypeEnum } from "../enums/PocketOperationTypeEnum";
+/** Mismas keys que el additional_data de un service payment en CP. */
+export declare class PocketTransferMetadata {
+    provider?: string;
+    subcategory?: string;
+    service?: string;
+    referenceNumber?: string;
+}
 export declare class BankAccountPocketTransferRequest {
     externalAccountId: string;
     amount: number;
@@ -7,4 +14,5 @@ export declare class BankAccountPocketTransferRequest {
     operation: OperationEnum;
     operationType: PocketOperationTypeEnum;
     originalRelatedId?: string;
+    metadata?: PocketTransferMetadata;
 }

package/bin/account/dtos/BankAccountPocketTransferRequest.js

@@ -1,6 +1,10 @@
 "use strict";
 Object.defineProperty(exports, "__esModule", { value: true });
-exports.BankAccountPocketTransferRequest = void 0;
+exports.BankAccountPocketTransferRequest = exports.PocketTransferMetadata = void 0;
+/** Mismas keys que el additional_data de un service payment en CP. */
+class PocketTransferMetadata {
+}
+exports.PocketTransferMetadata = PocketTransferMetadata;
 class BankAccountPocketTransferRequest {
 }
 exports.BankAccountPocketTransferRequest = BankAccountPocketTransferRequest;

package/bin/remittance/dtos/RemittanceAddBeneficiaryRequest.d.ts

@@ -31,9 +31,10 @@ export declare class RemittanceAddBeneficiaryRequest {
     payerBranchCode?: string;
     address: RemittanceBeneficiaryAddressDTO;
     /**
-     * Additional fields requeridos por algunos payers (ej. `accountType` para Account Credit).
-     * Se pasan tal cual a UNIR como `additionalFieldInfo`. Los nombres/valores válidos vienen de
-     * GET /payers/{code}/fields (fieldName + fieldOptions). Opcional: Cash Pickup no los necesita.
+     * Additional fields de beneficiario requeridos por algunos payers (ej. `accountType` en
+     * Account Credit, identificación del remitente en algunos Cash Pickup). Se pasan tal cual
+     * a UNIR como `additionalFieldInfo`. Los nombres/valores válidos vienen de
+     * GET /payers/{code}/fields (fieldName + fieldOptions; para dropdowns se envía el `key`).
      */
     additionalFields?: RemittanceBeneficiaryAdditionalFieldDTO[];
 }

package/bin/remittance/dtos/RemittancePayerAdditionalFieldDto.d.ts

@@ -1,11 +1,13 @@
+import { RemittanceFieldBelongsTo } from "../enums/RemittanceFieldBelongsTo";
 /**
  * Campo adicional requerido por un payer/receptionMethod, devuelto por el
  * endpoint público `GET /remittance/payers/{code}/fields?...`.
  *
  * El frontend renderiza un control según `fieldType` y valida con `regex` /
  * `minLen`/`maxLen` antes de submit. El valor capturado se envía al backend
- * como `additionalFieldInfo: [{ name, value }, ...]` en la request de
- * AddBeneficiary o SendMoneyPreview.
+ * como `additionalFields: [{ name, value }, ...]` — en AddBeneficiary si
+ * `belongsTo` es BENEFICIARY, en SendPreview si es TRANSACTION. Para dropdowns
+ * el `value` enviado es el `key` de la opción, nunca el label.
  *
  * Ejemplo real (Banco Industrial GTQ Account Credit): 1 field `accountType`
  * dropdown con opciones { key:"01", value:"Checking" }, { key:"02", value:"Savings" }.
@@ -15,7 +17,10 @@ export interface RemittancePayerAdditionalFieldDto {
     fieldLabel: string;
     /** "dropdown" | "text" | "number" | etc. — UI elige control según este valor. */
     fieldType: string;
+    /** UNIR no manda flag: un campo presente en el catálogo del payer es requerido. */
     required: boolean;
+    /** Entidad a la que pertenece el campo. Ausente = BENEFICIARY (compat). */
+    belongsTo?: RemittanceFieldBelongsTo;
     /** Solo si `fieldType === "dropdown"`. */
     fieldOptions?: Array<{
         key: string;

package/bin/remittance/dtos/RemittancePayerDto.d.ts

@@ -12,6 +12,22 @@ import { ReceptionMethod } from "../enums/ReceptionMethod";
  *  3. Valide el `accNumber` del lado del cliente con `accNumberRegex` antes
  *     de hacer submit (mejor UX que esperar 400 del backend).
  */
+/**
+ * Detalle por reception method de un payer. UNIR reporta los flags, el regex de
+ * cuenta y el límite POR MÉTODO; los campos planos de `RemittancePayerDto` son
+ * un agregado payer-level que puede sobre-reportar (ej. `requiresAdditionalFields`
+ * es el OR entre métodos). La UI debe preferir este detalle cuando esté presente.
+ */
+export interface RemittancePayerReceptionMethodDetailDto {
+    method: ReceptionMethod;
+    requiresAdditionalFields: boolean;
+    requiresBranch: boolean;
+    /** Regex de validación del `accNumber` para este método (UNIR solo lo define en ACCOUNT_CREDIT). */
+    accNumberRegex?: string;
+    accNumberHelperText?: string;
+    /** Límite USD por transacción reportado por UNIR para este payer+método. */
+    txnLimit?: number;
+}
 export interface RemittancePayerDto {
     /** Código UNIR del payer (ej. "GCA10" Banrural). Usado como `payerCode` en AddBeneficiary. */
     payerCode: string;
@@ -31,4 +47,6 @@ export interface RemittancePayerDto {
     logoUrl?: string;
     /** Orden de aparición sugerido por UNIR (asc). */
     sortOrder?: number;
+    /** Detalle por método (flags/regex/límite reales de UNIR). Preferir sobre los campos planos. */
+    receptionMethodDetails?: RemittancePayerReceptionMethodDetailDto[];
 }

package/bin/remittance/enums/RemittanceFieldBelongsTo.d.ts

@@ -0,0 +1,8 @@
+/**
+ * A qué entidad pertenece un additional field del payer (UNIR `fieldBelongsTo`).
+ * BENEFICIARY viaja en AddBeneficiary; TRANSACTION viaja en el SendPreview de la transacción.
+ */
+export declare enum RemittanceFieldBelongsTo {
+    BENEFICIARY = "BENEFICIARY",
+    TRANSACTION = "TRANSACTION"
+}

package/bin/remittance/enums/RemittanceFieldBelongsTo.js

@@ -0,0 +1,12 @@
+"use strict";
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.RemittanceFieldBelongsTo = void 0;
+/**
+ * A qué entidad pertenece un additional field del payer (UNIR `fieldBelongsTo`).
+ * BENEFICIARY viaja en AddBeneficiary; TRANSACTION viaja en el SendPreview de la transacción.
+ */
+var RemittanceFieldBelongsTo;
+(function (RemittanceFieldBelongsTo) {
+    RemittanceFieldBelongsTo["BENEFICIARY"] = "BENEFICIARY";
+    RemittanceFieldBelongsTo["TRANSACTION"] = "TRANSACTION";
+})(RemittanceFieldBelongsTo || (exports.RemittanceFieldBelongsTo = RemittanceFieldBelongsTo = {}));

package/bin/remittance/enums/index.d.ts

@@ -23,3 +23,4 @@ export * from "./RuleOperator";
 export * from "./RuleActionType";
 export * from "./AuditResult";
 export * from "./RemittanceExceptionCode";
+export * from "./RemittanceFieldBelongsTo";

package/bin/remittance/enums/index.js

@@ -39,3 +39,4 @@ __exportStar(require("./RuleOperator"), exports);
 __exportStar(require("./RuleActionType"), exports);
 __exportStar(require("./AuditResult"), exports);
 __exportStar(require("./RemittanceExceptionCode"), exports);
+__exportStar(require("./RemittanceFieldBelongsTo"), exports);

package/package.json

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

package/src/account/dtos/BankAccountPocketTransferRequest.ts

@@ -1,6 +1,14 @@
 import { OperationEnum } from "../../transaction";
 import { PocketOperationTypeEnum } from "../enums/PocketOperationTypeEnum";
 
+/** Mismas keys que el additional_data de un service payment en CP. */
+export class PocketTransferMetadata {
+    provider?: string;
+    subcategory?: string;
+    service?: string;
+    referenceNumber?: string;
+}
+
 export class BankAccountPocketTransferRequest {
     externalAccountId!: string;
     amount!: number;
@@ -8,4 +16,5 @@ export class BankAccountPocketTransferRequest {
     operation: OperationEnum;
     operationType: PocketOperationTypeEnum;
     originalRelatedId?: string;
+    metadata?: PocketTransferMetadata;
 }

package/src/remittance/dtos/RemittanceAddBeneficiaryRequest.ts

@@ -92,9 +92,10 @@ export class RemittanceAddBeneficiaryRequest {
     address!: RemittanceBeneficiaryAddressDTO;
 
     /**
-     * Additional fields requeridos por algunos payers (ej. `accountType` para Account Credit).
-     * Se pasan tal cual a UNIR como `additionalFieldInfo`. Los nombres/valores válidos vienen de
-     * GET /payers/{code}/fields (fieldName + fieldOptions). Opcional: Cash Pickup no los necesita.
+     * Additional fields de beneficiario requeridos por algunos payers (ej. `accountType` en
+     * Account Credit, identificación del remitente en algunos Cash Pickup). Se pasan tal cual
+     * a UNIR como `additionalFieldInfo`. Los nombres/valores válidos vienen de
+     * GET /payers/{code}/fields (fieldName + fieldOptions; para dropdowns se envía el `key`).
      */
     @IsOptional()
     @ValidateNested({ each: true })

package/src/remittance/dtos/RemittancePayerAdditionalFieldDto.ts

@@ -1,11 +1,14 @@
+import { RemittanceFieldBelongsTo } from "../enums/RemittanceFieldBelongsTo";
+
 /**
  * Campo adicional requerido por un payer/receptionMethod, devuelto por el
  * endpoint público `GET /remittance/payers/{code}/fields?...`.
  *
  * El frontend renderiza un control según `fieldType` y valida con `regex` /
  * `minLen`/`maxLen` antes de submit. El valor capturado se envía al backend
- * como `additionalFieldInfo: [{ name, value }, ...]` en la request de
- * AddBeneficiary o SendMoneyPreview.
+ * como `additionalFields: [{ name, value }, ...]` — en AddBeneficiary si
+ * `belongsTo` es BENEFICIARY, en SendPreview si es TRANSACTION. Para dropdowns
+ * el `value` enviado es el `key` de la opción, nunca el label.
  *
  * Ejemplo real (Banco Industrial GTQ Account Credit): 1 field `accountType`
  * dropdown con opciones { key:"01", value:"Checking" }, { key:"02", value:"Savings" }.
@@ -15,7 +18,10 @@ export interface RemittancePayerAdditionalFieldDto {
     fieldLabel: string;
     /** "dropdown" | "text" | "number" | etc. — UI elige control según este valor. */
     fieldType: string;
+    /** UNIR no manda flag: un campo presente en el catálogo del payer es requerido. */
     required: boolean;
+    /** Entidad a la que pertenece el campo. Ausente = BENEFICIARY (compat). */
+    belongsTo?: RemittanceFieldBelongsTo;
     /** Solo si `fieldType === "dropdown"`. */
     fieldOptions?: Array<{ key: string; value: string }>;
     regex?: string;

package/src/remittance/dtos/RemittancePayerDto.ts

@@ -13,6 +13,23 @@ import { ReceptionMethod } from "../enums/ReceptionMethod";
  *  3. Valide el `accNumber` del lado del cliente con `accNumberRegex` antes
  *     de hacer submit (mejor UX que esperar 400 del backend).
  */
+/**
+ * Detalle por reception method de un payer. UNIR reporta los flags, el regex de
+ * cuenta y el límite POR MÉTODO; los campos planos de `RemittancePayerDto` son
+ * un agregado payer-level que puede sobre-reportar (ej. `requiresAdditionalFields`
+ * es el OR entre métodos). La UI debe preferir este detalle cuando esté presente.
+ */
+export interface RemittancePayerReceptionMethodDetailDto {
+    method: ReceptionMethod;
+    requiresAdditionalFields: boolean;
+    requiresBranch: boolean;
+    /** Regex de validación del `accNumber` para este método (UNIR solo lo define en ACCOUNT_CREDIT). */
+    accNumberRegex?: string;
+    accNumberHelperText?: string;
+    /** Límite USD por transacción reportado por UNIR para este payer+método. */
+    txnLimit?: number;
+}
+
 export interface RemittancePayerDto {
     /** Código UNIR del payer (ej. "GCA10" Banrural). Usado como `payerCode` en AddBeneficiary. */
     payerCode: string;
@@ -32,4 +49,6 @@ export interface RemittancePayerDto {
     logoUrl?: string;
     /** Orden de aparición sugerido por UNIR (asc). */
     sortOrder?: number;
+    /** Detalle por método (flags/regex/límite reales de UNIR). Preferir sobre los campos planos. */
+    receptionMethodDetails?: RemittancePayerReceptionMethodDetailDto[];
 }

package/src/remittance/enums/RemittanceFieldBelongsTo.ts

@@ -0,0 +1,8 @@
+/**
+ * A qué entidad pertenece un additional field del payer (UNIR `fieldBelongsTo`).
+ * BENEFICIARY viaja en AddBeneficiary; TRANSACTION viaja en el SendPreview de la transacción.
+ */
+export enum RemittanceFieldBelongsTo {
+    BENEFICIARY = "BENEFICIARY",
+    TRANSACTION = "TRANSACTION",
+}

package/src/remittance/enums/index.ts

@@ -23,3 +23,4 @@ export * from "./RuleOperator";
 export * from "./RuleActionType";
 export * from "./AuditResult";
 export * from "./RemittanceExceptionCode";
+export * from "./RemittanceFieldBelongsTo";