Dinaup Flex a fondo: todas las piezas y cuándo usar cada una
Guía de Dinaup Flex: secciones, campos, algoritmos, DinaScript, scripts, informes y documentos dinámicos. Qué hace cada pieza y cuándo usarla.
Equipo DinaupDinaup Flex es la capa que adapta el sistema a tu negocio sin escribir SQL ni tocar la base de datos a mano. Creas tus propias tablas, calculas campos solos, automatizas procesos y generas documentos a medida desde la plataforma.
Esta guía explica qué es cada pieza, qué hace y cuándo usarla. Léela antes de montar algo en Flex.
Flex escribe sobre tus datos. Asigna el permiso Dinaup Flex solo a personal técnico. Prueba siempre en datos de prueba antes de pasar algo a producción.
El mapa: piezas que encajan
Flex no es una herramienta única. Son varias que se apoyan entre sí. Antes de entrar en cada una, quédate con el reparto de papeles:
- Secciones y campos — el qué hay: tus tablas y sus columnas.
- Algoritmos — el cuánto vale: cálculos que Flex compila a SQL.
- DinaScript — el lenguaje con el que escribes la lógica.
- Scripts — el cuándo pasa: lógica atada a eventos.
- Informes — el qué consulto: listados sin SQL.
- Documentos dinámicos — el qué genero: HTML, JSON, PDF, email.
Las secciones guardan datos. Los algoritmos calculan. DinaScript es el idioma. Los scripts deciden cuándo. Los informes consultan. Los documentos producen salida.
Secciones y campos: tus tablas
Una sección es una tabla. Almacena registros de un tipo: clientes, facturas, productos. Cada sección se respalda en una tabla PostgreSQL e incluye campos del sistema (id, fecha de alta, autor, eliminado) que Dinaup gestiona solo.
Un campo es una columna. Para definirlo eliges dos cosas:
- Tipo base — la naturaleza del dato. Hay 8: Texto, Texto Multilínea, Número decimal, Número entero, Sí/No, Fecha, Fecha y Hora, y Hora. Aparte está el tipo Relación, que enlaza con un registro de otra sección.
- Rol (opcional) — afina ese tipo. Un Texto con rol Email valida que tenga forma de correo. Con rol Teléfono lo formatea y lo hace pulsable. El rol convierte "esto es texto" en "esto es texto, y además es un email".
Cuando una Relación no apunta a nada, se guarda como cadena vacía, no como ausencia de valor. Tenlo en cuenta al filtrar "relaciones vacías" en informes o algoritmos.
Un campo bien tipado se valida, se formatea y se calcula solo. Marca un campo como auto-calculado y asígnale un algoritmo: su valor sale del cálculo, no del tecleo, y normalmente queda bloqueado para que nadie lo pise a mano.
Las secciones base evitan duplicar columnas comunes. Una base "Entidades" con NIF, dirección y teléfono la comparten "Clientes", "Proveedores" y "Bancos". Los módulos Ready To Go traen más de 180 secciones ya hechas, y puedes ampliarlas o crear las tuyas.
→ Detalle en Secciones y Campos.
Algoritmos: cálculos que se compilan a SQL
Un algoritmo es una operación que defines en Flex y que el sistema convierte en una consulta SQL nativa que se ejecuta en PostgreSQL. No hay procesamiento en memoria intermedio. El cálculo ocurre junto a los datos, así que rinde aunque la sección tenga millones de filas.
La lógica la escribes en DinaScript. Lo que cambia entre algoritmos es sobre qué datos operan:
| Tipo | Sobre qué opera | Devuelve |
|---|---|---|
| Lineal | Una fila y sus relaciones directas | Un valor de esa fila (cantidad × precio) |
| Cruzado | Registros relacionados, agregados | Un valor agregado (suma de las líneas de una factura) |
| Búsqueda | Otra sección, filtrada | El id del registro que coincide |
| Datos | Todos los registros de una sección | Un agregado global (total facturado del mes) |
| Independiente | Sin contexto de fila | Un valor de sesión o cálculo (el usuario actual) |
El algoritmo de Búsqueda no optimiza búsquedas ni trae el dato final. Devuelve el id del registro que casa con el filtro. Con ese id enlazas el registro o lees luego sus campos.
Los tipos que recorren varios registros (Cruzado, Búsqueda, Datos) se construyen por partes: la fórmula principal (obligatoria) y filtros opcionales que acotan qué entra en el cálculo —prefiltrado, filtrado izquierda (origen del cruce), filtrado derecha (lo cruzado) y Having (sobre el agregado ya hecho). Filtra pronto y por el lado correcto para mantener el algoritmo rápido.
Un mismo algoritmo se reutiliza en campos auto-calculados, columnas de informes y documentos dinámicos. Parametrízalo con variables (v.NombreVariable) para no duplicar la lógica: quien lo consume aporta el valor y el cálculo se ajusta sin tocar el código.
→ Detalle en Algoritmos.
DinaScript: el lenguaje, no el motor
DinaScript es el lenguaje con el que escribes la lógica de Flex. DinaScript no genera SQL. El SQL lo producen los algoritmos al compilarse. DinaScript es la sintaxis con la que expresas qué debe calcular ese algoritmo, o qué debe rellenar un documento.
Tiene dos particularidades que conviene conocer de entrada:
- Solo hay 2 tipos de variable:
txt(texto, y también fechas, booleanos y GUIDs como cadena) ynum(enteros y decimales). Los booleanos son números:1= verdadero,0= falso. - Todo lleva prefijo de espacio de nombres:
| Espacio | Para qué |
|---|---|
F. | Funciones generales: texto, fechas, matemáticas, agregación |
S. | Sistema/Schema: acceso a secciones y campos por su ID |
I. | Iterador: el registro actual cuando recorres datos |
D. | Datos globales del sistema (empresa, fecha actual...) |
V. | Variables locales que tú declaras (v.miVariable) |
A. | Opciones avanzadas de algoritmos |
Un bucle que recorre productos activos y avisa de bajo stock se lee así:
F.DataListLoad(S.Sections.Productos.ID, 1, 999999)
F.DataListLoadAddFilter(S.Sections.Productos.ID, S.Fields.Productos.Activo.ID, '=', 1)
num bajoStock = 0
F.ProcessDataList_Ini(S.Sections.Productos.ID)
if I.Productos.Stock < 10
F.Write(F.Concat("ALERTA bajo stock: ", I.Productos.Nombre))
v.bajoStock = v.bajoStock + 1
end if
F.ProcessDataList_EndLas fechas se manejan como texto y se operan con funciones F. (F.Cast_TextToDate, F.DaysDifferenceBetweenDates). No hay arrays nativos: para colecciones usa DataTables. Convierte siempre entre tipos con F.Cast_* (F.Cast_NumToText, F.Cast_TextToNum...).
→ Referencia del lenguaje en DinaScript.
Scripts: lógica atada a eventos
Un script es lógica que se ejecuta cuando ocurre un evento. El evento es el disparador (abrir un formulario, cambiar un campo, pulsar un botón). El script es lo que pasa después (recalcular, validar, imprimir, lanzar una acción). Sin evento no hay script.
Al montar un script tomas tres decisiones: qué tipo es, en qué ámbito vive y qué evento lo dispara.
Tipos de script
| Tipo | Qué hace |
|---|---|
| Terminal | Orquesta la interfaz: abrir una ventana, navegar, refrescar datos, mostrar un mensaje |
| Algoritmo | Calcula y valida con DinaScript (totales, derivar campos, reglas) |
| Plantilla de impresión | Genera un documento (factura, albarán) con un documento dinámico |
| Función API | Invoca una operación de la API para integrar con servicios externos |
Ámbitos: formulario o campo
| Ámbito | Reacciona a… | Se dispara |
|---|---|---|
| Script de formulario | El ciclo de vida del registro completo (abrir, cargar, aceptar, cancelar) | Una vez por operación |
| Script de campo | La interacción con un campo concreto (cambiar, foco, click) | Cada vez que tocas el campo |
Eventos más usados
- De formulario: Iniciado al agregar nuevo (valores por defecto), Pre-aceptar (validar y bloquear el guardado), Tick de recálculo (mantener derivados al día), Cargado.
- De campo: Cambiado (el más habitual para recalcular), Pierde foco (validar lo recién escrito), Click.
- Otros disparadores: Independiente (se invoca por sí solo), Informe e Informe (filas seleccionadas) para actuar sobre los resultados de un listado.
Una cuarta pieza es el contexto: dónde queda disponible el script para activarse (en todos los sitios aplicables, en campos personales, en botones de informe o en botones de widget). El tipo dice qué hace, el evento cuándo, y el contexto dónde aparece.
Para validar antes de guardar, usa un script de formulario en Pre-aceptar: se dispara justo antes de guardar, así que compruebas que todo cuadra y, si no, impides el guardado. Para validar un campo en cuanto el usuario lo abandona, usa Pierde foco en ese campo.
→ Detalle en Scripts y eventos.
Informes: consultar sin SQL
Un informe es una vista reutilizable sobre una sección. Eliges columnas, filtros, agrupación y orden, y obtienes una consulta que puedes ver en pantalla, exportar o consumir por API. Un informe siempre nace de una sección.
Lo que más vas a usar:
- Filtrado rápido — condiciones directas sobre los campos (igual, contiene, entre desde y hasta).
- Filtro por algoritmo — cuando la condición es un cálculo y no un campo directo.
- Columnas calculadas — su valor lo produce un algoritmo (totales, búsquedas, agregados).
- Rol de columna — le dices al informe que una columna es Moneda, Porcentaje o Cantidad para que la formatee y la sume bien.
- Preguntas dinámicas — el informe pregunta un parámetro al usuario antes de ejecutarse (lo típico: un rango de fechas) y filtra con su respuesta. Encajan con las variables
v.de un algoritmo.
Ocultar una columna no es lo mismo que quitarla. Una columna oculta sigue calculándose y puede usarse para filtrar, agrupar u ordenar. Solo deja de pintarse. Útil para columnas que el informe necesita internamente pero no quieres mostrar.
Cualquier informe puede exponerse como endpoint API para que un sistema externo lea sus datos sin acoplarse a la estructura interna de la base de datos.
→ Detalle en Informes.
Documentos dinámicos: generar salida a medida
Un documento dinámico es una plantilla programable que mezcla tus datos con código para producir un resultado concreto. No son texto plano. Se escriben sobre web estándar (HTML, CSS, JavaScript) y el mismo documento puede imprimirse en PDF, enviarse por email, incrustarse como widget o consultarse por API.
Al crearlo eliges un tipo según adónde va el resultado:
| Tipo | Qué produce | Cuándo |
|---|---|---|
| Diseño de informe | Plantilla visual de un informe | Dar formato a filas y totales de un informe |
| Documento de lectura libre (HTML) | Página HTML completa | Impresión (PDF), email y dashboards. El más versátil |
| API de lectura libre (JSON / XML) | Datos estructurados | Que otro sistema lea datos de Dinaup |
| API de escritura | Operación que recibe y guarda | Que otro sistema cree o actualice registros |
| Documento contable | Asientos y datos contables | Cuando el destino es la contabilidad |
En la mayoría de casos quieres un Documento de lectura libre (HTML): una misma plantilla cubre impresión, email y dashboard. Reserva los tipos API para cuando otro sistema vaya a hablar con Dinaup, y el contable para cuando el destino sea la contabilidad.
La lógica que rellena la plantilla la pones con DinaScript: defines variables, recorres registros y vuelcas el resultado. Para email, fijas los metadatos del envío desde la propia plantilla con F.MetaData_Set:
F.MetaData_Set('email_subject', F.Concat('Factura ', D.EmpresaActual.TextoPrincipal, ' nº', v.Factura.NumeroDeFacturaCompleto))
F.MetaData_Set('email_to', v.Factura.ReferenciaCliente.IdentificadorAcceso)
F.MetaData_Set('email_to_name', v.Factura.ReferenciaCliente.NombrePersonalRazonSocial)
F.MetaData_Set('email_attachment_name', 'factura.pdf')Para maquetar puedes apoyarte en Bootstrap, y para gráficos en paneles, en Google Charts: es web estándar.
→ Detalle en Documentos dinámicos.
Cómo encaja todo: un ejemplo de punta a punta
Quieres controlar cuánto llevas cobrado de cada venta y mandar la factura por email. Las piezas se ordenan así:
Secciones y campos
Tienes la sección Ventas (origen) y Cobros (destino). Añades a Ventas un campo auto-calculado "pendiente de cobro".
Algoritmo
Un algoritmo Cruzado suma los cobros relacionados con cada venta y da valor al campo auto-calculado, que se mantiene al día solo conforme entran cobros.
Informe
Un informe sobre Ventas filtra por "pendiente > 0" y lista todo lo que falta por cobrar.
Documento dinámico
Un documento de lectura libre (HTML) genera la factura en PDF y, con los metadatos de email, la manda al cliente.
Cada pieza hace una cosa y se apoya en las demás. Eso es Flex: ladrillos pequeños que, bien combinados, montan procesos completos sin salir de la plataforma.
Preguntas frecuentes
Siguiente paso
- El índice completo, pieza a pieza: Dinaup Flex
- La pieza que más rinde dominar: Algoritmos
- La referencia del lenguaje: DinaScript
- Plantillas de salida (PDF, email, API): Documentos dinámicos
