TOTAL Exemple

Parte 3 UN EJEMPLO
@EMG/10 - Enric Martnez Gomriz
-1-
PRESENTACIN
Se incluye a continuacin un ejemplo de un sistema distribuido. Intenta ser un lo ms real posible sin perder nunca de vista el objetivo docente. Como le comento en la especificacin, no se empee en hacerlo ms real. Se trata bsicamente de practicar el diseo de servicios. El enunciado es deliberadamente muy ambiguo. Est hecho as para motivarle a establecer otros criterios funcionales que le lleven a soluciones diferentes con lo que puede realizar prcticas adicionales. Los que yo utilizo para tomar mis decisiones se irn presentando a lo largo del desarrollo del ejemplo Le propongo que primero lo piense por su cuenta y plantee su solucin y despus vea mi propuesta. La solucin que le propondr, no intenta ser la mejor solucin. No olvidemos nunca que ese concepto no existe ya que depende de la aplicacin en si y de las caractersticas especficas del sistema distribuido, incluyendo su historia hasta ese momento. La solucin intenta ser completa. Sin embargo, se dejan algunos temas, como la definicin de los parmetros de las llamadas, por definir que Vd. podr completar como ejercicio adicional. Se utiliza MADFRA para establecer la especificacin del sistema.
-2-
SISTEMA DE INFORMACIN PARA LA GESTIN DE VENTAS DE UNA EMPRESA DE DISTRIBUCIN.

1. Enunciado.
Una empresa de distribucin tiene su red de ventas basada en tiendas repartidas geogrficamente y con almacenes autnomos en cada una de ellas. Tenemos que disear un Sistema de Informacin (SI) para la gestin de ventas y la reposicin de almacenes. La gestin de ventas se realiza con dos elementos: Tiendas de venta. Vendedores mviles equipados con un porttil.
Las tiendas pueden ser de tamao muy diverso: desde muy pequeas, donde una persona, lo hace todo hasta otras que disponen de muchos puntos de venta. Para la venta cara al pblico cada tienda realiza un esquema de venta que obedece a la siguiente operativa. Los clientes solicitan los productos en LUGARES DE CAPTACIN DE PEDIDOS, donde se le cogen los datos y la relacin de productos que desean comprar. Dado el diferente tamao de las tiendas, se debe prever la escalabilidad en los LUGARES DE CAPTACIN. Los clientes pagarn al contado, la cual cosa hace que no tengamos problemas de crdito. Se tiene que acceder al ordenador central de la Compaa para registrar al cliente y evitar duplicidades, la conexin puede ser lenta. Cada cliente queda identificado por su NIF/CIF. Cuando se coge el pedido de un producto de un cliente se tiene que asegurar el stock. Si el producto pedido se encuentra en el almacn de la tienda, se reserva. Si no se encuentra suficiente stock en la tienda, el SI que hemos de disear tiene que consultar el stock de las tiendas prximas con el fin de saber si el producto se encuentra all. Si est, se servir desde esa tienda, si no est, no se vender al cliente este producto. El algoritmo de secuencializacin para la bsqueda del producto en las tiendas de alrededor, que es diferente para cada tienda, NO ES EL OBJECTIVO DE ESTE TRABAJO. Suponga que est encapsulado dentro de una pieza. Cuando el cliente ya ha realizado el pedido tendr que pasar al LUGAR DE COBRO donde pagar en efectivo. Se prev que, sea cual sea el tamao de la tienda, habr suficiente con una caja para cobrar. El SI debe llevar control del arqueo de cada cajero. Una vez registrado, y en paralelo a la accin de cobro, el pedido se habr enviado al LUGAR DE ENTREGA DEL MATERIAL donde se sacar el material del almacn
y se preparar el pedido. Aqu se prev "cuello de botella" dado que el tiempo de preparacin de pedidos se estima ms largo que el tiempo de captacin y cobro. Las entregas de productos reservados por los clientes desde otras tiendas se gestionarn en el LUGAR DE ENTREGA DEL MATERIAL creando paquetes para un servicio de mensajera. El criterio ser prepararlos en los tiempos muertos cuando no hay pedidos para servir de la propia tienda. Al cerrar la jornada, se prepararn todos los que queden aun pendientes. Finalmente, las ventas, como conjunto de los pedidos y las acciones de cobro, deben llegar al ordenador central y anotarse en un fichero secuencial por jornada de venta. Las aplicaciones corporativas se encargarn de gestionarlas dentro de sistemas de Informacin ya construidos e independientes del ejercicio. Pensad una forma de integracin e intercambio lo ms flexible posible entre el nuevo SI y los antiguos. Interesa que las roturas de stock de las tiendas y el almacn central sean mnimas. Para esto, cada una tiene un algoritmo de optimizacin del stock mnimo y de la cantidad a pedir QUE NO SE DEBE DISEAR y que podis considerar encapsulado dentro de una pieza. Naturalmente, cada tienda tiene que vender aunque no tenga conexin con el exterior. Los porttiles de los vendedores mviles tienen que tener una aplicacin que se parezca lo ms posible a la de las tiendas. Deben tratarse como usuarios nmadas. La aplicacin ha de prever la recepcin de pedidos por WEB y directamente desde las aplicaciones corporativas. de los clientes de la Compaa El stock de las tiendas se repone segn los siguientes criterios: Algunos productos se compran directamente al proveedor. Estos productos pueden ser diferentes para cada tienda. El resto de los productos se piden al almacn central al final de cada jornada y se reciben a lo largo del da siguiente.
El stock del almacn central se repone a partir de pedidos a proveedores que toma como base una cantidad a comprar en funcin del stock actual, las ventas previstas, las histricas y las caractersticas de cada producto. Puede suponer que el algoritmo que da ese valor est ENCAPSULADO EN UNA PIEZA. El intercambio de documentos con los proveedores ser electrnico siempre que sea posible. Se pide que todos los documentos que afecten a stock estn en administracin con su estado de gestin. Disee el circuito de gestin de stock y de documentos afectados para este modelo de compras y reposicin. Piense la forma de agilizar en el almacn central la recepcin de material desde los proveedores y la preparacin y distribucin a tiendas del material a reponer. Interesa trabajar con stock futuro. Este concepto se implementar en dos stocks disponibles:
-4-
Actual En fecha futura (stock futuro) calculado como la suma del stock disponible y las compras previstas de recibir desde hoy hasta esa fecha.
Para simplificar no trate el tema de la ubicacin fsica del gnero en el almacn. Piense tambin en un sistema para minimizar el proceso de recepcin del material en las tiendas, dado que deben de vender mientras que incorporan el material a su inventario y almacn.
2. Posibles ampliaciones.
Arquitectura de dos niveles. La aplicacin ha de prever un modulo de control de presencia del personal del local con responsabilidad directa del director del local. Los datos de control de presencia se han de traspasar a la nmina corporativa de forma automtica. Control de la red de franquiciados
3. Observaciones y Recomendaciones.
El ejemplo es muy amplio. Tenga en cuenta, sin embargo, que el objetivo bsico del ejercicio es que el trabajo sea de calidad, no que se escriba mucho. A pesar que este sistema de informacin puede ser real, no se empee en "hacerlo demasiado real", no son importantes los detalles, sino disear la arquitectura de sistema, el anlisis de consistencia y el de administracin. No improvise. Siga la metodologa propuesta. No busque atajos. Es seguro que existen cosas que debern de aadir a la especificacin funcional anterior. Hganlo y acten en consecuencia. Es un objetivo del ejercicio que piense en ello. Haga un funcional sin entrar a fondo en los temas que, segn su opinin, tengan que quedar fuera del mbito afectado por el diseo distribuido. No disee GUI's, limtese a definir la transaccin que ha de generar. Proponga los datos a nivel de entidades y/o objetos, identificando los atributos slo cuando sea necesario. Reflejarlo todo con un Modelo de Objetos. No hace falta decir que el SI de informacin debe quedar lo ms consistente y robusto posible.
-5-
MODELO DE OBJETOS
1. Identificacin de clases.
Leyendo el enunciado se identifican las siguientes clases potenciales: Tienda Almacn de la tienda Vendedor. Puesto de captura de pedidos Puesto de cobro. Puesto de entrega del material Cliente. Producto. Stock. Pedido de captacin de la venta del cliente Venta Jornada. Almacn Central Proveedor. Pedido compra a proveedor. Pedido de reposicin desde almacn Cajero. Almacenero. Captador de pedidos. Transportista
Para no complicar el ejemplo con temas no bsicos al sistema distribuido, simplificaremos el problema suponiendo que todos los pedidos de compras y reposicin se entregan completos en un albarn. Esta simplificacin obviamente no puede hacerse nunca en la realidad pero nos tomamos la licencia para primar la claridad del diseo distribuido. Analtica
Pertenece a
Pedido
Podemos detectar cuatro jerarquas de herencia (is-a): Los almacenes de la tienda y la central tienen la mayor parte de la gestin de stock comn. La diferencia es que las entradas de la central son proveedores y las salidas son para las tiendas y en la tienda las entradas pueden ser tanto del almacn central como de proveedores. Parece
Cliente Proveedor
Figura Figura 1 1
1+
Venta
Compra
Reposicin
Lnea Ped
Puesto
Almacn
Incluye Producto
Captacin
Cobro
Entrega
Central
Tienda
-6-
razonable hacer una clase almacn y dos herencias pera la Central y la tienda. Los puestos de trabajo determinan una especializacin de nombre puesto. El cliente y el proveedor tienen muchas partes comunes. Los derivaremos de una clase genrica que denominaremos analtica. Lo mismo pasa con los tres tipos de pedido, compras a proveedores, reposicin desde almacn central y pedido de cliente, que especializaremos desde una clase genrica que denominaremos pedido.
Estas jerarquas de herencia pueden ser representadas por el esquema de la Figura 1. Se han incluido, adems, las relaciones establecidas entre pedido, analtica y producto. Intentemos ahora la identificacin de agregaciones (is-part-of) una de las cuales, pedido-linea ya se ha detectado en la figura 1. Otra de esta relaciones es, por criterios de contenido, que una tienda tiene un almacn y puestos de trabajo. Si buscamos ahora las asociaciones (has knowledge of) dentro del mbito de la tienda detectamos como posibles candidatas: Situacin del puesto de entrega del almacn de la tienta (Est en). Los almacenes de las tiendas reciben productos del Central (Se repone de). Los productos que una tienda debe pedir directamente a un proveedor se modelarn por una relacin terciaria entre tienda, producto y proveedor (Pedir a). El resto de productos de repondrn desde el almacn central. El almacn de una tienda se apoya en otras tiendas cuando no tiene stock (Se apoya en). Los productos vendidos por los vendedores se sirven desde almacenes. Hemos de decidir el criterio. Podemos escoger entre otros: o El vendedor Proveedor Tienda Vendedor Pedir a enva el pedido a un puesto de entrega de Producto Almacn una tienda o al almacn Se sirve desde central y all Puesto se espabilan. Se apoya en Escogemos como criterio Tienda Central en nuestro diseo 1+ 1+ enviarlos al Captura Cobro Entrega Est en almacn 1+ Se repone de central. o El vendedor tiene un criterio, parecido al de apoyo entre tiendas, que distribuye el pedido entre los almacenes adecuados. Es un caso particular del general en el cual la tienda que representa el vendedor mvil no tiene nada de stock.
Figura Figura 2 2
-7-
Todo junto lleva a proponer el modelo de objetos para la tienda que se presenta en la figura 2. Estudiamos a continuacin el modelo de objetos que caracteriza el circuito de ventas a cliente incluyendo lo necesario para seguir el stock en el almacn. El resultado se muestra en la figura 3. Observemos que el stock depende del almacn y que el producto ocupa una situacin fsica diferente dentro de cada almacn.
Venta Jornada
Es de
Cliente
Pertenece a Ped.Venda Hecha por

1+
Vendedor
Almacn
Transportista
Lnea Ped
Servido desde
Tienda
Central
Incluye
Producto
Tiene stock stock

localizacin fsica
Analicemos ahora el modelo de datos creado por los empleados de la compaa. Ligados al subsistema que estamos creando tenemos los siguientes empleados: Cajero. Vendedor mvil. Vendedor de tienda, que trabaja en el puesto de captura de pedidos Almacenero.
Figura Figura 3. 3.
En funcin de su gestin puede proponerse el siguiente modelo de objetos para esta parte de la aplicacin:
Unidad Venta
Operador
Puesto
Mvil
Fijo
Vendedor
Almacenero
Cajero
Asignada a
1+ Captura Cobro
Arqueo
Caixa
Cobra en
Entrega De Tienda Registro de pedidos Mvil
Vende a
Trabaja en
Almacn
Anotaciones
Figura Figura 4. 4.
-8-
El modelo de objetos de compras nos lleva al resultado de la figura 5. Hemos vuelto a incluir la relacin Pedir a detectada en el modelo de venta ya que afecta tambin a las compras. Adelantemos que la relacin precio ser la entidad que nos dar la relacin de que productos nos vende cada proveedor.
Proveedor Pertenece a Ped.Compra
Tienda
Pedir a Precio
Lo fabrica
1+
Lnea Pedido
Transportista
Producto
Incluye
Figura Figura 5. 5.
2. Identificacin de Atributos.
Deberamos incluir ahora los atributos de cada clase y en particular los que estan dirctamente relacionados con el problema como por ejemplo
Atributo NIF/DNI. Stock real. Stock disponible. Stock reservado. Stock mnimo. Stock en transito Stock futuro Cantidad a pedir. Arqueo de caja Estado jornada Clase Analtica Relacin Stock Campo calculado Relacin Stock Relacin Stock Relacin Stock Relacin Stock Relacin Stock Arqueo Jornada
No lo voy a hacer ya que mi objetivo no es anlisis de datos. De los campos que necesitar ir hablando a lo largo del ejercicio. Dejo a voluntad de lector la posibilidad de crear un diccionario de conceptos y completar esta parte del modelo de datos no condicionante a la hora de definir la arquitectura del sistema distribuido.
-9-
DISEO FUNCIONAL
1. Visin general.
El sistema de informacin a crear puede representarse a nivel superior por el DFD de la figura 10. Aplicando anlisis descendente el sistema puede dividirse en dos subsistemas independientes, el de Gestin de Stock y el de Ventas a Clientes tal como se muestra en la figura 11.
Productos por proveedor Proveedores Vendedor Jornada

Proveedor
Posicin productos en almacn Productos Jornada

Proveedor
Productos
Posicin productos en almacn Transportista
Vendedor
Fecha y hora de referencia
Gestin Stock Stock Arqueo Proveedores
Stock Arqueo S.I. Venta Venta
Cliente
Cliente
Venta Clientes Venta Clientes Resumen Ventas Arqueo Cajero Recibo Pedido
Clientes Resumen Ventas Arqueo Cajero Recibo Pedido
Figura 10
Figura Figura 11 11
El subsistema de Gestin de Stock se encargar de mantener el stock de las tiendas ya sea por compra directa o por reposicin desde el almacn central, las compras desde el almacn central y de intercambiar pedidos con los proveedores. El de ventas se encarga de la gestin de la venta directa a clientes desde la captura del pedido a la entrega del material.
2. Modulo de Stock.
Entremos a analizar el subsistema de gestin de stock. Podemos subdividirlo en dos partes tal como se muestra en la figura 20: Reposicin de stock de las tiendas desde el almacn central. Compras a proveedores que se utilizar tanto en la tienda como en el almacn central.
El proceso de reposicin del stock de las tiendas a partir del almacn central tiene dos partes separadas una en la tienda y otra en el almacn central. Observemos que el proceso de stock en la tienda usar el proceso de compra y la parte de la tienda del de reposicin.
-10-
La relacin de material a pedir por la tienda se obtendr en funcin del stock mnimo. El material a reponer, y a partir de la relacin tienda, producto, proveedor. se separar en dos bloques: Pedidos a proveedores que se debern servir directamente en la tienda Reposicin a pedir al almacn central.
Productos por tienda
Criterio de reposicin de stock
Posicin productos en almacn Productos
Proveedor
Stock
Comanda Compra Material a Reposar Reposicin a Tienda Reposicin des de M. Central Material Repuesto
Pedido Proveedor
Compras
Proveedores Los pedidos a proveedores en la tienda se tratarn Productos por proveedor bsicamente igual que en el caso del Figura Figura 20. 20. Proceso Proceso de de Gestin Gestin de de Stock Stock almacn central por lo que se analizarn conjuntamente ms adelante.
En el proceso de reposicin desde el almacn central, haremos que la relacin de material a reponer en la tienda se enve por comunicaciones al almacn central. All se acumularn todas las peticiones de todas las tiendas para gestionarlas despus conjuntamente. En el almacn central existir un proceso que generar la relacin de material a enviar a cada tienda acumulando los pedidos de reposicin de todas las tiendas.
Para no complicar el proceso supondremos que el almacn central puede servir siempre todo el gnero que se le pida. En caso contrario habra que hacer un prorrateo que nos obligara a trabajar con la entidad albarn (recuerde que hemos decidido no hacerlo) y que en cualquier caso no nos afectara a la arquitectura distribuida que es el objeto bsico del ejercicio.
El proceso de preparacin ser el siguiente: Acumulacin, como ya se ha dicho, de todo el material a preparar para su retirada del almacn en el mnimo de pasos posibles. Para ello, el material a retirar: o Se acumular agrupando todas las cantidades de producto de todos los albaranes a servir en una nica lnea por cdigo de producto y a partir del cual se retirar el gnero del almacn. o Se organizar una ruta de recorrido ptimo por el almacn en funcin de la situacin fsica de cada producto. El almacn se recorrer con un dispositivo mvil en el que se ir marcando la ruta seguida obligando a confirmar que se ha realizado la retirada del gnero. El material retirado se ir cargando en un dispositivo fsico, una carretilla por ejemplo, que har de almacenaje intermedio.
-11-
Una vez recorrido el almacn o llenada de gnero la carretilla, se trasladar a una zona del almacn dedicada a preparar la salida donde habr una zona dedicada a cada tienda. All se repartir el gnero retirado por cada una de las tiendas que lo han pedido. Si la vuelta al punto de separacin por tienda se ha debido a que se haba llenado la carretilla, la ruta se reiniciar donde se haba dejado, repitiendo el proceso hasta finalizar toda la retirada del gnero a enviar. De esta forma, una vez retirado todo el gnero del almacn, y salvo el proceso de confirmacin que propondremos ahora, estar repartido en el espacio fsico de cada tienda segn sus pedidos. A continuacin, y tienda a tienda, se recuperarn todas las lneas del pedido sobre la pantalla de un PC. El PC se colocar sobre una mesa mvil que permita acercarlo a la zona de cada tienda, probablemente con conexin inalmbrica, y se prepararn los bultos siguiendo la siguiente operativa: o A cada bulto se le asignar una referencia dentro del albarn de envo. o Se ir leyendo el gnero por su cdigo de barras y colocndolo dentro del bulto. A medida que se va leyendo cada cdigo de barras, a la lnea del producto afectada se ir rebajando la cantidad de la pantalla de forma que cuando toda la cantidad de un producto se haya introducido la lnea desaparecer. o Cuando el bulto este completo se cerrar y precintar listndose una etiqueta de cdigo de barras para el bulto y pegndose a ese bulto. La referencia el bulto puede ser la del albarn y un nmero secuencial dentro de l. o El proceso se repetir hasta acabar con el pedido de esa tienda. Si sobra gnero se apartar ya que es probable que sea de otra tienda y que nos hayamos equivocado al hacer la distribucin fsica. Si falta gnero se mirar en los sobrantes de otras tiendas y si todava falta se ir a buscarlo dentro del almacn. o El proceso se repetir para todas las tiendas. El gnero que sobra al final se devolver al almacn. Finalmente se prepararn para cada transportista: o La relacin de bultos a entregar en cada tienda. o Los albaranes de transporte con la relacin de bultos. Estos albaranes servirn nicamente para el control del transportista ya que todo el circuito ser controlado por el proceso distribuido. Se enviar confirmacin a la tienda del pedido que se enva traspasndole el albarn electrnicamente. El stock se colocar en transito para rebajarlo del stock disponible en el almacn central y esperar su confirmacin a la llegada y aceptacin por la tienda. El stock en trnsito pertenecer, pues, al almacn de salida hasta que no se acepte en destino.
A la llegada del material a la tienda: Se recuperar el albarn recibido anteriormente desde la central por comunicaciones sobre una pantalla del PC que atienda el almacn. La confirmacin ser de los bultos. Para ello, se leern los cdigos de barras de los bultos recibidos con un proceso visual en la pantalla parecido al de salida de almacn verificando que han llegado todos los bultos. Si falta alguno se marcar en el albarn.
-12-
Todo el gnero recibido se dar de alta en el stock de la tienda sin ms comprobaciones ya que se supone que los bultos no se han manipulado. Si un bulto estuviera abierto se comprobarn el gnero interno a travs de su cdigo de barras. Para ello el programa ha de dar la facilidad de poder obtener los productos incluidos en cada bulto para verificar sobre ellos. Se enviar el pedido aceptado a la central para que rebaje el stock. Si hubiera faltado algn bulto o producto, los productos afectados se volvern a dar de alta en el almacn central, quedando fuera del proceso que diseamos la investigacin de las causas que han motivado la perdida del / de los bultos afectados.
El circuito se muestra en los siguientes diagramas. El primero corresponde a la parte del proceso de reposicin de la tienda y se muestra en la figura 21
Stock
Productos por tienda Productos a pedir
Necesidades de compras
Seleccin material a reponer
Separar Compras y Reposicin
Compras Envo al Almacn Central
Material a Reponer Productos Registro en stock

Validacin recepcin reposicin
Albarn
Modificacin de stock
Incidencias
Figura Figura 21. 21. Reposicin Reposicin en en la la tienda tienda

Peticiones Pendientes Productos Posicin productos en almacn Material a Reponer Transportistas Acumulacin a Pendientes Stock Albarn transportista Relacin para transportista Etiquetas Preparar Envo Albarn
El segundo diagrama corresponde a la parte de la central y se muestra en la figura 22
Figura Figura 22. 22. Reposicin Reposicin desde desde almacn almacn central central
-13-
Aplicando anlisis descendente al proceso de preparar envo obtendremos el esquema de detalle de este proceso que se muestra en la figura 22a.
Peticiones Pendientes Posicin Productos Etiquetas
Obtencin de las rutas en almacn
Seguimiento de la ruta
Albarn Preparar bultos
Rutas de retirada
Impresin albaranes
Albarn transportista
Envo a la tienda
Actualizacin stock
Lista de envo
Relacin para transportista
Stock
Transportistas
Figura Figura 22a. 22a. Preparacin Preparacin del del envo envo
Finalmente, y siempre dentro del circuito de stock, hay que analizar el proceso de compras. La parte que estamos diseando se encarga solo del proceso de compras en si, traducido en el control de pedidos y albaranes, delegando al proceso contable la gestin de la factura, tanto de la conformacin contra los albaranes vlidados como la parte administrativa y de cobro. Con este objetivo, una vez conformados los albaranes, se integrarn en la aplicacin contable. El proceso resultante se muestra en la figura 23.
-14-
Productos Necesidades de Compra Proveedor
Obtencin Fechas de llegada Pedido Compra
Proveedor
Generacin pedido Pedidos Pendientes Stock
Envo al proveedor Albarn Proveedor
Registro compra Interfcie contable Entrega Validada
Recepcin Validacin recepcin Incidencias
Figura Figura 23. 23. Proceso Proceso de de Compras Compras

Se prevee intercambiar documentos electrnicamente con el proveedor, siempre que sea posible. Adems se quiere, si el proveedor da ese servicio, saber cuando recibiremos realmente el genero. Con la informacin sumistrada por este servicio, si se dispone de l, mantendremos el stock futuro, ligado a una fecha, y que se obtendr sumando al disponible actual la cantidad que se recibir ese da. Como estamos con un objetivo docente, no incluimos funcionalidad para la resolucin de las incidencias en la recepcin. El proceso de compras desde el almacn central usar este proceso general aadiendo la seleccin de los productos a comprar y un proceso para verificar la recepcin del material pedido y faciliar la entrada fsica en el almacn: Una vez aceptado y validado el gnero por el proceso de compras, se generarn las rutas de movimiento para situar el gnero en el almacn. Los citerios se encapsularn en una pieza que dejamos fuera del diseo que estamos realizando. Con estas rutas se iran cargando las carretillas. Cada vez que se llega a una posicin se comprobar que el genero que toca dejar se saca correctamente de la carretilla. Si tenemos un dispositivo mvil con lector de cdigo de barras se leer el cdigo de barras del gnero y del puesto de almacn donde se va a dejar. Si no es as, el cdigo de barras y la posicin del almacn se registrarn a mano sobre el disposivo mvil. La perdida de tiempo se considera necesaria para garantirzar la fiabiliadad de todo el circuito de localizacin de stock en los procesos de reposicin que hemos estudiado.
El esquema del proceso resultante se muestra en la figura 23a.
-15-
Productos Productos por proveedor Necesidades de Compra Proveedor Pedido Compra
Proveedor
Albarn Proveedor Seleccin compras a realizar Compras
Stock Ruta entrada

Criterios para situar el stock en el almacn
Ruta de entrada
Seguimiento de la ruta de entrada
Figura Figura 23a. 23a. Proceso Proceso de de Compras Compras en en la la Central Central
3. Modulo de Ventas.
Abordemos ahora el diseo del proceso de Venta a Cliente. Las ventas se agrupan por jornada a partir de todos los pedidos realizados en un da de venta. Este hecho es habitual para permitir el cuadre de los datos de venta, personal, caja, etc. de la tienda a nivel de jornada de trabajo. As, la jornada se convierte en el punto de focalizacin del diseo de esta parte de la aplicacin. Podemos, pues, aplicar anlisis descendente y hacer un primer nivel de diseo que se muestra en la figura 40. Toda la accin de venta se condicionar a que haya una jornada de ventas abierta. El final de jornada generar el resumen de ventas para el informe contable diario de la tienda, pondr el estado de la jornada a cerrado y enviar a la central la venta del da donde las aplicaciones corporativas ya existentes recogern el interfase y lo incorporarn en sus sistemas de informacin.
Jornada
Cliente
Productos
Stock Aqueo
Vendedores Inicio Jornada Proceso de Venta
Final Jornada
Clientes Arqueo Cajero Recibo
Venda Albarn Resumen Ventas
Figura Figura 40. 40. Proceso Proceso de de Venta Venta

-16-
Aparecen as unos procesos de apertura y cierre de jornada que en una primera aproximacin tienen la funcionalidad que se muestra en las figuras 41 y 42.
Jornada Fecha y hora de referencia
Responsable
Arqueo
Venta Tienda
Sincronizar fecha y hora
Creacin Apunte Jornada
Creacin Venta Jornada Poner Estado de Cerrado Listado Resumen de Ventas Envo de Ventas a Central Recepcin Ventas en Central Interfases con los otros SI
Responsable Tienda
Jornada
Venta Resumen Ventas Venta Central
Figura Figura 41. 41. Proceso Proceso de de Inicio Inicio de de Jornada Jornada
Figura Figura 42. 42. Proceso Proceso de de Cierre Cierre de de Jornada Jornada
Diferenciaremos a partir de ahora la copia de ventas de la central, representado por el interfase, de las ventas de la tienda en la base de datos de la tienda. Como unidad de diseo de la Gestin de la Venta puede cogerse la entrada de un pedido. Si lo hacemos as, aplicando anlisis descendente podemos dividir el proceso como se muestra en la figura 43.
Jornada Operadores
Arqueo
Si cajero
Apertura del puesto
Cliente
Venta por pedido Productos
Cierre del puesto
Si cajero
Operador
Clientes Vendedores Recibo Albarn
Stock Arqueo cajero
Figura Figura 43. 43. Proceso Proceso de de Venta Venta a a Clientes Clientes
En la apertura de los puestos de trabajo diferenciaremos tres tipos de operadores que resuelven los tres tipos de trabajos: Captura de pedidos donde trabaja el vendedor de la tienda.
-17-
Cajero. Almacenero.
Este hecho motiva que de facto haya tres especializaciones del proceso de Venta a Clientes para cada uno de estas funciones. En la figura 43a se muestra la correspondiente al puesto de captura de pedidos atendido por un vendedor. El proceso de trabajo ser: El responsable del local autorizar la jornada de trabajo realizando la apertura de puesto. Cuando cada vendedor inicie sesin se autentificar contra la tabla de Operadores. Realizar su turno de trabajo. Cuando acabe su turno acabar sesin. Al final de la jornada, el responsable del local cerrar el puesto para evitar que nadie ms trabaje sin autorizacin.
Jornada
Responsable
Responsable
Operadores
Apertura del puesto
Autentificacin Vendedor
Captacin de pedido
Salida Vendedor
Cierre del puesto
Productos
Vendedor Cliente
Stock Vendedores Albarn
Clientes
Figura Figura 43a. 43a. Proceso Proceso Puesto Puesto de de Captura Captura de de Pedidos Pedidos
La especializacin para el puesto de cobro se muestra en la figura 43b.
-18-
Jornada Operadores
Arqueo
Apertura del puesto
Autentificacin Cajero
Proceso de cobro
Salida de Cajero
Proceso de arqueo
Cierre del puesto
Responsable
Cliente
Recibo Arqueo cajero
Responsable
Cajero
Figura Figura 43b. 43b. Puesto Puesto de de Cobro Cobro a a Clientes Clientes
El proceso de la apertura de caja genera la informacin necesaria dentro de la entidad de arqueo para conseguir, con las anotaciones posteriores del cobro de las ventas, el listado de arqueo. Este listado servir, a travs de la firma de los cajeros (autentificacin) que entran y salen para el traspaso de la caja entre ellos. El ltimo cajero entrega la caja al responsable de la tienda y el primero la recibe de l. Otro sistema que tambin se usa habitualmente es que cada cajero reciba la caja y la liquide directamente con el responsable de tienda. En este caso, y para permitir el cambio de caja en caliente, a cada puesto de venta hay que poder asignarle diferentes cajones que se asignarn a cada operador y que se liquidarn como unidad de arqueo independiente. Ninguna de las dos vara sustancialmente la arquitectura del sistema distribuido. El proceso de trabajo ser: El responsable del local autorizar la jornada de trabajo realizando la apertura de puesto. Cuando cada vendedor inicie sesin se autentificar contra la tabla de Operadores. Realizar su turno de trabajo. Cuando acabe su turno acabar sesin. Arquear su cajn y registrar el arqueo real en el ordenador. Al final de la jornada, el responsable del local cerrar el puesto para evitar que nadie ms trabaje sin autorizacin.
-19-
Finalmente la especializacin del puesto de entrega del material se muestra en la figura 43c.
Jornada
Responsable
Responsable
Operadores
Apertura del puesto
Autentificacin Almacenero
Venta por pedido
Salida Almacenero
Cierre del puesto
Productos
Almacenero Cliente
Stock Albarn
Figura Figura 43c. 43c. Proceso Proceso Entrega Entrega del del Material Material
La forma de trabajar igual que en los casos anteriores por lo que no introducimos ninguna descripcin adicional. Abordemos ahora el diseo del proceso de Venta por Pedido. Aplicando anlisis descendente podemos dividirlo en los bloques que se muestran en la figura 44.
Cliente
Pedido (material desde otras tiendas Albarn Entrega del Material
Vendedores Productos Stock Jornada
Notificacin a las tiendas
Captacin de pedido
Proceso de cobro
Acumulacin a las ventas
Arqueo Clientes Venda Pedido Recibo
Figura Figura 44. 44. Proceso Proceso de de venta venta de de un un pedido pedido
@EMG/10 - Enric Martnez Gomriz -20-
Observe que los procesos de Captacin de Pedidos, Proceso de Cobro y Entrega del Material ya han aparecido en las especializaciones anteriores del proceso de Venta a Clientes.
El albarn se generar en el momento de la captura y registro del pedido de forma que servir como documento de circulacin del cliente por el puesto de cobro y por el puesto de entrega de material. Recordemos una vez ms que, para simplificar el ejemplo, hemos supuesto que un pedido es un albarn. Este albarn tendr marcado que productos entrega la tienda y cuales se enviarn posteriormente al cliente. En el puesto de cobro se colocar una marca de cobrado cuando el cajero cobre al cliente y una de entregado en el puesto de entrega del material cuando el cliente reciba el gnero. Como el proceso de localizacin del material puede motivar que parte de ese gnero puede entregarse desde otras tiendas, hay que disear un proceso nuevo en las tiendas para que reciba los pedidos que ha de preparar para las otras tiendas y los incorpore en su proceso normal de preparacin del material. La forma de gestionar la preparacin de estos pedidos por el almacenero puede hacerse de varias formas: En los tiempos muertos de las entregas de la propia tienda marcando prioridades entre los pedidos de la propios y externos. Es el que nos piden en la especificacin. Al final de la jornada, siguiendo un proceso parecido al de reposicin de tiendas que se ha explicado antes.
En cualquier caso
acabar generando paquetes y albaranes de entrega que se distribuirn normalmente por mensajeros, que codificaremos como un transportista ms. El proceso para la entrega del material se muestra en la figura 45. El programa para la preparacin del material mostrar sobre una pantalla en el almacn los
Cliente
Albaran
Impresin Albarn Material desde las otras tiendas Preparacin del Material
Albarn
Relacin Mensajero
Incorporacin a pedidos propios
Registro para el mensajero
Impresin relacin mensajero
Entregas por transportista Pedidos
Figura Figura 45. 45. Proceso Proceso de de entrega entrega del del material material
-21-
pedidos pendientes de entregar con actualizacin permanente de los nuevos pedidos que se van registrando. El almacenero escoger uno de esa lista y podr imprimirlo incluyendo la posicin en el almacn del gnero que ha de retirar. Este sistema permitir que varios almaceneros puedan trabajar simultneamente en momento de punta. Tambin pude pensarse, en tiendas grandes, en un proceso de PDAs parecido al de retirada de gnero del almacn central. Una vez retirado el gnero del almacn, se validar con el cdigo de barras. Este proceso es el mismo que en el caso de preparacin de envos de reposicin para tiendas excepto que el mbito de seleccin es de un solo albarn. Utilizar el mismo criterio tiene la ventaja adicional que en tiendas de mucha venta o en momentos de mucho trabajo se podr utilizar la opcin para la retirada de almacn de ms de un pedido a la vez tal como se hace en el proceso de reposicin desde el almacn central. Obviamente, no realizamos anlisis descendente de este proceso ya que bastara incluir como piezas las funciones del proceso de Preparacin de Envo que hemos visto antes: Obtencin de las rutas de los almacenes. Seguimiento de la ruta. Preparar bultos
El proceso de captura de pedidos puede diferenciarse, como se muestra en la figura 46, en otros dos: Captacin del Cliente para el registro de los datos de cliente. Registro del Producto con las lneas de producto a suministrar.
Clientes
Cliente
Jornada
Stock
Productos
Captacin cliente
Registro de productos
Vendedor Pedido
Figura Figura 46. 46. Proceso Proceso de de Registro Registro de de Pedido Pedido
Dentro del diseo habr que tipificar al cliente. Lo apropiado sera considerar dos tipos de clientes:
-22-
Habituales, que se registrarn en una entidad persistente. Como la gestin completa de clientes dentro de un entorno distribuido se ha usado ampliamente en los ejemplos de la segunda parte, no se va a incluir aqu. El lector la puede disearla e incorporarla como un ejercicio adicional No habituales, que no se identifican y se asignan a un cliente genrico tomando como datos descriptivos el CIF y el nombre.
El proceso de registro de los datos del cliente, que de hecho incluye el inicio del pedido, puede dividirse en los procesos que se muestran en la figura 47.
Clientes Jornada
Cliente
No existe Cliente Habitual Inicio Pedido Entrada Identificacin Cliente Cliente No Habitual Vendedor Entrada Resto de Datos Consulta Datos Cliente Existe
Entrada Resto de Datos
Copiar Resta Datos a Pedido
Alta Cliente
Pedido
Figura Figura 47. 47. Proceso Proceso de de Registro Registro del del Cliente Cliente
En el proceso de inicio del pedido se tomar como vendedor el operador autentificado y se crear una cabecera de pedido con los datos de la jornada. SI el cliente ya existe se tomar el resto de sus datos de la base de datos y en, caso contrario y si se quiere registrar como habitual, se pedirn esos datos y se proceder al alta. Como ya se ha dicho antes, el anlisis detallado de estos procesos de cliente no se realiza en este ejemplo. Entramos ahora a analizar el proceso de captura de los datos de los productos donde se deber buscar ayuda en las tiendas cercanas si de un producto no se dispone de stock en la propia. El proceso puede dividirse en dos partes, el registro de los datos del producto y la localizacin de su stock. Si no hay stock en la tienda ni en las
-23-
tiendas de apoyo se avisar al cliente y se permitir continuar registrando otros productos. El la figura 48 se muestra un esquema del proceso.
Productos
Cliente
Pedido
Entrada Producto
Hay stock o queda por asignar Localizacin Stock
Aviso que no hay stock
No hay stock Stock
Figura Figura 48.Proceso 48.Proceso de de Registro Registro de de Productos Productos

Para la gestin de stock se escoger el criterio de reservar la parte comprometida a travs del uso del concepto de stock disponible. Cuando desde el puesto de entrega del Es vendedor Es material se vendedor? Almacenes entregue el de genero al cliente No es apoyo Localizar vendedor en las o al mensajero, apoyo Pedido se pasar de Hay No Hay Almacn reservado a Hay stock No hay consumido. en la
tienda? en tienda stock Cuando la venta de apoyo se est registrando en un Stock Material desde otras tiendas vendedor mvil la aplicacin Por asignar Localizado No localizado actuar asumiendo que Figura no tiene stock de Figura 49. 49. Proceso Proceso de de Localizacin Localizacin de de Stock Stock ningn producto y directamente se traspasar la entrega del gnero a las tiendas de apoyo. En rigor, y si se quiere trabajar los vendedores como clientes nmadas, cosa habitual, se habra de saltar aqu todos los procesos de asignacin de stock y montar un proceso de recogida en lote de los pedidos de los vendedores mviles que har la asignacin de stock, recurriendo a un criterio de tiendas hay Reservar Registrar
-24-
de apoyo en el caso de vendedores mviles que garantice la entrega sin rotura de stock. Un esquema de este proceso se muestra en la figura 50.
Envo de pedidos mviles Localizar en las apoyo
Almacenes de apoyo
Pedido
Notificar a la tienda de apoyo
Almacn
Stock
Figura Figura 50. 50. Asignacin Asignacin de de stock stock en en pedidos pedidos mviles mviles
-25-
ANALISIS DE DATOS
1. Arquitectura de datos.
Estableceremos tres niveles lgicos en el sistema distribuido: Host. Servidor de tienda. Puesto de trabajo, con las especializaciones: o Puesto de captacin de la venta. o Puesto de cobro. o Puesto de entrega de material.
El almacn central est directamente soportado por el Host. Los productos de la compaa son pocos y tienen mnima volatilidad. Esto hace que para minimizar transito y garantizar autonoma en la tienda, adelantando anlisis de consistencia, decidamos replicarlos por copia en el servidor de la tienda y en el puesto de captacin de la venta. Se define una agrupacin en la replica de productos incluyndose cada vez que se realiza una replicacin: Todos los productos. Los proveedores a los que la tienda debe comprar directamente. Sus relaciones proveedor-producto. Los productos-proveedor-tienda de la tienda. Los transportistas.
El stock tiene instancia en la tienda, en lo sucesivo stock de tienda, y en el almacn central, en lo sucesivo stock de la central. Queremos llevar control de todas las compras en la central por lo que los pedidos pendientes de todas las tiendas deben registrarse, adems de en estas, en la base de datos de la central. Los clientes no pueden asignarse a la tienda lo que hace que el fichero de clientes no habituales se haya de ir a buscar al Host. Se considera que un puesto de venta mvil nada ms puede actuar un vendedor. Por ese el fichero de vendedores (operadores) en esos terminales se reduce a una identificacin de personalizacin de la aplicacin cuando se configura en el PC porttil. La localizacin de la entidad de arqueo, debido a que no hay ms que un puesto de cobro, poda ser ese mismo puesto de cobro. Pero si el resumen de ventas debe ser un verdadero parte de caja los datos del arqueo debern situarse en el servidor de la tienda para poder integrarlo fcilmente con los de venta.
-26-
Y adelantando la consistencia, hemos de pensar en que pasar si se estropea el ordenador ligado al puesto de cobro. Lo normal ser que otro asuma su funcin por lo que ser de inters tambin en este sentido que los datos se siten sobre le servidor de la tienda. En funcin de todo ello la localizacin de datos ser:
Host
Clientes. Productos Referencia. Stock Central. Localizaciones en almacn central. Proveedores. Condiciones de compra. Proveedores por tienda. Pedidos de compra pendientes. Transportistas.
Servidor Tienda
Productos. Stock Tienda. Localizaciones en almacn tienda. Proveedores. Condiciones de compra. Proveedores por tienda. Pedidos pendientes compras de tienda. Transportistas. Jornada. Operadores. Arqueo. Venta.
Puesto Captacin Venta

Productos Operadores
Los vendedores mviles se tratarn al final de esta capitulo pero ya adelanto que tendrn su propio modelo de datos. Para evitar administrar base de datos en los puestos de trabajo decidimos montar los datos replicados en ellos en formato XML. No he citado aqu todo el resto de parmetros que influyen en la venta como poltica de descuentos, tipos de cobro admitidos, etc... Estos datos tambin estaran replicados en XML en el puesto ya que se necesitan para dar autonoma en caso de cada. No lo he hecho para no complicar el modelo de datos ya que pueden considerarse incluidos dentro de la agrupacin de replicacin de productos o tratarse como otra agrupacin de replicacin independiente pero que en cualquier caso actuara en todo el circuito igual que la de productos aunque, seguro, con otra poltica de replicacin.
2. Adaptacin del diseo funcional.

Aparece un proceso nuevo para la replicacin de la agrupacin de productos desde la central a la tienda. El diseo de este nuevo proceso, que llamaremos de Replicacin de la Agrupacin de Productos, se muestra en la figura 60
-27-
-ODBC
Agrupacin de productos
Replica Masiva
Peticin Tienda
Peticin de Replicacin Enviar replica al local Servidor de Correo (Central)
R
Copia de la tienda F
Entidades en la tienda Copia de la Tienda
Servidor de Correo (Local)
Carga en el local
Figura Figura 60. 60.Replicacin Replicacin de dela la Agrupacin Agrupacinde deProductos Productos
Ser necesario definir una poltica de replicacin: Iniciativa desde la tienda. Seleccin por extraccin. Modelo de transmisin de la replicacin en cascada ya que desde la central se enviar al servidor de la tienda y del servidor de la tienda a los puestos de venta Peridica semanal o a peticin si el nmero de cambios es importante. Auditoria por copia.
Para llevar la replicacin hasta el servidor de la tienda se har servir el servidor de correo. La replicacin desde all al puesto de venta se tratar ms adelante. Se proveen dos formas de lanzar la replicacin: En un proceso de replica masiva. Tienda a tienda a solicitud remota de estas: o Automticamente. o Utilizando la opcin de elegir la tienda en la replicacin masiva.
El servidor de replicacin de productos implementar esta arquitectura con las condiciones que acabamos de definir. Mirar si hay copia del fichero con la replicacin en el servidor de correo. Si la hay, situacin habitual, la cargar. Si no realizar una peticin a la central de replicacin y esperar la llegada. De esta forma, el esquema de la figura 60 evolucionar al diseo del servidor de replicacin que se muestra en la figura 60b.
-28-
Cola Peticiones Replicacin Esta la copia? Peticin Tienda
R
No Si
Peticin de Replicacin
Espera llegada
Servidor de Correo Local Copia de la Tienda
Carga en el local
Entidades en la tienda
Figura Figura 60b. 60b.Servidor Servidor de de replicacin replicacinde deproductos productos

Y la arquitectura general del proceso de replicacin ser la que se muestra en la figura 60a.
-ODBC
Agrupacin de productos Cola Peticiones Replicacin Enviar replica al local Servidor de Correo (Central)
Replica Masiva
Peticin Tienda Servidor replicacin Productos
R
Copia de la tienda F
Copia de la Tienda
Figura Figura 60a. 60a. Arquitectura Arquitectura de dela la replicacin replicacinde de productos productos
Dentro del proceso de inicio de jornada se pedir a la central si hay cambio de alguna de las entidades de la agrupacin de productos y en caso afirmativo se recoger la nueva versin. Otra opcin sera montar el servidor como un agente que adelantara la carga en la base de datos de las agrupaciones. Con lo cual lo nico que debera comprobarse, probablemente con un ticket de control, es que las copias ya han llegado.
-29-
Esta segunda opcin, en general es ms usada que la primera ya que adelanta el tiempo de carga y al estar todo en base de datos basta que los datos que dependen de fecha, como el precio de venta en un cambio de tarifa, se tomen por fecha de vigencia desde el programa de venta. La primera solucin se usa cuando no hay fechas de vigencia ligadas a las entidades, opcin que no le recomiendo. A pesar de ello, me he decidido por la primera opcin debido a que la segunda se parece mucho a otras situaciones que se van a plantear en lo largo del ejemplo. Puede desarrollarla como ejercicio adicional. Para minimizar las preguntas, se utilizar la sincronizacin de fecha y hora para preguntar si hay cambios. Con todo ello el proceso de inicio de jornada queda modificado como se muestra en la figura 41.
Servidor Replicacin productos
Tomar productos Hay nuevo fichero de productos Fecha y hora de referencia
Sincronizar Fecha y Hora
Creacin Venta Jornada
Responsable Tienda
Jornada
Venta
Figura Figura 41. 41. Proceso Proceso de de Inicio Inicio de de la la Jornada Jornada
3. Diseo de la Lgica de datos.
Identificamos en la central los servidores de Altas de Clientes, y si fuera necesario de bajas y cambios, y el de Consulta de Clientes. Decidimos separarlos por el nmero desigual de llamadas que recibirn los dos servicios y por idempotencia. Encapsulamos la gestin de stock en la tienda en dos servicios, un Servidor de Consulta de Stock y un Servidor de Modificacin de Stock, estableciendo entre ellos la habitual relacin de pre-condicin que trataremos ms adelante.
4. Los vendedores mviles.

Los vendedores mviles se comportan como clientes nmadas por lo que conviene analizarlos de forma diferenciada.
Aunque en el ejemplo hemos supuesto que no hay problemas de crdito, en los vendedores mviles conviene llevar registrado a que clientes no se puede vender, opcin que en el caso de que si hubiera control del crdito se podra usar para cerrar el paso a los clientes morosos. Como no es plan que cada vez que el vendedor mvil se conecte reciba todos los clientes definiremos una nueva entidad que llamaremos clientes no disponibles, donde se registrarn del fichero de clientes cuales son los que no se pueden vender. Montaremos un servicio muevo de Obtencin de los Clientes no Disponibles que, dado un vendedor, le enve que clientes de su zona estn en esta situacin. Este servicio deber ser llamado cada vez que el vendedor se conecte a la central para entregar pedidos. Cuando el vendedor se conecte deber consultar tambin si hay replicacin de productos disponible y tomarla en caso afirmativo. Tambin deber recoger y entregar todo aquellos que sus servidores de correo tenga para l o deban entregar a la central. Para ello utilizara la opcin de arrancada automtica del servidor de correo. Finalmente debemos hablar de la gestin de clientes en el vendedor mvil. Estamos ante un modelo de replicacin con el master en la central y foco de mantenimiento en la replica que no puede auditarse por copia ya que la ventana de conexin no lo permite y el proceso de hecho no lo necesita ya que el vendedor tiene solo en su PC los clientes de su zona. Se prev auditoria por copia cuando, en la central, se haga mantenimiento preventivo del PC una vez cada seis meses. En este caso ser importantsimo revisar el proceso de comparacin de la auditoria para analizar las diferencias. Para controlar las altas, se aadir un atributo al fichero de clientes para controlar si el cliente se ha dado de alta o modificado en la central. Cada conexin del vendedor a la central deber aprovechar para autorizar a la central. Tambin se puede aprovechar la conexin para actualizar la fecha y la hora del porttil del vendedor a travs del servidor de fecha y hora de la central. Con todo ello el proceso de la figura 50a evoluciona hasta el siguiente esquema modificado para la gestin de conexin de los vendedores mviles.
-31-
Espera Finalizacin trfico
Arrancar servidores de correo
Actualizar Fecha y Hora
Envo de pedidos mviles Pedido
Almacenes de apoyo
Hay Replicacin Productos? Si Carga en el local No
Servidor de Correo (Vendedor)
R
Servidor de fecha y hora Notificar a la tienda de apoyo Stock
Localizar en las apoyo
Enviar altas y cambios clientes
Recoger clientes no disponibles
Almacn
R
Productos local Clientes local Alta de clientes Clientes no disponibles
R
Obtencin Clientes no Disponibles
Figura Figura 50a. 50a. Gestin Gestin conexin conexin vendedores vendedores mviles mviles
Observe que el servidor de correo es llamado de forma sncrona. Con todo ello, conviene diferenciar al vendedor en el modelo de datos distribuidos que se muestra a la derecha. Observe que, adems de la entidad de clientes no disponibles debern colocarse todas aquellas necesarias para el proceso de venta ya que el PC del vendedor mvil adems del papel de puesto de venta debe asumir el de servidor de tienda en todas las funciones necesarias para la venta.
Vendedor Mvil
Productos. Operadores (el vendedor). Clientes. Clientes no disponibles. Jornada. Arqueo. Venta.
5. Especificacin.
Dejo esta parte como ejercicio adicional para el lector.
6. Analizar rendimiento.
Obviamente esta etapa es imposible de hacer en un ejemplo de papel.
-32-
CREACIN DE LA ARQUITECTURA DISTRIBUIDA

1. Identificacin de funciones y distribucin de la funcionalidad por niveles.
Las funciones detectadas en el anlisis funcional pueden distribuirse as para identificar las de localizacin obligada y asimilarlas a servicios si han de ser utilizadas desde otros nodos.:
1. 1. Host (administracin y almacn central).

Reposicin desde el almacn central. o Acumulacin a pendientes. o Preparar envo: Obtencin de las rutas en almacn. Seguimiento de la ruta. Preparar bultos. Impresin albaranes. Impresin de la lista de envo. Actualizacin de stock. Envo a la tienda del albarn. Proceso general de compras. o Generacin de pedidos. o Envo del pedido al proveedor. o Recepcin de la compra. o Validacin de la recepcin de proveedor. o Registro de la compra o Obtencin de la fecha de llegada prevista.. Proceso de compras en la central. o Seleccin de compras a realizar por proveedor. o Ruta de entrada en el almacn. o Seguimiento de la ruta de entrada. Sincronizar fecha y hora. Final de jornada: o Recepcin de ventas desde la central. o Interfcies con el resto de Sistemas de Informacin. Alta de cliente habitual. Consulta clientes habituales.
1. 2. Servidor de la tienda.
Reposicin en la tienda. o Seleccin del material a reponer. o Separar compras y reposicin. o Envo del material a reponer al almacn central. o Validacin de la recepcin de reposicin. o Registro en stock. Proceso general de compras. o Generacin de pedidos. o Envo del pedido al proveedor.
-33-
o Registro de la compra o Obtencin de la fecha de llegada prevista.. Inicio Jornada: o Sincronizacin de fecha y hora. o Creacin del apunte de jornada. o Creacin del apunte de venta. Final de jornada. o Poner estado de jornada cerrada. o Listado del resumen de ventas. o Envo a la central. Apertura de caja. Cierre de caja. Incorporacin de ventas. Incorporacin de pedidos de otras tiendas. Proceso de localizacin de stock. o Localizacin segn que el vendedor sea mvil o no. o Localizacin en el stock propio. o Reserva de stock. o Obtencin de los almacenes de apoyo. o Peticin de las tiendas de apoyo. o Localizacin del stock en los almacenes de apoyo.
1. 3. Todos los puestos.

Inicio jornada. o Sincronizacin de fecha y hora. Autentificacin Operador. Salida Operador. Cierre de jornada
1. 4. Puesto de almacn.
Proceso general de compras. o Recepcin de la compra. o Validacin de la recepcin de proveedor. Entrega de material de la propia tienda. Preparacin de los envos a cargo de otras tiendas. o Preparacin del material. o Impresin de albarn. o Registro para el mensajero. o Impresin de la relacin por mensajeros.
1. 5. Puesto de venta.
Captacin del cliente. o Inicio pedido. o Entrada de la identificacin de cliente. o Consulta de los datos del cliente. o Entrada del resto de datos del cliente. o Copiar el resto de datos de cliente en el pedido. o Alta de clientes. Captura de productos: o Entrada de productos. o Aviso de que no hay stock.
-34-
1. 6. Puesto de Cobro.
Apertura de caja. Proceso de cobro. Cierre de caja. Proceso de Arqueo o Obtencin del listado de caja. o Entrar arqueo real.
1. 7. Funciones especificas de los vendedores mviles.

Envo por lotes de los pedidos. Arranque automtico del servidor de correo. Recogida de los clientes no disponibles.
2. Separar funciones e identificacin de servicios en el entorno de stock.

Analizando los procesos localizados en el HOST, en la figura 22 donde se refleja el proceso de reposicin desde almacn central identificamos el Servicio de Recepcin de Reposicin al que llaman las tiendas cuando lo necesiten. El servici recibir la entidad material a reponer El Servicio de Peticin de Reposicin ser llamado de forma indirecta por las tiendas mediante el servidor de correo. Este montaje permitir un funcionamiento desacoplado entre peticiones y proceso de acumulacin. Por esa razn se implementar como un agente con el diseo que se muestra en la figura 16. El diseo de este agente ser de viga sobre el buzn del servidor de correo de la central lanzando como disparador la acumulacin a pendientes. Las dos funciones de extraccin y acumulacin a pendientes se podran montar como un cliente back-ground en un hilo dentro del agente lo que permitira atender a varios locales simultneamente.
Material a Reponer
Peticiones Pendientes
R
F
Servidor de Correo (Central)

Si
Extraccin M
Acumulacin a Pendientes
Modificar Ticket
Ha llegado algo?
No
Tiendas Recibidas
Sleep
Figura Figura16. 16.Agente Agente de deRecepcin RecepcinReposicin Reposicin desde desdeTiendas Tiendas
Aadimos adems un ticket multihilo de reposiciones recibidas para conocer las tiendas de las que ya se ha recibido la peticin de reposicin. De esta forma podemos ligar al ticket procesos automticos o semiautomticos de control y administracin: reclamar a partir de usa hora los que no han llegado, revisar su estado de conexin, etc..
-35-
Observe que hay otra forma de implementar el Servicio de Reposicin que es eliminarlo como agente e incorporarlo como primer paso del proceso de separar la reposicin por rutas de retirada de almacn. Sin embargo, en este caso no se podran incorporar los procesos automticos de control tan fcilmente. Si observamos la figura 22a, donde se presenta la preparacin del envo de reposicin el proceso de comunicar los albaranes a la tienda, identificamos la necesidad un Servici de Envi de la Reposicin atacando directamente el directorio remoto con filosofa de envo PUSH al disponer la central de un ancho de banda importante. Obviamente otra solucin vlida para este servicio es montar una arquitectura parecida al Agente de Peticin de Reposicin desde la Tienda. He elegido la opcin anterior para mostrar diferentes opciones. Revisemos ahora del proceso general de compras que se muestra en la figura 23. El intercambio de informacin con el proveedor depender del tipo de servicio o conexin que proporcione cada uno de ellos. Estamos, pues, ante un servicio con una arquitectura basada en una filosofa de pasarela. Observemos que de hecho hay tres tipos de servicios: Envo de documentos desde nuestra organizacin a proveedores. Recepcin de documentos desde proveedores. Consulta de las fechas de recepcin.
Toda la comunicacin con los proveedores se implementar en un Servicio de Integracin de Proveedores que trabajar sobre colas, con una arquitectura de delegacin con sus clientes internos y otra de distribucin con sus servicios. Aunque la decisin de la arquitectura entre todos los servicios afectados debera dejarse para la etapa de arquitectura de servicios, a efectos docentes la adelantar aqu. Obviamente, la arquitectura de la solucin propuesta depender de cada organizacin. En la figura 17 se proporciona una posible solucin en que hay tres modelos de comunicacin de los servicios proporcionados por los proveedores: mail, RPC y Web Services.
Consulta y registro manual
Agente de Consulta
P R P
Proveedor 1
Integracin proveedores
Agente de salida
P P
Proveedor 2
R P R R P M P
Obviamente, si otros proveedores Figura Figura 17. 17. Integracin Integracin con con proveedores proveedores proporcionarn otros mecanismos se integraran de la misma forma que los que hemos tomado como ejemplo.
Agente de entrada
Proveedor 3
-36-
En la solucin propuesta un agente diferente se encargar de cada servicio.
El agente de salida gestionar los envos desde el sistema distribuido a los proveedores. El agente ir revisando la cola del servicio de integracin y estableciendo las conexiones con el proveedor travs del sistema que ste proporcione. En el caso de comunicacin con el documento adjunto a un mail, generar un correo con el fichero del documento en forma adjunta. Habr de pactarse el formato. Una buena solucin es pactar una salida en XML, solucin preferente o EXCEL. Observe que no he propuesto la tradicional .TXT ya que tiene demasiadas limitaciones. El agente pasar el formato interno del pedido al pactado con el proveedor. El agente de entrada puede ser de una arquitectura master-slave, asignando un hilo para cada sistema de vigilancia asignado a un grupo de proveedores de los que se esperen cosas. El agente deber convertir el formato del pedido del proveedor al formato interno. El agente de consulta solo podr gestionar automticamente aquellos proveedores que proporcionen el servicio. Peridicamente ir lanzando el servicio y verificando las fechas de entrega. Se puede complementar para los proveedores que no den este servicio con un proceso manual que ya se a travs de la informacin disponible o por llamada telefnica al proveedor, permita que una persona actualice los plazos de entrega previstos.
Como la cola ser servicio de integracin es compartida por tres servicios diferentes las anotaciones debern hacerse con calificador. Observe que segn el tipo de comunicacin que se utilice con el proveedor, como puede ser la de mail, muy utilizada, no hay forma real de conocer si realmente el proveedor ha recibido el pedido. En estos casos, que observe que son de comunicacin desacoplada, es bueno pactar con el proveedor que nos enve un OK de aceptacin para asegurarnos que ha llegado. No lo introduzco en el esquema para no complicar ms el esquema. Observe tambin que para obtener este OK puede utilizarse el servici de recepcin de albaranes de proveedores con un formato de parmetros pactado para reconocer que es una aceptacin de pedido y no un albarn real. Con este enfoque, el proceso de obtencin de fechas de llegada lo convertimos en un servicio de Obtencin de Fechas de Llegada implementado en un agente que peridicamente interacta con el servicio de Integracin de Proveedores actualizando el stock futuro. Obsrvese que este servicio tambin admitira la implementacin como un cliente back-ground arrancado a voluntad de un operador. Me decido por la implementacin como servicio para ganar automatismo en este punto. De la misma forma, la recepcin de albaranes de compra se convierte en un servicio de Recepcin de Albaranes de Proveedores implementado tambin en un agente. Conviene darse cuenta de que estos servidores debern interactuar con el de integracin de proveedores que vamos a arrancar solo en la central. Por esa razn decidimos implementar la conexin a travs de SOAP que nos filtrar la presencia local, para el almacn central, o remota, para las tiendas, del servicio Es conveniente tener en la central la integracin de todos los documentos de la organizacin. Ello nos obliga en el caso de las compras de las tiendas a ampliar los procesos de envo y recepcin de pedidos a proveedores.
-37-
Enviar los pedidos adems de al proveedor a la central. Una vez confirmados los albaranes, enviar una copia a la central.
Si Hay Pendientes? Enva
Sleep
No
Pedidos y albaranes central
Para resolver esta necesidad, nos sale un Figura 15. 15. Agente Agente de de envo envo de de documentacin documentacin nuevo Servicio de Envo de Figura la Documentacin que se cuidar de enviar los documentos de pedidos a la central e integrarlos con los documentos de toda la organizacin. Como la iniciativa es siempre de la tienda, el proceso se trabaja con filosofa de viga. Su integracin ser de agente tal como se muestra en la figura 15. Adems del servicio de envo de documentos, examinando el proceso de compra observamos la necesidad de realizar la imputacin del albarn en la aplicacin contable. Para hacerlo se utiliza un Servicio de Envolvente de la Aplicacin Contable que permite utilizar de forma remota la funcin de contabilizacin de albaranes. Reflexionemos sobre el uso de la envolvente contable desde la tienda. Mirando la figura 18 observamos que se llama cada vez que se registra un albarn de compra. La aplicacin contable queda fuera del control de la aplicacin distribuida que estamos diseado por lo que debemos tomar precauciones para garantizar funcionamiento aunque el sistema contable no este disponible. Para conseguirlo responsabilizaremos a un Servicio de Contabilizacin de Albaranes, implementado como un agente, de asegurar el funcionamiento de forma desacoplada. En el apartado de arquitectura de servicios se muestra como interactan. Si nos fijamos en el proceso de compras de la figura 23, como el envo del pedido y registro de la compra se ha de hacer tanto en las tiendas como en la central decidimos trabajar estos procesos como Servicio de Envo de Pedidos a Proveedores y Servicio de Registro de la Compra. Se pueden montar como: Agentes. Servicios pasivos.
Escogemos la primera opcin.
3. Separar funciones e identificacin de servicios en el entorno de ventas.

Para la sincronizacin de la fecha y la hora decidimos hacer un Servicio de Fecha y Hora a dos niveles: Central, donde est la de referencia Tienda.
-38-
Como la apertura de jornada se ha de hacer desde todos los puestos de trabajo identificamos un Servicio de Apertura de Jornada que: Haga la sincronizacin de fecha y hora. Verifique que la jornada est abierta en el servidor y la inicie en el puesto de trabajo. Informe si hay variacin del fichero de productos. Informe del estado de la jornada en el servidor de la tienda.
Ataquemos ahora el proceso del puesto de entrega del material de la figura 45. Se identifica aqu un Servicio de Incorporacin a Pedidos Propios necesario para recibir las peticiones de envo del resto de las tiendas que se generan dentro del proceso de venta. Se monta como un agente que acta como un viga de un directorio donde las tiendas van a poner el fichero con la reposicin pedida. Peridicamente el agente explorar el directorio y si hay algo pendiente, se incorporar. El recurso compartido que el viga escuchar ser el buzn de llegada del servidor de correo Adems de los dos servicios de stock identificados en el anlisis de la lgica de datos, necesitamos adems un Servidor de Gestin de Stock de Apoyo con dos funciones:
Saber si hay stock. Reservarlo.
Definimos un nico servicio con las dos funciones. Consltese la arquitectura de servidores de la que se habla ms adelante para obtener ms informacin. El criterio de bsqueda en las tiendas de apoyo se toma en el ejemplo como una precondicin y se deja por lo tanto fuera del ejemplo. Le invito, sin embargo, a pensar una posible arquitectura. A poco que lo haga ver que una arquitectura de procesador distribuido aparece de forma muy natural. Analizando el envo de pedidos en los vendedores mviles para la asignacin de stock observamos que necesitamos un Servicio de Asignacin de Stock a Pedidos Mviles que se detallar en el aparatado de arquitectura de servicios.
4. Definir la comunicacin cliente / servidor.

Dejo esta parte como ejercicio adicional al lector.
5. Definicin de la arquitectura de servidores en el entorno de stock.

La arquitectura entre todos los servicios afectados por la integracin de proveedores ya se ha mostrado al presentar el servicio. Analicemos ahora la arquitectura entre el Servicio de Contabilizacin de Albaranes y el Servicio de Envolvente Contable. Suponemos que el Servicio de Envolvente Contable se suministra sncrono y a travs de SOAP.
-39-
El Servicio de Contabilizacin se pedir de forma desacoplada a travs de una cola. Se implementar con un agente que ir explorando esa cola y llamar de forma remota al servicio de envolvente contable. La arquitectura resultante se muestra en la figura 19a, donde se muestra a la derecha el diseo interno del servicio de contabilizacin.
Interfcie contable Servicio contabilizacin de albaranes Hay Pendientes?
Si Enva
R
Sleep Envolvente Contable Sistema Contable Envolvente Contable No
Figura Figura 19a. 19a. Arquitectura Arquitectura contable contable

La arquitectura del servicio de Envo de Pedidos a Proveedores y los servicios que utiliza se muestra en la figura 18.
Pedidos Pendientes Tienda
Pedido Compra
Modificacin Pedidos Pendientes Local
Modificacin Pedidos Pendientes Central

F
Lanzamiento a proveedor
F
Pedido Compra Servicio de envo de documentos
Figura Figura 18. 18. Envo Envo de de Pedido Pedido a a Proveedor Proveedor
La arquitectura entre el servicio de Registro de la Compra y los servicios que utiliza se muestra en la figura 19
-40-
Pedidos Pendientes Tienda
Albarn Proveedor
Stock local
Modificacin Pedidos Pendientes Local
Modificacin Pedidos Pendientes Central

F
Imputacin Stock
Imputacin Contable
F
Albarn validado Entrega Validada Servicio de envo de documentos
Interfcie contable Servicio contabilizacin de albaranes
Figura Figura 19. 19. Registro Registro Compra Compra

La arquitectura entre del servio de envo al almacn central desde la tienda de la reposicin diaria se muestra en la figura 14.
Envo al Almacn Central F
Peticin de Reposicin
Figura Figura 14. 14. Arquitectura Arquitectura del del envo envo de de la la reposicin reposicin
Fecha y Hora de referencia
Hay cambio de productos
Jornada
Servidor de Fecha y Hora (Central)
Servidor de Fecha y Hora (Tienda)
Servidor de apertura de Jornada
6. Definicin de la arquitectura de
Hay cambio de productos Fecha y Hora
-41Figura Figura61. 61.Servidores Servidores de de Fecha Fecha y yHora Hora y yde de Apertura Apertura
servidores en el entorno de ventas.

Veamos la arquitectura entre los Servicios de Fecha y Hora y el de Apertura de Jornada. Recordemos que con anterioridad hemos decidido que el servidor de la central ha de informar cuando es llamado de la existencia de una nueva versin de la agrupacin de replicacin ligada al producto. La instancia del servicio de la tienda se localizar a nivel lgico en el servidor de la tienda desde donde lo pedirn el resto de programas cliente. La arquitectura resultante se muestra en la figura 61. Escogemos la comunicacin RPC para conseguir una mejor sincronizacin de la fecha y la hora evitando demoras. La arquitectura entre el servicio de correo y el de incorporacin de pedidos propios se muestra en la figura 45 a.
F Material desde las otras tiendas Incorporacin a Pedidos Propios
Pedidos
Figura Figura 45a. 45a. Incorporacin Incorporacin a a Pedidos Pedidos Propios Propios
Entramos ahora a gestionar el proceso de localizacin de stock. Necesitamos un Servidor de Gestin de Stock de Apoyo con dos funciones:
Saber si hay stock. Reservarlo.
Definimos un nico servicio con las dos funciones, En la figura 62 se muestra un esquema de este servidor.
-42-
Producto a localizar y cantidad
Hay Stock? No hay
Hay Stock
Reservar stock
Pre-C
Consulta Stock Actualizacin Stock
No localizado
Localizado
Figura Figura 62. 62. Servidor Servidor Gestin Gestin de de Stock Stock de de Apoyo Apoyo
La arquitectura del servicio de asignacin de stock a pedidos de los vendedores mviles se muestra en la figura 50b.
Extraccin
R
F
Servidor de Correo (Central) Si Ha llegado algo? No Sleep
Almacenes de apoyo
Pedido Notificar a la tienda de apoyo
Almacn
Figura Figura 50b. 50b. Agente Agente de de stock stock en en pedidos pedidos mviles mviles
Su arquitectura es muy parecida a la de recepcin de la peticin de reposicin por lo que no necesita ninguna explicacin adicional. El agente se localizar en el servidor de la central, comunicndose desde all a las tiendas implicadas en el envo.
7. La opcin de utilizar el procesador distribuido.

Existe otra posibilidad de abordar la arquitectura de este ejercicio, responsabilizando de todos o parte de los servicios desacoplados internos a la compaa a un procesador distribuido.
-43-
Los servicios sern los mismos pero suministrados por el procesador y no por los agentes. He optado por la solucin de agentes por que es docentemente ms clara al quedar mucho mas visibles los servicios. Puede hacerlo como ejercicio adicional. Ver, curiosamente, que no cambia mucho la arquitectura resultante.
8. Definicin de la arquitectura distribuida en el entorno de stock.

Si sustituimos el servidor de Peticin de Reposicin en la figura 22 obtenemos la arquitectura modificada de la figura.
Peticiones Pendientes Productos Material a Reponer Posicin productos en almacn
Peticin de Reposicin Preparar Envo Stock Albarn transportista Relacin para transportista
Transportistas
Albarn
Etiquetas
Realicemos ahora la arquitectura distribuida del Proceso de Preparacin de Envo de la figura 22a en el que se incorpora el Servicio de Envo de la Reposicin.
-44-
Posicin Productos
Etiquetas
Albarn
Preparar bultos
Rutas de retirada Servicio de envo de la reposicin
Impresin albaranes
Envo a la tienda
Actualizacin stock
Lista de envo
Albarn
Stock
Transportistas
Observemos que el Seguimiento de la Ruta se ha convertido en un cliente background que interacta con un componte de presentacin implementado en una PDA. Para dar posibilidad que ms de un almacenero siga la ruta simultneamente, programa se disea con la arquitectura master-slave de la figura 22b. La autentificacin desde el componente de presentacin pedir la posicin de la ruta donde que se quiere empezar la gestin
Autentificacin
C I Seguimiento Ruta D Rutas de retirada
Ruta
Trabajo
D D D I
M
I
I I
Servidor
de trabajo
Figura Figura 22b. 22b. Seguimiento Seguimiento Ruta Ruta

La arquitectura del Proceso de Compra con todos los servicios se muestra el esquema modificado de la figura 23.
-45-
Productos Necesidades de Compra Proveedor
Obtencin Fecha de Llegada
Proveedor F R
Pedido Compra Generacin pedido

Llamada al envo de pedido Stock
Envo Pedido
Pedidos Pendientes
Albarn Proveedor
Registro Pedido
Llamada al registro de pedido
Recepcin Albaranes Proveedores Validacin recepcin Incidencias
Interfcie contable Entrega Validada

Finalmente se revisamos la arquitectura de el Proceso de Compras en la Central obtendremos un proceso de Seguimiento de Ruta de Entrada parecido al anterior de ruta de reposicin.
Productos Productos por proveedor Necesidades de Compra Seleccin compras a realizar Proveedor Pedido Compra
Proveedor
Compras Albarn Proveedor
Stock
Criterios para situar el stock en el almacn
Ruta entrada
Ruta de entrada
Seguimiento de la ruta de entrada
Figura Figura 23a. 23a. Proceso Proceso de de Compras Compras en en la la Central Central
Por ltimo como queda modificado el proceso de reposicin en la tienda se muestra en la figura 21.
-46-
Stock local
Productos por tienda Productos a pedir
Necesidades de compras
Compras
Productos Registro en stock
Material a Reponer Albarn

Servidor de correo (local)

R
Incidencias
Servicio de envo de la reposicin
Peticin de Reposicin

9. Definicin de la arquitectura distribuida en el entorno de ventas.
Antes de abordar este apartado hagamos una simplificacin para no hacer procesos repetitivos muy parecidos que no portaran grandes diferencias y nos obligaran a definir muchas figuras parecidas,. Como hemos visto en el anlisis los procesos de apertura y cierre del puesto y los de identificacin y salida de operador son muy parecidos para los tres tipos de puestos de trabajo. Por esa razn, vamos a realizar una propuesta generalista de este tema. En este tema, ni le recomiendo que como ejercicio adicional haga la especializacin de cada caso. Con la utilizacin de los servicios definidos. el proceso de inicio de jornada quedar modificado como se muestra en la figura 41 a. En principio se localizar en el Servidor de la Tienda. Quedar por decidir como se implementan los servicios en los puestos de trabajo.
Hay cambio de productos Servidor fecha y hora de la Central Hay nuevo fichero de productos Tomar productos
Servidor agrupacin de productos
Iniciacin
Fecha y Hora Referencia Local

Responsable Tienda
La secuencia de operacin es que la Figura Figura 41a. 41a.Inicio Iniciode deJornada Jornadaen enel el Servidor Servidorde dela la Tienda Tienda jornada se inicie primero en el servidor de la tienda y despus desde cada puesto de trabajo.
Jornada
Venta
-47-
Por esa razn, los procesos de este segundo entorno debern verificar que la jornada este abierta en el servidor. Para conseguir este objetivo, y como ya he citado al definir las funciones del servicio, aadiremos esta informacin en el mensaje de peticin del servicio de apertura de jornada. As podemos pensar en un proceso de Apertura de Puesto que: Haga la sincronizacin de fecha y hora. Verifique que la jornada est abierta en el servidor y la inicie en el puesto de trabajo. Informe si hay variacin del fichero de productos.
Para pasar la replica de productos desde el servidor de la tienda hasta los puesto de venta se utilizarn los recursos de la red. Todas las copias de los datos, como los productos necesarios para la autonoma del puesto de venta, se registrarn en XML para evitar instalar BD en los puestos cliente. Todo ello define un proceso de apertura diferenciado para el puesto de venta que se muestra en la figura 41b. Obviamente la copia de productos solo tiene sentido en los puestos de captura de pedidos.
Agrupacin de Productos en el Servidor Servidor Apertura Jornada Hay nuevo fichero de productos Coger productos
Agrupacin de Productos en el Puesto de Venta
Inicio en el puesto
Responsable Tienda/ Cajero
Jornada
Fecha y Hora Referencia Puesto de Venta
Figura Figura 41b. 41b. Inicio Inicio de de Jornada Jornada en en el el Puesto Puesto de de Venta Venta
Del proceso de cierre de jornada hay que hacer versiones diferentes especializadas en la verificacin de las condiciones de cierre de jornada de cada puesto: El puesto de venta donde habr que cerrar todas las sesiones de venta abiertas. Para el puesto de cobro donde se habrn haber cerrado y arqueado todos los cajeros. Para el puesto de entrega de material donde se comprobar que no hay pedidos propios o de otras tiendas pendientes de preparar. La Tienda. Aqu, de forma parecida a la apertura, el servidor de la tienda no podr cerrar la jornada si no se ha cerrado cada puesto de trabajo
Los procesos de apertura y cierre de los tres tipos de puestos son muy parecidos y dejo al lector como ejercicio adicional su especializacin. El control de que se han cerrado todos los puestos de trabajo en el servidor para poder hacer el cierre de jornada de la tienda se puede llevar fcilmente con un ticket de cierre con la arquitectura que se muestra en la figura 42a.
-48-
Jornada
Venta Tienda Servidor de Correo (Local) Envo Ventas a la Central
Tiquet Cierre
Arqueo
R
F
Todos Cerrados?
Si
Poner Estado Cerrado
Listado Resumen Ventas Recepcin Ventas en Ventral
No Aviso
Ventas Central Resumen Ventas Interfcies a otros S.I.
Responsable
Figura Figura 42a. 42a. Proceso Proceso de de Cierre Cierre de de la la Jornada Jornada
El proceso de cierre modificado se muestra en la figura 42b.
Jornada
Referencia Puesto
Se cumplen Condiciones Cierre?

No
Si
Poner Estado de cerrado
Informar Tiquet
Tiquet Cierre
Aviso
Operador
Figura Figura 42b. 42b. Cierre Cierre de de la la jornada jornada en en un un puesto puesto
Con todo ello, le proceso de venta a clientes quedar como se muestra en la figura 43 donde observe que solo ha sido necesario colocar el servicio de acceso SQL al servidor de datos.
-49-
Jornada Operadores
Arqueo
Si cajero
Apertura del puesto
Cliente
Venta por pedido Productos
Cierre del puesto
Si cajero
Operador
Clientes Vendedores Recibo Albarn
Stock Arqueo cajero
Figura Figura 43. 43. Proceso Proceso de de Venta Venta a a Clientes Clientes
No hace falta que pierda tiempo modificando las especializaciones que vimos en el diseo funcional. La arquitectura resultante en el proceso de entrega de material se muestra en la figura 45 modificada.
Cliente
Albaran
Impresin Albarn Material desde las otras tiendas Preparacin del Material
Albarn
Relacin Mensajero
Incorporacin a Pedidos Propios
Registro para el mensajero
Impresin relacin mensajero
Entregas por transportista Pedidos
Figura Figura 45. 45. Proceso Proceso de de entrega entrega del del material material
El proceso de venta de pedido acaba enviando el material a reponer al almacn central desde la tienda utilizando el procedimiento que acabamos de explicar. El proceso modificado se muestra en la figura 44.
-50-
Cliente
Material para otras tiendas Albarn Notificacin a las tiendas
Vendedores Productos Stock Jornada
Entrega del Material
Servidor de Correo (Local) Proceso de cobro Acumulacin a las ventas
Captacin de pedido
Arqueo Clientes Pedido Recibo
Venda
Figura Figura 44. 44. Proceso Proceso de de venta venta de de un un pedido pedido
Analicemos ahora el proceso de captura de cliente donde utilizaremos los servidores de clientes identificados en la lgica de datos modificando y en consecuencia queda como se muestra en la figura 47.
Clientes local Jornada
Cliente
Consulta Clientes
R
Cliente Habitual
Consulta Datos Cliente No existe

Existe
Entrada Resto de Datos Clientes Central
Inicio Pedido
Entrada Identificacin Cliente

Cliente No Habitual
Vendedor
Entrada Resto de Datos
Copiar Resta Datos a Pedido
Alta Cliente
R
Pedido Alta Clientes
Figura Figura 47. 47. Proceso Proceso de de Registro Registro del del Cliente Cliente
El proceso de registro de productos no necesita nada ms que incorporar los accesos a los servicios de datos.
-51-
Productos
Cliente
Pedido
Entrada Producto
Hay stock
Localizacin Stock
Aviso que no hay stock
No hay stock Stock
Figura Figura 48.Proceso 48.Proceso de de Registro Registro de de Productos Productos

Y el proceso de localizacin de stock queda definitivamente como se muestra en la siguiente figura 49
Es vendedor Es vendedor? Almacenes de apoyo Hay No hay Reservar stock Hay en tienda de apoyo?
Por asignar No es vendedor Pedido
Hay stock en la tienda? hay
No hay
R
Gestin del del stock de apoyo
Consulta de Stock
Pre-C
Modificacin de Stock Localizado No localizado
Stock
Stock
Figura Figura 49. 49. Proceso Proceso de de Localizacin Localizacin de de Stock Stock
Finalmente el proceso de asignacin de stock a los pedidos mviles usando el servicio que hemos definido queda como se muestra en la figura 50c.
-52-
Envo de pedidos mviles
Pedido
R
F
Figura Figura 50c. 50c. Asignacin Asignacin de de stock stock en en pedidos pedidos mviles mviles
10. Map to reality.
10. 1. Localizacin.
10. 1. 1. Central. a) Almacn Central. Servidor de correo. Recepcin de la reposicin. Obtencin de fechas de llegada. Recepcin de albaranes de proveedores. Contabilizacin de albaranes. Envo de pedidos a proveedores. Registro de la compra. Consulta de stock. Modificacin de stock. Asignacin de Stock a Pedidos Mviles
b) Entorno de Administracin. Servidor de correo. Integracin de proveedores y los agentes afectados. Envolvente de la aplicacin contable. Servidor de fecha y hora de la central. Servidor de replicacin de la agrupacin de productos. Alta de clientes. Consulta de clientes. Obtencin de clientes disponibles para los vendedores mviles.
10. 1. 2. Servidor de Tienda.

-53-
Servidor de correo. Envo de la reposicin. Obtencin de fechas de llegada. Recepcin de albaranes de proveedores. Envo de la documentacin. Contabilizacin de albaranes. Envo de pedidos a proveedores. Registro de la compra. Incorporacin a pedidos propios. Servidor de fecha y hora del local. Apertura de jornada. Gestin del Stock de Apoyo. Consulta de stock. Modificacin de stock.
10. 1. 3. PC del Vendedor mvil. Servidor de correo. Servidor de fecha y hora del local. Apertura de jornada.
10. 2. Configuracin.
Como ejercicio adicional el lector puede definir las fichas de enviroment de cada servicio para poder definir la configuracin.
10. 3. Analizar Rendimiento.

Obviamente los objetivos de esta etapa no tienen sentido en un ejemplo de papel.
-54-
ANALISIS DE CONSISTENCIA
1. Utilizacin de XML.
A lo largo de este apartado, y para dar autonoma a los puesto de trabajo, vamos proponer llevar replicas en los puestos de trabajo. Para evitar administrar una BD en cada puesto, las replicas se llevarn en XML. Los logs tambin se registrarn en XML.
2. Circuito de Replicacin de Productos.

Empezaremos por tratar especficamente la replicacin de la agrupacin de productos y despus atacaremos la consistencia del resto de los servicios. Necesitamos una semntica de servidor exactly once (exactamente una vez) fcilmente administrable por los responsables de explotacin. Con este objetivo se desarrollarn dos procesos:
2. 1. Garantizar la semntica exactamente una vez.

Se definir un Ticket de Control de Replicacin que tendr dos instancias: En la Central, para control de la replicacin a las tiendas. En cada tienda para el control de la replicacin a cada una de los puesto de venta.
El criterio de gestin ser: Cuando cada copia llegue al puesto de venta, se actualizar la lnea del ticket correspondiente. Cuando todos los puestos de venta estn actualizados, se actualizar la lnea del ticket de la central correspondiente a esa tienda.
De les modificaciones pendientes se informar en el cuadro de control de administracin,
2. 2. Situacin de emergencia.
Cuando la copia falle se podr escoger entre: Trabajar con la copia anterior. Recibir las modificaciones por floppy o CD. Registrar los cambios a mano en los datos que afectan a la venta de forma ms urgente, normalmente slo los cambios de precios y altas y bajas de productos.
-55-
En cualquier caso, cuando la situacin se normalice, se realizar la actualizacin normal para asegurar los cambios. Si el problema es que desde el principio la tienda no recibe la notificacin de cambio, la notificacin se introducir manualmente en la tienda despus de recibir la notificacin del cambio de algn dato de la agrupacin de replicacin de productos por va administrativa. De esta forma, cuando el circuito se normalice automticamente se disparar el proceso de replicacin. Para dar la notificacin de replicacin con xito se definir un servicio nuevo del Servidor de Replicacin de Productos. En las figuras 60a, 60b y 41b se muestran los esquemas modificados.
Ticket Central -ODBC Agrupacin de productos Tienda
Responsable
Informe de xito
Replica Masiva
Mantenimientos Peticin tienda
Cola Peticiones Replicacin Enviar replica al local Servidor de Correo (Central)
Servidor replicacin Productos
R
Copia de la tienda Copia en CD Copia desde CD F Servidor de Correo (Local)
Tiquet Control Puestos Venta Entidades en la tienda Copia de la Tienda
Figura Figura 60a. 60a. Arquitectura Arquitectura de dela la replicacin replicacinde de productos productos
En programa de peticin de replicacin masiva hemos incluido tambin una funcin para informar manualmente a la central de que la replicacin ha tenido xito. Observe que la operativa pasa por engaar al proceso de replicacin y copiarle desde el CD o manualmente el fichero de cambios como si hubiera llegado por el servidor de correo. Dentro del servidor de replicacin estar la generacin de la hoja del ticket de replicacin para controlar que se han actualizado todos los puestos de la tienda.
-56-
Cola Peticiones Replicacin Esta la copia?
R
No Si
Peticin de Replicacin
Espera llegada
Peticin Tienda Creacin Ticket Control Puestos
Servidor de Correo Local Copia de la Tienda
Carga en el local
Tiquet Control Puestos Venta
Figura Figura 60b. 60b.Servidor Servidor de de replicacin replicacinde deproductos productos

Finalmente, el inicio del puesto de trabajo modificado ser:
Agrupacin de producto en el Servidor Coger Productos Copia Productos
Responsable Tienda
Servidor Apertura Jornada
Hay nuevo fichero de productos
Agrupacin en puesto venta Actualizar Tiquet Control
Servidor Modificacin Tiquet Replicacin
Inicio en el puesto
Emergencia
Entrar fecha y hora manual Pedir Jornada
Hay cambio de productos?
Responsable Tienda/ Cajero
Fecha y Hora referencia puesto venta
Jornada
Hay cambio de productos?
Figura Figura 41b. 41b. Inicio Inicio de de Jornada Jornada en en el el Puesto Puesto de de Venta Venta
La necesidad de mantener el ticket de control en el servidor de la tienda comporta la aparicin de un nuevo Servicio de Modificacin del Ticket de Replicacin cuyo esquema se muestra en le figura 64.
-57-
Actualitar Tiquet Control
Tiquet Control Completo?
Si
R
Tiquet Control Puesto Venta
Servidor de Peticin Replicacin
Tiquet Control Tiendas
Figura Figura 64. 64. Servidor Servidor de de Modificacin Modificacin Tiquet Tiquet del del Replicacin Replicacin
3. Semntica del servidor de correo.

Recuerde que partimos de la base que este servicio es de ejecucin segura por lo que no necesitamos trabajar este tema. Asumimos que la semntica del servidor de correo es Exactamente una vez en el transporte y que si el fichero transportado ya existe en destino regraba la copia anterior.
4. Semntica del resto de servidores.

Como criterio general, todos los intercambios con una cola por medio sern de semntica Exactamente una vez y se asegurar de que la confirmacin de anotacin en la cola y de captacin por el servidor funciona correctamente por la dinmica de referencias.
4. 1. Recepcin de la reposicin.
Semntica: Al menos una vez (At least one). Implementacin: Si se ejecuta ms de una vez hay que asegurar que el fichero nuevo machaca la copia anterior. Para conseguirlo se asociar la nombre del fichero que se transmite el cdigo de la tienda y la fecha. El servidor de correo en que se basa garantiza la ejecucin segura del transporte.
4. 2. Obtencin de la fecha de entrega.

Semntica: Quizs (May be). Implementacin: No es una funcin crtica ya que muchos proveedores no la darn por lo tanto no necesitaremos ninguna semntica severa.
4. 3. Recepcin de albaranes de proveedores.

Semntica: Como mximo una vez (At most once) Implementacin: Si el agente que lo da de alta ya tiene un albarn registrado con la misma referencia, y se ha registrado a mano o ya est tratado, no se realizar ninguna accin. Si todava no se ha tratado y se haba recibido automticamente se supondr que es una nueva versin del proveedor y se regrabar. Note que est semntica es al menos una vez si el albarn no se ha tratado y como mximo una vez en caso contrario.
4. 4. Contabilizacin de albaranes.
Semntica: Como mximo una vez (At most once) Implementacin: Si se recibe una peticin se intentar registrar en la envolvente contable y si devuelve que ya existe, se dar el trabajo por realizado. Observe que este circuito no permite la anulacin de albaranes, Los cambios deben de hacer albaranes de diferencias.
4. 5. Envo de pedidos a proveedores.

Semntica: Como mximo una vez (At most once) Implementacin: Si se recibe una peticin se intentar enviar el pedido y si el proveedor devuelve que ya existe, se dar el trabajo por realizado. Habr que aclarar con el proveedor la semntica de su servicio para filtrar que recibamos el doble de lo esperado si nos acepta dos veces el pedido enviado.
4. 6. Registro de la compra.
Semntica: Como mximo una vez (At most once) Implementacin: Si se recibe una peticin se mirar si el documento ya se ha imputado alguna vez realizando una consulta sobre la BD. En caso de que as sea, se dar la operacin por realizada. Otra opcin podra ser hacer el servicio idempotente programando que si el documento ya se ha registrado se retroceda (opcin que de hecho ya deber estar prevista en una aplicacin real) y despus se impute de nuevo.
4. 7. Consulta y modificacin de stock.

Los trato conjuntamente ya que estn ligados por la arquitectura de precondicin, Semntica: Exactamente una vez (Exacty once). Implementacin: Lo garantiza la resolucin de la pre-condicin.
4. 8. Integracin de proveedores.
Vale lo dicho para el envo de pedidos a proveedores ya que estar muy condicionado por la semntica de los servicios de cada proveedor.
4. 9. Envolvente contable.
Habr que ligarse a la semntica que garantiza este servicio del entorno contable.
4. 10. Servidores de fecha y hora.

Semntica: Al menos una vez (At least one). Implementacin: Con est semntica habr suficiente ya que el servicio es idempotente.
4. 11. Alta de clientes.

Semntica: Como mximo una vez (At most once). Implementacin: Si al dar el alta el servidor encuentra que el cliente ya existe, supondr ya se ha ejecutado con anterioridad y se tratar como modificacin por si hay campos diferentes. No se prev ninguna verificacin ms debido a que se supone que un mismo cliente no puede estar al mismo tiempo en dos tiendas.
4. 12. Consulta de clientes.

Semntica: Al menos una vez (At least once). Implementacin: No importa leer dos veces lo mismo ya que no hay ms que datos de consulta.
4. 13. Obtencin de clientes no disponibles.

Semntica: Al menos una vez (At least once). Implementacin: Si el servicio no responde se continua trabajando con la copia anterior.
4. 14. Envo de la reposicin.

Semntica: Al menos una vez (At least once). Implementacin: No importa que el servicio se vuelva a ejecutar ya que se supone que si se hace as es porque la tienda desea cambiar su pedido. Como medida adicional podra tomarse que si el pedido ya se ha servido, se devolviera error. Obviamente hacerlo as o no estar en funcin de que parte de la aplicacin asume esta responsabilidad.
4. 15. Incorporacin de pedidos propios.

Semntica: Al menos una vez (At least once). Implementacin: No importa que el servicio se vuelva a ejecutar ya que se supone que si se hace as es porque la tienda desea cambiar su pedido. Como medida adicional podra tomarse que si el pedido ya se ha servido, se devolviera error. Obviamente hacerlo as o no tambin estar en funcin de que parte de la aplicacin asume esta responsabilidad.
4. 16. Envo de la documentacin.

Semntica: Como mximo una vez (At most once) Implementacin: Razonamiento idntico al del servicio de envo de la reposicin.
4. 17. Gestin del stock de apoyo.

Estar ligada a la semntica del servicio del componente prefabricado que hemos asumido que nos dar este servicio y que queda fuera del mbito de este ejercicio. Sin embargo, es ms que probable que estemos en una semntica de cmo mximo una vez.
4. 18. Asignacin de stock a pedidos mviles.

Semntica: Como mximo una vez (At most once) Implementacin: Al apoyarse en el servidor de correo, el razonamiento ya lo hemos hecho para otros servicios.
5. Control de la situacin de emergencia.

5. 1. Agrupaciones de trabajo.
5. 1. 1. Servicios desacoplados montados por agente. El control de la recuperacin de la cada se realizar reintentando el servicio despus del tiempo de sleep. Servidor de correo. Recepcin de la reposicin desde tiendas. Envo de la reposicin. Agentes de la integracin de proveedores. Obtencin de fechas de llegada previstas para los pedidos a proveedores. Recepcin de albaranes de proveedores. Contabilizacin de albaranes. Envo de pedidos a proveedores. Registro de la compra. Incorporacin a pedidos propios. Envo de la documentacin. Asignacin de Stock a Pedidos Mviles. Obtencin de los clientes no disponibles.
5. 1. 2. Por la situacin en el entorno de administracin. Integracin de proveedores. Envolvente de la aplicacin contable. Servidor de fecha y hora de la central. Servidor de replicacin de la agrupacin de productos. Alta de clientes. Consulta de clientes.
5. 1. 3. Por localizacin en el servidor del almacn. Se localizarn en el entorno de la base de datos que da servicio a cada almacn. Consulta de stock.
-61-
Modificacin de stock.
5. 1. 4. Por localizacin en el servidor Tienda y conexin con otras tiendas. Gestin del Stock de Apoyo.
5. 1. 5. Por localizacin en el servidor de la Tienda. Servidor de fecha y hora del local. Apertura de jornada.
5. 2. Semforos de disponibilidad y vigilantes.

Utilizaremos dos semforos de disponibilidad:
Semforo de disponibilidad de los servicios de administracin, que se arrancar en cada una de las tiendas. Todos los servicios ligados a la agrupacin del entorno de administracin se harn jugar con este semforo tal como se ha explicado en el captulo dedicado a la consistencia. El semforo ser de tres estados. Semforo de disponibilidad de los almacenes de apoyo, opcional.
Al primer semforo se le asociar un Vigilante de disponibilidad de los servicios administracin. Semforo y vigilante se montarn en un nico Agente de Vigilancia y Disponibilidad de los Servicios de Administracin. El segundo semforo se hace ms difcil de disear sin saber como es el servicio que nos da la pieza de gestin de los almacenes de apoyo que nos dan como prefabricada. Probablemente habr algn ticket por el medio para controlar que nodos de apoyo hay cados. Sin ms informacin, suponemos una situacin paralela a la anterior y prevemos un Agente de Vigilancia y Disponibilidad de los Almacenes de Apoyo.
5. 3. Control de la situacin de emergencia.

Los Agentes de Vigilancia y Disponibilidad de los Servicios de Administracin y Almacenes de Apoyo controlarn los servicios de la agrupacin de administracin y de los almacenes de apoyo respectivamente. Los agentes no necesitan servicio de vigilancia ya que reintentan por peticin de servicio tras el periodo de sleep. Respecto a los servicios ligados al almacn hay dos posibilidades: Montar un servicio de vigilancia homlogo al de los servicios de administracin. Reintentar a cada peticin. Si se escoge esta ltima solucin, la situacin es diferente segn el almacn:
-62-
Si es el almacn central, comparte base de datos con el entorno de la central por lo que la probabilidad de cada ser muy baja. La notificacin de funcionamiento puede realizarse en fro, verbalmente por ejemplo, ya que el almacn puede retener los procesos mientras se arregla la avera Si el almacn es el de la tienda, trabajar contra la base de datos del servidor de tienda. Por lo que la avera del servidor obligara necesariamente a trabajar sin el ordenador ya que los clientes deberan llevarse el gnero. Este tema deber ser resuelto en el plan de trabajo en emergencia. Pero en cualquier caso, no parece que la presencia de un semforo mejore mucho la gestin.
En un ejercicio de papel como este se hace muy difcil tener criterios reales para tomar la decisin entre una y otra solucin en un servicio tan crtico como la cada de stock. No hace falta montar ningn control especial de la cada de los servicios del servidor de la tienda ya que se utilizan en momentos puntuales y bastar con: Informar al operador de la situacin cuando ejecute programa que utilice el servicio y este no obtenga respuesta. Reintentar cada vez que se autentifica un operador, accin obligada por el funcional que hemos decidido ya que hay que comprobar siempre el estado de la jornada.
6. Anlisis de la situacin de emergencia para el mdulo de stock.

En el circuito de reposicin de stock entre almacn y tienda, cuando falle la transmisin en cualquiera de los sentidos, se reintentar hasta que la transmisin se pueda conseguir. En el sentido tienda almacn central, si al segundo da el problema continua se generar un CD o un floppy con la necesidad de reposicin. En el sentido almacn central tienda, si no hay conexin con la tienda, con el envo del gnero desde el almacn central a la tienda se incluir un CD con los datos del envo. As, se ha de incluir una funcin nueva en el proceso de preparar el envo que pregunte si hay disponibilidad de la conexin con el servicio y en caso contrario genere el CD. Para evitar tener que generar CD especficos se generar uno de nico con todos los envos generando una copia para cada una de las tiendas con problemas. En la figura 22 se muestra el esquema de la parte del almacn central de la reposicin de tiendas y la figura
-63-
Peticiones Pendientes Productos Material a Reponer Posicin productos en almacn
Peticin de Reposicin Preparar Envo Stock Albarn transportista Relacin para transportista
Transportistas
Albarn
Etiquetas
Para poder preguntar por el estado de la lnea definimos un Servicio de Test de Lnea de Acceso a Nodos que nos informar del estado de la conexin con el local. El envo de los albaranes se har con filosofa PUSH para conseguir que pase el menor tiempo posible entre el test y el envo. De cualquier forma, en caso de que hubiera un problema entre estos dos momentos, el manual de procedimientos de la tienda establecer que si no tiene el albarn electrnico ni le llega el CD, conformar sobre el papel del albarn. Cuando se recupere el servicio y lo reciba electrnicamente, realizar el registro y validacin sobre el ordenador. El proceso de preparacin del Envo modificado se muestra en la figura 22a.
Peticiones Pendientes Posicin Productos Etiquetas
Albarn Preparar bultos
Rutas de retirada Servicio de envo de la reposicin Stock
Impresin albaranes
Envo a Si la tienda
No
Hay Conexin?
Actualizacin stock
Lista de envo
Albarn
Generar CD
Test en lnea de acceso al nodo
Transportistas
Revise la semntica del servicio y ver que permite esta forma de trabajar ya que si el albarn ya existe y ha sido tratado, no lo registra dndolo por procesado. Finalmente, el proceso de reposicin desde el almacn central en la tienda quedar como se muestra en la figura 21 en el que se ha reflejado el circuito de alternativo basado en CD.
Productos por tienda Stock local Productos a pedir Generacin directa Necesidades de compras
Compras
Llamada a Peticin de Reposicin

R
Productos Registro en stock
Material a Reponer Albarn

Incorporacin Directa
R
Peticin de Reposicin Servicio de envo de la reposicin
Incidencias

En el proceso se compras, en caso de que falle la comunicacin con el proveedor, el intercambio de documentos se har manualmente. Esto supone la aparicin en el circuito de compras las funciones necesarias para imprimir manualmente el pedido y registrar el albarn de entrega. Si llega un pedido a la tienda del que no hay albarn electrnico del proveedor, la tienda lo registrar a mano y a partir de aqu el circuito seguir normalmente. Este circuito de registro manual se ha previsto aqu como consistencia. En la realidad, el proceso de registro manual de los albaranes estar disponible desde el momento del funcional ya que es muy difcil, por no decir imposible, que todos los proveedores intercambien documentos manuales. El circuito de compras modificado se muestra en la figura 23.
-65-
Necesidades de Compra Proveedor Productos
Obtencin Fecha de Llegada
Impresin Albaran
F
Pedido a Proveedor
R
Proveedor
Pedido Compra Generacin pedido

F Integracin proveedores
Llamada al envo de pedido Stock
Envo Pedido
Pedidos Pendientes
Albarn Proveedor Recepcin Albaranes Proveedores Validacin recepcin Incidencias
Registro Pedido
Llamada al registro de pedido
Entrega Validada Interfcie contable
Entrada Manual Albaran
Albaran Proveedor
Operador
Observe que al ser el intercambio de documentos con el proveedor automtico habr que aadir dos nuevas operativas a la consistencia: Un check en el cuadro de control de explotacin para saber que hay pedidos que no se han generado y poder avisar para enviar los pedidos manuales. Se har una propuesta en el diseo de administracin que se incluye en el captulo siguiente. Establecer en el manual de procedimientos que si se recibe genero de un proveedor y no se dispone del albarn del proveedor electrnico, se registrar a mano.
Como el sistema es desatendido no podemos confiar en que alguien se de cuenta que hay pedidos pendientes de enviar a proveedores. Es necesario crear un agente que implemente un Servicio de Pedidos Pendientes de Entregar y notifique a los responsable de imprimirlos y enviarlos manualmente. Segn el pacto de comportamiento del servicio envo de pedidos del proveedor, repase la semntica del servicio si no se acuerda, la persona que enva el pedido lo registrar como enviado o no para evitar duplicidades El diseo del agente que cubre el servicio se muestra en la figura 65
-66-
Sleep Aviso a responsable
No
Hay pedidos fuera de Plazo?
Responsable pedidos
Si
Figura Figura 65. 65. Agente Agente Pedidos Pedidos Pendientes Pendientes de de Entregar Entregar
La arquitectura de uso de este servicio se muestra se muestra en la figura 66.
Agente pedidos pendientes de entregar
Responsable pedidos Proveedor
Informar Envo
Imprimir pedido
Pedido
Figura Figura 66. 66. Arquitectura Arquitectura de de gestin gestin de de los los pedidos pedidos de proveedores pendientes de entregar de proveedores pendientes de entregar
El criterio para decidir si un pedido esta fuera de plazo estara basado en la fecha de pedido ms un margen que se relacionar con el proveedor y/o el tipo de producto. Obviamente profundizar en este tema no tiene sentido aqu. En cuanto al servicio de Obtencin de la Fecha de Llegada Prevista para los pedidos de proveedores, si el proveedor no da el servicio o ha cado, se dejar la ltima fecha obtenida o la de entrega prevista inicialmente en el pedido si no se ha podido modificar nunca. Observe que este atributo deber implementarse en la aplicacin.
Los servicios de Contabilizacin de Albaranes, la Envolvente Contable y el Registro de la Compra se reintentan hasta que se consigue xito tal como hemos establecido al definir la semntica de estos servicios. Observe que al cierre contable de final de mes necesita que todos los documentos que afectan al mes que se cierra estn tratados. Normalmente necesitar unos das del mes siguiente para hacer el cierre del mes anterior por lo que se supone que en ese periodo ya se habr arreglado una posible avera que produzca la cada del sistema. Para confirmarlo debe disponerse de una consulta dentro del proceso de fin de mes para asegurarse que no hay nada pendiente de llegar y contabilizarse del mes anterior. Puede usarse la misma que se propone en el cuadro de control del captulo siguiente dedicado a la administracin. El diseo del proceso de cierre del mes, en el que se registrara probablemente el inventario de fin de mes, es un proceso puramente organizativo, que obviamente la aplicacin informtica deber soportar, que depende de cada compaa y que no nos aportara demasiadas novedades. Por ello, lo dejamos fuera del ejemplo. Probablemente el uso de tickets de control aqu sera habitual. En los almacenes, si se estropean los ordenadores: Si hay posibilidad se trabajar sobre otra mquina. Si no la hay se har el proceso afectado manualmente registrndolo posteriormente en el ordenador.
7. Circuito de Ventas.
Si los Servidores de Fecha y Hora caen, se sustituirn por: En el caso del servidor de la central, por una confirmacin manual sobre el servidor de la tienda en el momento de usar un programa que detecte la cada del servicio.. Si el que cae es el de la tienda, el servicio se omitir y los puestos de trabajo continuarn trabajando con los valores anteriores.
Si falla el servidor de apertura de los puestos de trabajo la jornada se pedir manualmente a la persona que inicie la jornada. Esta operativa ya se haba contemplado en la figura 41b. Revsela si no se ha percatado. En la figura 61 se muestra el servidor de fecha y hora modificado.
-68-
Fecha y Hora de referencia
Hay cambio de productos
Jornada
Servidor de Fecha y Hora (Central)
Servidor de Fecha y Hora (Tienda)
Servidor de Apertura
Cada del Servidor Central
Hay cambio de productos Entrada/ Confirmacin Manual(1)
Fecha y Hora
Responsable
(1) En los programas que usen el servicio
Figura Figura 61. 61.Servidores Servidores de deFecha Fechay yHora Hora y yde de Apertura Apertura
El anlisis de emergencia de los procesos de venta es muy parecido a los ejemplos que se han desarrollado en la segunda parte por lo que revselos all. Puede aplicarlos a este ejemplo como ejercicio adicional. A grandes rasgos el diseo de consistencia de esta parte supondra replicar el los puestos de trabajo: Jornada. Operadores. Productos en el puesto de venta.
Como ya hemos visto, un momento muy apropiado para hacerlo sera la apertura de jornada. En caso de cada de la conexin del puesto de venta, la situacin de emergencia sera: Si al arrancar el programa de venta ya hay cada de servicios, el programa se inicializa a partir de los ficheros XML en lugar de con los datos del servidor. En cualquier caso, a partir de ese momento, el servidor trabaja con los valores internos para prever posibles cadas y no tener que hacer cargas en caliente al entrar en emergencia. Las ventas se iran registrando en un log de ventas XML en el puesto de venta al mismo tiempo que en el servidor. Recuerde que el cliente recibe un albarn para poder pasar a los centros de cobro y entrega del material. Si cae la conexin, solo se actualizar el log. Al recuperarse la conexin las ventas se recuperar en back-ground. Si se ha arrancado en emergencia y hay cambios, se avisar al operador para que en cuanto pueda deje de vender y permita las actualizaciones. Si al final de da continua el problema pero es servidor esta trabajando las ventas se trasladarn en floopy o CD desde el puesto de venta al servidor.
-69-
Una buena forma de disear este proceso es preparar el programa de venta con un hilo adicional donde se monta en back-ground la conexin con el servidor. En caso de cada de servicios en el puesto de cobro, se grabar un log de cobros realizados recuperndose de forma parecida al log de ventas. El cobro se realizar a partir del albarn en papel que lleva el cliente. Si la maquina que soporta en puesto de cobro se estropea un puesto de venta asumira la funcin de cobro. Como para tiendas pequeas tambin se realizara un montaje en que todos los puestos se pudieran arrancar sobre la misma mquina, podramos abordar cualquier situacin de emergencia que pudiera ocurrir por avera de una mquina de puesto de trabajo de esta forma. Hay que prever para tiendas pequeas o cadas de suministro un documento de venta manual que se registrara posteriormente sobre el ordenador. El documento previsto tendr original y tres copias, una para cada puesto de trabajo. Tendr casillas para registrar el tipo de pago del cliente y observaciones a la entrega del material. En este caso, los productos que no estn en el local no se entregarn al cliente y se le enviarn ms tarde cuando los servicios funcionen. Para el registro de estas ventas manuales sobre papel puede seguirse dos caminos: Seguir el proceso normal como si el cliente estuviera presente si se quiere que cada puesto asuma su responsabilidad o no se quiere programar nada especfico. Montar un proceso de registro nico que agrupe en integracin grfica todos los procesos de atencin al publico y los lance a pedir del registro nico del documento manual.
Escogemos la primera opcin. En caso de cada del puesto de almacn y como sera muy improbable que por situacin fsica uno de los otros puestos pudiera asumir la funcin, se prev imprimir dos copias del albarn una de las cuales se hara llegar manualmente al almacn para que se fuera preparando la entrega del gnero. Se podra hacer que la aplicacin imprimiera la segunda copia del albarn solo si no hay conexin con el puesto de entrega del material. Puede aadirlo como ejercicio adicional. Un punto muy crtico en la consistencia es la cada de la conexin de la tienda con el exterior, situacin que le impedir realizar la peticin de apoyo. Si esto sucede, se puede trabajar como alternativa con el mismo proceso que los vendedores mviles enviando lo pendiente al final del da contra la central cuando se arregle la avera. En cualquier caso nos falta informacin para poder tomar acciones concretas en un caso real. La complejidad y criticidad del problema obligara a analizarlo con sumo cuidado. Observe que para los vendedores mviles toda la consistencia est ya resuelta.
En este caso, si: Falla la central, bastar con reintentar pasado un tiempo. Se estropea el PC, se usar el registro por papel. Se estropea la placa de comunicaciones, se grabarn los pedidos en CD y se enviarn a la central por mensajero. Cuando el PC se arregle se nivelar el sistema simplemente haciendo una conexin.
-71-
DISEO DE ADMINISTRACIN
1. mbito.
Mi objetivo no es incluir aqu una relacin exhaustiva de todos los procesos de administracin ya que la mayora de ellos estn ntimamente ligados a polticas de administracin que estn en funcin de cada organizacin y/o aplicacin y que por tanto se hacen difcil de trabajar en un ejemplo de papel. Me voy a militar a definir una posible poltica de las actividades de administracin y a definir un posible cuadro de control que se ajuste a las necesidades de esta aplicacin y aadir algunos procesos ms como informacin adicional.
Voy a suponer tambin que esta informado a nivel de tienda que das del ao trabaja. Como ver enseguida, esta informacin es necesaria para controlar varios de los procesos de negocio. En particular el concepto si la tienda o vendedor mvil trabaj ayer se traduce en el da antes de hoy que vendi, que puede ser hacer 2 das por no abrir un fin de semana o 30 por vacaciones.
Definimos como prerrequisito de administracin que los ordenadores de las tiendas no se apagan nunca. Aunque algunos de los procesos de negocio aparecern, como ya dijimos en la segunda parte, en el captulo de integracin del cliente, a efectos didcticos los incluimos ya aqu, haciendo referencia a la parte del captulo siguiente donde se explican. En funcin del tiempo del que disponga, puede Ud, amigo lector, completar el ejemplo situando diferentes precondiciones de organizacin en la lnea que vimos en el captulo dedicado al anlisis de la administracin
2. Organizacin del soporte.

Se establece el CDSD en la central. Se integrar en l, a dems del personal informtico, el subdirector del departamento de tiendas para que aporte la visin de los usuarios principales del sistema distribuido. Se establece un nico centro CASD en la central. El soporte directo a los usuarios lo dar un empresa subcontratada que realizar el diagnostico y seguimiento de todas las averas en los plazos y trminos pactados aunque la resolucin no dependa directamente de ellos. En las tiendas grandes se potenciar la existencia de un usuario avanzado que d formacin y asistencia de primer nivel in situ El mantenimiento del hardware se pactar con empresas del mbito local de las tiendas. El pacto de servicio ser: Las tiendas llamarn directamente a la Hot-Line en un horario que cubrir:
o Los das laborables de 8 de la maana a 1 de la madrugada. o De 8 a 10, 13 a 15, y 11 a 13 los sbados, domingos y festivos. Los tiempos de respuesta pactados son: o Atencin: 5 minutos. o Diagnostico: 2 horas. o Resolucin: Software: 8 horas (un da) Hardware: 8+8 horas (dos das). En las tiendas no se permite ningn software no homologado por la compaa por lo que la recuperacin del sistema se podr hacer por reconstruccin. Etc... .Aada aqu todo lo que le parezca necesario. Hgalo. Es un buen ejercicio.
CASD
Central
Existir una aplicacin de registro y seguimiento de las acciones de soporte que tendr permanentemente informado al cuadro de control de las incidencias abiertas. El almacn central depender directamente del CASD que ser tambin el ltimo nivel de apoyo de la empresa de hot-line y realizar el control de calidad de la gestin de la subcontratacin. El esquema del soporte se muestra en la figura.
Almacn Central
CDSD
CSSD
Usuario Avanzado
Tienda Tienda
Observe que no hay centro de administracin ligado a las tiendas por lo que temas como la reconstruccin de la base de datos se habrn de generar desde la estructura de soporte.
3. Criterios de Back-up, reconstruccin y eliminacin histrica.

El criterio ser reconstruir desde la central ya que se tiene la copia del da anterior. En caso de que no sea as o los datos que todava no se han registrado en la central, se recogern de los puestos de venta a partir de los logs XML que se generarn en los puestos de trabajo. As pues, habr que modificar el anlisis funcional para que: Los programas de captura de ventas, cobro y almacn generen el log. Estos logs son los mismos que se han citado en el anlisis de consistencia. Definir una nueva agrupacin de replicacin con todos los datos de la base de datos central generados por el local: ventas, albaranes, etc.. Definir un nuevo proceso, que se integrar en batch, para realizar la reconstruccin de la base de datos. Para ellos se utilizarn las funciones que han salido ya en el funcional y en el anlisis de consistencia. Si quiere puede definir la arquitectura de este proceso como ejercicio adicional.
-73-
Reconstruir la base de datos ser: Enviar al local una copia de todas las agrupaciones de replicacin a fecha actual. Enviar al local copia de la replicacin de datos que afecten al local desde la fecha de caducidad hasta la ltima correcta (probablemente el da anterior a la avera). Pasar la cadena de reconstruccin desde los logs de los puestos a partir de la primera fecha no recibida de la central.
Habr que prever tambin procesos de eliminacin histrica para la base de datos y todos los logs tanto de monitoring como de reconstruccin. Para hacerlo se asociar a cada entidad una fecha de caducidad en una entidad con todas las entidades sometidas a eliminacin histrica. Se preveen dos procesos:
Eliminacin histrica de la base de datos, que se incluir en el proceso de apertura de jornada del servidor. Adalo a la figura 41. Eliminacin de logs, que se aadirn a: o La apertura jornada del servidor para los logs de monitoring. Adalo a la figura 41 o A la apertura de los puestos. Adalo a la figuras 41.
4. Monitoring.
Todos los servicios, puestos de trabajo y servicio de soporte generaran un log que se enviar cada da por correo a la central en el momento del cierre de jornada donde se cargarn los datos de ese da en el repositorio de anlisis. En los procesos de cierre se incluirn tambin los agentes de mantenimiento preventivo que se presentan ms adelante al hablar del cuadro de control Modifique el proceso de la figura 42 para incluirlos. En la cadena batch que se crear en el captulo de integracin para la recepcin de las ventas en la central se incluirn la carga de los logs.
5. Servidores de programas.
En la central se montar un nico servidor de programas para los programas que deben dar servicio a administracin y el almacn central. Se localizar en la misma mquina que la base de datos, En la tienda, se montar un servidor de programas nico en el servidor de local. En l situarn tanto los programas de servidor como todos los de los puestos de trabajo. En cada puesto de trabajo se llevar un servidor de programas replicado con los programas del puesto.
-74-
Cada vez que se arranque un programa desde un puesto se actualizar la versin desde el servidor de la tienda si ha cambiado. En caso de cada del servidor se usar la versin del puesto.
6. Cuadro de mandos.
Como ya hemos dicho en el captulo de la segunda parte dedicado al diseo de la administracin, el cuadro de mandos nos ha de permitir la supervisin, control y gestin centralizada del sistema distribuido. Para este ejemplo, se construir con las siguientes zonas:
Control de Comunicaciones
Control de los Procesos
Centro Errores Control de comunicaciones. Dar una visin de la disponibilidad de la plataforma de comunicaciones. Zona de Comandos Control de Procesos. Su funcin es monitorizar el estado de los procesos de negocio. Control de incidencias del sistema y del soporte de usuarios. El Centro de Errores del sistema, entre otros el servidor de correo. Zona de comandos directos
Control Incidencias del sistema y del soporte a usuarios
A continuacin se describen con detalle cada una de estas zonas.
7. Arquitectura del cuadro de control.

El cuadro de control se montar en un nico programa master/slave multihilo configurable segn los derechos del cliente autentificado. Cuerpo del programa residirn: La lgica central, Los componentes de semforos y tickets propios. La carga inicial de todos los componente con opcin de recarga a solicitud del operador
Un hilo para incluir cada cliente back-ground de los que se hablar a continuacin.
8. Zona de control de las comunicaciones del cuadro.

Bsicamente habr dos zonas de informacin y una zona de comandos con la imagen de la figura.
-75-
Situacin Tiendas
Nombre Tienda Nombre Tienda Nombre Tienda
Con problemas Todas
Situacin Proveedores
Proveedor Proveedor
Con problemas Todas
TEST
Visin de una tienda
Conexin por terminal
Conexin Por emulacin
8. 1. Disponibilidad de cada nodo interno.

La representaremos por: Aviso general del nivel de problemas. La representaremos por un semforo de tres posiciones: o Verde, sin problemas. o mbar, hay conexin correcta con las tiendas pero alguna/s de ellas tiene/n terminales con problemas o Rojo, hay locales sin conexin con el exterior. Observe que aqu las luces mbar y rojo pueden encenderse simultneamente. Situacin concreta de cada nodo representada en un ticket con tres estados: o Sin problemas. o No hay conexin. o Falla el acceso a alguno de los puestos de trabajo del nodo.
Para implementar esta ltima funcin, asociado al estado de cada ticket colocaremos un fichero XML con el estado de cada puesto de trabajo de ese local. Elegimos una solucin XML para obtener independencia del nmero de puestos de trabajo del nodo. Por cada nodo habr una anotacin en el fichero con su referencia y estado de accesibilidad. La representacin de cada tienda en el cuadro ser una semforo de tres posiciones equivalente al general. Para saber el estado de una tienda se har doble clic con el ratn o se pedir el comando visin de una tienda obtenindose una visin detallada del estado de sus puestos de trabajo. Es la figura 70 se muestra una posible arquitectura del cliente back-ground para mantener la informacin. Este cliente realizar una actualizacin peridica segn sea el valor parametrizado en la ficha de enviroment.
-76-
Nodos
Actualizar Semforo general Verificar estado de cada nodo

R
Estado comunicaciones con nodos
Estado Nodos
Test en lnea de acceso al nodo Sleep
Actualizar pantalla de control
Figura Figura 70. 70. Test Test comunicaciones comunicaciones con con nodos nodos
A estas alturas la figura es bastante autoexplicativa. Hacer notar, sin embargo, que para comprobar el estado del acceso a cada nodo utilizamos el servicio de test de lnea de acceso al nodo creado anteriormente. Aadiremos a la respuesta el fichero XML con la situacin de cada nodo. Observe que en el repositorio de nodos debe haber informacin de que mquinas / puestos de trabajo de los nodos remotos interesa incluir en el test. Deje esta opcin abierta ya que no todos los ordenadores de la empresa deben salir aqu.
8. 2. Disponibilidad del enlace con proveedores.

Se resuelve de forma anloga al caso de los nodos pero implementando nicamente un semforo de dos estado ya que solo necesitamos saber si la via esta abierta o no. Obviamente en cada proveedor debe tener un atributo que informe de si hay o no hay pactado intercambio de documentos electrnicos. En la figura 71 se muestra una posible solucin que como ve es muy parecida a la anterior. Se plantea aqu la disyuntiva de que servicio hacer servir para comprobar el estado de la lnea, Se puede utilizar el servicio de recepcin de albaranes con un formato de parmetros errneo que responda error lgico por el error de parmetros si hay conexin, error que obviamente saltaremos, y como error fsico en ausencia de conexin.
-77-
Proveedores
Actualizar Semforo general
Estado comunicaciones con proveedores
Verificar Estado de Proveedor
Estado Proveedores
Recepcin Albaranes Proveedores Sleep
Figura Figura 71. 71. Test Test comunicaciones comunicaciones con con proveedores proveedores
8. 3. Comandos.
Se incluyen los siguientes comandos de accin: Test de las comunicaciones. Revisar el estado de uno o varios nodos y/o proveedores a obtener de una lista de checks con todas la tiendas y proveedores controlados. Visin de una tienda. Muestra el estado de la tienda pidiendo la opcin de si se desea actualizar previamente la informacin o no. Conexin remota: o Por emulacin para compartir pantalla con el personal de la tienda. o Por conexin de tipo Terminal Server para administrar sin interferir con el trabajo normal del local.
9. Tomar direcciones IP variables.

Lo montamos como se muestra en la figura 72. Se propone crear un servicio de registro de IPs variables que se arrancar en el centro de administracin donde est el repositorio principal, normalmente el CASD central. Observe que la lectura en nodo ser un proceso a integrar en los procesos del nodo que se comunicar sncronamente con el servicio de la central.
Nodos
Registro n el CASD
Lectura en nodo
Replicacin sncrona a los nodos interesados
Figura Figura 72. 72. Servicio Servicio de de registro registro de de IP IP variable variable
-78-
Puede pensarse en realizar una replicacin sncrona en cascada desde este repositorio del CASD Central a otros posibles nodos interesados como puede ser el soporte de Hot-Line. El anlisis de consistencia de este servicio es simple: si la Lectura en Nodo no tiene respuesta, se salta la actualizacin. La Lectura en Nodo la montaremos como un cliente back-ground que se arranque: Cada vez que se autentifique un usuario. Cada vez que se inicie la jornada. A peticin por men.
El cliente back-ground se auto desconectar una vez completada su misin. El la figura 41a se muestra el proceso de inicio de jornada modificado. Como ejercicio adicional puede modificar los otros procesos afectados.
Hay cambio de productos Servidor fecha y hora de la Central Tomar productos Servidor agrupacin de productos Registro de IP variable
Hay nuevo fichero de productos
Lectura en nodo de la IP
Iniciacin
Fecha y Hora Referencia Local

Responsable Tienda
Jornada
Venta
Figura Figura 41a. 41a.Inicio Iniciode deJornada Jornadaen en el el Servidor Servidor de dela la Tienda Tienda
10. Zona de control de procesos del cuadro.

Como ya se ha dicho su funcin es monitorizar el estado de los procesos de negocio. Dentro de cada proceso se definirn los estados de aviso y de alarma. Se asociar un semforo a cada proceso con el juego de luces siguiente: Verde: sin problemas. mbar: hay avisos. Rojo: hay alarmas.
Haciendo doble clic sobre el correspondiente semforo se dispondr de una pantalla especfica para cada proceso de negocio.
-79-
El aspecto de esta zona ser el que se muestra en la figura.
Situacin de los procesos de negocio

Recepcin en la reposicin desde las tiendas Contabilizacin de albaranes Envo de la reposicin desde la central a las tiendas Envo de la documentacin desde tiendas a la central Pedidos pendientes de recibir Envi de pedidos de compra a proveedores Verificacin de albaranes en almacenes
Registro de la compra
Jornadas pendientes de cerrar
Recepcin de las ventas desde las tiendas
Conexin de los vendedores mviles
Replicaciones pendientes
Recuperar Ventas
Replicar cierre jornadas
A continuacin se detallan para cada proceso de negocio los estados de aviso y de alarma y se explica la informacin de la pantalla de tratamiento especfico.
10. 1. Recepcin de la reposicin.

Las condiciones de control son: Aviso: A partir de las 2 de la maana y hasta las 0:59:59 del da siguiente, faltan reposiciones de la jornada que se acaba de cerrrar. Alarma: Faltan reposiciones por debajo del plazo de aviso.
Las dos luces pueden ser simultneas. El origen de la informacin es el ticket de tiendas recibidas que se presenta en la figura 81 del programa de obtencin de rutas del captulo siguiente. El acceso al ticket se hace directamente desde el hilo del cuadro de control asociado a este control. La informacin de la pantalla de gestin especializada es: Una lista con todas las incidencias pendientes. Posibilidad de consultar la hoja del ticket correspondiente agrupado por: o Una tienda y un mes. o Una jornada y todas las tiendas
10. 2. Envo de la reposicin.

Las condiciones de control son: Aviso: A partir de las 10 de la maana y hasta las 9:59:59 del da siguiente, faltan envos a entregar por debajo del plazo de aviso.
-80-
Alarma: Hay envos pendientes de das anteriores
Las dos luces pueden ser simultneas. El origen de la informacin es la cola del servicio. Se realizar solicitando las anotaciones pendientes de envo en la fechas de referencia. La informacin de la pantalla de gestin especializada es: Una lista con todas las incidencias pendientes ordenada por: o Tiendas. o Fechas,
10. 3. Envo de pedidos de compra a proveedores.

Las condiciones de control son: Aviso: Hay pedidos pendientes de salir realizados el da anterior Alarma: Hay envo pendientes de salir por debajo del plazo de aviso.
Las dos luces pueden ser simultneas. El origen de la informacin es la cola del servicio de integracin de proveedores. Se realizar solicitando las anotaciones pendientes de envo y analizando por fechas. La informacin de la pantalla de gestin especializada es: Una lista con todas las incidencias pendientes ordenada por: o Proveedor o Tiendas. o Fechas,
10. 4. Contabilizacin de albaranes.

Las condiciones de control son: Aviso: Hay albaranes pendientes de contabilizar hace ms de 2 horas. Como el host est permanentemente encendido se supone que la envolvente contable debe estar siempre activa. Alarma: Hay albaranes pendientes de contabilizar desde hace ms de 4 horas
Aqu podra valer un semforo de dos luces.. El origen de la informacin es el la cola del servicio de contabilizacin de albaranes. Se realizar solicitando las anotaciones pendientes de envo en la con hora de anotacin mayor de los plazos marcados. La informacin de la pantalla de gestin especializada presentar una lista con todos los albaranes pendientes de contabilizar.
10. 5. Envo de la documentacin.

-81-
Las condiciones de control son: Aviso: Hay documentacin pendiente de enviar desde hace ms de 4 horas. Alarma: Hay documentacin pendiente de enviar desde hace ms de 12 horas
Aqu podra valer tambin un semforo de dos luces. Hay una instancia del servicio de envo de la documentacin en cada almacn o tienda. Por esa razn, se acceder directamente la cola del servicio y se informar un ticket dentro del hilo de control. Si no hay conexin con el nodo se colocar en rojo. Observe que este caso esa misma informacin estar en la parte de comunicaciones del cuadro. La informacin de la pantalla de gestin especializada presentar una vista del ticket de control. Si se desea ms informacin se deber acceder remotamente al nodo desde las opciones de comunicaciones.
10. 6. Verificacin de albaranes.

Normalmente en todas las organizaciones hay un plazo para verificar los albaranes de llegada de gnero con el objetivo de que se haga lo antes posible en aras de tener el stock lo ms al da posible. Para comprobar que se hace as hay dos recursos: Modificar el proceso de cierre de jornada en el servidor de tienda para que pregunte si hay albaranes por verificar como una condicin ms del proceso de cierre. Esto filtrara el caso de los almacenes de la tienda. En los almacenes centrales no asociados a la tienda, al no haber proceso de cierre se debe montar un control especfico.
Las condiciones de control son: Aviso: hay albaranes del da anterior sin verificar en algn almacn Alarma: hay albaranes sin verificar en algn almacn de ms de dos das.
Para obtener esta informacin del albarn central se acceder directamente al fichero de albaranes de compra y se verificar cuales de ellos estn fuera de especificaciones
10. 7. Registro de la compra.

Las condiciones de control son: Aviso: Hay compras pendientes de registrar desde hace ms de 5 minutos. Aqu se est actualizando el stock por lo que la respuesta es crtica Alarma: Hay compras pendientes de registrar desde hace ms de 10 minutos
-82-
El proceso es tan crtico que podemos hacer que la misma cola se cuide de avisar a este hilo del cuadro de control a la que venzan estos plazos o que los programas cliente del servicio avisen a la central si no hay conexin. Hay una instancia del servicio en cada almacn o tienda. Por esa razn, se acceder directamente la cola del servicio y se informar un ticket dentro del hilo de control. Si no hay conexin con el nodo se colocar en rojo. Observe una vez ms que esta misma informacin estar en la parte de comunicaciones del cuadro. La informacin de la pantalla de gestin especializada presentar una vista del ticket de control. Si se desea ms informacin se deber acceder remotamente al nodo desde las opciones de comunicaciones.
10. 8. Pedidos pendientes de recibir.

Las condiciones de control son: Aviso: Hay pedidos con fecha de entrega inicialmente prevista superada. Rojo: Hay pedidos con fecha de entrega actualizada pendientes de llegar.
La informacin se sacar accediendo directamente a la tabla de pedidos de la BD de la central. Recuerde que todos los pedidos se concentran en esa base de datos.
10. 9. Jornadas pendientes de cerrar.

Este proceso esta pensado para afinar la administracin de la recogida de las ventas. Observe en la descripcin funcional que si no se produce el cierre de la jornada no se envan las ventas. As, si no han llegado ventas, la causa puede ser: Han llegado las ventas pero hay problemas lgicos de carga. No se ha cerrado la jornada, que es la que controlaremos con este proceso. Hay problemas de comunicaciones, que obviamente se puede analizar con la parte del cuadro de control ligada a ese tema
Las condiciones de control son: Aviso: Hay tiendas sin la jornada de ventas del da anterior cerrada. Alarma: Hay tiendas con jornada sin cerrar desde hace 2 o ms das.
Las dos luces pueden ser simultneas. Para obtener esta informacin el hilo del cuadro de control que gestione esta opcin acceder al ticket de cierre de jornada de cada tienda y copiar los agujeros de ltimos 30 das (das que faltan en el ticket de la central) en una replica del ticket que se llevar en la central. Recuerde que el mantenimiento
-83-
de este ticket se lleva regularmente en el proceso de recepcin de ventas ya que si llegan ventas es que se ha cerrado jornada. Vea la integracin de la parte cliente para obtener ms informacin. A partir de aqu, se realizar la presentacin de la pantalla de detalle donde se mostrar la informacin por: Tienda y mes. Jornada y tiendas.
Este proceso puede llevar mucho tiempo y los cambios son muy poco frecuentes por lo que su periodicidad de refresco ser muy baja. Por est razn, se prevee un botn de comando para refrescar a voluntad del administrador una o varias tiendas. El proceso de replicacin se muestra en la figura 73. Observe la doble ejecucin: Automtica, a partir de los criterios estndar de replicacin reflejados en la ficha de enviroment. En principio los ltimos dos meses de todos los locales. Manual desde el comando, eligiendo los locales y el periodo a replicar.
Cierre Jornada en Tienda Criterios en ficha enviroment Copia criterios de replica Sleep
Criterios de replica
Acceso al ticket en tienda Replica Modificacin Ticket Central
Comando
Peticin de criterios de replica
Responsable
Cierre Jornada en Central
Figura Figura 73. 73. Replicacin Replicacin ticket ticket cierre cierre jornada jornada
10. 10. Recepcin diaria de ventas.
Las condiciones de control son: Aviso: A partir de las 6 de la maana y hasta las 5:59:59 del da siguiente, falta por recibir informacin de las tiendas de la jornada del da anterior. Alarma: Faltan ventas de das anteriores
-84-
Las dos luces pueden ser simultneas. El origen de la informacin es el ticket de ventas de tiendas recibidas que se presenta en la figura 42a4 del programa de gestin de la recepcin de ventas que se muestra en la figura siguiente. El acceso al ticket se hace directamente desde el hilo del cuadro de control asociado a este control. La informacin de la pantalla de gestin especializada es: Una lista con todas las incidencias pendientes. Posibilidad de consultar la hoja del ticket correspondiente: o Una tienda y un mes. o Una jornada y todas las tiendas.
10. 11. Control de conexin de los vendedores.

Se establece como norma que todos los vendedores deben enviar cada da al final de la jornada los pedidos realizados. Para controlarlos se aade un ticket de conexin de vendedores mviles donde, en filosofa de multihoja, se registrar cada conexin. El esquema lgico modificado se muestra en la figura 50b.
Servidor de Correo (Vendedor) Extraccin Conexin Vendedores Mviles
R
F
Almacenes de apoyo
Si
Ha llegado algo? Pedido Notificar a la tienda de apoyo Almacn
No
Sleep
Figura Figura 50b. 50b. Agente Agente de de stock stock en en pedidos pedidos mviles mviles
Las condiciones de control son: Aviso: el da anterior hubo vendedores sin conexin Alarma: hay vendedores que llevan dos das o ms sin conexin..
Las dos luces pueden darse simultneamente. La informacin de la pantalla de gestin especializada presentar una vista del ticket de control por:
-85-
Vendedor y mes. Jornada y vendedor.
10. 12. Replicaciones pendientes.

Ponemos solo como ejemplo la agrupacin de productos pero es obvio que el esquema puede generalizarse sin problemas a cualquier otra agrupacin de replicacin. Las condiciones de control son: Aviso: hay replicaciones con fecha de vigencia a tres das de la actual. Alarma: hay replicaciones con fecha de vigencia a partir de maana o que ya deberan estarlo.
Es evidente que para gestionar esta informacin se ha de atacar el ticket de control de la replicacin que se presento en la consistencia del proceso de replicacin. En la figura 67 se muestra el diseo.
Ticket de Control Replicacin Tiendas
Criterios de vigilancia
Hay replicaciones Pendientes?
Sleep Modificacin Cuadro de control
Figura Figura 67. 67. Aviso Aviso de de replicaciones replicaciones pendiente pendiente
10. 13. Comandos.
Se montarn con dos botones especficos: Forzar recogida desde las tiendas. Refrescar estado cierre jornada, explicada anteriormente.
La opcin de forzar recogida presentar al operador; Una lista de tiendas a tratar. Un intervalo de fechas a recuperar.
-86-
Se acceder al local con dos posibilidades: Recuperar directamente las ventas. Forzar la ejecucin remota del proceso de envo de ventas a la central.
11. Zona del cuadro de control del sistema y de incidencias de usuario.

Trabajar a fondo este tema es imposible aqu ya que depender de la arquitectura y posibilidades de la aplicacin de soporte de la Hot-Line y de las posibilidades del sistema en diagnsticos preventivos. La idea, de cualquier forma es simple, hacer llegar hasta el cuadro: Todos los mantenimientos preventivos del sistema. o Volmenes ocupados de disco. o Impresoras desatendidas sin tinta o papel. o Etc.. Todas las incidencias de hot-line pendientes de resolver separadas en dos grupos: o Dentro de los plazos pactados de resolucin. o Fuera de plazo de resolucin.
La imagen final ser:

Control preventivo del sistema
Relacin de alarmas del sistema
Relacin de avisos del sistema
Incidencias de Hot-Line pendientes
Relacin incidencias fuera de plazo de resolucin
Relacin de incidencias abiertas en plazo de resolucin
Para informar los avisos de hot-line se deber tener acceso al repositorio de la aplicacin de soporte o esa misma aplicacin deber enviarlos. Escogemos esta segunda opcin. Para gestionar los diagnsticos preventivos del sistema puede usarse una arquitectura como la de la figura 74.
-87-
Programa de test y captura
Mensajes preventivos
Sleep
Figura Figura 74. 74. Mantenimientos Mantenimientos preventivos preventivos

Cada proceso de mantenimiento preventivo se montar como un cliente background que se arrancar en los nodos de forma peridica o como parte de otros procesos y que enviar los mensajes a una cola en la central desde donde los gestionar el cuadro de control. Esta cola deber tener persistencia y un proceso de eliminacin histrica. Cada mensaje grabado deber tener una referencia de nodo e incidencia para que solo se presente siemper la ltima versin.
12. Zona del cuadro de control para el centro de errores.

En esta zona se ir mostrando los errores que generen en lnea los diferentes componentes del sistema distribuido. Ya hemos dicho que suponemos que el servidor de correo tiene la posibilidad de trabajar con el centro de errores. La implementacin, como en el caso anterior depende de las herramientas disponibles. Una posible solucin es parecida a la de los diagnsticos preventivos del sistema.. La visualizacin puede hacer con una rejilla con nos permita ordenacin, filtro y agrupacin que dara una imagen como la de la figura.
-88-
Centro de Errores
Nodo Elemento Da Hora Nivel Descripcin
13. Una visin global del cuadro de control.

El cuadro de control acabara teniendo una visin global del estilo que se muestra en la figura.
Situacin Tiendas
Nombre Tienda Nombre Tienda Nombre Tienda
Situacin de los procesos de negocio

Recepcin en la reposicin desde las tiendas Contabilizacin de albaranes Envo de la reposicin desde la central a las tiendas Envo de la documentacin desde tiendas a la central Envi de pedidos de compra a proveedores Verificacin de albaranes en almacenes
Con problemas Todas
Situacin Proveedores
Proveedor Proveedor
Registro de la compra
Jornadas pendientes de cerrar
Recepcin de las ventas desde las tiendas
Conexin de los vendedores mviles
Con problemas Todas
Replicaciones pendientes
TEST
Visin de una tienda
Conexin por terminal
Conexin Por emulacin
Recuperar Ventas
Replicar cierre jornadas
Control preventivo del sistema
Centro de Errores
Nodo Elemento Da Hora Nivel Descripcin
Relacin de alarmas del sistema
Relacin de avisos del sistema
Incidencias de Hot-Line pendientes
Relacin incidencias fuera de plazo de resolucin
Relacin de incidencias abiertas en plazo de resolucin
-89-
14. Proceso de apertura y cierre de jornada centralizado para el responsable de la tienda desde el servidor de local.
He elegido este ejemplo para citar procesos que pueden detectarse tanto en momento del funcional como al revisar la operativa. No se preocupe mucho en que momento lo hace. Para facilitar el trabajo del responsable de la tienda y evitarle pasar por todos los puestos de trabajo se le monta un proceso centralizado en el servidor para hacer en bloque el cierre y la apertura de todos los puestos de trabajo simultneamente. Es proceso no es ms que la llamada puesto a puesto y desde el servidor de sus respectivos procesos de apertura. El diseo de esta nueva funcin, aprovechando los procesos que ya tenemos diseados es tan simple que ni le voy a recomendar que lo haga como ejercicio adicional. Observe que los accesos a base de datos son ya SQL y que bastar informar los directorios de copia de los ficheros XML afectados con la direccin lgica de la red con el cdigo de mquina por delante.
15.
-90-
INTEGRACIN DE LA PARTE CLIENTE

1. mbito.
Para decidir la integracin de la parte cliente repasaremos proceso a proceso los diagramas de flujo resultantes de la arquitectura del sistema distribuido resolviendo y decidiendo en cada caso el modo de integracin. Dejo para el lector un anlisis ms exhaustivo de la especificacin de las piezas cliente ya que no nos aportara nada significativo al ejemplo distribuido
2. Configuracin del puesto de trabajo.

Se realizar de forma general para todos los programas que se arranquen en el puesto asociando una ficha de enviroment en formato XML a cada puesto.
3. Programas de mantenimiento de las entidades principales.

Montaramos un Framework. Obviamente este proceso muy convencional lo dejamos fuera de este ejercicio.
4. Piezas de consulta de tickets y logs.

Crearemos las piezas de consulta de tickets y logs de forma estndar. Dejaremos dos posibilidades de integracin: Un programa de consulta estndar que pida como parmetro interactivo el ticket a consultar en una lista desplegable. No hace falta decir que en un sistema distribuido los ticket de control estn catalogados. La integraremos en los programas de gestin especializados cuando convenga.
5. Integraciones de WorkFlow.
El seguimiento del pedido y su traspaso entre los puestos de trabajo desde la peticin del pedido al cliente pasando por el cobro y por la entrega del material permite un mini Work-flow montado sobre los programas interactivos de los puestos de trabajo. Un servicio pasivo de acceso al pedido permitir seleccionar los que cumplan un criterio de seleccin por estado de pedido: Registrndose.
Registrado. Cobrado. Servido.
La implementacin del Work-Flow se realizar por un componente visual tipo rejilla sobre el que se presentarn los pedidos pendientes en un estado y que peridicamente ir actualizando la informacin recibiendo un evento del fin del paso anterior. El acceso a cada pedido se har con doble clic del ratn sobre la lnea correspondiente El esquema resultante se muestra en la figura 80. Como no queremos usar ningn gestor de eventos, para implementar el evento, haremos que un hilo del programa que atiende a cada puesto de trabajo vigile un directorio pactado donde aparecer la orden de actualizarse con un pedido del paso anterior.
Captacin de pedido Pedido Registrado
Registrado
Proceso de cobro
Cobrado
Entrega del material
Figura Figura 80. 80.WorkFlow WorkFlowde de Pedido Pedido
Se instanciar en cada caso segn los siguientes criterios: Puesto de venta: los pedidos en estado de registrndose. Puesto de cobro: los pedidos en estado de registrado. Puesto de entrega del material: los estados de registrado y cobrado.
Los estados a listar se codificarn en la fichas de enviroment del programa que atiende al operador de cada puesto de trabajo.
Nota. Estoy de acuerdo con Ud. la aparicin del proceso de WorkFlow aqu es muy forzado, pero se trata de practicar.
6. Procesos de Integrados en cadenas Batch.

Aunque no se cite expresamente en cada caso se prevee para las cadenas batch una opcin de lanzamiento desde men que pida al operador los parmetros de la cadena.
6. 1. Obtencin de las rutas en almacn.

Desde la figura 22a. Montaremos un proceso batch que se puede lanzar por dos vas:
-92-
Automticamente por el Agente de Recepcin de la Reposicin cuando detecte al actualizar el ticket que ya han llegado todos. Incorpore esta funcin al diseo de este agente como prctica adicional. Manualmente desde un programa de integracin GUI para el lanzamiento de la preparacin de las rutas de retirada de la reposicin de almacn. Este programa incluir dos funciones: o La consulta del ticket. o La entrada de los parmetros de la cadena batch.
En la figura 81 se muestra un esquema de la arquitectura resultante.
Responsable
Consulta Entrada Estado del Parmetros Ticket de la cadena
Tiendas Recibidas
Agente Recepcin reposicin
Ticket Completo
Rutas de retirada
Figura Figura 81. 81. Obtencin Obtencin rutas rutas almacn almacn
6. 2. Preparacin del envo.
Desde la figura 22a. Incluir los procesos: Preparar bultos. Impresin de albaranes. Lista de envo. Actualizacin de stock. Envo a la tienda. Generar CD (recordar anlisis de consistencia).
Cuando haya que generar CD se notificar por cartero al responsable de hacerlo. Los CD se grabarn sobre disco en un directorio pactado. Desde all los grabar el responsable en el soporte fsico.
6. 3. Generacin de pedidos para proveedores.

Desde la figura 21. Incluir los procesos: Separar compras y reposicin. Envo al Almacn Central de la reposicin. Generacin de pedidos en la tienda Llamada al envo de pedido en la tienda
-93-
6. 4. Imputaciones del cierre de la jornada.

Desde la figura 42a se deducen los procesos: Cadena batch: Imputaciones del cierre de la jornada. Incluir los procesos. o Poner estado de cerrado. o Listado del resumen de ventas. o Envo de ventas a la central. Integracin grfica: Lanzamiento de las imputaciones del cierre de la jornada. Incluye los procesos: o Verificacin de si todos los puestos estn cerrados (Todos Cerrados? En la figura) o Dar aviso en caso de que no. o Lanzar el proceso batch anterior. Cliente back-ground para la recepcin de las ventas de las tiendas en la central. Incluir el lanzamiento de las interfcies con el resto de sistemas de informacin. Vase su descripcin en el apartado de integracin por clientes back-ground. Cadena batch para la inclusin de los logs (recuerde el apartado de Monitoring del captulo de administracin). Cadena batch para la integracin con el resto de sistemas de informacin.
El la figura 42a1 se muestra la arquitectura distribuida resultante.

Jornada Venta Tienda Servidor de Correo (Local)
Tiquet Cierre
Arqueo
R
F
Lanzamiento Imputacin Jornada
Imputacin de la Jornada Recepcin de ventas de las tiendas
Servidor de Correo (Central) Ventas Central
Responsable
Resumen Ventas
Carga de los logs Interfcies a otros S.I.
Figura Figura 42a1. 42a1. Proceso Proceso de de Cierre Cierre de de la la Jornada Jornada
El proceso batch para la imputacin de jornada se muestra en la figura 42a3.
-94-
Jornada Arqueo
Venta Tienda Servidor de Correo (Local) Envo Ventas a la Central
R
F
Poner Estado Cerrado
Listado Resumen Ventas
Resumen Ventas
Figura Figura 42a3. 42a3. Imputacin Imputacin del del cierre cierre de de la la jornada jornada
El resto de programas se muestra en su apartado de integracin correspondiente.
6. 5. Reconstruccin de la BD desde los logs de los puestos.

Esta cadena es la que ya se ha hablado en el captulo de administracin al hablar de back-up y reconstruccin..
7. Clientes Back-Ground.
7. 1. Acumulacin de las reposiciones enviadas por las tiendas.
Resulta de figura 16 y se integra como un hilo en el agente de reposicin desde tiendas.
7. 2. Seguimiento de las rutas de almacn.

Consultar las figuras 22a, 22b y 23a. All se explica tambin la arquitectura de los procesos.
7. 3. Obtencin fechas llegada.

Consultar la figura 23.
7. 4. Recepcin de las ventas de las tiendas.

Ha surgido al analizar dentro de las cadenas batch el cierre de la jornada de la figura 42a. Su diseo de muestra en la figura 42a4.
-95-
Responsable
Consulta Estado del Ticket
Ventas Tiendas Recibidas
Sleep
Recepcin Ventas en Ventral
Replicacin Ticket Jornadas
No
Si
Hay algo pendiente?
Lanzamiento Cadena S.I.
Interfcies a otros S.I.
Replicacin Cierre de Jornadas
Ventas Central
Figura Figura 42a4. 42a4. Recepcin Recepcin de delas lasventas ventas de de la la jornada jornada
Observe que el ritmo de incorporacin es a medida que llegan las ventas. De esta forma se consigue aprovechar la noche para adelantar la carga de forma que a primera hora de la maana ya este realizada y la informacin a disposicin del personal de la central o supervisores. Al proceso se le asocia un ticket de ventas recibidas de las tiendas para controlar y administrar el proceso. Este ticket ser multihoja y el estado deber tener valores del tipo: No recibido. Recibido. Recibido con error. Procesado. Procesado con error, etc..
El programa de consulta del ticket de ventas recibidas permitir al responsable el seguimiento de la explotacin del proceso. En la realidad se monta un programa especializado que adems de la consulta del ticket permite: La recuperacin de jornadas desde el local. Test de las comunicaciones aprovechando las opciones del cuadro de control de administracin, etc..
7. 5. Gestin de la conexin de los vendedores mviles.

Agrupar las funciones de la figura 50a. Tambin podra ser una cadena batch pero preferimos esta opcin ya que nos permitir una mayor flexibilidad de dialogo con el vendedor en caso de incidencias,
-96-
8. Clientes de integracin grfica.

8. 1. Las interfcies grficas de los componentes de presentacin a travs de PDA.
No hay que insistir en que corresponden a un punto de heterogeneidad en el diseo y programacin.
8. 2. Lanzamiento masivo de la replicacin de la agrupacin de productos, tratamiento manual y el seguimiento del xito.
Ha surgido al hablar de la replicacin de la agrupacin de productos y de su proceso de la consistencia.
8. 3. Lanzamiento de la preparacin de las rutas de retirada de la reposicin de almacn.

Se ha explicado en la cadena batch de obtencin de las rutas en almacn.
8. 4. Grabacin de CD.
Se ha explicado en la cadena batch de preparacin del envio.
8. 5. Entrada de un pedido de proveedor.

De la figura 23. Incluir las funciones: Validacin de la recepcin. Llamada al registro del pedido.
8. 6. Generacin de pedidos para proveedores.

Desde la figura 23. Incluir los procesos: Generacin de pedidos. Llamada al envo del pedido.
Podra ser tambin un proceso batch.
8. 7. Entrada de la reposicin en la tienda.

Desde la figura 21. Incluir los procesos: Validar la recepcin de la reposicin.. Registrar en stock.
8. 8. Inicio de jornada en el servidor de la tienda.

Desde la figura 41a. Incluir los procesos: Inicializacin. Tomar productos. Creacin del apunte de la jornada. Creacin de la venta de la jornada.
-97-
8. 9. Lanzamiento de las imputaciones del cierre de la jornada.

Apareci dentro del apartado de cadenas batch al analizar el proceso de cierre de la figura 42a. Su estructura se muestra en la figura 42a2. Aunque queda fuera del objetivo de este ejemplo aqu se deberan implementar funciones para: Forzar el cierre aunque algn puesto de trabajo tenga problemas. Operativas de recuperacin de averas del servidor o las cajas. Etc
Puede pensarlas y aadirlas como ejercicio adicional.
Tiquet Cierre
Todos Cerrados?
Si
Lanzar Imputacin Jornada
Imputacin de la Jornada
No
Aviso
Responsable
Figura Figura 42a2. 42a2. Lanzamiento Lanzamiento de de la la imputacin imputacin de de la la jornada jornada
8. 10. Inicio de jornada en el puesto de trabajo.
Desde la figura 41b. Da lugar a un programa con tres especializaciones, una por tipo de puesto de trabajo. Incluye las funciones: Inicio en el puesto. Inicializar el puesto segn su funcin. Consultar para obtener mayor informacin la descripcin funcional.
En el caso del puesto de venta habr de integrar tambin los procesos del anlisis de consistencia: Entrar fecha y hora manualmente. Se mostrar la actualmente registrada y se pedir la confirmacin o el cambio. Pedir la jornada. Se actuar igual que en el apartado anterior. Preguntar si se quiere registrar un cambio de productos a partir de CD.
-98-
8. 11. Cierre de jornada en el puesto de trabajo

Desde la figura 42b. Incluye los procesos: Verificar si se cumplen las condiciones de cierre, especializado por tipo de puesto de trabajo. Se registrar en la ficha de enviroment a que tipo de puesto se asocia ese ordenador. Poner estado de cerrado. Informa el ticket del servidor.
8. 12. Apertura y cierre de jornada en los puestos de trabajo desde el servidor de la tienda.
Es el proceso presentado en el captulo anterior dedicado a la administracin.
8. 13. Entrega del material

Desde la figura 45. Incluye los procesos: Preparacin del material. Impresin de albaranes. Registro para el mensajero. Impresin de la relacin para el mensajero. Acumulacin para las ventas. Notificacin a las tiendas del stock de repuesto.
El programa organizar el proceso segn dos lneas de trabajo: Preparacin del material propio. o Una consulta para saber el material a preparar. o Confirmacin de que el material se ha entregado. o Acumulacin del pedido servido a las ventas del da. Preparar material para otras tiendas. o Una consulta para saber el material a preparar. o Impresin del albarn de entrega con dos copias para el cliente y el transportista o Confirmacin de que el material se ha entregado. o Registro para el mensajero. o Impresin de la relacin para el mensajero. o Notificacin a las tiendas del stock de repuesto.
Las dos lneas de trabajo se montarn integradas en un nico programa para facilitar la navegabilidad ya que el almacenero deber compartir su tiempo entre las dos actividades.
8. 14. Captacin de pedidos

Desde la figura 44. Incluye los procesos de esa funcin.
8. 15. Cobro a clientes

Desde la figura 44. Incluye los procesos de esa funcin.
-99-
8. 16. Lanzamiento manual de la replicacin de la agrupacin de productos.

Se prev un opcin interactiva a travs de interfcie grfica para la peticin directa y manual desde las tiendas de replicacin de la agrupacin de productos. Puede ser el mismo programa de la central debidamente configurado.
8. 17. Gestin de la replicacin en emergencia.

Desde la figura 60. Incluye los procesos de: Generacin del CD. Lectura del CD.
Una opcin alternativa es montar dos programas separados.
8. 18. Impresin de pedidos de compra no enviados automticamente.

Normalmente se implementara dentro del programa de mantenimiento directo de pedidos que seguro existira en una instalacin real.
8. 19. Registro de albaranes directos.

Incluye los procesos dos reas: Reposicin. o Lectura del CD de la reposicin. o Registro manual Compras. o Registro manual
8. 20. Registro en bloque de los pedidos recogidos en papel.

Obviamente para cubrir las situaciones de emergencia que obliguen a usar los impresos de papel.
8. 21. Cuadro de control de administracin.

Su descripcin ya se ha explicado anteriormente. Recuerde que debe configurarse en funcin del usuario autentificado.
9. Organizacin de mens.
Todas estas funciones cliente deberan organizarse en tres mens operativos: Central. Servidor de tienda Puesto de trabajo, especializando por configuracin y autentificacin del usuario cada tipo de puesto.
Que se personificaran de acuerdo con los derechos del usuario autentificado.
-100-
Obviamente este trabajo, que reflejaramos en un jerrquico, queda fuera de los objetivos de este ejemplo.
-101-
OTROS EJERCICIOS
Si desea hacer algn ejercicio ms le propongo otros temas en el entorno del mismo ejemplo. Estudie una arquitectura a dos niveles y compar ventajas e inconvenientes con la de tres que hemos presentado. Le adelanto que probablemente esta opcin tendra problemas para usarse con tiendas franquiciadas ya que lo normal es que los sistemas de informacin de las franquicias sean diferentes a los del franquiciador. Intente pensar una evolucin de la arquitectura de tres niveles a la de dos con el mnimo coste posible. o Niveles: Host. Cliente. o Pistas. Las funciones del funcional no cambian. Los servicios si? Recuerde el concepto de servicio pasivo. Recuerde el concepto de envolvente y de Web Service. Incluir autoventa, venta por interfase, venta por WEB y por fichero directo desde una aplicacin del cliente. o Aclaraciones. Autoventa es dar la posibilidad que el cliente se marque sus propios productos y vaya directamente a la caja. Venta por interfase es recibir directamente un documento del cliente, probablemente generado desde una aplicacin propia, con su pedido. o Pistas: Intente usar todos los procesos ya diseados que pueda. Tendr que pensar una solucin para el cobro ya que el cliente no est presente. Observe que la venta por interfase y la salida de la WEB se parecen mucho. Piense en XML. Incluir la gestin del personal y el control de presencia. No entre en la nmina a la que solo pasar las horas trabajadas que se obtienen desde ese control de presencia. o Ideas: El personal debe guardarse en la central y en cada tienda. Deber decidir donde est el foco de mantenimiento de esta replicacin, en la tienda o en la central. El personal puede cederse entre tiendas y habr que controlar la liquidacin de horas entre ellas. Puede incluir control de costes y rendimientos por tramos horarios segn la venta generada y las horas de personal presente en ese momento. Realizar un anlisis de administracin ms detallado estableciendo precondiciones de posibles entornos reales y herramientas disponibles. Pensar en las modificaciones a realizar en la arquitectura introduciendo un procesador distribuido que elimine agentes.
INDICE DE LA TERCERA PARTE

PRESENTACIN SISTEMA DE INFORMACIN PARA LA GESTIN DE VENTAS DE UNA EMPRESA DE DISTRIBUCIN.
1. 2. 3. 1. 2. 1. 2. 3. 1. 2. 3. 4. 5. 6. 1. Enunciado. Posibles ampliaciones. Observaciones y Recomendaciones. Identificacin de clases. Identificacin de Atributos. Visin general. Modulo de Stock. Modulo de Ventas. Arquitectura de datos. Adaptacin del diseo funcional. Diseo de la Lgica de datos. Los vendedores mviles. Especificacin. Analizar rendimiento.
2 3
3 5 5
MODELO DE OBJETOS
6
6 9
DISEO FUNCIONAL
10
10 10 16
ANALISIS DE DATOS
26
26 27 30 30 32 32
CREACIN DE LA ARQUITECTURA DISTRIBUIDA

Identificacin de funciones y distribucin de la funcionalidad por niveles. 1. 1. Host (administracin y almacn central). 1. 2. Servidor de la tienda. 1. 3. Todos los puestos. 1. 4. Puesto de almacn. 1. 5. Puesto de venta. 1. 6. Puesto de Cobro. 1. 7. Funciones especificas de los vendedores mviles. 2. Separar funciones e identificacin de servicios en el entorno de stock. 3. Separar funciones e identificacin de servicios en el entorno de ventas. 4. Definir la comunicacin cliente / servidor. 5. Definicin de la arquitectura de servidores en el entorno de stock. 6. Definicin de la arquitectura de servidores en el entorno de ventas. 7. La opcin de utilizar el procesador distribuido. 8. Definicin de la arquitectura distribuida en el entorno de stock. 9. Definicin de la arquitectura distribuida en el entorno de ventas. 10. Map to reality. 10. 1. Localizacin. 10. 1. 1. Central. 10. 1. 2. Servidor de Tienda. 10. 1. 3. PC del Vendedor mvil. 10. 2. Configuracin. 10. 3. Analizar Rendimiento.
33
33 33 33 34 34 34 35 35 35 38 39 39 41 43 44 47 53 53 53 53 54 54 54
ANALISIS DE CONSISTENCIA
1. 2. Utilizacin de XML. Circuito de Replicacin de Productos. 2. 1. Garantizar la semntica exactamente una vez. 2. 2. Situacin de emergencia.
55
55 55 55 55
-103-
3. 4.
Semntica del servidor de correo. Semntica del resto de servidores. 4. 1. Recepcin de la reposicin. 4. 2. Obtencin de la fecha de entrega. 4. 3. Recepcin de albaranes de proveedores. 4. 4. Contabilizacin de albaranes. 4. 5. Envo de pedidos a proveedores. 4. 6. Registro de la compra. 4. 7. Consulta y modificacin de stock. 4. 8. Integracin de proveedores. 4. 9. Envolvente contable. 4. 10. Servidores de fecha y hora. 4. 11. Alta de clientes. 4. 12. Consulta de clientes. 4. 13. Obtencin de clientes no disponibles. 4. 14. Envo de la reposicin. 4. 15. Incorporacin de pedidos propios. 4. 16. Envo de la documentacin. 4. 17. Gestin del stock de apoyo. 4. 18. Asignacin de stock a pedidos mviles. 5. Control de la situacin de emergencia. 5. 1. Agrupaciones de trabajo. 5. 1. 1. Servicios desacoplados montados por agente. 5. 1. 2. Por la situacin en el entorno de administracin. 5. 1. 3. Por localizacin en el servidor del almacn. 5. 1. 4. Por localizacin en el servidor Tienda y conexin con otras tiendas. 5. 1. 5. Por localizacin en el servidor de la Tienda. 5. 2. Semforos de disponibilidad y vigilantes. 5. 3. Control de la situacin de emergencia. 6. Anlisis de la situacin de emergencia para el mdulo de stock. 7. Circuito de Ventas.
58 58 58 58 58 59 59 59 59 59 59 60 60 60 60 60 60 60 61 61 61 61 61 61 61 62 62 62 62 63 68
DISEO DE ADMINISTRACIN
1. 2. 3. 4. 5. 6. 7. 8. mbito. Organizacin del soporte. Criterios de Back-up, reconstruccin y eliminacin histrica. Monitoring. Servidores de programas. Cuadro de mandos. Arquitectura del cuadro de control. Zona de control de las comunicaciones del cuadro. 8. 1. Disponibilidad de cada nodo interno. 8. 2. Disponibilidad del enlace con proveedores. 8. 3. Comandos. 9. Tomar direcciones IP variables. 10. Zona de control de procesos del cuadro. 10. 1. Recepcin de la reposicin. 10. 2. Envo de la reposicin. 10. 3. Envo de pedidos de compra a proveedores. 10. 4. Contabilizacin de albaranes. 10. 5. Envo de la documentacin. 10. 6. Verificacin de albaranes. 10. 7. Registro de la compra. 10. 8. Pedidos pendientes de recibir. 10. 9. Jornadas pendientes de cerrar. 10. 10. Recepcin diaria de ventas. 10. 11. Control de conexin de los vendedores. 10. 12. Replicaciones pendientes. 10. 13. Comandos. 11. Zona del cuadro de control del sistema y de incidencias de usuario. @EMG/10 - Enric Martnez Gomriz
72
72 72 73 74 74 75 75 75 76 77 78 78 79 80 80 81 81 81 82 82 83 83 84 85 86 86 87
-104-
12. Zona del cuadro de control para el centro de errores. 13. Una visin global del cuadro de control. 14. Proceso de apertura y cierre de jornada centralizado para el responsable de la tienda desde el servidor de local.
88 89 90
INTEGRACIN DE LA PARTE CLIENTE

1. 2. 3. 4. 5. 6.
91
mbito. 91 Configuracin del puesto de trabajo. 91 Programas de mantenimiento de las entidades principales. 91 Piezas de consulta de tickets y logs. 91 Integraciones de WorkFlow. 91 Procesos de Integrados en cadenas Batch. 92 6. 1. Obtencin de las rutas en almacn. 92 6. 2. Preparacin del envo. 93 6. 3. Generacin de pedidos para proveedores. 93 6. 4. Imputaciones del cierre de la jornada. 94 6. 5. Reconstruccin de la BD desde los logs de los puestos. 95 7. Clientes Back-Ground. 95 7. 1. Acumulacin de las reposiciones enviadas por las tiendas. 95 7. 2. Seguimiento de las rutas de almacn. 95 7. 3. Obtencin fechas llegada. 95 7. 4. Recepcin de las ventas de las tiendas. 95 7. 5. Gestin de la conexin de los vendedores mviles. 96 8. Clientes de integracin grfica. 97 8. 1. Las interfcies grficas de los componentes de presentacin a travs de PDA. 97 8. 2. Lanzamiento masivo de la replicacin de la agrupacin de productos, tratamiento manual y el seguimiento del xito. 97 8. 3. Lanzamiento de la preparacin de las rutas de retirada de la reposicin de almacn. 97 8. 4. Grabacin de CD. 97 8. 5. Entrada de un pedido de proveedor. 97 8. 6. Generacin de pedidos para proveedores. 97 8. 7. Entrada de la reposicin en la tienda. 97 8. 8. Inicio de jornada en el servidor de la tienda. 97 8. 9. Lanzamiento de las imputaciones del cierre de la jornada. 98 8. 10. Inicio de jornada en el puesto de trabajo. 98 8. 11. Cierre de jornada en el puesto de trabajo 99 8. 12. Apertura y cierre de jornada en los puestos de trabajo desde el servidor de la tienda. 99 8. 13. Entrega del material 99 8. 14. Captacin de pedidos 99 8. 15. Cobro a clientes 99 8. 16. Lanzamiento manual de la replicacin de la agrupacin de productos. 100 8. 17. Gestin de la replicacin en emergencia. 100 8. 18. Impresin de pedidos de compra no enviados automticamente. 100 8. 19. Registro de albaranes directos. 100 8. 20. Registro en bloque de los pedidos recogidos en papel. 100 8. 21. Cuadro de control de administracin. 100 9. Organizacin de mens. 100
OTROS EJERCICIOS INDICE DE LA TERCERA PARTE
102 103
-105-

TOTAL Exemple

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

TOTAL Exemple

Загружено:

Авторское право:

Доступные форматы

Parte 3 UN EJEMPLO

@EMG/10 - Enric Martnez Gomriz

@EMG/10 - Enric Martnez Gomriz

SISTEMA DE INFORMACIN PARA LA GESTIN DE VENTAS DE UNA EMPRESA DE DISTRIBUCIN.

@EMG/10 - Enric Martnez Gomriz

@EMG/10 - Enric Martnez Gomriz

Pertenece a Ped.Venda Hecha por

Tiene stock stock

Proveedor Pertenece a Ped.Compra

@EMG/10 - Enric Martnez Gomriz

Productos por proveedor Proveedores Vendedor Jornada

Posicin productos en almacn Productos Jornada

Posicin productos en almacn Transportista

Gestin Stock Stock Arqueo Proveedores

Fecha y hora de referencia

Stock Arqueo S.I. Venta Venta

Clientes Resumen Ventas Arqueo Cajero Recibo Pedido

@EMG/10 - Enric Martnez Gomriz

Posicin productos en almacn Productos

@EMG/10 - Enric Martnez Gomriz

@EMG/10 - Enric Martnez Gomriz

Productos por tienda Productos a pedir

Seleccin material a reponer

Separar Compras y Reposicin

Compras Envo al Almacn Central

Material a Reponer Productos Registro en stock

Figura Figura 21. 21. Reposicin Reposicin en en la la tienda tienda

El segundo diagrama corresponde a la parte de la central y se muestra en la figura 22

@EMG/10 - Enric Martnez Gomriz

Obtencin de las rutas en almacn

Albarn Preparar bultos

Relacin para transportista

@EMG/10 - Enric Martnez Gomriz

Productos Necesidades de Compra Proveedor

Obtencin Fechas de llegada Pedido Compra

Generacin pedido Pedidos Pendientes Stock

Envo al proveedor Albarn Proveedor

Registro compra Interfcie contable Entrega Validada

Recepcin Validacin recepcin Incidencias

Figura Figura 23. 23. Proceso Proceso de de Compras Compras

El esquema del proceso resultante se muestra en la figura 23a.

@EMG/10 - Enric Martnez Gomriz

Productos Productos por proveedor Necesidades de Compra Proveedor Pedido Compra

Albarn Proveedor Seleccin compras a realizar Compras

Stock Ruta entrada

Seguimiento de la ruta de entrada

Fecha y hora de referencia

Vendedores Inicio Jornada Proceso de Venta

Clientes Arqueo Cajero Recibo

Venda Albarn Resumen Ventas

Figura Figura 40. 40. Proceso Proceso de de Venta Venta

Sincronizar fecha y hora

Creacin Apunte Jornada

Venta Resumen Ventas Venta Central

Venta por pedido Productos

Cierre del puesto

Clientes Vendedores Recibo Albarn

Stock Arqueo cajero

@EMG/10 - Enric Martnez Gomriz

Apertura del puesto

Cierre del puesto

Stock Vendedores Albarn

@EMG/10 - Enric Martnez Gomriz

Apertura del puesto