Créditos: Esta documentación fue iniciada por Red1
Motivación
• Las necesidades actuales son cada vez mayores. Los usuarios desean un ERP en un plazo de 6 meses en lugar de 18.
• Las aplicaciones ERP se han expandido hasta convertirse en una solución universal.
• Las implementaciones de calidad a gran escala ya no pueden ser realizadas por un solo experto, sino que requieren un intercambio abierto entre todas las partes.
• La especialización mediante colaboradores diferenciados, reduce el coste total de propiedad para los usuarios de pago.
Marco de Aplicación en IDempiere
Figura 1 – El Modelo de Datos está integrado en el Diccionario de Aplicaciones.
Dado que el Diccionario de Aplicaciones de IDempiere minimiza la necesidad de modificar el código fuente o el software base, y permite realizar cambios de forma rápida y sencilla, tanto en la apariencia del Modelo de Datos como en el Modelo de Negocio, podemos denominarlo Marco de Aplicaciones.
Un Marco de Aplicaciones permite desarrollar una aplicación sin tener que empezar desde cero. IDempiere ya cuenta con la apariencia y muchos accesorios diseñados para funcionar de forma estable y eficaz. Estas características y accesorios no requieren codificación adicional en un nuevo diseño de software.
Un nuevo software puede simplemente introducir su Modelo de Datos como tablas y columnas organizadas en ventanas y asociadas a árboles de menús.
El inicio de sesión de cada usuario estará controlado por su rol o roles permitidos para acceder o no a ciertos menús de ventanas, procesos o informes.
Modelado de Aplicaciones
Figura 2: Cualquier aplicación vertical puede incorporarse y reutilizar utilidades estándar.
IDempiere funciona como una aplicación horizontal donde otras aplicaciones verticales, o incluso nuevas, pueden reutilizarla o basarse en ella.
Antes de introducir una nueva aplicación, es necesario diseñarla y modelarla para que se ajuste al marco de IDempiere.
Diseñar una nueva aplicación sobre IDempiere es quizás la parte más difícil o la que más cuesta desarrollar una aplicación.
El diseño de cualquier aplicación es complejo. Cuanto más grande es, más difícil es. Cuantos más módulos se integren, el desafío aumenta exponencialmente.
Pero si se dedica suficiente tiempo a la planificación (50%) y al diseño (90%), la parte de codificación representa solo el 10%.
El trabajo resultante de codificación o migración del sistema es sencillo.
Existen diversas herramientas de migración para realizar la integración final de los datos o el modelo de la aplicación heredada en IDempiere. Entre ellos se encuentran:
• Cargadores de importación (modelo actual).
• ADCK (modelo XML2AD mejorado por Trifon T.)
• 2Pack (modelo XML2AD mejorado por Robert Klein – estándar para la migración de aplicaciones propias)
• Scripts de migración (estándar para nuevas aplicaciones)
• Implementación de módulos OSGI (la última versión es OSGI HengSin)
En la etapa de diseño de sistemas, es importante estudiar el modelo y el marco de trabajo de ADempiere inherentes lo suficientemente bien como para reutilizarlos al máximo y evitar redundancia de trabajo y complicaciones posteriores.
Una aplicación vertical introducida o migrada con éxito no solo disfrutará de las múltiples interfaces y el motor de aplicaciones existentes, sino también de un salto cualitativo hacia el mercado de servicios de código abierto.
Los futuros desarrolladores de aplicaciones deben realinear su modelo de negocio de software a uno completamente nuevo.
Modelado de datos
Tenga en cuenta que el uso del término “debe” implica que es obligatorio e innegociable para una implementación exitosa. El término “debería” implica que es opcional, pero se recomienda para facilitar el mantenimiento y la escalabilidad del sistema.
Los scripts SQL para cada modelo de datos se pueden ejecutar primero en la base de datos. Posteriormente, la tabla y la columna de AD pueden incorporar las tablas creadas al diccionario de la aplicación.
Tabla debe tener los campos obligatorios para la persistencia y la gestión del modelo dentro del marco de ADempiere:
• AD_Client_ID: indica el nivel más alto y la identidad distintiva que controla toda la actividad de la organización.
• AD_Org_ID: indica los subniveles inferiores y dentro del cliente.
• Created: indica la marca de tiempo de cada registro en esta tabla en el momento de su creación.
• CreatedBy: indica el ID de usuario que creó el registro.
• Updated: indica la marca de tiempo de la última actualización de cada • registro.
• UpdatedBy: indica el ID de usuario que actualizó el registro por última vez.
• IsActive: indica si el registro está activo o no.
Cada nombre de tabla debe tener su clave principal como su nombre de tabla respectivo, más el ID de guión bajo. Por ejemplo, una nueva tabla “Cigarros” tendrá su clave primaria (PK) como “Cigarros_ID”. Cualquier convención de nomenclatura errónea que se desvíe de esta resultará en un fallo del modelo durante la ejecución.
Cada tabla debe tener un campo “valor” para la clave de búsqueda. En resumen, “valor” es otro nombre reservado en el modelado de tablas de ADempiere.
Se pueden introducir relaciones de entidad entre tablas mediante campos que cumplan con la convención de ID de tabla. Por ejemplo, la tabla “Fumadores de Cigarros” tendrá “Cigarro_ID”, lo que significa que es una clave externa de la tabla “Cigarros”. Esta es una relación de definición general.
La presentación de dicha relación de entidad se realiza dentro de la configuración de Ventana, Pestaña y Campo, donde una subpestaña tendrá su enlace de clave principal especificado. Esto define la relación de forma precisa, pero solo durante las visualizaciones en ventana.
Esta aparente relación maestro-detalle, mediante esta declaración PK-FK, se aplica durante la entrada de datos, donde cada línea de detalle posee el ID o la clave principal de la tabla principal.
Por supuesto, puede restringir aún más la configuración de la base de datos para indicar que si la tabla principal no se puede eliminar mientras exista una tabla secundaria, la tabla de detalle debe tener el sufijo “Línea” añadido a su nombre, tomado de la tabla maestra. Por ejemplo, una tabla “Cigarros” puede ser una tabla maestra con una tabla de detalle como “LíneaCigarros”.
Modelado de documentos
Numeración de secuencias
Modelado de informes
Figura 3 – El motor PrintFormat facilita la configuración de informes.
El motor de informes de ADempiere (heredado completamente de Compiere) se configura automáticamente y en caliente.
En cualquier tabla de la ventana con registros, puede hacer clic en el icono de Informe.
• Observe el visor de informes emergente con el registro seleccionado.
• Haga clic en el icono de Búsqueda en ese visor.
• Simplemente haga clic en Aceptar para seleccionar todo.
• Observe que se generan todos los registros.
• Por lo tanto, puede intentar realizar una búsqueda avanzada para obtener el cubo de informe que desee.
• Puede guardar sus preferencias avanzadas para su uso posterior.
Consulte este ejemplo en E-ticketing#Informes_Al_Movimiento.
Puede reformatear los campos y su disposición fácilmente mediante el cuadro de herramientas de informes PrintFormat.
Caja de herramientas de informes
Figura 4 – El filtro de búsqueda avanzada se puede guardar y recuperar (consulte la Figura 3)
- En la misma ventana emergente, seleccione el cuadro de herramientas para ampliar la ventana Formato de impresión.
- Haga clic en la pestaña Orden de visualización
- Seleccione los campos que no desea que aparezcan. Puede moverlos en el orden que prefiera.
- Haga clic en la flecha hacia atrás para eliminarlos de este informe.
- Después, puede guardar su nuevo informe para usarlo más adelante.
- Haga clic en la pestaña Formato de campo.
Puede añadir funciones adicionales, como obtener el total o la suma acumulada de un campo con importe o valor contable.
Al salir y actualizar el informe, se modifican los cambios. De nuevo, todos los cambios se guardan automáticamente en la nueva definición del informe. Y todas sus configuraciones personalizadas se pueden transferir mediante scripts de migración de registros (preferiblemente) o la gestión de paquetes 2Pack.
Búsqueda avanzada
Ya existe un motor de búsqueda avanzada sobre la marcha para filtrar cualquier resultado, ya sea en la ventana de visualización o en el formato del informe.
Las reglas booleanas permiten cualquier conjunto de información imaginable. • Esto evita tener que crear más motores o herramientas para generar la gama correcta de informes.
(Consulte la Figura 4)
- En el Visor de Informes, haga clic en el icono de búsqueda.
- Seleccione los elementos y las reglas booleanas para los valores necesarios.
- Guárdelo con un nombre atractivo para poder usarlo cuando desee realizar la misma búsqueda avanzada.
Modelo de Procesos
Un modelo pasa por varios procesos de controlador que automatizan el trabajo.
• El marco de AD permite que cualquier campo del modelo de tabla y columna tenga una llamada.
• La llamada realizará una acción cuando se produzca un cambio en el campo.
• La acción puede consistir en leer y calcular un nuevo valor para cualquier campo de la pestaña.
• El cálculo puede consistir en acceder a cualquier tabla o cambiar su valor en la base de datos.
• Las llamadas pueden estar en código Java compilado en el código fuente o en metadatos sin modificar el código fuente.
• La llamada de metadatos permite opciones de scripting JSR223, como Python, Beanshell, Groovy y, quizás, Ruby, además de Java.
A nivel de documento:
Hay un campo de botón que puede generar un proceso escrito en código SQL o Java.
El proceso puede determinar un proceso complejo:
• Contabilización de cuentas
• Gestión del flujo de trabajo
• Cambio de registros
• Al final del proceso, el botón puede cambiar su estado y el estado del registro de la pestaña se modifica. Implementación
Marco de pruebas
Empaquetado
Mantenimiento
Ver también
• Vistas del menú superior
• Modelo de negocio del software
• E-ticketing como prototipo rápido y sencillo
• EDIFACT como extensión real que utiliza una programación más compleja, pero con cambios sencillos en el modelo de datos.
• Llamada y llamada de script
