Memoria Gonzalo Losada

Universidad Católica del Uruguay
Facultad de Ingeniería y Tecnologías
Construir una interfaz que facilite la

integración de la gestión con
sistemas de inventarios
Lic. Gonzalo R. Losada Vasilisín
Ing. Daniel Paolillo

Orientador
Memoria de Grado
Montevideo, 26 de Octubre de 2009

Resumen
Resumen
Éste documento presenta una introducción al problema que se estudió, y más adelante,
una definición más detallada; el objetivo que llevó a realizar ésta investigación y la
determinación del alcance que ésta tiene.
Se presenta también un resumen del estado del arte de las distintas áreas de estudio que se
deben conocer para la comprensión de este trabajo, la metodología que se siguió en el
desarrollo del mismo, y la norma que permitirá la validación de los objetivos planteados.
Finalmente, luego de ésta parte introductoria, se presenta la descripción de la solución

propuesta y las conclusiones a las que se llegaron luego de evaluar los resultados del
trabajo.
Abstract
This document presents an introduction to the issue being studied, and later, a more
detailed definition, the objective that led to this research and the scope definition that it
has.
It also presents a summary of the state of the art of the different areas of study that should
be known for understanding this work, the methodology followed in its development and
the standard that was defined to aid in the validation of the stated objectives.
Finally, after this introduction, we present the description of the solution implemented
and the conclusions that were reached after evaluating the results of this work.
Universidad Católica del Uruguay. Facultad de Ingeniería y Tecnologías. 2

Tabla de Contenidos
Tabla de Contenidos
RESUMEN ............................................................................................................................... 2
ABSTRACT ............................................................................................................................... 2
TABLA DE CONTENIDOS ............................................................................................................. 3
TABLA DE IMÁGENES ................................................................................................................. 5
INTRODUCCIÓN ........................................................................................................................ 6
DEFINICIÓN DEL PROBLEMA ........................................................................................................ 8
OBJETIVO ............................................................................................................................... 9
ALCANCE .............................................................................................................................. 10
RESTRICCIONES AMBIENTALES Y OPERATIVAS............................................................................... 11
CONCLUSIONES DE LA RESTRICCIONES AMBIENTALES Y OPERATIVAS ............................................. 11
MOTIVACIÓN ........................................................................................................................ 13
ESTADO DEL ARTE .................................................................................................................. 14
GESTIÓN DE INVENTARIOS .................................................................................................... 14

SISTEMAS ERP .................................................................................................................. 19
INTEGRACIÓN DE APLICACIONES ............................................................................................ 20
Tipos de Integración de Aplicaciones ........................................................................ 21
SOA ............................................................................................................................ 22
Definición .................................................................................................................. 23
METODOLOGÍA ...................................................................................................................... 24
DEFINICIÓN DE LA NORMA ........................................................................................................ 25
DEFINICIÓN Y DESARROLLO DE LA INTERFAZ ............................................................................. 25

PROTOTIPO PARA PROBAR LA INTERFAZ ................................................................................... 25
ARQUITECTURA DE LA SOLUCIÓN ........................................................................................... 25

Tabla de Contenidos
DESCRIPCIÓN DE LA SOLUCIÓN .................................................................................................. 27
INTRODUCCIÓN .................................................................................................................. 27
ARQUITECTURA .................................................................................................................. 28
IMPLEMENTACIÓN .............................................................................................................. 29
Descripción General de la Aplicación ........................................................................ 29
Modelos de Inventario .............................................................................................. 30
Sistemas de Inventario .............................................................................................. 32
Parámetros de un Modelo en un Sistema ................................................................. 34
INTERFAZ PÚBLICA .............................................................................................................. 36
awsgetmodelosinventario......................................................................................... 36
awsgetsistemasinventariobymodeloinventario ........................................................ 37
awsgetparametrosbymodelosistema ....................................................................... 38
awsejecutacalculoinventario .................................................................................... 39
Funcionamiento ........................................................................................................ 41
SISTEMA DE INVENTARIO PROTOTIPO ..................................................................................... 42
awscalculateeoq ....................................................................................................... 43
IMPACTO EN ERP ............................................................................................................... 44
CONCLUSIONES ...................................................................................................................... 46
BIBLIOGRAFÍA ........................................................................................................................ 48

Tabla de Imágenes
Tabla de Imágenes
Modelo básico de inventario ............................................................................................................. 17
Arquitectura de la aplicación ............................................................................................................. 28
Interfaz – Descripción General ........................................................................................................... 29
Interfaz – Modelos de Inventario ....................................................................................................... 30
Interfaz – Visualizar Modelo de Inventario ......................................................................................... 30
Interfaz – Edición de Modelo de Inventario ........................................................................................ 31
Interfaz – Sistemas de Inventario....................................................................................................... 32
Interfaz – Visualizar Sistema de Inventario ......................................................................................... 32
Interfaz – Edición de Sistema de Inventario ........................................................................................ 33
Interfaz – Parámetros de un Modelo en un Sistema............................................................................ 34
Interfaz – Visualizar Parámetros de un Modelo en un Sistema ............................................................ 34
Interfaz – Edición de Parámetros de un Modelo en un Sistema ........................................................... 35
Flujo de la Aplicación ........................................................................................................................ 42
K2B – Datos de Reorden por Unidad Organizacional, Centro de Almacenaje, Producto ........................ 44
K2B – Cálculo de Reorden para un Producto (utilizando la extensión para Cálculo a través de un Sistema
Externo) .................................................................................................................................. 45

Introducción
Introducción
La investigación de operaciones es una ciencia que se remonta muchos años atrás, pero
que se desarrolla mayoritariamente durante y después de la revolución industrial. Se suele
decir ([ACK84], Introducción) que el término Investigación de Operaciones se utilizó por
primera vez en 1939.
La investigación de operaciones (IO) aspira a determinar el mejor curso de

acción (óptimo) de un problema de decisión con la restricción de recursos
limitados. El término investigación de operaciones muy a menudo está asociado
casi en exclusiva con la aplicación de técnicas matemáticas, para representar por
medio de un modelo y analizar problemas de decisión.
Arte y Ciencia de la Investigación de

Operaciones [TAH95], Capitulo 1
Con la popularización de los sistemas de cómputo, estos han tomado gran participación
en el apoyo a esta ciencia, y se han desarrollado varias técnicas para sustentar los
modelos teóricos y manuales que ésta describe. Se han desarrollado sistemas
informáticos, que apoyan al investigador de operaciones a resolver los problemas que se
le presentan.
Otra área donde los sistemas informáticos han hecho su aporte, es en la de los sistemas de
planificación de recursos empresariales (ERP por sus siglas en inglés, Enterprise
Resource Planning). Estos son sistemas de gestión de información, que integran,
formalizan y automatizan algunas de las actividades operativas o productivas de una
empresa, y suelen estar compuestos de varios módulos, que abarcan distintas partes del
proceso de la misma. Al igual que la investigación operativa, estos sistemas buscan la
optimización de los procesos empresariales, manteniendo una interconexión entre las
distintas partes de la empresa.

Introducción
En este trabajo, nos vamos a centrar puntualmente en la parte de gestión de inventarios de

la investigación operativa, y allanar el camino para que las técnicas de esta ciencia
puedan interconectarse de manera transparente, con los módulos que estén relacionados a
ella en un sistema ERP.

Definición del problema
Definición del problema

Un inventario consiste de recursos utilizables, pero que están ociosos. Estos
recursos pueden ser de cualquier tipo; por ejemplo: hombres, materiales,
máquinas o dinero. Cuando dicho recurso es material, o artículos en cualquier
etapa de su acabado, el inventario generalmente se menciona como “existencias
en almacén”.
Existe un problema de inventario si el volumen de recursos está sujeto a control y

si hay, cuando menos, un costo que disminuya al aumentar el inventario.
Naturaleza de los problemas de inventario

[ACK84], Capitulo 7
Un sistema ERP, tiene entre sus componentes, uno que se encarga de la gestión de
inventarios. Este componente maneja la información de los inventarios de la empresa,
controlando la logística de almacenamiento, entrada y salida del mismo, y todas las
operaciones internas para el correcto funcionamiento del área. A este componente, le
llegan las solicitudes de otros componentes del ERP, para abastecer de inventario a la
empresa (los inventarios salen del almacenamiento y pasan a utilizarse) y también los
avisos de entradas de nuevos inventarios para almacenar. En general, estos componentes
tienen implementados métodos simples para reabastecerse de un cierto inventario, pero
no cuentan con las técnicas avanzadas que define la investigación operativa, para tomar
determinaciones sobre cuánto y cuándo debe reabastecerse.
Por otro lado, los sistemas específicos de gestión de inventarios, que se basan en las
técnicas de investigación operativa, suelen ser independientes de los sistemas ERP.
Esto genera, que los sistemas se encuentren disjuntos, y presenta problemas tanto para
integrarlos, como para obtener informes consolidados, así como también presenta
problemas de duplicación de información.

Objetivo
Objetivo
El objetivo de este trabajo es construir una interfaz para facilitar la integración de un
sistema de gestión de inventarios, con los módulos correspondientes de un ERP. Esta
integración, permite al sistema de gestión de inventarios, obtener desde el ERP la
información de los inventarios a gestionar, con los datos que sean pertinentes para
realizar su función (p. ej.: la demanda; los costos de abastecimiento o mantenimiento,
etc.) y retorna la cantidad y el momento en que deberían realizarse dichos
reabastecimientos a futuro, de forma de optimizar costos.
Finalmente, realizar un prototipo para poner en práctica la interfaz, interconectando un

sistema ERP con un sistema de inventarios a través de la misma.

Alcance
Alcance
La teoría de gestión de inventarios, presenta varios modelos que representan distintas
variables que deben ser tenidas en cuenta para distintos tipos de inventarios. En este
trabajo, nos enfocamos en el modelo más simple de gestión de inventarios, en el cual se
asume una demanda lineal, y reposición instantánea. [Ack84] se refiere a este modelo de
la siguiente manera:
Las suposiciones determinísticas (es decir, conocimiento perfecto de los valores

de los parámetros) que se utilizan en esta formulación son una
sobresimplificación tosca de la mayoría de las situaciones reales. Sin embargo,
dicha formulación se utiliza ampliamente con éxito considerable. En realidad,
todos los modelos de situaciones de inventario son representaciones aproximadas
de la realidad, y aunque se pueden encontrar fórmulas más elaboradas que no
están expuestas inmediatamente a la crítica, aumentar la complejidad puede
encubrir errores y causar una precisión ficticia que siempre estará presente.
El problema general determinístico para

un articulo y un nivel [ACK84], Capitulo 7
En otras palabras, este modelo toma ciertos supuestos que podrían llegar a ser demasiado
generalistas, pero en la gran mayoría de los casos son o bien irrelevantes o no afectan
sensiblemente la precisión. Es sabido que para situaciones particulares, estas variables
toman una importancia mucho mayor, pero este tipo de casos quedarán fuera del alcance
de este trabajo.

Restricciones Ambientales y Operativas

En el estudio que se ha realizado para esta investigación, se han detectado las siguientes
restricciones.
Se trabajó con el modelo de inventario EOQ (Lote Económico), construyendo una

interfaz que permite la interacción entre los sistemas de gestión y los sistemas de
inventarios. Se tomaron en cuenta las características de este modelo para construir la
interfaz propuesta. No se incluyó dentro del estudio de este trabajo las características de
los restantes modelos de inventario (Protección de Stock, Producción, Demanda
Aleatoria, Demanda dada por una función de Probabilidad, Perdidas Por Penuria, etc.).
No se tiene acceso a todos los sistemas ERP que se manejan en mercado para poder
realizar pruebas de la interfaz directamente con todos ellos. Se construyó la interfaz y se
realizaron las pruebas interactuando con los sistemas a los que se obtuvo acceso.
Finalmente, las pruebas de la interfaz se realizaron utilizando datos de prueba, tratando de

abarcar distintas situaciones teóricas. Estos datos no son reflejo de una situación real,
dado que no se llevó a cabo un relevamiento de datos la gestión de inventarios en
diferentes empresas.
Conclusiones de la Restricciones Ambientales y Operativas
No se encontraron grandes restricciones a nivel ambiental, pero a nivel operativo existen

dos restricciones. Una concerniente a los tiempos con los que se cuenta para realizar esta
investigación, que limitan el alcance teórico de la misma. La otra, concerniente a la
disponibilidad de acceso que se pudo obtener sobre los sistemas ERP que estén en el
mercado, a fin de realizar las pruebas funcionales de la interfaz.
La primera restricción, si bien limitó el alcance del estudio lo hizo solamente en

amplitud, limitando la variedad de modelos a estudiar, no invalida los datos que se
obtengan para el modelo a estudiar. Por la teoría de gestión de inventarios, hemos visto
que este modelo, al ser el más utilizado, es un buen ejemplo para validar la interacción
entre los dos tipos de sistemas que estamos analizando.

Con respecto a la segunda restricción, si bien no se pudo realizar pruebas con todos los
ERPs del mercado, sí se tomaron en cuenta las formas de integración de cada uno ellos,
para llegar a un resultado válido aún haciendo pruebas de integración limitadas.

Motivación
Motivación
Habiendo participado de varios equipos de implantación de sistemas de información de
gestión empresarial, se ha notado la necesidad de poder integrar distintos módulos, de
distintos proveedores, de la manera más simple posible. Esto nos lleva a creer que es
necesario contar en cada uno de estos módulos con el mayor nivel de independencia
posible, sin que tomen por hecho ninguna realidad de los módulos con los que
interactúen, y que sean lo suficientemente flexibles para integrarse fácilmente con el
resto.
Dentro del área de gestión de inventarios, se cuenta en el mercado con varias opciones
para resolver esta problemática, pero no están enfocadas a ser fácilmente integrables con
los sistemas de información de gestión, por lo que notamos interesante tratar de aportar lo
que esta investigación produzca a minimizar esta problemática.

Estado del Arte
Estado del Arte
Gestión de Inventarios
Los problemas de inventario tienen como objetivo minimizar los costos, y se manejan a
través de ciertas variables. Algunas de estas, son controlables, y otras no, son dadas. De
[Ack84] podemos ver esto en detalle:
Normalmente, el objetivo es minimizar el costo total (real o esperado). Sin

embargo, si el inventario afecta la demanda (el volumen solicitado por los
clientes o usuarios), el objetivo puede ser maximizar las utilidades (reales o
esperadas).
Las variables que se pueden controlar, separadamente o en combinación, son las

siguientes:
1. La cantidad adquirida (por compra, producción o algún otro medio); o

sea, cuánto. Esto se puede fijar para cada tipo de recursos en forma
separada o para todos colectivamente; por ejemplo, la compra o el nivel
de producción, o ambos. Las decisiones acerca del número de puntos de
almacenamiento también afecta al volumen de existencias.
2. La frecuencia o tiempo de abastecimiento; es decir que tan a menudo o

cuándo.
En los problemas de inventario, las variables no controlables se dividen en

variables de costo y otras. Las variables principales de cada tipo son las
siguientes:
Costos de mantenimiento de inventarios: costos que se incrementan en

proporción directa al crecimiento del inventario y al tiempo que van a
permanecer almacenados los artículos.
Costo de capital invertido. Éste es un cargo que se refiere al interés y a menudo

necesita una investigación cuidadosa…

Estado del Arte
Costos de mantenimiento del archivo y cargos administrativos. Las existencias

son poco útiles, a menos que sepamos si el articulo requerido está o no en ellas.
Otros componentes del costo de mantenimiento del inventario son:
a) Costo de manejo …
b) Costos de almacenamiento …
c) Seguros e impuestos …
d) Costos de depreciación, deterioro y obsolescencia …
Todos estos costos requieren investigación, pero con la posible excepción de los
artículos usados, las drogas y los alimentos, con vida limitada, el costo total de
mantenimiento del inventario varía de 1 a 2 por ciento sobre el capital invertido
por mes. Sin embargo, el costo de almacenamiento, puede depender del volumen
de espacio existente y no del que se esté usando; de aquí que puede ser constante.
Costos de déficit o multas: Costos que surgen cuando algún artículo que se
demanda no se tiene en existencia.
Los costos de déficit se presentan en una de dos formas. La primera supone que
los costos son proporcionales tanto al déficit, como al tiempo que éste dure. Esto
es adecuado cuando el déficit se puede satisfacer no surtiendo los pedidos de
inmediato, pero sí antes de la fecha requerida por el cliente y de esta manera no
dar como resultado una pérdida de demanda. Representa la pérdida del buen
crédito o el costo del equipo ocioso. La segunda representación implica un costo
fijo cada vez que ocurre un déficit. Este costo cubre cuando menos la utilidad
perdida por pedido y puede incluir un componente para cubrir las pérdidas de
crédito.
Costos debidos a cambios en la tasa de producción: Incluyen costos de arranque

que resultan de cambiar la tasa de producción desde cero a un volumen positivo.
En el caso de una compra, implican los costos fijos administrativos de colocar un
pedido.

Estado del Arte
Precios de compra o costos de producción directos: El costo unitario por artículo

comprado puede depender de la cantidad que se compre debido a “precios
quebrados” o a “descuentos por volumen”.
Demanda: El número de artículos que se requieren por pedido. Nótese que esto
no es necesariamente la cantidad vendida, debido a que parte de la demanda
puede no satisfacerse por déficit o demoras. En efecto sería la cantidad que se
vendería si todo lo que se necesitara estuviera disponible.
Tiempo de reorden: El tiempo que ocurre entre la colocación del pedido y la

llegada del artículo al almacén. Si este es conocido y no es igual a cero y se
conoce la demanda, todo lo que se necesita hacer, es pedir con una anticipación
igual al tiempo de reorden.
Cantidad entregada: Si se pide una cantidad q para compra o producción, la

cantidad entregada puede varia alrededor de q con una función de densidad de
probabilidad conocida.

[ACK84], Capitulo 7
La estructura básica de un sistema de inventario, es una ecuación que relaciona las

existencias de un artículo en cierto momento en el tiempo, con las existencias del mismo
artículo, en otro momento de tiempo posterior. La ecuación, sería similar a la siguiente:
It’ = It + S – D
Es decir, que el inventario en un momento t’ lo podemos descomponer en el inventario

que había en un momento t (anterior), más la cantidad que se haya comprado (o
producido), menos la cantidad que se haya usado (o consumido, vendido, etc.; la
demanda). Esta demanda, podría llegar a ser mayor a la oferta (It + S), lo que nos llevaría
a evaluar algunas situaciones:
1. Si esta demanda permite surtirse apenas se consiga el inventario, entonces

simplemente tomamos estos momentos como valores negativos de inventario.

Estado del Arte
2. Si por el contrario, esta demandad extra (la que sobrepasa la oferta) se pierde (o se
satisface con otro método) entonces el inventario durante este tiempo es 0 y no
entra en el cálculo.
D2
It It’
S
t
D1
D = D1 + D2
t t’
Modelo básico de inventario
En la mayoría de los problemas de inventario, lo que se puede controlar es cuándo y

cuánto se agrega al mismo (S). Si bien es posible controlar alguna otra de las variables,
nos referiremos solamente a los modelos que controlan estas dos.
Existen muchos modelos de inventarios para realizar, y si bien cada uno persigue resolver
un objetivo particular, todos nacen de la siguiente necesidad:
Los modelos son representaciones de la realidad. Si fuesen tan complejos y

difíciles de controlar como la realidad, no habría ninguna ventaja en utilizarlos.

[ACK84], Capitulo 7
La abstracción de la realidad, en un modelo, lleva a identificar cuales variables

intervienen en el mismo, y reducir el problema para poder abordarlo, eliminando aquellas
que no sean tan significativas:

Estado del Arte
Aunque una situación real puede implicar un número sustancial de variables y

restricciones, generalmente sólo una pequeña fracción de estas variables y
restricciones domina verdaderamente el comportamiento del sistema real. Por lo
tanto, la simplificación del sistema con el fin de construir el modelo debe
concentrarse, fundamentalmente, en la identificación de las variables y
restricciones dominantes y también en otros datos que se juzguen pertinentes
para la toma de la decisión.
El arte de la representación por medio de modelos,

[Tah95], Capitulo 1
Para determinar cuánto y cuándo se debe comprar, el primer modelo es el EOQ

(Economic Order Quantity). Este modelo implica demanda constante en el tiempo, con
reabastecimiento instantáneo y sin escasez.
En este modelo, el nivel más alto en el inventario, es cuando se hace el reabastecimiento,

y el más bajo, es cuando llega a cero, momento en el cual se vuelve al siguiente nivel más
alto. A menores cantidades ordenadas, menor será el tiempo para la colocación de nuevos
pedidos. Sin embargo, también será menor la cantidad promedio de inventario mantenida
en el almacén. El caso opuesto se presenta, cuando se hacen pedidos de mayor cantidad.
Si bien en esta situación, la cantidad de pedidos disminuye, crece el inventario promedio
almacenado.
Debido a que tanto colocar un pedido, como mantener el inventario en almacén tienen sus
correspondientes costos, se debe encontrar la cantidad que equilibre estos costos,
minimizando el costo total. Éste es el fundamento para formular el modelo de inventario.
Sea K el costo fijo originado cada vez que se coloca un pedido y supongamos que
el costo de mantener una unidad en inventario (por unidad de tiempo) es h. Por lo
tanto, el costo total por unidad de tiempo CTU como función de y (siendo y la
cantidad a pedir) puede expresarse como
CTU (y) = (costo fijo)/unidad de tiempo + (costo de

mantenimiento del inventario)/unidad de tiempo

Estado del Arte
CTU (y) = K/y/D + h (y/2)
Modelo estático de un solo artículo,

[Tah95], Capitulo 14
Entonces, para encontrar el valor óptimo de esta función, asumiendo que y es una
variable continua, lo que hacemos es derivar CTU (y) y buscar su raíz. Esto nos deja que
la unidad de pedido que nos deja el costo mínimo es:
2
√

Esta cantidad y, que se calcula con esta fórmula, es la que se denomina cantidad pedida
económica, o Economic Order Quantity (EOQ). De aquí se infiere, que lo óptimo es
ordenar y unidades cada y/D unidades de tiempo. El costo óptimo, se obtiene
directamente sustituyendo y nos da:
√2
La información teórica, fórmulas y modelos, fue tomada de [Tah95], [Thi86] y [Ack84]
Sistemas ERP
Un sistema de ERP (Planificación de Recursos Empresariales, por sus siglas en ingles

Enterprise Resource Planning) es un sistema de información donde se integran varios de
los procesos horizontales dentro de la vida de una empresa. Un sistema ERP suele
manejar procesos dentro de las áreas de suministros, abastecimiento interno, gestión de
compras, manejo de cuentas por cobrar y/o pagar, y su registración contable y
presupuestal.
La interrogante principal de la gestión de inventarios es “cuanto comprar” (o producir) y

cuándo (o “cada cuándo”). En los sistemas ERP del mercado, esta pregunta suele o bien
no tener una manera de contestarse o en el mejor de los casos, se contesta utilizando los
métodos más simples de la gestión de inventarios (EOQ o EOQ con protección).

Estado del Arte
Integración de Aplicaciones
La Integración de aplicaciones en las empresas y entre ellas se ha convertido en

un tópico interesante. Es motivada por los B2B (Empresa A Empresa, por sus
siglas en ingles Business to Business), CRM (Administración de Relaciones de
Clientes, por sus siglas en ingles Customer Relationship Management) y por
Internet en general. Las tecnologías que hacen esta integración posible, son
llamadas middelware.
Trad. de Overview of Enterprise Application Integration,

[Ser02] Capítulo 1
La integración de aplicaciones nos lleva a enfrentar una serie de problemas para los
cuales debemos tratar de encontrar una manera consistente de resolver. Estos problemas
podrían resumirse en los siguientes:
• Proveer una visión consolidada de los datos corporativos

• Integrar sistemas de diferentes orígenes
• Permitir el acceso al sistema a usuarios tanto dentro como fuera de la empresa
• Conectar automáticamente las distintas tareas relacionadas para llevar a cabo una
función del negocio
• Reducir los tiempos de reacción del sistema de información
• Desarrollar e integrar rápidamente nuevas aplicaciones
Uno de los pilares de la ingeniería de software, es el identificar la mejor solución a un

problema dado. Entre las posibles maneras de resolver el problema se encuentra el tomar
una solución ya implementada, e integrarla al resto de los componentes que se tienen. Es
aquí donde entran las distintas técnicas de integración de aplicaciones en escena. Ésta
sección del documento se enfocará en analizar algunas de estas técnicas y su posible
aplicación al problema planteado
La integración de aplicaciones monolíticas con interfaces pobremente definidas o

sin ellas por completo es particularmente difícil y engorrosa, algunas veces al
nivel de que se torne altamente cuestionable la decisión original de integrar la
aplicación.

Estado del Arte
Trad. de Practical Experience,

[Crn02] Capítulo 18
Tipos de Integración de Aplicaciones
La Arquitectura de Integración es normalmente construida sistemáticamente en

varias capas. La idea detrás de esto es particionar el problema en varios
problemas más pequeños y resolver cada sub-problema paso a paso (similar, por
ejemplo, a la manera en que la arquitectura de redes se particiona en capas, tal
cual define el estándar ISO OSI). Entonces, la Arquitectura de Integración puede
ser vista en varias capas. Normalmente se comienza construyendo la integración
en la capa más baja, y de allí se comienza a subir gradualmente. Omitir una capa
es una solución a corto plazo para acelerar el proceso, pero muy probablemente
tengamos que pagar por ello más adelante. Los tipos más importantes de
integración son:
• Integración de Datos
• Integración de Aplicaciones
• Integración de Procesos de Negocio
• Integración de la Presentación
Estos tipos de integración se refieren tanto a integración dentro de la empresa

como a integración entre empresas (Empresa A Empresa, por sus siglas en ingles
Business to Business).
Trad. de Types of Integration,

[Jur07], Capítulo 1

Estado del Arte
Como se puede apreciar, la integración de aplicaciones es la combinación de

varios problemas. Cada organización y comunidad tiene su propio conjunto de
problemas de integración que deben ser analizados. Es por esto que es casi
imposible encontrar un solo conjunto de soluciones tecnológicas que puedan ser
aplicadas universalmente. Cada solución de integración de aplicaciones
requerirá diferentes enfoques. Por el momento, y en el futuro previsible, la
realidad de integración de aplicaciones no se asemeja a comprar soluciones
empaquetadas.
Si bien los enfoques de integración de aplicaciones varían considerablemente, es

posible crear algunas categorías generales, que incluyen:
• Orientada a Datos
• Orientada a Procesos de Negocios
• Orientada a Servicios
• Orientada a Portales
Trad. de Application Integration Approaches,

[Lin04], Capítulo 1
Como se puede ver, existen varias maneras de categorizar la integración de aplicaciones,

y es un tema tan amplio como variado. No es parte del alcance de este documento,
discutir las distintas técnicas de integración de datos, procesos o presentación. Nos
enfocaremos en las técnicas de integración de programas.
SOA
Es difícil encontrar una definición exacta de SOA. El problema no es que no haya

definiciones; el problema es que hay demasiadas… Sin embargo, por lo menos
todas las definiciones están de acuerdo en que SOA es un paradigma que mejora
la flexibilidad.
Trad. de SOA,
[Jos07], Capítulo 2

Estado del Arte
Podemos ver que integrar aplicaciones es una tarea compleja, capaz que el
mayor problema al que se enfrenta el desarrollo de aplicaciones corporativas.
Para alcanzar los objetivos de la integración de aplicaciones, varios métodos,
técnicas, patrones y tecnologías se han desarrollado a lo largo de los años,
abarcando desde integraciones punto a punto pasado por Enterprise Application
Integration (Integración de Aplicaciones Corporativas, EAI por sus siglas en
ingles) y Business Process Management (Administración de Procesos de Negocio)
hasta Arquitecturas Orientadas a Servicios.
Trad. de Integration Architecture, Principles, and Patterns,

[Jur07] Capítulo 1
Definición
Básicamente, es una arquitectura corporativa donde las aplicaciones son

diseñadas para proveer servicios de alto nivel que son consumidos por los
procesos de negocio u otras aplicaciones que se integren. La Arquitectura
Orientada a Servicios es tanto un concepto de diseño como una arquitectura. El
concepto de diseño detrás de SOA es acerca de diseñar las aplicaciones con
interfaces de acceso auto descriptas, y los servicios se compongan en procesos de
negocios. La arquitectura apunta a tener un mecanismo simple para utilizar éstas
interfaces de acceso para integrar la empresa.
Trad. de Defining Service-Oriented Architectures,

[Jur07] Capítulo 2

Metodología
Metodología
En una primera instancia, se recopiló la información respectiva de investigación
operativa. Se relevó la teoría existente sobre gestión de inventarios, el modelo EOQ
clásico y sus variantes. Sobre esto, se hizo un análisis de cuáles son los datos relevantes
para el cálculo utilizando este modelo, y al finalizar esta etapa, se realizaron ajustes al
alcance, determinando cual de las variantes del modelo EOQ se utilizaron en el estudio.
Una vez determinado el modelo, se definieron los requerimientos para la interfaz, y se
realizó un prototipo para poner en práctica la misma. Finalmente se realizaron las
conclusiones del uso de la misma.

Definición de la norma
Se construirá la interfaz que permita verificar empíricamente la integración entre un ERP
y un sistema de gestión de inventarios. El trabajo se dará por terminado cuando se
finalicen las etapas planificadas en la metodología, y podamos verificar empíricamente si
la interfaz permite la integración.
Definición y Desarrollo de la Interfaz
Se deberá definir los datos de entrada que requerirá la interfaz para obtener la respuesta al
requerimiento de los ERP’s. Los datos requeridos son el Periodo Total a Evaluar, el
Costo de Ordenar y el Costo de Mantener. Para este último se precisa la Tasa de
Demanda (medida en relación a la unidad de tiempo); la Unidad en la que está medida la
tasa de demanda; el Costo Unitario de Mantener proporcional al stock medio del producto
y/o el Costo Unitario de mantener proporcional al stock máximo.
Los datos que se retornarán son la cantidad a ordenar y la periodicidad con la que se
ordenará. Se deberá realizar una implementación de la interfaz para poder validar su uso.
Prototipo para probar la interfaz
Para probar la interfaz, se desarrollará un prototipo, que simulará los requerimientos

provenientes del ERP y las respuestas provenientes de los sistemas de gestión. Este
prototipo deberá poder solicitar a través de la interfaz la información, proporcionando los
datos requeridos por la misma en el formato definido por ésta.
A su vez, del lado del sistema de gestión, se recibirán las solicitudes que lleguen a la
interfaz y responderá de acuerdo al cálculo del modelo EOQ.
Arquitectura de la solución
Tanto la interfaz como el prototipo para validar su uso, se implementarán bajo la

siguiente arquitectura.
Se desarrollará utilizando GeneXus X Ev1, para la plataforma Java web, y utilizando

MySQL como gerenciador de base de datos.

Para probar la solución no se realizará un relevamiento de datos en distintas empresas,

sino que se utilizarán los datos a los que se tiene acceso. Estos datos son un resumen de
datos históricos a los que se tiene acceso.

Descripción de la Solución
Introducción
La interfaz que se diseñó, cuenta con la posibilidad de definir los modelos de inventario
con los que se va a trabajar, los sistemas de inventario a los que se tiene acceso, y el
conjunto de parámetros de entrada y salida que el modelo de inventario requiere para ser
utilizado en cada uno de estos sistemas.
Esta configuración permite que esta interfaz pueda funcionar para cualquier modelo de
inventario de cualquier sistema.
La aplicación que se conecte a través de la interfaz, preguntará a través de un servicio,

cuales son los modelos de inventario disponibles. Una vez que sepa que modelos de
inventario hay, pedirá a través de un segundo servicio, los sistemas que implementan
dicho modelo. Teniendo el Modelo que se desea utilizar y el Sistema con el cual se
calculará, se obtienen a través de un tercer servicio, el conjunto de parámetros de Entrada
y Salida necesarios para realizar la llamada. Finalmente, al tener toda la información
necesaria, se llama al cuarto servicio diciéndole qué modelo de inventario se desea
utilizar, con qué sistema se llevará adelante el cálculo, y el conjunto de parámetros de
entrada. Este servicio contestará el conjunto de parámetros de salida previamente
definidos.
Esta es la parte crítica de la solución, dado que indistintamente de qué modelo de

inventarios se desee utilizar y que sistema de inventarios se utilice para el cálculo, la
signatura del servicio para realizar el cálculo será siempre la misma.

Arquitectura
Arquitectura de la aplicación
Se implementó la solución con una arquitectura tres capas web estándar. Desde la capa
cliente se realizan requerimientos http a la capa lógica. En esta capa, el servidor web es el
encargado de responder a estos requerimientos, ya sea entregando los documentos
solicitados, o derivando el pedido al servidor de aplicaciones para satisfacer el
requerimiento. El servidor de aplicaciones, realiza la lógica que implementa la solución al
requerimiento, y en caso de ser necesario, se comunica con la capa de datos para obtener
los mismos. Una vez finalizado el cumplimiento del requerimiento, prepara la respuesta
que se enviará al cliente, y se la da al servidor de web, que será el encargado de enviarla
al cliente.
En este caso en particular, se implementó el prototipo en una arquitectura Java. Tanto el

servidor web como el servidor de aplicaciones son servidores Apache Tomcat, el servidor
de bases de datos es MySQL y la implementación está basada en servlets. La solución
está generada utilizando Genexus X Ev 1.

Implementación
Desde el backoffice de la interfaz se pueden definir los modelos de inventario, los

sistemas que los implementan así como los parámetros que precisan para ser invocados.
Descripción General de la Aplicación
Interfaz – Descripción General
La Interfaz cuenta con un diseño genérico, donde se tiene un cabezal, debajo del cabezal
una lista de las pantallas por las que se ha pasando, un menú en forma de árbol que
permite acceder a las distintas partes del sistema, el área de trabajo y un pie de página,
que nos da información contextual.

Modelos de Inventario
Interfaz – Modelos de Inventario
Desde esta pantalla podemos ver los distintos Modelos de Inventario que hay definidos en
el sistema, y nos permite realizar acciones como: buscar uno en particular, visualizarlo,
modificarlo, eliminarlo o agregar un nuevo Modelo.
Interfaz – Visualizar Modelo de Inventario

En la pantalla de visualización del modelo de inventario, se puede visualizar toda la

información del Modelo de Inventario. En la primera pestaña, se despliega la información
relativa al modelo en sí, y permite acceder directamente a modificar o eliminar el
Modelo. En la segunda pestaña, se despliegan los Sistemas de Inventario que
implementan este Modelo, y en la última pestaña, se puede visualizar la signatura
necesaria para llamar a este modelo en cada uno de los Sistemas.
Interfaz – Edición de Modelo de Inventario
Finalmente, en la pantalla de edición de un modelo de inventario, podremos agregar un

nuevo modelo, modificar sus datos y también eliminarlo.

Sistemas de Inventario
Interfaz – Sistemas de Inventario
Desde esta pantalla podemos ver los distintos Sistemas de Inventario que hay definidos
en el sistema, y nos permite realizar acciones como: buscar uno en particular,
visualizarlo, modificarlo, eliminarlo o agregar un nuevo Sistema.
Interfaz – Visualizar Sistema de Inventario

En la pantalla de visualización del sistema de inventario, podemos ver toda la

información del Sistema de Inventario. En la primera pestaña, tenemos la información
relativa al Sistema en sí, y nos permite acceder directamente a modificar o eliminar el
Sistema y en la segunda pestaña, tenemos los Modelos de Inventario que implementa este
Sistema.
Interfaz – Edición de Sistema de Inventario
Finalmente, en la pantalla de edición de sistema de inventario se puede agregar un nuevo

modelo, modificar sus datos y también eliminarlo.
Para un Sistema de Inventario, los datos que vamos a precisar, más allá de su descripción,
son los relativos a donde encontramos la implementación del mismo (servidor, puerto, si
se debe acceder a través de una conexión segura, y la ruta dentro del servidor). Además,
para cada modelo de inventario que implemente, debemos tener la información de la
aplicación que resuelve ese modelo, para completar la información de conexión.

Parámetros de un Modelo en un Sistema
Interfaz – Parámetros de un Modelo en un Sistema
Desde esta pantalla podemos ver los manejar los Parámetros para las distintas
combinaciones de Sistemas de Inventario y Modelos que hay definidos en el sistema, y
nos permite realizar acciones como: buscar una en particular, visualizarlos, modificarlos,
eliminarlos o agregar un nuevo Sistema.
Interfaz – Visualizar Parámetros de un Modelo en un Sistema

En la pantalla de visualizar parámetros de un modelo, podemos ver toda la información

referente a los Parámetros necesarios para realizar los cálculos en un Sistema de
Inventario particular, utilizando un Modelo de Inventarios en particular. En la primera
pestaña, tenemos la información relativa a la signatura que genera la definición de
parámetros, y permite acceder directamente a ingresar un nuevo parámetro o modificarlos
/ eliminar los ya ingresados. En la segunda y tercer pestaña tenemos los parámetros de
entrada y salida respectivamente.
Interfaz – Edición de Parámetros de un Modelo en un Sistema
Finalmente, en la pantalla de edición de parámetros, tendremos la posibilidad de agregar,

editar o eliminar tanto los parámetros de entrada como de salida.

Para cada parámetro, debemos indicar el orden dentro de la invocación, una descripción
para el parámetro, y el tipo de datos que tendrá el valor que se reciba/retorne.
Interfaz Pública
La interfaz, publica cuatro servicios. A través de estos servicios es que el ERP puede
comunicarse de manera uniforme con cualquier sistema de inventarios, y ejecutar los
cálculos a través de cualquier modelo que éstos implementen.
awsgetmodelosinventario
Nombre: wsGetModelosInventario
Namespace: Interfaz
Tipos de Datos:
Parámetros Entrada: No recibe
Parámetros Salida: ModelosInventario, Resultado

Descripción: El servicio retorna los Modelos de Inventario que están definidos en la

Interfaz, y para los cuales al menos un Sistema de Inventarios tenga una implementación.
Los parámetros que responde son una colección de Modelos de Inventario, donde cada
elemento cuenta con el identificador del modelo, y su descripción; y un segundo
parámetro con los resultados de ejecutar el servicio. Este tipo de datos es genérico en toda
la interfaz, y cuenta con un elemento que define si la ejecución del servicio fue
satisfactoria (suceso en verdadero) o si produjo algún error (suceso en falso). En caso de
que no haya sido satisfactoria, se retorna una colección de mensajes que explican la causa
del resultado insatisfactorio.
awsgetsistemasinventariobymodeloinventario
Nombre: wsGetSistemasInventarioByModeloInventario
Namespace: Interfaz
Tipos de Datos:

Parámetros Entrada: ModeloInventarioId
Parámetros Salida: SistemasInventario, Resultado
Descripción: El servicio retorna los Sistemas de Inventario que implementan el Modelo

de Inventario solicitado. Recibe como parámetro el identificador del Modelo de
Inventario para el cual se requiere la lista de Sistemas de Inventario, y responde la
colección de Sistemas de Inventario que lo implementan, donde cada elemento cuenta
con el identificador del Sistema, y su descripción; y un segundo parámetro con los
resultados de ejecutar el servicio.
awsgetparametrosbymodelosistema
Nombre: wsGetParametrosByModeloSistema
Namespace: Interfaz
Tipos de Datos:

Parámetros Entrada: ModeloInventarioId, SistemaInventarioId
Parámetros Salida: Parametros, Parametros, Resultado
Descripción: El servicio retorna los Parámetros de Entrada y los Parámetros de Salida

requeridos para ejecutar el cálculo de inventario según el Modelo seleccionado en el
Sistema seleccionado. Recibe como parámetro el identificador del Modelo de Inventario
que se selecciono y el identificador del Sistema de Inventario con el cual se va a efectuar
el cálculo, y responde la colección de Parámetros de Entrada y la colección de Parámetros
de Salida, donde cada elemento cuenta con el identificador del Parámetro, el Orden
dentro de la lista, la descripción del parámetro, el tipo de datos y el valor asignado para el
mismo; y un tercer parámetro con los resultados de ejecutar el servicio.
awsejecutacalculoinventario
Nombre: wsEjecutaCalculoInventario
Namespace: Interfaz
Tipos de Datos:

Parámetros Entrada: ModeloInventarioId, SistemaInventarioId, Parametros
Parámetros Salida: Parametros, Resultado
Descripción: El servicio ejecuta el cálculo de inventario según el Modelo seleccionado,

el Sistema seleccionado y los valores que se envían para los parámetros de entrada.
Recibe como parámetro el identificador del Modelo de Inventario que se seleccionó y el
identificador del Sistema de Inventario con el cual se va a efectuar el cálculo, y para cada
uno de los parámetros de entrada, el valor requerido, y responde la colección de
Parámetros de Salida, donde cada elemento cuenta con el identificador del Parámetro, el
Orden dentro de la lista, la descripción del parámetro, el tipo de datos y el valor asignado
para el mismo; y un segundo parámetro con los resultados de ejecutar el servicio.

Funcionamiento
El sistema ERP debe consumir los cuatro servicios para interactuar con la interfaz. El
primer paso, es solicitar la lista de Modelos de Inventario disponibles a través del servicio
awsgetmodelosinventario. Este servicio, le retorna la lista de modelos, de entre los cuales
se selecciona uno. Teniendo este Modelo, y utilizando el servicio
awsgetsistemasinventariobymodeloinventario se obtiene la lista de Sistemas de Inventario
que implementan este Modelo, entre los cuales se selecciona uno. Una vez seleccionado
el Modelo y Sistema con los cuales se desea realizar el cálculo, se invoca al servicio
awsgetparametrosbymodelosistema que retorna la lista de parámetros que se precisan
para ejecutar el cálculo, y la lista de parámetros que contendrá la respuesta. Finalmente,
se cargan los valores que correspondientes a los parámetros de entrada, y se invoca al
servicio awsejecutacalculoinventario y se obtiene la respuesta.
En la siguiente imagen se puede ver gráficamente los pasos para realizar esta interacción.

Flujo de la Aplicación
Sistema de Inventario Prototipo
Se realizó un prototipo para simular la interacción de la Interfaz con un Sistema de

Inventarios. En el prototipo se programó el funcionamiento del cálculo de un Sistema de
Inventarios para el Modelo de Inventarios EOQ Clásico.

awscalculateeoq
Nombre: wsCalculateEOQ
Namespace: Inventario
Tipos de Datos:
Parámetros Entrada: Demanda, CostoOrdenar, CostoMantener
Parámetros Salida: EOQ, CantidadPedidos, Resultado
Descripción: El servicio ejecuta el cálculo de inventario según el Modelo EOQ Clásico.

Recibe como parámetros la Demanda del Producto para una unidad de tiempo, el Costo
de Ordenar y el Costo de Mantener una unidad del Producto durante la unidad de tiempo,
y responde la Cantidad Económica de Pedido (EOQ) y la Cantidad de Pedidos a realizar
en el transcurso de la unidad de tiempo; y un tercer parámetro con los resultados de
ejecutar el servicio.

Impacto en ERP
Se realizó un prototipo para simular la interacción de la Interfaz con un ERP. Se utilizó el

ERP K2B (http://www.k2business.com).
En este ERP se realizaron las necesarias para interactuar con la Interfaz de manera de
validar la funcionalidad de la misma.
El ERP cuenta con un modulo de almacén, en el cual se tiene la funcionalidad de realizar

solicitudes de recursos (lanzar el proceso de compra) para los productos que se
determinen bajo condiciones determinadas. Estas condiciones se definen a nivel de
Unidad Organizacional, Centro de Almacenaje, Producto y Depósito. Para esta
combinación de factores, se define cuales son las condiciones de reabastecimiento
(creación de una nueva solicitud de recursos).
K2B – Datos de Reorden por Unidad Organizacional, Centro de Almacenaje, Producto
Para validar el funcionamiento de la interfaz, se realizaron modificaciones al tipo de

condiciones que se permiten, agregando el cálculo a través de un sistema externo, y se
agrega la posibilidad de almacenar para esta combinación de factores, el Modelo y
Sistema de Inventario que se utiliza para los cálculos.

K2B – Cálculo de Reorden para un Producto (utilizando la extensión para Cálculo a

través de un Sistema Externo)

Conclusiones
Conclusiones
Los modelos de inventarios nos permiten utilizar métodos cuantitativos al momento de
tomar decisiones. Gran parte del capital invertido en las empresas, está en los inventarios
que ésta maneja.
Como se mencionó en la delimitación del alcance, el modelo EOQ, es un modelo que si

bien asume ciertas restricciones, que son simplificaciones de la realidad, presenta
resultados ampliamente satisfactorios teniendo en cuenta el bajo costo necesario para
implementarlo.
En [Tor09] se comprueba que el uso del modelo EOQ presenta ventajas relevantes sobre
no utilizar ningún modelo de Inventario. Particularmente, se expresa en las conclusiones
el siguiente argumento:
La primera empresa estudiada, no aplica gestión de stock. Podría por ejemplo

guiarse por pedidos mensuales. Si así lo hiciera, el costo anual calculado sería de
1.470 $Mx para el año 2007, a diferencia del costo real de ese año que fue 2.776
$Mx. Sólo el hecho de aplicar el EOQ clásico reduce el costo de la gestión a
1.161 $Mx.
Determinar a partir de las características de ciertos

productos la aplicación de modelos de gestión de inventarios
más avanzados [Tor09], Conclusiones
Esto confirma las afirmaciones vistas anteriormente, y solidifica la teoría de que el

modelo, por más simplista que sea, ofrece ventajas sustanciales a no utilizar ninguno.
Los sistemas de administración de empresas, tienen como uno de sus objetivos entregar
información correcta y actualizada a los niveles gerenciales, de manera que estos puedan
utilizarla en la toma de decisiones.
La teoría de inventarios se especializa en responder las preguntas de cuánto se debe

comprar y cuándo, de determinado material o producto, de manera de maximizar los
beneficios minimizando los costos, es decir, maximizar los resultados.

Conclusiones
Se debe entonces encontrar la manera de integrar a los sistemas de administración de

empresas con los sistemas que responden estas preguntas de manera de tener una sola
visión consolidada de la información.
Esto nos lleva a la integración de aplicaciones. Se ha visto, que existen varias

clasificaciones de integración de aplicaciones, y si bien podríamos ahondar en cada una
de ellas, para la situación en la que nos encontramos, nos basta con integrar los servicios
que proveen ellas.
Dentro de la integración a nivel de servicios, SOA aparece como la metodología más

adecuada para esta tarea. Esto nos permite definir un conjunto de servicios que requiere
un sistema de administración de empresas para obtener los beneficios de un sistema de
inventarios.
El objetivo de este trabajo fue crear una interfaz que permita a los sistemas de
administración de empresas integrarse fácilmente con los sistemas de inventarios.
Teniendo esto presente, se creó la interfaz que describimos en capítulos anteriores, la cual
permite a través de ella, abstraerse de las distintas implementaciones de distintos sistemas
de inventarios, poder obtener resultados para cada uno de los modelos que se hayan
implementado.
No sólo permite que con una sola implementación, los sistemas de administración
obtengan los resultados de distintos sistemas de inventario, sino que además los aísla de
posibles cambios que éstos puedan tener en su interfaz a lo largo de nuevas versiones,
corrección de errores o mejoras.
Se había planteado el objetivo de realizar esta interfaz, y para validar su factibilidad

realizar pruebas sobre el Modelo EOQ. La interfaz planteada, de la manera que está
diseñada, permite también interactuar con otros modelos de inventario.

Bibliografía
Bibliografía
[ACK84] ACKOFF, RUSSEL L. Y SASIENI, MAURICE W.: Fundamentos de Investigación
de Operaciones. (Trad. Jiménez Ruiz, Enrique; 1ra Ed. 1971), 6ta
Reimpresión, México DF, Ed. Limusa, 1984.
[CRN02] CRNKOVIC, IVICA Y LARSSON, MAGNUS: Building reliable component-based

software systems. Massachusetts, USA Ed. Artech House Computing
Library, 2002.
[DIC07] DICKERSBACH, JÖRG T.; KELLER, GERHARD Y WEIHRAUCH, KLAUS:

Production Planning And Control With SAP. (Trad. Lemoine International
Inc de la Ed. Aleman) 1ra Ed., 2da. Reimpresión (con correcciones)
Massachusetts, USA, Ed. Galileo, 2007.
[FAL09] FALTER, HUVAR Y ZUBEV, FIEDLER: Developing Applications With

Enterprise SOA.(Trad. Franke, Jon de la 1ra. Ed. Alemana 2008). 1ra Ed.
Massachusetts, USA, Ed. Galileo, 2009.
[ERL09] ERL, THOMAS: SOA Design Patterns. 1ra Ed., Massachusetts, USA Ed.
Pearson Education, 2009.
[GAL85] GALLAGHER, CHARLES A. Y WATSON, HUGH J.: Métodos Cuantitativos para

la Toma de Decisiones en Administración. (Trad. González Osuna, Marcia
de la 1ra Ed. Ingles), México DF, Ed. McGraw-Hill 1985.
[HOH04] HOHPE, GREGOR Y WOOLF, BOBBY: Enterprise Integration Patterns:

Designing, Building, And Deploying Messaging Solutions 1ra. Ed., 10ma
Reimpresión, Massachusetts, USA, Ed. Pearson Education, 2004.
[JOS07] JOSUTTIS, NICOLAI M.: SOA in Practice. 1ra. Ed., California, USA, Ed.
O’Reilly 2007.
[JUR07] JURIC, MATJAZ B.; LOGANATHAN, RAMESH; SARANG, POORNACHANDRA

Y JENNINGS, FRANK: SOA Approach to Integration: XML, Web services,
ESB, and BPEL in real-world SOA projects. 1ra. Ed., Birmingham, UK, Ed.
Packt Publishing 2003.

Bibliografía
[KRA05] KRAFZIG, DIRK; BANKE, KARL Y SLAMA, DIRK: Enterprise SOA. 1ra. Ed.,
New Jersey, USA, Ed. Pearson, 2005.
[LIN04] LINTHICUM, DAVID S.: Next Generation Application Integration: From

Simple Information to Web Services. 1ra. Ed., Massachusetts, USA, Ed.
Pearson Education, 2004.
[MOU06] MOURAO, LUIS X. B. Y WEINER, DAVID: Dynamics AX: A Guide to

Microsoft Axapta. 1ra Ed., New York, USA, Ed. Apress 2006.
[MUR08] MURRAY, MARTIN: SAP MM – Functionality and Technical Configuration.

2da Ed., Bonn, Alemania, Ed. Galileo 2008.
[OLE02] O’ LEARY, DANIEL: Enterprise Resource Planning Systems – Systems,

Lifecycle, Electronic Commerce, and Risk. Reimpresión 2002, 1ra Ed. 2000,
USA, Ed. Cambridge University Press, 2002.
[SER02] SERAIN, DANIEL: Middleware and Enterprise Application Integration.

(Trad. Craig, Iain de la 3ra Ed. de la Ed. Francés 2001), Londres, Ed.
Springer-Verlag, 2002.
[SAS86] SASIENI, MAURICE; YASPAN, ARTHUR Y FRIEDMAN, LAWRENCE:

Investigación de Operaciones, Métodos y Problemas. (Trad. Nieto de
Pascual, José y Gonzalez Zubieta, Rómulo H. de la 9na Reimpresión de la
primera Ed. Inglés; Novena Reimpresión de la 1ra Ed. Español, 1967),
México, DF, Ed. Limusa, 1986.
[SHA87] SHAMBLING, JAMES E. Y STEVENS JR., G. T.: Investigación de Operaciones,

Un enfoque fundamental. (Trad. Duarte Torres, Alberto y Ponton, Alberto
de la 1ra Ed. Inglés, 1975; Reimpresión de la 1ra Ed. Español), México, DF,
McGraw-Hill, 1987.
[TAH95] TAHA, HAMDY A.: Investigación de Operaciones. (Trad. De la Cera Alonso,

José, 5ta Edición en Inglés de 1992), 1ra Impresión, México DF, Ed.
Alfaomega, 1995.

Bibliografía
[THI86] THIERAUF, ROBERT J.: Introducción a la investigación de operaciones.

(Trad. Garcia Díaz, Rafael, 1ra Ed. 1982), 2da Reimpresión, México DF,
Ed. Limusa, 1986.
[THI86A] THIERAUF, ROBERT J.: Toma de Decisiones por Medio de Investigación de

Operaciones. (Trad. Meza Nieto, Jose, 1ra Ed. 1972), 11ra Reimpresión,
México DF, Ed. Limusa, 1986.
[TOR09] TORRADO, CAROLINA.: Determinar a partir de las características de ciertos

productos la aplicación de modelos de gestión de inventarios más
avanzados. (Memoria de Grado), Montevideo, Uruguay, Universidad
Católica del Uruguay, Facultad de Ingeniería y Tecnologías, 2009.
[VAN71] VAN DER VEEN, B: Introducción a la teoría de la investigación operativa.

(Trad. SERCOMAR) Madrid, Ed. Biblioteca Técnica Philips, 1971.

Memoria Gonzalo Losada

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Memoria Gonzalo Losada

Cargado por

Copyright:

Formatos disponibles

Universidad Católica del Uruguay

Facultad de Ingeniería y Tecnologías

Construir una interfaz que facilite la

Lic. Gonzalo R. Losada Vasilisín

Ing. Daniel Paolillo

Montevideo, 26 de Octubre de 2009

Finalmente, luego de ésta parte introductoria, se presenta la descripción de la solución

Universidad Católica del Uruguay. Facultad de Ingeniería y Tecnologías. 2

TABLA DE CONTENIDOS ............................................................................................................. 3

TABLA DE IMÁGENES ................................................................................................................. 5

DEFINICIÓN DEL PROBLEMA ........................................................................................................ 8

RESTRICCIONES AMBIENTALES Y OPERATIVAS............................................................................... 11

CONCLUSIONES DE LA RESTRICCIONES AMBIENTALES Y OPERATIVAS ............................................. 11

ESTADO DEL ARTE .................................................................................................................. 14

GESTIÓN DE INVENTARIOS .................................................................................................... 14

DEFINICIÓN DE LA NORMA ........................................................................................................ 25

DEFINICIÓN Y DESARROLLO DE LA INTERFAZ ............................................................................. 25

Universidad Católica del Uruguay. Facultad de Ingeniería y Tecnologías. 3

DESCRIPCIÓN DE LA SOLUCIÓN .................................................................................................. 27

Universidad Católica del Uruguay. Facultad de Ingeniería y Tecnologías. 4

Universidad Católica del Uruguay. Facultad de Ingeniería y Tecnologías. 5

La investigación de operaciones (IO) aspira a determinar el mejor curso de

Arte y Ciencia de la Investigación de

Universidad Católica del Uruguay. Facultad de Ingeniería y Tecnologías. 6

En este trabajo, nos vamos a centrar puntualmente en la parte de gestión de inventarios de

Universidad Católica del Uruguay. Facultad de Ingeniería y Tecnologías. 7

Definición del problema

Existe un problema de inventario si el volumen de recursos está sujeto a control y

Naturaleza de los problemas de inventario

Universidad Católica del Uruguay. Facultad de Ingeniería y Tecnologías. 8

Finalmente, realizar un prototipo para poner en práctica la interfaz, interconectando un

Universidad Católica del Uruguay. Facultad de Ingeniería y Tecnologías. 9

Las suposiciones determinísticas (es decir, conocimiento perfecto de los valores

El problema general determinístico para

Universidad Católica del Uruguay. Facultad de Ingeniería y Tecnologías. 10

Restricciones Ambientales y Operativas

Se trabajó con el modelo de inventario EOQ (Lote Económico), construyendo una

Finalmente, las pruebas de la interfaz se realizaron utilizando datos de prueba, tratando de

Conclusiones de la Restricciones Ambientales y Operativas

No se encontraron grandes restricciones a nivel ambiental, pero a nivel operativo existen

La primera restricción, si bien limitó el alcance del estudio lo hizo solamente en

Universidad Católica del Uruguay. Facultad de Ingeniería y Tecnologías. 11

Universidad Católica del Uruguay. Facultad de Ingeniería y Tecnologías. 12

Universidad Católica del Uruguay. Facultad de Ingeniería y Tecnologías. 13

Estado del Arte

Normalmente, el objetivo es minimizar el costo total (real o esperado). Sin

Las variables que se pueden controlar, separadamente o en combinación, son las

1. La cantidad adquirida (por compra, producción o algún otro medio); o

2. La frecuencia o tiempo de abastecimiento; es decir que tan a menudo o

En los problemas de inventario, las variables no controlables se dividen en

Costos de mantenimiento de inventarios: costos que se incrementan en

Costo de capital invertido. Éste es un cargo que se refiere al interés y a menudo

Universidad Católica del Uruguay. Facultad de Ingeniería y Tecnologías. 14

Costos de mantenimiento del archivo y cargos administrativos. Las existencias

d) Costos de depreciación, deterioro y obsolescencia …

Costos debidos a cambios en la tasa de producción: Incluyen costos de arranque

Universidad Católica del Uruguay. Facultad de Ingeniería y Tecnologías. 15

Precios de compra o costos de producción directos: El costo unitario por artículo

Tiempo de reorden: El tiempo que ocurre entre la colocación del pedido y la

Cantidad entregada: Si se pide una cantidad q para compra o producción, la

Naturaleza de los problemas de inventario

La estructura básica de un sistema de inventario, es una ecuación que relaciona las

Es decir, que el inventario en un momento t’ lo podemos descomponer en el inventario