Descarga el contenido de un campo binario de cualquier modelo del ERP. A diferencia del resto de endpoints, es de tipo http: los parámetros van en los segmentos de la ruta (no en el body JSON) y la respuesta es el archivo binario directamente, sin envelope JSON-RPC, con headers Content-Type: application/octet-stream y Content-Disposition: attachment; filename=<nombre>. El ERP decodifica el base64 almacenado en el campo y entrega los bytes originales del archivo.

El último segmento (file_name) define el nombre del archivo: si coincide con un campo del registro (ej. number en una factura), se usa el valor de ese campo; en caso contrario se usa el texto literal del segmento. Si el registro no existe, el campo no existe o está vacío, responde 404 Not Found.

Devuelve el diccionario de campos de un modelo del ERP: nombre técnico (name), etiqueta (field_description), tipo (ttype), texto de ayuda (help), si se almacena en base de datos (store) y, para campos relacionales, el modelo destino (relation). Es el complemento natural de los endpoints genéricos /integration/api/query, /integration/api/create y /integration/api/update: permite conocer qué campos existen y de qué tipo son antes de leerlos o escribirlos.

Si falta model responde R001; si el modelo no existe en el ERP responde R002.

Webhook público que consume el proveedor de firma digital (Viafirma) para notificar al ERP los cambios de estado de un set de firmas. Al recibir la notificación, el ERP localiza la solicitud de firma (signature.request) por su set_code, actualiza el estado global del set y el de cada uno de sus documentos; cuando un documento queda firmado (estado RESPONSED), se descarga y almacena automáticamente el PDF firmado.

Usa autenticación public (no requiere token) porque es el proveedor externo quien invoca la URL como callback de sus procesos de firma; no está pensado para ser consumido directamente por integraciones de terceros. La respuesta exitosa devuelve únicamente status_code 00, sin payload adicional.

Verifica la conectividad con el servidor del ERP. No requiere autenticación y no recibe parámetros; es el primer paso recomendado al configurar una integración.

Crea un usuario del sistema (res.users) a partir de sus datos de identificación. Si ya existe un tercero (res.partner) con el mismo vat, el usuario se asocia a ese tercero; de lo contrario, el ERP crea primero el tercero como persona natural con facturación electrónica habilitada, componiendo el nombre completo a partir de nombres y apellidos. El login del usuario creado es el número de identificación (vat).

Si el tercero ya tiene un usuario del sistema asociado responde R005 indicando la identificación y el nombre. Requiere habilitación por compañía (política api_allow_user); si el servicio no está habilitado responde R009. Si falta un campo requerido responde R001; si el tipo de documento o la ciudad no existen responde R002; si un valor tiene un tipo inválido responde R003.

Verifica que el token JWT enviado en el header X-Access-Token sea válido y vigente. Útil para diagnosticar problemas de autenticación sin ejecutar operaciones de negocio.

Autentica al usuario de integración y devuelve un token JWT válido por 8 horas. El token debe enviarse en el header X-Access-Token de todas las peticiones protegidas.

Si el usuario o la api_key no se envían, responde A001; si las credenciales no son válidas, responde A002.

Crea uno o varios terceros (res.partner). Según los flags enviados puede crear también el paciente asociado (vertical salud) y/o el usuario del sistema.

Cuando is_customer es verdadero, el ERP aplica la parametrización comercial definida en la configuración API de la compañía (vendedor, lista de precios, plazo de pago, cuentas contables, obligaciones tributarias). Si falta alguna de esas parametrizaciones, responde R004 indicando el campo faltante.

Consulta un tercero por su número de identificación y devuelve sus datos básicos: identificación, tipo de documento, nombre, contacto, condición de cliente, lista de precios y ubicación.

Si no existe un tercero con ese vat, responde R002.

Consulta el estado de los procesos de facturación asíncrona encolados con /integration/api/invoice/async. Para los procesos que ya generaron factura, la respuesta incluye además número, estado contable y estado de facturación electrónica.

Crea y procesa facturas de venta de forma síncrona: la respuesta llega cuando todas las facturas del lote terminaron de procesarse. Para lotes grandes o flujos de alto volumen use /integration/api/invoice/async.

Cada factura del lote se procesa de forma independiente: las válidas se devuelven en response y las fallidas en novelty. Si al menos una falla, el status_code del lote es 99.

Encola facturas para procesamiento asíncrono por colas de trabajo y responde de inmediato con los identificadores de los procesos encolados. Es la opción recomendada para lotes grandes o integraciones de alto volumen.

El estado de cada proceso se consulta con /integration/api/async/read usando los async_id devueltos. Si la compañía tiene configurado un callback de facturación asíncrona, el ERP notificará el resultado a la URL parametrizada.

Devuelve la representación gráfica (PDF) de las facturas indicadas, codificada en base64. Si alguna factura no puede generar su representación gráfica, responde R008 con el detalle.

Consulta facturas por número y devuelve su estado contable, estado de facturación electrónica y CUFE. Opcionalmente adjunta el XML y/o el PDF de la factura electrónica en base64.

Envía por correo electrónico la factura indicada con sus adjuntos de facturación electrónica (XML y PDF), usando la plantilla de correo de facturación electrónica del ERP.

Devuelve el XML de facturación electrónica de las facturas indicadas, codificado en base64.

Registra y publica un recaudo (account.payment de tipo entrada) aplicado a una única factura de venta abierta. El pago se concilia contra la línea por cobrar de la factura y, si la compañía tiene habilitada la conciliación bancaria automática, crea además la partida bancaria por identificar con la referencia enviada.

El endpoint es idempotente por transaction_id (máximo 12 caracteres): un valor repetido en un recaudo no cancelado responde R005. Validaciones de negocio con código R003: la factura debe ser de venta y estar abierta, la fecha debe estar dentro del mes en curso y no ser futura, el monto debe ser positivo sin superar el saldo de la factura y la moneda debe ser COP. Para aplicar discount la compañía debe tener parametrizadas la cuenta y la analítica de descuentos financieros y el cliente debe tener franjas de descuento configuradas (responde R004 si falta parametrización); el porcentaje debe coincidir con una franja vigente según los días de la factura y no se admiten descuentos sobre facturas parcialmente conciliadas. Consulte las franjas disponibles con /integration/api/partner/discount.

Requiere habilitación por compañía (responde R009 si no está activo). R001/R002 aplican para campos faltantes o registros inexistentes y R008 para errores internos durante la generación del recaudo.

Registra y publica un recaudo aplicado a varias facturas del mismo cliente en una sola operación. El body lleva los datos de cabecera y una lista lines; cada línea referencia una factura por su número (invoice) con el valor a aplicar (amount) y admite una lista opcional discounts con ajustes o descuentos por concepto de conciliación (concept, name, amount).

Cada factura se localiza como apunte por cobrar contabilizado, sin conciliar, con saldo pendiente y fecha menor o igual a date (responde R003 si no se encuentra). El valor de cada línea no puede superar el saldo de su factura ni diferir en moneda, y el total de cabecera debe cuadrar: suma de líneas menos suma de descuentos (R003 en caso contrario). Cuando el concepto del descuento exige contabilidad analítica, o la compañía la requiere en pagos, esta se toma de la primera línea de la factura. El endpoint es idempotente por transaction_id y, si la compañía tiene habilitada la conciliación bancaria automática, crea la partida bancaria por identificar con las referencias enviadas.

Requiere habilitación por compañía (responde R009 si no está activo). R001/R002 aplican para campos faltantes o registros inexistentes y R008 para errores internos durante la generación del recaudo.

Ejecuta el ciclo completo de cierre de una orden de venta pagada: entrega el picking pendiente asociado, genera y valida la factura, crea el recaudo en el diario indicado, lo contabiliza y marca la orden como pagada (payment_integration_check). Al final intenta emitir la factura electrónica; si el envío a la DIAN falla, la operación contable ya quedó en firme y el campo message de la respuesta lo indica. Requiere habilitación por compañía (api_allow_sale); si no está activa responde R009.

La operación es transaccional: cualquier falla durante la entrega, la facturación o el recaudo revierte todo el proceso y responde R008. Otros códigos de error: R005 si la orden ya fue pagada por este canal, no está en estado "Pedido de venta" o ya tiene facturas asociadas; R003 si la fecha es anterior a hoy o el monto no coincide con el total de la orden; R002 si no existe un picking pendiente para la orden o hay más de uno; R001 si falta un campo requerido.

Consulta la política de descuentos financieros por pronto pago configurada para un cliente. Devuelve el indicador apply_discount (si el cliente tiene activa la novedad de descuento en ventas) y la lista discount_ids con las franjas parametrizadas: porcentaje de descuento y ventana de días (from / to) en la que aplica. Es la consulta previa recomendada antes de enviar el parámetro discount en /integration/api/account-payment.

Requiere que el servicio de recaudos esté habilitado para la compañía (comparte la habilitación de account-payment; responde R009 si no está activo). Responde R001 si no se envía partner_vat y R002 si el cliente no existe.

Devuelve el detalle completo de una configuración de archivo plano bancario de la central DrivErp, identificada por config_id o por bank_code (es obligatorio enviar al menos uno). Además de los datos generales (banco, código BIC, tipo de archivo, delimitador y codificación), retorna la estructura del archivo en tres secciones ordenadas por secuencia — header_lines, body_lines y footer_lines — donde cada campo define su contenido, tipo de contenido (plain, context o python), tamaño, ajuste a tamaño, alineación y carácter de relleno; y la lista variables con las variables auxiliares de la configuración.

No requiere habilitación por compañía; basta con un token válido. Códigos de error propios de este endpoint: E002 si no se envía ni config_id ni bank_code, E003 si no existe un banco con el BIC indicado, E004 si la configuración no se encuentra y E005 ante un error interno.

Devuelve la lista de configuraciones de archivos planos bancarios (payment.file.config) disponibles en la instancia central de DrivErp. Está pensado para que las instancias cliente sincronicen la parametrización de dispersión de pagos sin configurarla manualmente. Por cada configuración retorna el banco asociado (par [id, nombre]), su código BIC (bank_code), el tipo de archivo (txt o csv), el delimitador (coma o punto_coma) y la codificación (utf-8 o ANSI). Para obtener la estructura completa de un archivo use /integration/api/payment-file-config/detail.

No recibe parámetros en el body (enviar un objeto vacío) y no requiere habilitación por compañía; basta con un token válido. Un error interno al consultar las configuraciones responde código R009 con el detalle.

Registra anticipos de clientes como asientos contables publicados. El body recibe una lista advances (responde R001 si viene vacía) y crea un asiento por cada elemento: debita la cuenta por defecto del diario de banco/efectivo y acredita la cuenta del cliente — la cuenta por cobrar o la cuenta de anticipos, según la parametrización api_advance_account_source de la compañía. Un amount negativo invierte el sentido del asiento, lo que permite registrar la aplicación o devolución del anticipo. El endpoint es idempotente por transaction_id: un valor ya registrado devuelve el asiento existente en lugar de duplicarlo.

Requiere habilitación por compañía (responde R009 si no está activo). Otros códigos de error: R002 si el cliente, el diario o el usuario no existen; R003 si el diario no es de tipo banco/efectivo o maneja moneda extranjera; R004 si el diario no tiene cuenta débito por defecto o el cliente no tiene parametrizada la cuenta crédito correspondiente; y R008 si falla la creación o publicación del asiento.

Registra la reversión de anticipos de clientes creados con /integration/api/advance. El body recibe una lista advances (responde R001 si viene vacía) y genera un asiento contable publicado por cada elemento, entre la cuenta por defecto del diario y la cuenta del cliente — la cuenta por cobrar o la cuenta de anticipos, según la parametrización api_advance_account_source de la compañía. Las líneas del asiento conservan el número del anticipo como nombre y la identificación del cliente como referencia 2, de modo que la reversión quede cruzada con el anticipo original.

A diferencia de la creación de anticipos, este endpoint no valida el tipo del diario ni maneja transaction_id, por lo que reenvíos de la misma petición generan asientos adicionales. Requiere habilitación por compañía (responde R009 si no está activo). Otros códigos de error: R002 si el cliente o el diario no existen, R004 si el cliente no tiene parametrizada la cuenta correspondiente y R008 si falla la creación o publicación del asiento.

Consulta la cartera (cuentas por cobrar) de un tercero a partir de sus apuntes contables publicados en cuentas de tipo por cobrar. Los apuntes se agrupan por documento: cada elemento de la respuesta incluye el número del documento (invoice), el ID de la factura asociada (invoice_id), la fecha de vencimiento (exp_date), el detalle de saldos por cuenta contable (accounts, con account, code y residual) y el saldo total pendiente (total_residual, suma de los saldos por cuenta). Requiere habilitación por compañía: si el servicio no está activo responde R009.

Un partner_vat inexistente responde R002; invoices con un tipo distinto a lista responde R003. Los documentos con saldo en cero se incluyen salvo que se envíe ignore_zero en true.

Consulta la cartera de un tercero con el detalle de cada factura y el cálculo del descuento financiero por pronto pago. Por cada apunte contable publicado en cuentas por cobrar asociado a una factura, la respuesta incluye número y ID de la factura, fechas de emisión y vencimiento, subtotal, impuestos y total, el saldo pendiente (total_residual) y los campos de descuento: discount_percent, discount_value y total_inc_discount (saldo a pagar aplicando el descuento). Requiere habilitación por compañía: si el servicio no está activo responde R009.

El descuento se toma de los acuerdos de descuento financiero del tercero según los días transcurridos: dependiendo de la política de la compañía se cuentan desde la fecha de la factura o los días restantes hasta el vencimiento, buscando el rango de días aplicable en el acuerdo. Solo aplica sobre facturas sin abonos parciales (saldo igual al total); si la factura ya tiene pagos parciales o el descuento supera el saldo, los tres campos de descuento retornan 0. Un partner_vat inexistente responde R002 e invoices con un tipo distinto a lista responde R003.

Crea y publica uno o varios asientos contables. El body recibe una lista moves; cada asiento lleva sus datos de cabecera (journal_code, date, ref, transaction_id) y una lista lines con las líneas contables. Los asientos quedan contabilizados de inmediato.

La contabilidad analítica (contract, uep, analytic) solo es exigida en líneas cuya cuenta sea de resultado (clase distinta de Activo, Pasivo o Patrimonio). Si la cuenta del diario está marcada como banco/efectivo, la fecha de consignación de la línea se fija con la fecha del asiento. El endpoint es idempotente por transaction_id: un valor ya registrado devuelve el asiento existente en lugar de duplicarlo.

Requiere habilitación por compañía (responde R009 si no está activo). Otros códigos de error: R001 si moves viene vacío o falta un campo requerido, R002 si un registro relacionado no existe (diario, tercero, cuenta, contrato, analítica), R003 para valores inválidos o cuentas de tipo vista, y R008 si falla la creación o publicación en el ERP.

Cancela asientos contables identificados por su referencia (ref) o por su nombre (name). Todos los asientos que coincidan con la búsqueda pasan a estado cancelado, omitiendo las validaciones de bloqueo estándar del ERP. La respuesta lista los asientos afectados con su estado final; si ninguna referencia coincide, devuelve una lista vacía sin error.

Requiere habilitación por compañía (responde R009 si no está activo). Otros códigos de error: R001 si moves no se envía y R003 si el valor recibido no es una lista.

Crea una cuenta analítica (account.analytic, subcentro de costo) asociada a una categoría y a una sucursal analítica existentes. La cuenta creada queda disponible para ser referenciada por código en los demás endpoints que reciben el parámetro analytic (asientos, inventario, etc.).

Requiere habilitación por compañía (responde R009 si no está activo). Otros códigos de error: R001 si falta un campo requerido, R002 si la categoría o la sucursal no existen, R003 si analytic_type no es uno de los valores permitidos y R008 si falla la creación en el ERP.

Consulta los diarios contables de la compañía filtrando por tipo y, opcionalmente, por código. Por cada diario devuelve el nombre, el código, el tipo y las cuentas débito y crédito por defecto (como pares [id, nombre]). Es útil para descubrir los valores válidos de journal_code que exigen los endpoints de asientos, recaudos y anticipos.

Requiere habilitación por compañía (responde R009 si no está activo). Otros códigos de error: R001 si no se envía type y R002 si la búsqueda no arroja resultados.

Crea un ajuste de inventario (stock.inventory) y lo procesa completo en una sola llamada: inicia el conteo, recalcula las cantidades teóricas, aprueba y valida el ajuste, dejando las existencias de la ubicación en las cantidades enviadas. Las líneas de conteo se envían en el array lines, cada una con product_ref y quantity. Todo el proceso corre dentro de una misma transacción: si algún paso falla, no queda ningún registro creado y se responde R008 con el detalle de la excepción. Requiere habilitación por compañía: si el servicio no está activo responde R009.

El campo transaction_id hace la operación idempotente: si ya existe un ajuste con ese identificador, se retorna con status_code 00 y el atributo adicional error: "The transaction_id already exists". Un contrato inexistente responde R002; parámetros faltantes o con formato inválido responden R001 o R003.

Crea una ubicación de inventario (stock.location). El campo code es la llave con la que el resto de endpoints de la API (stock, picking, inventory) referencian la ubicación, por lo que debe ser único: un código repetido responde R005. Para ubicaciones de uso interno es obligatorio indicar el almacén (warehouse); si falta responde R001. Requiere habilitación por compañía: si el servicio no está activo responde R009.

Un type fuera de la lista de usos válidos responde R003, y un parent o warehouse inexistente responde R002. Errores internos en la creación responden R008 con el detalle de la excepción.

Crea una transferencia de inventario (stock.picking) con sus líneas de movimiento, la confirma y la reserva. Si la compañía tiene activada la autovalidación de transferencias, la operación queda validada (done) en la misma llamada. Las líneas de producto se envían en el array products (obligatorio, responde R001 si está vacío) con los campos default_code, qty, name, uom y lot. El endpoint requiere habilitación por compañía: si el servicio no está activo responde R009.

La cuenta analítica se resuelve en este orden: homologación analítica por model + uen + sucursal + analytic_location_id (cuando los módulos de homologación están instalados; combinación no encontrada responde R004), código enviado en analytic, o cuenta analítica de abastecimiento de la ubicación origen. Si la compañía valida la fecha de la transacción, una fecha distinta a la actual (o fuera de los días de tolerancia) responde R003. Con assert_stock activo se verifican existencias disponibles del producto (y lote) en la ubicación origen; inventario insuficiente responde R008. Parametrizaciones faltantes (ubicaciones por defecto, UEP del producto, dirección de entrega del cliente en despachos) responden R004.

El campo transaction_id hace la operación idempotente: si ya existe una transferencia con ese identificador, se retorna con status_code 00 y el atributo adicional error: "The transaction_id already exists".

Valida una transferencia de inventario existente registrando las cantidades realmente ejecutadas por línea. Para cada elemento del array products (obligatorio, responde R001 si está vacío) ubica la línea de operación que coincida con el producto y el move indicado, escribe la cantidad hecha y procesa la transferencia: si queda reservada (assigned) la valida de inmediato, generando automáticamente una entrega parcial (backorder) cuando las cantidades ejecutadas son menores a las demandadas. Requiere habilitación por compañía: si el servicio no está activo responde R009.

La operación es idempotente sobre el estado final: si la transferencia ya está en estado done o cancel, no se modifica y se retorna su estado actual con status_code 00. Errores internos al escribir cantidades o al procesar la validación responden R008 con el detalle de la excepción.

Consulta las existencias de una lista de productos en una ubicación interna, calculando por producto la cantidad total, la reservada y la disponible. Los productos a consultar se envían en el array products, cada uno con default_code y opcionalmente lot. Para productos con restricción de vencimiento, los lotes vencidos se excluyen del cálculo. Requiere habilitación por compañía: si el servicio no está activo responde R009.

Sin lot_detail, cada producto retorna un objeto con product, total_qty, reserved_qty y available_qty; si se filtró por lot, se agregan los campos lot y exp_date. Con lot_detail en true, cada producto retorna product y un array lots con las cantidades y fecha de vencimiento por lote, incluyendo los lotes sin existencias en la ubicación con cantidades en cero. Cada elemento de response es la lista de resultados de un producto consultado; los productos sin resultados se omiten. Errores internos en el cálculo responden R008.

Crea un producto duplicando el producto plantilla configurado en las políticas API de la compañía. El nuevo producto hereda toda la parametrización de la plantilla (categoría, UEP, unidad de medida, cuentas, trazabilidad) y solo recibe el name y default_code enviados; el tratamiento de IVA se fija en Excluido. Es la alternativa ligera a product/create cuando todos los productos comparten la misma parametrización.

Si la compañía no tiene configurado el producto plantilla responde R004. Campos faltantes responden R001 y errores internos en la copia responden R008 con el detalle de la excepción.

Crea uno o varios productos (product.product). Los productos se envían en el array products (obligatorio, responde R001 si está vacío); cada elemento usa los campos descritos abajo. La clasificación health_type activa validaciones de la vertical salud: Medicamento exige health_cum_code, Procedimiento exige health_cups_code, Insumo exige risk y Reactivo exige risk y health_temperature (faltantes responden R001). Si type_tax es Gravado, tax_iva es obligatorio y debe ser un impuesto de tipo IVA (R003 en caso contrario). Requiere habilitación por compañía: si el servicio no está activo responde R009.

La referencia interna (default_code) y el código de barras deben ser únicos; un valor repetido responde R005. Cuando no se envían category o line_analytic, se toman de las políticas API de la compañía; si esa parametrización no existe responde R004. La creación es atómica: si algún producto del lote falla, no se crea ninguno y se responde el error correspondiente (R008 para excepciones internas del ERP).

Consulta el precio de venta de una lista de productos según la lista de precios de integración configurada en las políticas API de la compañía (Lista de Precio Venta - Integración). Los productos se envían en el array products, cada uno con su default_code. Por cada producto se retorna la referencia, el precio final calculado por la lista de precios (0 si el producto no tiene regla aplicable) y su unidad de medida. Requiere habilitación por compañía: si el servicio no está activo responde R009.

Si la compañía no tiene configurada la lista de precios de integración responde R004. Un producto inexistente responde R002 y errores internos en el cálculo del precio responden R008.

Consulta las órdenes de venta confirmadas (estado "Pedido de venta") de un cliente identificado por su número de documento. Solo devuelve las órdenes cuyas líneas son en su totalidad productos de tipo servicio; las órdenes con productos almacenables o consumibles se excluyen del resultado. Requiere habilitación por compañía (api_allow_sale_read); si no está activa responde R009.

Códigos de error: R001 si no se envía vat, R002 si el cliente no existe, R003 si el cliente no tiene órdenes confirmadas, R005 si se intenta filtrar por órdenes ya facturadas (invoiced), R004 si ninguna de las órdenes encontradas es exclusivamente de servicios y R008 ante una excepción interna del ERP.

Crea órdenes de servicio (service.order) en lote. El payload envuelve las órdenes en la lista service_orders; cada orden lleva sus líneas en la lista lines con los campos product_ref, qty y price. El procesamiento es por orden: las que fallan no bloquean las demás y la respuesta separa successful_orders de failed_orders con el código de error de cada una. Requiere habilitación por compañía (api_allow_service_order); si no está activa responde R009.

La unicidad de name se valida por software integrador (usuario API que crea el registro), de modo que dos integradores distintos pueden usar la misma numeración. Códigos de error por orden: R001 campo requerido faltante, R002 registro no encontrado (cliente, paciente, contrato, sucursal u homologación de sucursal), R003 el total no corresponde a la sumatoria de las líneas, R005 la orden ya existe y R008 excepción interna. Si el body no incluye service_orders, responde R001 global.

Crea órdenes de punto de venta (pos.order) en lote a partir de un POS externo. El payload envuelve las órdenes en la lista orders; cada orden lleva sus líneas en lines y sus pagos en statements. Las órdenes se procesan y se marcan como pagadas en el ERP dentro de la sesión POS correspondiente. Requiere habilitación por compañía (api_allow_pos_order); si no está activa responde R009.

El campo sequence_ref garantiza idempotencia: si ya existe una orden con esa transacción, la respuesta devuelve la orden existente y agrega en cada elemento el campo error con el texto "The transaction_id already exists", sin crear duplicados. Para devoluciones se envía is_return: true con los valores en positivo y el ERP invierte los signos.

Códigos de error: R001 si falta orders o un campo requerido, R002 si el tercero no existe o está archivado, o si un código de impuesto no existe, R003 si un valor tiene tipo o formato inválido y R004 si el diario del método de pago no tiene cuenta débito configurada.

Devuelve el JSON RIPS (Registro Individual de Prestación de Servicios de Salud, el reporte que los prestadores presentan al Ministerio de Salud colombiano vía FEV-RIPS/SISPRO) generado por el ERP para cada factura consultada. El JSON se entrega sin el envoltorio rips del archivo radicado e incluye la identificación del obligado, el número de factura y los usuarios con sus servicios (consultas, procedimientos, urgencias, hospitalización, medicamentos, otros servicios, etc.). Requiere habilitación por compañía (api_allow_rips_consultation); si no está activa responde R009.

La consulta es parcialmente tolerante a fallos: si algunas facturas generan error, el resultado incluye las exitosas en response y las fallidas en la lista adicional errors; si todas fallan responde R008. Otros códigos de error: R001 si el body no es JSON válido o falta numbers y R002 si ninguno de los números corresponde a una factura.

Devuelve la respuesta de validación que SISPRO (Ministerio de Salud colombiano) emitió al radicar los RIPS de cada factura, incluido el CUV (Código Único de Validación) que certifica que el reporte fue aceptado. Todas las facturas consultadas deben estar en estado "Aceptado SISPRO"; si alguna no lo está, la consulta completa se rechaza con R003. Requiere habilitación por compañía (api_allow_cuv_consultation); si no está activa responde R009.

El objeto response de cada factura es la respuesta cruda de la aplicación FEV-RIPS: estado del resultado, CUV, fecha de radicación y el detalle de ResultadosValidacion cuando aplica. Códigos de error: R001 si el body no es JSON válido o falta numbers, R002 si ningún número corresponde a una factura o la factura no tiene respuesta SISPRO almacenada y R008 si la respuesta almacenada no es un JSON válido o hay un error interno.

Registra en lote eventos del ciclo de cartera del sector salud sobre facturas de venta: radicación ante el pagador, retiro, glosas (con sus subeventos de notificación, aceptación y rechazo) y notificación jurídica. El payload envuelve los eventos en la lista events. Cada evento creado se contabiliza de inmediato mediante la reclasificación entre las cuentas de radicación, glosa o jurídica parametrizadas en el tercero o en el segmento salud de la factura. Requiere habilitación por compañía (api_allow_medical_claim); si no está activa responde R009.

Para glosas la factura debe estar validada, ser a crédito y el valor glosado no puede superar su total. El campo transaction_id da idempotencia: si ya existe un evento con esa transacción, la respuesta devuelve el registro existente con el campo error "The transaction_id already exists". Códigos de error: R001 campo requerido faltante (events, amount o claim_event en glosas, return_invoice en aceptaciones), R002 registro no encontrado, R003 factura/asiento inexistente, factura no validada, valor de glosa superior al total o nota crédito inválida, R004 cuentas de radicación/glosa/jurídica sin parametrizar y R008 factura ya pagada al radicar, factura de contado al glosar o error interno en la creación.

Crea uno o varios pacientes (health.patient) para la vertical salud. El payload envuelve los registros en la lista patients; los campos descritos abajo corresponden a cada elemento de esa lista. Requiere habilitación por compañía (api_allow_patient); si no está activa responde R009.

La validación es por lote completo: si algún paciente falla, no se crea ninguno. Códigos de error: R001 si falta patients o un campo requerido, R002 si el tipo de documento, la ciudad o el país no existen, R003 si un valor tiene formato inválido (fechas, valores de selección) y R005 si ya existe un paciente con el mismo vat.

Consulta un paciente por su número de identificación y devuelve sus datos básicos: nombres, apellidos, dirección, tipo de documento, ciudad y correo electrónico. Los campos relacionales (document_type_id, city_id) se devuelven como pares [id, nombre]. Requiere habilitación por compañía (api_allow_patient_read); si no está activa responde R009.

Códigos de error: R001 si no se envía vat y R002 si no existe un paciente con esa identificación.

Crea un contrato comercial (res.contract) asociado a un cliente, con su modalidad, unidad estratégica de negocio y condiciones comerciales. Los campos comerciales opcionales (ejecutivo, ejecutivo de cartera, lista de precios y plazo de pago) toman por defecto la parametrización API de la compañía. Requiere habilitación por compañía (api_allow_contract); si no está activa responde R009.

La operación es idempotente por nombre: si ya existe un contrato con el mismo name, responde status_code 00 devolviendo el contrato existente sin crear duplicados. En instalaciones con el módulo extended_colcan el campo groupm es obligatorio y se crea adicionalmente la homologación contable del contrato con la cuenta por cobrar del cliente (o la de la configuración API de la compañía).

Códigos de error: R001 campo requerido faltante, R002 registro no encontrado (cliente, modalidad, UEN, ciudad, usuarios, lista de precios, plazo de pago o grupo de modalidad), R003 fecha con formato inválido y R008 error interno al crear el contacto de email, la homologación o el contrato.

Consulta registros de cualquier modelo del ERP a través del ORM y devuelve los campos solicitados. Además de los parámetros validados, el payload acepta un campo opcional domain: un string con un dominio Odoo estándar (ej. "[('customer', '=', True)]") que se evalúa de forma segura para filtrar los registros; si se omite, se devuelven todos los registros del modelo (sujetos a limit/offset).

Requiere habilitación por compañía (política api_allow_query); si el servicio no está habilitado responde R009. Si el modelo no existe en el ERP responde R002; si falta model responde R001; si algún parámetro tiene un tipo inválido responde R003; y si el dominio o la lectura de campos produce una excepción interna responde R008 con el detalle del error.

Ejecuta una consulta SQL directamente sobre la base de datos del ERP y devuelve las filas como objetos donde cada clave es el nombre de la columna del resultado. Está pensado exclusivamente para consultas de solo lectura (SELECT): antes de ejecutar, un filtro de palabras reservadas rechaza con R003 cualquier consulta que contenga delete, drop, insert, alter, truncate, execute, create, update, unlink, copy, write o referencias a la tabla ir_config_parameter, indicando en el mensaje las palabras detectadas.

Requiere habilitación por compañía (política api_allow_query); si el servicio no está habilitado responde R009. Si falta query responde R001, y si la consulta produce un error de SQL (sintaxis, tabla o columna inexistente) responde R008 con el mensaje del motor de base de datos.

Crea uno o varios registros en un modelo del ERP de forma genérica. Los valores de data se pasan directamente al método create del modelo, por lo que las claves deben ser los nombres técnicos de los campos (pueden consultarse con el endpoint /integration/api/fields). La respuesta devuelve la lectura completa de los registros creados, con todos sus campos.

Requiere doble habilitación por compañía: la política api_allow_create debe estar activa (de lo contrario responde R009) y el modelo debe estar incluido en la lista "Modelos Autorizados API" de la configuración API de la compañía; si el modelo no está autorizado responde R006. Los modelos típicamente habilitados para escritura vía API son res.partner, res.contract, health.patient y product.product. Si falta model o data responde R001.

Actualiza registros existentes de los modelos permitidos por la API: res.partner, res.contract, health.patient y product.product (cualquier otro modelo responde R006). El body es un objeto con tres claves: model (nombre técnico del modelo), ids (lista de identificadores; para res.partner acepta números de identificación — vat — o IDs internos, para los demás modelos IDs internos) y fields (objeto con los campos a escribir y sus nuevos valores). Los campos que no existan en el modelo se descartan silenciosamente; si tras el filtrado no queda ningún valor por escribir, o no se encuentra ningún registro, responde R002.

Para res.partner aplican políticas de compañía adicionales: permisos por tipo de tercero (jurídico/natural) y por rol (cliente/tercero) que, de no estar habilitados, responden R008; y bloqueos por campo (email, dirección, teléfonos, nombres, ciudad) que descartan el campo sin generar error. Si se actualizan campos de nombre (first_name, first_lastname, etc.) el ERP recompone automáticamente el nombre completo. Para product.product, en compañías con el módulo extended_cruzroja, no se permite inactivar productos cuyo tipo salud sea "Otros" (R007).

Requiere habilitación por compañía (política api_allow_update); si el servicio no está habilitado responde R009. Si falta model, ids o fields responde R001. La respuesta devuelve la lectura de los campos efectivamente actualizados en cada registro.