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, valida y contabiliza facturas de venta de forma síncrona: la respuesta llega cuando todas las facturas del lote terminaron de procesarse (la acción post-validación — validar, contabilizar, emitir factura electrónica — la define la política api_invoice_validation_action de la compañía). Para lotes grandes use /integration/api/invoice/async.

Es el endpoint más completo de la API: además de la factura puede crear o actualizar el cliente (objeto customer), crear productos (objeto product en la línea), registrar recaudos inmediatos (statements), cruzar anticipos (advances), generar la salida de inventario automática (location + operation_type), aplicar AIU y construir el detalle clínico RIPS para facturación de salud. Cada factura del lote se procesa de forma independiente dentro de un savepoint: las válidas llegan en response y las fallidas en novelty; si al menos una falla, el status_code del lote es 99.

Mecanismos de idempotencia: transaction_id (si ya existe, devuelve la factura original sin duplicar), customer_ref según la política api_invoice_reference_control, y number manual (R005 si se repite).

Dentro de cada elemento de rips pueden enviarse además los arreglos clínicos del anexo técnico RIPS — consultations, procedures, emergencies, hospitalizations, newborns y medicines — con sus campos normativos (modalidad de atención, grupo de servicios, finalidad tecnológica, diagnósticos CIE-10/CIE-11 principal y relacionados, vía de ingreso, MIPRES, tipo y valor del pago moderador, profesional que atiende, etc.). Los campos omitidos toman los valores por defecto del CUPS y del paciente.

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 payload de cada factura es idéntico al del endpoint síncrono Crear facturas; internamente cada proceso encolado ejecuta el mismo motor de validación y contabilización.

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 contabiliza 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; si esta no genera exactamente una línea de pago, la operación falla con R008. Con la política de compañía api_allow_bank_to_identified activa (y el módulo de conciliación bancaria instalado), el recaudo contabilizado crea además la partida bancaria por identificar con la referencia enviada en ref.

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 las políticas de descuentos financieros (api_payment_account_disc_id, api_payment_analytic_disc_id y api_payment_line_analytic_disc_id) 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 — contados desde la fecha de la factura o hacia su vencimiento, según la política discount_receivable_date de la compañía — y no se admiten descuentos sobre facturas parcialmente conciliadas (R003). 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 la cuenta del 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 (R003 si la factura no se encuentra para extraerla).

El endpoint es idempotente por transaction_id: un valor ya registrado devuelve el recaudo existente con la marca The transaction_id already exists sin crear duplicados. Si la política de compañía api_allow_bank_to_identified está activa (y el módulo de conciliación bancaria instalado), el recaudo contabilizado genera además la partida bancaria por identificar con las referencias ref1/ref2/ref3.

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 política 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: si algún elemento del lote trae un valor ya registrado, la respuesta devuelve el asiento existente con la marca The transaction_id already exists y ningún asiento del lote se crea (los demás elementos deben reenviarse con transacciones nuevas).

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 contabilizació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: debita la cuenta por defecto del diario y acredita la cuenta del cliente — la cuenta por cobrar o la cuenta de anticipos, según la política 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: R001 si falta un campo requerido, 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 contabilizació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, omitiendo las validaciones de bloqueo estándar del ERP.

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); en cuentas de balance estos campos se ignoran. Si la cuenta contable de la línea está marcada como cuenta de banco/efectivo, la fecha de consignación de la línea se fija automáticamente con la fecha del asiento.

El endpoint es idempotente por transaction_id: si algún asiento del lote trae un valor ya registrado, la respuesta devuelve el asiento existente con la marca The transaction_id already exists y ningún asiento del lote se crea (los demás elementos deben reenviarse con transacciones nuevas).

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 contabilizació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). 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. En instalaciones con la extensión Cruz Roja (extended_cruzroja) la homologación es obligatoria para las operaciones que exigen analítica y, si el tercero no tiene contrato, se crea automáticamente a partir de model y uen. 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 outgoing) 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 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. Una transferencia inexistente responde R002. 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. 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 el detalle de las órdenes cuyas líneas son en su totalidad productos de tipo servicio; las órdenes que incluyen productos almacenables o consumibles aparecen en el arreglo response como objetos vacíos {} (el integrador debe ignorarlos). 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) 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.

En la respuesta, el objeto summary totaliza las órdenes procesadas; su clave de éxitos es literalmente succesful (con un solo "s" intermedio), tal como la emite el ERP.

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. Si el cliente no tiene plazo de pago configurado, el ERP le asigna el plazo por defecto de la parametrización API de la compañía.

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. Los eventos se crean en una sola operación (si alguno falla no se crea ninguno) y cada uno 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. Disponible también en el alias /integration/api/medical-claim/create.

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 no validada, valor de glosa superior al total o nota crédito inválida (tipo o tercero distintos), 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. Si el número enviado en invoice no existe ni como factura ni como asiento de saldo inicial, la petición falla con un error interno del ERP.

Crea uno o varios pacientes (health.patient) para la vertical salud. El payload envuelve los registros en la lista patients. 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. El campo opcional domain es 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 — o no se envía model, ya que la autorización se verifica primero — responde R006. Los modelos típicamente habilitados para escritura vía API son res.partner, res.contract, health.patient y product.product. Si falta 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, ids y fields. 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. La respuesta devuelve la lectura de los campos efectivamente actualizados en cada registro.

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éfono, móvil, nombres, apellidos, 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. En compañías con el módulo extended_masterseries, los terceros marcados como proveedor o empleado no se actualizan: la respuesta llega con status_code 00 y el mensaje "No se permite actualizar el registro porque el partner es proveedor o empleado" en response.

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.