Diseño del canal de ventas por internet integrado a SAP R/3 para Mathiesen S.A.C. (página 2)

Partes: 1, 2

5
Super conjunto de actividades y flujos aplicados a un proceso específico.
5.5.6.- Promoción y publicidad

La promoción y publicidad del nuevo canal de ventas, en una primera instancia estará a cargo de los
operadores comerciales, ya que ellos serán quienes realizarán remotamente las primeras notas de ventas
en las dependencias físicas de los clientes y serán los encargados de mostrar cómo opera. Luego, se
tiene contemplado invitar a las principales empresas a probar un demo del canal y se les pedirá su
opinión acerca de la operación del sitio, con el fin de analizar posibles mejoras. Posteriormente, se podrá
promocionar y publicitar el canal por medio de charlas a ciertos clientes importantes, siendo los
operadores comerciales los encargados de dar a conocer el sitio a su cartera de clientes. Por último, se
realizará un lanzamiento oficial, en el que se invitarán a ciertos clientes y revistas de tecnologías de
información presentes en Chile enfocadas a negocios, de modo de potenciar la noticia y divulgarla a
actuales y potenciales clientes.

5.5.7.- Distribución

El nuevo canal de ventas actualizará en línea los nuevos pedidos, o sea los que se encuentran listos para
ser despachados, y de ahí en adelante el proceso seguirá su curso tradicional, es decir cada 5 minutos
aproximadamente el jefe de despacho verá en SAP cuáles son las órdenes de venta liberadas, luego
realizará el ruteo de los camiones, cerrando al medio día las órdenes a despachar en la tarde y a las 17
horas las que serán despachadas al siguiente día.

III.- Modelo de la situación actual aplicando patrones de negocio.

La experiencia muestra que el diseño o rediseño de procesos lleva a soluciones similares en procesos
del mismo tipo, los cuales se repiten en diferentes organizaciones, de la más variada naturaleza, y que la
manera en que ellos se realizan en las empresas líderes –de acuerdo a lo que se denominan "mejores
prácticas"– es muy parecida. El señor Oscar Barros en su libro “Rediseño de Procesos de Negocios
mediante el uso de Patrones” [1], aplica este concepto, construyendo varios modelos Macro, los cuales
han sido validados por medio de su especialización, detallando actividades y flujos a procesos en
dominios específicos. La ventaja principal de usar esta estructura en el diseño de la arquitectura que
definirá el nuevo canal de ventas de Mathiesen, radica en el hecho de mejorar los procesos actuales,
internalizando las mejores prácticas, sin tener que empezar desde cero, lo cual tiene obvias implicancias
en cuanto al aumento de productividad. La diagramación del tipo IDEFO mediante el uso de patrones5
(ver Figura N°5), es la técnica que mejor se adecua a este enfoque, pues permite analizar los procesos
desde su comportamiento global, detallando cada actividad en niveles inferiores hasta llegar al grado
requerido de detalle.
Control: Orienta el comportamiento
de esta actividad.
Entrada:
Información
o Física
Salida
Información
o Física

Mecanismos: Recursos tecnológicos y
otros para desarrollar la actividad

Figura N°5: Diagramación Modelo Estructurado.

Para el proceso de ventas tradicionales, se adaptará el patrón Macro1vsd, apoyado con el software
Bpwin. Este patrón se encuentra en el documento “Patrón del Proceso Venta y Distribución de Stock” [2],
y es un caso especial del Macro 1 “Provisión de un Bien o Servicio”.

La venta tradicional la realizan operadores y vendedores comerciales directamente en terreno o vía
telefónica con clientes de su cartera, (ver Figura N°6). El precio, cantidad y forma de pago se negocia
directamente con el consumidor, para luego interactuar con SAP y crear la respectiva nota de venta,
ingresando los antecedentes del cliente y del producto al sistema.
Figura N°6: Venta al Cliente

La primera actividad de la Figura N°6, “Venta Telefónica”, se detalla en la Figura N°7. Un asistente
comercial es el responsable de derivar el llamado del cliente a su correspondiente operador comercial o
representante de ventas. El cual se encarga de crear en ese mismo momento la nota de venta. En el
caso de ser un cliente nuevo se solicitan algunos antecedentes, como el balance comercial y el pago de
IVAs de sus últimas compras, a fin de que el personal de finanzas evalúe el límite de crédito a otorgar.

Figura N°7: Venta Telefónica
Algo distinto ocurre en el caso de las ventas que se realizan en terreno (Figura N°8), pues la creación de
la nota de venta se realiza en dependencias de la empresa, en un momento posterior a la negociación y
es por esta razón que se incurre en el riesgo de trabajar simultáneamente sobre un mismo stock.
Los flujos que salen de la actividad “Creación nota de venta” de las Figuras N°7 y N°8, son los siguientes:
? Mensaje pedidos liberados: Aviso que se genera en bodega al aprobarse un pedido para su despacho.
? Cambio de estado clientes pedidos y productos: Actualización en la base de datos de SAP de la nueva
transacción aprobada (pedido, monto de crédito del cliente y rebaja de stock).
? Mensaje pedido a decisión: Pedidos que deben someterse a distintas validaciones para decidir
aprobarlos o rechazarlos. Se traduce en un control que gatilla la actividad “Ingreso de datos de Clientes y
Productos en SAP” de la Figura N°9.
? Pedidos fallidos: Pedidos que por alguna razón no pudieron ser satisfechos directamente en SAP.

Figura N°8: Venta en Terreno

La figura N°9 comienza cuando el vendedor ingresa los antecedentes del cliente, pedido y producto para
que el sistema decida aprobación, rechazo o derivación a decisión manual.
De esta manera el pedido pasará por una verificación de disponibilidad del producto y un análisis de
riesgo crediticio.
Por otra parte, al momento de ingresar un pedido, el sistema devuelve distintas clasificaciones de riesgo,
las cuales fueron creadas manualmente y no se han actualizado a la fecha.
El personal de finanzas, cuando dispone de los antecedentes comerciales de los clientes, calcula
informalmente el límite de crédito en una planilla excel, según criterios detallados en el capítulo siguiente
y que se basan principalmente en el balance comercial de cada empresa. De excederse el pedido en el
límite de crédito asignado a cada cliente o al tener clientes morosos o al cambiar la modalidad con la que
pagará a la empresa, la decisión de aceptación o rechazo del pedido será derivada al personal de
finanzas, el cual actuará en base a su criterio y experiencia para liberar o bloquear la venta. Esta
situación ocurre aproximadamente para el 50% de los pedidos cursados en SAP y de no liberase la venta
(aproximadamente en el 5% de los casos), el operador comercial
–principal interesado en concretar la
venta– acude al departamento de finanzas para tratar de revertir la situación, produciéndose en no pocos
casos, fuertes diferencias de opinión.

Figura N°9: Decisión Pedidos
IV.- Diseño de la arquitectura e-Business
1.- Modelo del diseño de la arquitectura
Para realizar el diseño de la arquitectura se utilizarán los patrones que aparecen en el documento [3], en
donde el autor especializa la actividad “Venta Internet” (Figura N°10), desde el patrón “Venta y
distribución de stock” [2].

Figura N°10: Venta Internet
De la figura anterior se detallarán las actividades “Búsqueda de información, verificación cliente y
selección pedido” (Figura N°11) y “Procesamiento automático pedido” (Figura N°12).
En el primero de los casos el navegante visitará la página viendo información de la empresa y los
productos disponibles.
Si el cliente desea conocer los precios de los distintos productos, el browser pedirá que ingrese login y
password, y mediante el “Controlador de interacción” iniciará el procesamiento de autenticación por
medio del flujo “Mensaje verificación ingreso cliente”.
El flujo anterior pasará por la actividad “Lógica Verificación cliente y Precio”, en donde se verifica el
password y se transfieren los datos de los productos y de los precios a la actividad “Lógica Interfaz
Usuario” para que se genere la página HTML con los precios para el cliente particular.
También en este proceso se llevará a cabo el almacenamiento de los datos de sesión en memoria y se
actualizarán los productos seleccionados en el carro de compras. Este tipo de datos sólo persistirá
durante el período que dure la sesión.

Figura N°11: Búsqueda de Información Verificación Cliente y Selección Pedido
Cuando el cliente completa el pedido definitivo y se decide a comprar comenzará el proceso de decidir la
aprobación o rechazo del pedido por medio del flujo ”Invocación procesamiento SAP”.
De igual modo, el controlador de interacción se encargará de grabar el pedido en tablas SAP por
intermedio del flujo llamado “Grabación pedido a SAP”, con el fin de ir construyendo un repositorio de
datos, el cual podrá ser procesado a futuro para analizar el comportamiento de los clientes.
Para llevar a cabo la decisión del pedido, el “Controlador de interacción” de la Figura N°13, mandará el
flujo llamado “Invocación remota a lógica de crédito SAP” a la actividad “Lógica de otorgamiento de
crédito”, y de manera análoga el flujo “Invocación remota a lógica de stock SAP” activará la lógica de
disponibilidad y rebaja de stock.

La decisión de aprobación o rechazo de la compra irá en el flujo “Decisión pedidos (crédito, stock)” y se
informará al cliente mediante “Página HTML (respuesta a pedidos)” de la Figura N°11.
Figura N°12: Procesamiento Automático Pedido

El “Controlador de interacción” realiza una serie de otras actividades:

? Cuando el pedido del cliente ha sido aceptado, genera “Mensaje pedidos liberados” y “Cambio de
Estado Clientes y pedidos”, para que se grabe el nuevo pedido en SAP y se rebaje el stock del producto
comprado, así también se actualizará el crédito disponible. De ahí en adelante la venta seguirá el curso
tradicional.
? Cuando el pedido requiere estudio por algún cambio en las condiciones de crédito, genera “Pedidos a
finanzas”.
? Cuando el pedido no se pudo resolver por cualquier motivo, genera “Pedidos derivados a O.C.” para
que el operador comercial realice un procesamiento tradicional.
Figura N°13: Decisión pedidos Internet – SAP

Por otra parte, en la Figura N°14 se detalla el “Cálculo de parámetros de crédito”. Estos parámetros
servirán como input para el otorgamiento de crédito en SAP.
Se tiene contemplado como un periodo razonable, que la clasificación y la determinación de la línea de
crédito, sean actualizados semestralmente por el personal de finanzas en una Intranet Corporativa.
Figura N°14: Cálculo de Parámetros Crédito

2.- Lógica de apoyo a la arquitectura e-Business
2.1.- Determinación de la Clasificación de Crédito

Cada uno de los clientes de Mathiesen cuenta entre sus atributos con una clasificación crediticia, que
define la confiabilidad que la empresa puede depositar en la capacidad de pago de sus clientes. Esta
clasificación es definida por Mathiesen de acuerdo a tres variables. (En el Anexo N° 1.1 se encuentra el
detalle de las características de las diferentes clasificaciones)
1. Deuda morosa histórica del cliente
2. Protestos de los pagos del cliente
3. Propietarios del cliente

A fin de estructurar el manejo de estas variables para que puedan ser incluidas en la lógica programada
del proceso a automatizar, se les asigna valores según los siguientes criterios:

? DDME (días existentes de deuda morosa)
Variable cuantitativa que indica históricamente el tiempo (en días), que el cliente ha presentado
morosidad en el pago de sus deudas.

? DMSP (deuda morosa sin plan de pago)
Variable cualitativa que define la situación de pago que ha presentado un cliente con deuda morosa. Se
asigna el valor 1 si el cliente tiene deuda morosa sin plan de pago, y el valor 2 si el cliente presenta
deuda morosa con prórrogas reiteradas.

? Protestos
Variable cualitativa que indica la situación del cliente en cuanto a la presentación de protestos a sus
pagos. Los valores asignados a esta variable son los mostrados en la Tabla N°8.
Tabla N°8: Situación Protestos

? Propiedad
Variable cualitativa que discrimina a los clientes según la organización a la que pertenecen. (Ver Tabla
N°9).
Tabla N°9: Situación Propiedad

Utilizando de manera lógica las variables recién definidas, Mathiesen determina para cada cliente su
clasificación crediticia, representada por una letra para los distintos casos.
Se identifican las siguientes clasificaciones6:
6
Este proceso se encuentra explicado con mayor detalle en el Anexo N° 1.1

Tabla N°10: Clasificación Crediticia de los Clientes
En el Anexo N° 2.1 se muestra la lógica de este proceso en lenguaje seudo-estructurado. Esta lógica
será la base para una posterior programación que automatice el proceso en una Intranet.
2.2.- Determinación del Límite para el Monto del Crédito
Paralelamente a la determinación de la clasificación crediticia de los clientes, Mathiesen define el monto
máximo de crédito disponible (MC) para ellos, atendiendo a ciertos parámetros comerciales del cliente y a
algunas variables cualitativas.
Aspectos Cuantitativos
En general, el límite de crédito se determina en base al balance comercial del cliente, aunque en no
pocos casos se recurre a otras fuentes de información, tales como DICOM, estimaciones cualitativas y
minoritariamente apoyo mutuo con los competidores.
Para los clientes que presentan balances comerciales se calcula el siguiente algoritmo en una planilla
excel:
1) Se pondera por 0.2 el monto total de las compras realizadas por el cliente en los últimos tres meses,
asegurando de esta manera no entregar un crédito que supere el 20% de tal cantidad.
2) Se determina las utilidades del cliente en el último año.
3) La tercera variable depende de la relación entre el pasivo exigible del cliente y su patrimonio:
? Si los pasivos exigibles son menores al patrimonio, se entregará un crédito no superior al 20% de este
último.
? Si los pasivos exigibles están entre una y dos veces el patrimonio, se entregará un crédito no superior
al 15% de este último.
? Si los pasivos exigibles están entre dos y tres veces el patrimonio, se entregará un crédito no superior
al 10% de este último.
? Si los pasivos exigibles son superiores a tres veces el patrimonio, no se entregará crédito al cliente
(MC=0).
El promedio simple de los tres valores recién obtenidos determina la línea de crédito del cliente, la que
además debe ser ajustada según variables cualitativas definidas en la Tabla N°11.

Aspectos Cualitativos

Se designa una calificación para cada cliente en dos ámbitos: riesgo del cliente y riesgo del sector
económico al que pertenece.
Para determinar esa calificación se utiliza en ambos casos la escala ilustrada en la Tabla N°11.
Tabla N°11: Escala de Riesgo Crediticio
Si el promedio simple de las dos calificaciones anteriores es menor a tres, la línea de crédito determinada
cuantitativamente se castiga en un 25% (se multiplica por 0.75).

Restricción
Finalmente, se restringe el crédito obtenido determinando que no puede sobrepasar el 10% del
patrimonio de Mathiesen.

Un par de ejemplos pueden ser consultados en el Anexo N°1.2 del presente informe. Además, en el
Anexo N°2.2 se encuentra la lógica asociada a este proceso en lenguaje seudo-estructurado.

2.3.- Otorgamiento del Crédito (SAP)
Cada compra que realiza un cliente de Mathiesen está sujeta a la clasificación determinada anteriormente
y según ésta se le asignan distintos montos de crédito, el cual no deberá exceder el límite total. Las
condiciones establecidas en SAP para cada categoría se pueden observar en la siguiente Tabla N°12
Clasificación

A+

A

B

B-

C
Cliente

Prime

Bueno

Normal

Problema

Riesgoso
Tipo de Pago

Crédito
75.000
25
30
45
3
50.000
15
30
45
3
25.000
10
7
30
3
10.000
10
5
15
3
0
Condiciones

Valor máximo de venta ($US)
% tolerancia
PA Días tope
Días tope antigua
Nivel de reclamación
Valor máximo de venta ($US)
% tolerancia
PA Días tope
Días tope antigua
Nivel de reclamación
Valor máximo de venta ($US)
% tolerancia
PA Días tope
Días tope antigua
Nivel de reclamación
Valor máximo de venta ($US)
% tolerancia
PA Días tope
Días tope antigua
Nivel de reclamación
Valor máximo de venta ($US)

Tabla N°12: Condiciones según Clasificación Crediticia

En donde7
? % tolerancia: es la cantidad porcentual que puede excederse un cliente por sobre su línea de crédito.
? PA (Partida Abierta) días tope: es el promedio permitido de días con deudas vencidas del cliente para
no bloquear el actual pedido.
? Días tope antigua: es la máxima cantidad permitida de días desde que ha vencido la deuda más
antigua del cliente para no bloquear el actual pedido.
? Nivel de reclamación: se refiere al número permitido de cartas por deuda que se le ha enviado al
cliente antes de bloquear su crédito.

En el Anexo N°2.3 se encuentra la lógica asociada al proceso de otorgamiento de crédito en lenguaje
seudo-estructurado.

Con el fin de realizar un proceso transparente y no tener replicación de recursos, esta lógica no se
programará, sino que tendrá que ser integrada a la nueva aplicación.

V.- Diseño de los componentes e-Business
1.- Derivación de los casos de uso y sus escenarios

El diseño de la arquitectura del sitio presentada anteriormente permitió identificar los procesos que serán
apoyados con tecnología Internet. Para pasar de tal arquitectura a una definición de los requerimientos
que deben satisfacer los componentes (y siguiendo con la metodología ilustrada en la Figura N°3), se
utilizarán los Casos de Uso, los cuales serán detallados mediante el lenguaje UML (Unified Modeling
7
En el Anexo N°1.3 se describen con más detalle las condiciones de bloqueo de crédito impuestas por
Mathiesen

Figura N°15: Caso de Uso “Seleccionar Pedido”
Language), el cual permite un enfoque orientado a objetos que llevará a definir con precisión los
componentes a automatizar.
Concretamente, a partir de los modelos de la arquitectura e-Business presentados en Figuras N°11 a la
N°14 se derivan los casos de uso de las Figura N°15, N°16, N°17 y N°18, apoyados con el software
Rational Rose.
Figura N°16: Caso de uso “Decisión Pedidos SAP”

La relación < < includes>> de la Figura N°16 indica que el caso “Atención Pedido” incluye el caso
“Decisión Pedidos” para su ejecución. Esto significa que para atender completamente un pedido será
necesario invocar la lógica de SAP para que tome la decisión sobre el otorgamiento de crédito y la
disponibilidad de stock.

Por otra parte, en una Intranet un usuario de finanzas atenderá los pedidos que por alguna razón (cambio
de condiciones de pago, fallas del sistema, etc.) quedaron para estudio de crédito, liberando o
bloqueando los pedidos según corresponda.

De la misma manera un usuario de finanzas semestralmente invocará las lógicas de clasificación
crediticia y del cálculo del límite de crédito para cada cliente. Este proceso derivará el caso de uso
llamado “Cálculo de parámetros”.
? Entity: Clases que describen por medio de atributos las
representadas en la aplicación por medio de métodos u
entidades que serán
operaciones. También ilustra
los servicios que se proveerán a partir de los datos almacenados para atributos de objetos en SAP
(particularmente se muestran los nombres de las tablas relacionales de SAP que serán abordadas). Se
simboliza como:
? Control:
requerimiento
del “Controlador
Clases que ejecutan lógica, tanto de presentación como del negocio, a
de otras; una clase particular de control es aquella que implementa la función
de interacción” el cual dirige distintos flujos computacionales que utilizará la
adaptan al caso particular por medio del mecanismo

: Interface
aplicación. Se simboliza como:

? Interface: Otro tipo de clases que se
de estereotipo. Se simboliza como:
Figura N°17: Caso de Uso “Otorgar Crédito a Estudio”

Figura N°18: Caso de Uso “Calcular Parámetros”

2.- Identificación de clases y su interacción

2.1- Clases de objetos genéricas

A continuación se detallan las clases de objetos que materializan los nuevos componentes del canal de
ventas por Internet y de la Intranet de la empresa, adoptando la clasificación de UML, que las divide en:

? Boundary: Clases a través de las cuales un usuario interactúa con la aplicación; en este caso serán
las páginas invocadas y desplegadas por medio de un browser, las cuales serán de ingreso o de
respuesta de pedidos. Se simboliza como:

2.2- Realización de los casos de uso
Las relaciones y la lógica ligan las actividades descritas por medio de diagramas de secuencia, lo que
también corresponde a una realización de los casos de uso descritos con anterioridad. Tales diagramas
se muestran en las Figuras N°19, N°20, N° 21 y N°22, y representan una buena aproximación al diseño
de las clases y sus interacciones y tiene, implícitamente una asignación de responsabilidades.
Cuando un cliente ha navegado por el sitio de la empresa informándose de las novedades y de los
productos disponibles y desea entrar a la “tienda virtual” como un nuevo comprador, entonces se dará
curso al primer caso de uso llamado “Seleccionar Pedido” (Figura N°19), para lo cual será necesario
que el nuevo cliente se registre. Luego la clase de control “Registrar” informará por medio de la misma
página y por mail, la existencia de un nuevo cliente al respectivo operador comercial de su cartera
(asignado según la información del rubro de la “empresa cliente”), y de verificar que es una empresa real,
se le informará su password por medio de mecanismos de encriptación con las llamadas “llaves públicas
y privadas”. No se automatiza el registro de clientes por un tema meramente estratégico, pues dada la
alta competencia del mercado será conveniente dar acceso a la información de precios sólo a potenciales
clientes, previamente verificados.
Si se trata de un cliente registrado, entonces él ingresará inmediatamente su login y password, (teniendo
tres posibilidades de errar). Estos datos de autentificación serán validados por medio de los RFC
(llamadas remotas a las funciones de SAP). La integración (Internet – SAP) se desarrollará mediante un
tipo de “midleware” o conector, cuya elección se tomará cuando se detalle el diseño de la aplicación
(Subcapítulo 4).
El comprador ingresará el ítem del producto seleccionado en el carrito de compras, el cual será manejado
con variables de sesión, útiles para almacenar en forma unívoca la información temporal para cada
comprador. Específicamente la clase de control “Seleccionar” será la encargada de ingresar en la clase
definida por medio del mecanismo de estereotipo “Session” el producto y la cantidad requerida. Luego se
actualizará la nueva sesión y se enviará a la página de respuesta al cliente, quien tendrá la libertad de
seguir agregando productos, eliminarlos o confirmar su compra.
En el caso que el cliente decida comprar los productos seleccionados, se dará curso al segundo caso de
uso de la Figura N°20 llamado “Decisión Pedidos SAP”. En el cual la página inicial, (clase “boundary”)
obtiene el pedido actualizado virtualmente en memoria desde el control “Carrito”. Luego envía
remotamente –vía RFC– estos parámetros a las funciones respectivas de SAP, capaces de guardar el
pedido en las tablas de nombre VBAP y VBAK para finalmente decidir su aprobación chequeando
condiciones de crédito y stock.
Se enfatiza el hecho de que se guardarán todos los pedidos (aprobados y no aprobados), a fin de tener
un registro del comportamiento del cliente y poder en el futuro realizar ofertas proactivas a cada cliente.
Los diagramas de las Figuras N°21 y N°22 se relacionan directamente con el apoyo que se brindará al
departamento de finanzas para que su personal cuente con una buena herramienta de apoyo al cálculo y
actualización semestral de todos los parámetros de crédito en la Intranet.
Se pretende con este sistema disminuir en un 80% los pedidos que requieren de una decisión manual en
su tramitación, dejando que lleguen a estudio sólo aquellos pedidos en que el cliente desee ampliar el
plazo en su condición de pago.
En el caso "Otorgar Crédito a Estudio” el usuario de finanzas entrará al sistema con una clave que se
validará contra una nueva tabla llamada Usuario_finanzas. Luego el control “Actualizar_SAP” rescatará
desde la tabla VBKD los pedidos que han quedado a estudio y según su parecer liberará o bloqueará
remotamente la nota de venta en SAP.
Para el caso “Calcular Parámetros” (Figura N° 22), se presupone que se ha validado el ingreso del
usuario (ilustrado en la figura anterior). Acá el personal de finanzas, en una primera etapa poblará una
nueva tabla llamada “balance comercial” con los datos del balance, el promedio de las compras totales y
algunos datos de riesgo, con lo cual la clase boundary “Calcular_límite” estará en condiciones de
proponer un límite de crédito. De ser aceptado este límite, la misma clase anterior actualizará el límite de
crédito en SAP. En caso contrario se actualizará una nueva cifra ingresada por el mismo usuario.
Luego de poblada esta tabla, será necesario modificar cada 6 meses estos valores. También con esta
misma frecuencia de tiempo se actualizarán los parámetros de clasificación de crédito, en donde la clase

boundary “Calcular_Clasificación” obtendrá la deuda histórica de la tabla “Deuda_Histórica” y actualizará
dichos valores de manera similar al caso anterior.

Figura N°19: Realización del Caso “Seleccionar Pedidos”

Figura N°20: Realización del Caso “Decidir Pedidos SAP”

Figura N°21: Realización del Caso “Otorgar Crédito a Estudio”

Figura N°22: Realización del Caso “Calcular Parámetros”

3.- Arquitectura del diseño

A partir de la identificación de clases del punto anterior, se definen subsistemas que agrupan las clases
según criterios de similitud e interrelación o cohesión. En primer lugar, para el caso de procesamiento del
pedido en el nuevo canal de ventas se agrupan los datos en clases relacionadas por medio de atributos
llegando al paquete “Comprador registrado” (Figura N°23).
Figura N°23: Clases Paquete “Comprador registrado”

Similarmente para los casos que se desarrollarán como apoyo al departamento de finanzas, se llegará al
paquete “Usuario Finanzas” (Figura N°24).
Figura N°24: Clases Paquete “Usuario_finanzas”

Se da a continuación un detalle del contenido de estos paquetes a partir de las clases del tipo boundary y
de control.
Es así como en la Figura N°25 se encuentra el detalle del paquete “Seleccionar Pedido”, y en las tres
figuras siguientes las clases paquete “Decidir Pedidos SAP”, “Otorgar Crédito a Estudio” y “Calcular
Parámetros”.
Figura N°25: Clases Paquete “Seleccionar Pedido”
Figura N°26: Clases Paquete “Decidir Pedidos SAP”

Figura N°28: Clases paquete “Calcular Parámetros”
Figura N°27: Clases Paquete “Otorgar Crédito a Estudio”

4.- Diseño detallado de la aplicación

Con todo lo anterior se está en condiciones de avanzar hacia el diseño detallado de la aplicación. Esto
implica la selección de una tecnología y modalidad de implementación específica, detallando el diseño
expresado en las clases y sus interacciones.
Para ello se explícita la tecnología de implementación, la cual ya está definida como la de Internet, con el
modelo de n capas.

Dentro de Internet se elige a ASP (Active Server Pages) como lenguaje de programación, por ser la que
mejor se adecua a la realidad de la empresa, dado que se trabaja total y exclusivamente en un ambiente
Micrososf, con el sistema operativo Windows NT y con bases de datos relacionales SAP en SQL Server,
para el almacenamiento de información.
4.1.- Integración Web SAP

Para el caso en estudio existen dos maneras distintas en que la aplicación web interactuará con SAP:

1. La primera corresponde al caso trivial donde se accede directamente a las tablas de SAP sólo con
permiso de lectura y con el propósito de mostrar información. Ejemplos de estos casos se producen al
buscar clientes, mostrar cuentas corrientes, mostrar productos disponibles, etc.
Para utilizar esta información, la aplicación Web llamará al controlador de la base de datos (ODBC)
mediante una cadena de conexión, el cual consta con todos los parámetros necesarios para establecer
dicha conexión.

2. El caso complejo ocurre en el momento en que se desea actualizar la base de datos de SAP, (ejemplo
de ello ocurre al grabar una nota de venta).
Debido a la gran cantidad de tablas relacionadas en el modelo de datos (aproximadamente 14.000) y a la
dependencia de muchas de ellas, sería muy difícil lograr consistencia actualizando los registros que
correspondan.

Para este último caso SAP dispone de diferentes alternativas de solución basados en los llamados RFC
(Remote Function Call). Entre las más importantes se pueden mencionar:

? ITS (Internet Transaction Server)8: Corresponde a la alternativa mayormente difundida y usada a la
fecha y se trata básicamente de un software que permite la interacción entre un servidor web y un
sistema SAP R/3, mediante transacciones preprogramadas y desarrolladas especialmente para mantener
la consistencia [9]. ITS está basado a su vez en otras dos aplicaciones llamadas Internet Application
Components (IAC) y Easy Web Transactions (EWT).

? DCOM Connector: Programa diseñado en conjunto por SAP y Microsoft, que genera el código binario
de componentes COM (Modelo de objetos componentes), y que puede comunicarse directamente con las
BAPIs (Business Application Programming Interface) de SAP, integrándolas a programas de Microsoft
(Visual Basic, ASP, Office, etc), sin necesidad de conocer el lenguaje de programación de SAP (ABAP/4)
o los detalles de la ejecución de las BAPIs.

? Java Connector: Programa integrador en que las llamadas a las BAPIs son realizadas desde código
Java. Por esta razón posee las ventajas típicas de este lenguaje, como son la flexibilidad y su carácter
multiplataforma.

? Net Connector: El mismo caso anterior, sólo que ahora SAP se integra al mundo .net.

Dado que Mathiesen trabaja plenamente con tecnología Microsoft se opta por utilizar el SAP Dcom
Connector como medio para que las aplicaciones web –desarrolladas en ASP– se conecten remotamente
al sistema SAP R/3.
Se descarta el uso de los ITS por su complejidad e inflexibilidad, puesto que no poseen inteligencia
propia, sino que funcionan a nivel de transacciones SAP. Por lo cual no permiten agregar lógica y de
8
En el Anexo N°4 se puede consultar mayor información a cerca de los ITS

querer modificar la aplicación web habría que programar nuevas transacciones en ABAP/4 (lenguaje
nativo de SAP).

4.2.- Arquitectura tecnológica

1. Para el primer caso, en que se accede directamente a las tablas de SAP con permiso de lectura y con
el propósito de mostrar información, se implementará la arquitectura de tres capas.

Como se puede observar en la Figura N°29, el servidor web con plataforma tecnológica Windows NT
CLIENTE
SERVIDOR WEB
Windows NT. IIS.
Aloja archivos ASP
SERVIDOR
APLICACIONES
Procesa contenidos
del ASP
SERVIDOR
DE B.D.
SAP ADEXUS
SQL SERVER
Figura N°29: Arquitectura de acceso a tablas SAP
alojará las páginas ASP. Mientras que la lógica del negocio se procesará en el servidor de aplicaciones,
el cual a su vez llamará al controlador de Base de Datos ODBC (Open Database Connectivity) mediante
una cadena de conexión, con los parámetros respectivos para realizar las consultas necesarias.

2. Por otra parte, la arquitectura tecnológica que soportará el segundo caso se ilustra en Figura N°30. En
ella, el servidor web basado en Windows NT será quien aloje las páginas ASP con sus respectivos
scripts.
Será necesario instalar en este servidor el MTS (Microsoft Transaction Server) y el Dcom Connector.

El proceso comienza cuando el cliente invoca la aprobación de su pedido en una página ASP. Esta
Figura N°30: Arquitectura de Integración usando Dcom Connector

página llamará al objeto Dcom connetor que generará los componentes COM capaces de comunicarse
con métodos escritos en el lenguaje ABAP/4 (BAPIs) y residentes en el Repositorio de Objetos Business
de SAP (ROP). Acá se obtendrá una respuesta a la petición, chequeando condiciones de crédito y stock,
tal cual como si se hubiese utilizado SAP directamente, retornando la página ASP de respuesta al pedido
del cliente.

Por su parte el MTS (Micrososft transacción Server) será el encargado de coordinar las transacciones,
resolviendo problemas de concurrencia y gestionando recursos. Los componentes COM se convertirán
en componentes MTS constituidos como una DLL y se agruparán en paquetes para su gestión conjunta.

4.3.- Programación de la lógica del negocio

Existirán también dos casos diferentes de programar la lógica del negocio en la nueva aplicación:

1. Cuando se requiera programar lógica anexa a SAP (Ej: Cálculo de parámetros de crédito), lo
adecuado será programar procedimientos en VBScript o Javascript indicando a la página ASP que
procese las secuencia de comandos en el servidor de aplicaciones.
La principal ventaja de utilizar estos lenguajes será su simplicidad y su baja demanda de requisitos
comparado con otros lenguajes, (como es el caso de Java propiamente tal).
Y aunque Javascript no es orientado a objetos, puede utilizar los objetos en muchas ocasiones con
funciones del tipo constructor, las cuales se encargarán de construir los objetos en memoria e
inicializarlos, definiendo sus propiedades y métodos [8].
Por último, cabe mencionar que para hacer más clara y estructurada la programación, en la mayoría de
los casos se crearán pequeños programas que serán invocados por distintas páginas ASP, de manera
que el código pueda ser reutilizado.

2. Para el segundo caso sólo se incorporará la lógica con que actualmente trabaja SAP (Ej: otorgamiento
de crédito, disponibilidad y rebaja de stock). Esta acción será transparente para el programador, pues –
como se ha mencionado– la aplicación se integrará al sistema SAP por medio del Dcom Connector.
4.4.- Mapeo de clases

A partir de los diagramas de las Figuras N°19, N°20, N°21 y N°22 se mapearán las clases lógicas a
componentes físicos Active Server Page (ASP) de la siguiente manera:

Caso “Seleccionar Pedido”:
Página_ingreso_pedido
Registrar
?
?
Página HTML
ASP
Verificar
?
ASP (VBScript – Dcom Connector)
Dar precio
?
ASP
Carrito
Página_respuesta_pedido

Caso “Decidir pedidos SAP”:
Página_Venta
?
?

?
ASP
ASP

ASP (VBScript – Dcom Connector)
Carrito
?
ASP
Página_respuesta_pedido
?
ASP
Caso “Otorgar Crédito a Estudio”:
Página_ingreso_finanzas
?
Página HTML
Verificar
?
ASP
Actualizar_ Estado
?
ASP (VBScript – Dcom Connector)
ASP
Página_respuesta_finanzas ?

Caso “Calcular Parámetros”:
Página_cálculo
Calcular_clasificación
Calcular_límite
Página_respuesta_finanzas
?
?
?
?
Página HTML
ASP (VBScript – Dcom Connector)
ASP (VBScript – Dcom Connector)
ASP

La justificación de las elecciones anteriores radica en que cada tecnología elegida se ajusta a los
requerimientos de procesamiento de la clase respectiva.
En particular, HTML es la tecnología apropiada para las páginas estáticas de ingreso que servirán a los
usuarios para entregar información. Por su parte se emplea ASP –con secuencia de comandos en
VBScript o Javascript– para generar las páginas de respuesta de contestación al cliente, ya que se trata
de una lógica con variadas alternativas y páginas diferentes.
Por su parte, VBScript (de Microsoft) es el lenguaje que permite realizar las llamadas necesarias al
DCOM Connector desde las clases Verificar, Página_venta, Actualizar_Estado, Calcular_ límite y
Calcular_clasificación.

4.5.- Tablas requeridas por la Aplicación
En las Figuras N°19, N°20, N°21 y N°22 se aprecian los nombres de las tablas que ocupará la aplicación.
Nuevamente se distinguen dos casos:

1. Los nombres de las tablas complementarias a SAP –o sea que deberán crearse en SQL Server–
serán las siguientes:

? Usuario_Finanza.
? Deuda_Histórica.
? Balance_Comercial.

2. Por su parte, las tablas de SAP que serán llamadas a modo de consultas desde la nueva aplicación
serán:
?
?
?
?
?
KNKK (Datos maestros): Clientes, parámetros de crédito, forma de pago, moneda.
KONP (Condición): Condición cliente, precio, material.
VBKD (Crédito a estudio): Bloqueo crédito.
VBAK (Nota_Venta): Documento de ventas, datos de cabecera.
VBAP (Nota_Venta): Documento de ventas, datos de detalle.
VI.- Conclusiones del diseño
Primeramente, se considera importante mencionar que la metodología empleada facilitó en gran medida,
la definición en forma precisa –y en un tiempo razonable– de los componentes a automatizar.
Al utilizar los patrones para modelar la arquitectura e-Business se identificaron rápidamente los procesos
que serían apoyados con tecnología Internet, se definió la lógica del negocio de manera clara y precisa y
se derivaron casi directamente los casos de uso junto con la información necesaria para seleccionar la
tecnología y modalidad de implementación específica.

Por otro lado, como consecuencia del actual trabajo, la empresa se ha dado cuenta de los beneficios que
conllevaría comercializar sus productos por este nuevo canal, mostrando un claro interés en seguir
adelante con el proyecto. Por este hecho, el autor ha considerado apropiado construir una Intranet con un
módulo orientado a que las distintas personas que están involucradas en el proyecto –personal de
informática, finanzas y comerciales– puedan ir probando un prototipo funcional del sitio.

De esta manera, el prototipo está orientado más que a una autoatención9 por parte del cliente, a una
primera etapa de prueba, permitiendo inicialmente que los vendedores creen de forma remota una orden
de venta en SAP.
Además, siendo consistente con el diseño planteado, se ha creado una herramienta de apoyo al cálculo
de los parámetros necesarios para el otorgamiento automático del crédito a los clientes, el cual está
siendo usado de manera informal por el personal de finanzas.

VII.- Construcción del prototipo

Esta aplicación –como se mencionó anteriormente– inicialmente está destinada a que los mismos
operadores comerciales realicen las órdenes de venta en las dependencias físicas de los clientes, (en el
9
En el Anexo N°3 se encuentran las pantallas de Internet, que simulan una autoatención por parte del
cliente.

Anexo N°3 pueden ser consultadas las pantallas del diseño del sitio orientadas a una autoatención por
parte de los clientes).

A continuación se recorrerán las principales pantallas del prototipo, mostrando los pasos que seguirá
cada operador comercial para realizar remotamente la orden de venta.

Figura N°31: Página Inicial del Módulo Comercial
En la primera pantalla del módulo comercial (Figura N°31), inicialmente se dan las opciones de crear una
nota de venta, buscar las órdenes que se le han procesado a un determinado cliente o buscar clientes
según algún criterio.

De querer crear una nota de venta se pedirá autentificación, el tipo de orden –normal o importación a
terceros– y el número del cliente al que se le desea cursar la orden (Figura N°32).

Figura N°32: Página de Autentificación Comercial

Suponiendo que el vendedor en vez de ingresar directamente el número del cliente, desea buscarlo
(Figura N°33), entonces digitará parte del nombre recibiendo como respuesta el o los clientes que
coincidan con tal petición (Figura N°34). Para el caso del ejemplo, se procesará una venta al cliente
“Agric y Ganadera Mc Osker y Cia. Ltd.”, cuyo número es el 10048. Éste tiene asociado dos canales de
distribución “Químico y Plástico”, por lo cual el vendedor que esté cursando la orden elegirá el canal que
le corresponda para quedar como responsable de la venta.

Luego deberá ingresar los productos que requiera comprar. En la Figura N°35 busca el producto que
tenga la sigla AB, lo encuentra (Figura N°36) y lo agrega al portafolio de productos (Figura N°37). Notar
que inmediatamente aparecerá la unidad de medida del tal producto –que en este caso es kilos- y la
moneda que utiliza el cliente para comprar (CLP, que en SAP equivale a pesos).

A continuación insertará el producto en el carro de compras (Figura N° 38), no sin antes indicar cantidad,
precio y clase de valoración (importado normal, importado a terceros o nacional). Es importante que se
ingrese la clase de valoración por un tema contable, pues dependiendo de la opción elegida, el producto
tendrá un distinto margen sobre el precio de compra.
En este momento el vendedor tiene la opción de borrar, agregar productos o confirmar la compra para
que el DCOM Connector procese la aprobación del pedido llamando a las BAPIs de SAP10.
Notar que la condición de pago negociada es de crédito a 18 días. En el caso que desee cambiar la
condición por un crédito de mayor plazo, deberá tener presente que la venta quedará en espera de
liberación por parte del personal de finanzas.
10
En el Anexo N°5 se encuentra parte del programa que permite la conexión con SAP (en VBScript).

Figura N°33: Página de Búsqueda de Clientes
Después de ingresado un segundo producto (Figura N°39) y de confirmada la compra aparecerá la
pantalla con el resumen y el número de la orden de venta (Figura N°40).
Finalmente se puede comprobar con el número de la orden, que efectivamente la nueva venta ha sido
grabada en SAP (Figura N°41).

Figura N°34: Resultado de la Búsqueda de Clientes
Figura N°35: Ingreso del Canal de Distribución
Figura N°36: Resultado de la Búsqueda de Productos

Figura N°37: Portafolio de Productos
Figura N° 38: Carro de Compras (1 producto)

Figura N° 39: Carro de Compras (2 productos)
Figura N° 40: Resumen de Venta

Figura N° 41: Orden Grabada en SAP
Como se mencionó en el diseño, para disminuir el porcentaje de órdenes de venta que caen a finanzas,
será necesario actualizar los parámetros actuales de crédito. Con este fin, se encuentra disponible una
herramienta de apoyo al cálculo del límite de crédito efectuado por el personal de finanzas. Para ingresar
se validará el username y password (Figura N°42), contra la tabla creada en SQL Server llamada
“usuario_finanza”
Figura N°42: Página de Autentificación Finanzas

De ser un usuario válido, se mostrará el módulo correspondiente al cálculo del límite de crédito (Figura
N°43), y se proporcionarán las opciones de ingresar modificar o buscar –en la tabla llamada
“Balance_Comercial”– la información necesaria para el cálculo de tal parámetro. En la pantalla ilustrada
en Figura N°44 se ingresarán los valores del balance comercial del cliente, los que a su vez invocarán la
lógica11 del cálculo para proponer un límite de crédito. De ser aceptado tal parámetro, el Dcom
Connector tomará el control para grabarlo en SAP por intermedio de la BAPI correspondiente. En caso
contrario el usuario podrá ingresar otro valor bajo algún criterio particular.
Figura N°43: Página Principal Finanzas
11
En el Anexo N°2.2 se encuentra esta lógica en un pseudo lenguaje estructurado y en el Anexo N°5 está
parte del script de programación.

Figura N°44: Página de Ingreso de Datos del Balance
Figura N°45: Actualización del Límite de Crédito
Por otro lado, se muestra en la Figura N°46 la posibilidad que tiene un determinado cliente de acceder al
estado de su cuenta corriente, para lo cual primero tendrá que autentificarse. Finalmente, en la Figura
N°47 se ilustra el resultado de la consulta anterior, desplegando todas las partidas abiertas que posee el
cliente, específicamente la fecha de emisión y de vencimiento de cada documento, el importe y el
impuesto, entre otros.

Figura N°46: Acceso a la Cuenta Corriente
Figura N°47: Despliegue de las Partidas Abiertas

VIII.- Referencias
1. Barros, O.

2. Barros, O.
Rediseño de Procesos de Negocios Mediante el Uso de Patrones, Dolmen, 2000.

Patrón del Proceso de Venta y Distribución de Stock, Depto. Ingeniería Industrial, U. de
Chile, Serie Gestión Nº17, Octubre 2000.
3. Barros, O.
Diseño de la Arquitectura de un e-Business, Depto. Ingeniería Industrial, U. de Chile,
Serie Gestión Nº 27, Septiembre 2001.
4. Barros, O.
Diseño de los Componentes de un e-Business, Depto. Ingeniería Industrial, U. de Chile,
Serie Gestión Nº 28, Septiembre 2001.
5. Barros, O.
Componentes de Lógica del Negocio Desarrollados a partir de Patrones de Procesos, U.
de Chile, Serie Gestión Nº 34, Marzo 2002.

6. Cámara de Comercio de Santiago: La Economía digital en Chile, Departamento de Estudios. Año
2001. Capítulo XV.

7. http://www.nwfusion.com/ecomm2000/ecomm-endtoend.html

8. http://www.desarrolloweb.com/articulos/789.php

9. http://www.sapmania.com/comunicaciones/its.htm

10.http://www.ciudadfutura.com/sap/sap/info/its.htm

11.http://www.programming-vb.com/mts/docs/intro.htm

IX.- Anexos
Anexo N°1: Políticas actuales de crédito
1.1.- Características de las diferentes clasificaciones de crédito

Cabe mencionar que las clasificaciones de crédito se asignaron de forma manual por un cómite de crédito
y no han sido actualizadas a la fecha.
Los criterios de clasificación actual son los siguientes:

Tipo Significado
A+Premium
A Buena
B Normal
B- Problema
C Riesgoso
D Estudio
N Nuevo
U Pesado
J Judicial
? A+
PRIME
MOROSIDAD: No presenta ni ha presentado morosidad.
PROTESTOS: No presenta ni ha presentado protestos
PROPIEDAD: La propiedad está en manos de grupos económicos de reconocido prestigio nacional e
internacional.
? A
BUENO
MOROSIDAD: No presenta ni ha presentado morosidad.
PROTESTOS: No presenta ni ha presentado protestos
PROPIEDAD: La propiedad está en manos de grupos económicos de reconocido prestigio y solvencia
nacional.
? B
NORMAL
MOROSIDAD: Variable entre 0-30 días.
PROTESTOS: No presenta ni ha presentado protestos
PROPIEDAD: La propiedad está en manos de socios de reconocido prestigio y solvencia en su respectivo
mercado.
? B-
PROBLEMA
? MOROSIDAD: Sobrepasa los 30 días, recae en prorrogas reiteradas
? PROTESTOS: No presenta pero ha presentado protestos, los cuales están aclarados
? PROPIEDAD: La propiedad está en manos de personas con patrimonio deteriorado y/o en riesgo.
? C
RIESGOSO
MOROSIDAD: Sobrepasa los 30 días, recae en prorrogas reiteradas
PROTESTOS: Con protestos videntes y no aclarados.
PROPIEDAD: La propiedad está en manos de personas que carecen de patrimonio.
? D
ESTUDIO
CARACTERÍSTICA GENERAL. No tiene historia como cliente. Se tienen sólo algunos antecedentes. A
este tipo de cliente se le hará un seguimiento sistemático.
? N
NUEVO
CARACTERÍSTICA GENERAL. Es la categoría asociada a los clientes que ingresan a la base de datos.
Se crea modalidad de pago al contado. Si requiere crédito se revisa DICOM. Crédito autorizado sin
antecedentes financieros USD 800.
? U
PESADO
CARACTERÍSTICA GENERAL: Corresponde a aquellos clientes con cesación de pagos y que si
presentaron un plan de pago. Sólo se podrán efectuar ventas al contado o ventas que en su valor estén
generando excedentes que abonen la deuda vencida. Las ventas sólo podrán ser autorizadas por la
Gerencia de Finanzas y Operaciones.
? J
JUDICIAL
CARACTERÍSTICA GENERAL: Clientes que han debido ser enviados a los abogados de Mathiesen para
la regularización de su deuda. Ventas sólo podrán ser autorizadas por la Gerencia de Finanzas y
Operaciones.

1.2.- Ejemplos para determinar línea de crédito
1.- Plásticos Temuplas
? Datos:
Compras anuales: US$ 5.700.000
Utilidad anual: US$185.000
Patrimonio: US$ 3.600.000
Pasivo Exigible: US$ 4.000.000
Clasificación del cliente: peor que normal
Clasificación de la Industria: Riesgosa
? Aspectos Cuantitativos:
1.- 20% de las compras.
Son US$ 5.700.000/12 * 3 * 0,2 = US$285.000
2.- Utilidad anual US$185.000
3.- % del patrimonio. Un 15% son US$540.000
Promedio = US$ 336.000
? Aspectos Cualitativos:
Ambas calificaciones son peores que normal, por lo cual se aplica el castigo de 25%. La línea sugerida es
US$ 252.000
? Restricciones:
El Patrimonio de Mathiesen es US$7.000.000, su 10% son US$ 700.000 por lo que no aplica.
2.- Cerámicas Cordillera
? Datos:
Compras anuales US$ 30.000.000
Utilidad anual US$4.500.000
Patrimonio US$ 43.000.00
Pasivo Exigible US$ 21.400.000
Clasificación del cliente: Buena
Clasificación de la Industria: Buena
? Aspectos Cuantitativos:
1.- 20% de las compras.
Son US$ 30.200.00/12 * 3 * 0,2 = US$1.509.999
2.- Utilidad anual US$ 4.500.000
3.- % del patrimonio. Un 20% son US$8.600.000
Promedio = US$ 4.800.000
? Aspectos Cualitativos:
Ambas calificaciones son mejores que normal, por lo cual no se aplica el castigo de 25%.
? Restricciones:
El Patrimonio de Mathiesen son US$7.000.000, su 10% son US$ 700.000 por lo la línea sometida a
directorio es de US$ 700.000
1.3.-Condiciones de bloqueo de crédito
Existen opciones de bloquear automáticamente la venta si se cumplen ciertas condiciones de crédito:
? Línea de crédito: Se bloquea al cliente una vez que excede su limite de crédito asignado.
? Partida Abierta Antigua: Se utiliza para no bloquear al cliente apenas tenga deuda vencida. Se
permite la opción en que se indica el número de días necesarios para el bloqueo después de vencida
esta deuda.
? Partida Abierta: Se utiliza para no bloquear al cliente por montos vencidos insignificantes. Se puede
especificar un porcentaje por sobre el cual se bloquee al cliente si pasan mas de “n” días de su
vencimiento.
? Campo Crítico: Al activarse este campo, se obliga a vender a esta clase de cliente según la condición
de pago especificada en su maestro.
? Valor documentado: Indica el monto máximo de venta para cada clase de riesgo

? Fecha verificación: El sistema otorga la posibilidad de no bloquear al cliente, una vez cumplida la
fecha de revisión de la línea de crédito durante n días.
? Nivel de reclamación: Se puede bloquear al cliente cuando se encuentre en algún nivel de
reclamaciones avanzado. El nivel de reclamación corresponde al número de cartas por deudas que se le
ha enviado al cliente. En el primer aviso se le recuerda al cliente que posee una deuda con la empresa y
se le solicita que le pague a alguno de sus cobradores. En el segundo aviso se le pide que cancele a la
brevedad la deuda sostenida, a fin de no tener dificultades en la entrega de futuras materias primas. En el
tercer y último aviso se le informa al cliente que los documentos que certifican la morosidad, fueron
enviados al Boletín Comercial para su publicación como deuda morosa y que de mantenerse la situación
por un plazo mayor a 7 días, se traspasará dicha cobranza a los abogados de Mathiesen.
Para cada uno de estos bloqueos existe la posibilidad de enviar un mensaje de advertencia al usuario o
incluso de impedir que grabe dichos pedidos de venta.
En la práctica, las principales causas de bloqueos son: campo critico (40%) – de estos pedidos un 50% se
libera y el otro 50% se mantiene bloqueado – y sobregiro de línea (40%), repartiendo el 20% restante
entre las otros tipos bloqueos.
Anexo N°2: Lógica del cálculo de los parámetros crediticios en pseudo-lenguaje
2.1.- Lógica para la Determinación de la Clasificación de Crédito
Si (DDME = 0 y Pto = 1 y Prop = 1)
CL.Clasificacion = A+
Sino
Si (DDME = 0 y Pto = 1 y Prop = 2)
CL.Clasificacion = A
Sino
Si (0 < DDME < 30 y Pto = 1 y Prop = 3)
CL.Clasificacion = B
Sino
Si (DDME >30 y Pto = 2 y Prop = 4)
CL.Clasificacion = B-
Sino
Si (DDME >30 y Pto = 3 y Prop = 4)
CL.Clasificacion = C
Sino
Si (DDME >30 y DMSP=1)
CL.Clasificacion = U
Sino
Si (CL.Clasificacion = U y Fecha.3erAviso – Fecha.Actual > 7)
CL.Clasificacion = J
Sino
Si (Pto = 0 y Prop = 0)
CL.Clasificacion = N
Sino // no se cumplio ninguna condición
CL.Clasificacion = D

2.2.- Lógica para la Determinación del Límite para el Monto del Crédito

Leer Cliente = CL
Leer (CL.promedio compra de ult. 3 meses) * 3 *0,2 = COM
Leer CL.Utilidad= UTI // Resultado ejercicio
Leer CL.Patrimonio= PAT
Calcular Leverage= (CL.Pasivo Exigible / PAT) = LEV
Calcular (Mathiesen.Patrimonio)*0.1= MAX

Si (LEV >3)
MC= 0 // No dar crédito
Sino
Si (2< LEV< 3 )
LEVPAT=PAT*0,1
Sino
Si (1< LEV< 2)
LEVPAT=PAT*0,15
Sino
Si (0< LEV< 1)
LEVPAT=PAT*0,2

PROM= (LEVPAT+UTI+COM) / 3

Si (CL.Riesgo + SECTOR.Riesgo) / 2 < 3 // Peor que Normal
LC= PROM *0,75 // Castigo Límite crédito con 25%
Sino
LC= PROM

Si (LC > MAX)
MC=MAX // Monto máx crédito = 10% utilidad de Mathiesen (US$ 700.000)
Sino
MC=LC

2.3.- Lógica de otorgamiento de crédito
MP
MC
CC
PA
PAA
NR
: Monto en $US del pedido solicitado (incluido impuestos)
: Monto máximo de crédito
: Monto de deuda en cuanta corriente del cliente con la empresa
: Promedio de días vencimiento de todas las deudas
: Días de vencimiento de la deuda más antigua
:Número de reclamos que Mathiesen le ha realizado al cliente por no pago de alguna deuda
Si NV.Pago = Contado
NV.Estado = OK
Sino
Si (CL.clasificación = A+)
Si (MP< 75000) y (CC + MP ? 1.25MC) y (PA< 30) y (PAA< 45) y (NR< 3)
NV.Estado = OK
Sino NV.Estado = Rechazada
Sino
Si (CL.clasificación = A)
Si (MP< 50000) y (CC + MP ? 1.15MC) y (PA< 30) y (PAA< 45) y (NR< 3)
NV.Estado = OK
Sino NV.Estado= Rechazada
Sino
Si (CL.clasificación = B)
Si (MP< 25000) y (CC + MP ? 1.1MC) y (PA< 7) y (PAA< 30) y (NR< 3)
NV.Estado = OK

Sino NV.Estado= Rechazada
Sino
Si (CL.clasificación = B-)
Si (MP< 10000) y (CC + MP ? 1.1MC) y (PA< 5) y (PAA< 15) y (NR< 3)
NV.Estado = OK
Sino NV.Estado= Rechazada
Sino
Si (CL.clasificación = D o N)
Si (MP< 800) y (CC + MP ? 1.2MC) y (PA< 7) y (PAA< 15) y (NR< 3)
NV.Estado = OK
Sino NV.Crédito= Rechazada
Sino
Si (CL.clasificación = E)
Si (MP< 75000) y (CC + MP ? 1.15MC) y (PA< 7) y (PAA< 15) y (NR< 2)
NV.Estado = OK
Sino NV.Crédito= Rechazada
Sino // CL.clasificación = C o U o J
NV.Crédito = Rechazada

Anexo N°3: Pantallas del canal de ventas de Internet
Figura 1A: Página Ingreso Tienda Virtual
La Figura 1A muestra la página de entrada al nuevo canal de ventas. En ella se encuentra el menú de
opciones para el navegante (frame horizontal superior), que permanece fijo para las páginas interiores.
En el cuerpo central está la información básica para contactarse con Mathiesen y, lo más importante, el
formulario para ingreso de clientes (username y password). En caso de no ser un cliente, a un costado se
encuentra la opción de registrarse.
En la Figura 2A se simula la intención de un cliente registrado de ingresar a cotizar los productos de la
empresa. Más adelante se señala la secuencia para un cliente no registrado (al que se nombrará
simplemente como navegante).

Figura 2A: Portafolio de Productos de Mathiesen
Al ingresar a la página de la Figura 2A, el cliente podrá optar entre dos maneras de buscar un
determinado producto; por familia o bien mediante la letra inicial del producto. Al suponer que se elige la
familia de plásticos y elastómeros, se derivará la Figura3A.
Figura 3A: Familias de Productos de Mathiesen

Figura 4A: Elección del Producto
Cuando el cliente selecciona un producto, aparecerá la pantalla que permite realizar la transacción
(Figura 4A). Cabe destacar que el precio aparece inmediatamente, debido a que el cliente se registró con
anterioridad. En la pantalla de la Figura 5A se muestra el caso contrario, o sea de un navegante que no
se ha registrado; en tal caso cuando seleccione un producto en particular, el sitio le exigirá su
identificación como cliente antes de enseñarle los precios.
Figura 5A: Identificación Navegante para Indicar Precios

Si el sitio reconoce al navegante como cliente, accederá a la página de transacción (Figura 6A). Al
ingresar la cantidad se agregará el producto al carro de compras (Figura7A).
Figura 6A: Acceso de Navegante al Carro de Compras
Figura 7A: Carro de Compra

Finalmente al confirmar la compra, el sistema integrará la lógica que utiliza SAP para verificar stock y
crédito automáticamente, a fin de dar una respuesta en línea al cliente sobre la aceptación, estudio o
rechazo de su pedido. En la pantalla de la Figura 8A se observa un caso en que el crédito será enviado a
estudio, debido a que el cliente solicita cambiar su condición de pago desde un crédito a 60 días por un

crédito a 90 días. En la mayoría de los casos la decisión de aceptación o rechazo de la venta será un
proceso automático, pero se quiso ejemplificar este caso para apreciar el ciclo completo que podría tener
un pedido en Internet. Posteriormente el pedido que ha quedado a estudio será rescatado en la Intranet
Corporativa por personal de finanzas, quien tendrá la responsabilidad de bloquearlo o liberarlo. Dicho
cambio se actualizará automáticamente en SAP (Figura 9A).

Figura 8A: Confirmación de la Compra
Figura 9A: Intranet Finanzas

Volviendo atrás en el sitio Internet, para el caso en que el navegante no es un cliente, deberá registrarse
en el formulario de la página principal indicado para ello (Figura 10A).

Figura 10A: Formulario Ingreso Clientes Nuevos
Una vez que el nuevo cliente llena y envía sus datos, se despliega la Figura 11A.

A partir del rubro que ingresa el nuevo cliente en el formulario se derivará la solicitud al operador
comercial respectivo, el cual tendrá la misión de crear en el sistema los clientes nuevos.
Rescatará estos requerimientos a través de un módulo especial para ello incluido en la página principal
donde dice "Administrador". (Figura 1A)
Cuando el operador comercial ingresa a esta opción se le exige su identificación (Figura 12A).

Figura 11A: Confirmación Envío de Datos
Figura 12A: Ingreso Operador Comercial

Después de identificarse, el operador comercial podrá observar la información de los clientes nuevos y
decidir su incorporación al sistema (Figura 13A).

Figura 13A: Identificación Nuevo Cliente
De esta manera se han mostrado algunas de las secuencias principales del nuevo canal, para
comprender la manera en que un cliente operará en el futuro sitio web de Mathiesen.

Anexo N°4: Función del Internet Information Server

Cuando un usuario de Internet hace una petición al servicio ITS pulsando un hipervínculo URL o
tecleando una dirección URL en el navegador Web para ejecutar un IAC o un EWT, la petición es
procesada como sigue [10]:
1. El navegador de Internet pasa a través de un servidor Web.
2. El Web Server llama a la extensión de servidor WGate del ITS. WGate es una extensión del servidor
Web que encapsula varias interfaces del servidor HTTP, tales como: CGI (Common Gateway Interface),
NSAPI (Netscape Server Application Programming Interface) e ISAPI (Internet Server Application
Programming Interface).
3. WGate dirige la petición al proceso del servidor ITS denominado AGate (el cual puede o no residir en
la misma máquina.). AGate es el vínculo entre ITS y el servidor de aplicaciones SAP R/3. O sea es el que
recibe peticiones del navegador Web desde el WGate y se comunica con el servidor de aplicaciones SAP
R/3 a través de DIAG o protocolos RFC.
4. AGate entonces procesa las peticiones y envía todos los detalles relevantes (incluyendo información
de conexión) al sistema SAP R/3, el cual o inicia la primera pantalla de conexión o envía los datos de la
siguiente transacción ya iniciada.
5. SAP R/3 inicia la transacción para el servicio solicitado y envía la salida de pantalla al AGate.
6. Cuando el diálogo ha finalizado, AGate recupera el resultado desde SAP R/3, siendo el responsable
del tratamiento de la sesión, incluyendo el mapeo de la pantalla SAP R/3 o los módulos de la función a
HTML.
7. AGate envía la página HTML formateada a WGate.
8. WGate envía la página HTML formateada al servidor Web.
9. Por último, el servidor Web envía la página HTML formateada al navegador Web, donde podrá ser
visualizada por el usuario final.
Anexo N°5: Principales scripts del prototipo

5.1.- Extracto de la lógica para crear la orden en SAP (VBScript)

< % Set oSAPDemoObj = Server.CreateObject("RFCSampObj.RFCSampObj.1")
‘ Le asigna al objeto oSAPDemoObj el valor del componente “RFCSampObj.RFCSampObj.1”

Call oSAPDemoObj.DimHeader(HeaderIn)
‘ Llama al método DimHeader y le asigna los datos de cabecera
HeaderIn.AddNew
HeaderIn.Fields("DOC_TYPE") = session("tipo")
HeaderIn.Fields("SALES_ORG") = "MATH"
HeaderIn.Fields("DISTR_CHAN") = session("canal")
HeaderIn.Fields("DIVISION") = "00"
HeaderIn.Fields("PMNTTRMS") = session("pagoy")
HeaderIn.Update

Call oSAPDemoObj.DimPartners(Partners)
‘ Llama al método Partners y le asigna los datos del cliente
Partners.AddNew
Partners.Fields("PARTN_ROLE") = "AG"
Partners.Fields("PARTN_NUMB") = session("clienteh")
Partners.Update

if session("num_articulos") = "1" then
Call oSAPDemoObj.DimItems(ItemsIn)
‘ Llama al método DimItems y le asigna los datos de detalle del ítem
ItemsIn.AddNew
ItemsIn.Fields("MATERIAL") = session("producto1")
ItemsIn.Fields("PLANT") = "C100"
ItemsIn.Fields("REQ_QTY") = session("Quantity1") * 1000
ItemsIn.Fields("COND_TYPE") = "PREC"
ItemsIn.Fields("COND_VALUE") = session("precio1")
ItemsIn.Update
end if

REM set logon option:
oSAPDemoObj.Destination= "PRUEBA2" ‘ Se conecta al Dcom Connector
doneit = CreateOrder
if DoneIt = true then
BapiReturn.MoveFirst
if BapiReturn.Fields("TYPE") = "E" then ‘ Existe error
Response.Write( BapiReturn.Fields("TYPE")) ‘ Tipo de error
Response.Write( BapiReturn.Fields("CODE")) ‘ Código del error
Response.Write( BapiReturn.Fields("MESSAGE")) ‘Mensaje del error
else
Response.Write(OrderNumber) ‘ Graba pedido en SAP y devuelve el número de la orden
end if ' finaliza la llamada a la BAPI
end if ' finaliza la creación de la nota de venta
Function CreateOrder()
on Error Resume Next
Call oSAPDemoObj.OrderCreate(HeaderIn, _
ItemsIn, _
Partners, _
OrderNumber, _
,,,_
ItemsOut, _
BapiReturn) ‘ Llama a la BAPI OrderCreate y le ingresa los valores de sesión
CreateOrder = True
End Function
%>

5.2.- Extracto de la lógica para calcular el límite de crédito (VBScript)
< %
Session ("clienteh")= request.Form("cliente")
comprah = request("compra")* 0.6
utilidadh = request("utilidad")
patrimonioh = request("patrimonio")
pasivoh = request("pasivo")
riesgoh = request("riesgo")
riesgo2h = request("riesgo2")
dolarh = request("dolar")
if patrimonioh < > 0 then
Leverage = pasivoh/patrimonioh
end if
if Leverage > 0 and Leverage < = 1 then
Levpat = patrimonioh * 0.2 ‘ 20% del patriminio
ElseIf Leverage > 1 and Leverage < = 2 then
Levpat = patrimonioh * 0.15 ‘ 15 % del patrimonio
ElseIf Leverage > 2 and Leverage < = 3 then
Levpat = patrimonioh * 0.1 ‘ 10% del patrimonio
Else
mc=0 ‘ Si el leverage es mayor a 3 no se da crédito
end if
prom =(Levpat + utilidadh + comprah)/3
res= (riesgoh + riesgoh2)/2 ‘ Promedia el riesgo del cliente con el riesgo del sector
if res < 3 then
lc = prom * 0.75 ‘ Castiga con un 25% el promedio
Else
lc = prom
end if
if dolarh < > 0 then
mc = lc/dolarh
end if
if mc > 700000 then '10% Patrimonio de Mathiesen en USD
mc = 700000
end if
%>