Changelog

v1.5 — 2026-08-06 (estado actual)

moneda en las respuestas ahora es el código ISO ("CRC" / "USD"), como siempre estuvo documentado y como se envía al emitir. Antes se devolvía el código interno ("01" / "02"): un integrador enviaba "CRC" y recibía "02". Si el código del integrador comparaba contra "01"/"02", debe ajustarse a "CRC"/"USD".

GET /api/v1/facturas/{clave}/respuesta — el XML de acuse firmado por Hacienda, que ya se guardaba pero no se podía descargar. También para factura de compra.
GET /api/v1/facturas-compra/{clave}/xml — no existía; únicamente estaba disponible el PDF.

Las notas de crédito y débito no se podían recuperar. La API las emitía, pero GET /facturas/{clave}, /pdf y /xml respondían 404: la búsqueda por clave solo consultaba las tablas de factura y tiquete. Ahora resuelve los cuatro tipos.

Mensaje receptor: POST /api/v1/mensajes-receptor y GET /api/v1/mensajes-receptor/{clave}. Aceptar, aceptar parcialmente o rechazar ante Hacienda la factura electrónica de un proveedor. Scopes nuevos: mensajes:write y mensajes:read.

El mensaje receptor se enviaba a Hacienda con el consecutivo vacío. Al migrar el procedimiento a PostgreSQL, el INSERT dejó de escribir numero_consecutivo, que es el campo que viaja como NumeroConsecutivoReceptor en el XML firmado. Afectaba al POS desde entonces; se corrigió en los 16 tenants antes de exponer el flujo por API.

Catálogo de productos: POST /api/v1/productos (upsert por el codigo propio del integrador) y GET /api/v1/productos/{codigo}.
Catálogo de clientes: POST /api/v1/clientes (upsert por identificacion, con actualización parcial) y GET /api/v1/clientes/{identificacion}.
Catálogos de códigos: GET /api/v1/catalogos/{medios-pago, condiciones-venta, unidades-medida, actividades, puntos-venta, tipos-codigo, marcas}. Las actividades económicas, los puntos de venta y las marcas son propios del tenant y antes no existía forma de consultarlos sin solicitarlos a LX Systems.
Alta de marcas: POST /api/v1/marcas, upsert por nombre.
Dos scopes nuevos: catalogo:write y catalogo:read. Ver Scopes.
idPuntoVenta opcional al emitir, tanto en ventas como en facturas de compra: fija de qué stock se descuenta la venta y qué sucursal o terminal llevan el consecutivo y la clave. Omitirlo mantiene el comportamiento de v1.2.

Los cachés en memoria se discriminaban por hostname. En el POS cada tenant entra por su subdominio, pero en la API todos entran por api.pos.lxsyscr.com, así que dos tenants compartían entrada de caché: un producto resuelto por codigoProducto —con su nombre, precio y CABYS— podía cruzarse de un tenant a otro y terminar en un comprobante fiscal ajeno. No llegó a ocurrir en producción (había una sola key emitida) y se corrigió antes de que existiera la segunda.
POST /api/v1/productos sobre un código existente respondía con el producto sin los cambios recién aplicados durante unos 30 segundos, aunque la base de datos sí quedaba correcta. Una emisión inmediata por codigoProducto tomaba también el precio anterior.
Un idMarca, idProveedor o tipoCodigo inexistente al guardar un producto respondía "No se pudo guardar el producto.", sin decir qué campo estaba mal. Ahora los tres se validan antes y el error nombra el campo y dónde consultar los valores válidos.

Emitir NC/ND ahora requiere el scope notas:write. Antes alcanzaba con facturas:write. Una key con facturas:write pero sin notas:write sigue emitiendo FE y TE sin problema, pero recibe 403 al enviar tipo: "NotaCredito" o "NotaDebito". La justificación de esta separación se detalla en Scopes.

Factura electrónica de compra (tipo 08) — la autofactura que se emite a nombre de un proveedor de régimen especial. Tres endpoints nuevos: POST /api/v1/facturas-compra, GET /api/v1/facturas-compra/{clave} y /pdf. Dos scopes nuevos: facturas-compra:write y facturas-compra:read.
El catálogo de scopes ahora se sirve como dato en vez de permanecer hardcodeado en la UI de administración — el CRM lo consume directamente desde esa fuente.

idUsuario es obligatorio en POST /api/v1/facturas. Identifica al usuario del tenant al que se atribuye el comprobante en los reportes del POS. Un request sin él responde 400.

Cliente por identificación (cliente.identificacion), con alta automática si no existe: ya no es necesario sincronizar ids internos antes de facturar. Ver FacturaApiClienteDto.
Producto por código de catálogo (linea.codigoProducto) como alternativa a idProducto. Ver FacturaApiLineaDto.
Base URL definitiva: https://api.pos.lxsyscr.com
tipo acepta tanto el nombre ("FacturaElectronica") como el código numérico.

Los comprobantes emitidos por la API no se enviaban a Hacienda: quedaban persistidos con clave y consecutivo, pero nunca se generaba ni firmaba el XML. Ahora la emisión encola el envío y el estado final llega por webhook como está documentado.
Una emisión fallida podía responder 201 con clave vacía. Ahora responde 400.