@fiado/type-kit 3.327.0 → 3.328.0

package/bin/transaction/dtos/Product.d.ts

@@ -7,4 +7,21 @@ export declare class Product {
     relatedProductId: string;
     targetRelatedProductId: string;
     originalRelatedId: string;
+    /**
+     * Id del producto de `ProductCatalog_GT` con el que se tarifo esta
+     * transaccion (ej. `SP_CASH_IN`, `SP_CASH_IN_OXXO`).
+     *
+     * POR QUE NO ALCANZA CON `type`/`subType`: esos dos describen la OPERACION,
+     * no el producto ni el proveedor. Un cash-in de SinergyPay se persiste con
+     * `type=EQ_CASH_SA` —el tipo de Equality, hardcodeado a proposito para que
+     * la UI aplique su template— asi que por ellos NO se distingue quien lo
+     * proceso ni con que tarifa. Este campo si: `SP_CASH_IN` (cuota fija) contra
+     * `SP_CASH_IN_OXXO` (porcentual) son productos distintos con cobros
+     * distintos.
+     *
+     * OPCIONAL y aditivo: las filas historicas no lo tienen, y ninguna que se
+     * cree sin el cambia de comportamiento. Cualquier consulta que lo use debe
+     * tolerar su ausencia.
+     */
+    productCatalogId?: string;
 }

package/bin/transaction/dtos/Product.js

@@ -42,3 +42,8 @@ __decorate([
     (0, class_validator_1.IsOptional)(),
     __metadata("design:type", String)
 ], Product.prototype, "originalRelatedId", void 0);
+__decorate([
+    (0, class_validator_1.IsString)(),
+    (0, class_validator_1.IsOptional)(),
+    __metadata("design:type", String)
+], Product.prototype, "productCatalogId", void 0);

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@fiado/type-kit",
-  "version": "3.327.0",
+  "version": "3.328.0",
   "description": "",
   "main": "bin/index.js",
   "types": "bin/index.d.ts",
@@ -28,4 +28,4 @@
     "class-validator": "^0.14.2",
     "reflect-metadata": "^0.2.2"
   }
-}
+}

package/src/transaction/dtos/Product.ts

@@ -23,4 +23,24 @@ export class Product {
     @IsString()
     @IsOptional()
     originalRelatedId: string;
+
+    /**
+     * Id del producto de `ProductCatalog_GT` con el que se tarifo esta
+     * transaccion (ej. `SP_CASH_IN`, `SP_CASH_IN_OXXO`).
+     *
+     * POR QUE NO ALCANZA CON `type`/`subType`: esos dos describen la OPERACION,
+     * no el producto ni el proveedor. Un cash-in de SinergyPay se persiste con
+     * `type=EQ_CASH_SA` —el tipo de Equality, hardcodeado a proposito para que
+     * la UI aplique su template— asi que por ellos NO se distingue quien lo
+     * proceso ni con que tarifa. Este campo si: `SP_CASH_IN` (cuota fija) contra
+     * `SP_CASH_IN_OXXO` (porcentual) son productos distintos con cobros
+     * distintos.
+     *
+     * OPCIONAL y aditivo: las filas historicas no lo tienen, y ninguna que se
+     * cree sin el cambia de comportamiento. Cualquier consulta que lo use debe
+     * tolerar su ausencia.
+     */
+    @IsString()
+    @IsOptional()
+    productCatalogId?: string;
 }