Sistema de gestión de comercio electrónico al por mayor. Cuba

Resumen

El presente trabajo expone una propuesta de Sistema de Gestión de Ventas de Productos al por Mayor acotado a las regulaciones vigentes para la realización de esta actividad en Cuba.

Este persigue el objetivo de resolver el problema de la dualidad monetaria y las formas de pago propias del país que imposibilitan la aplicación de otros sistemas existentes.

El sistema resultante cuenta con mejoras y agregaciones de funcionalidades comerciales en un entorno amigable y fácil de utilizar; además de que garantiza la seguridad e integridad que requieren los datos que el mismo procesa agilizando y facilitando el proceso de Ventas de Productos al por mayor.

Para el desarrollo del sistema se utiliza la metodología ágil de construcción de software Scrum y se hace un estudio de los sistemas existentes y de las herramientas adecuadas para la construcción del mismo.

Palabras Claves

Software de Gestión, Comercio Electrónico, Ventas Mayoristas.     

Abstract

This investigation Project exposes a proposal for Wholesale System according to regulations in force for carrying out this activity in Cuba. This system aims to solve the dual currency problem, payment forms and others themes who make impossible to apply existing systems.

The result system improved aggregations of commercial functions in a friendly and easier environment of usage. Besides this system guarantee security and integrity required for managed data making faster and easier the process of selling products at wholesale.

For system development is used an agile method for project management: Scrum.

Keywords

E-Commerce, Wholesale System

Introducción.

El comercio es una actividad realizada por el hombre desde tiempos inmemoriales. Alude a la necesidad de la compra, venta o permutación de especies, y también intercambio de servicios que históricamente se han gestado a través de mercados, almacenes o establecimientos comerciales. Sin embargo, por primera vez en la historia, esta concepción ha cambiado. Esto está dado por el surgimiento de Internet que ha marcado una nueva era de entendimiento interpersonal, y una expansión radical de los medios y alcances del comercio.

El comercio electrónico nace como expresión de la eficiencia y para ser más productivo; como afán de satisfacer de forma integral nuevas necesidades, bajo el visor de la tecnología, que juega un papel esencial en su materialización. Cuba no vive exenta de la realización de comercio por lo que potencia su entrada al mercado internacional por todas las vías y especialmente mediante la realización de comercio electrónico.

Sin embargo, la economía del país posee características especiales que hacen imposible la aplicación de sistemas ya existentes pues no cuentan con las formas idóneas para realizar pagos y manejo de una doble moneda circulante entre otras regulaciones. Por esta razón puede afirmarse que no existe sistema informático capaz de realizar ventas mayoristas que cumpla con las características del comercio cubano. De modo que la elaboración de un Sistema de Gestión de Ventas de Productos al por Mayor como herramienta que cumpla con las regulaciones establecidas para Cuba favorecería el desarrollo del  comercio electrónico aportando beneficios a la economía del país.

Sistemas de Comercio Electrónico existentes

Existe una amplia gama de plataformas desarrolladas sobre diferentes tecnologías para la realización de comercio electrónico. Por solo mencionar algunas puede enumerarse Gesticom B2B, TornadoStore™, AB-Shop 3. Todas ellas con muchas facilidades de uso y atractivas para la creación de cualquier tipo de tienda virtual. Incluso, algunas de estas plataformas son gratis y de código abierto. Sin embargo ninguna de ellas ni los sistemas de inventario que las sustentan es aplicable en Cuba.

Razones que descartan el uso o reutilización de estos sistemas:

• Ya se ha incursionado en el uso de estos sistemas y se han hecho parches y modificaciones a las ventas minoristas que ellos realizan para adecuarlos a las mayoristas definidas en Cuba.
• Los procesos que estos modelan no son los que se aplican en el país por la forma en que se concibe la Contratación y el Proceso de Venta.
• La vía de negociar márgenes comerciales, créditos y los instrumentos de pago no son adecuados o usados en Cuba.

El proceso de facturación manejado por los sistemas expuestos no es el que se describe para el país.

• La circulación de la doble moneda no puede ser manejada por estos sistemas ni por sus respectivos inventarios.

Teniendo en cuenta que las funciones principales del sistema deben ser la venta y facturación asociadas a la gestión de márgenes comerciales y créditos queda muy poco por reutilizar de los sistemas existentes: ideas de diseño, buenas prácticas de programación, patrones…

En la actualidad empieza a potenciarse el desarrollo del comercio electrónico en el país y se están dando los primeros pasos en las ventas mayoristas dirigidas a empresas o personas jurídicas. Esto da la posibilidad de hacer un levantamiento de requisitos exhaustivo para que la primera plataforma de comercio electrónico desarrollada capaz de trabajar con el modelo de comercio cubano sea lo más eficiente posible.

La idea de crear una nueva plataforma esta sustentada además en el uso de una arquitectura orientada a servicios que permita mayor facilidad de comunicación entre sistemas y así lograr más fácilmente su integración (debe ser posible integrar el sistema resultante con el ERP-Cuba^[1] en desarrollo actualmente). Los sistemas expuestos usan una arquitectura híbrida entre cliente-servidor y 3 capas que no facilita el proceso de integración.

Metodología de Desarrollo

“Scrum” es una metodología para la gestión de proyectos, expuesta por Hirotaka Takeuchi e Ikujiro Nonaka, en el artículo The New Product

Development Game [Harvard Business Review Ene-Feb 1986]. “El precepto básico de esta metodología es que el mercado competitivo de los productos tecnológicos, además de los conceptos básicos de calidad, coste y diferenciación, exige también rapidez y flexibilidad”. (Takeuchi, 1999) A continuación se relacionan las características de Scrum  que implicaron la decisión de escoger esta metodología y no otra:

• Es una metodología de desarrollo ágil.
• Está pensada para equipos de desarrollos pequeños (no más de 8 personas)
• Se especifican pocos artefactos eliminando el “papeleo” innecesario y dedicando más tiempo a la implementación.
• Permite la entrega de un producto funcional al finalizar cada Sprint.
• Da la posibilidad de ajustar la funcionalidad en base a la necesidad de negocio del cliente.
• Permite hacer una visualización del proyecto diaria.
• Tiene un alcance acotado y viable.
• Se aplica en equipos integrados y comprometidos con el proyecto y que se auto administran.
• No es una metodología de análisis, ni de diseño (aunque puede adaptarse para que lo sea) sino de gestión del trabajo.
• Puede ser aplicado a distintos modelos de calidad (como podría ser CMMI) puesto que estos te dicen qué tienes que hacer, es decir, te dicen que tienes que gestionar el proyecto, pero no te dicen cómo. Ahí es donde entra SCRUM como modelo de gestión del proyecto.

Descripción de los procesos del negocio.

Para describir los procesos del negocio que se relacionan con el campo de acción de este trabajo, es necesario centrar la atención en los procesos de solución de problemas y la relación de las aplicaciones de este tipo que se conocen.

Este trabajo pretende modelar los procesos de ventas mayoristas según las regulaciones planteadas de forma que se cumpla con las especificaciones del comercio en Cuba. Estas regulaciones particulares se relacionan a continuación:

Contratación y el  Proceso de Venta

Para la realización de las ventas mayoristas, el Área Comercial o Especialista de la Unidad  deberá conformar el Expediente de cada Comprador, el cual contará con los siguientes documentos:

• Resolución de nombramiento y facultad de la persona autorizada a firmar Contratos.
• Licencia del Banco Central de Cuba que autoriza a la entidad o empresa a operar en divisas, debidamente actualizada.

Acta, Escritura, Resolución, Documento protocolizado ante Notario u otro documento legal de constitución de la entidad o empresa, conjuntamente con su objeto social. Contrato de compraventa firmado y acuñado, según Pro forma de Contrato (Anexo No 4)

Los Contratos de Compraventa Mayorista serán promovidos  por la Unidad de Venta, Producción o Servicio, ajustando las cláusulas de la pro forma de contrato (Anexo 4) al comprador con el que se está suscribiendo. Una vez precisados con el Comprador los términos en que se realizará el contrato y los intereses de compra del cliente en el territorio debe ser remitido a la Asesoría Legal de la Sucursal Provincial para su revisión.

El Contrato de Compraventa Mayorista será suscrito a nombre de la entidad que publica el sistema y será firmando por el Director de la Sucursal Territorial y el Director Comercial. Los contratos  tendrán alcance a todas las Unidades de Ventas Mayoristas del Territorio previamente pactadas en los Contratos. En el Contrato se deberán relacionar en anexo expreso las Unidades del territorio donde se realizaran las Ventas Mayoristas al Comprador con el que se suscribe el Contrato, determinando las que se comercializaran en cada una de las Unidades.

En ningún caso los contratos de ventas mayoristas abarcaran Unidades o Áreas  Mayoristas de otros territorios. Una vez suscrito el Contrato Mayorista la Asesoría Jurídica de la Sucursal Provincial certifica las copias de las Unidades a las que tiene alcance el contrato. La Dirección Comercial de la Sucursal es responsable de proporcionar las referirías copias certificadas a las Unidades que ampara el Contrato.

En casos de nuevos clientes, la Sucursal Provincial solicitará a la Dirección de Comercio de la Casa Matriz el No. de Cliente según lo establecido sobre el Nomenclador Corporativo de Clientes y Proveedores.  Las Unidades que no cuenten con las copias certificadas de los contratos o no se encuentren actualizados los referidos contratos y no esté habilitado en el sistema el Código de Cliente, no podrán efectuar las ventas hasta tanto no quede actualizada en el expediente de la Unidad la documentación establecida y habilitado el No. de Cliente en el Nomenclador.

Los Contratos que se suscriban con Empresas u Organismos estatales para la venta de módulos a sus trabajadores tendrán definida la Unidad Especializada para la venta mayorista al detalle y no tendrá alcance a otras unidades, territorios o tipos de venta.

Para los Contratos de Compraventa con las Sucursales de las Sociedades

Mercantiles Extranjeras radicadas en Cuba, así como los Operadores de Zona Franca serán firmados solamente por el representante de las mismas, debidamente autorizado para ello. Los documentos requeridos para suscribir contratos con éstas entidades con los siguientes:

• Licencia de la Cámara de Comercio o MINVEC, según sea el caso, con lo cual se  notifique su estatus en el país.
• Acta de Escritura, Resolución, documento protocolizado ante notario u otro documento legal de la constitución de la entidad.
• Ficha del cliente, donde se relacionan los funcionarios autorizados para realizar las compras.

Los contratos con las Embajadas y Consulados serán firmados por el Embajador y/o Representante. En la ficha del cliente, además de los datos relacionados, se adjuntará la copia del carnet emitido por el MINREX para los funcionarios autorizados a realizar las compras y copia del carnet de la Agencia Empleadora de los funcionarios y trabajadores autorizados a recoger mercancía.

Los Contratos que se suscriban con los Proyectos o Programas de Colaboración del Ministerio para la Inversión Extranjera y la Colaboración Económica deberán presentar copia certificada por el MINVEC del presupuesto y Términos del Proyecto aprobado con las obligaciones de las contrapartes que  deberá estar firmado por éstas  contrapartes y el MINVEC.

Los Contratos Mayoristas se suscribirán por  un (1) año fecha a partir de la cual caduca su vigencia. Los Contratos Mayoristas no son prorrogables automáticamente, requieren suplementarse y de forma obligatoria la vigencia y la ficha del cliente cumpliendo con lo regulado para éste último documento.

En el momento de realizar la venta, la Unidad revisará las fichas de clientes  y su vigencia así como verificará si la entidad interesada está debidamente registrada en el nomenclador de clientes.

Las ventas mayoristas a Instituciones Religiosas, Empresas y Organismos de la Administración Central del Estado, Organizaciones Políticas, Sociales y de Masas, Representaciones Diplomáticas y Consulares, a las Sucursales de

Sociedades Mercantiles Extranjeras, Operadores de Zona Franca, Representaciones Bancarias y Proyectos o Programas del MINVEC; se realizarán según lo establecido en el presente procedimiento en correspondencia con la Resolución 222/2003, la autorización I-885/2007 y de la Instrucción 2/2003 todas del Ministerio del Comercio Interior.

Para la realización de la venta a los clientes que se mencionan en el apartado anterior, la Unidad exigirá además de los anteriores, la presentación de los siguientes documentos:

• Para las representaciones de Bancos Extranjeros:
  • Carta de solicitud de compra con la relación de productos a comprar y cantidad.
  • Resolución del Banco Central de Cuba que autoriza que la representación bancaria opere en Cuba.
• Para las Sucursales de Sociedades Mercantiles Extranjeras y Empresas Mixtas:
  • Carta de solicitud de compra con la relación de productos a comprar y la cantidad.

• Licencia expedida por la Cámara de Comercio de la República de Cuba, para operar en el país.

• Para los Proyectos y Programas de colaboración aprobados por el MINVEC:
  • Copia Certificada por el MINVEC del Presupuesto del Proyecto o Programa. o Copia Certificada por el MINVEC de los Términos de Referencia del Proyecto aprobado con las obligaciones de las contrapartes y las firmas de éstas y del MINVEC.
• Para los Operadores de Zona Franca:
  • Carta de solicitud de compra con la relación de productos a comprar y la cantidad.
  • Resolución del Ministerio para la Inversión Extranjera que lo acredita como Operador.
• Para las Embajadas y Consulados:
  • Carta de solicitud de compra con la relación de productos a comprar y la cantidad.
  • Identificación que lo acredita como miembro del cuerpo Diplomático, expedida por el Ministerio de Relaciones Exteriores de Cuba.
• Para las Empresas y OACE:
  • Las entidades presentaran la documentación legal establecida en el sistema de Contratación Mayorista y demás requisitos establecidos en el presente procedimiento sin requerir otras autorizaciones especiales para los productos que no cuenten con regulaciones especiales.  ü Para las Instituciones Religiosas:  
  • La autoridad superior de la Institución Religiosa interesada en la compra emitirá un documento firmado y acuñado  donde refleje las necesidades que demanda, sus destinos y contra que actividad se realiza. En los casos que se demanden artículos de aseo personal, higiene y limpieza, esta debe acompañarse de una declaración jurada del número de personas atendidas en la entidad de destino de los productos. Cuando la solicitud se refiera a equipos eléctricos o electrodomésticos, cocinas industriales o bicicletas con o sin motor la institución religiosa deberá presentar una solicitud de autorización al Viceministro del Ministerio de Comercio Interior y una vez emitida será tramitada por la Vicepresidencia Comercial con las Sucursales y Divisiones. Una vez recibida la autorización del Vicepresidente Comercial o del Viceministro de Comercio Interior, según sea la aprobación y la Institución Religiosa solicite la compra, la Sucursal Provincial consultará por escrito al  que atiende Religión en el Comité Provincial del territorio para que emita su aprobación sobre la venta. En caso que se vete total o parcialmente deberá ser comunicado por escrito a la Vicepresidencia Comercial.  En todos los casos la Unidad que reciba solicitud de compra de Instituciones Religiosas deberá tramitar y recibir la autorización escrita para realizar la venta. Los documentos de autorización y consulta se archivan en el expediente del contrato.  Cuando se reciba solicitud de oferta de un cliente para la  compra mayorista de mercancías no acorde con lo habitual o se aprecien volúmenes o productos que no se correspondan con la actividad que desarrolla la Empresa o Institución, se solicitará de forma puntual que la solicitud sea emitida o avalada por el Jefe de la Empresa o Institución mediante documento en el que se reflejen los productos y las cantidades que se solicitan.

Márgenes comerciales, los créditos y los instrumentos de pago

La determinación del precio se realizara sobre la base de calcular todos los costos del producto hasta su puesta a la venta a partir lo cual se establecen los siguientes márgenes comerciales mínimos:

• Para las Subcuentas de Partes y Piezas automotrices y Materiales de la Construcción =  Precio de Costo x 1.80.
• Para la Venta de Mercancías = Precio de Costo x 1.30
• Para las Producciones de Gastronomía = 10% inferior al Precio de Venta Minorista.
• Para los Servicios = Ficha de Costo del Gasto Total x 1.30
• Firmas e Instituciones  Extranjeras,  Cuerpo Diplomático =  Precio de Costo x 1.40
• Instituciones Religiosas = Precio de Costo x 1.60
• Para la venta mayorista al detalle (Módulo) = Precio de Costo x 1.30

(Los precios de venta de las mercancías comercializadas en Unidades para la venta de módulos serán redondeados a 0 ó 5 siguiendo el mismo procedimiento que en la formación del precio minorista)

En el acto de venta pueden aplicarse precios superiores atendiendo a la calidad del producto, su posición en el mercado y la negociación con el cliente.

Cuando existan razones fundadas que aconsejen la reducción de los márgenes establecidos, el Director Comercial  de la Sucursal o División solicitará al Vicepresidente Comercial a través del Dpto. de Ferretería y Ventas Mayoristas la autorización para realizar la venta con márgenes inferiores a los establecidos.

En las propuestas deben evaluarse:

1. Volumen de la venta.
2. Inventario y Rotación de los productos.
3. Características del Comprador al que se propone vender.
4. Margen Comercial que se propone.
5. Otros elementos cuantitativos y cualitativos que la fundamenten.

Las ventas mayoristas de mercancías  a entidades externas, sólo se realizará mediante el pago contra la entrega de las mercancías.

El cobro se realizara mediante la presentación de cheque emitido por el comprador al vendedor, transferencias bancarias recibidas y acreditadas en la cuenta del Vendedor y por tarjeta magnética en el momento de realizarse  la venta, siguiendo el procedimiento establecido para este sistema de cobros.

Los Cheques con importes superiores a 500 CUC deberán certificarse por la entidad Bancaria.

Las ventas mayoristas sólo se realizarán a personas jurídicas. Por ningún concepto se recibirán cheques u otros instrumentos de pago de personas naturales.

Para las ventas mayoristas de producciones y servicios, incluidos los productos que forman parte de estas, se podrán emitir créditos de hasta 30 días.

Para las Ventas Mayoristas de Mercancías excepcionalmente se emitirán Créditos Comerciales hasta 30 días posteriores a la facturación los cuales serán autorizados previamente por escrito por el Vicepresidente Comercial, a propuesta del Director de la Sucursal correspondiente; para lo cual se deberá realizar un análisis previo de los siguientes aspectos:

• Monto de la mercancía a vender.
• Solvencia económica reconocida del cliente.
• Si es cliente habitual, puntualidad en los pagos anteriores
• Conveniencia de la empresa de realizar las mercancías propuestas a vender a crédito.

Los incumplimientos del pago en el plazo fijado en el Crédito Comercial otorgado, tanto para las ventas mayoristas de mercancías autorizadas a crédito como en las producciones y servicios, imposibilitan a realizaran nuevas ventas hasta tanto se realice el pago de las deudas.

Los incumplimientos en los pagos de las mercancías autorizadas excepcionalmente a vender a crédito  anulan automáticamente la autorización del Crédito Comercial al Cliente Moroso y podrá reanudarse la venta una vez saldada la deuda envejecida con el pago contra la entrega de la mercancía.

Los clientes objetos de crédito comercial de las ventas mayoristas de producciones y servicios  que reiteradamente incumplan los plazos en sus compromisos de pago serán objeto de análisis y la adopción de medidas que garanticen el cobro en el tiempo previsto o la suspensión del crédito comercial.

Las cuentas por cobrar que pudieran generarse por incumplimientos de pago serán objeto de una activa y sistemática gestión de cobro por la unidad que la registra, adoptando las medidas establecidas, incluida la presentación a los tribunales competentes.

Facturación

El Área Comercial o Especialista de la Unidad confeccionará una prefactura u oferta de venta al cliente, fijando los datos de éste, los datos del producto, cantidades y precios así como la  fecha de validez de la oferta sin que se creen obligaciones de reservar los productos.  Cuándo la venta a realizar aconseje reservar los productos deberá asegurarse financieramente su realización y consignarse el plazo para ello.

En el momento de la venta el Área Económica confeccionará la factura final de venta atendiendo a la oferta presentada, entregándole al  comprador el original debidamente firmado y acuñado. El duplicado se archiva en la Unidad de Venta y el triplicado se expide al transportista.

La facturación mayorista se realizará de acuerdo  a lo establecido en la

Instrucción No 15/2006 del MFP.  Será responsabilidad del Jefe Económico o Contador de la Unidad, archivar la copia de cada una de las facturas emitidas debidamente firmadas y acuñadas por las personas facultadas. Debe consignarse el cuño de pagado en las facturas cuyo cobro se haya realizado y comprobado, independientemente del instrumento de pago utilizado. No deben realizarse ventas ni emitir facturas sin que previamente se haya comprobado la acreditación del pago.  En los casos que establece el presente procedimiento donde se otorgan créditos comerciales debe fijarse la fecha de pago en la factura como referencia cruzada. En los casos en que se utilice el Cheque como instrumento de pago se deberá archivar junto a la factura una copia del cheque recibido del cliente.   En los casos de otros instrumentos de pago se

dejará copia del comprobante que acredite el pago al momento de realizar la facturación.

Descripción del sistema propuesto.

Para cumplimentar el objetivo propuesto al inicio de este trabajo y teniendo en cuenta los procesos de negocio planteados, el sistema que se propone constará de tres sitios:

• HostingService (Servidor de Servicios): Es el sitio principal del sistema: contiene un conjunto de servicios web publicados que deben permitir realizar todos los procesos planteados anteriormente. Todos los demás sitios trabajan con los servicios expuestos en este.
• AdminSite (Sitio de Administración): Es un sitio destinado para el trabajo de los funcionarios y que implementa todas las funcionalidades señaladas para estos. Este sitio no es muy vistoso teniendo en cuenta sus usuarios finales.
• VirtualStore (Tienda Virtual): Es la tienda virtual que será vista por los clientes. Dispone de todas las funcionalidades implementadas en cualquier tienda en línea y ajustas las necesarias a las particularidades cubanas.

Roles de usuarios

A continuación se relacionan los roles preconcebidos para actuar sobre el Sistema de Gestión de Ventas de Productos al por Mayor:

Rol                      Justificación

Usuario Es cualquier persona que quiera acceder al Sistema y que no necesita autenticarse para navegar en las páginas públicas.

Funcionario Especialización de Usuario: Es una persona perteneciente a la Unidad o de Ventas Mayoristas autorizada a realizar acciones varias en la tienda virtual. Generalización de Administrador, Comercial, Jurídico y Vendedor.

Administrador Especialización de Funcionario, encargado de la administración general del sistema. Persona encargada de la configuración inicial del sistema y solución de problemas administrativos.

Comercial Especialización de Funcionario encargado de procesar los productos nuevos recibidos del Sistema  de inventario y fijarle el precio de venta según reglas de formación de precios.

Jurídico Especialización de Funcionario que se encarga de “bloquear” el acceso a los clientes con problemas de esta índole evitando que compren en la tienda en línea.

Vendedor           Especialización   de       Funcionario que     procesa        ordenes comenzadas por los clientes o crea nuevas en presencia de este en un mostrador de ventas fijo en la tienda física de ventas mayoristas.

Cliente Especialización de Usuario identificado por un contrato y que representa a una persona jurídica autorizada a hacer compras al por mayor en la tienda.

Arquitectura orientada a servicios n-tiers

Una arquitectura orientada a servicios (No necesariamente SOA) facilita la integración con otros sistemas, tanto locales como externos de otras empresas, abriendo puertas para el Sistema de Comercio Electrónico Mayorista; facilita la reusabilidad pues los servicios se pueden consumir por un sin número de aplicaciones, o se pueden componer entre sí para formar otras. Combinado con una arquitectura n-tiers facilita el mantenimiento y la flexibilidad.

Figura 2. Forma de organización de los servicios e interfaces que pueden consumirlos.

El Sistema se divide en las siguientes capas:

• Capa de Interoperabilidad.
• Capa de Negocio.
• Capa de Acceso a Datos.
• Capa de Datos.

Figura 3. Vista lógica general

El Sistema se comunica con los usuarios a través de la capa de interfaz y con otros sistemas a través de otros servicios.

La comunicación de la capa de servicios con otros sistemas y con las interfaces graficas de usuario estará basada en mensajes SOAP^[2] utilizando el estándar industrial WS-*. La capa de negocio ofrece una fachada a los clientes y el resto de los servicios cooperan transaccionalmente para llevar a cabo las funciones de negocio.

Los servicios utilizan una capa de acceso a datos para interactuar con la base de datos. Este modelo es flexible en cuanto al tipo base de datos a utilizar. El uso de NHibernate permitirá el uso de cualquier otro gestor solo cambiando las configuraciones pertinentes.

Despliegue

La arquitectura del sistema permite una escalabilidad vertical y horizontal. El sistema es bastante flexible a la hora de elegir una variante para el despliegue. Los siguientes diagramas muestran posibles configuraciones de despliegue y la distribución de las aplicaciones en esas variantes.

Aplicacion Web y servicios

Figura 4. Variante de despliegue

Atendiendo a que algunos servicios son internos y otros privados, se recomienda la siguiente configuración:

Figura 5. Variante recomendada de despliegue.

Seguridad

La seguridad del sistema se aplica en 3 dimensiones fundamentales: Cliente Ligero, Servidor de Aplicación y Servidor de BD.

Figura 6. Dimensiones de la seguridad del sistema

En el cliente las mayores amenazas de seguridad son el Cross Site Scripting (XSS) y el SQL Injection. Las consideraciones que se han hecho para eliminar estas brechas son las siguientes:

XSS

• Usar el mehotd POST y no GET y hacer validaciones de datos en el lado del servidor.

SQL Injection

• Se creo la Base de Datos bajo el principio del mínimo privilegio.
• Se regula el flujo de las Consultas SQL mediante el NHibernate.
• Se filtran errores las excepciones lanzadas por el servidor para ofrecer la descripción del libre de datos que describan la forma en que se estructuran las entidades.

Para la eliminación de posibles ataques al servidor de aplicación se implementa el servicio de seguridad en una Infraestructura de clave pública (PKI, Public Key Infrastructure) que es una combinación de hardware y software, políticas y procedimientos de seguridad que permiten la ejecución con garantías de operaciones criptográficas como el cifrado, la firma digital o el no repudio de transacciones electrónicas.

Igualmente, se reimplementó la seguridad que provee ASP.NET para que se usen los métodos del servicio de seguridad y brindar así la vía para la Autenticación, Autorización y Control de Acceso de los usuarios. Para la autenticación de los servicios se genera un “toquen” de seguridad que espira a los 15 segundos.

En el servidor de datos igualmente se trabajó bajo el principio de mínimo privilegio y se configuran las reglas de seguridad del gestor (SQL 2005 Express en este caso pero configurable en cualquier otro gestor que se determine). La aplicación controla que las peticiones que se hacen a los servidores provengan de la subred predefinida para el acceso de los usuarios en cada caso posibilitando elevar aun más los niveles de seguridad del sistema.

Finalmente se hacen las configuraciones para el trabajo con el historial y las restricciones de contraseñas  y se firman digitalmente las facturas generadas por los funcionarios y los clientes garantizando el no repudio de las acciones que acometen. Igualmente, con el uso de la programación orientada a aspectos y Spring Framework se garantiza la generación de bitácoras (trazas) de seguridad que se registran en el servidor Web y en la Base de Datos.

Product Backlog / Pila de Tareas del Producto

Los requisitos del sistema o del producto desarrollado se enumeran en el Product Backlog. El Product Owner es responsable del contenido, priorización, y disponibilidad de este: nunca se acaba y es usado en la planificación del proyecto, es simplemente una estimación inicial de los requisitos. El Product Backlog se desarrolla paralelamente a medida que  el producto y el ambiente en el cual se trabaja evoluciona, es dinámico; maneja constantemente los cambios para identificar que necesita el producto para ser: apropiado, competitivo, y útil. Mientras exista un producto, el Product Backlog también existe.

Id     Modulo                Descripción                                                                   Estado

Requerimientos Críticos

1 HostingService El Sistema recibe información de un “Sistema  100% de inventario” sobre la existencia de productos

 

Id	Modulo	Descripción	Estado
		destinadas al “área para venta en línea” (Código de producto, CSTA o familia, Nombre, Descripción, Cantidad, Costo, Precio minorista; y el por ciento de descuento para clientes aplicables.
2	AdminSite	El        Sistema                     espera           por      un             proceso administrativo       de             preparación   de       estos productos para la presentación a los clientes, este proceso incluye: Definir o crear la(s) imagen(es) del producto si existe(n). Asignar el producto a la categoría a la que pertenece. Marcar el producto como listo para la venta (activo).	100%
3	AdminSite	El     registro     de     los     usuarios      se      hace 100% administrativamente por algún personal de la Empresa que tendrá un usuario en el Sistema  con rol administrador de usuarios. ü  Existen varios tipos de usuarios del sitio: Clientes, Funcionarios. ü  Dentro de los usuarios funcionarios se encuentran los siguientes roles: o   “Administrador” usuario administrativo general. o   “Administrador de Usuarios” encargado de registrar usuarios cliente en el Sistema. o   “Administrador Comercial” encargado de procesar los productos nuevos recibidos del Sistema  de inventario y fijarle el precio de venta. o   “Administrador Jurídico” encargado de “bloquear” a los clientes con problemas para evitar que compren en la tienda en línea. o   “Comercial Vendedor” usuario del Sistema  que procesa ordenes comenzadas por los clientes. ü  Los  usuarios clientes se pueden encontrar en estos roles:

 

Id     Modulo                Descripción                                                                  Estado

o “Cliente Autorizado” comprador identificado por un contrato y que representa a una persona jurídica.

4 AdminSite El Sistema debe almacenar la siguiente 100% información de los clientes: Nombre de la empresa, numero de registro comercial, si es cliente interno, si es cliente diplomático, si es cliente “una moneda”, en caso que pague con cheque „a plazo‟ especificar la cantidad de días.

5      AdminSite                 El Sistema  debe manejar un mecanismo de 100% rebajas, esas se aplican a un cliente específico, o a un producto especifico: ü  Cliente Especifico: Determinados clientes preferenciales tienen un por ciento de descuento en todas las compras que hagan mientras esta preferencia sea válida. Este por ciento lo define un administrador comercial. Si en una compra el cliente es un “cliente preferencial”, al monto total de la compra se le aplicará este descuento y no se continuará aplicando ningún otro descuento. ü  Producto Especifico: Algunos productos tienen un por ciento de rebaja en su precio de venta. Este por ciento es especificado por el  administrador comercial. En una compra se aplicaran descuentos a aquellos productos que lo tengan siempre que el cliente actual no sea preferencial, en ese caso solamente se descuenta su por ciento sobre el monto total sin tener en cuenta los productos con descuento.

Requerimientos Necesarios

6                                     VirtualStore           El Sistema  debe mostrar a los clientes la 100% siguiente           información   de       los         productos aprobados          y          organizados por         categorías definidas: imagen, nombre, precio  de venta.

7 VirtualStore El Sistema debe mostrar a los clientes 100% información detallada sobre un producto determinado mostrando: imagen, precio de venta, nombre, descripción, cantidad en existencia.

 

Id	Modulo	Descripción	Estado
8	VirtualStore	El Sistema debe brindar un buscador  de productos	100%
9	VirtualStore	El Sistema mostrará al usuario los X productos visitados resientes durante su visita al sitio.	100%
11	VirtualStore	El Sistema debe brindar un “carro de compras” donde se pueda ir almacenando productos hasta que se desee comprar. ü  Los elementos en el carro de compras debe continuar disponible en próximas visitas al sitio hasta que se proceda a comprar o los productos se eliminen del Sistema. ü  El Sistema debe permitir hacer modificaciones a la cantidad o tipo de productos adicionados al carro de compras. ü  En el carro de compras el Sistema debe mostrar el monto de cada producto y el monto total. ü  Si algún producto deja de existir al actualizar o abrir el carro de compras, este aparecerá destacando su faltante.	100%
12	VirtualStore	El carro de compras debe permitir pre-facturar su contenido. ü  El Sistema confeccionará una pre-factura que contiene el nombre, descripción, precio de venta y cantidad de cada producto seleccionado, y un resumen con el monto total a pagar. ü  El Sistema  guardará un historial de las pre-facturas para futura consulta, esta información es privada para el cliente pero accesible por los administradores. ü  La pre-factura estará visible para el cliente durante un tiempo X configurable por el administrador.	100%
13	VirtualStore	Una vez hecha la pre-factura el Sistema  debe permitir “reservar la mercancía”. ü El Sistema reservará durante un tiempo X, configurable por el administrador, la mercancía solicitada en una determinada pre-factura. Si durante este tiempo no se ha pagado dicha pre-factura, la	100%

 

Id	Modulo	Descripción	Estado
		mercancía no estará reservada. Esta opción es configurable por el administrador quien selecciona si está habilitada la reserva o no. ü El Sistema genera la “nota de reserva de mercancía”, que contiene un memorándum para el cliente sobre el tiempo en el que estará reservada la mercancía y las condiciones de reserva.
14	VirtualStore	Una vez hecha la pre-factura el Sistema debe 100% permitir “comprar la mercancía”. ü  El Sistema  debe chequear que los productos y cantidades adicionadas a la factura todavía están disponibles para la compra actual y tomar las medidas pertinentes en caso de que no lo estén. ü  El cliente debe seleccionar el tipo de pago: Cheque, Carta de Crédito, Letra de Cambio, Pago En línea, o Pago en Efectivo. El Pago en Efectivo se puede combinar con Cheque para el caso que el cheque del cliente sea inferior al monto de la factura, se aceptan pagos en efectivo hasta por $0.99, el sistema genera un comprobante de pago. Para el pago con Cheque o Letra de cambio o Efectivo, el cliente proporcionará los datos relevantes. Si el cliente paga más del monto de la factura, el Sistema genera una carta de crédito. El Sistema guarda las cartas de crédito y las notifica al             sistema          de       facturación. Administrativamente se cancelan las cartas de crédito. Para concretar el pago y que el Sistema considere la orden o pre-factura “pagada” y continuar el proceso, el cliente debe presentarse en el local comercial de la Empresa y el funcionario debe procesar el pedido como se explica más adelante en este documento. ü  El Sistema debe tener en cuenta las siguientes reglas a la hora de calcular el monto total de un pedido: o  Para clientes (firmas extranjeras que no tienen cuenta en MN) de

 

Id     Modulo                Descripción                                                                  Estado
una sola moneda: se cobra solamente la componente CUC. o Para clientes externos con que pagan en una sola moneda: el monto MN se suma al CUC sin conversión alguna. o   Para clientes con descuento en CUC y cobro en MN: se le descuenta del CUC el valor del MN sin conversión alguna, y se cobra por separado: el CUC con el descuento y el MN completo. o Para clientes internos se cobra el costo base en CUC y el MN. o   Para diplomáticos se cobra el precio minorista pero restándole el por ciento aplicable para algunos productos. ü Una vez generada la factura, el Sistema notifica al usuario los días que tiene para recoger la mercancía, esto es una política de la Empresa y no depende del tipo de productos que haya comprado.
Requerimientos Opcionales
15 AdminSite El Sistema  debe brindar una interfaz de trabajo 56% para el personal comercial en el local comercial de la Empresa: ü  El Sistema debe mostrar detalles de las órdenes o pre-facturas y facturas. ü  El Sistema debe permitir que un funcionario procese una orden que confeccionó un cliente estando este presente. o   El funcionario debe seleccionar la orden. o   Si el pago es por Letra de Cambio, Cheque o Efectivo, debe realizarlo manualmente y el Sistema debe permitir marcar la orden como pagada. En caso de Efectivo el Sistema  genera un comprobante de pago. o   Una vez procesada la orden el Sistema se comporta igual que si fuera procesada en línea: la mercancía             es        reservada         de
Id	Modulo	Descripción                                                                   Estado
		verdad, los productos comprados se rebajan del área de venta. ü El Sistema  debe permitirle a los administradores jurídicos congelar algún cliente. Estos clientes no pueden efectuar compras.
16	VirtualStore	El Sistema  publicará el formulario utilizado por 65% la Empresa para afiliarse como comprador.

Requerimientos adicionales

• Apariencia o interfaz externa:
  • Diseño sencillo, una interfaz simple de usar e interactiva para que al usuario le sea fácil el trabajo con el Sistema.
  • Diseño perfectamente encuadrado para resoluciones de 1024×768, pero preparado para verse en otras resoluciones.
• Usabilidad:
  • La instalación del sistema trae consigo una mayor rapidez en la venta de productos al por mayor haciendo su proceso mucho más eficiente.
• Software:
  • La aplicación se hospeda en un servidor web IIS o Apache con el módulo para compilar páginas “aspx” instalado.
  • El servidor de base de datos debe ser SQL Server 2005 o PostgreSQL aunque puede instalarse cualquier otro especificándolo en la configuración del Sistema.
  • Todas las máquinas clientes deben tener un navegador instalado, preferentemente de la versión Internet Explorer 5.0 en adelante, pueden ser además: Mozilla FireFox, Netscape y Opera

(versiones recientes).

• Además, instalado el Flash Player versión 6.0 o superior para visualizar el banner (opcional).

• Portabilidad:
  • La aplicación se podrá ejecutar en la mayoría de los sistemas operativos tales como Microsoft Windows 98/Me/2000/XP y Linux, en estos últimos instalando las versiones Linux de los software especificados en estos requerimientos.
• Hardware:
  • Para trabajar con el sistema de forma eficiente se necesita una máquina servidor que como mínimo debe tener las siguientes características: Pentium IV con 768 MB de RAM, un microprocesador a 3.00 GHz y una tarjeta de red Protocolo Ethernet 10/100 MB/s.
  • Para máquinas clientes: un procesador gráfico de 16 bits o superior con una resolución de 1024×768 píxeles o superior, procesador a 600 MHz y memoria RAM de 64 MB o superior.

Deben estar conectadas en una red local de 10/100 MB o deben tener un módem de línea telefónica con una conexión a 128 Kbps.

Aportes prácticos y vías de solución.

Primeros pasos

Luego de instalado el sistema deben configurarse los siguientes elementos para su correcto funcionamiento:

Metadatos: Este concepto surge para almacenar datos no concebidos en las entidades de la base de datos diseñada. Por ejemplo: El sistema almacena de los contratos su número, fecha de creación, y opcionalmente si este es destinado a una empresa (en caso contrario es una persona); si se desea que este contrato tenga una nueva propiedad “X” se define como un metadato de contrato y se especifica el tipo de dato y si es requerido a la hora de completar el formulario. De esta forma, cuando se presente el formulario de Contrato se pintarán los campos predefinidos para el y los agregados por la vía de los Metadatos.

Roles: Independientemente de los niveles de usuarios que se establecen para el funcionamiento básico del sistema en sus archivos de configuración estos pueden o no existir. Para el uso del sistema con roles personalizados se crea esta entidad encargada de manejar las definiciones de roles del sistema.

Categorías: El sistema funciona con las familias (o agregados) provistas(os) por el sistema de inventario o permite personalizarlas. Esta definición de categorías es necesaria al instalar el sistema para poder organizar luego los productos.

Monedas: El sistema se concibe con la idea de que pueda ser configurado para el uso de 1, 2 o „n‟ monedas. Para ello se establece la entidad del mismo nombre encargada de guardar sus especificaciones. Estas serán usadas para la definición de precios mayoristas como se explica más adelante.

Unidades de Medida: Los productos que se venden pueden ser tratados tanto por sus unidades de medidas base (provenientes del sistema de inventario) o por las equivalencias que se definan en el sistema. Para ellos se crean las entidades UM y Equivalencia respectivamente.

Contenido: Es la definición de un contenido en formato HTML que será mostrado en la portada del sitio se designe. Para ello se cuenta con un editor de páginas en formato visual WYSIWYG.

Los demás elementos se incorporan al sistema o bien por la vía del sitio de administración o por los servicios web publicados con ese fin.

Manejo de multimoneda y formación de precios mayoristas

Una vez identificadas las „n‟ monedas con las que trabajará el sistema se debe(n) crear la(s) regla(s) de formación de precios. Para ello se cuenta con un formulario en el cual el administrador comercial del sistema ingresa sus especificaciones siendo la más importante la “fórmula”.

Esta fórmula no es más que una expresión regular con el siguiente formato:

(\w{1,}([-+*/’]\d{1,})*;)*

Una cadena de caracteres que debe corresponderse con el identificador de la moneda que se formula, un operador matemático, un valor de afectación y la terminación de la expresión especificada por un punto y coma (;). El caso de las expresiones regulares fuera del formato especificado será ignorado por el evaluador. La idea es lograr especificaciones como esta:

CUC*9/10; CUP;

En este caso, los clientes afectados por la regla mostrada, tendrán como precio mayorista el resultado de evaluar la función escrita, con el precio minorista en cada una de sus componentes.

Para clientes que operan con una sola moneda o solo con una parte de las „n‟ configuradas en el sistema se omiten o no partes de la regla. Por ejemplo: si el sistema está configurado para trabajar con CUC y CUP y se quiere que un cliente pague el 98% de la componente CUC deberá escribirse la siguiente regla:

CUC*98/100;

Definidas las reglas el sistema es capaz de evaluarlas para los clientes autenticados de forma tal que es posible que un cliente “X” y otro “Y” se encuentren visitando un producto al unísono y vean precios diferentes debido a las reglas que se le aplican.

Con lo descrito hasta el momento se logra que el sistema formule precios y totales acorde a los clientes que navegan en sus páginas pero, ¿cómo se realiza el pago?

Cuando el cliente tiene en su “carro de compras” los productos que desea comprar puede imprimir el contenido  o remitirse al formulario de pago donde se recogerán los datos de las tarjetas de crédito para cada una de las cuentas asociadas a las monedas en las que se realiza la venta. Opcionalmente puede definir un destinatario para la compra caso en el cual se requerirán nuevos datos y se reevaluara el precio total teniendo en cuenta la distancia de la entrega.

Servicio en Línea

Como un valor agregado se incluye al sistema una vía de servicio en línea. Para ello se idea en las vistas detalladas de productos la opción con este nombre con la que los clientes pueden desplegar un panel de chat y contactar un funcionario encargado de atender estas solicitudes u otros clientes que navegan en el sitio. De esta forma se propicia un entorno de intercambio de información comercial sobre los productos y de experiencias de su uso entre funcionarios y clientes.

Para evitar los usos indebidos de esta opción se debe implementar un diccionario de palabras “no permitidas” y que tanto los funcionarios encargados de atender estas solicitudes como los administradores jurídicos se velen por la integridad de lo que se envía inactivando el acceso de los clientes infractores so pena de medidas comerciales añadidas como clausulas al contrato.

Construcción de la propuesta de solución

Principios del diseño de la aplicación

Los 7 Principios del Diseño Universal, se centran en el diseño utilizable universalmente o por todos, pero hay que tener en cuenta que en el diseño intervienen otros aspectos, como el coste, la cultura en la que será usado, el ambiente; que tampoco pueden olvidarse. Estos Principios generales del diseño, son aplicables y de hecho se aplican en la arquitectura, la ingeniería y, por supuesto, las páginas y aplicaciones Web, entre otros campos de aplicación.

1er Principio: Uso equiparable

El diseño es útil y vendible a personas con diversas capacidades.

Pautas para el Principio 1:

• Que proporcione las mismas maneras de uso para todos los usuarios: idénticas cuando es posible, equivalentes cuando no lo es.
• Que evite segregar o estigmatizar a cualquier usuario.
• Las características de privacidad, garantía y seguridad deben estar igualmente disponibles para todos los usuarios.
• Que el diseño sea atractivo para todos los usuarios.

2do Principio: Uso flexible

El diseño se acomoda a un amplio rango de preferencias y habilidades individuales.

Pautas para el Principio 2

• Que ofrezca posibilidades de elección en los métodos de uso.
• Que pueda accederse y usarse tanto con la mano derecha como con la izquierda.
• Que facilite al usuario la exactitud y precisión. ü Que se adapte al paso o ritmo del usuario.

3er Principio: Simple e intuitivo

El uso del diseño es fácil de entender, atendiendo a la experiencia, conocimientos, habilidades lingüísticas o grado de concentración actual del usuario.

Pautas para el Principio 3

• Que elimine la complejidad innecesaria.
• Que sea consistente con las expectativas e intuición del usuario.

 

Que se acomode a un amplio rango de alfabetización y habilidades lingüísticas.

• Que dispense la información de manera consistente con su importancia.
• Que proporcione avisos eficaces y métodos de respuesta durante y tras la finalización de la tarea.

4to Principio: Información perceptible

El diseño comunica de manera eficaz la información necesaria para el usuario, atendiendo a las condiciones ambientales o a las capacidades sensoriales del usuario.

Pautas para el Principio 4

• Que use diferentes modos para presentar de manera redundante la información esencial (gráfica, verbal o táctilmente)
• Que proporcione contraste suficiente entre la información esencial y sus alrededores.
• Que amplíe la legibilidad de la información esencial.
• Que diferencie los elementos en formas que puedan ser descritas (por ejemplo, que haga fácil dar instrucciones o direcciones).
• Que proporcione compatibilidad con varias técnicas o dispositivos usados por personas con limitaciones sensoriales.

5to Principio: Con tolerancia al error

El diseño minimiza los riesgos y las consecuencias adversas de acciones involuntarias o accidentales.

Pautas para el Principio 5

• Que disponga los elementos para minimizar los riesgos y errores: elementos más usados, más accesibles; y los elementos peligrosos eliminados, aislados o tapados.
• Que proporcione advertencias sobre peligros y errores.
• Que proporcione características seguras de interrupción.
• Que desaliente acciones inconscientes en tareas que requieren vigilancia.

6to Principio: Que exija poco esfuerzo físico

El diseño puede ser usado eficaz y confortablemente y con un mínimo de fatiga.

Pautas para el Principio 6

• Que permita que el usuario mantenga una posición corporal neutra.
• Que utilice de manera razonable las fuerzas necesarias para operar.
• Que minimice las acciones repetitivas.

Que minimice el esfuerzo físico continuado.

7mo Principio: Tamaño y espacio para el acceso y uso

Que proporcione un tamaño y espacio apropiados para el acceso, alcance, manipulación y uso, atendiendo al tamaño del cuerpo, la postura o la movilidad del usuario.

Pautas para el Principio 7

• Que proporcione una línea de visión clara hacia los elementos importantes tanto para un usuario sentado como de pie.
• Que el alcance de cualquier componente sea confortable para cualquier usuario sentado o de pie.
• Que se acomode a variaciones de tamaño de la mano o del agarre.
• Que proporcione el espacio necesario para el uso de ayudas técnicas o de asistencia personal.

El diseño tiene que basarse en la mezcla de las ideas, deseos y necesidades del usuario y en los materiales de que dispone el programador, y en este caso se trata de usuarios que pueden ser expertos o inexpertos en el tema; algunos de ellos sin preparación en las cuestiones de la informática.

Para ello, este sistema utiliza ciertos principios generales que garantizan la usabilidad en los diseños para estas aplicaciones:

• La interfaz no debe sobrecargar al usuario con complejidades innecesarias o distraerlo de su labor.
• Se debe dar al usuario un ambiente flexible para que pueda aprender rápidamente a usar la aplicación donde se ofrezcan posibilidades de elección en los métodos de uso, que facilite al usuario la exactitud y precisión, y se adapte al paso o ritmo del usuario.
• La interfaz debe ser consistente.
• Se debe considerar la productividad del usuario antes que la productividad de la máquina. Si el usuario debe esperar la respuesta del sistema por un período prolongado, estas pérdidas de tiempo se pueden convertir en pérdidas económicas para la organización. Los mensajes de ayuda deben ser sencillos y proveer respuestas a los problemas. Los menús y etiquetas de botones deberían tener las palabras claves del proceso.
• La interfaz debe tener acciones reversibles.

En el desarrollo de la interfaz de esta aplicación se tuvieron en cuenta los principios anteriores de la siguiente manera:

• Se usaron colores e imágenes que resultaran agradables, logrando una mayor y adecuada comunicación entre la aplicación y el usuario.
• Se mantuvieron las alineaciones de textos así como la alineación de los botones navegables y se tienen en cuenta otros elementos como su iluminación.

Se utilizaron elementos característicos para la descripción de acciones, tanto imágenes como textos.

Se evidencia en la aplicación el cumplimiento de las exigencias fisiológicas con respecto al ser humano a la hora de recibir información digital, para que no se viera afectada su salud por un uso inadecuado, por ejemplo: tamaño de letra, espaciamiento entre caracteres, tipografía, contraste figura – fondo de la información mayoritaria, estandarización de márgenes y distribución de información a lo largo de todo el software.

Tratamiento de Excepciones

Es de vital importancia para lograr el correcto funcionamiento de cualquier sistema identificar y controlar los posibles errores que se pueden presentar a la hora de interactuar con el software. Para el correcto funcionamiento de la aplicación se tratarán estos errores de forma tal que las interacciones con la base de datos (inserción, eliminación, modificación…) se realicen de forma correcta, para lograr esto se establecieron mecanismos de validación que comprueban la corrección de los datos a tratar; además en los formularios se insiste en que el usuario introduzca la menor cantidad posible de datos, aprovechando al máximo los campos calculables dentro del formulario, controles de selección; como: botones de opción (RadioButton), casillas de verificación (CheckBox), y listas de selección (ListBox), entre otros. De esta forma el usuario selecciona entre opciones predefinidas lo que no da margen al error.

En el caso de la entrada de datos por parte del usuario se utilizan las facilidades que brinda C# y ASP.NET para la validaciones de los datos; de existir errores, se muestren mensajes que ilustren la incorrecta inserción, modificación o mala manipulación de datos en general con las posibilidades que brinda el lenguaje utilizado mostrando al usuario una información correcta y explicativa sobre el posible error cometido. Todos los mensajes de error se muestran en mensajes resaltados usando las facilidades de la tecnología AJAX para la implementación de las funciones encargadas del control y validación de datos en el cliente, y se implementará una segunda validación de los datos enviados por el usuario y recibidos de la base de datos para lograr minimizar a cero los posibles errores y lograr que el usuario interactúe con un sistema de calidad.

Estándar de codificación

“Cualquier tonto puede escribir código que entienden las computadoras. Los buenos programadores escriben código que entienden las personas.” Martin Fowler

El estándar de codificación centra en las guías de estilo para programación en lenguaje C# aunque puede ser utilizado en muchos otros lenguajes y entornos para establecer las convenciones a utilizar.

1. Organización de los ficheros
   • Archivos fuente

Cada clase debe estar en un solo archivo, y un archivo no puede contener más de una clase. Si bien, en un archivo, junto con su clase se pueden definir los elementos relacionados, p.e. las excepciones que puede lanzar.

• Árbol de directorios y espacio de nombres

El espacio de nombres de los objetos se verá reflejado en el árbol de directorios del código fuente. Así, la clase Y10K.AyeAye.Switch, tendrá su código en Y10K/AyeAye/Switch.cs. Si una clase abstracta contiene código útil y además de ella heredan otras clases, como las de especialización, se tendrá el fichero con extensión cs correspondiente a la clase abstracta y, en el mismo nivel, el directorio con el nombre de la clase abstracta que contendrá las clases herederas.

2. Indentación
   • Longitud de línea

No se mantendrá, siempre que sea posible, la longitud de la línea más allá de los 80 caracteres.

• Dividir líneas: siempre que sea necesario dividir una línea en dos, se utilizarán las siguientes convenciones:

Si hay una lista de elementos separados por comas, se dividirá tras una coma.

Si se trata de una expresión, se dividirá tras uno de los operadores. Preferentemente, una expresión se dividirá en niveles superiores, antes que en inferiores.

La línea dividida se alineará con el nivel dentro del que se ha producido la división.

• Espaciados de indentación

Dada la disparidad que hay sobre la cantidad de espacios de indentación, se utilizarán tabuladores, los cuales pueden usarse con muchos editores para representarse con distintas cantidades de espacios y, sobretodo, se convierten en una pulsación por indentación.

3. Declaraciones
   • Número de declaraciones por línea

Por definición, nunca se utilizará una misma línea para más de una definición, la cual cosa facilita los comentarios relativos al elemento declarado.

• Inicialización

Siempre que sea posible las variables se inicializarán en la misma línea de declaración

• Declaración de clases e interfaces: Para definir las clases e interfaces, se seguirán las siguientes reglas:

No se usará ningún espacio entre el nombre de un método y el paréntesis de abertura de la lista de parámetros.

La llave de abertura que contiene el código se escribe sola en la línea siguiente a la definición del prototipo. Igualmente, la llave de cierre correspondiente se escribe sola en la última línea.

4. Sentencias
   • Sentencias simples

Cada línea contendrá no más de una sentencia, aunque, según lo explicado en el apartado 3, una sentencia puede estar en más de una línea

• Sentencias de retorno

La sentencia return no utiliza paréntesis.

• Sentencia de selección básica(if/if…else/if…else if…else)

Las llaves de inicio de un bloque de código se ponen al final de la sentencia if, else o else if. Las llaves de cierre van en líneas independientes. Cuando una sentencia else o else if vaya tras un bloque de código, la sentencia se colocará en la misma línea que la llave de cierre.

• Sentencias de bucle for o foreach

De forma similar a las sentencias de selección, la llave de abertura de bloque se colocará tras la sentencia de definición del for o foreach, y la de cierre en una línea independiente.

• Sentencias de bucle while o do while

De modo idéntico al for, pero en el caso del do while, el while se colocará en la misma línea que la última llave.

• Sentencias de selección múltiple (switch)

Respecto a lo que concierne a las llaves, se colocarán como en el resto de casos. Respecto al código y la línea  break, éstas irán con una indentación más que la línea  case  correspondiente, que irá con una indentación más que la línea de switch.

• Sentencias de captura y tratamiento de excepciones (try/catch/finally) El tratamiento de las llaves de bloque será como en el resto de sentencias.

5. Espacios en blanco
   • Líneas en blanco: Se pueden utilizar líneas en blanco para separar grupos de líneas que tengan cierta relación lógica. Dos líneas en blanco seguidas se usan para:

Separar secciones de código en un fichero.

Separar definiciones de clases e interfaces dentro de un fichero.

• Una línea en blanco separa…

Métodos.

Definiciones de variables locales dentro del método. Bloques de código que no guarden relación directa.

• Separaciones entre términos

En una lista de parámetros, se pondrán espacios tras las comas, pero nunca tras o antes de los paréntesis. En las asignaciones, se pondrán espacios antes y después del =. En las expresiones, se utilizarán espacios sólo cuando sean estrictamente necesarios y para separar las distintas expresiones.

• Separaciones en las declaraciones

Se procurará mantener una estructura tabulada para las líneas de declaraciones de variables, de manera que leer la información sea fácil. En el ejemplo siguiente se puede observar cómo mantener dicha estructura, pero hay que tener en cuenta que para el espaciado, hay que utilizar espacios, no tabuladores:

string name = “Mr. Ed”; int myValue = 5;

Test aTest = Test.TestYou;

6. Nomenclatura: Es importante tener presente que no se utilizará la notación húngara para absolutamente nada, exceptuando la codificación   de   GUI,   donde   se   puede   utilizar,   pero   detallando   los   tipos   en   sufijos   detallados (cancelButton, por ejemplo).
   • Nomenclatura para las clases

El nombre de una clase debe componerse de sustantivos. Se utilizará capitalización Pascal. No se utilizará ningún prefijo de clase.

• Nomenclatura para interfaces

Se nombrarán con sustantivos o adjetivos que describan el comportamiento. Capitalización Pascal. Se prefijan con una I, en mayúsculas, y la palabra que sigue también va en mayúsculas.

• Nomenclatura para enumeraciones

Se utilizará Pascal tanto para los nombres de los valores como para los nombres de tipo. No se utilizarán ni prefijos ni sufijos. Se utilizarán sustantivos en singular.

• Nomenclatura para constantes y para atributos de sólo lectura Se utilizará Pascal con sustantivos o abreviaciones de sustantivos.
• Nomenclatura para parámetros y atributos normales

Se utilizarán nombres descriptivos, destacando el significado antes que la tipología del parámetro. En este caso se utiliza capitalización Camel.

• Nomenclatura para variables

Se utilizará Camel. Cuando se utilicen contadores triviales, se utilizarán nombres como i, j, k, m, n,…

• Nomenclatura para métodos

Los métodos se nombrarán con verbos, en Pascal.

• Nomenclatura para propiedades Se utilizarán sustantivos, en Pascal.
• Nomenclatura para eventos

Los eventos tendrán como sufijo EventHandler y se utilizarán dos parámetros, denominados sender y e. Se utilizará Pascal. Se utilizarán verbos en tiempos pasado y presente para dar una idea del significado del evento.

7. Prácticas de programación
   • Visibilidad

Preferentemente se codificarán los atributos de clase y de instancia como privadas, de modo que existirán métodos accesores.

• La magia está prohibida

No se utilizarán números que puedan ser reemplazados por constantes. Esto es únicamente para que, si se presentara el caso de que el número tuviera que se modificado, sólo hay que modificarlo en un lugar.

8. Comentarios

Se utilizará solamente el formato //, nunca se utilizará el /*…*/.

Cuando haya que comentar un bloque de líneas, se utilizarán tantos // al principio de línea como convenga, como si se tratase de un # en un shell script.

Concepción de la Ayuda

Teniendo en cuenta que todos los usuarios que trabajarán con la aplicación no son avanzados y pueden tener poca o ninguna experiencia con la aplicación se deriva la necesidad de mostrarle la ayuda, la cual les permitirá conocer el funcionamiento de cada una de las opciones del sistema, para esto se implementarán varios mecanismos que le permitan al usuario estar informado y orientado en todo momento, de ahí que existirá en cada interfaz una opción de ayuda con la descripción de cada campo y las opciones de esa interfaz, lo que le permitirá saber que hacer y que datos introducir en cualquier momento.

Valoración de Sostenibilidad

Impacto Administrativo

La elaboración del sistema web no requiere de recursos excesivos, con el empleo de un ordenador no tan avanzado, perteneciente a la quinta generación de microcomputadoras con los sistemas operativos más utilizados y el empleo de algún software de libre distribución se puede lograr una versión estable en unos pocos meses.

Para visualizar el sitio se necesitan condiciones no tan avanzadas: un ordenador Pentium III con navegador web (Internet Explorer, Mozilla Firefox, Opera), 64 MB de RAM y una conexión a la RED donde se encuentra publicado el “HostingService” que pudiera ser una LAN, Intranet o Internet. Si quiere implantar la aplicación en condiciones óptimas, se pueden emplear las tecnologías de punta, que  arrojarían los siguientes gastos (Hardware para red. Precios suministrados por la Corporación Copextel):

Cantidad Descripción		Precio (CUC)
1	Servidor DELL PE830 3GHZ/2MB/800/512MB/2X73GB/M/K	2,177.80
1	Monitor DELL E173FP Digital Flat Panel 17”	299.00
1	Gabinete Mural 2 cpo 12U pta cristal	239.89
1	AT-8024-10. 24 Port 10/100 Base TX, Layer 2, Manager	424.84
1	Zyxel ES-1024A Fast Ethernet Switch 24×10/100 Base Tx	129.04
34	Patch Cord 3m	81.94
14	DEXSON Canal 60×40 (2m)	68.04

La creación del sistema potencia nuevas formas de distribución de productos (o servicios) aumentando las oportunidades de negocio teniendo en cuenta el aumento de clientes potenciales de cualquier zona geográfica sin limitaciones. Igualmente se logra una apertura y expansión hacia nuevos mercados remotos y/o desconocidos y se maximiza el horario de servicio del negocio de „n´ horas al día a ofrecer el servicio 360 días al año, las 24 horas del día.

La implantación del sistema no exige una presencia física de personal por lo que reduce los gastos empleados en la manutención y paga de estos empleados. Igualmente potencia un aumento de la satisfacción de los clientes al contar con un medio cómodo, rápido y sencillo de contactar con el negocio: No necesitan esperar a que les atiendan al teléfono, a desplazarse hacia su comercio, a sugerirle, consultarle y comprarle con una limitación horaria…

Para la elaboración e implantación del sistema, se necesitan una serie de software y plataformas de trabajo algunos de los cuales son de libre distribución:

Software	Precio (USD)
Variante de Software Libre
Kubuntu 7.10 Gusty	Gratis
Monodevelop	Gratis
Apache Web Server	Gratis
PostgreeSQL Database Server 8.2.4.1	Gratis
Variante con Software Propietario
Windows XP	$128.00                – $307.53
Visual Web Developer 2005 (Express Edition)	Gratis
Internet Information Server	Incluido en el SO
SQL Server 2005 (Express Edition)	Gratis

Impacto Socio – Humanista

El sistema no perjudica la calidad de vida de la sociedad en ningún aspecto, al contrario, constituye un aporte a la informatización de la sociedad y fuente de información y mercado confiable y actualizado, mediante la cual personas registradas pueden hacer sus compras en línea.

Al sistema se puede acceder desde cualquier lugar con acceso a la Red donde se publica, por lo que su nivel de generalización es variable pues podría ser desde una pequeña red local hasta Internet

La implementación del sitio genera varias plazas de empleo: un Ingeniero Informático encargado de llevar a cabo la Administración de los servicios que brinda el sitio, que velará por su mantenimiento y correcto funcionamiento; un Administrador Comercial y un Administrador Jurídico que deben ser personas graduadas de especialidades afines a la función que realizan.

Para favorecer la aceptación de la aplicación se diseñó una estructura compuesta por una interfaz de usuario agradable, con animaciones suaves y que no prolongan demasiado el tiempo de carga, la información que se expone es posteada por la entidad que aloja la aplicación y los precios de ventas los establecidos para este tipo de comercio en el país.

Impacto Ambiental

Para el diseño del Sistema de Gestión de Ventas de Productos al por Mayor no se utilizó ningún recurso perjudicial para el Medio Ambiente y fue concebida una interfaz de usuario uniforme, sencillo y con contrastes agradables, los colores empleados son suaves y a la vez representan a la entidad que lo publica o al país. Se evitó el uso en exceso de colores cálidos, de manera que el diseño no es agotador y refresca la vista debido a que el color predominante es el blanco. Los colores empleados no son saturados, al contrario, predominan los colores claros evitando el cansancio o daño en la vista al usuario que visita el sitio. La información presentada es resumida y concisa, con una tipografía clara y a un tamaño promedio, y una buena navegabilidad, esto limita el tiempo de búsqueda de información y evita daños en la columna vertebral de los usuarios.

La interfaz está caracterizada por rasgos curvos y suaves lo que transmite una sensación de tranquilidad y paz, y debido a que se emplea AJAX  se utilizan animaciones sutiles, transiciones suaves, sin exceso de información y evita el estrés psicológico en los usuarios.

Impacto Tecnológico

Para la utilización de la aplicación no se requieren conocimientos avanzados en informática, al contrario, solo se requieren conocimientos básicos de cómo manipular una página web en el explorador; además tener nociones mínimas sobre la navegación en Internet para poder acceder a los distintos módulos de información, venta y configuración del sistema. Para la administración del sitio tampoco se requieren conocimientos avanzados, solo principios básicos, dominar los distintos módulos, y tener conocimientos medios sobre la tecnología cliente – servidor (administrar un servidor web y un sistema gestor de base de datos).

La organización que adopte el sitio puede ser completamente independiente al productor, lo que permite, según su impacto social, la implantación del sitio en otras localidades sin necesidad de la presencia del productor o creador de esta.

Entre los factores tecnológicos que constituyen un riesgo de vulnerabilidad se encuentran la ruptura o mal funcionamiento del servidor en que se encuentra hospedada la aplicación, la ruptura del equipamiento de las vías de comunicación digitales (cables de red, switches, hubs, étc.). Todo esto puede ser evitado mediante el cumplimiento de las medidas de seguridad informática y aplicando el mantenimiento periódico del hardware y software con que cuenta la organización.

La aplicación cuenta con la posibilidad de adaptarse a cambios futuros, debido a la arquitectura orientada a servicios n-tiers los cuales son cargados dinámicamente y pueden ser actualizados tanto dinámica como manualmente sin que la aplicación presente fallas o desperfectos en su funcionamiento.

Conclusiones

Como resultado de la investigación se destacan las siguientes conclusiones:

1. Se desarrolló una herramienta que realiza los procesos de comercio electrónico mayorista cumpliendo con las regulaciones establecidas para Cuba.
2. Se realizó una revisión de la bibliografía existente para conocer origen, y evolución del comercio electrónico y el grado de novedad de los resultados de este trabajo.
3. Se desarrolló el diseño, implementación y prueba del Sistema de Gestión de Ventas de Productos al por Mayor resultante.
4. La metodología utilizada para el diseño y desarrollo de la aplicación resultó eficiente y queda disponible para su utilización en sistemas similares.
5. Valorados los impactos social, económico, tecnológico y ambiental del proceso de desarrollo del Sistema de Gestión de Ventas de Productos al por Mayor, se puede afirmar que este producto es sostenible.

Recomendaciones

Se recomienda basado en el resultado de la investigación:

1. La implantación y uso del sistema en PYMEs del país para valorar su despliegue a mayor escala.
2. El uso del sistema como material de apoyo para impartir asignaturas como “Comercio Electrónico” y cursos optativos como “Arquitectura y Patrones”.
3. Desarrollar nuevas versiones incursionando en el uso de otras metodologías como RUP o XP para hacer una comparación de los resultados obtenido.
4. Realizar la migración total del sistema a plataformas que garanticen la independencia tecnológica del mismo.

Bibliografía

• ¿Por qué ASP.NET? Esquivel, Julio Batista. 2006. 4, Madrid : s.n., 2006, Vol. 1.
• Almeida. 2002. Bufet Almeida. Sitio Web de Bufet Almeida. [En línea] 12 de Octubre de 2002. [Citado el: 13 de Diciembre de 2007.] http://www.lssice.com/23/lssice.
• Alvarez, Miguel Angel. 2006. Desarrollo Web. [En línea] 2006. [Citado el: 13 de 03 de 2008.] http://www.desarrolloweb.com/php/.
• Aravena I, Diego, y otros. 2006. Comercio Electrónico. Facultad de Educación y Humanidades, Universidad de la Frontera. Temuco : s.n., 2006.
• Arsys. 2007. Arsys.es. Sitio web de Ayuda: recursos hosting, comercio electronico. [En línea] [Citado el: 13 de           Diciembre           de           2007.] http://www.arsys.es/ayuda/directorio/productos/hosting/comercio-electronico.htm.
• Asociados, Anguiano &. 2006. Problemas jurídicos del comercio electrónico. España : s.n., 2006.
• AUKEN,        J.        2007.       Transacciones        HTTP       usando        PHP.        [En       línea]       2007.
• http://www.malditainternet.com/node/63?PHPSESSID=d7825b7a5b5ca2adea79bd0505c09db
• Ávila, Eduardo René Rodríguez. 2008. Comercio Electrónico. Sección de Estudios de Posgrado e Investigación, UPIICSA. 2008.
• BANCARIOS, C. D. S. 2006. Otras operaciones bancarias: operativa de cobros y pagos. [En línea]              2006. http://www1.euskadi.net/guiaconsumo/curso_bancario/preguntas.apl?apartado=26.
• Bitpipe. 2004. Bitpipe.com. [En línea] 2004. http://www.bitpipe.com/tlist/Perl.html.
• BORETTO, M. M. 2005. Aspectos de la propiedad intelectual derivados del entorno digital, en el             derecho               internacional     privado.               [En         línea]    2005. http://www.eumed.net/libros/2005/mmb/index.htm.
• Brosa, Pedro. 2000. Estrategias de negocio e implicaciones legales y fiscales. 2000.
• CAMPITELLI,   ADRIÁN.              2003.    Comercio             electrónico.        [En         línea]    2003. http://www.monografias.com/trabajos12/monogrr/monogrr.shtml.
• CARAMÉS,       H.           V.           2006.    Bancos en           Internet.             [En         línea]    2006. http://www.ciao.es/Opiniones/PayPal__289916.
• COMMUNICATIONS, D.           G.           2007.    Pasarelas             de           pago.     [En         línea]              2007. http://www.dimensis.com/pasarela-de-pagos.html.
• Corporation, Microsoft. 2005. Información general del producto SQL Server 2005. Microsoft TechNet SQL Server TechCenter. [En línea] 2005.
• —. 2007. The Architecture Journal. 2007.
• Cuervo, José. 2008. La Firma Digital y Entidades de Certificación. [En línea] 2008.
• http://www.informatica-juridica.com/trabajos/firma_digital.asp.
• DILOCONFORES.           2006.    Transacciones   Seguras,               Formas                 de           pago.              [En         línea]    2006. http://diloconflores.com/store/comersus_index.asp.
• Esplicando Scrum en 10 minutos. Serrano, Jorge. 2007. 4, Bogotá : s.n., 2007, Vol. 1.
• Estenos, Raul Sanchez. 2005. 10 Razones para usar Java . Lima : s.n., 2005.
• FERNÁNDEZ,     F.     2007.    Programación     Web:    Lenguajes     utilizados.    [En    línea]     2007.
• http://www.xeoweb.com/programacion-web.php.
• Gomez, Raciel. 2001. Marketing en Internet. [aut. libro] Raul Porto Santos. Lima : s.n., 2001.
• GUARDIA, C. D. L. 2007. La evolución del comercio electrónico. [En línea] 2007.
• http://www.razonypalabra.org.mx/anteriores/n20/20_cguardia.html.
• Herrera, Johany. 2007. Técnicas y herramientas utilizadas en la ingeniería de requerimientos.
• [En      línea]     2007.    [Citado el:           22           de           02           de           2008.] http://www.monografias.com/trabajos6/resof/resof2.shtml..
• ITAA. 2004. Information Technology Association of America. [En línea] 2004. www.itaa.org.
• MARAÑÓN, G. Á. 2008. Transacciones Electrónicas Seguras (SET), Medios de pago. [En línea] 2008. http://www.iec.csic.es/criptonomicon/comercio/set.html.
• MENDEZ, J. 2006. Las tendencias en los lenguajes de programación. [En línea] 2006. http://www.monografias.com/trabajos/tendprog/tendprog.shtml.
• Microsoft. 2006. La Firma Electrónica y la fiabilidad de las transacciones online. [En línea] 2006. http://www.microsoft.com/spain/seguridad/xp/firma/default.asp.
• NEWKIRK, J. 2002. La programación extrema en la práctica. Madrid : s.n., 2002.
• Noticias jurídicas. Noticias jurídicas. [En línea] 2000. http://noticias.juridicas.com.
• Planeta Código. [En         línea]     2005. http://www.planetacodigo.com/wiki/glosario:extreme_programming.
• Pressman, Roger S. 2002. Ingeniería del Software. Un enfoque práctico. 2002.
• REBELDE, M. E. C. D. 2005. Obstáculo al comercio electrónico. [En línea] 2005. http://www.mesaredonda.cu/informacion.asp?idInformacion=254&idSeccion=4&Logo=71.
• Ribas, Xavier. 2005. ELECTRÓNICO, ASPECTOS LEGALES DEL COMERCIO. 2005.
• Rodriguez, Javier Prenafeta. 2005. Contratos de hosting. Una visión general acerca de las principales cuestiones que conviene tener en cuenta al negociar este tipo de contratos“ en la web de la Asociación para la Promoción de las Tecnologías de la Información y el Comercio Electrónico (APT. [En línea] 2005. http://noticias.juridicas.com/external/nj_aptice/2002085556141710242121.html.
• Russo, Renne. 2001. Tecnologías de la información y la comunicación. 4, 2001, Vol. 1.
• Saldivar, Raul Vicente. 2007. 5 razones para no utilizar Spring. Mexico DF : s.n., 2007. 2.
• Schwaber, Ken y Beedle, Mike. 2003. Agile Software Development with SCRUM. 2003.
• Seguridad Informática, por qué y para qué. 2002. Noviembre de 2002, RED.
• Serrano, Agustín. 2006. Marco legal y fiscal en el e-commerce. 2006.
• Simsom, Richard. 2007. Seguridad Informática. La comunidad de expertos en redes. [En línea] 2007.
• Sparxsystems. 2005. [En línea] 2005. www.sparxsystems.com.
• STEPHENS, M., ROSENBERG,D. 2003. Extreme programming refactored: the case against X.P. California : s.n., 2003.
• Takeuchi, Hirotaka. 1999. Scrum. 1999.
• Varea, Ismael García. 2006. JAVA ¿Un refugio para los expertos? [En línea] 14 de 4 de 2006. [Citado el: 24 de 12 de 2007.]

Anexos

Anexo 1: Vista de la Tienda Virtual

Anexo 2: Vista del Sitio de Administración

Anexo 3: Funcionalidades básicas de un sistema de comercio electrónico.

• Acceso restringido a usuarios con clave de acceso.
• Catálogo de productos público y privado.
• Impresión de catálogos.
• Situación y seguimiento de pedidos.
• Gestión y Situación de riesgos, devoluciones y cobros.
• Buscador de artículos.
• Tienda virtual.
• Stock de artículos por opciones (colores, tallas, hormas, etc.).
• Encriptación de datos y pedidos.
• Histórico de facturación.
• Envío de Pedidos.
• Impresión de facturas.
• Validación de pago a través de páginas segura SSL y banco En línea.
• Ficha de artículo configurable.
• Formulario de compra configurable.
• Importación de artículos desde otras bases de datos.
• Copia de seguridad.
• Plantillas de diseños incluidas.
• Mantenimiento Off-line.
• Cesta de productos seleccionados.
• Edición de páginas en formato visual WYSIWYG.

Glosario de Términos

1. Áreas de Ventas Mayoristas: Son aquellas enclavas en Unidades Minoristas, de Producción o Servicios que comercializan de forma mayorista los productos o servicios previamente aprobados en su política de surtidos mayorista.
2. Cliente Final Mayorista: Persona Natural, trabajador de una de las Empresas, Organismos u Organizaciones de la Administración Central del Estado con las cuales se ha suscrito Contrato de Compraventa de Módulos y se encuentra expresamente registrado en el Contrato.
3. Comercio Mayorista: Se denomina comercio mayorista o al por mayor, a la venta de mercancías de producción nacional o importadas, con destino a vendedores al por menor, consumidores industriales e institucionales y a vendedores al por mayor, entre otros. En este comercio también se puede realizar la venta al detalle.
4. Comprador: Persona Jurídica con la cual mediante Contrato se establece las obligaciones relacionadas con el Acto de Compraventa.
5. PYME(s): Pequeña(s) y mediana(s) empresas.
6. Unidades de Venta Mayorista al detalle (Comercialización de Módulos), son Unidades destinadas a la comercialización mayorista al detalle de productos previstos en la Política de Surtidos de la Unidad con esta modalidad de ventas destinadas a las Empresas, Organismos y Organizaciones de la Administración Central del Estado  y cuya entrega se realiza al detalle al cliente final. Esta modalidad de ventas se realizará sólo en Unidades Especializadas para este tipo de venta mayorista.
7. Unidades Mayoristas: Se denominan Unidades de Ventas Mayoristas a las instalaciones definidas en un Centro de Costo donde se realiza la comercialización mayorista de los productos o servicios aprobados en su Política de Surtidos.
8. Vendedor: Unidad o Área de Ventas Mayoristas de la empresa autorizada mediante el presente procedimiento a realizar la venta mayorista a las personas jurídicas previstas en el presente procedimiento

[1] Enterprise Resource Planning

[2] Simple Object Access Protocol. Es un protocolo estándar creado por Microsoft, IBM y otros, está actualmente bajo el auspicio de la W3C que define cómo dos objetos en diferentes procesos pueden comunicarse por medio de intercambio de datos XML.