# Changelog

Todas las versiones notables de `@wepos/sdk`. Sigue [SemVer](https://semver.org/lang/es/)
y el formato de [Keep a Changelog](https://keepachangelog.com/es-ES/).

## [1.4.1]

### Docs
- `ProvisionTenantInput.location`: se aclara que acepta **códigos** de Hacienda (recomendado) o los **nombres oficiales** de provincia/cantón/distrito (WePOS los resuelve al código). Antes el ejemplo mostraba nombres; ahora muestra códigos. (Corrige de raíz en el servidor la emisión con `<Provincia>Heredia</Provincia>` — un tenant provisionado con nombres se normaliza a códigos IGN al emitir.)

## [1.4.0]

### Added — Data keys por ambiente (Partner)

Resuelve el caso "un tenant se creó bajo la partner key **live** y no puedo emitir en sandbox": ahora se puede pedir una data key de cualquier ambiente para un tenant EXISTENTE, sin borrarlo ni recrearlo.

- `wepos.partner.tenants.issueKey(tenantId, { environment?, name?, scopes? })` — emite una nueva data key (`wpk_…`) para el tenant; `environment` default = el de la partner key. Pedí `environment: 'STAGING'` para obtener una `wpk_test_` y emitir en sandbox aunque el tenant se haya creado con una partner key live. El plaintext se devuelve **una sola vez**. Como el ambiente lo manda la data key (estilo Stripe), un mismo tenant puede tener keys de STAGING y PRODUCTION a la vez.
- `wepos.partner.tenants.listKeys(tenantId)` — lista las data keys del tenant (solo metadatos: id, nombre, prefijo, ambiente, scopes, uso; **nunca el secreto**).
- `wepos.partner.tenants.revokeKey(tenantId, keyId)` — revoca una data key (inmediato e irreversible).
- Endpoints REST nuevos: `GET`/`POST /api/v1/partner/tenants/{tenantId}/keys`, `DELETE .../keys/{keyId}`.
- Tipos nuevos exportados: `TenantApiKeyInfo`, `IssueKeyInput`, `IssuedKey`.

## [1.3.0]

### Added — Migración de consecutivos (Partner)

- `wepos.partner.tenants.getConsecutives(tenantId, environment?)` — lista los contadores de consecutivos del tenant por ambiente, con el próximo consecutivo (20 dígitos) de cada uno.
- `wepos.partner.tenants.setConsecutives(tenantId, { environment?, counters })` — fija el consecutivo de arranque cuando un negocio **migra desde otro sistema** (ej. venía en la FE 400 → `value: 400`, la próxima sale 401). Aplica todos los contadores de forma **atómica** (todo o nada) y es **monótono**: el nuevo valor debe ser ≥ el actual (un consecutivo nunca se reutiliza).
- Endpoints REST nuevos del plano de control: `GET`/`PATCH /api/v1/partner/tenants/{tenantId}/consecutives`.
- Tipos nuevos exportados: `ConsecutiveDocumentType`, `ConsecutiveCounter`, `SetConsecutivesInput`, `SetConsecutivesResult`.

## [1.2.1]

### Docs
- README: guía de integración **Partner** (backend fiscal embebido) — los dos tipos de credencial (`wppk_` vs `wpk_`), el flujo end-to-end (provisionar → configurar cert+credenciales por ambiente staging/prod → promover → emitir), tabla de métodos y notas de seguridad del `.p12`. (El código de la superficie partner ya venía en 1.2.0.)

## [1.2.0]

### Added — Partner (WePOS como backend fiscal embebido)

Superficie de plano de control para SaaS partner (se usa con una **partner key `wppk_…`**, no una key de tenant):

- `wepos.partner.tenants.create()` / `.list()` — aprovisionar y listar tenants desde el SaaS. Al crear se devuelve un `tenantApiKey` de datos para emitir por ese tenant.
- `wepos.partner.tenants.setCredentials()` / `.uploadCertificate()` — configurar credenciales ATV y subir el certificado (.p12 en base64) del tenant, **por ambiente (STAGING/PRODUCTION)**.
- `wepos.partner.tenants.get()` / `.update()` — leer la config fiscal + estado por ambiente (sin exponer secretos) y editar: promover el ambiente por defecto (STAGING→PRODUCTION) y/o reemplazar las actividades económicas.
- Tipos nuevos exportados: `ProvisionTenantInput`, `ProvisionedTenant`, `PartnerTenantSummary`, `SetCredentialsInput`, `UploadCertificateInput`, `TenantConfig`, `UpdateTenantConfigInput`.

## [1.1.0]

### Added
- `CreateInvoiceInput.activityCode` — elegir con cuál **actividad económica del emisor** se emite (CodigoActividadEmisor) cuando el emisor tiene varias. Si se omite, usa la principal.
- `CreateInvoiceInput.receptorActivityCode` — **actividad económica del receptor** (CodigoActividadReceptor, opcional v4.4). Combínalo con `reference.getTaxpayer()` para que el comprador elija entre sus actividades.

## [1.0.2]

### Changed
- README nivel enterprise: tabla de contenido, badges (versión, descargas, Node, tipos, licencia),
  sección **Obtener una API key** (se solicita en pos.wecodecr.com), requisitos/compatibilidad y
  Roadmap inline (sin enlaces relativos que fallaban en npm).
- Metadatos del paquete: `repository`, `author`, más `keywords`, y correo de soporte `support@wecodecr.com`.

## [1.0.1]

### Changed
- Documentación reescrita: características, cobertura de la API, manejo de errores y guía de DX.
- Añadidos `ROADMAP.md` (plan de evolución) y este `CHANGELOG.md`.

## [1.0.0]

### Added
- Cliente `WeposClient` con autenticación por API key y ambientes por prefijo (`wpk_test_` / `wpk_live_`).
- **Facturas**: `create`, `issueAndWait`, `get`, `list`, `getXml`, `createCreditNote`, `createDebitNote`, `export` (FEE).
- **Clientes**: `create`, `list`.
- **Catálogo**: `products.list`, `inventory.list`, `branches.list`.
- **Referencia Hacienda**: `getCabys`, `searchCabys`, `getTaxpayer`, `getExoneration`.
- DX: reintentos con backoff (429/5xx/red), timeouts, idempotencia, errores tipados (`WeposApiError`, `WeposTimeoutError`).
- Distribución dual ESM + CJS con tipos `.d.ts`. Cero dependencias en runtime.
- Script `gen:types` para regenerar tipos desde el OpenAPI vivo.