Você está na página 1de 149

Trabajo Fin de Máster

Máster en Organización Industrial y Gestión de


Empresas

Integración de sistemas ERP y MES mediante el


estándar ANSI/ISA-95

Autor: Álvaro Roberto Rojas Castro


Tutor: José Manuel Framiñán Torres

Equation Chapter 1 Section 1

Dep. Organización Industrial y Gestión de Empresas I


Escuela Técnica Superior de Ingeniería
Universidad de Sevilla
Sevilla, 2016
ii
Trabajo Fin de Máster
Máster en Organización Industrial y Gestión de Empresas

Integración de sistemas ERP y MES mediante el


estándar ANSI/ISA-95

Autor:
Álvaro Roberto Rojas Castro

Tutor:
José Manuel Framiñán Torres
Profesor titular

Dep. de Organización Industrial y Gestión de Empresas I


Escuela Técnica Superior de Ingeniería
Universidad de Sevilla
Sevilla, 2016

iii
iv
Trabajo Fin de Máster: Integración de sistemas ERP y MES mediante el estándar ANSI/ISA-95

Autor: Álvaro Roberto Rojas Castro

Tutor: José Manuel Framiñán Torres

El tribunal nombrado para juzgar el Proyecto arriba indicado, compuesto por los siguientes miembros:

Presidente:

Vocales:

Secretario:

Acuerdan otorgarle la calificación de:

Sevilla, 2016

El Secretario del Tribunal

v
vi
A María y Mario
A mis padres

vii
Agradecimientos

En primer lugar me gustaría agradecer a todas aquellas personas que han sido fundamentales para la
realización de este Máster y por el apoyo, colaboración, ánimo e inestimable ayuda de mi tutor José Manuel
Framiñán.
A mis compañeros de trabajo que sirvieron de inspiración y guía para la selección del tema del trabajo fin de
máster.
En tercer lugar agradecer a mis padres por su sacrificio y por la educación que nos han dado tanto a mis
hermanos como a mí, sin ellos este trabajo no hubiera sido posible.
También quisiera agradecer a mi mujer su ayuda y comprensión en las largas jornadas de dedicación en las
que no la he podido acompañar por la dedicación al máster, ha sido un apoyo fundamental en todo momento.
Muchas gracias María por tu cariño, por tu ánimo, por tu profundo amor y por estar ahí siempre que te he
necesitado.
Finalmente mi especial dedicatoria a mi hijo Mario, eres lo mejor que me ha pasado y haces de mí una mejor
persona.

viii
ix
Resumen

En el presente trabajo fin de máster se pretende desarrollar y presentar una prueba de concepto para la
integración entre un sistema ERP y un sistema MES mediante la utilización de las especificaciones del
estándar internacional ANSI/ISA-95.
El sistema ERP seleccionado para la integración es Odoo (antes conocido como OpenERP) por ser de código
abierto y fácilmente ampliable y por permitir la modificación de su comportamiento de manera sencilla.
Como sistema MES se ha seleccionado PROMIA, del que se disponía del esquema de base de datos por parte
del Departamento de Organización Industrial y Gestión de Empresas I.
La prueba de concepto desarrollada permite el registro de órdenes de fabricación del ERP en el MES; sin
embargo, no se ha desarrollado una integración completa de la información, pudiéndose quedar dicha
integración completa como un trabajo a finalizar en el futuro. La prueba de concepto cumple su objetivo
principal que no es más que la demostración de cómo se puede llevar a cabo la integración de los sistemas
ERP y MES mediante el estándar ISA-95.

x
xi
Abstract

In this Master’s degree job I develop and explain a proof of concept to integrate an ERP System and a MES
using the specification of the international standard ANSI/ISA-95.
The selected ERP System for this integration is Odoo (formerly known as OpenERP) because it is open source
and easily expandable and because it permits modifying its behavior in a simple way.
The selected MES system is PROMIA, of which the database schema was available by the Department of
Industrial Organization and Enterprises Management I.
The developed proof of concept allows the registration of manufacturing orders from the ERP in the MES;
however, a complete integration of the information has not been developed, such complete integration can
remain as a work to be completed in the future. The proof of concept fulfills its main purpose which is nothing
more tan de demonstration of how the integration of the ERP and MES systems can be carried out using the
standard ISA-95.

xii
Índice

Agradecimientos viii
Resumen x
Abstract xii
Índice xiii
Índice de Tablas xv
Índice de Figuras xvi
1 Introducción 1
1.1 Objeto 1
1.1.1 Objetivos generales 1
1.1.2 Objetivos específicos 1
1.2 Alcance 1
2 Estado de la integración de Sistemas 3
2.1 Sistemas de información 3
2.2 Sistemas ERP / MRP 5
2.3 Sistemas MES 9
2.4 Integración de Sistemas 11
2.5 Estándar ANSI/ISA-95 13
2.5.1 B2MML 18
3 Escenario para la Integración de Sistemas 21
3.1 Descripción del scenario a desarrollar 21
3.2 Odoo 21
3.2.1 El módulo MRP de Odoo 22
3.3 MES PROMIA 22
3.3.1 Flujo de trabajo de PROMIA 23
3.3.2 Conceptos clave de PROMIA 24
4 Desarrollo de la prueba de concepto 26
4.1 Objetivos, alcance y descripción del escenario 26
4.2 Desarrollo en Odoo 30
4.2.1 Modificaciones en el flujo de trabajo del módulo MRP de Odoo 30
4.2.2 Desarrollo de módulo isa95mrp 34
4.2.3 Recepción de mensajes por parte del MES 41
4.3 Desarrollo en PROMIA 42
4.3.1 Desarrollo de aplicación CRUD de PROMIA 42
4.3.2 Desarrollo de Webservice en aplicación PROMIA 46
4.3.3 Desarrollo para el traslado de estado finalizado desde PROMIA a Odoo 47

xiii
4.4 Desarrollo del Middleware 49
4.4.1 Desarrollo de Webservice de alta de órdenes de fabricación de Odoo en PROMIA 49
4.4.2 Desarrollo de Webservice de finalización de órdenes de fabricación de PROMIA en Odoo 49
4.5 Integración entre el ERP y el MES en acción 51
4.5.1 Flujo de información del ERP al MES 51
4.5.2 Flujo de información del MES al ERP 56
4.6 Descripción y recomendaciones de Seguridad, Infraestructura y Hardware 60
5 Conclusiones y líneas futuras 62
5.1 Conclusiones 62
5.2 Líneas de trabajo futuras 63
Referencias 64
Anexos 66
A. Anexo A: Funcionalidades del módulo MRP de Odoo 66
Entorno de trabajo con Odoo 66
Introducción al módulo MRP de Odoo 68
Funciones adicionales del módulo MRP de Odoo 84
B. Anexo B: Fichero B2MML generado con el módulo isa95mrp de Odoo 112
C. Anexo C: Código del módulo isa95mrp de Odoo 116
D. Anexo D: Código del Servicio Web del MES PROMIA 129
E. Anexo E: Fichero B2MML generado por el MES PROMIA 130

xiv
ÍNDICE DE TABLAS

Tabla 4–1. Correspondencias B2MML-Odoo 40


Tabla 4–2. Correspondencias B2MML-Odoo 48

xv
ÍNDICE DE FIGURAS

Figura 2-1. Agrupaciones de programas comerciales (Fuente: Santos et al., (Los Sistemas Integrales de
Información del Siglo XXI, 2000)) 4
Figura 2-2. Evolución de los sistemas de Planificación (Fuente: (Implantación de un sistema ERP en una
organización, 2005)) 5
Figura 2-3. Estructura de un Sistema MRP (Fuente: (Evolución en los sistemas de gestión empresarial. Del
MRP al ERP., 2000)) 6
Figura 2-4. Estructura de un Sistema MRP II (Fuente: (Evolución en los sistemas de gestión empresarial. Del
MRP al ERP., 2000)) 7
Figura 2-5. Estructura de un Sistema ERP (Fuente: (Evolución en los sistemas de gestión empresarial. Del
MRP al ERP., 2000)) 8
Figura 2-6. Integración de Sistemas de Gestión Empresarial (Fuente: (Evolución en los sistemas de gestión
empresarial. Del MRP al ERP., 2000)) 9
Figura 2-7. Contexto de los sistemas MES (Fuente: (MES explained: A high level vision. White Paper 6,
1997)) 11
Figura 2-8. Integración Horizontal de Sistemas (ESB) 12
Figura 2-9. Integración de Sistemas en Estrella 13
Figura 2-10. Integración de Sistemas mediante Formato de datos común 13
Figura 2-11. Modelo funcional de control empresarial de ISA-95 (Fuente: (A Study on OPC Specifications.
Perspective and Challenges, 2010)) 14
Figura 2-12. Jerarquía funcional de ISA-95 (Fuente: (Estándar ANSI/ISA-95 partes 1, 2, 3 y 5)) 15
Figura 2-13. Niveles funcionales de ISA-95 (Fuente: (Estándar ANSI/ISA-95 partes 1, 2, 3 y 5)) 16
Figura 2-14. Información intercambiada en ISA-95 (Fuente: (Estándar ANSI/ISA-95 partes 1, 2, 3 y 5)) 17
Figura 2-15. Modelo de Intercambio de Información de la Producción en ISA-95 (Fuente: (Estándar
ANSI/ISA-95 partes 1, 2, 3 y 5)) 18
Figura 2-16. Modelos de Objetos del Rendimiento de la Producción de ISA-95 (Fuente: (MESA)) 19
Figura 2-17. Esquema B2MML del Objeto Production Response (Fuente: (MESA)) 20
Figura 3-1. Arquitectura del Sistema PROMIA (Fuente: (Departamento de Organización Industrial y Gestión
de Empresas de la Universidad de Sevilla, 2014)) 23
Figura 4-1. Integración de Odoo-PROMIA. Iniciar Producción 27
Figura 4-2. Integración Odoo-PROMIA. Finalizar Producción 28
Figura 4-3. Diagrama de estado de órdenes de producción entre sistemas 29
Figura 4-4. Entrada en modo desarrollador. Acceso a ventana “Acerca de” 30
Figura 4-5. Entrada en modo desarrollador. Ventana "Acerca de" 31
Figura 4-6. Edición de flujo de trabajo. Menú Debug 31
Figura 4-7. Edición de flujo de trabajo. Listado de Flujos de trabajo 32
Figura 4-8. Edición de flujo de trabajo. Vistas de Flujos de trabajo disponibles 32

xvi
Figura 4-9. Edición de flujo de trabajo. Diagrama de Flujo de trabajo de órdenes de producción 32
Figura 4-10. Edición de flujo de trabajo. Formulario de nuevo nodo 33
Figura 4-11. Edición de flujo de trabajo. Formulario de transición desde ready hacia send_MES 33
Figura 4-12. Edición de flujo de trabajo. Formulario de transición desde send_MES hacia in_production 34
Figura 4-13. Edición de flujo de trabajo. Diagrama de Flujo de trabajo de órdenes de producción modificado
34
Figura 4-14. Desarrollo de módulo en Odoo. Fichero __openerp__.py 35
Figura 4-15. Desarrollo de módulo en Odoo. Fichero isa95mrp_workflow.xml definición de nuevo estado
35
Figura 4-16. Desarrollo de módulo en Odoo. Fichero isa95mrp_workflow.xml definición de nuevas
transiciones 36
Figura 4-17. Desarrollo de módulo en Odoo. Fichero isa95mrp_workflow.xml redefinición de transiciones
existentes 36
Figura 4-18. Desarrollo de módulo en Odoo. Fichero isa95mrp_view.xml definición de nuevo estado en barra
de estados 36
Figura 4-19. Desarrollo de módulo en Odoo. Fichero isa95mrp_view.xml definición y modificación de
botones 37
Figura 4-20. Desarrollo de módulo en Odoo. Fichero isa95mrp_view.xml definición botón cancel 37
Figura 4-21. Desarrollo de módulo en Odoo. Fichero isa95mrp.py definición de clase 37
Figura 4-22. Desarrollo de módulo en Odoo. Fichero isa95mrp.py definición función action_send_MES 38
Figura 4-23. Desarrollo de módulo en Odoo. Instalación de Módulo isa95mrp 38
Figura 4-24. Desarrollo de módulo en Odoo. Instalación de Módulo isa95mrp. Detalles del módulo 39
Figura 4-25. Desarrollo de módulo en Odoo. Instalación de Módulo isa95mrp. Detalles técnicos del módulo
39
Figura 4-26. Desarrollo de módulo en Odoo. Instalación de Módulo isa95mrp. Módulo isa95mrp instalado
40
Figura 4-27. Página principal de la aplicación web del MES PROMIA 43
Figura 4-28 - Listado de Presupuestos de la aplicación web del MES PROMIA 44
Figura 4-29 - Formulario de edición de Presupuestos en la aplicación web de PROMIA 44
Figura 4-30 - Listado de Ots de la aplicación web del MES PROMIA 45
Figura 4-31 - Formulario de edición de Ots en la aplicación web de PROMIA 46
Figura 4-32. Operación addManufacturingOrder del Servicio Web del MES PROMIA 47
Figura 4-33. Función parse2Database del MES PROMIA 47
Figura 4-34. Función edit de la clase P520OtFacade del MES PROMIA 48
Figura 4-35. Servicio Web sendToMES del Sistema Middleware 49
Figura 4-36. Servicio Web sendToERP del Sistema Middleware 50
Figura 4-37 - Función endManufacturingOrder del Sistema Middleware 50
Figura 4-38. Listado de órdenes de producción del módulo MRP de Odoo 51

xvii
Figura 4-39 - Formulario de orden de producción MO00073 en estado “Nuevo” 52
Figura 4-40 - Formulario de orden de producción MO00073 en estado Esperando materias primas 52
Figura 4-41 - Formulario de orden de producción MO00073 en estado Listo para producir 53
Figura 4-42 - Formulario de orden de producción MO00073 en estado Producción iniciada tras generación de
fichero B2MML 53
Figura 4-43 - Fichero B2MML generado para la orden MO00073 54
Figura 4-44 - Página inicial de la aplicación web MES PROMIA 55
Figura 4-45 - Listado de Presupuestos en el MES PROMIA 56
Figura 4-46 - Listado de órdenes de trabajo del MES PROMIA 56
Figura 4-47. Orden de producción en estado Producción Iniciada 57
Figura 4-48. Detalle de producto en Odoo 57
Figura 4-49. Formulario de orden de trabajo en el MES 58
Figura 4-50. Detalle de orden de trabajo modificada en el MES 59
Figura 4-51. Repositorio de ficheros B2MML generados por el MES 59
Figura 4-52. Orden de producción en estado Realizado en Odoo 60
Figura 4-53. Detalle de producto en Odoo. Se observa que se ha incrementado el número de unidades 60
Figura 4-54. Esquema Físico de Integración de Sistemas 61
Figura 4-55 - Esquema Físico de Integración de Sistemas con bases de datos en servidores independientes
61
Figura A-1. Página de Login de Odoo 66
Figura A-2. Página de gestión de base de datos de Odoo 67
Figura A-3. Página de creación de base de datos en Odoo 67
Figura A-4. Página de aplicaciones en línea de Odoo antes de instalar el módulo MRP 68
Figura A-5. Página de Aplicaciones en línea de Odoo tras la instalación de MRP 68
Figura A-6. Página principal del módulo MRP de Odoo 69
Figura A-7. Página principal de Productos del módulo MRP de Odoo 70
Figura A-8. Formulario de creación de Productos en el módulo MRP de Odoo 70
Figura A-9. Página inicial de Lista de Materiales de Producto del módulo MRP de Odoo 71
Figura A-10. Formulario de creación de Listas de Materiales en el módulo MRP de Odoo 71
Figura A-11. Lista de materiales de Producto en el módulo MRP de Odoo 72
Figura A-12. Lista de materiales de Producto finalizada 72
Figura A-13. Formulario de creación de Orden de Fabricación 73
Figura A-14. Formulario de creación de Orden de Fabricación 74
Figura A-15. Listado de Órdenes de Fabricación 74
Figura A-16. Vista Calendario de ördenes de Fabricación 75
Figura A-17. Vista Calendario Filtrado de ördenes de Fabricación. 75
Figura A-18. Vista Tablero de Órdenes de Fabricación 76
Figura A-19. Formulario de Orden de Fabricación en estado Esperando Materias Primas 76

xviii
Figura A-20. Formulario de Orden de Fabricación en estado Listo para Producir 77
Figura A-21. Ventana de confirmación de producción de Orden de Fabricación 77
Figura A-22. Formulario de Orden de Fabricación en estado Realizado 78
Figura A-23. Formulario de Lista de Materiales de Producto (con acciones desplegadas) 78
Figura A-24. Formulario de Lista de Materiales de Producto 79
Figura A-25. Listado de lista de materiales de producto 79
Figura A-26. Formulario de creación de Orden de producción en estado Nuevo. Selección de lista de
materiales 80
Figura A-27. Formulario de creación de Orden de producción en estado Listo para producir 80
Figura A-28. Formulario de creación de Orden de producción en estado Producción iniciada 81
Figura A-29. Formulario de creación de Orden de producción en estado Producción iniciada con materiales
consumidos. 81
Figura A-30. Ventana de confirmación de Orden de Producción 82
Figura A-31. Formulario de Orden de producción en estado Realizado 82
Figura A-32. Formulario de Lista de materiales con rangos de fechas para los materiales 83
Figura A-33. Formulario de creación de Orden de producción con fecha de fabricación posterior a la fecha de
disponibilidad de materiales 83
Figura A-34. Lista de Materiales del producto Nueva Placa Base 84
Figura A-35. Formulario de creación de orden de producción de producto con materiales que han de ser
fabricados 85
Figura A-36. Formulario de Orden de fabricación en estado Realizado 85
Figura A-37. Informe de Valoración de Inventario 86
Figura A-38. Informae de Valoración de inventario con información desglosada 86
Figura A-39. Tablero de productos en el módulo de Inventario 87
Figura A-40. Formulario de creación de Ajuste de Inventario 88
Figura A-41. Formulario de ajuste de inventario en proceso 88
Figura A-42. Formulario de ajuste de inventario validado 89
Figura A-43. Tablero de Productos 89
Figura A-44. Formulario de creación de Orden de fabricación para subproducto 90
Figura A-45. Formulario de Orden de fabricación para subproducto en estado Realizado 90
Figura A-46. Tablero de Productos en el módulo Inventario. 91
Figura A-47. Tablero de Productos en el módulo Inventario 91
Figura A-48. Formulario de Producto. Estableciendo fabricación bajo demanda. 92
Figura A-49. Formulario de Orden de producción en estado Esperando materias primas 92
Figura A-50. Listado de Órdenes de fabricación. Orden de producción de subproducto generada
automáticamente 93
Figura A-51. Formulario de Orden de fabricación de producto intermedio en estado Realizado 93

xix
Figura A-52. Listado de órdenes de fabricación. Orden de producción de producto pasa automáticamente a
estado Listo para producir 94
Figura A-53. Formulario de Orden de producción en estado Realizado 94
Figura A-54. Formulario de Lista de Materiales de Producto 95
Figura A-55. Página de detalle de producto 95
Figura A-56. Página de detalle de producto 96
Figura A-57. Ventana de actualización de cantidad de producto en stock 96
Figura A-58. Formulario de Orden de producción de producto compuesto por subproductos en estado
Esperando materias primas 97
Figura A-59. Listado de Órdenes de producción. Se han creado automáticamente dos órdenes de productos
intermedios del producto final 97
Figura A-60. Formulario de Orden de producción de producto intermedio que depende de subproducto 98
Figura A-61. Listado de Órdenes de producción. Producto intermedio finalizado 98
Figura A-62. Listado de Órdenes de producción. Producto intermedio finalizado 99
Figura A--63. Formulario de Producto. 100
Figura A-64. Formulario de Producto 100
Figura A-65. Formulario de reglas de abastecimiento de producto 101
Figura A-66. Página de Lista de materiales de producto 102
Figura A-67. Formulario de Producto con reglas de abastecimiento 102
Figura A-68. Página de confirmación de ejecución de reglas de reabastecimiento 103
Figura A-69. Listado de Órdenes de producción. Se crea orden de fabricación automática a partir de regla de
abastecimiento 103
Figura A-70. Formulario detalle de producto tras la ejecución de la orden de fabricación de reabastecimiento
104
Figura A-71. Página de configuración del módulo MRP. Se señala la opción para gestionar las órdenes de
producción como órdenes de trabajo 104
Figura A-72. Página inicial de Centros de producción 105
Figura A-73. Formulario de creación de centro de trabajo 106
Figura A-74. Página inicial de Rutas de Producción 107
Figura A-75. Formulario de creación de Rutas de producción 108
Figura A-76. Ventana de creación de operaciones en el centro de producción 108
Figura A-77. Formulario de Ruta de producción 109
Figura A-78. Formulario de Lista de Materiales con Ruta de producción asignada 109
Figura A-79. Formulario de creación de producto con Ruta de producción asignada 110
Figura A-80. Formulario de orden de producción con orden de trabajo creada automáticamente 110
Figura A-81. Listado de órdenes de producción 111

xx
1 INTRODUCCIÓN

“La simplicidad llevada al extremo se convierte en elegancia.”

Jon Franklin.

n el presente capítulo estableceremos los objetivos generales y específicos que se pretenden alcanzar con

E este trabajo fin de máster. Además, estableceremos el alcance del trabajo para dejar claro lo que se
pretende hacer y lo que queda fuera de las motivaciones y objetivos del trabajo.

1.1 Objeto
1.1.1 Objetivos generales
El objetivo general del proyecto es el de realizar una prueba de concepto de las capacidades del estándar ISA-
95 para la integración entre un sistema ERP y un sistema MES. Para llevar a cabo este objetivo general se han
debido llevar a cabo los objetivos específicos que se explican en la siguiente sección.

1.1.2 Objetivos específicos


Los objetivos específicos necesarios para llevar a cabo el objetivo general se desglosan en los siguientes
puntos:
• Descripción del sistema ERP Odoo, centrándonos más concretamente en su módulo de producción
MRP.
• Definición y especificaciones del estándar ANSI/ISA-95 y su aplicación práctica mediante la
generación de ficheros B2MML (Business to Manufacturing Markup Language).
• Explicación del MES PROMIA y su base de datos que nos servirá para la integración de ambos
sistemas.
• Especificación y desarrollo de la integración del módulo MRP de Odoo con el MES PROMIA
mediante un sistema Middleware que utilice ficheros B2MML para el traspaso de información entre
sistemas.
• Descripción de la solución propuesta para la integración y recomendaciones de seguridad,
infraestructura tecnológica y hardware de la implementación realizada.

1.2 Alcance
El alcance del trabajo se limita a cubrir los objetivos descritos en el apartado anterior. El aspecto más
2 Introducción

importante es el desarrollo de una herramienta middleware que permita la integración del ERP seleccionado
(Odoo) y el sistema MES de la forma más transparente posible para ambos sistemas.
Desde el punto de vista tecnológico, los desarrollos a efectuar se realizarán con tecnologías de código abierto
en la medida de lo posible, entre las que se encuentran los lenguajes de programación Python (para
modificaciones en el ERP Odoo) y Java (para el desarrollo de la herramienta middleware y simulación del
sistema MES a partir de su base de datos), además del uso de una plataforma para la publicación de servicios
web.
De forma más detallada se procederá a la modificación del flujo de trabajo de las órdenes de producción del
módulo MRP de Odoo. Estas órdenes de Odoo no pasarán a estado “En producción” hasta que no se realice el
envío de la orden al sistema MES y éste confirme su recepción correcta. Además, a la hora de finalizar las
órdenes de producción, éstas pasarán a estado “Realizado” cuando se reciba por parte del MES el mensaje de
que, efectivamente, se ha finalizado la orden.
Se creará un módulo en Odoo que, cuando se detecte que una orden de fabricación pasa a estado “Enviar al
MES” por parte del usuario, se genere el fichero B2MML para ser publicado por el servicio web que gestiona
el sistema Middleware. En el otro extremo, cuando se detecte la recepción del fichero B2MML, el middleware
realizará la inserción de la orden de producción en la base de datos del MES e informará al sistema ERP el
registro de la misma. Cuando la producción finalice, el middleware enviará una señal a Odoo (mediante el
middleware) para que la orden de producción pase a estado “Realizada”.
Para la integración de sistemas nos centraremos exclusivamente en las órdenes de producción, obviando el
resto de posibles flujos de información que debería existir entre el ERP y el MES (productos, materiales,
equipamiento, recursos humanos y físicos, etc.), por lo que tan sólo se controlará que las órdenes de
producción generadas en el ERP sean enviadas y almacenadas por el MES y que el estado de dichas órdenes
sea equivalente en ambos sistemas.
Por otro lado, se tratará el sistema MES como una caja negra, por lo que no entraremos en los procedimientos
internos que este necesite para efectuar las órdenes de fabricación. Tan sólo tendremos en cuneta que para la
correcta creación de una orden de trabajo en el MES, ésta debe tener asociado un presupuesto aprobado que
permita el inicio del proceso de producción.
2 ESTADO DE LA INTEGRACIÓN DE SISTEMAS

La mejor forma de predecir el futuro es implementarlo.

David Heinemeier Hansson

ras especificar los objetivos y alcance del trabajo, en el presente capítulo vamos a realizar un repaso del

T estado del arte en lo que respecta a la integración de sistemas. Para ello, vamos a definir qué es un
sistema de información, los disitintos tipos de sistemas a los que nos vamos a referir en este trabajo y los
distintos tipos de integraciones que existen.

2.1 Sistemas de información


Un sistema de información (SI) es un conjunto de elementos interrelacionados con el propósito de prestar
atención a las demandas de información de una organización, para elevar el nivel de conocimientos que
permitan un mejor apoyo a la toma de decisiones y desarrollo de acciones Fuente especificada no válida..
Un sistema de información también se puede definir como el conjunto de elementos que interactúan entre sí
con el fin de apoyar las actividades de una empresa o negocio. Dichos elementos son:
• el equipo computacional: el hardware necesario para que el sistema de información pueda operar,
• el recurso humano que interactúa con el Sistema de Información, el cual está formado por las personas
que utilizan el sistema Fuente especificada no válida..
En definitiva, se podría definir un sistema de información como el que está formado por un conjunto de
funciones y componentes (físicos y humanos) interrelacionados entre sí, cuyo objetivo es la obtención,
procesamiento, almacén y salida de la información procesada que facilite la toma de decisiones en una
organización.
Para entender mejor los Sistemas de Información, veremos a continuación los tipos de sistemas de información
que se pueden encontrar en una empresa para ayudar a la toma de decisiones de distintos aspectos de la gestión
empresarial.
Santos et al Fuente especificada no válida. realizaron una agrupación de sistemas de información
comerciales a partir de 5 aproximaciones a la gestión integrada de la empresa: Planificación, ingeniería,
logística, control de producción y comercial. Los veremos con más detalle a continuación:
Aplicaciones que gestionan la función de planificación:
Dentro de esta aproximación se pueden incluir las herramientas de planificación de materiales conocidas como
MRP (Material Requirement Planning) a las que posteriormente se le añadieron la gestión de la capacidad
(CRP – Capacity Requirement Planning) y la gestión de los recursos financieros para dar paso a las
4
Estado de la integración de Sistemas

aplicaciones conocidas como MRP II (Manufacturing Resource Planning). Tiempo más tarde, en los años 90,
surgen las aplicaciones ERP (Enterprise Resource Planning), término acuñado por Gartner Group (Lauchbury
y Ptak, 1998). En 1997, META Group bautizó a los sistemas ERP que estudiaba como ERM (Enterprise
Resource Management).
Tanto los ERP como los ERM no son más que una evolución de los MRP II que mantienen su misma
funcionalidad y estructura.
Aplicaciones que gestionan la función de ingeniería:
Los primeros sistemas que informatizaron los diseños de los productos fueron los conocidos como CAD
(Computer Aided Design). Los CAD se enriquecieron con funciones CAE (Computer Aided Engineering)
para estudiar el comportamiento mecánico de los diseños. Finalmente, los programas CAM (Computer Aided
Manufacturing) permiten la conexión con la fabricación de los productos diseñados.
Actualmente, para integrar en una sola herramienta todos los datos que monitorizan el ciclo de vida de un
producto se conocen como aplicaciones PDM (Product Data Management).
Aplicaciones que gestionan la función logística:
Se ha pasado desde los programas DRP (Distribution Resource Planning) que permiten la gestión de la cadena
de suministro a programas SCM (Supply Chain Management) que pretenden abarcar todas las relaciones
cliente-proveedor que tienen lugar tanto dentro como fuera de la empresa.
Aplicaciones que gestionan la función de control de producción:
Los programas conocidos como SFC (Shop Floor Control) recogían datos de las máquinas y los almacenaba
para su posterior tratamiento. En 1992 se fundó la asociación sin ánimo de lucro MESA (Manufacturing
Enterprise Solutions Association) formada por empresas proveedoras de programas de control de producción
llamadas aplicaciones MES (Manufacturing Execution System). Estos sistemas los veremos en siguientes
apartados.
Aplicaciones que gestionan la función comercial:
Engloba las herramientas que pretenden gestionar la información necesaria para ofrecer un servicio de calidad
a los clientes, son las aplicaciones llamadas CRM (Customer Relationship Management) que vienen siendo
desarrolladas por las empresas de desarrollo de sistemas ERP y tienen en cuenta las capacidades de producción
y los costes.

Figura 2-1. Agrupaciones de programas comerciales (Fuente: Santos et al., Fuente especificada no válida.)
En el gráfico de la figura 2-1 se muestran todos los distintos sistemas de información descritos y su
solapamiento en las funciones de gestión dentro de la empresa.
Integración de sistemas ERP y MES mediante el estándar ANSI/ISA-95 5

De los distintos tipos que se han explicado, nos centraremos a continuación en los sistemas de información
ERP/MRP y MES enfocados los primeros en la planificación de recursos de la empresa y en el control de
producción los segundos.

2.2 Sistemas ERP / MRP


Los sistemas de información conocidos como ERP (Enterprise Resources Planning) por sus siglas en inglés, se
consideran por muchos autores la evolución de los sistemas MRP (Material Requirement Planning), y más
concretamente de los sistemas MRP II (Manufacturing Resources Planning) al extender sus funcionalidades a
otras áreas de la empresa.

Figura 2-2. Evolución de los sistemas de Planificación (Fuente: Fuente especificada no válida.)
Como establecen los autores Delgado y Marín Fuente especificada no válida., las herramientas MRP surgen
a comienzos de los años 70 del siglo XX como respuesta al problema de determinar cuándo lanzar las órdenes
de aprovisionamiento que hasta entonces se realizaban mediante la técnica de punto de pedido. Los MRP
integran el cálculo de necesidades y métodos específicos de dimensionado de lotes.
Los sistemas MRP presentan una estructura modular como se muestra en la siguiente figura:
6
Estado de la integración de Sistemas

Figura 2-3. Estructura de un Sistema MRP (Fuente: Fuente especificada no válida.)


En dicha estructura destaca el plan maestro de producción, que es donde se establecen las cantidades de
productos terminados a obtener en un tiempo determinado a partir de los pedidos y las previsiones de ventas.
La lista de materiales (BOM: Bill Of Materials) contiene la información de todos los artículos y de la
composición de los productos terminados. En el proceso de planificación de necesidades de materiales se
establecen las órdenes de compra y producción de todos los artículos necesarios para cumplir el plan maestro
de producción.
Para ello, además de conocer la composición de los productos, se necesita determinar los plazos de
reaprovisionamiento y la disponibilidad de materiales mediante el control de inventario. Los procesos de
compras y producción proporcionan información acerca de la recepción de órdenes prevista para determinar la
disponibilidad de material en un horizonte próximo. De esta manera, dichas funciones de compras y
producción generan las órdenes de compra y producción que se necesiten para satisfacer el plan maestro de
producción.
La utilización de sistemas MRP establece una forma de planificar la producción mediante la anticipación: se
determina qué se quiere hacer en el futuro y, a partir de ahí, surge la secuencia de acciones a emprender para
poder realizarlo.
Estos sistemas MRP presentan un inconveniente claro en lo referente a la planificación de la producción, ya
que no se tiene en cuenta la disponibilidad de recursos para llevar a cabo las órdenes de producción sugeridas;
por lo tanto, pueden aparecer órdenes de producción irrealizables y que finalmente cuestionan la verosimilitud
del resto de resultados de la planificación.
En los años 80 aparecen los sistemas MRP II para solucionar el problema de gestión de la capacidad
productiva disponible en los centros de producción para realizar los planes de producción que sugerían los
MRP. También se les denomina “MRP con capacidad finita” porque contrasta la disponibilidad de los recursos
necesarios para la ejecución de las órdenes de producción planificadas.

Figura 2-4. Estructura de un Sistema MRP II (Fuente: Fuente especificada no válida.)


Como se puede apreciar en la figura 2-4, los sistemas MRP II incluyen la planificación de necesidades de
capacidad en la planificación de órdenes de producción. Para poder contrastar la capacidad existente con el
plan de producción, se incluye el módulo de centros de trabajo que define la disponibilidad de recursos del
sistema. También se incluye información sobre rutas que determinan qué centros de trabajo y qué intensidad
de uso requiere cada artículo de fabricación.
Gracias a la planificación de necesidades de capacidad se calcula la capacidad disponible por cada centro de
Integración de sistemas ERP y MES mediante el estándar ANSI/ISA-95 7

trabajo frente a la carga resultante de la ejecución de las órdenes de producción planificadas en un horizonte de
tiempo determinado. Esta planificación de las necesidades de capacidad permite tomar decisiones respecto a la
capacidad de los centros de trabajo como la modificación de dicha capacidad, la subcontratación de ciertos
procesos o la modificación de rutas o fechas de las órdenes de producción.
En la década de los 90, surge la necesidad de integrar diferentes áreas de la empresa (ingeniería, ventas,
fabricación o compras) bajo un mismo sistema de información. Así aparecen los sistemas ERP que abordan la
planificación de recursos humanos o financieros junto con la planificación de necesidades de materiales y de
recursos de producción. Estos sistemas dotan a las empresas de un sistema de información sin duplicidades
respecto a la información utilizada por diferentes componentes de la empresa.

Figura 2-5. Estructura de un Sistema ERP (Fuente: Fuente especificada no válida.)


La tendencia de los últimos tiempos es la de la integración interempresarial mediante el intercambio
electrónico de datos (EDI: Electronic Data Interchange, Internet). Estas herramientas pretenden integrar la
información de los sistemas ERP de distintas empresas y son un elemento fundamental en la gestión de la
cadena de suministros (Supply Chain Management) que permite el intercambio de información por parte de
todos los agentes implicados en un canal logístico desde las materias primas hasta los productos terminados.
8
Estado de la integración de Sistemas

Figura 2-6. Integración de Sistemas de Gestión Empresarial (Fuente: Fuente especificada no válida.)

Existen dos tipos de integraciones entre sistemas: los conocidos como B2B (Business To Business) y B2C
(Business To Consumer). Los sistemas B2B pretenden mejorar la interacción entre empresas mediante el uso
de sistemas de información compartidos. Las herramientas B2C están orientadas a la relación con los clientes
finales utilizando las nuevas tecnologías de comunicación.
El valor de la Planificación de los Recursos Empresariales (ERP) en los negocios.
Como establecen Díaz et al. Fuente especificada no válida., la implantación de un sistema ERP en una
organización supone una ventaja competitiva o, en su defecto permitirá alinearse comparativamente con sus
competidores. Las ventajas que aporta un ERP bien implantado suponen una reducción de costes, aumento de
la productividad y la automatización de procesos, ya que se establece una solución que permite la integración
total de todas las operaciones de la empresa con el fin de tener una gestión adecuada en cada una de sus áreas.

2.3 Sistemas MES


Los sistemas MES, por sus siglas en inglés (Manufacturing Execution Systems) son los Sistemas de Ejecución
de la Fabricación. Éstos aparecen a mediados de la década de los 90 como una evolución de los conocidos
como CIM (Computer Integrated Manufacturing).
Como se apuntaba en el apartado anterior, los sistemas MRP II alcanzaron su apogeo a finales de los años 80 y
principios de los 90. Los sistemas MES surgen para complementar los sistemas MRP II, y, además, extienden
sus capacidades incorporando una aproximación al control de la ejecución de la fabricación Fuente
especificada no válida..
Los objetivos de los sistemas MES se pueden englobar en los siguientes:
• Entrega y control de órdenes de producción en tiempo real desde su lanzamiento hasta la obtención
del producto terminado.
Integración de sistemas ERP y MES mediante el estándar ANSI/ISA-95 9

• Optimización de actividades de producción y mejora de la productividad global.


En lo que respecta a las mejoras que introduce un sistema MES en el proceso productivo de una empresa, la
asociación MESA publica una investigación que realiza un estudio entre varias empresas industriales que
utilizan sistemas MES, dicho artículo titulado “The Benefits of MES: A report from the field” Fuente
especificada no válida. ofrece las siguientes estadísticas:
• Reducción del ciclo de producción un 40% o más.
• Reducción o eliminación del tiempo de entrada de datos un 75% o más.
• Reducción de los trabajos en proceso en un 25% o más.
• Reducción o eliminación de papeleo entre turnos en un 50% o más.
• Reducción de plazos de entrega en un 30% o más.
• Mejora de la calidad del producto. Reduce defectos en un 15%.
• Reducción de pérdida de planos y documentos en un 57%.
MESA (la Manufacturing Enterprise Solution Association) es una asociación nacida en 1992 que agrupa a
proveedores de sistemas MES. Dicha asociación define las funciones y actividades que se pueden cubrir con
un sistema MES. Más concretamente, las 11 funciones que define MESA son las siguientes:
1) Resource Allocation and Status (Localización y Estado de Recursos)
2) Operation/Detail Scheduling (Programación de operaciones)
3) Dispatching Production Units (Envío de unidades de producción)
4) Document Control (Control de Documentación)
5) Data Collection/Acquisition (Adquisición de datos)
6) Labor Management (Gestión de mano de obra)
7) Quality Management (Gestión de la calidad)
8) Process Management (Gestión de los procesos)
9) Maintenance Management (Gestión del mantenimiento)
10) Product Tracking and Genealogy (Trazabilidad y genealogía de productos)
11) Performance Analysis (Análisis de rendimiento)
Los sistemas MES no suelen trabajar de forma autónoma y están enfocados a interactuar con otros sistemas de
información que cubren la gestión de la empresa, como muestra, la siguiente figura de MESA:
10
Estado de la integración de Sistemas

Figura 2-7. Contexto de los sistemas MES (Fuente: Fuente especificada no válida.)

Las necesidades de comunicación más frecuentes de los MES se producen con los sistemas ERP para la
planificación de la producción y con los sistemas de control de la producción a pie de planta.
Resulta, por tanto, interesante la integración entre los sistemas ERP y MES para que exista una
implementación del paso de la planificación de la producción al control de la misma, ya que, mientras que una
fábrica ejecuta las órdenes en tiempo real, los ERP habrán realizado una planificación previa con unas
hipótesis de funcionamiento fijadas a priori, pero no tienen constancia de las operaciones realmente efectuadas
y no tienen supervisión ni control en tiempo real del proceso productivo. Estas funciones son las propias de los
MES con quienes se tendrán que integrar los ERP para compartir información y sacar el máximo partido de las
operaciones de fabricación.

2.4 Integración de Sistemas


Según podemos ver en la web techopedia Fuente especificada no válida., se conoce a la Integración de
Sistemas como el proceso de las Tecnologías de la Información mediante el cual se unen diferentes
subsistemas o componentes para dar lugar a un único sistema mayor. Con la Integración de sistemas, nos
aseguramos que cada uno de los sistemas integrados funciona según sus requerimientos de forma individual,
pero colaboran entre ambos a dar un servicio más amplio a las empresas. La Integración de Sistemas también
se utiliza para dar valor añadido a un sistema mediante la inclusión de nuevas funcionalidades aportadas por
otros sistemas.
En las últimas décadas, la agregación de diferentes componentes de sistemas o subsistemas que cooperan para
proporcionar una funcionalidad completa ha sido el énfasis de las industrias que utilizan las Tecnologías de la
Información. Esto se conoce como el enfoque modular del desarrollo de sistemas, y el proceso de integración
de sistemas se encuentra en las últimas fases del ciclo de desarrollo de sistemas. Existen diferentes métodos de
Integración de sistemas:
• Integración Horizontal: Implica la creación de un único subsistema que se destina a ser la única
interfaz entre todos los otros subsistemas, asegurando que sólo hay una interfaz entre todos los
subsistemas integrados y se pueda reemplazar con otro sin afectar al resto utilizando datos e interfaces
totalmente distintos. También se conoce como Bus de Servicios Empresariales, o ESB por sus siglas
en inglés (Enterprise Service Bus) generando una Arquitectura orientada al Servicio (SOA, Service
Oriented Architecture).
Integración de sistemas ERP y MES mediante el estándar ANSI/ISA-95 11

Figura 2-8. Integración Horizontal de Sistemas (ESB)

• Integración Vertical: Los subsistemas se integran de acuerdo a su funcionalidad creando silos de


entidades funcionales, comenzando con la funcionalidad básica más baja hacia arriba. Este es un
método rápido, pero que acaba siendo más caro en el tiempo porque para implementar nuevas
funcionalidades, se deben crear nuevos silos.
• Integración en Estrella: Cada subsistema se conecta con múltiples subsistemas, de forma que los
diagramas de interconexión tienen aspecto de estrella.
12
Estado de la integración de Sistemas

Figura 2-9. Integración de Sistemas en Estrella

• Formato de Datos Común: Este tipo de integración permite evitar el uso de adaptadores desde y
hacia cada uno de los formatos de datos de las aplicaciones. Los sistemas que utilizan este método
establecen un formato de datos común e independiente de aplicaciones, o bien, se proporciona un
servicio que hace la transformación de datos desde y hacia una aplicación a la aplicación común.

Figura 2-10. Integración de Sistemas mediante Formato de datos común

Para la prueba de concepto que vamos a desarrollar en este trabajo realizaremos una integración horizontal
donde utilizaremos un sistema Middleware como Bus de servicio empresariales; sin embargo, la integración
también tendrá características de formato de datos común por la utilización de ficheros B2MML que
explicaremos en el siguiente capítulo.

2.5 Estándar ANSI/ISA-95


El ISA-95 es un estándar internacional desarrollado por la Sociedad Internacional de Automatización (o ISA
por sus siglas en inglés International Society of Automation) con el objetivo de reducir los costes, riesgos y
errores asociados con la implementación de interfaces entre los sistemas de control empresariales y de
producción Fuente especificada no válida..
El estándar ANSI/ISA-95 define un modelo funcional completo a utilizar en el control empresarial. La
estructura del siguiente modelo no refleja la estructura organizacional dentro de una compañía, si no la
estructura organizacional de las funciones.
Integración de sistemas ERP y MES mediante el estándar ANSI/ISA-95 13

Figura 2-11. Modelo funcional de control empresarial de ISA-95 (Fuente: Fuente especificada no válida.)

La mayor parte de la información descrita en este modelo funcional se puede agrupar en tres grandes áreas:
• Información necesaria para producir un producto.
• Información sobre la capacidad para producir un producto.
• Información sobre la producción real de un producto.
ISA-95 es un estándar internacional en desarrollo para la integración de la empresa con los sistemas de control.
Proporciona un modelo de referencia para la organización de sistemas, asignando el negocio a diferentes
sistemas y el flujo de información entre sistemas. Originariamente es un estándar estadounidense, pero se ha
adoptado como un estándar internacional como IEC/ISO 62246.
El propósito del estándar es:
• Acentuar las buenas prácticas en la integración de sistemas de control con sistemas empresariales
durante todo su ciclo de vida.
• Se puede utilizar para la mejora de las capacidades de integraciones existentes.
• Se puede aplicar sin importar el grado de automatización de los sistemas.
El estándar ISA-95 se centra principalmente en tres áreas y estará dividido en 6 partes:
• Modelos de intercambio de información entre sistemas logísticos del negocio y sistemas de
operaciones de fabricación. (Partes 1, 2 y 5).
• Modelos de actividades en sistemas de operaciones de fabricación. (Parte 3).
14
Estado de la integración de Sistemas

• Modelos de intercambio de información entre sistemas de operaciones de fabricación. (Futuras partes


4 y 6).
A continuación los nombres de cada una de dichas partes:
• ISA 95.00.01 Modelos y Terminología (también IEC/ISO 62264-1).
• ISA 95.00.02 Modelos de Objetos y Atributos (también IEC/ISO 62264-2).
• ISA 95.00.03 Modelos de Actividad de Fabricación (Gestión de Operaciones).
• ISA 95.00.04 Modelos de Objetos y Atributos de la Gestión de Operaciones de Fabricación.
• ISA 95.00.05 Transacciones del Negocio a la Fabricación.
• ISA 95.00.06 Modelo de Servicio de Mensajería.
En este trabajo nos centraremos en analizar las partes 1, 2 y 5, pues son las que se centran en la integración
entre los sistemas de control empresarial y de control de fabricación. En dichas partes, el estándar define un
modelo de jerarquía funcional en 5 niveles.

Figura 2-12. Jerarquía funcional de ISA-95 (Fuente: Fuente especificada no válida.)

En el estándar, estos niveles funcionales se definen así:


• Nivel 0: Define los procesos físicos reales.
• Nivel 1: Define las actividades involucradas en la detección y manipulación de los procesos físicos.
• Nivel 2: Define las actividades de monitorización y control de los procesos físicos.
• Nivel 3: Define las actividades del flujo de trabajo para la producción del producto final deseado.
• Nivel 4: Define las actividades relacionadas con el negocio que necesita gestionar una empresa
industrial.
Integración de sistemas ERP y MES mediante el estándar ANSI/ISA-95 15

Figura 2-13. Niveles funcionales de ISA-95 (Fuente: Fuente especificada no válida.)

Respecto a las correspondencias de estos niveles funcionales definidos por el estándar, queda claro que:
• El nivel 1 se corresponde con dispositivos inteligentes.
• El nivel 2 se corresponde con los sistemas de control como por ejemplo, los Programadores Lógicos
Programables (o PLC por sus sigls en inglés, Programmable Logic Controller).
• El nivel 3 se corresponde con los sistemas de Operaciones de Fabricación (MES, Batch, Sistemas de
Gestión de Información de Laboratorio o LIMS por sus siglas en inglés, Laboratory Information
Management System).
• El nivel 4 se corresponde con los sistemas logísticos del negocio (ERP).
El tipo de información que se define para su intercambio entre los sistemas del nivel 3 y el nivel 4 se muestran
en la siguiente figura:
16
Estado de la integración de Sistemas

Figura 2-14. Información intercambiada en ISA-95 (Fuente: Fuente especificada no válida.)

Dicha información de intercambio se define mediante los modelos de datos formales mediante notación UML
(Unified Modeling Language) y se implementan utilizando esquemas B2MML (Business To Manufacturing
Markup Language). De esta manera, se definen clases, definiciones de materiales e instancias, así como sus
propiedades y valores.
Integración de sistemas ERP y MES mediante el estándar ANSI/ISA-95 17

Figura 2-15. Modelo de Intercambio de Información de la Producción en ISA-95 (Fuente: Fuente


especificada no válida.)

2.5.1 B2MML
B2MML responde a las siglas en inglés Business To Manufacturing Markup Language y no es más que el
lenguaje para el intercambio de información entre los sistemas de gestión del negocio (ERP) y los sistemas de
gestión de la fabricación (MES). Es una implementación completa en XML del estándar ISA-95 en el que se
representan las estructuras de datos definidas en el estándar. Consta de una serie de esquemas XML escritos en
el lenguaje XSD del WWC (World Wide Web Consortium). B2MML fue desarrollado por el WBF (World
Batch Forum), organización que ha quedado incluida dentro de la asociación MESA.
Cualquier empresa que esté interesada en seguir el estándar ISA-95 para proyectos de integración, pueden
utilizar el lenguaje B2MML para la integración entre sistemas del negocio (como los ERP) y sistemas de
gestión de la cadena de suministro con sistemas de fabricación, tales como los sistemas de control y los
sistemas de ejecución de la fabricación (MES). Se puede utilizar libre de cargos, siempre dándole el crédito a
la asociación MESA.
La última versión disponible es la B2MML V0600, que incluye soporte para la parte 4 del ISA-95, lanzada en
2012. El lenguaje B2MML se ha convertido en la implementación estándar por excelencia para las
integraciones entre sistemas del negocio y de la fabricación.B2MML es también una implementación del
estándar ISA-88, que queda fuera del alcance de este proyecto.
Para entender mejor el lenguaje B2MML, veremos un ejemplo, si observamos en objeto de la parte 1 de ISA-
95 “Rendimiento de Producción” (“Production Performance”), veremos que está compuesto de una serie de
“Respuestas de Producción” (“Production Responses”). Por ejemplo, una orden de producción de, digamos,
18
Estado de la integración de Sistemas

1.000 productos, podría ser dividida en planta en 5 lotes de 200. Cada “Respuesta de Producción” se refiere a
un sub-lote de 200. Cada “Respuesta de Producción” está compuesta de una serie de “Respuestas de
Segmento” (“Segment Response”) que, a su vez, se compone de una serie de objetos que contienen los datos
reales de la producción para uno o más pasos del proceso. Mostramos esto en el siguiente diagrama de
modelado de objetos del ISA-95.

Figura 2-16. Modelos de Objetos del Rendimiento de la Producción de ISA-95 (Fuente: Fuente especificada
no válida.)

Este modelado de objetos se representa como un conjunto de esquemas XML que forman el B2MML. Por
ejemplo, a continuación se muestra el objeto de “Respuesta de Producción” (“Production Response”).
Integración de sistemas ERP y MES mediante el estándar ANSI/ISA-95 19

Figura 2-17. Esquema B2MML del Objeto Production Response (Fuente: Fuente especificada no válida.)
3 ESCENARIO PARA LA INTEGRACIÓN DE
SISTEMAS

Hazlo todo tan simple como sea possible, pero no más simple.

Albert Einstein.

n este capítulo vamos a describir los sistemas a integrar mediante la implementación del estándar

E ANSI/ISA-95 explicado en el capítulo anterior. Más concretamente describiremos el sistema ERP Odoo
(antes llamado OpenERP) centrándonos en su módulo MRP y, por otro lado, veremos el sistema MES
PROMIA. Para la integración entre ambos, se utilizarán los ficheros B2MML descritos anteriormente.

3.1 Descripción del scenario a desarrollar


Como se ha visto en el capítulo anterior, el “sueño de la integración” entre sistemas del pasado, está casi
completamente cubierto gracias al estándar ISA-95 y su implementación en B2MML.
Entre este capítulo y el siguiente intentaremos realizar una prueba de concepto mediante la implementación de
una integración transparente para los usuarios entre el sistema ERP de una empresa industrial y su sistema
MES.
El sistema ERP seleccionado es Odoo (antes conocido como OpenERP), por su carácter de código abierto y la
facilidad a la hora de desarrollar nuevos módulos personalizados para modificar su funcionamiento y
adecuarlo a nuestras necesidades.
El sistema MES seleccionado es el llamado PROMIA, por ser el que estaba disponible en el Departamento.
Cabe destacar que la gran mayoría de sistemas MES son sistemas propietarios y suelen estar muy ligados al
fabricante de la infraestructura de fabricación que se encuentre en planta. Este sistema PROMIA es
independiente de la infraestructura.
Para realizar la integración entre ambos sistemas y realizar el intercambio de mensajes B2MML, vamos a
utilizar una arquitectura orientada al servicio (SOA) y nos vamos a valer de servicios web (Web Services) para
el intercambio de ficheros B2MML entre ambos sistemas. Para ello, desarrollaremos un sistema intermedio
(Middleware) que será el encargado de llamar a los servicios web de ambos sistemas cuando reciba la señal
oportuna que lo indique.

3.2 Odoo
OpenERP (en la actualidad, Odoo) es un sistema de gestión empresarial (ERP) de código abierto que no
presenta costes de licencia y cubre las necesidades que pueda tener una empresa en las áreas, entre otras, de
contabilidad y finanzas, ventas, recursos humanos, compras, gestión de almacenes, CRM y fabricación.
Fuente especificada no válida.
OpenERP pasó a denominarse Odoo en su versión 8, en la que se incorporan nuevas funcionalidades web,
como el CMS (Gestor de Contenidos Web), herramientas de blog, un módulo para el comercio electrónico y
funcionalidades para el Marketing Online (Newsletters, encuestas, foros o creación de eventos) que funcionan
Integración de sistemas ERP y MES mediante el estándar ANSI/ISA-95 21

como aplicaciones. Por tanto, la inclusión de dichas funcionalidades web, hacen de OpenERP algo más que un
ERP, por ello el cambio de nombre a Odoo pretende desvincular la marca con la palabra “ERP”. Fuente
especificada no válida.
Debido a su carácter modular, permite la personalización de Odoo con aquellas funcionalidades que se
necesiten sin tener instalado ningún módulo que no se vaya a utilizar. Todos estos módulos funcionan de
forma integrada, sin necesidad de utilizar conectores entre distintas aplicaciones. La modularidad de Odoo, por
tanto, permite añadir o eliminar funcionalidades con todos sus datos unificados y con una misma interfaz web.
Odoo utiliza flujos de trabajo flexibles y personalizables conforme a las necesidades específicas de la empresa.
Permite modificar flujos de trabajo de manera gráfica e intuitiva, así como informes personalizados.
Además, es un sistema de código abierto y libre, disponible bajo licencia AGPL (Affero General Public
License), está basado en estándares abiertos y desarrollado basado en herramientas libres.
Odoo es un sistema orientado a objetos que utiliza el lenguaje de programación Python. Utiliza un esquema
cliente-servidor que permite distribuir el servidor y la base de datos para realizar balanceos de carga y
configuraciones en alta disponibilidad.
También permite realizar modificaciones en el código para tener una mayor personalización del sistema a los
procesos de la empresa, sin limitaciones ni restricciones. Además permite la extensión de las aplicaciones
mediante el desarrollo de módulos personalizados que modifiquen el funcionamiento de Odoo según nuestras
necesidades.
Debido a todas estas características de flexibilidad, código abierto y posibilidades para realizar desarrollos
personalizados, Odoo es el ERP que vamos a utilizar para nuestra prueba de concepto de la integración con un
sistema MES mediante el estándar ISA-95. La versión seleccionada de Odoo es la 9 por ser la última
disponible al comienzo de este trabajo.

3.2.1 El módulo MRP de Odoo

Como se ha comentado en el apartado anterior, Odoo es un sistema completamente modular que cubre todas
las funciones de las empresas. Entre dichas funciones está el proceso de fabricación de productos en el que
Odoo nos ayuda a la programación de las órdenes de fabricación basándose en los recursos disponibles.
Dichos recursos serían las materias primas, mano de obra y la disponibilidad de una determinada máquina.
Estas funciones se consiguen en Odoo gracias al módulo MRP (Manufacturing Resources Planning).
En el Anexo A se puede seguir un recorrido completo al módulo MRP Fuente especificada no válida.. Las
funcionalidades básicas que ofrece este módulo son las siguientes:
• Planificación de recursos de producción: Gestión de lista de materiales, planificación de órdenes de
producción y seguimiento de órdenes de trabajo.
• Programación eficiente de órdenes de fabricación.
• Definición de Datos Maestros flexible: productos, listas de materiales y operaciones de órdenes de
trabajo.
• Flexibilidad en todas las operaciones
• Programación de órdenes de trabajo: comprobando capacidades de los recursos y resolviendo cuellos
de botella.
• Análisis de Inventarios y Producción.
• Completamente integrado con otras operaciones: Ventas, Compras y Contabilidad.
22
Escenario para la Integración de Sistemas

3.3 MES PROMIA


El sistema MES seleccionado para realizar la integración mediante el estándar ISA-95 es el denominado
PROMIA, que es un desarrollo del Departamento de Organización Industrial y Gestión de Empresas de la
Universidad de Sevilla como sistema de control de la producción genérico que se pueda personalizar para la
implementación en distintas empresas.
Más formalmente, PROMIA es un framework de aplicaciones informáticas para el soporte a la toma de
decisiones en la gestión de la fabricación de productos. Así, una implementación del framework PROMIA en
una empresa concreta consta del desarrollo personalizado y la configuración de las distintas aplicaciones y
sistemas, que pueden incluir las siguientes:
• PROMIA – DM: Se trata de la aplicación principal del framework y que contiene la mayor parte de
funcionalidades de soporte a la toma de decisiones, así como a la gestión de datos del sistema (con
excepción de los datos de control de planta, que se introducen con la aplicación de PROMIA –
Control).
• PROMIA – Control: Se trata de un conjunto de interfaces para la introducción de datos de control de
planta.
• PROMIA – DB: Se trata de una base de datos bajo SQL Server que gestiona los elementos
persistentes del framework.

Figura 3-1. Arquitectura del Sistema PROMIA (Fuente: Fuente especificada no válida.)
En nuestros trabajos de integración con el ERP, el funcionamiento interno del MES no será excesivamente
importante, ya que nuestro objetivo principal es modelar e implementar el intercambio de datos entre ambas
aplicaciones; sin embargo, a continuación vamos a detallar los flujos de trabajo y algunas definiciones del
MES PROMIA que pueden resultar interesantes para entender su funcionamiento y el alcance de la
integración que vamos a desarrollar.
Integración de sistemas ERP y MES mediante el estándar ANSI/ISA-95 23

3.3.1 Flujo de trabajo de PROMIA


El flujo de trabajo definido en la aplicación PROMIA se puede resumir en los siguientes pasos:
1. Determinar los Recursos Físicos y Humanos de la fábrica; los Centros y Equipos de Trabajo a los que
pertenecen y los Tipos de Centros y Equipos de Trabajo que existan. Además de la disponibilidad de
cada uno de esos recursos.
2. Identificar los productos que se fabrican o que queremos utilizar en la aplicación.
3. Definir todos los estados por los que pasa el producto para la obtención final del mismo, dichos
estados serán denominados ítems en la aplicación. Los ítems pueden ser externos (si provienen del
exterior; es decir, de fuera de la fábrica), internos (si proviene de una operación de la fábrica) o ítem
final (si es el estado último del producto).
4. Identificar las relaciones de precedencia de cada ítem con los demás y las multiplicidades de los ítems
con los ítems antecesores.
5. Identificar las operaciones que dan lugar a cada ítem y definir qué recursos pueden realizar dicha
operación.
6. Asignar una operación a cada ítem.
7. Establecer la ruta de fabricación del producto.
8. Analizar si es viable el producto para la tasa objetivo.
9. Planificar los presupuestos.
10. Programar las órdenes de trabajo planificadas.

3.3.2 Conceptos clave de PROMIA


• Recurso: Unidad mínima de equipamiento y personal que puede ejecutar una o varias Operaciones.
Nótese que un recurso puede realizar varias operaciones y que una operación puede ser realizada por
varios recursos. Hay dos tipos de recursos diferentes, los físicos y los humanos.
• Centro de Trabajo: Agrupación de recursos físicos.
• Tipo de Centro de trabajo: Agrupación de centros de trabajo.
• Equipo de Trabajo: Agrupación de recursos humanos.
• Tipo de Equipo de Trabajo: Agrupación de equipos de trabajos.
• Buffers: Almacenes intermedios que pueden existir tanto antes como después de cada recurso.
• Material: Consumible que interviene en la fabricación de un Componente y que es utilizado durante
la misma.
• Ítem: Estados por los que pasa el producto hasta que se termina de fabricar.
• Multiplicidad: Número de unidades del componente “hijo” que se necesitan para fabricar una unidad
de componente “padre”. La multiplicidad es un atributo de la asociación entre dos componentes. Si el
componente es de tipo final (producto), entonces, su multiplicidad es uno.
• Operación: Proceso de transformación (fabricación, ensamblado, soldado, inspección, transporte,
etc.) de una o varias unidades de uno o más componentes externos o internos (inputs) en una o varias
unidades de componentes (output). Además, una operación puede conllevar el empleo de uno o varios
consumibles. Todo componente de tipo interno lleva asociada una y solo una operación.
• Presupuestos: Pedidos de productos que demandan las empresas.
24
Escenario para la Integración de Sistemas

• Cuellos de botella: Son las operaciones que limitan el ritmo de producción de la fábrica.
• Planificar: Estimar si es posible realizar la fabricación de los productos del pedido para cumplir con
la fecha de entrega establecida en el presupuesto. Si fuera posible su planificación, nos calculará el
tiempo más tardío de comienzo de cada una de las operaciones de los ítems para cumplir con la fecha
de entrega.
• Programar: Determinar la secuencia de procesamiento de cada tarea de la que se compone la
fabricación de productos. Indica en qué momento empieza cada tarea y en qué momento finaliza.
• Órdenes de Trabajo (OT): Orden de fabricación de una unidad de producto, o de un lote de
unidades de un mismo producto que han sido programadas. Una Orden de Trabajo específica, para un
tipo de Producto y una Ruta para fabricar el mismo, el número de unidades de dicho producto que es
preciso fabricar antes de una determinada “Fecha de Entrega”. En el caso de que se trate de un lote de
unidades de un mismo producto, el lote de unidades será tratado de forma conjunta, de manera que a
todos los efectos (incluyendo la programación de la producción) se considerará una única unidad de
producto.
• Tareas: Unidad de trabajo de cada Orden de Trabajo que se corresponde con la fabricación de un
componente del producto asociado. Cada tarea tendrá asociado un estado que describirá su ciclo de
vida desde que se inicia la tarea hasta que se finaliza.
• Estado de la tarea: Indica la fase en la que se encuentra. Se considerarán los siguientes estados:
o Creada: La Orden de Trabajo a la que pertenece la tarea ha sido creada, pero no tiene
asignadas fechas de comienzo ni de finalización estimadas.
o Planificada: La tarea ha sido planificada y tiene, por tanto, unas fechas de inicio y fin
estimadas que vendrán determinadas por el proceso de Planificación de la Producción.
o Programada: La tarea ha sido programada y tiene, por tanto, unas fechas de inicio y fin
estimadas que vendrán determinadas por el proceso de Programación de la Producción.
o En proceso: La tarea ha comenzado, por lo que además de las fechas estimadas, tiene una
fecha de comienzo real.
o Terminada: La tarea ha terminado, por lo que tiene fechas estimadas y reales tanto de inicio
como de finalización.
o Pendiente de Cierre de Observaciones.
o Validada.
4 DESARROLLO DE LA PRUEBA DE CONCEPTO

Hoy en día, la mayoría del software existe no para resolver un problema,


sino para actuar de interfaz con otro software.

I.O. Angell

n este capítulo realizaremos una explicación detallada de los desarrollos y modificaciones que se van a

E realizar para la integración entre el sistema ERP Odoo y el sistemas MES PROMIA explicados en el
capítulo anterior. Además, estableceremos los objetivos y el alcance de la implementación de la
integración entre ambos sistemas

4.1 Objetivos, alcance y descripción del escenario


El principal objetivo del desarrollo de la integración entre sistemas es servir como prueba de concepto de una
implementación del estándar ANSI/ISA-95 entre el ERP de código libre Odoo y el sistema MES PROMIA.
Como prueba de concepto, la integración entre ambos sistemas no se pretende que sea exhaustiva en toda la
información que ambos deben compartir, simplemente que las órdenes de producción entre ambos sistemas
compartan unos estados equivalentes.
Como se ha explicado en capítulos anteriores, el estándar ANSI/ISA-95 ofrece una amplia gama de datos que
se pueden compartir entre sistemas ERP y MES y para su implementación ofrece muchos esquemas diferentes
de ficheros B2MML que se pueden generar.
Sin embargo, para el desarrollo de la prueba de concepto que nos ocupa en el presente trabajo, nos centraremos
exclusivamente en el intercambio de información de órdenes de fabricación. Se van a obviar, por tanto, el resto
de flujos de información que ISA-95 nos permite: productos, materiales, equipamiento, recursos humanos,
recursos físicos e información de operaciones y de producción. Por consiguiente, se realizará la suposición que
todos los productos, materiales, recursos físicos y humanos y equipamiento que exista en el ERP Odoo y a los
que se refiera una orden de fabricación, deberán existir a su vez en el MES PROMIA para, de esta manera,
poder controlar exclusivamente el flujo de órdenes de producción entre ambos sistemas y la equivalencia de
los estados de ambos.
Adicionalmente a lo anterior, obviaremos la generación de rutas y centros de trabajo del MRP de Odoo, ya que
esta información estará controlada por parte del MES PROMIA. Además, se obviará la funcionalidad que
ofrece el módulo MRP de Odoo que permite la granularidad de productos mediante la generación automática
de órdenes de fabricación de productos intermedios y dicho funcionamiento estará delegado al MES
PROMIA; de esta manera, nos evitamos la generación de órdenes de trabajo duplicadas en el ERP que sólo se
correspondan con una única orden en el MES.
Por otro lado, y debido a que solo se ha podido disponer del esquema de base de datos del MES PROMIA,
éste sistema se tratará como una caja negra desde el punto de vista de la integración de la información y no nos
fijaremos en los procesos internos que la generación de órdenes de producción pueda conllevar en el mismo.
Así, nos centraremos en el paso de las órdenes de fabricación a estado finalizado para lanzar los procesos
necesarios para que en el MRP de Odoo se replique dicho estado para la orden de fabricación correspondiente.
El escenario a implementar consta de una serie de modificaciones y desarrollos a realizar para permitir el flujo
de información entre ambos sistemas. Se diferencian claramente dos sentidos en el flujo de la información, un
primer flujo que parte desde el ERP hacia el MES en el momento de creación de las órdenes de fabricación y
26
Desarrollo de la prueba de concepto

un segundo flujo desde el MES al ERP en el momento de finalización de dichas órdenes.


En el primer flujo desde el ERP al MES, tendremos que modificar el flujo de trabajo de las órdenes de
fabricación en el módulo MRP de Odoo para que una vez creadas y reservados los materiales necesarios para
llevar a cabo la orden de fabricación, en lugar de pasar directamente a estado “En producción”, se pase a un
estado intermedio “Enviado al MES” mientras que este último recibe la información de la orden de fabricación
y la registra en su base de datos y, en cuanto la orden es registrada en el MES, esta pasa a estado “En
producción” en el ERP.
En la siguiente figura se resume este primer flujo de información desde el ERP hacia el MES:

Figura 4-1. Integración de Odoo-PROMIA. Iniciar Producción


Por su parte, en el flujo de información desde el MES hacia el ERP, tendremos que detectar el momento en
que una orden pase a estado “Finalizada” para enviarle el correspondiente mensaje B2MML al ERP para que
actualice también el estado y la fecha de finalización de su orden correspondiente. A continuación se puede
observar la figura donde se modela este flujo de información.
Integración de sistemas ERP y MES mediante el estándar ANSI/ISA-95 27

Figura 4-2. Integración Odoo-PROMIA. Finalizar Producción


Como se ha comentado, el flujo de trabajo de ambos sistemas se modifica quedando la actividad de estados de
órdenes de fabricación como se observa en el siguiente diagrama de estados.
28
Desarrollo de la prueba de concepto

Figura 4-3. Diagrama de estado de órdenes de producción entre sistemas


Finalmente podemos concluir citando las modificaciones a desarrollar en cada uno de los sistemas para
implementar la integración entre ambos.
En el ERP Odoo tenemos que:
• Modificar el flujo de trabajo de las órdenes de fabricación para que se incluya un nuevo estado
“Enviado al MES” entre la reserva de materiales y el paso a “En Producción” para modelar el estado
en que se encuentra mientras se efectúa el registro de la orden en el MES.
• Desarrollo de módulo personalizado en Odoo que lleve a cabo la generación y almacenamiento del
fichero B2MML y efectúe la llamada al Webservice del Middleware en el que se adjunte el fichero.
Dicho módulo deberá heredar del módulo MRP de Odoo para poder acceder a la información del
mismo. Además, una vez recibida la respuesta positiva de almacenamiento de la orden en el MES,
deberá pasar la orden correspondiente a estado “En producción”. En caso de que se reciba como
respuesta un error por parte del MES, en el ERP pasaremos la orden de fabricación a estado
cancelado.
• Recepción de llamadas XML-RPC en Odoo que permita su ejecución por parte del Middleware
cuando las órdenes pasen a estado finalizado en el MES y haga lo propio en las órdenes
correspondientes en Odoo. Las llamadas XML-RPC (EXtended Markup Language - Remote Control
Procedure por sus siglas en inglés) no son más que los procedimientos a los que se puede llamar desde
un sistema externo a Odoo mediante el módulo Web Service API. Dicho módulo está disponible con
la instalación base del ERP.
En lo que respecta al MES, los desarrollos a realizar se desglosan en:
• Desarrollo de aplicación web de acceso a la base de datos del MES que simule el MES de forma
completa. Esta aplicación nos permitirá observar las órdenes de fabricación que se creen a través de la
Integración de sistemas ERP y MES mediante el estándar ANSI/ISA-95 29

integración de sistemas y modificar el estado de las mismas y su fecha de finalización para poder
pasarlas a estado “Finalizada”.
• Desarrollo de Webservice que reciba como entrada el fichero B2MML proveniente del Middleware y
que lo dé de alta en la base de datos del MES.
• Desarrollar función mediante la cual, una vez se detecte la finalización de una orden de fabricación, se
llame al Webservice del Middleware que permita el traspaso de dicha información al ERP.
El desarrollo del Middleware consta de dos servicios web que permitirán la interconexión entre sistemas en los
dos flujos de información definidos anteriormente:
• Desarrollo de Webservice que reciba la llamada desde el ERP adjuntando el fichero B2MML y que lo
traslade al servicio web del MES para que esta se registre en PROMIA. Una vez registrada, trasladará
a Odoo el mensaje positivo o negativo de creación de la orden de fabricación en el MES mediante la
respuesta a la llamada del Servicio Web.
• Desarrollo de Webservice que reciba la llamada desde el MES con el fichero B2MML adjunto de
finalización de orden de fabricación y efectúe la llamada a los procedimientos remotos necesarios de
Odoo mediante XML-RPC para que la orden de fabricación pase a estado “Finalizado”.

4.2 Desarrollo en Odoo


Como se ha explicado en la sección anterior, los desarrollos a realizar en la parte del ERP se pueden resumir
en la modificación del flujo de trabajo de las órdenes de fabricación, el desarrollo de un módulo personalizado
para la generación de ficheros B2MML y la recepción de mensajes de finalización de órdenes por parte del
MES, aunque esto último no requiere de ningún desarrollo en Odoo, pues el módulo Web Service API está
disponible en la instalación básica de Odoo 9.

4.2.1 Modificaciones en el flujo de trabajo del módulo MRP de Odoo


Para poder controlar el flujo de trabajo de las órdenes de producción del módulo MRP de Odoo y con el
objetivo de incluir un paso intermedio en dicho flujo que nos permita realizar el traslado de información hacia
el MES, debemos modificar el flujo de estados de las órdenes de producción. En Odoo es muy sencillo realizar
cambios en los flujos de estados gracias a su alto nivel de posibilidades de configuración.
La modificación de estados se puede llevar a cabo mediante la activación del modo desarrollador en Odoo.
Para ello, estando logados como usuario administrador, hacemos clic en el nombre de usuario donde se nos
desplegará un menú que contiene la opción “Acerca de”. Seleccionamos dicha opción.

Figura 4-4. Entrada en modo desarrollador. Acceso a ventana “Acerca de”


Y nos aparecerá la ventana “Acerca de”. En esta ventana seleccionamos el enlace “Activar modo
desarrollador”.
30
Desarrollo de la prueba de concepto

Figura 4-5. Entrada en modo desarrollador. Ventana "Acerca de"


En ese momento se reiniciará la página de Odoo donde nos encontrábamos y aparecerá un nuevo menú con
una figura de bicho (o bug en inglés). Dicho menú es el denominado “Debug” que sirve para depurar el
funcionamiento de Odoo. Al desplegar este menú mientras nos encontramos en la página de listado de
Órdenes de producción del módulo MRP de Odoo, veremos la opción “Editar Flujo de trabajo” donde tenemos
que hacer clic.

Figura 4-6. Edición de flujo de trabajo. Menú Debug


A continuación, nos aparece la página de listado de flujos de trabajo de las órdenes de producción donde sólo
nos aparece un flujo de trabajo. En esta página podemos crear nuevos flujos o visualizar y editar los existentes.
Integración de sistemas ERP y MES mediante el estándar ANSI/ISA-95 31

Figura 4-7. Edición de flujo de trabajo. Listado de Flujos de trabajo


En la página de listado de flujos de trabajo de órdenes de producción tenemos disponibles tres vistas, la de
listado por defecto, vista de formulario y vista de diagrama. Para editar el flujo de trabajo de forma más visual
seleccionaremos esta última vista de diagrama.

Figura 4-8. Edición de flujo de trabajo. Vistas de Flujos de trabajo disponibles


Al seleccionar esta vista, nos aparece el diagrama de estados del flujo de trabajo de las órdenes de producción
en un gráfico que podremos editar.

Figura 4-9. Edición de flujo de trabajo. Diagrama de Flujo de trabajo de órdenes de producción
En esta ventana podemos crear el nuevo estado que necesitamos haciendo clic en el botón “Nuevo nodo”. El
nuevo estado lo llamaremos send_MES, será de tipo función y especificaremos la función de Python llamada
action_send_MES() que es donde implementaremos las funcionalidades necesarias para el paso a este nuevo
estado.
32
Desarrollo de la prueba de concepto

Figura 4-10. Edición de flujo de trabajo. Formulario de nuevo nodo


A continuación enlazaremos el nuevo estado “send_MES” con los otros dos estados con los que compartirá
transiciones (lo situaremos como estado intermedio entre “ready” y “in_production”). Para crear nuevas
transiciones, con el estado origen de la transición seleccionado, pulsaremos sobre uno de los puntos negros que
le rodean y lo arrastraremos hacia el estado final de dicha transición.
La transición desde el estado “ready” hacia el estado “send_MES” quedará como sigue:

Figura 4-11. Edición de flujo de trabajo. Formulario de transición desde ready hacia send_MES
Y la transición entre el estado “send_MES” y “in_production”:
Integración de sistemas ERP y MES mediante el estándar ANSI/ISA-95 33

Figura 4-12. Edición de flujo de trabajo. Formulario de transición desde send_MES hacia in_production
Se puede observar que se está definiendo un nuevo botón (“button_send_MES”) para el paso entre el estado
“ready” y “send_MES”. En definitiva el flujo de trabajo de las órdenes de producción quedará como se
observa en la siguiente figura:

Figura 4-13. Edición de flujo de trabajo. Diagrama de Flujo de trabajo de órdenes de producción modificado
En la siguiente sección veremos más en detalle cómo se ha realizado la definición del nuevo estado junto a sus
transiciones y las modificaciones de las vistas mediante el desarrollo de un nuevo módulo de Odoo.

4.2.2 Desarrollo de módulo isa95mrp


Para la personalización del módulo MRP de Odoo, se necesita la creación de un nuevo módulo con una
relación de herencia con MRP para poder acceder a la información contenida en este además de realizar
modificaciones en el comportamiento y las vistas del módulo MRP.
34
Desarrollo de la prueba de concepto

Las modificaciones del flujo de trabajo también se pueden realizar en el nuevo módulo, como veremos en este
apartado.
A este nuevo módulo le llamaremos “isa95mrp” para hacer referencia a que se pretende incluir en éste los
desarrollos necesarios para la implementación del estándar ISA-95 dentro del módulo MRP de Odoo.
En primer lugar, todo módulo de Odoo debe contener un fichero llamado __openerp__.py donde se defina el
nombre del módulo, su descripción, autor, versión y categoría a la que pertenece. Además, podemos definir en
este fichero las dependencias del módulo así como los datos a cargar en la instalación del módulo y
configuración de sus posibilidades a la hora de instalar el módulo.

Figura 4-14. Desarrollo de módulo en Odoo. Fichero __openerp__.py


Una vez definidas las características y definiciones del módulo Odoo, podemos pasar a la definición de las
modificaciones del flujo de trabajo (exactamente iguales a las introducidas de manera gráfica en el apartado
anterior) y las modificaciones en las vistas del módulo MRP. Dichas modificaciones se definen en los ficheros
isa95mrp_workflow.xml e isa95mrp_view.xml respectivamente.
El fichero isa95mrp_workflow.xml es un fichero XML donde se definen nuevos estados y transiciones o bien
modificaciones de los estados y transiciones existentes. En nuestro caso, definiremos el nuevo estado del flujo
de trabajo:

Figura 4-15. Desarrollo de módulo en Odoo. Fichero isa95mrp_workflow.xml definición de nuevo estado
Se puede observar que definimos el nuevo estado con el nombre “send_MES” y ejecuta la función
“action_send_MES()” que definiremos en este mismo módulo.
En lo que respecta a las nuevas transiciones también las definimos en el fichero XML de workflow:
Integración de sistemas ERP y MES mediante el estándar ANSI/ISA-95 35

Figura 4-16. Desarrollo de módulo en Odoo. Fichero isa95mrp_workflow.xml definición de nuevas


transiciones
Se puede comprobar que hemos definido las tres transiciones que presenta el nuevo estado “send_MES“:
• Transición desde el estado “ready” a “send_MES” que se realiza gracias al botón
“button_send_MES” que definiremos en las modificaciones de vistas del módulo.
• Transición desde el estado “send_MES” a “in_production” que se realiza gracias al botón
“button_produce”.
• Y la transición desde el estado “send_MES” a “cancel” cuando pulsemos el botón de cancelación
“button_cancel”.

Finalmente, para terminar la definición de modificaciones del flujo de trabajo, redefinimos la transición entre
los estados “ready” y “in_prodcution” para evitarla de forma que cortocircuitemos el flujo por defecto de las
órdenes de producción.

Figura 4-17. Desarrollo de módulo en Odoo. Fichero isa95mrp_workflow.xml redefinición de transiciones


existentes
El fichero isa95mrp_view.xml es un fichero XML donde se definen nuevos campos y botones dentro de las
vistas que se definan. En nuestro caso, definiremos el nuevo estado del flujo de trabajo en la barra de estado
del formulario de órdenes de producción:
36
Desarrollo de la prueba de concepto

Figura 4-18. Desarrollo de módulo en Odoo. Fichero isa95mrp_view.xml definición de nuevo estado en barra
de estados
También en el fichero de vistas incluimos el botón “button_send_MES” antes del botón “button_produce”
además de sustituir la configuración de este último con los botones “button_produce” relativos al nuevo estado
“send_MES”.

Figura 4-19. Desarrollo de módulo en Odoo. Fichero isa95mrp_view.xml definición y modificación de


botones
Además, añadimos el botón “button_cancel” que permita el paso del estado “send_MES” al estado “cancel”.

Figura 4-20. Desarrollo de módulo en Odoo. Fichero isa95mrp_view.xml definición botón cancel
Por otro lado, y para finalizar el desarrollo del módulo personalizado de Odoo, tenemos que definir el fichero
isa95mrp.py donde desarrollaremos en Python toda la lógica del módulo. En dicho fichero definiremos la clase
“isa95mrp_production” que heredará de la clase “mrp.production” donde se redefinen los estados del MRP de
Odoo de forma análoga a como lo hicimos en el XML de workflow.
Integración de sistemas ERP y MES mediante el estándar ANSI/ISA-95 37

Figura 4-21. Desarrollo de módulo en Odoo. Fichero isa95mrp.py definición de clase


Además, en este fichero Python tenemos que definir la función “action_send_MES()” que se ejecuta en el
estado “send_MES”. En dicha función realizaremos una llamada a la función “generateB2MML()” que es
donde se genera el fichero B2MML a partir de la información de la orden de producción, seguidamente
subimos dicho fichero a un servidor FTP, accesible tanto desde Odoo como desde el Middleware, y
realizaremos la llamada al Webservice del Middleware.

Figura 4-22. Desarrollo de módulo en Odoo. Fichero isa95mrp.py definición función action_send_MES
Se puede observar que, tras la llamada al servicio web del middleware, si este envía el código de alta realizada
correctamente (igual a “0”), pasaremos la orden de fabricación a estado “En Producción”, pero si se recibe un
código de error, cancelaremos la orden de fabricación de Odoo.
Una vez finalizado el desarrollo del módulo personalizado de Odoo, podemos pasar a la instalación del mismo
en Odoo. Para ello, copiamos la carpeta del módulo isa95mrp en la ruta de addons de Odoo (C:\Program Files
(x86)\Odoo 9.0-20160204\server\openerp\addons\ en Windows), a continuación se reinicia el servidor de
Odoo (en Windows se reinicia el servicio odoo-server) y al volver a iniciar Odoo, vamos al menú aplicaciones
en línea y en el buscador de módulos buscamos el texto isa95mrp.
38
Desarrollo de la prueba de concepto

Figura 4-23. Desarrollo de módulo en Odoo. Instalación de Módulo isa95mrp


Nos aparece el módulo que acabamos de crear, si pulsamos en su nombre, nos aparecerá más información
acerca del módulo (básicamente la información que introdujimos en el fichero __openerp__.py).

Figura 4-24. Desarrollo de módulo en Odoo. Instalación de Módulo isa95mrp. Detalles del módulo
Si hacemos clic en la pestaña “Technical Data”, nos aparecerá información técnica del módulo donde
podemos destacar las dependencias de este módulo con otros de Odoo.
Integración de sistemas ERP y MES mediante el estándar ANSI/ISA-95 39

Figura 4-25. Desarrollo de módulo en Odoo. Instalación de Módulo isa95mrp. Detalles técnicos del módulo
Observamos que las únicas dependencias de este módulo son con los módulos base y mrp que están ambos
instalados, por tanto podemos proceder a instalar el módulo isa95mrp haciendo clic en el botón “Install”.

Figura 4-26. Desarrollo de módulo en Odoo. Instalación de Módulo isa95mrp. Módulo isa95mrp instalado
Una vez finalizada la instalación del módulo volverá a aparecer la página de detalle del módulo isa95mrp
donde ya aparecen los botones “Actualizar” y “Desinstalar”. Ahora, cuando creemos una nueva orden de
fabricación se regirá por el flujo de trabajo que hemos definido en nuestro módulo y pasará por el estado
“send_MES” donde se generará el fichero B2MML y se llamará al Webservice del Middleware.
Un ejemplo de fichero B2MML que se genera con este módulo se puede observar en el Anexo B.
En el Anexo C se incluye el código de todos los ficheros que forman el módulo personalizado isa95mrp.
En la siguiente tabla se muestran las correspondencias que se han detectado entre la información de Odoo y la
40
Desarrollo de la prueba de concepto

del fichero B2MML a generar.


Tabla 4–1. Correspondencias B2MML-Odoo

Campos B2MML Información Odoo


ProductionSchedule.ID mrp_production.id
ProductionSchedule.Description “Manufacturing Order”
ProductionSchedule.HierarchyScope “Site”
ProductionSchedule.PublishedDate Hora actual
ProductionSchedule.StartTime Hora actual
ProductionSchedule.EndTime Hora actual + 1 día
ProductionSchedule.EquipmentLevel “Site”
ProductionRequest.ID mrp_production.id
ProductionRequest.Description mrp_production.name
ProductionRequest.HierarchyScope mrp_routing.name (mrp_production.routing_id)
ProductionRequest.StartTime mrp_production.date_start
ProductionRequest.EndTime mrp_production.date_finished
ProductionRequest.Priority mrp_production.priority
SegmentRequirement.ID mrp_production.id
SegmentRequirement.Description mrp_production.name
SegmentRequirement.HierarchyScope mrp_routing.name (mrp_production.routing_id)
SegmentRequirement.EarliestStartTime mrp_production.date_start
SegmentRequirement.LatestEndTime mrp_production.date_finished
SegmentRequirement.Duration mrp_production.hour_total
PhysicalAssetRequirement.PhysicalAssetID mrp_production.routing_id
PhysicalAssetRequirement.Description mrp_routing.name
PhysicalAssetRequirement.HierarchyScope mrp_routing.code
PhysicalAssetRequirement.Quantity “1”
PhysicalAssetRequirementProperty.ID mrp_production.routing_id
PhysicalAssetRequirementProperty.Description mrp_routing.name
PhysicalAssetRequirementProperty.Quantity “1”
MaterialRequirement.Description product_product.name_template (mrp_production.product_id)
MaterialRequirement.HierarchyScope mrp_routing.name (mrp_production.routing_id)
MaterialRequirement.MaterialUse “Product”
MaterialRequirement.Quantity mrp_production.product_qty
MaterialRequirementProperty.ID mrp_production.product_id
MaterialRequirementProperty.Description product_product.name_template (mrp_production.product_id)
MaterialRequirementProperty.Value "Product"
MaterialRequirementProperty.Quantity mrp_production.product_qty
MaterialRequirement.Description product_product.name_template
(mrp_bom_line.bom_id(mrp_bom.id
(mrp_production.bom_id)))*
MaterialRequirement.HierarchyScope mrp_routing.name (mrp_production.routing_id)
MaterialRequirement.MaterialUse "Consumed"
Integración de sistemas ERP y MES mediante el estándar ANSI/ISA-95 41

Campos B2MML Información Odoo


MaterialRequirement.Quantity mrp_bom_line.product_qty(mrp_bom_line.bom_id(mrp_bom.id
(mrp_production.bom_id)))*
MaterialRequirementProperty.ID product_product.product_id
(mrp_bom_line.bom_id(mrp_bom.id
(mrp_production.bom_id)))*
MaterialRequirementProperty.Description product_product.product_name_tempalte
(mrp_bom_line.bom_id(mrp_bom.id
(mrp_production.bom_id)))*
MaterialRequirementProperty.Value "Raw Material"
MaterialRequirementProperty.Quantity mrp_bom_line.product_qty(mrp_bom_line.bom_id(mrp_bom.id
(mrp_production.bom_id)))*

4.2.3 Recepción de mensajes por parte del MES


Para permitir que Odoo modifique el estado de las órdenes de producción una vez que estas se hayan
finalizado en el MES, haremos uso del módulo Web Service API de Odoo que permite la recepción de
llamadas XML-RPC desde cualquier sistema externo para acceder y modificar la información que aparece en
Odoo.
Por tanto, esta parte no requiere de un desarrollo personalizado y basta con conocer los procedimientos a los
que llamar desde el Middleware que permitan la finalización de las órdenes de fabricación.

4.3 Desarrollo en PROMIA


Como se ha comentado en secciones anteriores, solo se ha podido disponer del esquema de base de datos del
MES PROMIA, por lo tanto, para poder ser capaces de realizar las modificaciones necesarias en la base de
datos para; por ejemplo, pasar una orden de fabricación a estado finalizada, necesitamos realizar el desarrollo
de una aplicación que nos permita el acceso y modificación de la base de datos de PROMIA.
Por otro lado, necesitaremos desarrollar un servicio web en la aplicación PROMIA que reciba el fichero
B2MML generado por Odoo y almacene la información que contiene en la base de datos.

4.3.1 Desarrollo de aplicación CRUD de PROMIA


La tecnología seleccionada para el desarrollo de la aplicación web del MES a partir de la base de datos de
PROMIA es JSF (JavaServer Faces) debido a las ventajas de integridad de datos y fiabilidad que ofrece su
arquitectura con una capa de persistencia de datos; además permite una aplicación más mantenible gracias a su
implementación del patrón de diseño MVC (Modelo-Vista-Controlador).
La aplicación web que simulará el MES PROMIA es básicamente una aplicación CRUD (CReate-Update-
Delete) que permite la creación, modificación y borrado de los registros de la base de datos en la que se basa.
Por lo tanto, no nos preocuparemos de la lógica de negocio interna del sistema MES y sólo nos interesa el
registro de órdenes de producción (OTs) y sus presupuestos asociados que nos lleguen desde Odoo mediante
ficheros B2MML y su paso a estado finalizada para lanzar la ejecución del Webservice que traslade dicho
estado al ERP.
Sí es importante crear ambos registros en el MES PROMIA, tanto la orden de producción como su
presupuesto asociado ya que el funcionamiento interno del MES no permite que exista una orden de
producción sin un presupuesto asociado.
42
Desarrollo de la prueba de concepto

En las siguientes figuras se puede apreciar cómo queda la aplicación MES tras su desarrollo:

Figura 4-27. Página principal de la aplicación web del MES PROMIA


Integración de sistemas ERP y MES mediante el estándar ANSI/ISA-95 43

Figura 4-28 - Listado de Presupuestos de la aplicación web del MES PROMIA

Figura 4-29 - Formulario de edición de Presupuestos en la aplicación web de PROMIA


44
Desarrollo de la prueba de concepto

Figura 4-30 - Listado de Ots de la aplicación web del MES PROMIA


Integración de sistemas ERP y MES mediante el estándar ANSI/ISA-95 45

Figura 4-31 - Formulario de edición de Ots en la aplicación web de PROMIA

4.3.2 Desarrollo de Webservice en aplicación PROMIA


Para permitir la llamada de Odoo (mediante el Middleware) para que nos haga llegar las órdenes de
producción el MES, debemos publicar un servicio web en PROMIA que reciba como entrada la ruta en un
servidor FTP del fichero B2MML generado y devuelva una respuesta del procesamiento correcto o incorrecto
del fichero.
El proceso interno de dicho servicio web tomará el fichero B2MML, lo leerá y lo trasladará a una estructura de
datos Java más fácilmente procesable de forma automática y la información leída la registrará como orden de
46
Desarrollo de la prueba de concepto

producción del MES (tabla P520Ot de PROMIA) y su presupuesto asociado (en su tabla P510Presupuesto
correspondiente). Durante esta transacción a la base de datos, se comprobará que los datos de productos,
materiales y recursos físicos y humanos son correctos y ya existen en la base de datos PROMIA, en caso
afirmativo, se responderá al servicio web con un código de procesamiento correcto; en caso contrario, se
devolverá un error.

Figura 4-32. Operación addManufacturingOrder del Servicio Web del MES PROMIA
El mapeo de la información recibida en el fichero B2MML en la base de datos se realiza en la función
parse2Database que básicamente comprueba que la información que contiene es correcta y coherente con la
información del MES (productos, materiales, etc.) y que si la información es correcta, realiza el alta de los
registros correspondientes en la tabla de presupuestos y en la de órdenews de fabricación, como se observa en
el siguiente código:

Figura 4-33. Función parse2Database del MES PROMIA


Para más detalle del código con el que se ha implementado la lógica necesaria, tenemos el código completo en
el Anexo D.

4.3.3 Desarrollo para el traslado de estado finalizado desde PROMIA a Odoo


Además del desarrollo necesario para el registro de órdenes de producción en el MES, también tendremos que
controlar el cambio de estado de dichos procesos para que, cuando pasen a estado “finalizada” se lance la
llamada correspondiente al servicio web del Middleware que traslade dicho cambio de estado al ERP.
Para ello, vamos a modificar la función de edición de los registros P520Ot (dentro de la clase P520OtFacade)
de tal manera que, en primer lugar, comprobemos los cambios que se han realizado en el registro y, si el estado
que se ha insertado en el formulario es distinto al que se encuentra en la base de datos, tendremos que generar
el fichero B2MML correspondiente y realizar la llamada al servicio web del Middleware. Si la llamada al
servicio web va bien, ejecutamos la modificación del registro en la base de datos de PROMIA. Todo ello se
lleva a cabo en el siguiente código:
Integración de sistemas ERP y MES mediante el estándar ANSI/ISA-95 47

Figura 4-34. Función edit de la clase P520OtFacade del MES PROMIA


En el Anexo E se puede comprobar cómo es el fichero B2MML generado por el MES PROMIA para la
finalización de órdenes de fabricación.
En la siguiente tabla se muestran las correspondencias entre los datos del fichero B2MML y el MES Promia.
Tabla 4–2. Correspondencias B2MML-Odoo

Campos B2MML Información PROMIA


ProductionSchedule.ID P520_OT.nombre_ot
ProductionSchedule.PublishedDate Hora actual
ProductionSchedule.StartTime Hora actual
ProductionRequest.ID P520_OT.nombre_ot
ProductionRequest.Description P520_OT.descripcion_ot
ProductionRequest.StartTime P520_OT.fecha_estimada_inicio
ProductionRequest.EndTime P520_OT.fecha_estimada_finalización
ProductionRequest.Priority P520_OT.prioridad_ot
SegmentRequirement.ID P520_OT.nombre_ot
SegmentRequirement.Description P520_OT.descripcion_ot
SegmentRequirement.EarliestStartTime P520_OT.fecha_estimada_inicio
SegmentRequirement.LatestEndTime P520_OT.fecha_estimada_finalización
PhysicalAssetRequirement.PhysicalAssetID P210_CENTRO_TRABAJO.nombre_centro_trabajo
PhysicalAssetRequirement.Description P210_CENTRO_TRABAJO.descripcion_centro_trabajo
PhysicalAssetRequirementProperty.ID P210_CENTRO_TRABAJO.nombre_centro_trabajo
PhysicalAssetRequirementProperty.Description P210_CENTRO_TRABAJO.descripcion_centro_trabajo
MaterialRequirementProperty.ID P530_ITEM.nombre_item
MaterialRequirementProperty.Description P530_ITEM.descripcion_item
48
Desarrollo de la prueba de concepto

4.4 Desarrollo del Middleware


Para permitir la integración horizontal sin que haya un acoplamiento muy fuerte entre los dos sistemas,
desarrollamos un sistema Middleware que nos sirva de interfaz entre ambos. De esta manera, si en el futuro se
decide cambiar uno de los dos sistemas, tan sólo tendremos que preocuparnos de la integración del nuevo
sistema con el Middleware quedando el otro sistema sin cambios.
El sistema Middleware constará de dos servicios web que gestionarán las comunicaciones de órdenes de
producción y sus estados en ambos sentidos.

4.4.1 Desarrollo de Webservice de alta de órdenes de fabricación de Odoo en PROMIA


Este servicio web permite la comunicación desde el ERP al MES para el alta de órdenes de producción de
Odoo en PROMIA. El servicio recibirá la ruta en el FTP del fichero B2MML generado por Odoo y realizará la
llamada al servicio web del MES con la misma información. La respuesta que reciba del servicio web del
MES será la misma que trasladará a Odoo.
Así se puede comprobar en el siguiente código:

Figura 4-35. Servicio Web sendToMES del Sistema Middleware


Por tanto, en este caso, nos limitamos a darle traslado del fichero B2MML recibido del ERP al MES porque
hemos desarrollado la interpretación de este tipo de ficheros en el MES. Si el sistema MES no entendiera
ficheros B2MML, en este servicio web tendríamos que programar la lógica necesaria para la traducción del
fichero B2MML al tipo de mensajes que entienda el MES.

4.4.2 Desarrollo de Webservice de finalización de órdenes de fabricación de PROMIA en Odoo


En lo que respecta al servicio web de finalización de órdenes de producción, éste recibirá la ruta en el servidor
FTP del fichero B2MML generado por el MES con la información de finalización de la orden de producción y
realizará las llamadas necesarias a los procedimientos remotos del Web Service API de Odoo para que
gestione la actualización de la orden con el estado “finalizada”.
Integración de sistemas ERP y MES mediante el estándar ANSI/ISA-95 49

Figura 4-36. Servicio Web sendToERP del Sistema Middleware


De forma más detallada, lo que hacemos en este servicio web es leer el fichero B2MML recibido por el MES,
obtener los datos relevantes para identificar las órdenes de fabricación en Odoo (identificador y nombre de la
orden e identificador y cantidad de producto generado por la orden). Seguidamente, se pasa dicha información
a una función que se encarga de las llamadas a procedimientos remotos de Odoo llamada
endManufacturingOrder.

Figura 4-37 - Función endManufacturingOrder del Sistema Middleware


En la función endManufacturingOrder, realizamos la autenticación en el servidor Odoo mediante la función
remota “authenticate”, realizamos la búsqueda de la orden de fabricación que deseamos finalizar mediante la
50
Desarrollo de la prueba de concepto

llamada al procedimiento remoto “search”, a continuación preparamos el asistente de consumo y producción


de productos y finalmente efectuamos la producción final de la orden en el módulo MRP de Odoo; de esta
manera, si no se producen errores, habremos finalizado la orden de fabricación en ambos sistemas.

4.5 Integración entre el ERP y el MES en acción


Una vez finalizados los desarrollos necesarios para la integración de ambos sistemas vamos a realizar un
repaso de cómo quedará la operativa de alta y finalización de órdenes de fabricación en nuestra prueba de
concepto. Diferenciaremos las operaciones en ambos sentidos.

4.5.1 Flujo de información del ERP al MES


Para crear una orden de fabricación en Odoo, tras hacer login en el sistema y seleccionar el módulo MRP
(opción Manufacturing del menú) se abre el listado de órdenes de producción.

Figura 4-38. Listado de órdenes de producción del módulo MRP de Odoo


Al hacer clic en el botón Crear se abre el formulario de nueva orden de fabricación donde se puede observar
que se ha generado una referencia de forma automática (MO00073). Se selecciona el producto que deseamos
producir (en este caso de ejemplo, un PC de Sobremesa) y pulsamos el botón Confirmar Producción.
Integración de sistemas ERP y MES mediante el estándar ANSI/ISA-95 51

Figura 4-39 - Formulario de orden de producción MO00073 en estado “Nuevo”


Observamos cómo la orden pasa del estado Nuevo a estado Listo para producir. También es importante
destacar el identificador único asignado a nuestra orden de fabricación (id = 66 en la captura siguiente) en la
barra de direcciones de la aplicación. Pulsamos sobre el botón Reserva para efectuar la reserva de materiales
necesarios para la fabricación del producto seleccionado.

Figura 4-40 - Formulario de orden de producción MO00073 en estado Esperando materias primas
En la siguiente imagen se puede observar cómo en el estado Listo para producir nos aparece el botón Enviar
al MES que realizará el procedimiento de generación del fichero B2MML y llamada al servicio web del
middleware.
52
Desarrollo de la prueba de concepto

Figura 4-41 - Formulario de orden de producción MO00073 en estado Listo para producir
Cuando pulsamos el botón Enviar al MES, tras unos pocos segundos de carga, la orden de fabricación pasa
directamente a estado Producción Iniciada, ya que el estado Envío al MES es transitorio mientras se recibe
respuesta a la llamada al servicio web.

Figura 4-42 - Formulario de orden de producción MO00073 en estado Producción iniciada tras generación de
fichero B2MML
Una vez que se ha enviado la información al MES, podemos comprobar que se ha generado el correspondiente
fichero B2MML en el repositorio de ficheros (Nótese el identificador 66 en el nombre del fichero resaltado en
la captura).
Integración de sistemas ERP y MES mediante el estándar ANSI/ISA-95 53

Figura 4-43 - Fichero B2MML generado para la orden MO00073


Si vamos ahora a la aplicación web del MES PROMIA, se nos muestra las posibles consultas que se pueden
realizar a la base de datos destacando el listado registros de las tablas P510Presupuesto y P520Ot que son en
las que inyectamos la información del fichero B2MML generado con la información de la orden de
producción del módulo MRP de Odoo.
54
Desarrollo de la prueba de concepto

Figura 4-44 - Página inicial de la aplicación web MES PROMIA


Al entrar en el listado de registros de presupuestos, se observa que se ha creado un nuevo registro
correspondiente a nuestra orden de fabricación.
Integración de sistemas ERP y MES mediante el estándar ANSI/ISA-95 55

Figura 4-45 - Listado de Presupuestos en el MES PROMIA


Lo mismo ocurre en el listado de órdenes de trabajo (P520Ot), se ve que aparecen los datos de la orden de
producción en cuestión.

Figura 4-46 - Listado de órdenes de trabajo del MES PROMIA

4.5.2 Flujo de información del MES al ERP


Una vez comprobada la integración desde el ERP Odoo hacia el MES PROMIA, vamos a ver cómo se
finalizan las órdenes de fabricación desde el MES.
En primer lugar, para comprobar que los cambios realizados en el MES se trasladan a Odoo, verificamos que
la orden de fabricación se mantiene en estado Producción Iniciada.
56
Desarrollo de la prueba de concepto

Figura 4-47. Orden de producción en estado Producción Iniciada


Y observamos el número de productos existentes en el inventario del producto al que se refiere la orden de
fabricación (PC Sobremesa en nuestro caso, con 14 unidades).

Figura 4-48. Detalle de producto en Odoo


A continuación en la aplicación web del MES PROMIA, accedemos al formulario de edición del registro
P520Ot (orden de trabajo) correspondiente a la orden de fabricación que se generó en el apartado anterior.
Integración de sistemas ERP y MES mediante el estándar ANSI/ISA-95 57

Figura 4-49. Formulario de orden de trabajo en el MES


Se modifica la fecha real de finalización y el estado de la orden de trabajo y se pulsa sobre Guardar para
finalizar la orden en PROMIA y efectuar la llamada al Middleware que actualiza los cambios en Odoo.
58
Desarrollo de la prueba de concepto

Figura 4-50. Detalle de orden de trabajo modificada en el MES


Se comprueba que se genera el fichero B2MML correspondiente a la orden de trabajo del MES en el
repositorio de ficheros.

Figura 4-51. Repositorio de ficheros B2MML generados por el MES


Se comprueba que la orden de nuestro ejemplo (MO00073) ha pasado a estado Realizado.
Integración de sistemas ERP y MES mediante el estándar ANSI/ISA-95 59

Figura 4-52. Orden de producción en estado Realizado en Odoo


Y se ha incrementado el número de productos de PC Sobremesa al que se refiere la orden de fabricación (15
unidades).

Figura 4-53. Detalle de producto en Odoo. Se observa que se ha incrementado el número de unidades

4.6 Descripción y recomendaciones de Seguridad, Infraestructura y Hardware


Para el paso a producción de la solución propuesta se recomienda alojar cada aplicación en un servidor
distinto; es decir, se deberán tener tres servidores; uno que alojará Odoo (habitualmente con sistema operativo
Linux Ubuntu Server), otro que aloje el sistema MES (en nuestro caso Windows Server 2012, por ser el motor
de la base de datos un SQL Server 2012) y un último servidor donde se ejecute el Middleware y que también
sirva de servidor FTP para almacenar los ficheros B2MML generados para el intercambio de información.
No cabe duda de que estos tres servidores deberán tener una buena comunicación de red entre ellas para el
óptimo funcionamiento de la integración mediante servicios web implementada, además de mantener una
seguridad de la infraestructura que no permita la interferencia de ataques externos o virus informáticos.
60
Desarrollo de la prueba de concepto

Figura 4-54. Esquema Físico de Integración de Sistemas


Incluso, para optimizar el rendimiento de los servidores de aplicaciones, se puede separar el servidor de
aplicaciones del servidor de base de datos en los casos del ERP y el MES como se muestra en la siguiente
figura.

Figura 4-55 - Esquema Físico de Integración de Sistemas con bases de datos en servidores independientes
Además, dependiendo de la criticidad con la que se evalúen los procesos del negocio que soportan estos
sistemas, puede resultar imprescindible la configuración de los servidores en alta disponibilidad y con una
contingencia de los servidores e incluso de las salas donde estos se ubiquen.
Es una buena práctica conocida la publicación de los servicios web en un bus de servicios para tener una
arquitectura SOA (Service Oriented Architecture), de esta manera, se pueden publicar los servicios de esta
integración y otros servicios propios de la organización en cuestión centralizando las llamadas en un único
servidor incrementando la mantenibilidad y accesibilidad de los servicios web.
5 CONCLUSIONES Y LÍNEAS FUTURAS

La informática tiene que ver con los ordenadores lo mismo que la


astronomía con los telescopios.

Edsger W. Dijkstra

n este capítulo realizaremos una evaluación final de la prueba de concepto desarrollada en este trabajo

E para la integración de sistemas mediante el estándar ANSI/ISA-95. Además, se sentarán las bases para
las posibles líneas de investigación y trabajo que se puedan derivar de la elaboración del trabajo.

5.1 Conclusiones
Mediante el desarrollo de la prueba de concepto que se ha explicado en el presente trabajo fin de máster se ha
demostrado la simplicidad que otorga el estándar ANSI/ISA-95 a la hora de realizar la integración entre los
sistemas ERP y MES. Quizá se podría destacar que la mayor complejidad reside en el mapeo de campos entre
los sistemas y los ficheros B2MML.
En nuestro caso, al no estar Odoo preparado para la integración con el estándar ISA-95, hemos tenido que
desarrollar un módulo completo que permita la generación de ficheros B2MML en el paso a producción de las
órdenes de fabricación.
Por otro lado, al haber desarrollado la aplicación MES a partir de su base de datos, hemos podido hacer que el
MES cumpliera el estándar y pudiera leer y generar los ficheros B2MML necesarios para su comunicación con
ERP.
Debido a esto último, nuestro Middleware se ha quedado algo más vacío de funcionalidad, con la excepción de
las necesarias llamadas a procedimientos remotos de Odoo para la finalización de órdenes de producción a
partir de la información recibida del MES en forma de fichero B2MML.
Si el MES a integrar hubiera sido de código cerrado y no cumpliera con el estándar ISA-95, tendríamos que
haber realizado un desarrollo más extenso en sistema de integración Middleware porque tendríamos que haber
traducido los ficheros B2MML en el formato de los mensajes que entendiera el sistema MES en cuestión.
En los últimos tiempos el estándar ANSI/ISA-95 está adquiriendo una notoriedad en el sector industrial que
los proveedores de software y los integradores no pueden ignorar. En el nivel del MES, los proveedores de
sistemas ofrecen interfaces que cumplen con el estándar ISA-95 y en el nivel de los ERP, nos encontramos con
que SAP, el líder mundial de este tipo de sistemas, ofrece también interfaces que cumplen el estándar. Por lo
tanto, es innegable que se hace necesario el ofrecer una integración completa cumpliendo el estándar ISA-95
para el ERP Odoo, lo cual podría considerarse una oportunidad de mercado.
El estándar ANSI/ISA-95 no está enfocado tan sólo a la interfaz entre sistemas de la empresa y del control de
la producción, sino que también puede utilizarse como una buena guía que recopila los requisitos funcionales y
de los usuarios, para el desarrollo de aplicaciones MES y bases de datos y para la optimización procesos
productivos.
La utilización de estándares está creciendo en la industria, pero la cuestión permanece en si las empresas
también siguen esto estándares en sus métodos de trabajo; es por ello que existe un clamor que solicita la
creación de un certificado de cumplimiento del estándar ISA-95 para sistemas; sin embargo, de momento no
parece que se vaya a llevar a cabo, pues el estándar aún sigue en desarrollo.
62
Conclusiones y líneas futuras

5.2 Líneas de trabajo futuras


Como se ha mencionado anteriormente, en este trabajo nos hemos limitado a la integración de los sistemas
ERP y MES pero sólo en lo que respecta a la creación y finalización de órdenes de fabricación, quedando
fuera del alcance de la prueba de concepto el resto de posibles flujos de información que se pueden realizar
entre ambos.
Parece evidente concluir que un posible trabajo futuro sea continuar desarrollando la prueba de concepto para
cubrir el resto de objetos que permite integrar el estándar ISA-95, como son los productos, materiales,
equipamiento y activos físicos y humanos. De esta manera podríamos establecer una integración que cumpla
completamente el estándar.
Adicionalmente a lo anterior, sería interesante continuar con el desarrollo del módulo isa95mrp de Odoo que
permita la integración completa mediante ficheros B2MML incorporando parte del sistema Middleware dentro
de dicho módulo de tal manera que la comunicación en ambos sentidos sea mediante B2MML y, por tanto, el
módulo y a su vez el ERP cumpla completamente con dicho estándar.
De esta manera, no sería complicado, realizar una prueba de concepto más completa con la integración entre el
ERP Odoo y varios sistemas MES que cumplan con el estándar ISA-95 de distintos fabricantes.
REFERENCIAS
ANEXOS
A. Anexo A: Funcionalidades del módulo MRP de Odoo
Entorno de trabajo con Odoo
En primer lugar, para trabajar con una base de datos limpia en Odoo, vamos a crearnos una nueva base de
datos sobre la que trabajar. Para ello, en la página de login de Odoo, hacemos clic en Gestionar base de
datos.

Figura A-1. Página de Login de Odoo


Y a continuación en Crear base de datos.
Integración de sistemas ERP y MES mediante el estándar ANSI/ISA-95 65

Figura A-2. Página de gestión de base de datos de Odoo


Seguidamente introducimos los datos necesarios en el formulario de creación de base de datos:

Figura A-3. Página de creación de base de datos en Odoo


Nos aseguramos de no seleccionar la opción Load demonstration data para que no nos cree registros de
demostración en la base de datos y hacemos clic en Continue. Una vez que se crea una nueva base de datos,
se nos muestra un listado con todos los módulos que se pueden instalar en Odoo. En nuestro caso
seleccionamos el módulo MRP señalado en la siguiente captura:
66
Anexos

Figura A-4. Página de aplicaciones en línea de Odoo antes de instalar el módulo MRP
Hacemos clic en Install y esperamos a que cargue. En cuanto finaliza de instalar volvemos a la misma página
de instalación de módulos (Aplicaciones en línea):

Figura A-5. Página de Aplicaciones en línea de Odoo tras la instalación de MRP


Pero podemos observar que, además de instalar el módulo MRP que nos ocupa, también se han instalado los
módulos Inventory Management, Contactos, Debates y Facturación, que son necesarios para el correcto
funcionamiento del módulo MRP.
Ya estamos listos para comenzar a utilizar nuestro módulo de fabricación.

Introducción al módulo MRP de Odoo


Una vez instalado el módulo MRP, cuando accedemos al mismo, nos aparece la siguiente ventana:
Integración de sistemas ERP y MES mediante el estándar ANSI/ISA-95 67

Figura A-6. Página principal del módulo MRP de Odoo


En ella se nos dice que haciendo clic en el botón Crear podemos crear una orden de producción; sin embargo,
para poder entender mejor las órdenes de producción, primero debemos comprender las listas de materiales.

Crear una lista de materiales

Se puede pensar en una lista de materiales como una receta de cocina; ya que para fabricar un producto vamos
a necesitar una serie de materias primas que, gracias al proceso productivo, se convertirán en el producto final.
Por lo tanto, antes de crear una orden de producción vamos a crear un producto donde definiremos la lista de
materias primas necesarias para su fabricación.
Vamos a poner como ejemplo la fabricación de un PC de sobremesa que tiene como materias primas la
carcasa del PC, la placa base, la fuente de alimentación, el disco duro y la memoria RAM (un PC de
sobremesa tendrá más componentes, pero lo dejaremos simple de momento para mostrar las posibilidades del
módulo MRP de Odoo).
Para crear el producto, hacemos clic en el menú Productos y hacemos clic en el botón Crear:
68
Anexos

Figura A-7. Página principal de Productos del módulo MRP de Odoo


En el formulario de Producto, introducimos el nombre del producto y seleccionamos en Tipo de Producto la
opción Stockable Product para que sea un producto que se pueda almacenar una vez fabricado.

Figura A-8. Formulario de creación de Productos en el módulo MRP de Odoo


A continuación vamos a crear la lista de materiales necesarios para la fabricación del PC de Sobremesa. Para
ello, hacemos clic en el la opción Lista de materiales dentro del formulario del producto que acabamos de
crear y nos aparecerá la página de Lista de Materiales donde añadir materias primas para el producto.
Integración de sistemas ERP y MES mediante el estándar ANSI/ISA-95 69

Figura A-9. Página inicial de Lista de Materiales de Producto del módulo MRP de Odoo
Hacemos clic en el botón Crear y observamos que el campo Producto se rellena automáticamente:

Figura A-10. Formulario de creación de Listas de Materiales en el módulo MRP de Odoo


En primer lugar, en el campo Referencia pondremos la cadena Montaje Estándar para indicar el tipo de
montaje del producto que va a incluir las materias primas que añadiremos. Es decir, se puede tener distintas
listas de materiales para un mismo producto que muestren distintas configuraciones o montajes del mismo
producto. Además, seleccionaremos la opción Fabricar este producto para indicar que el producto se obtiene
a partir de una combinación o montaje de los distintos materiales y no es un simple conjunto de componentes
(kit).
Para añadir materias primas, hacemos clic en Añadir un elemento y vamos creando las materias primas que
vayamos a necesitar para la fabricación del producto final con sus cantidades adecuadas.
70
Anexos

Figura A-11. Lista de materiales de Producto en el módulo MRP de Odoo


En nuestro caso, como se ha descrito anteriormente, el producto PC Sobremesa (en su montaje estándar) va a
necesitar las materias primas siguientes:
• Una carcasa de PC.
• Una Placa Base
• Una Fuente de Alimentación
• Un Disco Duro de 250GB
• Dos módulos de memoria RAM de 4 GB.

Figura A-12. Lista de materiales de Producto finalizada


Integración de sistemas ERP y MES mediante el estándar ANSI/ISA-95 71

Crear una orden de producción

Una vez que hemos creado la lista de materiales, podemos continuar creando la orden de fabricación de
nuestro producto.
Para ello, seleccionamos el enlace del menú lateral Órdenes de producción y pulsamos el botón Crear.

Figura A-13. Formulario de creación de Orden de Fabricación


Nos aparece el formulario para la creación de una orden de producción con el número de referencia rellenado
como el número 1 (por ser la primera orden de producción que creamos) precedido por el Código MO (de
Manufacturing Order).
Al seleccionar el producto que acabamos de crear (PC Sobremesa), se rellena automáticamente el campo Lista
de materiales con la lista que creamos en el apartado anterior para el montaje estándar de un PC Sobremesa.
Si decidimos seleccionar una cantidad mayor que uno en el campo Cantidad de producto, estaremos
indicando que mediante esta orden de producción se van a fabricar varios productos y Odoo se encargará de
recalcular las materias primas necesarias para su producción.
El campo Fecha prevista se rellena automáticamente con las fecha y hora actuales porque Odoo interpreta que
queremos ordenar la fabricación de este producto en ese momento, pero podemos modificarlo para establecer
la fecha en la que deseamos que se realice la fabricación.
Se puede observar que, por defecto, la ubicación de las materias primas y de los productos finales es la misma
(WH/Existencias) que se refiere a los almacenes en los que se encuentra cada tipo de producto. Esto podemos
configurarlo a nuestro gusto creando tantos almacenes como necesitemos, pero en lo que se refiere a este
documento lo mantendremos simple dejando un único almacén de existencias.
El campo Documento Origen se refiere al documento que origina la orden de fabricación, que puede ser un
pedido de cliente o bien para almacenar. Al ser un campo no obligatorio lo dejaremos vacío.
72
Anexos

Figura A-14. Formulario de creación de Orden de Fabricación


Una vez que pulsamos en el botón Guardar, la orden de producción se crea en un estado de borrador llamado
Nuevo.

Figura A-15. Listado de Órdenes de Fabricación


Aunque la orden se encuentre en dicho estado, si seleccionamos la vista de calendario podremos ver que la
orden se puede ver en la fecha y hora que hemos seleccionado.
Integración de sistemas ERP y MES mediante el estándar ANSI/ISA-95 73

Figura A-16. Vista Calendario de ördenes de Fabricación


Sin embargo, si en el cuadro de búsqueda filtramos por los estados Pendiente, Preparado o En Producción,
nuestra orden desaparecerá del calendario pues no se encuentra en ninguno de estos estados.

Figura A-17. Vista Calendario Filtrado de ördenes de Fabricación.


Existe otra vista llamada kanban que muestra las órdenes de producción en tableros mostrando además el
estado en que se encuentran.
74
Anexos

Figura A-18. Vista Tablero de Órdenes de Fabricación


Volviendo a nuestra orden de producción, observamos que tenemos disponible el botón Confirmar
producción. Al hacer clic en dicho botón, vemos como la orden pasa del estado Nuevo al estado Esperando
materias primas.

Figura A-19. Formulario de Orden de Fabricación en estado Esperando Materias Primas


En este estado se rellena la sección Productos a consumir con todas las materias primas que creamos
anteriormente; sin embargo, aparecen en color rojo porque se necesita comprobar la disponibilidad de los
materiales en el almacén. Para ello, se nos activan los botones Reserva y Forzar reservas que sirven para
realizar una reserva de los materiales disponibles en el inventario o para forzar su reserva aunque no existan
los mismos en el inventario respectivamente. Al pulsar el botón Reserva observamos que la orden de
fabricación pasa a estado Listo para producir y los productos a consumir se ponen ya en color negro
indicando que ya se han reservado los materiales necesarios para la fabricación.
Integración de sistemas ERP y MES mediante el estándar ANSI/ISA-95 75

Figura A-20. Formulario de Orden de Fabricación en estado Listo para Producir


Ahora tenemos disponible el botón Producir porque ya disponemos de las materias primas necesarias para
ejecutar la fabricación del producto. Al pulsar en dicho botón nos aparecerá una ventana de confirmación
donde se detallan los materiales que se van a consumir y la cantidad de cada uno de ellos.

Figura A-21. Ventana de confirmación de producción de Orden de Fabricación


Al confirmar este mensaje, vemos como la orden de fabricación pasa a estado Realizado y se vacía la sección
Productos a consumir para que se llene la sección Productos consumidos con las materias primas de nuestra
lista de materiales.
76
Anexos

Figura A-22. Formulario de Orden de Fabricación en estado Realizado

Crear múltiples listas de materiales para un mismo producto

Como se comentó en el apartado anterior, es posible que necesitemos especificar distintas configuraciones
para un mismo producto que requiera que la lista de materiales sea distinta según las materias primas que se
utilicen. Para ello, Odoo nos permite crear varias listas de materiales para un mismo producto final; esto es útil
para, por ejemplo, crear un mismo producto con distintas configuraciones; en nuestro caso crearemos una
variación del montaje para poder definir un PC sobremesa con montaje multimedia que incluya una tarjeta
gráfica y más memoria RAM que la configuración estándar.
Para crear esta nueva lista de materiales podemos abrir la que creamos anteriormente y hacer clic en Acción >
Duplicar para que nos cree una nueva lista de materiales pero basada en los datos ya configurados en la lista
anterior.

Figura A-23. Formulario de Lista de Materiales de Producto (con acciones desplegadas)


Integración de sistemas ERP y MES mediante el estándar ANSI/ISA-95 77

Una vez duplicada la lista de materiales, podemos modificar los componentes para crear el nuevo tipo de
montaje.

Figura A-24. Formulario de Lista de Materiales de Producto


Como se puede ver sustituimos los dos módulos de memoria RAM de 4GB por dos módulos de 8GB y
añadimos la tarjeta gráfica de 2GB. Por tanto, ya disponemos de dos tipos de montaje para un mismo
producto.

Figura A-25. Listado de lista de materiales de producto


Si ahora vamos a crear una orden de producción nueva, podemos seleccionar el nuevo montaje multimedia en
lugar del montaje estándar en el campo Lista de materiales.
78
Anexos

Figura A-26. Formulario de creación de Orden de producción en estado Nuevo. Selección de lista de
materiales
Cuando guardamos y confirmamos producción de esta nueva orden de producción nos volverán a aparecer los
materiales en rojo en el apartado de Productos a consumir. Al hacer clic en Reserva, ya tendremos las
materias primas reservadas para su consumo en el proceso de fabricación.

Figura A-27. Formulario de creación de Orden de producción en estado Listo para producir
En esta ocasión vamos a consumir los materiales de uno en uno utilizando la flecha verde que aparece junto a
ellos; en lugar de pulsar el botón Producir. Esta manera de consumir los productos de uno en uno nos permite
tener un seguimiento del proceso de fabricación más a bajo nivel informando al sistema del consumo de los
productos a medida que se vayan utilizando.
Integración de sistemas ERP y MES mediante el estándar ANSI/ISA-95 79

Figura A-28. Formulario de creación de Orden de producción en estado Producción iniciada


En la captura anterior se puede observar que se han consumido tres materias primas (Carcasa PC, Placa Base y
Fuente de Alimentación) pero aún queda por incorporar a la fabricación el disco duro, las memorias RAM y la
tarjeta gráfica.
Cuando se hayan consumido todos los materiales necesarios, esto no quiere decir que el producto ya se haya
fabricado; si no que se han incorporado todas las materias primas a la fabricación.

Figura A-29. Formulario de creación de Orden de producción en estado Producción iniciada con materiales
consumidos.
Al pulsar el botón Producir, nos aparecerá la ventana de confirmación pero en esta ocasión no se listarán los
productos a consumir pues ya se han consumido de uno en uno.
80
Anexos

Figura A-30. Ventana de confirmación de Orden de Producción


En esta ventana de confirmación también se nos permite añadir algún material adicional que se requiera para
esta producción en concreto. Esto es muy útil en casos en los que haya un producto que incorporar pero en
casos aislados que ocurren muy pocas veces. Al confirmar la producción de la orden, la misma pasa a estado
Realizado.

Figura A-31. Formulario de Orden de producción en estado Realizado

Especificando componentes por rango de fechas

En este apartado vamos a comprobar cómo se comporta Odoo cuando especificamos los rangos de fechas de
los materiales de la lista de materiales. En nuestro caso vamos a suponer que a partir de una fecha determinada
vamos a dejar de montar los PCs de sobremesa con la placa base habitual y se van a comenzar a montar con
una nueva placa base de otro proveedor o de un modelo superior, por ejemplo.
Para ello, en la lista de materiales estándar editamos la línea de la placa base y ponemos la fecha deseada en el
campo Válido hasta. Además, añadimos un material Nueva Placa Base que indicaremos que estará disponible
a partir de la fecha introducida en el campo Válido desde.
Integración de sistemas ERP y MES mediante el estándar ANSI/ISA-95 81

Figura A-32. Formulario de Lista de materiales con rangos de fechas para los materiales
Para ver cómo funcionan estos campos de rango de fechas vamos a crear una nueva orden de fabricación con
una fecha prevista de fabricación posterior a la fecha en que deja de estar disponible la placa base antigua.

Figura A-33. Formulario de creación de Orden de producción con fecha de fabricación posterior a la fecha de
disponibilidad de materiales
Observamos que, al confirmar la producción de la orden de fabricación, los productos a consumir se ven ahora
distintos, ya que no aparece la placa base antigua pero sí aparece la Nueva Placa Base.
Hay que destacar que estos campos no se tienen en cuenta para fechas futuras; es decir, si en la orden de
facturación seleccionamos una fecha prevista futura y en la lista de materiales hemos configurado un cambio
de materias primas por fechas también futuras (anteriores a la fecha prevista de la orden de fabricación), en los
productos a consumir de la orden no se refleja este cambio de materias primas. Si las fechas de cambio de
materiales ya han pasado, al crear la orden de producción, sí se refleja el cambio de materiales en los productos
82
Anexos

a consumir.
Esto es probablemente un bug que se corrija en nuevas actualizaciones de Odoo, pero de momento hay que
tenerlo en cuenta para la especificación de componentes por rango de fechas.

Funciones adicionales del módulo MRP de Odoo

Creación de subproductos con la lista de materiales

Hasta el momento todas las materias primas que hemos ido consumiendo en nuestras órdenes de producción
han sido del tipo consumible (Consumable), por lo que Odoo, nos permitía su reserva incluso aunque no los
tuviéramos en el inventario. Sin embargo, podemos configurar uno de los materiales de la lista como un
producto almacenable (Stockable Product) que sea subproducto de otras materias primas de manera que se
puede configurar el módulo MRP de manera más modular.
En nuestro ejemplo supongamos que una placa base no es un producto consumible y que tiene que ser
fabricado y almacenado a partir de un circuito integrado, un microprocesador y un ventilador para este.

Figura A-34. Lista de Materiales del producto Nueva Placa Base


Si ahora nos creamos una nueva orden de producción de un PC sobremesa con montaje estándar, si
confirmamos su producción y a continuación intentamos reservar los materiales de la lista de materiales,
observaremos que logramos reservar todos los materiales exceptuando la nueva placa base que no somos
capaces de reservar de forma normal porque lo hemos modificado para hacerlo un producto que debemos
fabricar para tenerlo disponible.
Integración de sistemas ERP y MES mediante el estándar ANSI/ISA-95 83

Figura A-35. Formulario de creación de orden de producción de producto con materiales que han de ser
fabricados
En esta ocasión podemos bien crear una orden de fabricación para fabricar una nueva placa base o bien
podemos forzar la reserva de materiales (botón Forzar reservas) que nos permite reservar materiales aun
cuando éstos no estén disponibles. Esta opción es útil cuando sabemos que tenemos disponibilidad del
producto aunque Odoo desconozca su existencia en el inventario.

Figura A-36. Formulario de Orden de fabricación en estado Realizado


Si vamos ahora al módulo Inventario, podemos observar los efectos que nuestras órdenes de producción han
causado en la cantidad de productos en el inventario. Hacemos clic en Inventario, y en el menú Informes
hacemos clic en Valoración del inventario.
84
Anexos

Figura A-37. Informe de Valoración de Inventario


Observamos que tenemos en stock tres PCs de sobremesa, pero tenemos números negativos en el inventario
del resto de materiales.
Si desglosamos la información podemos observar las fechas en que se han producido los consumos e
incrementos de materiales y productos por nuestras órdenes de producción.

Figura A-38. Informae de Valoración de inventario con información desglosada


En la próxima sección profundizaremos un poco más en esta información de inventarios.

Gestión de inventario de subproductos

Como vimos en la sección anterior, al configurar la nueva placa base como un producto que se debe fabricar,
al reservar materiales en una orden de fabricación, la placa base se mantiene en rojo y sólo pudimos
consumirla forzando su reserva, veamos ahora cómo podemos arreglar estos problemas de abastecimiento del
Integración de sistemas ERP y MES mediante el estándar ANSI/ISA-95 85

inventario de una forma más convencional.


Nos dirigimos al módulo de inventario y seleccionamos Productos dentro de la sección Control inventario.

Figura A-39. Tablero de productos en el módulo de Inventario


En esta ventana podemos observar que el producto Nueva Placa Base tiene una cantidad a mano de -1 y una
cantidad prevista de -2; esto quiere decir que no teníamos ninguna unidad en el inventario y, tras forzar su
reserva, se ha decrementado su cantidad para aparecer como -1. Además, existe una orden de fabricación
prevista que necesitará utilizar una nueva placa base, por lo que su cantidad prevista será -2. Por otro lado, si
nos fijamos en el producto PC Sobremesa, vemos que disponemos de 3 unidades y tenemos previsto disponer
de 5 unidades, por lo que se intuye que existen dos órdenes de fabricación en espera de realizarse.
Para arreglar estas cantidades negativas en el inventario, Odoo nos ofrece la opción de crear ajustes de
inventario. En el módulo inventario seleccionamos Ajustes de inventario dentro de la sección Control
Inventario. Hacemos clic en el botón Crear.
86
Anexos

Figura A-40. Formulario de creación de Ajuste de Inventario


Rellenamos el formulario dándole un nombre al ajuste de inventario y seleccionando Solo un producto y
definimos que el producto del que vamos a ajustar su inventario es Nueva Placa Base. Hacemos clic en el
botón Iniciar Inventario para ajustar las cantidades del producto en stock.

Figura A-41. Formulario de ajuste de inventario en proceso


En el apartado Cantidad real informamos al sistema de que en realidad, aparte de la Nueva Placa Base que ya
hemos usado, aún nos queda en el inventario una unidad más.
Al hacer clic en el botón Validar inventario, Odoo actualizará las unidades del producto seleccionado en el
inventario.
Integración de sistemas ERP y MES mediante el estándar ANSI/ISA-95 87

Figura A-42. Formulario de ajuste de inventario validado


Si ahora volvemos a la página de productos, veremos que existe una unidad del producto Nueva Placa Base a
mano y ninguna unidad prevista, porque tenemos una orden de fabricación pendiente que la usará.

Figura A-43. Tablero de Productos


Si necesitáramos más nuevas placas base para otras órdenes de producción podríamos decidir lanzar su
fabricación mediante una orden de fabricación de Nuevas Placas Base.
88
Anexos

Figura A-44. Formulario de creación de Orden de fabricación para subproducto


Observamos que hemos configurado una orden de fabricación de 5 unidades de Nuevas Placas Base y las
materias primas necesarias son productos consumibles, por lo que podemos reservarlas sin problemas
(aparecerán con unidades negativas en el inventario).

Figura A-45. Formulario de Orden de fabricación para subproducto en estado Realizado


Una vez confirmada la producción de las nuevas placas base, nos aparecerán las 5 nuevas unidades adicionales
en la ventana de productos; por lo tanto, tendremos 6 unidades a mano y 5 previstas.
Integración de sistemas ERP y MES mediante el estándar ANSI/ISA-95 89

Figura A-46. Tablero de Productos en el módulo Inventario.


Si confirmamos la producción de las distintas órdenes de fabricación que tenemos en espera de materiales, se
actualizarán el número de productos en la ventana de productos y se igualarán las unidades a mano con las
previstas.

Figura A-47. Tablero de Productos en el módulo Inventario


En el siguiente apartado veremos cómo podemos automatizar las órdenes de fabricación para que se produzca
bajo pedido sin nuestra intervención.

Creación automática de órdenes de producción bajo pedido

Odoo nos permite la opción de generar órdenes de producción de productos intermedios a partir de la orden de
producción del producto final; es decir, en nuestro ejemplo, podríamos configurar el producto intermedio
90
Anexos

Nueva Placa Base para que cuando se genere una orden de fabricación de PCs de sobremesa que requieran la
fabricación de Nuevas Placas Base, por no tener en stock, se cree de manera automática la orden de
producción para las nuevas placas base necesarias para cubrir la producción de PCs de Sobremesa de la orden
original.
Para ello, vamos a la configuración del producto Nueva Placa Base y en la pestaña Inventario, en la sección
Rutas, activamos las opciones Fabricar y Bajo Pedido.

Figura A-48. Formulario de Producto. Estableciendo fabricación bajo demanda.


Una vez realizada esta configuración en el producto intermedio, si lanzamos la orden de fabricación de un
producto final (PC Sobremesa) y reservamos los materiales, nos volverá a aparecer marcado en rojo el
producto intermedio que se ha de construir (Nueva Placa Base).

Figura A-49. Formulario de Orden de producción en estado Esperando materias primas


Pero en esta ocasión, si volvemos al listado de órdenes de producción, observaremos que se ha creado de
forma automática una nueva orden para la producción de la Nueva Placa Base (la orden MO00012 en la
Integración de sistemas ERP y MES mediante el estándar ANSI/ISA-95 91

siguiente captura) que se encuentra en espera de materias primas y cuyo Documento Origen es nuestra orden
de producción de PC de Sobremesa original (MO00011).

Figura A-50. Listado de Órdenes de fabricación. Orden de producción de subproducto generada


automáticamente
Si lanzamos esta nueva orden y fabricamos el producto intermedio mediante la reserva manual de los
materiales y finalizamos su producción.

Figura A-51. Formulario de Orden de fabricación de producto intermedio en estado Realizado


Cuando volvamos al listado de órdenes de producción podremos ver que nuestra orden original ha pasado de
manera automática a estado Listo para producir.
92
Anexos

Figura A-52. Listado de órdenes de fabricación. Orden de producción de producto pasa automáticamente a
estado Listo para producir
Y ya podremos finalizar la fabricación de nuestro producto final.

Figura A-53. Formulario de Orden de producción en estado Realizado


Como se puede intuir, el módulo MRP de Odoo nos permite la definición de tantos niveles de productos
intermedios como necesitemos; de tal manera que la definición de nuestro sistema de producción se puede
hacer tan modular como se desee, evitando así largas listas de materiales para productos finales.
Supongamos ahora que deseamos definir el material de la Nueva Placa Base llamado Circuito integrado como
un producto también intermedio que se compone de dos materias primas: Chip controlador de memoria y Chip
controlador I/O. Para definir este producto intermedio, editamos el que ya teníamos para añadirle una lista de
materiales.
Integración de sistemas ERP y MES mediante el estándar ANSI/ISA-95 93

Figura A-54. Formulario de Lista de Materiales de Producto


Además, tenemos que modificar el tipo de producto para hacer al Circuito Integrado un Stockable Product.

Figura A-55. Página de detalle de producto


Y también, en la pestaña Inventario informaremos al sistema de que es un producto que se puede fabricar bajo
pedido.
94
Anexos

Figura A-56. Página de detalle de producto


Análogamente, podemos actualizar la cantidad de este producto intermedio a mano mediante el botón Update
Qty On Hand. Modificamos el número de cantidad negativo (por ser hasta ahora un producto consumible que
podíamos reservar aun quedando una cantidad negativa en el inventario) para poner la cantidad a cero.

Figura A-57. Ventana de actualización de cantidad de producto en stock


Si ahora creamos una orden de producción de un PC de sobremesa y realizamos la reserva de materiales,
observaremos un comportamiento similar al anterior, ya que la materia prima Nueva Placa Base queda en rojo
por no poder reservarse.
Integración de sistemas ERP y MES mediante el estándar ANSI/ISA-95 95

Figura A-58. Formulario de Orden de producción de producto compuesto por subproductos en estado
Esperando materias primas
Pero si vemos ahora el listado de órdenes de producción, observaremos que se ha creado una orden de
producción de la nueva placa base que a su vez ha generado una orden de producción para el circuito integrado
que lo compone.

Figura A-59. Listado de Órdenes de producción. Se han creado automáticamente dos órdenes de productos
intermedios del producto final
Si intentamos ahora realizar la reserva de materiales de la orden de producción de la Nueva Placa Base
(MO00014), observaremos que el material Circuito Integrado no se puede reservar porque tiene una orden de
fabricación en espera de materiales (MO00015).
96
Anexos

Figura A-60. Formulario de Orden de producción de producto intermedio que depende de subproducto
Por lo tanto, tenemos que ejecutar la orden de producción del circuito integrado antes de poder fabricar la
nueva placa base. Una vez que el Circuito Integrado esté disponible, orden de fabricación de la Nueva Placa
Base pasará a estado Listo para Producir.

Figura A-61. Listado de Órdenes de producción. Producto intermedio finalizado


Y en cuanto se produzca la Nueva Placa Base, tendremos la orden de fabricación del PC Sobremesa en estado
Listo para Producir.
Integración de sistemas ERP y MES mediante el estándar ANSI/ISA-95 97

Figura A-62. Listado de Órdenes de producción. Producto intermedio finalizado


De esta manera, podemos organizar nuestro sistema de producción de la forma que más se adecúe a nuestras
necesidades teniendo los productos intermedios en órdenes de producción distintas de los productos finales, se
obtiene así un diseño modular del sistema que puede obedecer a una división lógica o física para modelar el
proceso productivo que se va a controlar con este módulo MRP de Odoo.

Órdenes de producción automatizadas con reglas de reabastecimiento

En esta sección vamos a definir unas cantidades mínimas y máximas de materiales y productos para que las
órdenes de producción se lancen de forma automática para satisfacer esas unidades mínimas.
Supongamos que la Carcasa de PC es un producto que tenga que ser montado por nuestros operarios a partir
de las piezas de montaje del proveedor. Al ser una pieza tan básica en la producción de PCs de sobremesa,
digamos que queremos tener una cantidad mínima en stock de 5 unidades y como máximo 20 para no saturar
el espacio de nuestro almacén. Para ello modificamos el producto Carcasa PC para hacerlo un Stockable
Product, en lugar de Consumable.
98
Anexos

Figura A--63. Formulario de Producto.


A continuación, en la pestaña Inventario, lo definimos como un producto a Fabricar, pero dejamos
desactivada la opción Bajo Pedido.

Figura A-64. Formulario de Producto


A continuación, vamos a definir las unidades mínimas y máximas del producto en el inventario mediante la
opción Reglas de reabastecimiento.
Integración de sistemas ERP y MES mediante el estándar ANSI/ISA-95 99

Figura A-65. Formulario de reglas de abastecimiento de producto


Establecemos como cantidad mínima 5 y como cantidad máxima, 20. Dichas cantidades mínima y máxima se
definen como:
• Cantidad mínima: Cuando las existencias virtuales estén por debajo de la cantidad mínima
especificada en este campo, Odoo generará un abastecimiento para llevar la cantidad prevista a la
cantidad máxima.
• Cantidad máxima: Cuando las existencias virtuales estén por debajo de la cantidad mínima, Odoo
generará un abastecimiento para llevar la cantidad especificada aquí como máxima.
El abastecimiento de los productos se puede referir tanto a una orden de compra como a una orden de
fabricación, como es nuestro caso.
También tendremos que crear una lista de materiales para este producto.
100
Anexos

Figura A-66. Página de Lista de materiales de producto


Si volvemos ahora al detalle del producto Carcasa PC, observaremos que ya están definidas sus reglas de
reabastecimiento con cantidades mínima y máxima, pero la cantidad a mano y prevista se mantienen en -12
unidades.

Figura A-67. Formulario de Producto con reglas de abastecimiento


Para que las reglas de reabastecimiento se ejecuten, debemos solicitarlo manualmente en el módulo
Inventario haciendo clic en el menú Run Reordering Rules dentro de la sección Planificaciones.
Integración de sistemas ERP y MES mediante el estándar ANSI/ISA-95 101

Figura A-68. Página de confirmación de ejecución de reglas de reabastecimiento


Al confirmar y finalizar las reglas de reabastecimiento, si vemos el listado de órdenes de producción
detectaremos que se ha creado de manera automática una orden de producción para 32 unidades de Carcasas
PC que cubrirán el déficit de 12 que teníamos más las 20 unidades para llegar a la cantidad máxima.

Figura A-69. Listado de Órdenes de producción. Se crea orden de fabricación automática a partir de regla de
abastecimiento
Si ejecutamos dicha orden de producción y volvemos al detalle del producto observaremos que la cantidad de
producto ha llegado a 20, el máximo que habíamos configurado.
102
Anexos

Figura A-70. Formulario detalle de producto tras la ejecución de la orden de fabricación de reabastecimiento

Utilizando Centros de trabajo para el seguimiento de la producción

Hasta el momento hemos estado gestionando la producción mediante órdenes de fabricación; sin embargo,
Odoo nos ofrece la posibilidad de gestionarla mediante órdenes de trabajo. Para modificar esta forma de
trabajar, en primer lugar tenemos que modificar la configuración del módulo MRP de Odoo, por tanto, en la
sección Configuración, hacemos clic en Settings y en la opción Rutas de Producción se selecciona
Gestionar la producción por órdenes de trabajo como se muestra en la captura siguiente.

Figura A-71. Página de configuración del módulo MRP. Se señala la opción para gestionar las órdenes de
producción como órdenes de trabajo
Con esta configuración las operaciones de una orden de trabajo nos permiten crear y gestionar las operaciones
de fabricación que deben seguirse en nuestros distintos centros de trabajo con el fin de fabricar un producto.
Dichos centros de trabajo se asocian a las listas de materiales que definirán las materias primas necesarias.
Integración de sistemas ERP y MES mediante el estándar ANSI/ISA-95 103

En cuanto modifiquemos esta configuración, nos aparecerá dentro del menú de configuración dos nuevas
entradas correspondientes a los Centros de producción y Rutas de Producción, veamos con más detalle
cada uno de ellos.
Al acceder al menú Centros de producción nos aparecerá la opción de crear un centro de trabajo que nos
permiten crear y gestionar las unidades de fabricación. Estos centros se componen de trabajadores y/o
máquinas a las que se asignarán tareas y se configurará su capacidad y previsión de la planificación.

Figura A-72. Página inicial de Centros de producción


Supongamos que queremos crear un centro de producción donde se realice el montaje de la Nueva Placa Base.
En el formulario para crear el Centro de trabajo tenemos que rellenar los siguientes campos:
• Nombre: Nombre con el que conoceremos el centro de producción.
• Tipo de recurso: Se define si el centro de trabajo consta de recursos materiales o humanos.
• Horario de trabajo: Horario en el que trabaja el centro de producción.
• Código: Código interno con el que se nomina al centro de producción.
• Activo: Establece si el centro de trabajo está activo o no.
• Información de capacidad:
o Factor de eficiencia: representa la eficiencia de los recursos para completar tareas; es decir,
la capacidad del centro de trabajo para completar tareas en un periodo determinado. Por
ejemplo, un recurso con un ciclo de 5 días con 5 tareas asignadas, tendrá una carga del 100%;
sin embargo, si configuramos una eficiencia del 200%, entonces su carga será del 50%.
o Capacidad por ciclo: Número de operaciones que este centro de trabajo puede hacer en
paralelo. Si tenemos 5 operarios, la capacidad por ciclo sería de 5.
o Tiempo para 1 ciclo (horas): Tiempo en horas para realizar un ciclo.
o Tiempo antes producción: Tiempo en horas para la configuración y preparación de los
recursos antes de ejecutar sus tareas.
o Tiempo después producción: Tiempo en horas para la limpieza tras la ejecución de sus
tareas.
104
Anexos

• Información de costes:
o Producto centro producción: Producto que se genera en el centro de producción. Sirve para
seguir la pista a sus costes de producción fácilmente en la contabilidad analítica.
o Coste por hora: Coste horario del centro de producción.
o Coste por ciclo: Coste del centro de producción por ciclo.
• Descripción: Texto que describa más concretamente al centro de producción.

Figura A-73. Formulario de creación de centro de trabajo


En nuestro ejemplo, llamamos al centro de producción Montaje de Placa Base y lo configuramos con recursos
materiales con un tiempo por ciclo de 15 minutos y unos tiempos de pre y post producción de 3 y 5 minutos
respectivamente.
Como podemos observar, aún no hemos relacionado nuestro centro de trabajo con ningún producto ni con
ninguna lista de materiales. Para establecer esa relación tenemos que crear Rutas de Producción.
Integración de sistemas ERP y MES mediante el estándar ANSI/ISA-95 105

Figura A-74. Página inicial de Rutas de Producción


Estas Rutas de producción nos permiten definir el flujo de trabajo de las operaciones de producción. Están
relacionadas con las listas de materiales de los productos finales y permiten crear y gestionar las operaciones
en los centros de producción para fabricar un producto.
Para crear una Ruta de Producción debemos de rellenar el formulario con la siguiente información:
• Nombre: Nombre de la Ruta de producción.
• Código: Código interno para la Ruta de producción
• Ubicación de producción: Ubicación física de la empresa en la que se localiza.
• Activo: Indica si la Ruta se encuentra activa o inactiva.
• Operaciones del centro de producción: Operaciones asociadas a la Ruta que se ejecutan en un
determinado centro de producción.
• Notas: Notas adicionales para la Ruta de Producción.
106
Anexos

Figura A-75. Formulario de creación de Rutas de producción


La Ruta de producción se asocia a los Centros de producción mediante las operaciones de dicho centro. Estas
operaciones requieren la siguiente información:
• Nombre: Nombre de la operación del centro de producción.
• Centro de producción: Centro de producción donde se realizará la operación.
• Número de ciclos: Número de iteraciones que debe realizar este centro de producción en la operación
indicada en la ruta.
• Número de horas: Tiempo en horas para este centro de producción para realizar la operación
específica en el proceso productivo.
• Descripción: Descripción más detallada de lo que hace la operación.

Figura A-76. Ventana de creación de operaciones en el centro de producción


Con esta información ya tenemos creada nuestra ruta de producción que engloba los montajes internos de
Integración de sistemas ERP y MES mediante el estándar ANSI/ISA-95 107

nuestra empresa y tiene como única operación el montaje de las placas base en el centro de trabajo de montaje
de las mismas.

Figura A-77. Formulario de Ruta de producción


Ahora nos queda asignar la ruta que acabamos de crear con la lista de materiales que debe lanzar las órdenes
de trabajo al centro especificado en la ruta. Para ello, editamos la lista de materiales del montaje del producto
Nueva Placa Base y veremos que ahora tenemos un nuevo campo por rellenar llamado Ruta de producción
que se define como la lista de operaciones (lista de centros de trabajo) para producir productos finales. La ruta
se utiliza principalmente para calcular los costes de los centros de trabajo durante las operaciones y planificar
su carga de trabajo prevista basada en la planificación de la producción.

Figura A-78. Formulario de Lista de Materiales con Ruta de producción asignada


Ahora ya podemos crear una orden de producción de una Nueva Placa Base que generará la correspondiente
orden de trabajo para el centro de producción que hemos definido previamente.
108
Anexos

Figura A-79. Formulario de creación de producto con Ruta de producción asignada


Como vemos, al seleccionar el producto a fabricar (Nueva Placa Base), se rellena automáticamente la Lista de
materiales y la Ruta de producción. Al confirmar la fabricación del producto, la orden pasará a estado
Esperando materias primas y se creará una orden de trabajo asignada al centro de producción que creamos
anteriormente.

Figura A-80. Formulario de orden de producción con orden de trabajo creada automáticamente
En la orden de trabajo que se ha creado automáticamente podemos ver que se calcula el número de horas
según configuramos en el centro de trabajo; es decir, se suma el tiempo para un ciclo al tiempo necesario para
la pre y post producción del artículo (total de 23 minutos en el ejemplo).
Si vamos ahora al listado de órdenes de producción, veremos que la configuración de rutas y centros de
producción no ha afectado a las configuraciones previas que habíamos definido para la fabricación de los
productos intermedios y; por tanto, se ha generado una orden de producción para el circuito integrado
necesario para la nueva placa base.
Integración de sistemas ERP y MES mediante el estándar ANSI/ISA-95 109

Figura A-81. Listado de órdenes de producción


Por lo tanto, podemos seguir con la producción de ambos productos como hacíamos hasta ahora, sólo que en
esta ocasión se va a generar una orden de trabajo para el centro de producción según la ruta que se ha
configurado.
110
Anexos

B. Anexo B: Fichero B2MML generado con el módulo isa95mrp de Odoo


<ProductionSchedule>
<ID>38</ID>
<Description>Manufacturing Order</Description>
<HierarchyScope>Site</HierarchyScope>
<PublishedDate>2016-06-03 15:20:21</PublishedDate>
<StartTime />
<EndTime />
<EquipmentElementLevel>Site</EquipmentElementLevel>
<ProductionRequest>
<ID>38</ID>
<Description>MO00044</Description>
<ProductProductionRuleIDGroup />
<HierarchyScope>False</HierarchyScope>
<StartTime>2016-05-31 11:26:28</StartTime>
<EndTime>False</EndTime>
<Priority>1</Priority>
<SegmentRequirement>
<ID>38</ID>
<ProductSegmentID />
<ProcessSegmentID />
<Description>MO00044</Description>
<HierarchyScope>False</HierarchyScope>
<EarliestStartTime>2016-05-31
11:26:28</EarliestStartTime>
<LatestEndTime>2016-06-01 11:26:28</LatestEndTime>
<Duration>0.0</Duration>
<ProductionParameter>
<ProductSegmentID />
<ProcessSegmentID />
<Parameter />
</ProductionParameter>
<PersonnelRequirement>
<PersonnelClassID />
<PersonID />
<Description />
<HierarchyScope />
<Quantity />
<PersonnelRequirementProperty>
<ID />
Integración de sistemas ERP y MES mediante el estándar ANSI/ISA-95 111

<Description />
<Value />
<Quantity />
</PersonnelRequirementProperty>
<RequiredByRequestedSegmentResponse />
</PersonnelRequirement>
<EquipmentRequirement>
<EquipmentClassID />
<EquipmentID />
<Description />
<HierarchyScope />
<Quantity />
<EquipmentRequirementProperty>
<ID />
<Description />
<Value />
<Quantity />
</EquipmentRequirementProperty>
<RequiredByRequestedSegmentResponse />
</EquipmentRequirement>
<PhysicalAssetRequirement>
<PhysicalAssetClassID />
<PhysicalAssetID>False</PhysicalAssetID>
<Description />
<HierarchyScope>False</HierarchyScope>
<Quantity />
<PhysicalAssetRequirementProperty>
<ID>False</ID>
<Description>False</Description>
<Value />
<Quantity>1</Quantity>
</PhysicalAssetRequirementProperty>
<RequiredByRequestedSegmentResponse />
</PhysicalAssetRequirement>
<MaterialRequirement>
<MaterialClassID />
<MaterialDefinitionID />
<MaterialLotID />
<MaterialSubLotID />
112
Anexos

<Description>Circuito Integrado</Description>
<HierarchyScope>False</HierarchyScope>
<MaterialUse>Product</MaterialUse>
<Quantity>1.0</Quantity>
<AssemblyRequirement />
<AssemblyType />
<AssemblyRelationship />
<MaterialRequirementProperty>
<ID>11</ID>
<Description>
Circuito Integrado
</Description>
<Value>Product</Value>
<Quantity>1.0</Quantity>
</MaterialRequirementProperty>
<RequiredByRequestedSegmentResponse />
</MaterialRequirement>
<MaterialRequirement>
<MaterialClassID />
<MaterialDefinitionID />
<MaterialLotID />
<MaterialSubLotID />
<Description>Chip Controlador
Memoria</Description>
<HierarchyScope>False</HierarchyScope>
<MaterialUse>Consumed</MaterialUse>
<Quantity>1.0</Quantity>
<AssemblyRequirement />
<AssemblyType />
<AssemblyRelationship />
<MaterialRequirementProperty>
<ID>14</ID>
<Description>
Chip Controlador Memoria
</Description>
<Value>Raw Material</Value>
<Quantity>1.0</Quantity>
</MaterialRequirementProperty>
<RequiredByRequestedSegmentResponse />
</MaterialRequirement>
Integración de sistemas ERP y MES mediante el estándar ANSI/ISA-95 113

<MaterialRequirement>
<MaterialClassID />
<MaterialDefinitionID />
<MaterialLotID />
<MaterialSubLotID />
<Description>Chip Controlador I/O</Description>
<HierarchyScope>False</HierarchyScope>
<MaterialUse>Consumed</MaterialUse>
<Quantity>1.0</Quantity>
<AssemblyRequirement />
<AssemblyType />
<AssemblyRelationship />
<MaterialRequirementProperty>
<ID>15</ID>
<Description>Chip Controlador I/O
</Description>
<Value>Raw Material</Value>
<Quantity>1.0</Quantity>
</MaterialRequirementProperty>
<RequiredByRequestedSegmentResponse/>
</MaterialRequirement>
<RequiredByRequestedSegmentResponse />
<SegmentState />
</SegmentRequirement>
<SegmentResponse>False</SegmentResponse>
<RequestState />
</ProductionRequest>
<ScheduleState />
</ProductionSchedule>
114
Anexos

C. Anexo C: Código del módulo isa95mrp de Odoo


__openerp__.py

# -*- coding: utf-8 -*-


{
‘name’: "ISA95mrp",
‘summary’: """ MRP module modification to make it ISA-95 Standard
compliant. """,
‘description’: """
MRP module modification to make it ISA-95 Standard compliant by
sending Manufacturing Orders to a MES (webservice) via B2MML files.
""",
‘author’: "Álvaro Rojas",
‘website’: "",
# Categories can be used to filter modules in modules listing
# Check
https://github.com/odoo/odoo/blob/master/openerp/addons/base/module/module_da
ta.xml
# for the full list
‘category’: ‘Manufacturing’,
‘version’: ‘0.1’,
# any module necessary for this one to work correctly
‘depends’: [‘base’,’mrp’],
# always loaded
‘data’: [
‘isa95mrp_view.xml’,
‘isa95mrp_workflow.xml’,
],
# only loaded in demonstration mode
‘demo’: [],
‘installable’: True,
‘auto_install’: False,
}

isa95mrp.py

# -*- coding: utf-8 -*-

from openerp import models, fields, api


from openerp.osv import fields, orm
from xml.etree import ElementTree
from suds.client import suds
from suds.client import Client
import base64
import datetime
import logging
from openerp.osv import orm

class isa95mrp_production(orm.Model):
"""
Extending Production Orders / Manufacturing Orders Workflow
"""
_inherit = ‘mrp.production’
_columns = {
‘state’: fields.selection([
(‘draft’, ‘New’),
(‘cancel’, ‘Cancelled’),
(‘confirmed’, ‘Awaiting Raw Materials’),
Integración de sistemas ERP y MES mediante el estándar ANSI/ISA-95 115

(‘ready’, ‘Ready to Produce’),


(‘send_MES’, ‘Envío al MES’),
(‘in_production’, ‘Production Started’),
(‘done’, ‘Done’)
],string=’Status’, readonly=True,
track_visibility=’onchange’, copy=False,
help="When the production order is created the status
is set to ‘Draft’.\n"
"If the order is confirmed the status is set to
‘Waiting Goods’.\n"
"If any exceptions are there, the status is set to
‘Picking Exception’.\n"
"If the stock is available then the status is set to
‘Ready to Produce’.\n"
"When the order is sent to the MES then the status is
set to ‘Send to MES’.\n"
"When the production gets started then the status is
set to ‘In Production’.\n"
"When the production is over, the status is set to
‘Done’."),
}

def generateB2MML(self, cr, uid, ids, context=None) :


date_today = datetime.datetime.now()
date_tomorrow = date_today + datetime.timedelta(days=1)
man_order = self.browse(cr, uid, ids, context=context)
routing_obj = man_order.routing_id
product_obj = man_order.product_id
bom_obj = man_order.bom_id
# <ProductionSchedule>
productionSchedule = ElementTree.Element("ProductionSchedule")
# <ID />
productionScheduleID =
ElementTree.SubElement(productionSchedule, "ID")
productionScheduleID.text = str(man_order.id)
# <Description />
productionScheduleDesc =
ElementTree.SubElement(productionSchedule, "Description")
productionScheduleDesc.text = "Manufacturing Order"
# <HierarchyScope />
productionScheduleHierarchyScope =
ElementTree.SubElement(productionSchedule, "HierarchyScope")
productionScheduleHierarchyScope.text = "Site"
# <PublishedDate />
productionSchedulePublishedDate =
ElementTree.SubElement(productionSchedule, "PublishedDate")
productionSchedulePublishedDate.text =
date_today.strftime(‘%Y-%m-%d %H:%M:%S’)
# <StartTime />
productionScheduleStartTime =
ElementTree.SubElement(productionSchedule, "StartTime")
productionSchedulePublishedDate.text =
date_today.strftime(‘%Y-%m-%d %H:%M:%S’)
# <EndTime />
productionScheduleEndTime =
ElementTree.SubElement(productionSchedule, "EndTime")
productionSchedulePublishedDate.text =
date_tomorrow.strftime(‘%Y-%m-%d %H:%M:%S’)
# <EquipmentElementLevel />
116
Anexos

productionScheduleEquipmentElementLevel =
ElementTree.SubElement(productionSchedule,
"EquipmentElementLevel")
productionScheduleEquipmentElementLevel.text = "Site"
# <ProductionRequest>
productionScheduleProductionRequest =
ElementTree.SubElement(productionSchedule,
"ProductionRequest")
# <ID />
productionScheduleProductionRequestID =
ElementTree.SubElement(productionScheduleProductionRequest,
"ID")
productionScheduleProductionRequestID.text = str(man_order.id)
# <Description />
productionScheduleProductionRequestDescription =
ElementTree.SubElement(productionScheduleProductionRequest,
"Description")
productionScheduleProductionRequestDescription.text =
str(man_order.name)
# <ProductProductionRuleIDGroup />

productionScheduleProductionRequestProductProductionRuleIDGroup =
ElementTree.SubElement(productionScheduleProductionRequest,
"ProductProductionRuleIDGroup")
# <HierarchyScope />
productionScheduleProductionRequestHierarchyScope =
ElementTree.SubElement(productionScheduleProductionRequest,
"HierarchyScope")
productionScheduleProductionRequestHierarchyScope.text =
str(routing_obj.name)
# <StartTime />
productionScheduleProductionRequestStartTime =
ElementTree.SubElement(productionScheduleProductionRequest,
"StartTime")
productionScheduleProductionRequestStartTime.text =
str(man_order.date_planned)
# <EndTime />
productionScheduleProductionRequestEndTime =
ElementTree.SubElement(productionScheduleProductionRequest,
"EndTime")
productionScheduleProductionRequestEndTime.text =
str(man_order.date_finished)
# <Priority />
productionScheduleProductionRequestPriority =
ElementTree.SubElement(productionScheduleProductionRequest,
"Priority")
productionScheduleProductionRequestPriority.text =
str(man_order.priority)
# <SegmentRequirement>
productionScheduleProductionRequestSegmentRequirement =
ElementTree.SubElement(productionScheduleProductionRequest,
"SegmentRequirement")
# <ID />

productionScheduleProductionRequestSegmentRequirementID =
ElementTree.SubElement(productionScheduleProductionRequestSegmentR
equirement, "ID")

productionScheduleProductionRequestSegmentRequirementID.text =
str(man_order.id)
# <ProductSegmentID />
Integración de sistemas ERP y MES mediante el estándar ANSI/ISA-95 117

productionScheduleProductionRequestSegmentRequirementProductSegmentID =
ElementTree.SubElement(productionScheduleProductionRequestSegmentRequirement,
"ProductSegmentID")
# <ProcessSegmentID />
productionScheduleProductionRequestSegmentRequirementProcessSegmentID =
ElementTree.SubElement(productionScheduleProductionRequestSegmentRequirement,
"ProcessSegmentID")
# <Description />
productionScheduleProductionRequestSegmentRequirementDescription =
ElementTree.SubElement(productionScheduleProductionRequestSegmentRequirement,
"Description")
productionScheduleProductionRequestSegmentRequirementDescription.text =
str(man_order.name)
# <HierarchyScope />
productionScheduleProductionRequestSegmentRequirementHierarchyScope =
ElementTree.SubElement(productionScheduleProductionRequestSegmentRequirement,
"HierarchyScope")
productionScheduleProductionRequestSegmentRequirementHierarchyScope.text =
str(routing_obj.name)
# <EarliestStartTime />
productionScheduleProductionRequestSegmentRequirementEarliestStartTime =
ElementTree.SubElement(productionScheduleProductionRequestSegmentRequirement,
"EarliestStartTime")
productionScheduleProductionRequestSegmentRequirementEarliestStartTime.text =
str(man_order.date_planned)
# <LatestEndTime />
productionScheduleProductionRequestSegmentRequirementLatestEndTime =
ElementTree.SubElement(productionScheduleProductionRequestSegmentRequirement,
"LatestEndTime")
date_planned =
datetime.datetime.strptime(str(man_order.date_planned), ‘%Y-
%m-%d %H:%M:%S’)
date_planned_1 = date_planned + datetime.timedelta(days=1)
productionScheduleProductionRequestSegmentRequirementLatestEndTime.text =
str(date_planned_1)
# <Duration />
productionScheduleProductionRequestSegmentRequirementDuration =
ElementTree.SubElement(productionScheduleProductionRequestSegmentRequirement,
"Duration")
productionScheduleProductionRequestSegmentRequirementDuration.text =
str(man_order.hour_total)
# <ProductionParameter>
productionScheduleProductionRequestSegmentRequirementProductionParameter =
ElementTree.SubElement(productionScheduleProductionRequestSegmentRequirement,
"ProductionParameter")
# <ProductSegmentID />
productionScheduleProductionRequestSegmentRequirementProductionParameterProdu
ctSegmentID =
ElementTree.SubElement(productionScheduleProductionRequestSegmentRequirementP
roductionParameter, "ProductSegmentID")
# <ProcessSegmentID />
productionScheduleProductionRequestSegmentRequirementProductionParameterProce
ssSegmentID =
ElementTree.SubElement(productionScheduleProductionRequestSegmentRequirementP
roductionParameter, "ProcessSegmentID")
# <Parameter />
productionScheduleProductionRequestSegmentRequirementProductionParameterParam
eter =
118
Anexos

ElementTree.SubElement(productionScheduleProductionRequestSegmentRequirementP
roductionParameter, "Parameter")
# </ProductionParameter>

# <PersonnelRequirement>
productionScheduleProductionRequestSegmentRequirementPersonnelRequirement =
ElementTree.SubElement(productionScheduleProductionRequestSegmentRequirement,
"PersonnelRequirement")
# <PersonnelClassID />
productionScheduleProductionRequestSegmentRequirementPersonnelRequirementPers
onnelClassID =
ElementTree.SubElement(productionScheduleProductionRequestSegmentRequirementP
ersonnelRequirement, "PersonnelClassID")
# <PersonID />
productionScheduleProductionRequestSegmentRequirementPersonnelRequirementPers
onID =
ElementTree.SubElement(productionScheduleProductionRequestSegmentRequirementP
ersonnelRequirement, "PersonID")
# <Description />
productionScheduleProductionRequestSegmentRequirementPersonnelRequirementDesc
ription =
ElementTree.SubElement(productionScheduleProductionRequestSegmentRequirementP
ersonnelRequirement, "Description")
# <HierarchyScope />
productionScheduleProductionRequestSegmentRequirementPersonnelRequirementHier
archyScope =
ElementTree.SubElement(productionScheduleProductionRequestSegmentRequirementP
ersonnelRequirement, "HierarchyScope")
# <Quantity />
productionScheduleProductionRequestSegmentRequirementPersonnelRequirementQuan
tity =
ElementTree.SubElement(productionScheduleProductionRequestSegmentRequirementP
ersonnelRequirement, "Quantity")
# <PersonnelRequirementProperty>
productionScheduleProductionRequestSegmentRequirementPersonnelRequirementPers
onnelRequirementProperty =
ElementTree.SubElement(productionScheduleProductionRequestSegmentRequirementP
ersonnelRequirement, "PersonnelRequirementProperty")
# <ID />
productionScheduleProductionRequestSegmentRequirementPersonnelRequirementPers
onnelRequirementPropertyID =
ElementTree.SubElement(productionScheduleProductionRequestSegmentRequirementP
ersonnelRequirementPersonnelRequirementProperty, "ID")
# <Description />
productionScheduleProductionRequestSegmentRequirementPersonnelRequirementPers
onnelRequirementPropertyDescription =
ElementTree.SubElement(productionScheduleProductionRequestSegmentRequirementP
ersonnelRequirementPersonnelRequirementProperty, "Description")
# <Value />
productionScheduleProductionRequestSegmentRequirementPersonnelRequirementPers
onnelRequirementPropertyValue =
ElementTree.SubElement(productionScheduleProductionRequestSegmentRequirementP
ersonnelRequirementPersonnelRequirementProperty, "Value")
# <Quantity />
productionScheduleProductionRequestSegmentRequirementPersonnelRequirementPers
onnelRequirementPropertyQuantity =
ElementTree.SubElement(productionScheduleProductionRequestSegmentRequirementP
ersonnelRequirementPersonnelRequirementProperty, "Quantity")
# </PersonnelRequirementProperty>
Integración de sistemas ERP y MES mediante el estándar ANSI/ISA-95 119

#
<RequiredByRequestedSegmentResponse />
productionScheduleProductionRequestSegmentRequirementPersonnelRequirementRequ
iredByRequestedSegmentResponse =
ElementTree.SubElement(productionScheduleProductionRequestSegmentRequirementP
ersonnelRequirement, "RequiredByRequestedSegmentResponse")
# </PersonnelRequirement>

# <EquipmentRequirement>
productionScheduleProductionRequestSegmentRequirementEquipmentRequirement =
ElementTree.SubElement(productionScheduleProductionRequestSegmentRequirement,
"EquipmentRequirement")
# <EquipmentClassID />
productionScheduleProductionRequestSegmentRequirementEquipmentRequirementEqui
pmentClassID =
ElementTree.SubElement(productionScheduleProductionRequestSegmentRequirementE
quipmentRequirement, "EquipmentClassID")
# <EquipmentID />
productionScheduleProductionRequestSegmentRequirementEquipmentRequirementEqui
pmentID =
ElementTree.SubElement(productionScheduleProductionRequestSegmentRequirementE
quipmentRequirement, "EquipmentID")
# <Description />
productionScheduleProductionRequestSegmentRequirementEquipmentRequirementDesc
ription =
ElementTree.SubElement(productionScheduleProductionRequestSegmentRequirementE
quipmentRequirement, "Description")
# <HierarchyScope />
productionScheduleProductionRequestSegmentRequirementEquipmentRequirementHier
archyScope =
ElementTree.SubElement(productionScheduleProductionRequestSegmentRequirementE
quipmentRequirement, "HierarchyScope")
# <Quantity />
productionScheduleProductionRequestSegmentRequirementEquipmentRequirementQuan
tity =
ElementTree.SubElement(productionScheduleProductionRequestSegmentRequirementE
quipmentRequirement, "Quantity")
# <EquipmentRequirementProperty>
productionScheduleProductionRequestSegmentRequirementEquipmentRequirementEqui
pmentRequirementProperty =
ElementTree.SubElement(productionScheduleProductionRequestSegmentRequirementE
quipmentRequirement, "EquipmentRequirementProperty")
# <ID />
productionScheduleProductionRequestSegmentRequirementEquipmentRequirementEqui
pmentRequirementPropertyID =
ElementTree.SubElement(productionScheduleProductionRequestSegmentRequirementE
quipmentRequirementEquipmentRequirementProperty, "ID")
# <Description />
productionScheduleProductionRequestSegmentRequirementEquipmentRequirementEqui
pmentRequirementPropertyDescription =
ElementTree.SubElement(productionScheduleProductionRequestSegmentRequirementE
quipmentRequirementEquipmentRequirementProperty, "Description")
# <Value />
productionScheduleProductionRequestSegmentRequirementEquipmentRequirementEqui
pmentRequirementPropertyValue =
ElementTree.SubElement(productionScheduleProductionRequestSegmentRequirementE
quipmentRequirementEquipmentRequirementProperty, "Value")
# <Quantity />
120
Anexos

productionScheduleProductionRequestSegmentRequirementEquipmentRequirementEqui
pmentRequirementPropertyQuantity =
ElementTree.SubElement(productionScheduleProductionRequestSegmentRequirementE
quipmentRequirementEquipmentRequirementProperty, "Quantity")
# </EquipmentRequirementProperty>

#
<RequiredByRequestedSegmentResponse />
productionScheduleProductionRequestSegmentRequirementEquipmentRequirementRequ
iredByRequestedSegmentResponse =
ElementTree.SubElement(productionScheduleProductionRequestSegmentRequirementE
quipmentRequirement, "RequiredByRequestedSegmentResponse")
# </EquipmentRequirement>

# <PhysicalAssetRequirement>
productionScheduleProductionRequestSegmentRequirementPhysicalAssetRequirement
=
ElementTree.SubElement(productionScheduleProductionRequestSegmentRequirement,
"PhysicalAssetRequirement")
# <PhysicalAssetClassID />
productionScheduleProductionRequestSegmentRequirementPhysicalAssetRequirement
PhysicalAssetClassID =
ElementTree.SubElement(productionScheduleProductionRequestSegmentRequirementP
hysicalAssetRequirement, "PhysicalAssetClassID")
# <PhysicalAssetID />
productionScheduleProductionRequestSegmentRequirementPhysicalAssetRequirement
PhysicalAssetID =
ElementTree.SubElement(productionScheduleProductionRequestSegmentRequirementP
hysicalAssetRequirement, "PhysicalAssetID")
productionScheduleProductionRequestSegmentRequirementPhysicalAssetRequirement
PhysicalAssetID.text = str(routing_obj.id)
# <Description />
productionScheduleProductionRequestSegmentRequirementPhysicalAssetRequirement
Description =
ElementTree.SubElement(productionScheduleProductionRequestSegmentRequirementP
hysicalAssetRequirement, "Description")
productionScheduleProductionRequestSegmentRequirementPhysicalAssetRequirement
Description = str(routing_obj.name)
# <HierarchyScope />
productionScheduleProductionRequestSegmentRequirementPhysicalAssetRequirement
HierarchyScope =
ElementTree.SubElement(productionScheduleProductionRequestSegmentRequirementP
hysicalAssetRequirement, "HierarchyScope")

productionScheduleProductionRequestSegmentRequirementPhysicalAssetRequirement
HierarchyScope.text = str(routing_obj.code)
# <Quantity />
productionScheduleProductionRequestSegmentRequirementPhysicalAssetRequirement
Quantity =
ElementTree.SubElement(productionScheduleProductionRequestSegmentRequirementP
hysicalAssetRequirement, "Quantity")
productionScheduleProductionRequestSegmentRequirementPhysicalAssetRequirement
Quantity = "1"
#
<PhysicalAssetRequirementProperty>
productionScheduleProductionRequestSegmentRequirementPhysicalAssetRequirement
PhysicalAssetRequirementProperty =
ElementTree.SubElement(productionScheduleProductionRequestSegmentRequirementP
hysicalAssetRequirement, "PhysicalAssetRequirementProperty")
# <ID />
Integración de sistemas ERP y MES mediante el estándar ANSI/ISA-95 121

productionScheduleProductionRequestSegmentRequirementPhysicalAssetRequirement
PhysicalAssetRequirementPropertyID =
ElementTree.SubElement(productionScheduleProductionRequestSegmentRequirementP
hysicalAssetRequirementPhysicalAssetRequirementProperty, "ID")
productionScheduleProductionRequestSegmentRequirementPhysicalAssetRequirement
PhysicalAssetRequirementPropertyID.text = str(routing_obj.id)
# <Description />
productionScheduleProductionRequestSegmentRequirementPhysicalAssetRequirement
PhysicalAssetRequirementPropertyDescription =
ElementTree.SubElement(productionScheduleProductionRequestSegmentRequirementP
hysicalAssetRequirementPhysicalAssetRequirementProperty, "Description")
productionScheduleProductionRequestSegmentRequirementPhysicalAssetRequirement
PhysicalAssetRequirementPropertyDescription.text = str(routing_obj.name)
# <Value />
productionScheduleProductionRequestSegmentRequirementPhysicalAssetRequirement
PhysicalAssetRequirementPropertyValue =
ElementTree.SubElement(productionScheduleProductionRequestSegmentRequirementP
hysicalAssetRequirementPhysicalAssetRequirementProperty, "Value")
# <Quantity />
productionScheduleProductionRequestSegmentRequirementPhysicalAssetRequirement
PhysicalAssetRequirementPropertyQuantity =
ElementTree.SubElement(productionScheduleProductionRequestSegmentRequirementP
hysicalAssetRequirementPhysicalAssetRequirementProperty, "Quantity")
productionScheduleProductionRequestSegmentRequirementPhysicalAssetRequirement
PhysicalAssetRequirementPropertyQuantity.text = "1"
#
</PhysicalAssetRequirementProperty>

#
<RequiredByRequestedSegmentResponse />
productionScheduleProductionRequestSegmentRequirementPhysicalAssetRequirement
RequiredByRequestedSegmentResponse =
ElementTree.SubElement(productionScheduleProductionRequestSegmentRequirementP
hysicalAssetRequirement, "RequiredByRequestedSegmentResponse")
# </PhysicalAssetRequirement>

# <MaterialRequirement> PRODUCT
productionScheduleProductionRequestSegmentRequirementMaterialRequirement =
ElementTree.SubElement(productionScheduleProductionRequestSegmentRequirement,
"MaterialRequirement")
# <MaterialClassID />
productionScheduleProductionRequestSegmentRequirementMaterialRequirementMater
ialClassID =
ElementTree.SubElement(productionScheduleProductionRequestSegmentRequirementM
aterialRequirement, "MaterialClassID")
# <MaterialDefinitionID />
productionScheduleProductionRequestSegmentRequirementMaterialRequirementMater
ialDefinitionID =
ElementTree.SubElement(productionScheduleProductionRequestSegmentRequirementM
aterialRequirement, "MaterialDefinitionID")
# <MaterialLotID />
productionScheduleProductionRequestSegmentRequirementMaterialRequirementMater
ialLotID =
ElementTree.SubElement(productionScheduleProductionRequestSegmentRequirementM
aterialRequirement, "MaterialLotID")
# <MaterialSubLotID />
productionScheduleProductionRequestSegmentRequirementMaterialRequirementMater
ialSubLotID =
122
Anexos

ElementTree.SubElement(productionScheduleProductionRequestSegmentRequirementM
aterialRequirement, "MaterialSubLotID")
# <Description />
productionScheduleProductionRequestSegmentRequirementMaterialRequirementDescr
iption =
ElementTree.SubElement(productionScheduleProductionRequestSegmentRequirementM
aterialRequirement, "Description")

productionScheduleProductionRequestSegmentRequirementMaterialRequirementDescr
iption.text = str(product_obj.name_template)
# <HierarchyScope />

productionScheduleProductionRequestSegmentRequirementMaterialRequirementHiera
rchyScope =
ElementTree.SubElement(productionScheduleProductionRequestSegmentRequirementM
aterialRequirement, "HierarchyScope")
productionScheduleProductionRequestSegmentRequirementMaterialRequirementHiera
rchyScope.text = str(routing_obj.name)
# <MaterialUse />
productionScheduleProductionRequestSegmentRequirementMaterialRequirementMater
ialUse =
ElementTree.SubElement(productionScheduleProductionRequestSegmentRequirementM
aterialRequirement, "MaterialUse")
productionScheduleProductionRequestSegmentRequirementMaterialRequirementMater
ialUse.text = "Product"
# <Quantity />
productionScheduleProductionRequestSegmentRequirementMaterialRequirementQuant
ity =
ElementTree.SubElement(productionScheduleProductionRequestSegmentRequirementM
aterialRequirement, "Quantity")
productionScheduleProductionRequestSegmentRequirementMaterialRequirementQuant
ity.text = str(man_order.product_qty)
# <AssemblyRequirement />
productionScheduleProductionRequestSegmentRequirementMaterialRequirementAssem
blyRequirement =
ElementTree.SubElement(productionScheduleProductionRequestSegmentRequirementM
aterialRequirement, "AssemblyRequirement")
# <AssemblyType />
productionScheduleProductionRequestSegmentRequirementMaterialRequirementAssem
blyType =
ElementTree.SubElement(productionScheduleProductionRequestSegmentRequirementM
aterialRequirement, "AssemblyType")
# <AssemblyRelationship />
productionScheduleProductionRequestSegmentRequirementMaterialRequirementAssem
blyRelationship =
ElementTree.SubElement(productionScheduleProductionRequestSegmentRequirementM
aterialRequirement, "AssemblyRelationship")
# <MaterialRequirementProperty>
productionScheduleProductionRequestSegmentRequirementMaterialRequirementMater
ialRequirementProperty =
ElementTree.SubElement(productionScheduleProductionRequestSegmentRequirementM
aterialRequirement, "MaterialRequirementProperty")
# <ID />
productionScheduleProductionRequestSegmentRequirementMaterialRequirementMater
ialRequirementPropertyID =
ElementTree.SubElement(productionScheduleProductionRequestSegmentRequirementM
aterialRequirementMaterialRequirementProperty, "ID")
productionScheduleProductionRequestSegmentRequirementMaterialRequirementMater
ialRequirementPropertyID.text = str(product_obj.id)
# <Description />
Integración de sistemas ERP y MES mediante el estándar ANSI/ISA-95 123

productionScheduleProductionRequestSegmentRequirementMaterialRequirementMater
ialRequirementPropertyDescription =
ElementTree.SubElement(productionScheduleProductionRequestSegmentRequirementM
aterialRequirementMaterialRequirementProperty, "Description")
productionScheduleProductionRequestSegmentRequirementMaterialRequirementMater
ialRequirementPropertyDescription.text = str(product_obj.name_template)
# <Value />
productionScheduleProductionRequestSegmentRequirementMaterialRequirementMater
ialRequirementPropertyValue =
ElementTree.SubElement(productionScheduleProductionRequestSegmentRequirementM
aterialRequirementMaterialRequirementProperty, "Value")
productionScheduleProductionRequestSegmentRequirementMaterialRequirementMater
ialRequirementPropertyValue.text = "Product"
# <Quantity />
productionScheduleProductionRequestSegmentRequirementMaterialRequirementMater
ialRequirementPropertyQuantity =
ElementTree.SubElement(productionScheduleProductionRequestSegmentRequirementM
aterialRequirementMaterialRequirementProperty, "Quantity")
productionScheduleProductionRequestSegmentRequirementMaterialRequirementMater
ialRequirementPropertyQuantity.text = str(man_order.product_qty)
# </MaterialRequirementProperty>

#
<RequiredByRequestedSegmentResponse />
productionScheduleProductionRequestSegmentRequirementMaterialRequirementRequi
redByRequestedSegmentResponse =
ElementTree.SubElement(productionScheduleProductionRequestSegmentRequirementM
aterialRequirement, "RequiredByRequestedSegmentResponse")
# </MaterialRequirement>

for bom_line in bom_obj.bom_line_ids:


# <MaterialRequirement> BOM
productionScheduleProductionRequestSegmentRequirementMaterialRequirement =
ElementTree.SubElement(productionScheduleProductionRequestSegmentRequirement,
"MaterialRequirement")
# <MaterialClassID />
productionScheduleProductionRequestSegmentRequirementMaterialRequirementMater
ialClassID =
ElementTree.SubElement(productionScheduleProductionRequestSegmentRequirementM
aterialRequirement, "MaterialClassID")
# <MaterialDefinitionID />
productionScheduleProductionRequestSegmentRequirementMaterialRequirementMater
ialDefinitionID =
ElementTree.SubElement(productionScheduleProductionRequestSegmentRequirementM
aterialRequirement, "MaterialDefinitionID")
# <MaterialLotID />
productionScheduleProductionRequestSegmentRequirementMaterialRequirementMater
ialLotID =
ElementTree.SubElement(productionScheduleProductionRequestSegmentRequirementM
aterialRequirement, "MaterialLotID")
# <MaterialSubLotID />
productionScheduleProductionRequestSegmentRequirementMaterialRequirementMater
ialSubLotID =
ElementTree.SubElement(productionScheduleProductionRequestSegmentRequirementM
aterialRequirement, "MaterialSubLotID")
# <Description />
productionScheduleProductionRequestSegmentRequirementMaterialRequirementDescr
iption =
124
Anexos

ElementTree.SubElement(productionScheduleProductionRequestSegmentRequirementM
aterialRequirement, "Description")
productionScheduleProductionRequestSegmentRequirementMaterialRequirementDescr
iption.text = str(bom_line.product_id.name_template)
# <HierarchyScope />
productionScheduleProductionRequestSegmentRequirementMaterialRequirementHiera
rchyScope =
ElementTree.SubElement(productionScheduleProductionRequestSegmentRequirementM
aterialRequirement, "HierarchyScope")
productionScheduleProductionRequestSegmentRequirementMaterialRequirementHiera
rchyScope.text = str(routing_obj.name)
# <MaterialUse />
productionScheduleProductionRequestSegmentRequirementMaterialRequirementMater
ialUse =
ElementTree.SubElement(productionScheduleProductionRequestSegmentRequirementM
aterialRequirement, "MaterialUse")
productionScheduleProductionRequestSegmentRequirementMaterialRequirementMater
ialUse.text = "Consumed"
# <Quantity />
productionScheduleProductionRequestSegmentRequirementMaterialRequirementQuant
ity =
ElementTree.SubElement(productionScheduleProductionRequestSegmentRequirementM
aterialRequirement, "Quantity")
productionScheduleProductionRequestSegmentRequirementMaterialRequirementQuant
ity.text = str(bom_line.product_qty)
# <AssemblyRequirement />
productionScheduleProductionRequestSegmentRequirementMaterialRequirementAssem
blyRequirement =
ElementTree.SubElement(productionScheduleProductionRequestSegmentRequirementM
aterialRequirement, "AssemblyRequirement")
# <AssemblyType />
productionScheduleProductionRequestSegmentRequirementMaterialRequirementAssem
blyType =
ElementTree.SubElement(productionScheduleProductionRequestSegmentRequirementM
aterialRequirement, "AssemblyType")
# <AssemblyRelationship />
productionScheduleProductionRequestSegmentRequirementMaterialRequirementAssem
blyRelationship =
ElementTree.SubElement(productionScheduleProductionRequestSegmentRequirementM
aterialRequirement, "AssemblyRelationship")
#
<MaterialRequirementProperty>
productionScheduleProductionRequestSegmentRequirementMaterialRequirementMater
ialRequirementProperty =
ElementTree.SubElement(productionScheduleProductionRequestSegmentRequirementM
aterialRequirement, "MaterialRequirementProperty")
# <ID />
productionScheduleProductionRequestSegmentRequirementMaterialRequirementMater
ialRequirementPropertyID =
ElementTree.SubElement(productionScheduleProductionRequestSegmentRequirementM
aterialRequirementMaterialRequirementProperty, "ID")
productionScheduleProductionRequestSegmentRequirementMaterialRequirementMater
ialRequirementPropertyID.text = str(bom_line.product_id.id)
# <Description />
productionScheduleProductionRequestSegmentRequirementMaterialRequirementMater
ialRequirementPropertyDescription =
ElementTree.SubElement(productionScheduleProductionRequestSegmentRequirementM
aterialRequirementMaterialRequirementProperty, "Description")
productionScheduleProductionRequestSegmentRequirementMaterialRequirementMater
ialRequirementPropertyDescription.text =
str(bom_line.product_id.name_template)
Integración de sistemas ERP y MES mediante el estándar ANSI/ISA-95 125

# <Value />
productionScheduleProductionRequestSegmentRequirementMaterialRequirementMater
ialRequirementPropertyValue =
ElementTree.SubElement(productionScheduleProductionRequestSegmentRequirementM
aterialRequirementMaterialRequirementProperty, "Value")
productionScheduleProductionRequestSegmentRequirementMaterialRequirementMater
ialRequirementPropertyValue.text = "Raw Material"
# <Quantity />
productionScheduleProductionRequestSegmentRequirementMaterialRequirementMater
ialRequirementPropertyQuantity =
ElementTree.SubElement(productionScheduleProductionRequestSegmentRequirementM
aterialRequirementMaterialRequirementProperty, "Quantity")
productionScheduleProductionRequestSegmentRequirementMaterialRequirementMater
ialRequirementPropertyQuantity.text = str(bom_line.product_qty)
#
</MaterialRequirementProperty>

#
<RequiredByRequestedSegmentResponse />
productionScheduleProductionRequestSegmentRequirementMaterialRequirementRequi
redByRequestedSegmentResponse =
ElementTree.SubElement(productionScheduleProductionRequestSegmentRequirementM
aterialRequirement, "RequiredByRequestedSegmentResponse")
# </MaterialRequirement>

# <RequiredByRequestedSegmentResponse />
productionScheduleProductionRequestSegmentRequirementRequiredByRequestedSegme
ntResponse =
ElementTree.SubElement(productionScheduleProductionRequestSegmentRequirement,
"RequiredByRequestedSegmentResponse")
# <SegmentState />
productionScheduleProductionRequestSegmentRequirementSegmentState =
ElementTree.SubElement(productionScheduleProductionRequestSegmentRequirement,
"SegmentState")
# </SegmentRequirement>

# <SegmentResponse />
productionScheduleProductionRequestSegmentResponse =
ElementTree.SubElement(productionScheduleProductionRequest,
"SegmentResponse")
productionScheduleProductionRequestSegmentResponse.text =
"False"
# <RequestState />
productionScheduleProductionRequestRequestState =
ElementTree.SubElement(productionScheduleProductionRequest,
"RequestState")
# </ProductionRequest>

# <ScheduleState />
productionScheduleScheduleState =
ElementTree.SubElement(productionSchedule, "ScheduleState")
# </ProductionSchedule>

outFile = open(‘B2MML\B2MML_ProductionSchedule_’ +
str(man_order.id) + ‘.xml’, ‘w’)
b2mml = ElementTree.ElementTree(productionSchedule)
b2mml.write(outFile)

def action_send_MES(self, cr, uid, ids, context=None):


126
Anexos

res = self.write(cr, uid, ids, {‘state’: ‘send_MES’},


context=context)
self.generateB2MML(cr, uid, ids, context)
#Guardar fichero B2MML en servidor FTP
man_order = self.browse(cr, uid, ids, context=context)
b2mmlFile = ‘C:\Program Files (x86)\Odoo 9.0-
20160204\B2MML\B2MML_ProductionSchedule_’ + str(man_order.id)
+ ‘.xml’
#Llamada al WS del Middleware
url = ‘http://localhost:8080/MiddlewareWS/MiddlewareWS?WSDL’
client = Client(url)
result = client.service.sendToMES(b2mmlFile)
if result == "0":
res = self.write(cr, uid, ids, {‘state’:
‘in_production’}, context=context)
else:
res = self.write(cr, uid, ids, {‘state’: ‘cancel’},
context=context)
return res
Integración de sistemas ERP y MES mediante el estándar ANSI/ISA-95 127

D. Anexo D: Código del Servicio Web del MES PROMIA


B2MMLWebService.java
/*
* To change this license header, choose License Headers in Project
Properties.
* To change this template file, choose Tools | Templates
* and open the template in the editor.
*/
package org.promia.service;

import java.io.IOException;
import javax.jws.WebService;
import javax.jws.WebMethod;
import javax.jws.WebParam;
import javax.ejb.Stateless;
import org.promia.b2mml.ReadB2MMLFile;

/**
*
* @author rojasa06
*/
@WebService(serviceName = "B2MMLWebService")
@Stateless()
public class B2MMLWebService {

/**
* Web service operation
*/
@WebMethod(operationName = "addManufacturingOrder")
public String addManufacturingOrder(@WebParam(name = "B2MMLPath") String
B2MMLPath) throws IOException {
String response = "0";
ReadB2MMLFile xml = new ReadB2MMLFile(B2MMLPath);
if (xml.getDoc() != null) {
if (xml.parse2Database()) {
response = "0";
} else {
response = "-1";
}
} else {
response = "-1";
}
return response;
}
}
128
Anexos

E. Anexo E: Fichero B2MML generado por el MES PROMIA


<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<ProductionSchedule>
<ID>66</ID>
<Description>Manufacturing Order</Description>
<PublishedDate>2016-11-21 13:11:17</PublishedDate>
<HierarchyScope>Site</HierarchyScope>
<EndTime>2016-11-25 13:30:00</EndTime>
<EquipmentElementLevel>Site</EquipmentElementLevel>
<ProductionRequest>
<ID>66</ID>
<Description>MO00073</Description>
<ProductProductionRuleIDGroup/>
<HierarchyScope>Site</HierarchyScope>
<StartTime>2016-11-21 12:06:59</StartTime>
<EndTime>2016-11-25 13:30:00</EndTime>
<Priority>1</Priority>
<SegmentRequirement>
<ID>66</ID>
<ProductSegmentID/>
<ProcessSegmentID/>
<Description>MO00073</Description>
<HierarchyScope>False</HierarchyScope>
<EarliestStartTime>2016-11-21
12:06:59</EarliestStartTime>
<LatestEndTime/>
<Duration/>
<ProductionParameter>
<ProductSegmentID/>
<ProcessSegmentID/>
<Parameter/>
</ProductionParameter>
<PersonnelRequirement>
<PersonnelClassID/>
<PersonID/>
<Description/>
<HierarchyScope/>
<Quantity/>
<PersonnelRequirementProperty>
<ID/>
<Description/>
<Value/>
<Quantity/>
</PersonnelRequirementProperty>
<RequiredByRequestedSegmentResponse/>
</PersonnelRequirement>
<EquipmentRequirement>
<EquipmentClassID/>
<EquipmentID/>
<Description/>
<HierarchyScope/>
<Quantity/>
<EquipmentRequirementProperty>
<ID/>
<Description/>
<Value/>
<Quantity/>
</EquipmentRequirementProperty>
<RequiredByRequestedSegmentResponse/>
Integración de sistemas ERP y MES mediante el estándar ANSI/ISA-95 129

</EquipmentRequirement>
<PhysicalAssetRequirement>
<PhysicalAssetClassID/>
<PhysicalAssetID>False</PhysicalAssetID>
<Description/>
<HierarchyScope>False</HierarchyScope>
<Quantity/>
<PhysicalAssetRequirementProperty>
<ID>False</ID>
<Description>False</Description>
<Value/>
<Quantity>1</Quantity>
</PhysicalAssetRequirementProperty>
<RequiredByRequestedSegmentResponse/>
</PhysicalAssetRequirement>
<MaterialRequirement>
<MaterialClassID/>
<MaterialDefinitionID/>
<MaterialLotID/>
<MaterialSubLotID/>
<Description>PC Sobremesa</Description>
<HierarchyScope>False</HierarchyScope>
<MaterialUse>Product</MaterialUse>
<Quantity>1.0</Quantity>
<AssemblyRequirement/>
<AssemblyType/>
<AssemblyRelationship/>
<MaterialRequirementProperty>
<ID>1</ID>
<Description>PC Sobremesa</Description>
<Value>Product</Value>
<Quantity>1.0</Quantity>
</MaterialRequirementProperty>
<RequiredByRequestedSegmentResponse/>
</MaterialRequirement>
<RequiredByRequestedSegmentResponse/>
<SegmentState/>
</SegmentRequirement>
<SegmentResponse>True</SegmentResponse>
<RequestState/>
</ProductionRequest>
</ProductionSchedule>

Você também pode gostar