@cobre-npm/library-portal-core 0.60.0 → 0.62.0

package/README.md

@@ -387,6 +387,17 @@ the geo-flattened, unlabeled rows first and only attaches `label` to what matche
 never accepts `label` as a filter — unlike the other two `XQuery` types, this is enforced at the type level,
 not just by convention.
 
+Usages and validation types are exposed as **types only**, no runtime constant: write the literal and the
+union checks it (autocomplete included, a typo doesn't compile). That replaces the deprecated root's
+`DocumentTypeUsages.Business` / `DocumentTypeValidationTypes.Numeric`:
+
+```ts
+import type { DocumentTypeUsage, DocumentTypeValidationType } from "@cobre-npm/library-portal-core/documentTypes"
+
+queryDocumentTypes({ lang, usage: "business" })
+if (record.type === "numeric") { … }
+```
+
 ### `currencies`
 
 ```ts
@@ -677,6 +688,8 @@ import {
   so whoever reads the catalog fills it in and the column's type keeps one source of truth.
 - `ExportQuerySort` uses `field`; `ExportQueryFilter` uses `column` — not a typo, the engine's own DTOs
   name the two differently.
+- `field_date` is optional: the column id that `start_date` /
+  `end_date` filter on (`"transaction_date"`, `"movement_date"`, `"created_at"`, …).
 - `column_aggregations` is a required `boolean` (apply aggregations or don't), not a per-column map — the
   catalog's `aggregation: "sum"` markers describe what *can* be aggregated, not the request shape.
 - `language` is deliberately typed `string`, not `Locale`: the engine validates it against
@@ -696,15 +709,18 @@ import {
   type FinancialInstitutionOption, type FinancialInstitutionQuery,
 } from "@cobre-npm/library-portal-core/financialInstitutions"
 
-getFinancialInstitutions("en").pr_col_1007            // { code: "pr_col_1007", geo: "col", label: "Bancolombia" }
+getFinancialInstitutions("en").pr_col_1007            // { code: "pr_col_1007", rawCode: "1007", geo: "col", label: "Bancolombia" }
 queryFinancialInstitutions({ lang: "en", geo: "col" }) // FinancialInstitutionOption[]  → every COL institution
 ```
 
-- **institutions** (i18n): `getFinancialInstitutions(lang)`; each record carries `code`, `geo`
-  (`"col" | "mex"`) and `label`. One code per financial institution — a bank's code already encodes its
-  country (`pr_col_*` / `pr_mex_*`), so there is no repeat-by-geo the way `accounts/types` needs one.
+- **institutions** (i18n): `getFinancialInstitutions(lang)`; each record carries `code`, `rawCode`, `geo`
+  (`"col" | "mex"`) and `label`. The catalog is **keyed by `code`** (`pr_col_1007`, `pr_mex_40072`): that is
+  the `FinancialInstitution` union, the key into the locale files and the value the APIs and logos use.
+  `rawCode` is the bare bank code (`"1007"`), unique only within a `geo`; `code` is always
+  `pr_<geo>_<rawCode>` (a test enforces it). One entry per financial institution, so there is no
+  repeat-by-geo the way `accounts/types` needs one.
 - `queryFinancialInstitutions({ lang, ... })` returns the same catalog as a **list**, narrowed by
-  `code`/`geo` — same matching rules as [`queryAccountStatuses`](#accounts): `lang` is required (i18n
+  `code`/`rawCode`/`geo` — same matching rules as [`queryAccountStatuses`](#accounts): `lang` is required (i18n
   domain, no default) and lives inside the query object, and **a key that is present always filters** —
   `queryFinancialInstitutions({ lang: "en" })` returns everything, `queryFinancialInstitutions({ lang:
   "en", geo: "col" })` returns only Colombia's institutions.

package/dist/cjs/exports/interfaces/request.interface.d.ts

@@ -6,6 +6,7 @@ export interface ExportQueryConfig {
     timezone: string;
     start_date: string;
     end_date: string;
+    field_date?: string;
     columns: string[];
     column_aggregations: boolean;
     query_filters?: ExportQueryFilter[];