4 DESARROLLObibing.us.es/proyectos/abreproy/10934/fichero/4... · 4 DESARROLLO En esta sección...

33
4 DESARROLLO En esta sección vamos a ver como se ha desarrollado la aplicación. Comenzaremos hablando de las características generales del diseño (organización, estructura…) para a continuación ir comentando cada una de las secciones del sistema e ir viendo las pantallas que conforman la aplicación y las funcionalidades añadidas del modelo como búsquedas inteligentes, validaciones de controles, paginaciones, etc. Para acabar la sección se mostrará el diseño de clases y un esquema de las tablas usadas de la base de datos. 4.1 DISEÑO DE UN SITIO WEB En esta apartado comentaremos algunas consideraciones previas que se deben tener en cuenta antes de comenzar el diseño de un sitio web. Necesitamos saber para qué queremos el sitio, quiénes serán nuestros futuros usuarios o qué requisitos de diseño queremos cumplir, pues estos datos influyen decisivamente en el diseño final del sistema. 4.1.1 OBJETIVO Una vez decididos a construir un sitio web la primera pregunta que debemos hacernos es para qué deseamos construir el sitio. Puede parecer una pregunta inútil, pero es de una gran importancia, ya que si delimitamos claramente el objetivo de nuestras páginas habremos avanzado mucho en el establecimiento del esquema general que debemos usar en nuestro sitio web. No es lo mismo el diseño ni los contenidos de una página que va a servir para transmitir unos conocimientos (un manual, resultados de una investigación…), los de una cuyo objetivo va a ser mostrar un catálogo de productos, los de un negocio de comercio electrónico, los de una página destinada a la banca electrónica, los de un portal lúdico o los de un portal educativo. En resumen, existen muchos tipos de sitios web y en todos estos casos, las herramientas necesarias, las bases de datos y los lenguajes de programación a usar, tanto en el cliente como en el servidor, serán también diferentes. 4.1.2 FUTUROS USUARIOS La siguiente pregunta a hacernos es para quién vamos a crear nuestro conjunto de páginas web, y esta pregunta a la vez se debe desglosar en dos: quién va a ser nuestro cliente (la persona o empresa para la que vamos a crear el sitio) y quiénes van a ser nuestros potenciales visitantes. La primera de ellas va a marcarnos el contenido de las páginas que debemos crear, ya que en ellas deberemos expresar el espíritu y la imagen de la empresa, organización o particular para el que las creamos, conjugando esta imagen con las directrices que hayamos sacado de la pregunta "para qué". Es decir, si el sitio web va a ser por ejemplo una tienda on-line, con todas las tecnologías y herramientas que necesitemos para ello, deberemos adaptar éstas y el diseño de las páginas a la imagen corporativa concreta de la empresa que va a vender sus productos. Esto incluye el

Transcript of 4 DESARROLLObibing.us.es/proyectos/abreproy/10934/fichero/4... · 4 DESARROLLO En esta sección...

Page 1: 4 DESARROLLObibing.us.es/proyectos/abreproy/10934/fichero/4... · 4 DESARROLLO En esta sección vamos a ver como se ha desarrollado la aplicación. Comenzaremos hablando de las características

4 DESARROLLO

En esta sección vamos a ver como se ha desarrollado la aplicación. Comenzaremos hablando de las características generales del diseño (organización, estructura…) para a continuación ir comentando cada una de las secciones del sistema e ir viendo las pantallas que conforman la aplicación y las funcionalidades añadidas del modelo como búsquedas inteligentes, validaciones de controles, paginaciones, etc. Para acabar la sección se mostrará el diseño de clases y un esquema de las tablas usadas de la base de datos.

4.1 DISEÑO DE UN SITIO WEB

En esta apartado comentaremos algunas consideraciones previas que se deben tener en cuenta antes de comenzar el diseño de un sitio web. Necesitamos saber para qué queremos el sitio, quiénes serán nuestros futuros usuarios o qué requisitos de diseño queremos cumplir, pues estos datos influyen decisivamente en el diseño final del sistema.

4.1.1 OBJETIVO

Una vez decididos a construir un sitio web la primera pregunta que debemos hacernos es para qué deseamos construir el sitio. Puede parecer una pregunta inútil, pero es de una gran importancia, ya que si delimitamos claramente el objetivo de nuestras páginas habremos avanzado mucho en el establecimiento del esquema general que debemos usar en nuestro sitio web.

No es lo mismo el diseño ni los contenidos de una página que va a servir para transmitir unos conocimientos (un manual, resultados de una investigación…), los de una cuyo objetivo va a ser mostrar un catálogo de productos, los de un negocio de comercio electrónico, los de una página destinada a la banca electrónica, los de un portal lúdico o los de un portal educativo. En resumen, existen muchos tipos de sitios web y en todos estos casos, las herramientas necesarias, las bases de datos y los lenguajes de programación a usar, tanto en el cliente como en el servidor, serán también diferentes.

4.1.2 FUTUROS USUARIOS

La siguiente pregunta a hacernos es para quién vamos a crear nuestro conjunto de páginas web, y esta pregunta a la vez se debe desglosar en dos: quién va a ser nuestro cliente (la persona o empresa para la que vamos a crear el sitio) y quiénes van a ser nuestros potenciales visitantes.

La primera de ellas va a marcarnos el contenido de las páginas que debemos crear, ya que en ellas deberemos expresar el espíritu y la imagen de la empresa, organización o particular para el que las creamos, conjugando esta imagen con las directrices que hayamos sacado de la pregunta "para qué". Es decir, si el sitio web va a ser por ejemplo una tienda on-line, con todas las tecnologías y herramientas que necesitemos para ello, deberemos adaptar éstas y el diseño de las páginas a la imagen corporativa concreta de la empresa que va a vender sus productos. Esto incluye el

Page 2: 4 DESARROLLObibing.us.es/proyectos/abreproy/10934/fichero/4... · 4 DESARROLLO En esta sección vamos a ver como se ha desarrollado la aplicación. Comenzaremos hablando de las características

diseño y la implementación del logotipo de la misma, el uso de los colores corporativos propios, etc.

En cuanto al segundo apartado, referente a quién van a estar dirigidas principalmente las páginas, va a depender del baremo estadístico potencial de visitantes posibles. Si el sitio a crear es de manuales informáticos para principiantes deberemos crear un diseño neutro y general, apto para todo tipo de público, con menús de navegación claros y unos textos fácilmente comprensibles. Si es de manuales avanzados, se supone que nuestros visitantes ya poseen unos conocimientos suficientes del tema a tratar y además una buena experiencia en navegación por Internet, por lo que podemos permitirnos más libertades a la hora de diseñar los menús y el contenido textual.

Si el sitio es una tienda virtual deberemos en este caso usar un esquema de navegación simple e intuitivo, mostrando siempre claramente la forma de consultar los artículos que ofrecemos y el método para realizar la compra y el pago, ya que la venta será nuestro principal objetivo. Deberemos procurar que el usuario final pueda acceder a cualquiera de los artículos en menos de tres clic de ratón, y que el formulario de introducción de datos personales y de su número de tarjeta de crédito (si así procede) sea lo más sencillo posible, a la vez que deberemos ofrecer una imagen de seguridad y confianza.

Por supuesto, el tipo de público al que irá destinada la aplicación web también va a ser determinante en el diseño estético de las páginas que la formen. Así, si el usuario tipo es una persona joven, los colores y las imágenes deben ser vivos, alegres, estando permitido el uso en este caso de gamas brillantes. En cambio, si el usuario tipo es una persona de edad madura los colores deben ser neutros, tal vez en tonos pastel o grises, con pocas variaciones en el colorido, o colores serios, como el azul oscuro. En fin, para cada tipo de usuario final hay que hacer un estudio de colores y gráficos adecuado.

4.1.3 REQUISITOS DE DISEÑO

Otro aspecto importante en el diseño web es el delicado equilibrio que hay que tener para cumplir los tres requisitos fundamentales: que sea funcional, bonito y navegable. Es prácticamente imposible encontrar un sitio web que cumpla con todos los requisitos de diseño.

Se puede definir un sitio web funcional como aquel que cumple los objetivos prácticos para los que fue construido, un sitio bonito como aquel cuya estética es particularmente agradable y un sitio navegable como aquel en el que el usuario debe emplear poco esfuerzo en llegar a la información que desea encontrar. Generalmente tendremos que elegir entre dos de los tres requisitos, dejando el tercero un poco más descuidado.

Así, podemos crear unas páginas muy bonitas, con animaciones en Flash y un diseño a base de capas, y que a la vez pueda ser navegado por el usuario en unos pocos clics de ratón, pero entonces será muy difícil que cumpla los requisitos funcionales exigidos. Por ejemplo si es una tienda virtual o cualquier otra aplicación que precise el uso de formularios de forma intensiva, con las animaciones y las capas le haremos la vida muy negra a los programadores que tengan que trabajar luego en nuestras páginas.

Page 3: 4 DESARROLLObibing.us.es/proyectos/abreproy/10934/fichero/4... · 4 DESARROLLO En esta sección vamos a ver como se ha desarrollado la aplicación. Comenzaremos hablando de las características

Podemos crear un sitio web totalmente funcional y operativo, en el que los procesos de intercambio con las bases de datos sean fácilmente implementables, y que además sea muy fácil de navegar, pero entonces seguramente estaremos muy limitados a la hora de expresar en sus páginas nuestras inquietudes estéticas y de diseño.

Como hemos dicho antes, normalmente deberemos impulsar dos de los tres elementos, y puestos a elegir cuáles, podemos seguir unas reglas básicas:

• En el caso de sitios web destinados a comercio o banca electrónica, o en aquellos que deban soportar complejos procesos de intercambio con bases de datos el orden a seguir será: funcional, navegable y estético. Esto es debido a que el objetivo principal de estos sitios será que las consultas preliminares que haga el usuario y las transacciones de datos posteriores se realicen de forma correcta, sin posibilidad de fallos de ningún tipo. Además, debemos tener en cuenta que a este tipo de páginas accede todo tipo de público, que no necesariamente tiene que tener grandes conocimientos informáticos ni de Internet, por lo que debemos facilitarle lo máximo posible su navegación por las diferentes páginas que forman el sitio. Como regla general, debe acceder a la información que busca con tres clics de ratón como máximo. Con estas limitaciones es a veces difícil crear un diseño vanguardista o innovador, ya que además deberemos emplear en estos casos colores corporativos de la empresa cliente. Deberemos pues, una vez cumplidos los objetivos de funcionalidad y navegabilidad, ajustar nuestro diseño lo más posible al estándar del tipo de aplicación desarrollada.

• Si el sitio web pertenece a una empresa que desea ofrecer un catálogo de sus productos, pero sin posibilidad de compra on-line, o a una organización (universidad, organismo oficial…) que desea ofrecer la posibilidad al navegante de poder consultar documentos de cualquier tipo, entonces la guía a seguir es la navegabilidad. En estos casos lo que busca el usuario es poder encontrar lo antes posible el producto o documento que busca, estando generalmente el aspecto de programación web limitado a una simple consulta a una o más bases de datos. Debemos diseñar el sitio web de tal forma que desde el principio el usuario sepa en cada momento dónde se encuentra, cómo volver al inicio y cómo filtrar los datos para acceder rápidamente a la información que busca, y si las páginas tienen como objetivo el que el visitante pueda imprimirlas para su consulta off-line, deberán poseer un diseño que contemple este aspecto, estructurando su contenido de forma documental. En estos casos, y siempre que se cumpla esta primera condición, disponemos de más libertad en el diseño, pudiendo ofrecer una imagen más innovadora, aunque siempre dentro de los estándares que nos impongan la lógica de este tipo de sitios y el propio cliente.

Sitios web destinados a dar a conocer una nueva empresa en general, un grupo musical o de teatro, una asociación de cualquier tipo… deberán ser ante todo creativos en su diseño y estética, con el objetivo de captar desde el principio la atención del visitante y mantenerlo enganchado a nuestras páginas y que explore todas ellas. Este será pues el objetivo principal a conseguir, seguido de la navegabilidad, para que sepa siempre en qué lugar del sitio se encuentra.

Page 4: 4 DESARROLLObibing.us.es/proyectos/abreproy/10934/fichero/4... · 4 DESARROLLO En esta sección vamos a ver como se ha desarrollado la aplicación. Comenzaremos hablando de las características

4.1.4 CARACTERÍSTICAS DE NUESTRO SITIO WEB

Las características de nuestro sitio web vienen definidas por su propia naturaleza, estamos ante una aplicación de gestión comercial vía web, esto implica las siguientes particularidades:

• Existe una base de datos con un gran flujo de datos y en todas las páginas se hacen una o varias peticiones de datos que pueden implicar búsquedas complejas en tablas y en algunos casos inserciones de datos en ellas.

• Debido al intercambio de información, las páginas estarán llenas de tablas para mostrar los datos solicitados y de formularios para solicitar nuevos datos o modificar los existentes.

• Los usuarios que accederán serán empleados de empresas o directivos de las mismas con dominio de la informática medio-alto, debido a que deben estar familiarizados con herramientas similares y con aplicaciones clientes en Windows.

En función de estas características se ha decido que los tres requisitos fundamentales del diseño web se cumplan en el siguiente orden: funcionalidad, navegabilidad y aspecto gráfico.

La funcionalidad es la clave de la aplicación. El usuario querrá recuperar información valiosa para su empresa de una forma fiable y desde cualquier terminal conectado a Internet. La veracidad de los datos prima ante cualquier otro criterio, y de hecho es el objetivo del programa, el manejo de datos a distancia. De nada sirve una página bonita que muestre los datos de otro cliente que no sea el que estamos solicitando nosotros. Por lo tanto debemos asegurarnos que toda la información que se muestra es correcta y que no se produzcan errores al introducir datos nuevos.

En cuanto a la navegabilidad, es importante que el usuario no se pierda en las páginas, para lo que se ha colocado a la izquierda de cada página un menú navegable, para tener siempre claro dónde se está o dónde poder ir. Además no se produce pérdida de información al cambiar de página. Cuando volvamos a la página la encontraremos con la información tal y como nosotros la dejamos.

Por último, al tema estético es al que menor valor se le ha dado aunque sin olvidarlo. Es importante proporcionar un entorno agradable a la vez que funcional al usuario, para hacer más llevadero el trabajo y otorgar menor sensación de pesadez.

4.2 DESCRIPCIÓN Y FUNCIONAMIENTO

En esta sección se describirán las diferentes páginas que componen la aplicación, se analizará su funcionamiento, y se explicarán las funcionalidades específicas que se han diseñado.

La aplicación se compone de 6 páginas en total:

• Página de autenticación: Es la primera página, de paso obligatorio, donde el usuario presenta sus credenciales para acceder a la aplicación.

• Página del menú: Esta página ha sido incluida en el Proyecto para entender que el alcance total de la aplicación de gestión empresarial es mucho mayor

Page 5: 4 DESARROLLObibing.us.es/proyectos/abreproy/10934/fichero/4... · 4 DESARROLLO En esta sección vamos a ver como se ha desarrollado la aplicación. Comenzaremos hablando de las características

que el implementado en este Proyecto. En este caso se ha implementado la aplicación “Punto de Venta” de la sección “Área de Venta y Comercial”.

• Página de inspección: Donde se realiza la búsqueda de los albaranes almacenados en la base de datos en base a diversos criterios.

• Página de zoom: En esta página podemos observar y editar los detalles del albarán seleccionado en la pantalla anterior.

• Página de nuevo: Es en esta página donde se nos permite crear un albarán nuevo.

• Página de vista previa: Aquí podemos previsualizar el informe, elaborado a partir de los datos del albarán, listo para imprimirse o exportarse a diversos formatos.

A continuación se presenta una descripción más detallada de cada una de ellas.

4.2.1 PANTALLA DE AUTENTICACIÓN

Es la primera página que el usuario encuentra al conectarse al servidor. El paso por ella es obligado para acceder a la aplicación, ya que es en ella cuando el usuario adquiere una cookie que le sirve como pasaporte para visitar las paginas de la aplicación, si la autenticación se realizase con éxito. Inmediatamente después de que el usuario se haya registrado, el sistema le redirecciona al menú principal.

Figura 4.2.1 Página de Autenticación

Destacar que el cursor se sitúa al cargar la página directamente en el campo de usuario, para que éste no tenga que usar el ratón o tabular varias veces hasta llegar a él. De este modo se agiliza el proceso.

Page 6: 4 DESARROLLObibing.us.es/proyectos/abreproy/10934/fichero/4... · 4 DESARROLLO En esta sección vamos a ver como se ha desarrollado la aplicación. Comenzaremos hablando de las características

4.2.2 PANTALLA DE MENU

Se trata de una página simple donde el usuario decide la aplicación que quiere usar. Actualmente se ha implementado únicamente el programa “Punto de Venta” del apartado “Área de Venta y Comercial”, siendo los diferentes programas de ese mismo apartado inmediatos de implementar a partir del modelo creado. Todos ellos (“Presupuestos a Clientes”, “Pedidos de Clientes”, “Punto de Venta” y “Facturación Eventual”) usan la misma estructura y basta usar las clases creadas en el modelo para reproducir el programa y posteriormente dotar de las diferentes peculiaridades a cada uno de ellos.

Las otras secciones de menú se refieren a aplicaciones mas concretas, no siguiendo las características del modelo implementado.

Este menú se ha incluido en el Proyecto para dar una idea del alcance de la aplicación de gestión empresarial, que se irá implementando poco a poco.

Pasamos a describir por encima cada una de ellas para tener una visión más global de la aplicación:

• Productos: Controla el catálogo de artículos que ofrece la empresa.

• Ficheros Maestros: Aquí se encuentran datos importantes de la empresa, tales como los relacionados con sus cuentas bancarias, los clientes, etc.

• Área de Venta y Comercial: Controla las salidas de mercancías de la empresa, los pedidos de los clientes, los presupuestos a clientes, etc.

• Área de Aprovisionamiento: Trata la información relativa a los proveedores de la empresa.

• Existencias: Lleva el control del stock en el almacén. Se efectúan recuentos periódicos con el fin de valorar las pérdidas, deterioro de mercancía, robos y la información se almacena con el objetivo de reabastecer existencias agotadas.

• Área Técnica: Controla la maquinaria de la empresa, así como la informática asociada a la misma.

• Área Financiera: Regulación de cuentas, ejercicios de renta anuales, y demás información relativa a bancos y financiaciones.

• Informes: Es la parte de la aplicación dedicada a elaborar documentos rápidamente imprimibles sobre toda la información almacenada en las secciones anteriores.

• Órdenes de Producción: Relaciona los pedidos de los clientes con el stock para así determinar cuánto producir de un determinado articulo.

• Configuración: Este último apartado trata de personalizar la aplicación para que al usuario le resulte más cómodo el trato con ella. Además se encarga de la configuración de la red local para que el sistema funcione correctamente en el entorno cerrado de la empresa. En el caso del cliente web, este apartado será mas breve, ya que la configuración a nivel de red local no será necesario.

Page 7: 4 DESARROLLObibing.us.es/proyectos/abreproy/10934/fichero/4... · 4 DESARROLLO En esta sección vamos a ver como se ha desarrollado la aplicación. Comenzaremos hablando de las características

Figura 4.2.2.a Pantalla del Menú Inicial

Como ya se ha dicho, este Proyecto se ha basado en la implementación del apartado “Punto de Venta”, así que pinchando en esa opción del menú pasamos a la aplicación.

Figura 4.2.2.b Pantalla de Menú “Área de Venta y Comercial”

4.2.3 PANTALLA INSPECCION

Es la primera página propia de la aplicación “Punto de Venta”. En ella podemos hacer una búsqueda filtrada de los albaranes que queramos consultar para su posterior edición o impresión. Para ello tenemos a nuestra disposición un total de 5 filtros opcionales de carácter sumativo. Los resultados vienen dados paginados con un tamaño configurable de 250 líneas, con el fin de no sobrecargar la red y limitar el tiempo de espera.

Page 8: 4 DESARROLLObibing.us.es/proyectos/abreproy/10934/fichero/4... · 4 DESARROLLO En esta sección vamos a ver como se ha desarrollado la aplicación. Comenzaremos hablando de las características

Figura 4.2.3.a Pantalla Inspección antes de inspeccionar

Figura 4.2.3.b Pantalla de Inspección tras realizar una búsqueda con resultados

Al introducir un criterio de búsqueda válido que devuelva resultados, éstos aparecen alineados en una DataGrid (en Visual Basic.NET los controles con forma de tabla que muestran datos por pantalla se llaman DataGrids) en el centro de la pantalla. En el ejemplo mostrado en la Figura 4.2.3.b se ha realizado una búsqueda por fecha. Para cada albarán se muestra su número de serie, el número dentro de la serie, la fecha, el código del cliente, el nombre del cliente y el importe total. Además en la parte de arriba es posible navegar por las páginas de resultados (si hay más de una) con los botones “Página Anterior” y “Página Siguiente”

Una vez tengamos los resultados deseados en pantalla podremos seleccionar el albarán que nos interese en cuestión pulsando en el link de su izquierda “Seleccionar”,

Page 9: 4 DESARROLLObibing.us.es/proyectos/abreproy/10934/fichero/4... · 4 DESARROLLO En esta sección vamos a ver como se ha desarrollado la aplicación. Comenzaremos hablando de las características

de este modo nos redirigiremos a la ventana Zoom para ver los detalles del albarán, y poder editarlo o imprimirlo.

Es posible que la búsqueda que solicitemos no devuelva ningún resultado, en ese caso un cartel en el centro de la pantalla nos lo indicaría.

Figura 4.2.3.c Pantalla de Inspección tras realizar una búsqueda sin resultados

4.2.3.1 Solución al problema de ASP.NET sobre la paginación de resultados

Cuando se trata de rellenar un DataGrid con datos provenientes de la base de datos, hemos de tener mucha precaución con la cantidad de datos que viajan por la red. La base de datos modelo con la que se ha trabajado para diseñar la aplicación tiene un total del 37134 albaranes almacenados. Esto quiere decir que si se hiciera una búsqueda sin ningún tipo de filtrado, y no se tuviera en cuenta ninguna paginación, por la red viajarían esos 37134 albaranes desde el servidor de la base de datos hasta el cliente. Lógicamente el tiempo de espera sería muy grande y esta opción se debía descartar. ASP.NET ofrece una paginación para su control DataGrid que tampoco soluciona este problema, pues lo que hace es descargar todos los resultados de la búsqueda (en este caso los 37134) y una vez están todos los resultados en el cliente nos presenta sólo los que le hayamos indicado en la propiedad de paginación del control DataGrid. Estamos pues ante una paginación desde el punto de vista de la visualización de resultados, pero no desde el punto de vista de descarga desde la red.

Para solventar el problema se hace uso de un procedimiento almacenado en la base de datos que nos devuelve los resultados en bloques de tamaño fijo, según le especifiquemos el tamaño que queremos y el número de página que solicitamos. De este modo es importante guardar siempre el número de página actual, para saber cual es la anterior y la próxima a solicitar por el usuario.

4.2.4 PANTALLA ZOOM

En esta pantalla se pueden controlar todos los detalles del albarán seleccionado en la pantalla anterior. El albarán siempre se carga bloqueado, es decir, de sólo lectura.

Page 10: 4 DESARROLLObibing.us.es/proyectos/abreproy/10934/fichero/4... · 4 DESARROLLO En esta sección vamos a ver como se ha desarrollado la aplicación. Comenzaremos hablando de las características

Para pasar a modo edición será necesario solicitarlo seleccionando la opción correspondiente, y el albarán se desbloqueará para nuestra edición siempre y cuando no halla otra persona, en otro lugar, editándolo al mismo tiempo, evitando así el consiguiente caos que se formaría. De este modo se consigue realizar la operación de edición de forma atómica.

A parte del menú navegable de la izquierda, siempre presente dentro de la aplicación, en esta pagina se pueden diferenciar 3 partes donde se presenta toda la información posible sobre el albarán: una cabecera con 3 paneles (un panel en ASP.NET es un contenedor de controles), un control de solapas en la parte central y un pie con otros 2 paneles y una barra de herramientas.

Figura 4.2.4 Pantalla Zoom

4.2.4.1 Cabecera

Se divide en tres paneles:

• En el primero de ellos se muestran los datos de número de serie y fecha con su calendario de consulta integrado. El campo de fecha está sujeto a validación de formato de fecha corto.

• En el panel central se encuentran los datos del cliente, código, nombre, domicilio, NIF y la búsqueda inteligente de clientes (con el fondo en amarillo). Estos datos del cliente son de sólo lectura, para modificarlos habrá que acudir a la solapa Cliente, que más tarde comentaremos. Al realizar la búsqueda del cliente y seleccionar un resultado, se rellena automáticamente la solapa “Cliente” del TabControl (es un control personalizado que se explicará en breve) con todos los detalles del mismo, listos para su consulta o edición. Destacar que se han optimizado los campos de este panel (y algunos otros) para que al ir tabulando y cambiando el cursor de campo a campo, se salte aquellos que son de sólo lectura, ya que no tiene sentido posicionar el cursor en ellos (excepto para

Page 11: 4 DESARROLLObibing.us.es/proyectos/abreproy/10934/fichero/4... · 4 DESARROLLO En esta sección vamos a ver como se ha desarrollado la aplicación. Comenzaremos hablando de las características

copiar el texto al portapapeles, pero sucede en raras ocasiones). De esta forma el usuario introduce datos en los albaranes de una forma más rápida.

• En el tercer y último panel se encuentran los datos de la referencia y el número de albaran. En la cabecera del albarán, los datos de número y serie son de sólo lectura, ya que no tiene sentido cambiarlos. Todos estos campos de datos se encuentran vinculados a tablas que se rellenan desde la base de datos al hacer la selección del albarán.

Figura 4.2.4.1 Paneles Superiores de la Pantalla Zoom

4.2.4.1.1 Búsqueda inteligente de clientes

La búsqueda inteligente de clientes consiste en que la aplicación detecta el tipo de dato introducido por el usuario en el campo de búsqueda y realiza la búsqueda según el dato que se ha introducido. Los datos que se pueden introducir son: el inicio del nombre del cliente, el código del cliente, o el NIF del cliente. Por ejemplo, escribir en el campo de búsqueda las cadenas “sani”, “4300.003378” o “B80519267” nos devolverá el mismo resultado: el cliente cuyo nombre es “SANITRADE S.L.”, cuyo código es “4300.003378” y cuyo NIF es “B80519267”. Es así porque la aplicación identificó la cadena “sani” como inicio de un nombre, la cadena “4300.003378” como un código de cliente (siempre con ese formato de número) y la cadena “B80519267” como un NIF.

4.2.4.2 TabControl

TabControl es un control personalizado que gestiona de una manera fácil y cómoda la navegación a través de las diferentes solapas que hayan sido insertadas al inicializar el control. Es un control altamente escalable, ya que basta escribir en una de sus propiedades los nombres de las clases que deben incluirse en las solapas para que se añadan automáticamente en tiempo de ejecución. En este caso al TabControl se le han añadido 6 solapas: Líneas, Económicos, Logística, Cliente, Articulo y Notas.

4.2.4.2.1 Líneas

Presenta las líneas de artículos del albarán. Es un DataGrid que se carga dinámicamente de la base de datos. Los datos que se detallan aquí son:

• Línea: El orden de la línea dentro del albarán.

• Código: El código del artículo.

• Descripción: La descripción del artículo.

• Cantidad: Se refiere al número de artículos.

• Precio: Precio de una unidad del articulo. Varía de un cliente a otro, teniendo asociado cada articulo hasta 4 precios posibles.

Page 12: 4 DESARROLLObibing.us.es/proyectos/abreproy/10934/fichero/4... · 4 DESARROLLO En esta sección vamos a ver como se ha desarrollado la aplicación. Comenzaremos hablando de las características

• %Dto: El descuento dado en ese momento al cliente, expresado en tanto por cierto.

• Importe: Es el importe total de la línea, se calcula a partir del precio, de la cantidad y del descuento.

• T. IVA: Tipo de IVA asociado al articulo. Existen hasta cuatro tipos de IVA.

Figura 4.2.4.2.1.a Control Líneas

La primera columna del DataGrid muestra un link con el nombre “Detalles”. Al pinchar en él, automáticamente pasamos a la solapa “Artículo” donde se muestran más detalles asociados al artículo de la línea en cuestión como se verá en el apartado 4.2.4.2.5 Artículo.

Al desbloquear el albarán, es decir al pasar a modo edición, aparece una última columna con un botón en rojo. Pulsándolo eliminamos la línea en cuestión.

Figura 4.2.4.2.1.b Control Líneas desbloqueado

Cabe reseñar que pueden existir albaranes sin líneas, en cuyo caso el control muestra un mensaje advirtiéndolo.

Figura 4.2.4.2.1.c Control Líneas sin líneas

4.2.4.2.2 Económicos

En esta solapa se muestran datos relacionados con el IVA y el importe total del albarán con (“Tot Albarán”) y sin IVA (“SubTotal”). Como ya se comentó antes, cada artículo está asociado a un tipo de IVA, y es en esta solapa donde se puede observar el % aplicado. En “Base IVA” se observa el importe al que se le aplicará el “%IVA”

Page 13: 4 DESARROLLObibing.us.es/proyectos/abreproy/10934/fichero/4... · 4 DESARROLLO En esta sección vamos a ver como se ha desarrollado la aplicación. Comenzaremos hablando de las características

colocado en la columna central. En la última columna se especifica si se aplica algún tipo de recargo adicional.

El botón “Recalcular Totales” debe usarse cuando una línea del albarán es eliminada, para tener este hecho en cuenta y presentar el nuevo importe del albarán.

Figura 4.2.4.2.2 Control Económicos

4.2.4.2.3 Logística

En esta sección nos encontramos con algunos datos variados del albarán, relacionados con el pago. Algunos de estos campos son opcionales como veremos a continuación. Las listas desplegables están vinculadas a la base de datos.

• Proyecto: Indica el nombre del proyecto al que pueda pertenecer un albarán.

• Agrupac: Indica si el albarán esta agrupado a otros o es individual. Puede o no estar especificado.

• A. Envío: Especifica el agente de envío. Opcional.

• Clv. Fact: Es la clave de la factura. Opcional.

• Campaña: Indica a qué campaña pertenece el albarán. Su valor puede estar en blanco.

• Anular Pt: Especifica una anulación de la petición de venta.

• Cv Venta: Una clave interna de venta.

• Estadist: Para solicitar o no estadísticos.

• F Pago: Forma de pago.

• Periodic: Indica si el albarán se repetirá periódicamente. Muestra el ciclo en meses.

• Agente: Agente de venta.

• SubAgente: Subagente de venta. De carácter opcional.

Page 14: 4 DESARROLLObibing.us.es/proyectos/abreproy/10934/fichero/4... · 4 DESARROLLO En esta sección vamos a ver como se ha desarrollado la aplicación. Comenzaremos hablando de las características

Figura 4.2.4.2.3 Control Logística

4.2.4.2.4 Cliente

Esta solapa añade información a la ya suministrada en la cabecera de la pantalla y además sus campos son todos editables (salvo el código ya que no tiene sentido cambiar el código de un cliente a no ser que sea en la aplicación “Clientes”) a diferencia de la cabecera. Los controles de listas desplegables se rellenan según la base de datos. Vamos a ver los campos del control, muchos de ellos de carácter opcional.

• Código: Es el código del cliente. Sólo lectura.

• NIF: NIF del cliente.

• T. IVA: Descripción del tipo de IVA facturado a ese cliente.

• N. Social: Nombre social del cliente.

• Tipo: Tipo de IVA.

• N. Comer: Nombre comercial del cliente.

• Zona: Región del cliente.

• Domicilio: Domicilio del cliente.

• Tarifa: Código de la tarifa aplicada a ese cliente.

• Localidad: Localidad del cliente.

• C Postal: Código postal del cliente.

• Provincia: Provincia del cliente.

• Teléfono: Teléfonos del cliente. También puede especificar el nombre de la recepcionista del cliente o el código interno de la persona de contacto. Sólo lectura.

• Fax: Fax del cliente. Sólo lectura.

• Email: Email del cliente. Sólo lectura.

• Web: Dirección web del cliente. Sólo lectura.

Page 15: 4 DESARROLLObibing.us.es/proyectos/abreproy/10934/fichero/4... · 4 DESARROLLO En esta sección vamos a ver como se ha desarrollado la aplicación. Comenzaremos hablando de las características

Figura 4.2.4.2.4 Control Cliente

4.2.4.2.5 Artículo

Es el control donde se detallan los detalles asociados a un artículo. Inicialmente se carga en blanco. Se rellena al pulsar sobre el link “Detalles” de una línea particular del albarán en cuestión. Los campos que en él encontramos son:

• Código: Código del artículo, es un campo de sólo lectura.

• Udad. Medida: Unidad de media del articulo (kilos, gramos, litros, natural, etc.)

• Descripción: Breve descripción del artículo.

• Envase: Especifica un envase en particular del producto.

• Descrip.Comp: Añade mas información al campo descripción anterior.

• Situación: Indica en qué estado se encuentra el artículo.

• C. Logico: Es el código lógico del artículo. Es un código alfanumérico.

• Tipo: Tipo de IVA asociado al artículo.

• Código EAN: Código de carácter financiero asociado al artículo.

• IVA: Descripción del tipo de IVA aplicado al artículo.

• Familia: Familia al cual pertenece el artículo.

• Marca: Marca del artículo.

• Grupo: Indica a qué grupo pertenece el artículo.

• UEN: Unidad Estratégica de Negocio

• Precio1: Uno de los precios del artículo. Cada artículo tiene varios precios debido a que este depende del cliente al que se factura.

• Precio2: Uno de los precios del artículo.

Page 16: 4 DESARROLLObibing.us.es/proyectos/abreproy/10934/fichero/4... · 4 DESARROLLO En esta sección vamos a ver como se ha desarrollado la aplicación. Comenzaremos hablando de las características

• Precio3: Uno de los precios del artículo.

• Precio4: Uno de los precios del artículo.

Figura 4.2.4.2.5 Control Artículo

4.2.4.2.6 Notas

La última solapa del TabControl, usada para que el usuario deje constancia de cualquier dato que no se recoja en las solapas anteriores. El control consta de un TextArea amplio y un botón para borrar todo el contenido.

El control sólo inserta y presenta texto plano (no enriquecido), pero sin embargo es capaz de detectar cuando un albarán contiene texto en formato enriquecido y hacer una conversión previa para que se pueda visualizar correctamente. Una vez el albarán sea editado y en el momento de volver a grabarse en la base de datos se comprueba el campo “notas” para ver si este ha sido modificado. Si no ha sido modificado, el campo no se sobrescribe y de este modo no se ha perdido el formato de texto enriquecido aun habiéndose efectuado la conversión a texto plano para presentarlo en pantalla. La existencia de albaranes con el campo “notas” en texto enriquecido se debe a que en el cliente Windows en posible la inserción de este tipo de texto. De este modo vemos una limitación de la aplicación web.

Figura 4.2.4.2.6 Control Notas

Page 17: 4 DESARROLLObibing.us.es/proyectos/abreproy/10934/fichero/4... · 4 DESARROLLO En esta sección vamos a ver como se ha desarrollado la aplicación. Comenzaremos hablando de las características

4.2.4.3 Pie

En el pie de la página se encuentran los campos referentes a la introducción de líneas en el albarán.

Figura 4.2.4.3.a Paneles Inferiores de la Pantalla Zoom

En el primer panel encontramos la búsqueda de artículos (campos en amarillo) y el campo de la descripción del artículo. En el segundo, los campos de unidades, precio y descuento. Los campos descripción y precio se rellenan automáticamente al seleccionar un artículo tras haber realizado una búsqueda con resultados. Además el precio se rellenara de manera diferente dependiendo del cliente que se haya seleccionado con anterioridad en la cabecera de la página, ya que no se les da el mismo precio a todos los clientes.

Los campos numéricos “Uds.”, “Precio” y “Dto%” están sujetos a validación, y el campo “Parcial” se calcula de forma automática en el cliente usando funciones de JavaScript, al rellenar los 3 campos anteriores o bien al clicar sobre el icono de la calculadora situado a su lado. Su cálculo es sencillo, y consiste en multiplicar el número de unidades por el precio y restarle el descuento. Todos estos campos numéricos están formateados (también usando JavaScript) para presentar los números con 2 cifras decimales (excepto el campo unidades que siempre es entero y puede ser negativo si se indica una devolución de artículos).

La propiedad de tabulación de los campos del panel se ha optimizando para que al tabular el cursor de un campo a otro, salte directamente después de introducir el “Dto” al botón “Entrar”, y de ese modo el usuario gane tiempo al introducir líneas. (Eso es posible ya que no hace falta hacer clic sobre la calculadora para calcular el parcial, éste se calculará solo siempre que los tres campos de “Uds.”, “Precio” y “Dto” estén rellenos con datos coherentes. De hecho el botón de la calculadora sólo está presente pensando en el hecho de que el usuario use el ratón en vez del teclado para saltar de un campo a otro, en cuyo caso necesita un paso anterior al botón “Entrar” para visualizar el “Parcial”).

El botón “Entrar” nos permite introducir una línea en el albarán (siempre que éste no esté bloqueado, claro) una vez hayamos seleccionado el valor de todos los campos del pie de la página (el campo “Descripción” es el único opcional en este caso).

4.2.4.4 Barra de herramientas

Para terminar de describir la página, resta explicar el funcionamiento de la barra de herremientas que está situada debajo del primer panel comentado anteriormente.

Page 18: 4 DESARROLLObibing.us.es/proyectos/abreproy/10934/fichero/4... · 4 DESARROLLO En esta sección vamos a ver como se ha desarrollado la aplicación. Comenzaremos hablando de las características

Figura 4.2.4.3.b Barra de herramientas

4.2.4.4.1 Desbloquear

Es el botón que nos permite editar el contenido del albarán. Como ya se ha dicho, inicialmente se carga bloqueado (solo lectura), si quisiéramos pasar a modo edición debemos solicitarlo por medio de este botón, y se nos permitirá el acceso en escritura o no dependiendo de si otra persona ya está editándolo en ese mismo momento en otro lugar. En caso negativo, aparecería un mensaje en pantalla advirtiendo que no ha sido posible su desbloqueo.

4.2.4.4.2 Grabar

Permite insertar las modificaciones hechas al albarán en la base de datos. Es necesario desbloquear al albarán antes de grabarlo, ya que si no es así significaría que el albarán no ha sufrido cambios y no tendría sentido grabarlo. Al grabar correctamente el albarán pasa a un estado bloqueado, para indicar que la operación se efectuó correctamente. En caso contrario se presenta en pantalla un mensaje advirtiendo que no se pudo grabar correctamente.

4.2.4.4.3 Cancelar

Este botón permite deshacer los cambios que hemos hecho sobre el albarán original, devolviéndonos a la versión guardada de la base de datos. Sólo tiene sentido pulsarlo cuando el albarán está en modo edición.

4.2.4.4.4 Vista Previa

Haciendo clic en este botón siempre y cuando el albarán esté bloqueado, saltamos a la ventana de “Vista Previa”, la cual se comentará a continuación.

4.2.5 PANTALLA VISTA PREVIA

Es la pantalla de vista preliminar al elaborar un informe. Se cargan todos los datos del albarán seleccionado y se formatean en un documento Crystal Report quedando listo para imprimir.

Page 19: 4 DESARROLLObibing.us.es/proyectos/abreproy/10934/fichero/4... · 4 DESARROLLO En esta sección vamos a ver como se ha desarrollado la aplicación. Comenzaremos hablando de las características

Figura 4.2.5.a Pantalla Vista Previa

En la parte superior de la pantalla se observan las opciones de impresión o exportación que se facilitan, y en la segunda línea aparece una barra de herramientas para ofrecernos algunas ayudas, tales como variar el zoom sobre el informe, hacer una búsqueda de texto o navegar por las páginas en el caso de que hubiese más de una (sólo en casos de albaranes que incluyan un gran numero de líneas).

Figura 4.2.5.b Barra de herramientas de la Vista Previa

Bajo la barra de herramientas se muestran los detalles del informe. Como título aparece el texto “NOTA DE PEDIDO/CARTA DE PORTE” para indicar el tipo de documento al que nos enfrentamos, en este caso es un informe de Punto de Venta. En la cabecera aparecen los datos básicos del albarán:

• Número y serie del albarán.

• Fecha.

• Código del cliente.

• Código del agente.

• Código de la zona.

• Código de la forma de pago.

Inmediatamente a la derecha de la cabecera principal, hay otra cabecera con datos del cliente tales como:

• Nombre social del cliente.

• Domicilio.

• Código postal.

Page 20: 4 DESARROLLObibing.us.es/proyectos/abreproy/10934/fichero/4... · 4 DESARROLLO En esta sección vamos a ver como se ha desarrollado la aplicación. Comenzaremos hablando de las características

• Localidad.

• Provincia.

• NIF.

Bajo estas dos cabeceras se listan las líneas relativas al albarán, conteniendo las columnas:

• Código de artículo.

• Descripción de artículo.

• Numero de unidades solicitadas.

• Precio por unidad.

• Importe de la línea.

• Tipo de IVA aplicado.

Abajo del todo se muestra el subtotal (total sin IVA) y el total del albarán.

Una vez que el informe se elabora automáticamente con todos los datos del albarán, resta elegir la forma en la que lo queramos imprimir, ya que es posible exportar el informe a tres formatos conocidos: PDF, Microsoft Word o Microsoft Excel.

4.2.5.1 Vista de impresión

No requiere exportar el archivo a ningún formato. Al hacer clic sobre esta opción se abre una nueva ventana donde no están presentes ni el menú de navegación ni la barra de herramientas, por lo que podemos imprimir la página directamente usando la opción imprimir del navegador. Es la opción más rápida, pero la menos configurable.

Page 21: 4 DESARROLLObibing.us.es/proyectos/abreproy/10934/fichero/4... · 4 DESARROLLO En esta sección vamos a ver como se ha desarrollado la aplicación. Comenzaremos hablando de las características

Figura 4.2.5.1 Vista de impresión del informe

4.2.5.2 Exportar a PDF

Pulsando sobre esta opción el informe es exporta a formato PDF y se abre una ventana del Acrobat Reader si está instalado en el equipo. En caso contrario la aplicación pregunta al usuario si lo desea descargar en formato PDF.

Figura 4.2.5.2 Exportación a PDF

4.2.5.3 Exportar a Word

Con esta opción conseguimos un resultado similar al anterior, pero esta vez en formato Word. Una vez más, si el usuario no tiene instalado el Microsoft Word, la aplicación le pregunta si desea descargar el fichero en formato .doc.

Page 22: 4 DESARROLLObibing.us.es/proyectos/abreproy/10934/fichero/4... · 4 DESARROLLO En esta sección vamos a ver como se ha desarrollado la aplicación. Comenzaremos hablando de las características

Figura 4.2.5.3 Exportación a Word

4.2.5.4 Exportar a Excel

Idéntico al apartado anterior esta vez con el formato de Microsoft Excel.

Figura 4.2.5.4 Exportación a Excel

4.2.6 PANTALLA NUEVO

La pantalla Nuevo tiene un gran paralelismo con la pantalla ya comentada Zoom. La diferencia radica en que en esta nueva ventana no se carga ningún albarán ya existente como sucedía en Zoom, sino que ahora se crea desde cero. Al cargar la página se cargan todos los campos con valores por defecto de la base de datos o vacíos. Además el cursor se sitúa directamente en el campo de búsqueda inteligente de clientes

Page 23: 4 DESARROLLObibing.us.es/proyectos/abreproy/10934/fichero/4... · 4 DESARROLLO En esta sección vamos a ver como se ha desarrollado la aplicación. Comenzaremos hablando de las características

para comenzar rápidamente, ya que ese debe ser el primer campo a rellenar (siempre y cuando la fecha y la serie estén conformes con los valores por defecto, que suele ser así). Lógicamente en este caso, al ser un albarán en blanco, se presenta en modo edición, y no bloqueado tal y como sucedía en Zoom.

Figura 4.2.6.a Pantalla Nuevo

De este modo, todo lo descrito para la pantalla Zoom es aplicable a este caso, con algunas excepciones de funcionamiento básico:

• En esta ocasión los campos “Serie” y “Numero” del albarán son editables. La serie se elige de una lista desplegable que se rellena de la base de datos al cargar la página. El número se recomienda dejarlo a cero, ya que de este modo, al grabar, se grabará automáticamente con el número inmediatamente superior al albarán con el último número ya guardado.

• La barra de herramientas es ligeramente diferente.

Figura 4.2.6.b Barra de herramientas de la Pantalla Nuevo

Vemos como ahora no existe ni el botón “Desbloquear” ni “Cancelar”, ya que ambos carecen de sentido es este caso. Sin embargo hay un nuevo botón, “Limpiar”, que realiza la función de dejar en blanco el albarán, con el objetivo de deshacer el trabajo hecho hasta ahora, o bien empezar uno nuevo una vez guardado el anterior. Ahora, al igual que antes, al grabar el albarán se bloquea y queda listo para ir a la ventana de Vista Previa.

4.2.7 VALIDACIONES

Para controlar que ciertos datos sean correctos, antes de su envío por la red hacia el servidor, se hace uso de la validación proporcionada por ASP.NET. Se trata de una validación en el cliente, por lo que no se desperdicia tiempo de espera ni se cursa tráfico

Page 24: 4 DESARROLLObibing.us.es/proyectos/abreproy/10934/fichero/4... · 4 DESARROLLO En esta sección vamos a ver como se ha desarrollado la aplicación. Comenzaremos hablando de las características

inútil. Los campos sujetos a validación son los de fecha, y los datos económicos de las líneas en las páginas Nuevo y Zoom.

• Fecha: No debe faltar, y su formato tiene que ser el de fecha corta (dd/mm/aaaa). Es el formato con el que rellena el campo el calendario integrado al seleccionar una fecha.

• Uds: El campo de unidades de artículos no debe faltar y ha de ser un número entero (puede ser negativo si indica la devolución de un artículo).

• Precio: Tiene que estar presente por fuerza, y debe ser un número. Se acepta el separador de decimales tanto si es un “.” (punto) como si es una “,” (coma).

• Dto: El campo descuento es de obligada cumplimentación y debe ser un numero entre 0 y 100. Al igual que en el caso anterior se aceptan tanto el punto como la coma para separar la parte decimal.

Si alguno de estos campos no presenta el formato de datos esperado, una ventana de notificación y un asterisco rojo junto al campo de los datos incorrectos se encargará de hacer saber al usuario que dato debe repasar en el formulario.

Figura 4.2.7 Validaciones

4.2.8 CALENDARIO INTEGRADO

El calendario integrado es un control personalizado que trata de ser de ayuda al usuario a la hora de elegir una fecha. Cuando se hace clic en la lupa situada junto al campo de fecha, aparece sobreimpresionado un calendario donde inicialmente está seleccionada la fecha actual. No obstante disponemos de un control de navegación que nos permite movernos por los diferentes meses hacia adelante y hacia atrás según nuestra conveniencia. Una vez tengamos la fecha localizada, basta pinchar sobre el día que hayamos elegido para que el calendario desaparezca y el campo de texto asociado a él quede relleno con el dato de la fecha seleccionada formateada correctamente. También es posible cerrar el calendario volviendo a pinchar sobre la lupa con la que lo

Page 25: 4 DESARROLLObibing.us.es/proyectos/abreproy/10934/fichero/4... · 4 DESARROLLO En esta sección vamos a ver como se ha desarrollado la aplicación. Comenzaremos hablando de las características

abrimos. El calendario integrado está presente en las ventanas de Inspeccion, Nuevo y Zoom, y para incluirlo en otras bastaría hacer una referencia a la clase que lo implementa desde el formulario web.

Figura 4.2.8 Calendario integrado

4.2.9 MENÚ NAVEGABLE

Se trata de un elemento común a las cuatro páginas principales de la aplicación. Está situado ocupando la franja izquierda de la pantalla y con él podemos ir de una ventana a otra según nos interese en cualquier momento y sin perder la información que hayamos dejado escrita en la página. La no pérdida de la información se consigue usando tablas internas de almacenamiento de datos que vendrán descritas con más detalle cuando se estudien las características del modelo.

Además de proporcionar la navegación por las diferentes páginas, el menú navegable nos indica permanentemente en qué pantalla estamos, por si el usuario se despistase.

Page 26: 4 DESARROLLObibing.us.es/proyectos/abreproy/10934/fichero/4... · 4 DESARROLLO En esta sección vamos a ver como se ha desarrollado la aplicación. Comenzaremos hablando de las características

Figura 4.2.9 Menú navegable

4.2.10 SALVAGUARDA DE LOS DATOS

Una misión importante a la hora de facilitar la navegación por las diferentes páginas de la aplicación ha sido facilitar la recuperación de los datos introducidos por el usuario al recargar una página que ya había sido cargada previamente y en la que el usuario había introducido ciertos datos en los campos del formulario. De este modo el usuario puede navegar a su libre albedrío por la aplicación, sin tener la obligación de terminar una tarea para saltar a otra página. Por ejemplo un usuario que esté editando un albarán en la ventana Zoom, podrá volver a ver los resultados de la búsqueda que hizo en la ventana Inspección, o empezar a crear uno en la ventana Nuevo, pudiendo volver posteriormente a Zoom y encontrarse la página tal y como la dejó.

El salvar los datos requiere una especial atención en el caso de que los controles que aparecen en la página se creen dinámicamente en tiempo de ejecución (como en el caso del TabControl), ya que para estos sus propiedades no serán guardadas en el “View State” de la página. En esos casos al realizar sucesivos “PostBacks” de la página deberemos de ser nosotros los encargados de guardar los contenidos de los controles en variables de sesión, ya que el ASP.NET Framework no se encarga de los controles dinámicos. No obstante también deberemos utilizar variables de sesión para salvar los datos de los controles, tanto dinámicos como estáticos, cada vez que la página se abandone. Para este propósito, la aplicación detecta cuando el usuario cambia de página y guarda el objeto “BoData” en una variable de sesión, así como algunos otros valores de campos de texto, que aparecerán escritos cuando el usuario vuelva a la página en la que inicialmente comenzó.

4.3 DIAGRAMAS DE CLASES Y TABLAS

En este apartado veremos la organización de clases con las que se construyen las diferentes páginas de la aplicación, así como las tablas de la base de datos y sus relaciones. También se hará una breve descripción de los métodos de cada clase.

Page 27: 4 DESARROLLObibing.us.es/proyectos/abreproy/10934/fichero/4... · 4 DESARROLLO En esta sección vamos a ver como se ha desarrollado la aplicación. Comenzaremos hablando de las características

4.3.1 LA PÁGINA INSPECCION

En la Figura 4.3.1 se observan las clases que incluye la página de inspección. Se trata de un diagrama sencillo, ya que el cometido de la página es hacer la búsqueda de albaranes en la base de datos. De hecho en el esquema sólo se observan dos clases definidas por el usuario, la del formulario web (Inspeccion) y la del calendario personalizado (CustomCalendar), perteneciente al modelo de la aplicación. Vemos como dentro de una misma clase de Inspeccion se pueden implementar múltiples clases CustomCalendar, de hecho en la aplicación la ventana Inspeccion tiene dos calendarios, uno para cada campo de fecha.

Figura 4.3.1 Diagrama de bloques de la clase inspeccion

Tanto CustomCalendar como Inspección heredan de otras, Inspeccion lo hace de System.Web.UI.Page y CustomCalendar de System.Web.UI.WebControls.WebControl. Esto se debe a que Inspeccion está implementando un formulario web, y todo formulario web en ASP.NET debe ser heredado de la clase Page. Además CustomCalendar es un control personalizado, y la tecnología ASP.NET también nos dice que este tipo de clase debe heredarse de otra, en este caso de System.Web.UI.WebControls.WebControl. Notar como además CustomCalendar implementa la interfaz INamingContainer. Esto debe ser así obligatoriamente para evitar un conflicto de nombres en el espacio de nombres de los controles de la página. Al implementar la interfaz, el control queda registrado con su nombre en el espacio de nombres, y de este modo la clase System.Web.UI.Page que la incluya identificará al control por su nombre.

A continuación se describen brevemente los métodos de cada una de las clases.

4.3.1.1 Métodos de la clase Inspección

• Page_Load: Es el método que maneja el evento MyBase.Load, por lo que se ejecuta automáticamente al cargar la página.

Page 28: 4 DESARROLLObibing.us.es/proyectos/abreproy/10934/fichero/4... · 4 DESARROLLO En esta sección vamos a ver como se ha desarrollado la aplicación. Comenzaremos hablando de las características

• Initialize: Se encarga de restaurar los valores que el usuario dejó escritos la última vez que se visualizó la página (dentro de una misma sesión).

• MenuNavigation: Controla la navegación del menú navegable.

• SaveData: Guarda los datos presentados en la pantalla, al abandonar la página.

• CalendarPopUp: Saca el calendario, para la elección de una fecha como criterio de búsqueda.

• Search_Cab: Es el método encargado de lanzar los comandos SQL que se ejecutaran en función del criterio de búsqueda facilitado por el usuario. Además, se encarga de la correcta paginación de los resultados, para no saturar la red, ya que la paginación ofrecida por ASP.NET es deficiente en ese aspecto. Como numero máximo de líneas al realizar la paginación se usa el valor del atributo PageSize de esta misma clase. Un valor adecuado para este atributo puede ser 250, siempre dependiendo de la velocidad de la red y el tráfico. En condiciones óptimas será posible usar 400 líneas con un tiempo de espera aceptable.

• Select_Cab: Redirecciona a la ventana de zoom con los datos del albarán seleccionado por el usuario.

4.3.1.2 Métodos de la clase CustomCalendar

• PopUp: Abre el control para que pueda ser usado.

• Select_Date: Cuando el usuario selecciona una fecha, el control se cierra y rellena el contenido de un campo de texto asociado con el valor de la fecha seleccionada.

4.3.2 LA PÁGINA ZOOM

En este apartado se puede apreciar la potencia del modelo con el que se ha implementado la aplicación. De forma general podríamos dividir el diagrama en tres partes. La primera parte sería la clase Zoom, que instancia a todas las demás clases y contiene métodos que gobiernan el funcionamiento de la página. La segunda parte sería la clase BoData y sus derivadas, que se encargan de almacenar toda la información extraída de la base de datos y gestionar el acceso a la misma por medio de llamadas a los procedimientos almacenados. La tercera parte de este gran esquema serían las clases heredadas de System.Web.UI.UserControl y que son implementadas por el TabControl. Son las clases que se encargan de mostrar la información del BoData por pantalla y permiten su edición.

Page 29: 4 DESARROLLObibing.us.es/proyectos/abreproy/10934/fichero/4... · 4 DESARROLLO En esta sección vamos a ver como se ha desarrollado la aplicación. Comenzaremos hablando de las características

Figura 4.3.2 Diagrama de clases de la página Zoom

En la Figura 4.3.2, como en la anterior se observa que la clase de formulario web hereda de System.Web.UI.Page, como es norma en ASP.NET, y los controles personalizados lo hacen de System.Web.UI.WebControls.WebControl. No obstante, ahora aparece una clase nueva, System.Web.UI.UserControl, de la que heredan los controles de usuario. Son estos controles los que conforman las solapas del TabControl al añadirse dinámicamente en tiempo de ejecución, lo que confiere al programa una gran potencia de modelado. Basta añadir un parámetro con el nombre de la clase a incluir en la solapa, y el nombre de la solapa, en la propiedad UserControls del TabControl para incluir un nuevo control de usuario que presente más datos por pantalla o realice cualquier otra funcionalidad propia de la aplicación.

Page 30: 4 DESARROLLObibing.us.es/proyectos/abreproy/10934/fichero/4... · 4 DESARROLLO En esta sección vamos a ver como se ha desarrollado la aplicación. Comenzaremos hablando de las características

Como ya hemos comentado, el trato con los datos lo lleva a cabo la clase “BoData” (Bo son las siglas de Bussiness Object, ya que estos objetos pertenecen a la capa de negocios de la aplicación). Esta clase es instanciada por la clase “Zoom” y recibe los parámetros “BoCab”, “BoCli” y “BoArt”, que son clases previamente instanciadas en “Zoom”. Por lo tanto “BoData” es un contenedor de estas tres clases, así como de la variable booleana “_Block” que es la encargada de almacenar el estado de bloqueo del albarán.

“BoCab” es una clase que contiene los datos relativos a la cabecera del albarán y las líneas incluidas en él, así como los métodos para gestionar estos datos. Por lo tanto en su interior se incluye un DataSet (“dscab”) con dos DataTables: “cab” (datos propios de la cabecera) y “lin” (datos de las líneas del albarán).

“BoCli” contiene el DataSet “dscli” con los datos del cliente que se han extraído de la base de datos y algunas funciones para su gestión. “BoArt” es su equivalente, para los datos asociados a articulo. En el diagrama se observa como tanto “BoCli” como “BoArt” contienen muchos menos métodos que “BoCab”. Esto es debido a que la aplicación no permite modificar las tablas de cliente y articulo, tan solo se limita a recoger los datos contenidos en ella y los asocia al albarán correspondiente, por lo tanto los métodos se reducen a los de búsqueda y selección.

Vamos a describir brevemente a continuación los métodos de las clases más importantes.

4.3.2.1 Métodos de la clase Zoom

• Page_Load: Es el método que maneja el evento MyBase.Load, por lo que se ejecuta automáticamente al cargar la página.

• Initialize: Se encarga de restaurar los valores que el usuario dejó escritos la última vez que se visualizó la página (dentro de una misma sesión) e implementa e inicializa la clase TabControl.

• MenuNavigation: Controla la navegación del menú navegable.

• SaveData: Guarda los datos de la página al abandonarla.

• CalendarPopUp: Saca el calendario personalizado, para facilitar la elección de la fecha al usuario.

• Select_Cab: Extrae de la base de datos los datos de cabecera y de líneas del albaran, que se especifica en los parámetros de entrada “serie” y “numero”.

• Insert_Line: Inserta una línea al albarán siempre y cuando éste esté en modo edición.

• Page_Unload: Es el método que maneja el evento MyBase.Unload, por lo que se ejecuta automáticamente cuando la página esté a punto de descargarse hacia el cliente.

• Toolbar_Option: Gestiona el manejo de la barra de herramientas.

• UpDate_DataBase: Realiza la función de actualizar los datos del albarán, modificando la base de datos.

Page 31: 4 DESARROLLObibing.us.es/proyectos/abreproy/10934/fichero/4... · 4 DESARROLLO En esta sección vamos a ver como se ha desarrollado la aplicación. Comenzaremos hablando de las características

• Cancel_UpDate: Es el método que se encarga de eliminar los cambios introducidos por el usuario y volver a la versión guardada del albarán.

• Search_Cli: Se encarga de realizar la búsqueda inteligente de clientes en la tabla cliente.

• Search_Art: Realiza la búsqueda de artículos en la taba artículos.

• Bind_Cli: Rellena los campos de datos del formulario web del cliente, con los datos del DataTable “dscli”, que ha sido previamente cargado al hacer la búsqueda de clientes.

• Bind_Art: Funciona igual que el anterior, pero esta vez con los datos de artículo en vez de los del cliente.

• Bind_Cab: Es el método que se encarga de rellenar los campos de datos de cabecera del albarán, una vez se ha seleccionado uno de la ventana Inspección.

4.3.2.2 Métodos de la clase BoCab

• LinNew: Introduce una línea en blanco en el DataTable, para que sea rellenada a continuación.

• Select: Rellena las columnas del DataTable con los datos del albarán, identificado con los parámetros de entrada “serie” y “numero”, desde la base de datos.

• Insert: Introduce los datos de un albarán nuevo en la base de datos.

• UpDate: Actualiza la base de datos con las modificaciones que el usuario haya hecho sobre un albarán previamente cargado.

• Block: Obtiene el permiso para desbloquear el albarán y pasar a modo edición.

• LinDefaults: Deja la línea del DataTable con los valores por defecto o en blanco.

• LinLoadWorkArea: Se encarga de validar en el servidor los datos de la línea que quiere ser introducida en la base de datos, antes de ejecutar la acción.

• Rlin_CalculoParcial: Este método se encarga de calcular el parcial de la línea, operando con las columnas de precio, descuento y unidades.

• Rlin_RetrieveArt: Cuando se introduce el código del cliente en una línea que quiere ser añadida al albarán y se ejecuta este método, todos los demás campos de la cabecera del albarán relacionados con artículos (por ejemplo la descripción del articulo, sus precios, etc.) se rellenan automáticamente desde la tabla “articulo”.

• Cab_RetrieveCli: Funciona igual que el anterior, pero con los datos del cliente. En este caso, cuando el código del cliente se introduce en la cabecera del albarán, y se llama a este método, todos los datos relacionados con cliente se rellenará automáticamente de la tabla “cliente” (campos tales como el nombre del cliente, el NIF, etc.)

Page 32: 4 DESARROLLObibing.us.es/proyectos/abreproy/10934/fichero/4... · 4 DESARROLLO En esta sección vamos a ver como se ha desarrollado la aplicación. Comenzaremos hablando de las características

Por último señalar que el diagrama de clases de la página de Nuevo es idéntico a este último, ya que ambas páginas presentan un comportamiento casi idéntico, aunque su cometido sea distinto. Además la página de Vista Previa tampoco merece especial atención en este aspecto, ya que no se encarga del manejo de datos ni posee características tan escalables como las ya comentadas para la clase Zoom (aplicables también a Nuevo).

4.3.3 TABLAS DE LA BASE DE DATOS

En esta sección se explicará la organización de las diferentes tablas que se han utilizado de la base de datos. En la Figura 4.3.3 puede apreciarse la organización y los campos de los que se componen cada una de ellas.

4.3.3.1 Tabla Cab

Contiene los campos correspondientes a los datos de cabecera del albarán. Tiene una clave primaria compuesta por los campos “sercab” y “numcab”, que se corresponden con los valores de serie y número del albarán. Además, como claves externas contiene “clicab”, que es el código del cliente, “agecab” que es el código del agente y el mismo campo “sercab”, que hace las veces de clave externa para la tabla “cot”, siempre y cuando se especifique un valor para el campo “idecot” de la tabla “cot”. Sus campos son todos obligatorios excepto “notcab”, que es el correspondiente al campo “notas” del albarán.

4.3.3.2 Tabla Cli

En esta tabla encontramos los datos de los clientes. Su clave primaria es “codcli”. Esta tabla sólo se usa en modo lectura en la aplicación, ya que la gestión de clientes corresponde a otra parte de la aplicación. Todos los campos en esta tabla son obligatorios.

4.3.3.3 Tabla Lin

Es la tabla donde se almacenan todos los datos relativos a una línea del albarán. Por lo tanto su clave primaria está compuesta por los campos “serlin”, “numlin” y “ordlin”, que se corresponden con la serie del albarán, su número, y la posición de la línea en el albarán (recordemos que un albarán puede contener de cero a más líneas). Además la tabla posee dos claves externas: “artlin” , que es el código del artículo asociado a la línea, es la clave de la tabla “art” y “serlin” y “numlin” son clave compuesta de la tabla “cab”. Los campos de “lin” son de carácter obligatorio.

4.3.3.4 Tabla Art

Contiene los datos de los artículos. Su clave primaria es “claart”. En esta ocasión, todos los campos deben ser no nulos, excepto “notart”.

4.3.3.5 Tabla Age

Es la tabla para almacenar los datos de los agentes. La aplicación no maneja la tabla directamente, sino una vista (“vage”) que no es más que una versión reducida de la misma (con algún campo extra añadido), ya que normalmente no son interesantes todos

Page 33: 4 DESARROLLObibing.us.es/proyectos/abreproy/10934/fichero/4... · 4 DESARROLLO En esta sección vamos a ver como se ha desarrollado la aplicación. Comenzaremos hablando de las características

los datos de la tabla. La clave primaria de la tabla es “codage” y todos los campos deben estar rellenos, excepto “nomage”, que no es obligatorio.

4.3.3.6 Tabla Cot

Es la tabla para los contadores. De esta tabla es de donde se rellenan las listas desplegables de las páginas, que dan opción al usuario a elegir entre unas opciones determinadas para rellenar un campo concreto. Su clave primaria es “idecot” junto con “sercot”. No obstante, al igual que sucede con la tabla “age”, en la aplicación se ha hecho uso de una vista, “vcot”, que es una versión reducida de la misma tabla con algunas columnas añadidas de otras tablas, que en el caso de esta aplicación no nos concierne. En la tabla “cot” también tenemos un solo campo opcional, que es “empcot”.

Figura 4.3.3 Tablas y vistas usadas de la Base de Datos