Versión 2026.20

Finanzas

Nuevos recursos de gestión de Ventas en API Fundanet Connect

En el marco de la evolución de la gestión de ventas en Fundanet, se ha incorporado un nuevo recurso de Pedidos de Venta en la API Fundanet Connect, que permite dar de alta, consultar, modificar o eliminar pedidos de venta, aplicando las mismas validaciones que rigen estas acciones en la aplicación de escritorio.

En este sentido, tanto la edición como el borrado están condicionados al estado del pedido de venta:

• El pedido de venta se crea siempre en estado Autorizado.
• Desde Autorizado, el único cambio permitido es pasar a Pendiente (paso obligatorio para poder editar el resto de campos/líneas o eliminar el pedido).
• Desde Pendiente, se admite edición completa de cabecera y líneas, el paso a Rechazado, y es el único estado desde el que se permite el borrado.
• Rechazado no es un estado terminal: puede volver a Pendiente o a Autorizado.

El recurso incluye los siguientes campos:

La columna Eliminación es "N/A" en el resto de los campos porque el DELETE no recibe el cuerpo de los datos: la única condición para poder eliminar es que Estado Aprobación sea Pendiente (ver fila Estado Aprobación y sección Eliminación).

Editable (solo en Pendiente) significa que el campo forma parte del PUT completo y solo se acepta un valor distinto al guardado cuando el pedido está en estado Pendiente; en Autorizado o Rechazado debe coincidir con el valor ya almacenado.

Creación – POST – Add sales order:

• El pedido se crea siempre en estado Autorizado, con independencia de lo indicado en la petición.
• Control entrega admite los valores:
  • I (control por importe base de los albaranes asociados)
  • C (control por cantidad/unidades).
• El pedido llega ya formado desde origen: este recurso no calcula el Precio Unitario por tarifa, se recibe tal cual en la petición.
• Domicilio de entrega, Forma de cobro y Domicilio de facturación se resuelven siempre desde la ficha del Cliente; si se envían en la petición, se ignoran. Lo mismo aplica a todos los campos calculados o autoasignados.
• Se rechaza la creación si el Artículo de una línea no existe en la base de datos o si la Persona de contacto indicada no pertenece a los contactos del Cliente.

Edición – PUT – Update Sales Order:

• El PUT recibe siempre el registro completo (cabecera y líneas), no solo los campos que cambian.
• El alcance permitido depende del estado actual:
  • Con el pedido en Autorizado o en Rechazado, el único cambio permitido es el de Estado Aprobación (a Pendiente desde Autorizado; a Pendiente o Autorizado desde Rechazado). Como el PUT siempre trae el registro completo, se rechaza la petición si el contenido de cualquier campo de cabecera o del array de líneas difiere de lo ya guardado; si todo coincide y solo cambia el Estado Aprobación, se acepta.
  • Con el pedido en Pendiente, se permite edición completa de cabecera y líneas con el mismo formato que la creación: el array de líneas recibido sustituye por completo a las líneas existentes (no es edición incremental línea a línea). Desde Pendiente también se admite pasar a Rechazado, con la misma regla de comparación si no se quiere modificar nada más además del estado.

Eliminación - DELETE – Delete sales order:

• Solo se permite si el pedido está en estado Pendiente; se bloquea el borrado tanto en Autorizado como en Rechazado. No se han considerado condiciones adicionales (facturación, entregas registradas): el estado es la única validación.

Consulta - GET – Get sales orders by filter:

• Filtros disponibles: Empresa, Cliente, Id, Código Id, Tipo de pedido, Estado Aprobación, Fecha Pedido, Unidad de gestión, Proyecto de ingreso, Importe total incl. IVA.

Junto al recurso de Pedidos de Venta se publican dos nuevos recursos de solo consulta, Tarifas de venta y Artículos, que permiten al sistema externo obtener los datos maestros necesarios para formar los pedidos: consultar los artículos disponibles para informar las líneas y consultar las tarifas vigentes para obtener el Precio Unitario. Ninguno de los dos permite crear, modificar ni eliminar registros.

TARIFAS DE VENTA – GET - Get products sales rates catalog by filter:

Devuelve las tarifas de venta definidas en Fundanet. Cada registro corresponde al precio de un artículo dentro de un periodo de vigencia y para un ámbito de aplicación, determinado por el Tipo Tarifa:

• General (1): aplica a todos los clientes.
• Individual (2): aplica a un cliente concreto (Tercero).
• Por Agrupación (3): aplica a los clientes de una agrupación.

Filtros disponibles: la Empresa es obligatoria en todas las consultas. El resto de los filtros son opcionales y se pueden combinar.

Campos de salida:

La columna Informado indica si el campo siempre viene con valor (Siempre), puede venir vacío (Opcional) o depende del valor de otro campo (Condicional).

ARTÍCULOS - GET – Get products catalog by filter:
Devuelve los artículos definidos en Fundanet que cumplen los criterios de búsqueda indicados.

Filtros disponibles: la Empresa es obligatoria en todas las consultas. El resto de los filtros son opcionales y se pueden combinar.

Campos de salida:

Los indicadores booleanos (Activo en venta, Activo en recuentos, Venta web, Tratamiento por lotes, Activo en reservas y Control de existencias) se devuelven tal y como están configurados en la ficha del artículo. El recurso no comprueba si su combinación es coherente: se limita a devolver los artículos que cumplen los filtros indicados.

Compras y Expedientes

Nuevo check Recurrencia en el formulario de Propuestas de Compra

En el marco de la evolución de la gestión de compras en iFundanet, se está trabajando en el desarrollo de nuevas funcionalidades que próximamente estarán disponibles. Como parte de este proceso, se irán incorporando en la aplicación de escritorio determinados campos que, si bien no tendrán uso operativo de forma inmediata, sentarán la base para las próximas mejoras que se pondrán a disposición de los clientes.

En esta ocasión, se incorpora en el formulario de Propuestas de Compra (escritorio), pestaña Contratación Pública, un nuevo check denominado Recurrencia, que vendrá desmarcado por defecto al crear una nueva propuesta. Cuando la propuesta se genere a partir de una tramitación realizada desde la web, el campo se cumplimentará automáticamente con el valor indicado por el investigador en dicha tramitación.

Este campo permitirá indicar si una propuesta de compra corresponde a una compra recurrente, facilitando la identificación de posibles casos de fraccionamiento indebido. Además, sienta la base para un desarrollo posterior en el que estas propuestas podrán seguir un flujo de aprobación específico (fuera del alcance de esta entrega).

Nuevo campo "Tarifa editable en Web" en los formularios de Tarifas y Descuentos de Compra

Siguiendo la línea de evolución de la gestión de compras en iFundanet mencionada en la entrada anterior, se incorpora en el formulario de Tarifas de Compra (escritorio) un nuevo campo denominado Tarifa editable en Web, que viene cumplimentado como "No" por defecto al crear una nueva tarifa. Este campo permite distinguir entre artículos con precio cerrado y artículos con precio abierto a negociación puntual (servicios o precios negociados), de forma que, en un desarrollo posterior, la web pueda permitir o no al investigador modificar el precio en el momento de la compra.

El grid de Descuentos de Compra muestra, de forma no editable, el valor heredado de la tarifa asociada, de manera que el descuento sigue siempre el mismo criterio de editabilidad que su tarifa, sin necesidad de configurarlo de forma independiente. Dado que los descuentos no se asocian directamente a una tarifa, el sistema determina qué tarifa les corresponde buscando aquella cuyo periodo de vigencia se solape con el del descuento, según el tipo (General, Proveedor o Contrato). En función del resultado de esa búsqueda:

• Si el descuento se solapa con una única tarifa, la columna muestra el valor ("Sí"/"No") heredado de esa tarifa.
• Si se solapa con más de una tarifa con valores distintos, la columna muestra "Depende de la fecha".
• Si no existe ninguna tarifa vigente asociada, la columna se muestra vacía.

El valor mostrado se actualiza de forma inmediata si se modifica el campo en la tarifa de origen.

Este desarrollo afecta únicamente a escritorio. El consumo de este valor desde la web se abordará en un desarrollo independiente y no forma parte de esta entrega.

Nuevo check "Exclusividad" en el formulario de Tercero Ofertante de la Propuesta de Compra

Siguiendo la línea de evolución de la gestión de compras en iFundanet mencionada en las entradas anteriores, se incorpora en el formulario de Tercero Ofertante, dentro de Propuestas de Compra (escritorio), un nuevo check denominado Exclusividad, que viene desmarcado por defecto al crear un nuevo ofertante. Este campo permite reflejar de forma estructurada que existe justificación documentada de proveedor único, en lugar de gestionarlo de forma informal en el campo Motivo o en documentos adjuntos.

El check Exclusividad solo puede marcarse si el ofertante está marcado como Adjudicatario; en cualquier caso, el campo Motivo sigue siendo obligatorio para el adjudicatario, tenga o no marcada la Exclusividad. El sistema no limita el número de ofertantes que puede tener una propuesta, aunque su adjudicatario tenga Exclusividad = Sí.

Este desarrollo afecta únicamente a escritorio. La recuperación de este valor desde la web se abordará en un desarrollo independiente y no forma parte de esta entrega.

Para los ofertantes ya existentes, el campo se migra con el valor "No" por defecto.