Ampliación de un sistema CRM (Gestión de Relación con Clientes) Proyecto Final de Carrera

Transcripción

1 Ampliación de un sistema CRM (Gestión de Relación con Clientes) Proyecto Final de Carrera Ingeniería Técnica en Informática de Gestión Autor: Jaime Molina Perdomo Tutor: Pere Millán Tutor en la empresa: David Rodríguez Moreno Fecha: Junio 2011

2 2

3 1. Índice 1. Índice La empresa Descripción Ubicación Servicios que ofrece Investigación y Desarrollo Ubicación del proyectante dentro de la empresa Descripción de la tarea realizada Objetivos del proyecto Especificaciones del proyecto Diseño Arquitectura del SugarCRM Decisiones de diseño Etapa 1: Control y exportación de gastos Etapa 2: Modificación de módulos Etapa 3: Creación de recibos bancarios Etapa 4: Creación de gráficos Desarrollo Requisitos e instalación Desarrollo por etapas Etapa 1: Control y exportación de gastos Etapa 2: Modificación de módulos Etapa 3: Creación de recibos bancarios Etapa 4: Creación de gráficos Evaluación Recursos utilizados Documentos consultados Páginas web consultadas Aportaciones del proyecto a los conocimientos del alumno Aportaciones de los estudios realizados al proyecto Conclusiones Anexo 1: Sentencias SQL Anexo 2: Imágenes de las modificaciones realizadas

4 2. La empresa 2.1 Descripción TechnoDAC es una empresa especializada y consolidada en el desarrollo de aplicaciones para Internet con un amplio abanico de productos propios y servicios integrales. Sus casos de éxito en proyectos de vanguardia y la confianza que han depositado en su equipo tanto empresas del sector público como privado, hacen de TechnoDAC una empresa destacada en un entorno en continua evolución como es el de las nuevas tecnologías. 2.2 Ubicación Actualmente están situados en la calle Higini Anglés nº 10, escalera izquierda 1º 4ª de Tarragona. 2.3 Servicios que ofrece TechnoDAC ofrece un servicio integral de alojamiento web con el que el cliente dispondrá de la máxima velocidad y seguridad, ilimitadas cuentas de correo, tráfico y un servicio integral para que el cliente pueda hacer su trabajo sin preocuparse por el estado de su espacio WEB. Además de esto, dispone también de los siguientes servicios: Imagen corporativa Administración de redes Mantenimientos informáticos Posicionamiento natural (SEO) Sincronización entre programas de gestión y WEB Pagos por Internet Multimedia Software a medida Márketing WEB Portavoz Virtual 4

5 2.4 Investigación y Desarrollo Además de lo anteriormente mencionado, actualmente están trabajando en un proyecto de I+D llamado WaI? Yah! (Where am I? You are here!), con el que pretenden desarrollar un sistema de información multi-idioma y posicionamiento GPS para peatones mediante códigos de barras bidimensionales. Estos códigos se colocan a la entrada de establecimientos comerciales, hoteles, restaurantes, museos u otros puntos de interés turístico. Cada código contiene información relativa al lugar en que se encuentra situado dicho código: nombre, descripción, teléfono, web, horario Para leer los códigos solamente se necesita un teléfono móvil con cámara y el programa lector. El programa lector se configura según una lista de idiomas, en orden de preferencia del usuario. Cuando el programa lee uno de estos códigos (que contiene información en varios idiomas), muestra al usuario la información en el idioma deseado. Cada código permite conectarse al servidor WaI? Yah! para obtener información adicional o en otros idiomas. Los códigos también contienen las coordenadas de latitud, longitud (y opcionalmente altitud), de forma que un teléfono móvil con cámara se puede convertir en un GPS a coste cero, simplemente leyendo las coordenadas contenidas en el código. Los códigos se pueden utilizar en lugares cerrados, donde la señal de un GPS no llega o está distorsionada, y permiten mayor resolución que otras técnicas como triangulación de celdas GSM o Wi-Fi. El sistema WaI? Yah! se adapta a las necesidades de los clientes que eligen utilizarlo. WaI? Yah! permite disponer de un nuevo canal (teléfonos móviles) para promocionar los productos y servicios turísticos (entre otros muchos campos de aplicación). La combinación de los códigos bidimensionales con las conexiones a Internet desde el móvil, permiten superar las limitaciones de capacidad de los códigos y hacer un seguimiento de la utilización y el impacto que tiene el sistema, así como detectar nuevas necesidades de los usuarios. La adaptación de la web de los clientes al formato móvil también es un servicio disponible. El sistema está diseñado para funcionar en cualquier idioma, permitiendo su uso a nivel mundial. 5

6 3. Ubicación del proyectante dentro de la empresa El objetivo del proyecto era muy claro, ya que desde un principio se marcaron unas pautas a seguir y se detalló bastante bien lo que necesitaba la empresa. Por este motivo la gran mayoría del tiempo el proyecto lo he realizado fuera de la oficina de la empresa, aunque siempre en contacto con David, mi tutor dentro de la empresa, ya fuese mediante o chat (Google Talk). Además de eso, cada cierto tiempo concertábamos reuniones para llevar un seguimiento de las tareas desarrolladas y verificar el funcionamiento de lo realizado hasta entonces. Todo esto ha sido posible dado que mi situación dentro de la empresa no era como la de un trabajador más, sino como un trabajador externo que les modificaba una aplicación interna. 6

7 4. Descripción de la tarea realizada 4.1 Objetivos del proyecto El objetivo es ampliar e implementar nuevas funcionalidades en el sistema de gestión de relaciones con los clientes (SugarCRM) que actualmente utiliza la empresa TechnoDAC. Para ello he realizado un estudio, diseño, implementación y modificación de los módulos de Business Intelligence, contabilidad interna y exportación de datos. El módulo de contabilidad interna servirá para llevar un control de los gastos de la empresa, de tal forma que cada vez que les emitan una factura la introducirán de forma sencilla en la base de datos. Con dichos datos, además, a final de cada trimestre podrán generar un fichero Excel, que enviarán a su contable para poder cuadrar el IVA trimestral. Hasta la fecha, para realizar dicho Excel debían ir guardando todas las facturas que les emitían, para que luego al final de cada trimestre fueran volcadas a mano en un Excel. El módulo de Business Intelligence consiste en plasmar una serie de gráficos con datos referentes a la empresa, como por ejemplo el volumen de ventas y gastos, o la distribución de los diferentes tipos de gastos que han tenido. Gracias a esta nueva herramienta, la empresa podrá hacer algo que hasta ahora no tenía forma de hacer, ya que desde la implantación de esta nueva funcionalidad podrá realizar un análisis de la situación actual de la empresa y ver una evolución de los datos a lo largo del tiempo. Y gracias a dicha información reflejada en gráficos, y por lo tanto mucho más sencilla de analizar, podrán realizar un previsión con la que poder tomar decisiones para el futuro de la empresa. Por último están las modificaciones en los módulos para poder extraer datos. Dichas modificaciones consisten, en primer lugar, en lo mencionado anteriormente, para poder generar un Excel que enviar a su contable con el listado de gastos e ingresos trimestrales. Y por otro lado, en la creación de un fichero con el que podrán generar los recibos bancarios de forma automática y únicamente deberán cargarlo en la web del banco para efectuar los cobros. Hasta ahora, para realizar los cobros mediante recibo bancario debían introducir uno a uno los recibos en la página del banco, y con este nuevo sistema únicamente deberán escoger qué recibos desean cobrar para ser introducidos en este fichero. 7

8 4.2 Especificaciones del proyecto Con el fin de llevar a cabo los objetivos del proyecto, se ha divido el proyecto en cuatro etapas. La primera consiste en generar una serie de módulos que permitan llevar un control de los gastos que tiene la empresa y a su vez permita generar una serie de informes en Excel que serán enviados al contable de la empresa, para poder gestionar los diferentes IVA trimestrales. La segunda etapa consiste en realizar una serie de correcciones al SugarCRM actual, dado que había varias herramientas que no funcionaban de forma correcta. En tercer lugar se tiene que implementar un sistema que permita exportar los vencimientos deseados por el usuario a un fichero N19, que permitirá generar los recibos bancarios de forma mucho más sencilla, ya que únicamente tendrán que cargar el fichero generado en la página del banco. Además de ello, debe permitir llevar un registro de todos los recibos generados, con el fin de poder modificarlos si fuera necesario. Y por último, modificar el módulo del gestor llamado Cuadro de Mando, que está pensado para llevar un control de datos, pero que hasta ahora no funcionaba de forma correcta y no mostraba los datos que el usuario solicitaba. Para ello se han de generar una serie de Dashlets nuevos, con las diferentes informaciones solicitadas por el cliente. 8

9 4.3 Diseño Arquitectura del SugarCRM Antes de empezar a diseñar, hay que comprender cómo funciona el gestor SugarCRM. Dicho gestor está diseñado bajo el patrón de arquitectura MVC (Modelo- Vista-Controlador) que se basa en diferenciar tres partes elementales dentro de una aplicación: Modelo: ésta es la representación específica de la información con la cual el sistema opera. Vista: ésta es la encargada de presentar el modelo en un formato adecuado para el usuario. Controlador: ésta es la responsable de toda la lógica de la aplicación. Se encarga de responder a los eventos solicitados por el usuario y, en función de la acción solicitada, invoca una serie de modelos que luego son representados en las vistas. Vista Modelo Controlador 6 1 Usuario Las líneas discontinuas representan acciones indirectas 9

10 Una vez comprendido el funcionamiento del modelo MVC, hay que ver como lo aplica nuestro gestor. Antes de nada hay que aclarar que el gestor SugarCRM trabaja de forma modular, es decir, está formado por diferentes módulos que le dan diferentes funcionalidades a la aplicación. Por lo tanto, el usuario siempre accede a la aplicación y después decide a que módulo acceder. Para comprender mejor el funcionamiento, a continuación se muestra un gráfico explicativo. Usuario EntryPoint SugarApplication Module SugarController Action Module SugarView Module SugarBean MetaData 10

11 El usuario siempre accede a la aplicación mediante un EntryPoint. Dichos EntryPoint permiten que se inicialice la aplicación, para que acto seguido se cargue el módulo deseado y se ponga en funcionamiento la arquitectura MVC. Un ejemplo de cómo accedería el usuario a la aplicación sería el siguiente: De esta forma arrancamos la aplicación, ya que es el index.php quien arranca el SugarApplication. A partir de aquí, mediante los parámetros indicados en la URL se van realizando una serie de cargas y consultas, para que finalmente lleguemos a la página destino. En el caso del ejemplo, lograríamos acceder al módulo de Gastos, a la vista de edición del elemento con ID A continuación se detalla qué funciones tiene cada parte de la estructura: Sugar Application Es el Core de la aplicación. Siempre que el usuario solicite un recurso, se deberá ejecutar con el fin de realizar las siguientes funciones: Controlar la sesión para validar la autentificación del usuario y en caso de no estar identificado cargar, el módulo de usuarios para realizar dicha identificación. Realizar la verificación de la base de datos, y en caso de ser correcta, realiza la conexión que será usada después por el SugarController. Aplicar los permisos asociados al usuario. Configurar las variables de idioma, franja horaria y aspecto visual de las pantallas. Cargar el controlador del módulo indicado en la URL. SugarController Es el encargado de la lógica de la aplicación, en función de los parámetros recibidos por URL, decidirá qué Vista hay que mostrar o qué consulta hay que realizar. Hay que matizar que la estructura MVC del SugarCRM nos permite definir un controlador para cada módulo, lo cual nos facilita mucho el trabajo, ya que si deseáramos cambiar la lógica de la aplicación para algún módulo en cuestión, podríamos hacerlo sin problema creando un Controller.php en la carpeta de nuestro módulo. Pero si en vez de eso, lo que deseamos es usar el Controlador genérico veremos que dicho controlador dispone de cinco acciones predefinidas, que se ejecutará en función del parámetro llamado action pasado por la URL. Las acciones predefinidas son: 11

12 ListView: esta acción genera una vista con un listado de los elementos del módulo. DetailView: esta acción genera la vista detallada de un elemento del módulo. EditView: esta acción genera la vista para editar un elemento del módulo. Save: esta acción recoge los parámetros enviados desde la vista, para guardarlos en la base de datos respetando las reglas de negocio marcado por el modelo. Delete: con esta última acción se borra el elemento o elementos seleccionados en pantalla. SugarView Es la encargada de mostrar al usuario la interfaz establecida por el controlador. Al igual que el Controlador, las vistas se pueden redefinir para cada módulo. El SugarView además utiliza una clase que extiende del SugarView con el fin de mostrar las diferentes tipos de vistas establecidasdiferente para cada tipo de vista. Para poder construir las diferentes vistas utiliza la información del SugarBean. Ejemplo ListView: 12

13 Ejemplo DetailView: Ejemplo EditView: 13

14 SugarBean Esta parte es el modelo de la aplicación. Contiene toda la información referente a los elementos del módulo, por lo que permite tanto a las vistas como al controlador realizar consultas de la información y actualizaciones de las mismas. MetaData Esta última parte de la aplicación es utilizada para detallar qué información debe reflejarse en cada una de las vistas, además de detallar de qué forma hacerlo. De esta forma resulta mucho más sencillo modificar las vistas sin necesidad de modificar el SugarView, ya que el SugarView define la estructura de la vista y en estos ficheros se definen qué campos mostrar. 14

15 4.3.2 Decisiones de diseño Etapa 1: Control y exportación de gastos Para llevar a cabo la primera etapa del proyecto, que consistía en poder llevar un control de los gastos que tiene la empresa y poder exportarlos, se han diseñado tres módulos: Módulo Compañías: dicho módulo llevará un control de las compañías en las que se tienen los diferentes gastos. Únicamente daremos de alta nuevas empresas y tendremos un listado de ellas. Módulo Gastos Periódicos: TechnoDAC deseaba además de llevar un control de todos los gastos, poder llevar un control de forma más sencilla de los gastos que se generaban de forma periódica. Es por ello que creamos este módulo, donde el usuario puede generar un gasto periódico y asociarlo con una compañía. Módulo Gastos: este último módulo de la primera etapa sería el encargado de dar de alta los gastos y asociarlos primeramente con una compañía, y si dicha compañía tuviera activo algún gasto periódico, podríamos relacionarlo con él. El diseño inicial para estos tres módulos era el siguiente: Compañía 1 N Gasto 1 N N 1 Gasto Periódico 15

16 Aunque finalmente no se optó por ese diseño sino por este otro: Compañía M N Gasto M N N M Gasto Periódico El primer diseño consistía en almacenar en la tabla de Gastos Periódicos el identificador de la compañía con la que estaba relacionado el gasto periódico, y en la tabla de Gastos el identificador de la compañía a la que pertenecía el gasto y en el caso de ser un gasto periódico, almacenar también el identificador del gasto periódico. De esta forma podríamos obtener la información de las relaciones con una simple consulta sin necesidad de generar tablas auxiliares. Pero a la hora de implementarlo surgió un problema, y es que el gestor SugarCRM funciona de otra forma y para generar las relaciones en las vistas, va a buscar la información de las relaciones en tablas auxiliares. Por lo tanto, se diseñaron las tablas para una relación N-M, aunque realmente fuera ficticia, ya que la relación real que solicitó la empresa fue 1-N. Otra decisión que hubo que tomar era como almacenar todas las facturas de gastos que la empresa tenía desde que comenzó su actividad. Para ello se implementó un sistema de importación que añadía todos los datos a la base de datos a partir de un fichero de texto. Pero antes de ello se tendrían que añadir las compañías a mano para poder crear la relación con los gastos. En último lugar, con el fin de poder exportar todos los gastos para poder facilitárselos al contable de la empresa, se utilizó una librería ya existente en el SugarCRM, con la que únicamente deberíamos generar una serie de consultas a la base de datos, que serían previamente mostradas al usuario para poder verificar que todos los datos fueran correctos, y una vez aceptados poder crear el fichero XLS (Excel). 16

17 Para facilitar el trabajo al contable, se generan dos tipos de Excel: El primero contiene un listado detallado con los gastos generados por la empresa, otro listado con las facturas emitidas por la empresa y finalmente un listado de gastos intracomunitarios de la empresa. El segundo fichero Excel contiene el Modelo 347, que únicamente contendrá un listado tanto de facturas como de gastos, agrupados por aquellas empresas a las que se les facture más de o en la que los gastos sean superiores a Finalmente sólo quedaba añadir las funcionalidades de Importar/Exportar en alguno de los módulos creados. Para ello se decidió añadir (al menú del módulo de gastos) tres botones que permitían generar dichos informes. 17

18 Etapa 2: Modificación de módulos Esta etapa únicamente consistía en realizar una serie de arreglos a diferentes módulos ya existentes en el gestor. Por este motivo no se han tomado grandes decisiones de diseño, ya que la empresa solicitaba cambios muy concretos, como por ejemplo cambiar textos de diferentes páginas, re-ajustar el orden de visualización de campos Otro de los cambios solicitados por la empresa estaba relacionado con el tamaño de los Pop-Up que creaba la aplicación. Dichos Pop-Up suelen generar listados en los que el usuario debe seleccionar uno o varios elementos y con el tamaño que se generaban, en según qué ocasiones resultaba complicado ver la información reflejada en ellos. Por ese motivo decidimos aumentar el tamaño del Pop-Up a 800x600 píxeles. De esa forma la información quedaría mejor reflejada y el Pop-Up podría ser abierto desde cualquier PC, ya que la resolución de pantalla 800x600 suele ser la resolución mínima que hoy en día aceptan todos los ordenadores. 18

19 Etapa 3: Creación de recibos bancarios La empresa necesitaba generar un fichero, que se cargaría en la página web del banco y automáticamente generaría los recibos bancarios a los clientes. El fichero en cuestión debe cumplir unos estándares aprobados por la Asociación Española de Banca (AEB), Confederación Española de Cajas de Ahorro (CECA) y Unión Nacional de Cooperativas de Crédito (UNACC). Para poder rellenar el fichero son necesarios una serie de datos vinculados en primer lugar al presentador y ordenante de los recibos, y acto seguido una serie datos relacionados con cada uno de los recibos a generar. Los datos necesarios por parte del ordenante y presentador, que en nuestro caso serán los mismos, son: El NIF del presentador. Un sufijo que debemos asignar a cada posible presentador. Fecha en la que se genera el fichero y fecha de cobro. Nombre del presentador. Entidad bancaria, oficina, dígito de control y número de cuenta. Y por otro lado, para generar los datos de cada recibo necesitamos: NIF de la empresa. Código de referencia, para poder identificar el recibo. Usamos en este caso el número de la factura. Concepto del recibo. Entidad bancaria, oficina, dígito de control y número de cuenta. Para finalizar será necesario añadir una serie de datos que indicarán la cantidad total a facturar, junto al número total de recibos. Todos estos datos habrá que reflejarlos en un fichero con formato N19 que deberá cumplir una estructura muy estricta, conteniendo los datos mencionados anteriormente reflejados tal y como se muestran en las imágenes de la página siguiente. Cada bloque corresponde a una línea dentro del fichero, que se verá identificada con unos códigos que indicarán qué están reflejando. Los códigos a mostrar para identificar cada bloque son: : indica que estamos mostrando la información del presentador : indica que estamos mostrando la información del ordenante : indica que estamos mostrando la información de un recibo : indica que estamos mostrando la información total del ordenante : indica que estamos mostrando la información total general. 19

20 20

21 Una vez establecida toda la información necesaria para generar el fichero, decidí añadir la nueva funcionalidad en el módulo ya existente de Vencimientos. Dicho módulo lleva un registro de los vencimientos generados por cada factura que ha generado el usuario. Es decir, una factura puede ser desglosada en diferentes pagos, y por cada pago se genera un vencimiento. Antes de empezar a trabajar con este módulo, los vencimientos tenían una fecha de vencimiento que indicaba el plazo máximo que el cliente tenía para pagar, tenían también la fecha en que realizaron el pago y un campo que indicaba si estaba o no pagado, además de los campos que indican cómo se realiza el pago, si en efectivo, recibo bancario o transferencia bancaria, y por último la descripción del vencimiento, usada como concepto. Para poder llevar un control de qué vencimientos habían sido presentados en el banco, cuáles no y cuáles estaban ya pagados, se realizó una pequeña modificación en este módulo para que en vez de mostrar si el vencimiento estaba pagado o no, mostraría un desplegable indicando en qué estado estaba, del tal forma que en cuanto se generase el recibo, dicho campo cambiaría automáticamente a presentado. De esta forma podemos llevar un mejor control de los estados de los vencimientos. Dejando esto solucionado, necesitamos los datos del presentador/ordenante, y con el fin de evitar tener que introducirlos cada vez que el usuario quisiera crear un nuevo recibo, creamos un nuevo módulo llamado Presentadores. Este módulo únicamente contendría la información necesaria de cada presentador. Una vez disponible toda la información, se añadió un botón en el listado de Vencimientos de tal forma que el usuario podía seleccionar de forma sencilla los vencimientos que deseaba introducir en el recibo y una vez seleccionados se le muestra en pantalla una pre-visualización, para poder mostrar en caso de error qué vencimientos daban problemas, como por ejemplo el caso de que un vencimiento ya estuviera pagado o la forma de pago fuera en efectivo. Para acabar con esta etapa, sólo quedaba decidir cómo llevar un registro de los recibos creados y qué vencimientos contenían. Para ello se creó otro nuevo módulo llamado Recibos, que contendría la información de los vencimientos y del presentador, además del nombre del recibo y su fecha de creación. Se creó una relación 1-N con la tabla de vencimientos para poder controlar la relación, y tal y como se comentó antes acabó siendo una relación ficticia N-M. 21

22 Etapa 4: Creación de gráficos La última petición de la empresa era añadir al módulo de Control de Mando del SugarCRM una serie de gráficos que reflejaran toda la información que hemos obtenido con los módulos anteriores. Este módulo estaba preparado para mostrar una serie de gráficos generados por una animación Flash que incluye el propio gestor y que recoge datos de las tablas guardadas en las bases de datos. Además, dicho módulo está caracterizado por un sistema de Dashlets, que permite al usuario mover por diferentes zonas de la pantalla los gráficos según desee. De esta forma puede organizar a su gusto los gráficos a mostrar. Inicialmente se intentó utilizar dichas animaciones Flash para rellenarlas con los datos obtenidos de la base de datos mediante una serie de consultas SQL. Pero fue imposible, ya que dichos gráficos estaban únicamente preparados para mostrar una serie de datos. Por lo tanto, decidimos aprovechar dicho módulo, pero modificando el contenido de los Dashlets. Para ello se hizo un estudio de cómo funcionaba internamente el módulo y vimos que realmente no era necesario utilizar los dashlets creados por el SugarCRM. Así que decidimos crear nuestros propios Dashlets con los gráficos que solicitaba la empresa. Para ello, primeramente se hizo un estudio de qué datos serían convenientes mostrar para poder llevar un mejor control sobre ellos, y poder realizar análisis de forma mucho más sencilla sobre la evolución y el estado de la empresa. Una vez decidido qué tipo de gráficos se querían, únicamente había que crearlos, y para ello se usó una librería externa que facilita Google, de forma gratuita, llamada Google Chart Tools. El motivo por el que se escogió usar esta librería, en vez de crear una nueva o usar alguna otra, es que generar este tipo de gráficos conlleva un coste elevadísimo. Además Google aporta un sin fin de tipos de gráficos con un diseño muy claro y conciso que muestra la información de forma correcta y entendible. Además de ello, una vez extraída la información necesaria de la base de datos, la construcción del gráfico se realiza de forma rápida y sencilla. 22

23 4.4 Desarrollo Requisitos e instalación Para poder utilizar y modificar el SugarCRM es necesario realizar una instalación de un Servidor Web, PHP y en último lugar la base de datos MySQL. Una vez está todo instalado, hay que añadir el código fuente de la aplicación, que en este caso fue facilitado por la empresa. Para ello únicamente habría que copiar el código a la carpeta donde se alojan los ficheros del servidor web. Para acabar habría que importar una base de datos creada por TechnoDac para realizar las diferentes pruebas necesarias. Una vez nombrados los requisitos, sólo quedaría hacer funcionar el SugarCRM. Para ello debemos modificar el fichero config.php, para que realice de forma correcta la conexión con nuestra base de datos, indicándole el usuario y contraseña correctos. Otro asunto muy importante es activar el modo desarrollador en el SugarCRM. Para ello sólo hay que acceder con nuestro usuario a la sección de Administración, y en las configuraciones activar dicha opción. Es necesario realizar esto ya que el SugarCRM usa un sistema de cache que él mismo genera, con el fin de acelerar la navegación. Pero en muchos casos, si esta opción no se activa no se apreciarán los cambios realizados en el código. 23

24 4.4.2 Desarrollo por etapas Etapa 1: Control y exportación de gastos Los pasos que se siguieron para poder realizar los tres módulos necesarios para llevar el control y exportación de los gastos de la empresa fueron: 1. Después de decidir qué información deseaba almacenar la empresa en cada módulo se procedió a crear las tablas necesarias para almacenar la información de cada módulo (Compañías, Gastos Periódicos, Gastos). Para crear estas tablas se utilizó el gestor PhpMyAdmin, que nos permite crear las tablas mediante una consulta SQL. 2. Crear las tablas que contienen la información referente a la relación entre los módulos (Compañías-Gastos, Gastos Periódicos-Gastos, Compañías-Gastos Periódicos). Dichas tablas únicamente contienen los identificadores de los elementos relacionados. Al igual que el caso anterior, las tablas fueron añadidas mediante el gestor PhpMyAdmin. 3. Añadir un nuevo registro a la tabla Relationships, añadiendo la información sobre las relaciones entre módulos, ya que esta tabla es usada por el SugarCRM para poder implementar dichas relaciones. 4. Una vez creadas las tablas para almacenar la información se procedió a generar los ficheros para los tres módulos. Todos ellos siguen el mismo esquema: NombreDelModulo Dashlets NombreDelModuloDashlets NombreDelModulo.meta.php NombreDelModuloDashlet.php Language es_es.lang.php en_us.lang.php metadata subpanels default.php dashletviewdefs.php detailviewdefs.php editviewdefs.php listviewdefs.php metafiles.php popupdefs.php searchdefs.php SearchFields.php sidecreateviewdefs.php NombreDelModulo.php NombreDelModulo_sugar.php vardefs.php 24

25 5. Después de crear los diferentes ficheros con la información básica para cada módulo, se detallaron los campos en el fichero vardefs.php, donde se establece toda la información de los campos. 6. Se procedió a modificar los ficheros de la carpeta metadata, con el fin de mostrar la información deseada por la empresa en cada una de las vistas. 7. También se modificaron los ficheros de la carpeta language para añadir las etiquetas necesarias en cada idioma para cada uno de los campos. 8. En el módulo de Compañías, además se añadió un nuevo fichero llamado Save.php. De esta forma se sustituye la función definida en el controlador para guardar el elemento y usaremos en cambio el código definido en este fichero. El motivo por el que se creó dicho fichero fue para evitar guardar compañías con el NIF duplicado. Para ello se recoge la información enviada por el formulario y en función de si existe o no el ID sabemos si estamos realizando una actualización de una compañía o creando una nueva. En el caso de crear una nueva, usaremos la siguiente función para verificar si existe alguna con el mismo NIF introducido. function checkforduplicates(){ $query = "SELECT nif FROM gas_companys WHERE deleted!= 1 AND nif like '".$_POST['nif']."%'"; if(!empty($query)){ $rows = array(); global $db; $result = $db->query($query); $i=-1; while(($row=$db->fetchbyassoc($result))!= null) { $i++; $rows[$i] = $row; } if ($i==-1) return null; return $rows; } } return null; 9. Para el módulo de Compañías se añadió un fichero javascript, con el que en la vista de edición podremos seleccionar un color mediante una paleta de colores, que luego será usado a la hora de exportar los gastos a un fichero Excel. 10. En el módulo de Gastos también se añadió un fichero javascript, en este caso para controlar el total de un gasto, ya que el total debía ser calculado en función de un Subtotal+IVA-Retención. Para ello se ejecutan las siguientes funciones cada vez que el subtotal, IVA o retención son modificados en la pantalla de edición. 25

26 function gettotal(){ var subtotal = Number(document.getElementById('subtotal').value); var iva = Number(document.getElementById('iva').value); var retencion = Number(document.getElementById('retencion').value); } var retencion = subtotal*(retencion/100); document.getelementbyid('valor_retencion').value=retencion; var total = subtotal+(subtotal*(iva/100))-retencion; document.getelementbyid('total').value=total; Dicha función únicamente recoge el porcentaje marcado en el IVA y en la retención para añadírselo al subtotal y mostrarlo en el campo de total. 11. Dado que al crear un nuevo Gasto se debe relacionar primeramente con una compañía y en el caso de que dicha compañía tuviese relacionados algún gasto periódico, se modificó la selección de Gasto Periódico de tal forma que en primer lugar forzase a escoger una compañía, para a la hora de generar la lista de gastos periódicos poder realizar el filtrado de forma correcta. Para ello se modificó la función que ejecuta el botón Seleccionar. node = document.getelementsbyname("btn_gas_gastos_periodicos_gas_gastos_name"); node[0].onclick= function(){ if(document.getelementbyid("gas_companys_id").value!=""){ open_popup("gas_gastos_periodicos", 800, 600, "&gas_companys_id="+document.getelementbyid("gas_companys_id").value, true, false, {"call_back_function":"set_return","form_name":"editview","field_to_name_array":{"id":"g as_periodicos_id","descripcion":"gas_gastos_periodicos_gas_gastos_name","tipo_gasto":"tipo _gasto","retencion":"retencion","iva":"iva","intra_com":"intra_com"}}, "single", true); }else{ alert("debes seleccionar una compañia"); document.getelementbyid("gas_companys_gas_gastos_name").focus(); } }; 12. En la vista de edición del módulo Gastos, se añadió un botón que mostraba un listado de los Tipos de Gastos contables que ya se han introducido en la base de datos. Para ello, al mismo tiempo que se genera la vista de edición, se realiza una consulta SQL que nos retorna el listado de tipos de gastos y la cantidad que hay de cada uno de ellos. Con este listado se genera una tabla que queda en primera instancia oculta para el usuario. Pero gracias al botón, se permite al usuario mostrar dicha tabla, ya que el botón ejecuta la siguiente función javascript. 26

27 function showlistgastos(){ if(document.getelementbyid('lista_gastos').style.display=='block'){ document.getelementbyid('lista_gastos').style.display='none' }else{ document.getelementbyid('lista_gastos').style.display='block' } } 13. Una vez finalizada la parte que permite llevar el control de los gastos de la empresa, pudiendo añadir nuevas compañías, nuevos gastos periódicos y nuevos gastos, además de poderlos relacionar entre sí, quedaba la parte en la que la empresa tenía que exportar dichos gastos a un Excel. Para ello se añadieron una serie de botones en el menú del módulo de Gastos que permitirían dicha funcionalidad. Para ello únicamente se redefinió el fichero Menu.php para que mostrase dichos botones. Dichos botones llevan en primer lugar a una pantalla donde el usuario puede introducir el periodo del que desea extraer los gastos. Para ello, simplemente se añadieron dos inputs a la pantalla donde el usuario podía introducir la fecha inicio y la fecha, ayudándose de un calendario que incorpora la librería de SugarCRM. Una vez introducidas las fechas, se realiza una consulta SQL que extrae todos los datos necesarios para generar el fichero Excel. Pero antes de generarlo son mostradas en la página, para que el usuario pueda verificar toda la información, además de ser advertido en el caso de que falte algún gasto periódico. Si finalmente el usuario da por bueno el listado, dispone de un botón que generará el fichero Excel. 14. Por último sólo queda añadir los módulos al gestor. Para ello únicamente se han tenido que añadir las rutas y los nombres al fichero del gestor donde se lleva el control de los módulos. Además de crear los tres módulos para llevar el control, se creó un página php que permitía introducir en la base de datos todos los gastos anteriores. Como hasta la fecha la empresa creaba los Excel s a mano, se pudo exportar toda esa información en ficheros CSV. Estos ficheros no dejan de ser ficheros de texto que contienen la información separada por comas. Por lo tanto, únicamente se creó una página php que leyera dichos datos para introducirlos en la base de datos. Pero surgieron varios problemas. El primero de ellos es que los datos reflejados en los ficheros CSV tenían algunos errores, ya que existían NIF s de empresa mal introducidos y faltaba algún que otro dato. Por lo tanto en primer lugar se revisaron dichos ficheros para corregir todos los errores. Esto fue con ayuda de David, ya que sólo él disponía de la información correcta. Una vez limpiados los ficheros, se ejecutó el código, que recorre línea a línea el fichero, recogiendo la información referente a los gastos y las compañías, para generar una serie de arrays de compañías y gastos que luego insertará en la base de datos. El código utilizado se muestra a continuación: 27

28 <?php $connect = mysql_connect("localhost","xxxx","yyyy"); mysql_select_db("sugarcrm",$connect); $archivo = file('datos.txt'); foreach($archivo as $linea){ $datos = explode(";",$linea); if($datos[3]!=""){ // Para no cargar compañias que no tienen NIF $companys[$datos[3]] = array("name" => $datos[4],"id" => "NULL"); } $datos[21] = str_replace(",",".",$datos[21]); $datos[20] = str_replace(",",".",$datos[20]); $subtotal = $datos[21]-$datos[20]; if($datos[3]==""){ //Las compañias sin NIF, son las de electro se las asocia a ese NIF $datos[3] = "A "; } $gastos[$datos[2]] = array("nif" => $datos[3], "fecha" => $datos[1], "concepto" => $datos[5], "subtotal" => $subtotal, "iva" => $datos[19], "total" => $datos[21] ); } foreach($companys as $nif => $company){ $id_company = create_guid(); $name = $company["name"]; mysql_query("insert INTO gas_companys (id,name,date_entered,date_modified,modified_user_id,created_by,deleted,nif,color) VALUES ('$id_company','$name',now(),now(),'1','1','0','$nif','#ffffff')") or die(mysql_error()." $nif y $name"); } $company["id"]=$id_company; $companys[$nif]=$company; foreach($gastos as $num_factura => $gasto){ $id_gasto = create_guid(); $concepto = $gasto["concepto"]; $subtotal = $gasto["subtotal"]; $iva = $gasto["iva"]; $total = $gasto["total"]; $fecha = $gasto["fecha"]; mysql_query("insert INTO gas_gastos (id,name,date_entered,date_modified,modified_user_id,created_by,deleted,numero_factura,concepto, subtotal,iva,total,fecha_factura) VALUES ('$id_gasto','',now(),now(),'1','1','0','$num_factura','$concepto','$subtotal','$iva','$total',str_to_dat E('$fecha','%d/%m/%Y')) ") or die(mysql_error()); $id_relacion = create_guid(); $id_company = $companys[$gasto["nif"]]["id"]; mysql_query("insert INTO gas_companys_gas_gastos_c (id,date_modified,deleted,gas_companys_id,gas_gastos_id) VALUES ('$id_relacion',now(),'0','$id_company','$id_gasto')") or die(mysql_error()); }?> 28

29 Etapa 2: Modificación de módulos La empresa solicitó modificar el orden en los que se mostraban algunos campos de los módulos ya existentes. Para ello únicamente se modificaron los ficheros de la carpeta metadata de las vistas deseadas, simplemente cambiado el orden de los arrays quedaba solventado este problema. Para el problema de que algunos textos se mostraban de forma incorrecta, se realizaron modificaciones en los ficheros de la carpeta language de cada módulo, para reajustarlos al texto solicitado. Para modificar el tamaño de los Pop-Up, se tuvo que redefinir el tamaño modificando la función open_popup en los ficheros siguientes: Include/SugarFields/Fields/Parent/SearchView Include/SugarFields/Fields/Parent/EditView Include/Generic/SugarWidgets Además de eso, se tuvo que solucionar un problema con los popup, ya que no recibía los parámetros que luego utilizaría de filtro para crear los listados. Para ello se corrigió la función interna encargada de recoger los parámetros, que recibe la pantalla mediante el request. 29

30 Etapa 3: Creación de recibos bancarios Para llevar a cabo esta etapa se siguieron los siguientes pasos: 1. En primer lugar se crearon las tablas en la base de datos para los módulos de Recibos y Presentadores tal y como se indicó anteriormente. 2. Se creó la tabla para establecer la relación entre Recibos y Vencimientos. 3. Se crearon las estructuras de ficheros para los módulos Recibos y presentadores tal y como se mencionó anteriormente. 4. Se eliminaron los campos number, cuenta, cuenta_id_c y pagado de la tabla vencimientos ya que no se volverían a utilizar. 5. Se añadió un nuevo campo a la tabla de vencimientos llamado estado de tipo enum que podía optar entre No Presentado, Presentado, Pagado y Retornado. 6. Se eliminó la tabla extra de vencimientos, que únicamente contenía el campo de fecha_pago. Dicha tabla existía ya que anteriormente se realizó una modificación incorrecta sobre este módulo, y para ello crearon una nueva tabla con este campo y el id del vencimiento con el que estaba asociado. Con tal de evitar tener que modificar dos tablas, se traspasó toda la información de esta tabla extra a la tabla original de vencimientos. Para ello, en primer lugar se creó el campo fecha_pago y acto seguido se ejecutó una consulta SQL para migrar todos los datos. UPDATE ven_vencimientos SET ven_vencimientos.fecha_pago = (SELECT ven_vencimientos_cstm.fecha_pago_c FROM ven_vencimientos_cstm WHERE ven_vencimientos_cstm.id_c = ven_vencimientos.id); 7. En el módulo de Presentadores se añadieron unas funciones javascript para controlar que el sufijo del presentador y el número de cuenta fueran correctos. Para ello se usaron las siguientes funciones javascript que validaban dichos campos. 30

31 function checksufijo(){ var sufijo = document.getelementbyid('sufijo'); if(isnan(sufijo.value)){ sufijo.value=''; sufijo.focus(); alert("recuerda que el sufijo deben ser 3 digitos"); } else if(sufijo.value.length!=3){ alert("recuerda que el sufijo deben ser 3 digitos"); sufijo.focus(); } } 31

32 function comprobar_ccc() { var cond=check_form('editview'); var ccc= document.getelementbyid('cc_1').value + document.getelementbyid('cc_2').value + document.getelementbyid('cc_3').value + document.getelementbyid('cc_4').value; document.getelementbyid('numero_cuenta').value = ccc; if (ccc!= "") { var c1, c2, c3, c4, digito, Resto, DC1, DC2, DC, Apesos, x; var parte1, parte2; c1 = ccc.substr(0, 4); c2 = ccc.substr(4, 4); c3 = ccc.substr(8, 2); c4 = ccc.substr(10, 10); parte1 = c1 + c2; parte2 = c4; Apesos = new Array(10); Apesos[0] = 1; Apesos[1] = 2; Apesos[2] = 4; Apesos[3] = 8; Apesos[4] = 5; Apesos[5] = 10; Apesos[6] = 9; Apesos[7] = 7; Apesos[8] = 3; Apesos[9] = 6; DC1 = 0; DC2 = 0; x = 8; while (x > 0) { digito = parte1.substr(x - 1, 1); DC1 = DC1 + (Apesos[x + 2-1] * digito); x = x - 1; } Resto = DC1 % 11; DC1 = 11 - Resto; x = 10; while (x > 0) { digito = parte2.substr(x - 1, 1); DC2 = DC2 + (Apesos[x - 1] * digito); x = x - 1; } Resto = DC2 % 11; DC2 = 11 - Resto; } if (DC1 == 10) { DC1 = 1; } if (DC1 == 11) { DC1 = 0; } if (DC2 == 10) { DC2 = 1; } if (DC2 == 11) { DC2 = 0; } DC = DC1 + "" + DC2; if ((DC == c3) == false ) { alert("número de cuenta erróneo"); return false; } } else { return (cond); } 32

33 8. Dado que ahora los vencimientos no disponían del campo Pagado, pero sí del campo estado, se modificaron las definiciones de los campos en el fichero vardefs.php del módulo vencimientos, además de eliminar los mencionados en el punto cuatro. 9. La forma en que se generan los vencimientos no es mediante el módulo de vencimientos, sino desde el módulo de facturas, ya que los vencimientos no son nada más que un desglose de pagos de una factura. Por lo que hasta ahora, cada vez que se generaba una factura, se podían añadir vencimientos y se debían rellenar una serie de campos sobre los vencimientos, tal y como se muestra en la siguiente imagen. Se puede apreciar en la imagen que el usuario debe informar de los campos de porcentaje, forma de pago, fecha vencimiento, estado, fecha pago y descripción. Como es lógico, antes de realizar las modificaciones pertinentes el campo de Estado no existía, pero sí existía un campo llamado Pagado. Por lo tanto se han tenido que realizar una serie de modificaciones para mostrar los campos correctos, y guardar dicha nueva información. Para ello en primer lugar se modificó una función javascript que añadía esas líneas de vencimientos para que en vez de insertar el campo Pagado, pusiera el campo Estado, rellenando el combo con los valores correctos. Dicha función se encontraba en el fichero EditView.html del módulo Facturas. Cabe destacar que este módulo no usa la Vista genérica para la vista detallada, ya que dispone de su propia vista. Para finalizar los cambios en este módulo, se tuvo que modificar el fichero Factura.php que extiende del SugarBean, y por lo tanto dispone de los métodos necesarios para recuperar información referente a los elementos de este módulo. El cambio consistía en modificar las funciones get_vencimiento_detail_view y get_vencimiento, para igual que antes, en vez de recuperar los valores del campo Pagado, recuperara y mostrase de forma correcta el campo Estado. Además se modificó la tabla en la que se guardaba la fecha de pago. 10. Una vez realizados todos los cambios necesarios en el módulo de facturas y vencimientos, se procedió a la creación del fichero para enviar los recibos bancarios mediante la web del banco. Para ello se añadió un botón en el menú del módulo vencimientos. Dicho botón, en primer lugar comprobaba si existía algún vencimiento seleccionado, para insertarlo en el fichero mediante una función javascript. 33

34 function createaeb(){ var marcados = document.massupdate.uid.value; if(marcados!= ""){ marcados = ","+marcados; } inputs = document.massupdate.elements; ar = new Array(); for(i = 0; i < inputs.length; i++) { if(inputs[i].name == "mass[]" && inputs[i].checked && typeof(inputs[i].value)!= "function") { ar.push(inputs[i].value); } } var newform = document.createelement("form"); newform.method = "post"; newform.action = "index.php?module=pres_recibos&action=create_recibo"; document.body.appendchild(newform); var elements = document.createelement("textarea"); elements.name = "elementos"; elements.value = ar.join(",")+marcados; } if(elements.value == ""){ alert("selecciona al menos un registro"); }else{ newform.appendchild(elements); newform.submit(); } Dicha función javascript, valida si existe algún vencimiento marcado en el listado, y en el caso de existir crea un nuevo formulario añadiendo en un campo oculto los identificadores de los vencimientos marcados, para enviarlos al fichero encargado de presentar en primer lugar la información de los vencimientos, para acto seguido poder crear el fichero N19. Una vez validados los vencimientos, la nueva página recoge los identificadores y recupera la información necesaria de cada vencimiento para poder generar el fichero. Además verifica que los vencimientos seleccionados pueden ser exportados al fichero, ya que en el caso de que el vencimiento ya esté pagado, o ya se haya presentado, o no disponga de un concepto, la pantalla informará del error y no dejará generar el fichero. Además se muestra un combo con los diferentes Presentadores creados, donde el usuario debe seleccionar uno, con el fin de crear el fichero. Si finalmente el usuario pulsa el botón que genera el fichero, se procede a actualizar el estado de los vencimientos marcados a Presentado, se actualiza la fecha de pago a cinco días después y se crea un nuevo recibo vinculado con los vencimientos establecidos, que es enviado al usuario para poder ser descargado. 34

35 Etapa 4: Creación de gráficos Para poder incorporar los gráficos solicitados por la empresa en el módulo ya existente dentro del gestor llamado Cuadro de Mando, se realizaron las siguientes modificaciones: 1. En primer lugar se modificó el fichero index.php del módulo DashBoards, ya que hasta la fecha los Dashlets mostrados en este módulo se dividían en dos columnas, la primera ocupaba el 60% y la segunda el 40%. Pero la empresa solicitó que ambas columnas ocuparan el 50% de la pantalla. Para ello únicamente se modificó el array dashboardcolumns, para que cada columna tuviera un width del 50%. 2. Acto seguido, para poder utilizar la librería de Google que generaba los gráficos a partir de los datos enviados, fue necesario importar la librería javascript que proporciona la compañía Google. Para ello fue necesario modificar el fichero MySugar.tpl que se encuentra en la carpeta include/mysugar/tpls/. Dicho archivo es la plantilla que se usa para generar la vista del módulo Cuadro de Mando. Por lo tanto, añadiendo la importación de la librería en dicho fichero, podríamos usarla en todos los dashlets generados. Para importar la librería se añadió la siguiente línea de código: <script type='text/javascript' src=' 3. Una vez modificado el módulo de Cuadro de Mando a nuestro gusto, sólo quedaba generar nuestros Dashlets, donde cada uno de ellos contendría uno de los gráficos solicitados por la empresa. Para poder generar cada uno de los gráficos, se creó la siguiente estructura de ficheros para cada uno de ellos: modules/ Charts/ Dashlets/ NombreDelDashlet/ NombreDashletConfigure.tpl NombreDashletDashlet.data.php NombreDashletDashlet.en_us.lang.php NombreDashletDashlet.es_es.lang.php NombreDashlet.meta.php NombreDashlet.php 35

36 Dichos ficheros contienen la información referente al Dashlet a mostrar, las variables que se usarán para ello y las etiquetas que se usan en cada uno de ellos. Como estos Dashlets extienden de la clase Dashlet que existe ya en el SugarCRM, únicamente se modificó la función constructquery y display dentro del fichero NombreDashlet.php. La función constructquery únicamente construye la consulta SQL que utilizará la función display para obtener los datos necesarios de la base de datos. Dichas consultas reciben además una variable llamada year, que proviene de los parámetros introducidos por el usuario. Dichos parámetros establecen un intervalo de tiempo, ya que para cada año se añadirá un nuevo rango de datos al gráfico. Todas las consultas pueden se detallan en el anexo 1. Una vez construida la consulta, se ejecuta y se obtiene un array con los datos, que se usa para construir una serie de sentencias javascript que finalmente crean un objeto que junto a la librería de Google nos permitirá mostrar el gráfico al usuario. 36

37 4.5 Evaluación Para asegurar el buen funcionamiento de todos los módulos generados y todas las modificaciones realizadas, se han realizado diferentes juegos de pruebas. Módulo de Compañías Se ha verificado que se puedan generar compañías de forma correcta. Se ha comprobado que no se puedan duplicar compañías con el mismo NIF, y en caso de error se notifica al usuario. Se ha verificado que a la hora de mostrar el listado para extraer los gastos se muestre el color de fondo establecido en el campo de la compañía. Módulo Gastos Periódicos Se ha verificado el correcto funcionamiento al crear un gasto periódico y al enlazarlo con una compañía. Se ha verificado que muestra la relación correcta con los gastos asociados. Módulo Gastos Se ha verificado que se puede introducir un gasto de forma correcta verificando todos los campos necesarios. Se ha verificado que establece bien la relación con la compañía. Se ha verificado que en el caso de querer relacionarlo con un gasto periódico, nos solicita primero seleccionar una compañía. También se ha comprobado que el listado de gastos periódicos que muestra al intentar seleccionar uno, está filtrado en función de la compañía seleccionada. Comprobado que el importe total se calcula de forma correcta sumando los valores del IVA y la retención. Verificado que exporta de forma correcta todos los gastos y genera correctamente los diferentes Excel. Comprobado que importa de forma satisfactoria los gastos previos a la instalación del módulo. Se ha verificado que el orden de los formularios es el deseado por el usuario. Verificada la función que muestra los diferentes tipos de gastos introducidos anteriormente por el usuario. 37

38 Módulo Vencimientos Se ha comprobado que al generar un nuevo recibo se actualiza la fecha de pago y el estado se modifica a Presentado. Se ha validado que funciona correctamente el enlace creado desde el vencimiento hasta la Factura, tanto de la vista detallada, como de la vista de edición y la vista del listado. Se ha verificado el correcto funcionamiento del botón para generar ficheros N19 para el banco. Se ha verificado que recupera de forma correcta los datos del presentador seleccionado. Se ha verificado que en caso de error a la hora de generar un posible fichero, se muestran los errores de forma correcta y además no da la opción de crear el fichero. Módulo Facturas Se ha verificado la correcta creación de un vencimiento con los nuevos datos desde la edición de una factura. Módulo Presentadores Verificado el correcto funcionamiento del módulo. Verificado que los datos del presentador son guardados correctamente. Verificado que funciona la función para verificar que el número de cuenta es correcta. Módulo Recibos Verificado que la información generada desde el módulo Vencimientos se genera de forma correcta. Verificada que los datos de relación con los vencimientos son correctos. Verificada que la fecha de cobro es la fecha actual más 5 días de plazo. Verificado que el botón Generar fichero vuelve a generar de forma correcta el recibo con los vencimientos relacionados y la información almacenada del presentador. 38

39 Módulo Cuadro de Mando Comprobado que se pueden desplazar los Dashlets por las diferentes zonas de la pantalla. Comprobado que el tamaño de las dos columnas posibles para desplazar los Dashlets tiene un mismo tamaño. Comprobado que los gráficos generados muestran la información de forma correcta. Comprobado que al cambiar las fechas de los gráficos, muestran la información de los años correspondientes. Cambios generales Se ha revisado todo el texto introducido y mostrado por pantalla para verificar que es correcto tanto gramáticalmente como ortográficamente, Verificado que el tamaño de los pop-up es el correcto. Para no generar ni incidentes ni sorpresas en la empresa, todos los cambios eran primeramente probados en un entorno de desarrollo y una vez validados se volvían a realizar en producción. Aún así, en más de una ocasión nos encontramos que después de un tiempo en producción surgían nuevos errores, que eran nuevamente solucionados y vueltos a probar. Todas las pruebas se iban realizando a medida que íbamos avanzando en otras etapas, ya que íbamos añadiendo el código en producción a medida que se finalizaban las diferentes etapas del proyecto. 39

40 4.6 Recursos utilizados Documentos consultados Sugar Developer Guide Version 5.2, eloper_guide_5.2/sugardeveloperguide_v52.pdf The Definitive Guide to SugarCRM, Better Business Applications By John Mertic Adeudos por domiciliaciones en soporte magnético Serie normas y procedimientos bancarios 19 ation%2fpdf&blobheadername1=contentdisposition&blobheadervalue1=attachment%3b+filename%3des_recibo_d OMIC_CUADERNO_N19NOU.pdf&blobkey=id&blobtable=MungoBlobs&bl obwhere= &ssbinary=true 40

41 4.6.2 Páginas web consultadas Programa para instalar el servidor Apache con PHP y MySQL API de PHP Tutoriales JavaScript Documentación e información referente a SugarCRM Documentación de librería Excel Documentación de librerías de gráficos

42 5. Aportaciones del proyecto a los conocimientos del alumno El proyecto me ha aportado diferentes conocimientos. En primer lugar he maximizado mis conocimientos sobre los lenguajes de programación PHP, HTML, CSS y JavaScript, ya que todos ellos me han sido necesarios para llevar a cabo el proyecto. También hay que añadir los conocimientos obtenidos al usar el gestor SugarCRM, ya que he aprendido realmente para qué sirve un CRM y qué utilidad tiene dentro de una empresa. En último lugar mencionar que gracias al proyecto he visto de forma más amplia cómo funciona un MVC. El gestor SugarCRM es una herramienta muy elaborada y con muchas funciones, y gracias a su modelo MVC he podido comprender la funcionalidad de dicho patrón de arquitectura. 42

43 6. Aportaciones de los estudios realizados al proyecto Todo lo aprendido en la Universidad nos es de mayor o menor utilidad a lo largo de nuestra vida, ya que toda asignatura nos abre un pequeño mundo de posibilidades y nos introduce en la temática de su contenido. Para realizar este proyecto, los conocimientos que más me han servido han sido los obtenidos en las siguientes asignaturas: Programación I y II: son la base de todo programador, aunque en este proyecto he utilizado un lenguaje que nada tiene que ver con el enseñado en estas asignaturas, gracias a ellas obtuve la base y los fundamentos básicos de la programación, ya que una vez aprendido un lenguaje es bastante fácil adaptarse a cualquier otro. También hay que valorar que Java es un sistema de programación orientada a objetos, y en este proyecto se han usado de forma constante. Introducción a las Bases de Datos y Bases de Datos: con estas dos asignaturas obtuve conocimientos sobre la gestión de bases de datos, además de adquirir agilidad con el lenguaje SQL, que me ha permitido crear las tablas necesarias para la generación de los módulos nuevos. Economía y Economía de Empresa: aunque no en gran medida, los conocimientos obtenidos me han servido para llevar un mejor control de la contabilidad de la empresa, y entender los motivos por los que la empresa me solicitaba los módulos de contabilidad. Sistemas Abiertos: gracias a esta asignatura, obtuve conocimientos de HTML, CSS y JavaScript y además comprendí el funcionamiento cliente/servidor que existe en toda página web. Gestión de la Informática: en esta asignatura, además de mostrarnos cómo se organizan los equipos informáticos a la hora de gestionar un proyecto, nos enseñaron a elaborar una planificación para llevar a cabo nuestro proyecto, y es gracias a ello que he podido gestionar de forma correcta mi proyecto. Además de todo esto, también me han sido útiles todas las diferentes prácticas realizadas en la gran mayoría de asignaturas, ya que me han servido para saberme plantear problemas y buscarles una solución. 43

44 7. Conclusiones La realización del proyecto dentro de una empresa me ha servido para tener un primer contacto con el mundo laboral. Aunque no he realizado todo el proyecto dentro de la empresa, he aprendido a llevar una planificación del proyecto y tener un trato con el cliente, dado que en este caso la empresa con la que he hecho el proyecto es como si fuera mi cliente. También me he dado cuenta de que en el mundo de la informática todo cambia de forma continua, los lenguajes evolucionan y hay que estar aprendiendo de forma continua para no quedarse desfasado. Por último, he aprendido que después de recibir unos requisitos iniciales dentro de un proyecto, estos cambian de forma continua, el cliente siempre solicita modificaciones de lo realizado y hay que estar en constante desarrollo de la aplicación hasta el cierre del proyecto. De esto me he percatado ya que cuando hice la primera reunión con David me indicó unas tareas a realizar, que como ya he mencionado antes se dividían en tres etapas, pero a medida que avanzaba, los requisitos de las siguientes etapas iban cambiando, y a medida que iba finalizando las diferentes etapas siempre tenía que volver atrás para realizar modificaciones sobre lo ya hecho. 44

45 8. Anexo 1: Sentencias SQL Sentencia para crear la tabla del módulo de Compañías: CREATE TABLE `gas_companys` ( `id` char(36) NOT NULL, `name` varchar(200) NOT NULL, `date_entered` datetime default NULL, `date_modified` datetime default NULL, `modified_user_id` char(36) default NULL, `created_by` char(36) default NULL, `description` text, `deleted` tinyint(1) default '0', `assigned_user_id` char(36) default NULL, `nif` varchar(12) NOT NULL, `direccion` varchar(100) default NULL, `ciudad` varchar(20) default NULL, `provincia` varchar(20) default NULL, `codigo_postal` varchar(5) default NULL, `telefono` varchar(20) default NULL, `fax` varchar(20) default NULL, `persona_contacto` varchar(50) default NULL, ` _contacto` varchar(50) default NULL, `color` varchar(7) default NULL, PRIMARY KEY (`id`), UNIQUE KEY `nif` (`nif`) ) ENGINE=MyISAM DEFAULT CHARSET=utf8; 45

46 Sentencia para crear la tabla del módulo de Gastos Periódicos: CREATE TABLE `gas_gastos_periodicos` ( `id` char(36) NOT NULL, `name` varchar(255) NOT NULL, `date_entered` datetime default NULL, `date_modified` datetime default NULL, `modified_user_id` char(36) default NULL, `created_by` char(36) default NULL, `description` text, `deleted` tinyint(1) default '0', `assigned_user_id` char(36) default NULL, `descripcion` varchar(50) NOT NULL, `tipo_gasto` varchar(50) NOT NULL, `tiempo` int(2) NOT NULL, `iva` int(2) NOT NULL, `retencion` decimal(16,2) default NULL, `activo` tinyint(1) default '1', `intra_com` tinyint(1) default '0', PRIMARY KEY (`id`) ) ENGINE=MyISAM DEFAULT CHARSET=utf8; 46

47 Sentencia para crear la tabla del módulo de Gastos: CREATE TABLE `gas_gastos` ( `id` char(36) NOT NULL, `name` varchar(255) NOT NULL, `date_entered` datetime default NULL, `date_modified` datetime default NULL, `modified_user_id` char(36) default NULL, `created_by` char(36) default NULL, `description` text, `deleted` tinyint(1) default '0', `assigned_user_id` char(36) default NULL, `numero_factura` varchar(50) NOT NULL, `concepto` varchar(50) NOT NULL, `subtotal` decimal(16,2) NOT NULL, `iva` int(2) NOT NULL, `retencion` decimal(16,2) default NULL, `valor_retencion` decimal(16,2) default NULL, `total` decimal(16,2) NOT NULL, `tipo_gasto` varchar(25) NOT NULL, `fecha_factura` date NOT NULL, `intra_com` tinyint(1) default '0', PRIMARY KEY (`id`) ) ENGINE=MyISAM DEFAULT CHARSET=utf8; 47

48 Sentencia para crear la tabla del módulo de Presentadores: CREATE TABLE `pres_presentadores` ( `id` char(36) NOT NULL, `name` varchar(255) NOT NULL, `date_entered` datetime default NULL, `date_modified` datetime default NULL, `modified_user_id` char(36) default NULL, `created_by` char(36) default NULL, `description` text, `deleted` tinyint(1) default '0', `assigned_user_id` char(36) default NULL, `nif` varchar(15) NOT NULL, `sufijo` varchar(3) NOT NULL, `direccion` varchar(255) default NULL, `poblacion` varchar(255) default NULL, `codigo_postal` varchar(5) default NULL, `numero_cuenta` varchar(20) NOT NULL, PRIMARY KEY (`id`) ) ENGINE=MyISAM DEFAULT CHARSET=utf8; 48

49 Sentencia para crear la tabla del módulo de Recibos: CREATE TABLE `pres_recibos` ( `id` char(36) NOT NULL, `name` varchar(255) NOT NULL, `date_entered` datetime default NULL, `date_modified` datetime default NULL, `modified_user_id` char(36) default NULL, `created_by` char(36) default NULL, `description` text, `deleted` tinyint(1) default '0', `assigned_user_id` char(36) default NULL, `sufijo` varchar(3) NOT NULL, `nif` varchar(15) NOT NULL, `nombre_presentador` varchar(40) default NULL, `numero_cuenta` varchar(20) NOT NULL, `fecha` varchar(6) NOT NULL, `fecha_pago` varchar(6) NOT NULL, PRIMARY KEY (`id`) ) ENGINE=MyISAM DEFAULT CHARSET=utf8; Sentencia para crear las tablas de relaciones entre los diferentes módulos: CREATE TABLE `gas_gastos_s_gas_gastos_c` ( `id` varchar(36) NOT NULL, `date_modified` datetime default NULL, `deleted` tinyint(1) NOT NULL default '0', `gas_periodicos_id` varchar(36) default NULL, `gas_gastos_id` varchar(36) default NULL, PRIMARY KEY (`id`) ) ENGINE=MyISAM DEFAULT CHARSET=utf8; 49

50 CREATE TABLE `gas_companys_periodicos_c` ( `id` varchar(36) NOT NULL, `date_modified` datetime default NULL, `deleted` tinyint(1) NOT NULL default '0', `gas_companys_id` varchar(36) default NULL, `gas_periodicos_id` varchar(36) default NULL, PRIMARY KEY (`id`) ) ENGINE=MyISAM DEFAULT CHARSET=utf8; CREATE TABLE `gas_companys_gas_gastos_c` ( `id` varchar(36) NOT NULL, `date_modified` datetime default NULL, `deleted` tinyint(1) NOT NULL default '0', `gas_companys_id` varchar(36) default NULL, `gas_gastos_id` varchar(36) default NULL, PRIMARY KEY (`id`) ) ENGINE=MyISAM DEFAULT CHARSET=utf8; CREATE TABLE `pres_recibos_ven_vencimientos_c` ( `id` varchar(36) NOT NULL, `date_modified` datetime default NULL, `deleted` tinyint(1) NOT NULL default '0', `pres_recibos_id` varchar(36) default NULL, `ven_vencimientos_id` varchar(36) default NULL, PRIMARY KEY (`id`) ) ENGINE=MyISAM DEFAULT CHARSET=utf8; Sentencia para crear gráfico de cantidad total de facturas: SELECT SUM(subtotal_amount) as subtotal, month(date_entered) as mes FROM facturas WHERE deleted = 0 AND year(date_entered) = '$year' GROUP BY month(date_entered) 50

51 Consulta para crear el gráfico de cantidad total de gastos: SELECT SUM(subtotal) as subtotal, month(fecha_factura) as mes FROM gas_gastos WHERE deleted = 0 AND year(fecha_factura) = '$year' GROUP BY month(fecha_factura) Consulta para crear el gráfico que muestra la cantidad total de gastos, agrupados por el tipo de gasto: SELECT SUM(subtotal) as total, tipo_gasto FROM gas_gastos WHERE deleted = 0 AND year(fecha_factura) = '$year' GROUP BY tipo_gasto Consulta para crear el gráfico que refleja el retraso o anticipo en los pagos: SELECT AVG(DATEDIFF(fecha_vencimiento,fecha_pago)) as Diferencia, billing_account as Cuenta FROM ven_vencimientos V JOIN facturas F ON F.id = V.factura_id_c AND F.deleted = 0 WHERE V.estado = 'Pagado' AND V.deleted = 0 GROUP BY F.billing_account 51

52 9. Anexo 2: Imágenes de las modificaciones realizadas Imagen del módulo Cuadro de Mando con varios gráficos generados. Imagen del módulo Vencimientos, donde el usuario puede seleccionar los vencimientos deseados para generar el fichero N19 que cumple con el estándar AEB. Imagen que muestra algunos de los posibles errores por los que no se puede generar el fichero N19, además se puede apreciar que no muestra el botón para crearlo. 52

53 En esta otra imagen se puede apreciar como no marca ningún error, y por lo tanto se activa el botón para crear el fichero. Imágenes que muestran los errores al validar el sufijo y el número de cuenta del nuevo presentador. 53