APPSEn producción
Módulos: aplicaciones sin código
No todo es un flujo; a veces es un maestro.
Un listado de proveedores, un inventario de contratos o un registro de novedades no necesita un diagrama: necesita una ficha, un listado y un historial. Eso se arma con el mismo diseñador, sin pedir una tabla nueva a sistemas.
Qué incluye
Una aplicación de datos en una tarde.
El módulo define su formulario, su listado y su presentación en tarjetas, con categoría, dueño funcional y dueño técnico.
Diseño
- El mismo diseñador de formularios del proceso
- Listado configurable: columnas, búsqueda y tarjetas
- Categorías, dueño de módulo y dueño técnico
- Versión, historial y comparación entre versiones
Datos
- Alta, consulta, edición y borrado de registros
- Historial de auditoría por registro
- Guardado parcial del formulario
- Tablas propias en el esquema de datos del producto
Con los procesos
- Arrancar un proceso desde un registro del módulo
- Arrancar un proceso desde una fila de una tabla del registro
- Mapeo de entrada y salida entre el módulo y las variables del proceso
- El proceso devuelve el resultado al registro que lo originó
Para el usuario
- Portal de módulos con búsqueda y vista de tarjetas o tabla
- Distintivo de estado por módulo
- Listas desplegables que leen estas mismas tablas
- Mismos permisos y misma empresa que el resto del producto
Se apoya en
No trabaja solo.
Estas otras partes del producto son las que hacen que esta funcione de punta a punta.
Estándares y límites
Con qué se puede contar.
Un módulo es una aplicación de datos, no un flujo: si hay aprobaciones y plazos, eso vive en un proceso y se arranca desde el registro.
- Mismo ciclo que un proceso
- Diseño, publicación, versiones y motivo del cambio se comportan igual que en un proceso.
- Tablas consultables
- Los datos quedan en tablas de SQL Server del propio producto, no en un formato cerrado.
Traiga la hoja de cálculo que quiere dejar de usar.
Le mostramos uno de sus propios procesos modelado y corriendo, con sus formularios y sus plazos.