Cuerpo.tex

\documentclass[a4paper, 12pt]{article}
\usepackage[utf8]{inputenc}
\usepackage[spanish]{babel}
\usepackage{fancyhdr}
\usepackage{setspace}
\usepackage[scaled]{helvet}
\usepackage{makeidx}

\setlength{\parskip}{\baselineskip}

\pagestyle{fancy}
\lhead{}
\chead{}
\rhead{Israel Fermín Montilla}
\lfoot{}
\cfoot{\thepage}
\rfoot{}
\renewcommand{\headrulewidth}{0.4pt}
\renewcommand{\footrulewidth}{0.4pt}

\begin{document}
\lhead{Índice}
\tableofcontents

\newpage

\section{Sinopsis}
\lhead{Sinopsis}
El presente informe, describe todos los detalles de la pasantía realizada por el Br. Israel Fermín Montilla en la empresa Vauxoo, desarrollando un Módulo para la herramienta de Planificación de Recursos Empresariales (ERP) llamada OpenERP, utilizando OpenObject como marco de trabajo y el lenguaje de programación Python, para la empresa mexicana Clima Perfecto (Cliper), la cual se dedica a proveer servicio de Mantenimiento e Instalación de equipos de Aire Acondicionado y Refrigeración, a través de contratos de póliza. El módulo desarrollado, debía soportar el proceso de facturación automática para dichos contratos.

El desarrollo del módulo surge de la necesidad en Cliper de cambiar su actual sistema ERP, el cual es un desarrollo interno basado en SQL Server 2005. El modelo de datos usado por el sistema antiguo será mostrado en el desarrollo de este informe. Este sistema, sólo provee información acerca de las pólizas activas mas no automatiza los procesos como tal. Con la migración a OpenERP, de busca mejorar el estado actual en cuanto a Sistemas Administrativos en Cliper, mediante la automatización del sistema de contabilidad, administración de recursos humanos y gestión automática de pólizas de mantenimiento de aires acondicionados, si bien la situación no se puede considerar ``mala" o ``deficiente" en cuanto a tecnología, pues si existía un sistema para gestionar la información de clientes, proveedores, personal y contratos, esta se podía mejorar mediante la automatización de procesos (o subprocesos) críticos de la empresa y esto es exactamente lo que se desea lograr a través de OpenERP.

En este informe se describirá todo el desarrollo del módulo de gestión y facturación automática para pólizas de mantenimiento de aires acondicionados y equipos de refrigeración, desde el comienzo, hasta la entrega final del módulo. 

\newpage
\section{Planteamiento del Problema}
\lhead{Planteamiento del Problema}
La situación actual de Cliper, en cuanto a sistemas administrativos, no puede decirse que era mala o deficiente, sino más bien regular y mejorable, pues efectivamente existe un sistema para gestionar Proveedores, Clientes, Contratos, Equipos y todas las entidades que es necesario controlar para el buen funcionamiento del negocio de Cliper. El sistema está basado en Microsoft SQL Server 2005, lo cual significa que únicamente puede correr sobre Sistema Operativo Windows, lo que, además, implica el pago de ciertas licencias para poder utilizar el software de manera legal. También, el sistema fue producto de un desarrollo interno de la empresa, lo cual, si bien garantiza que se adapte bastante bien al esquema de negocio que maneja Cliper, resulta difícil la escalabilidad y la continuidad del proyecto pues, sólo una persona, conoce a profundidad el trabajo realizado y el funcionamiento del sistema.

Lo que se puede concluir de la situación actual es que más temprano que tarde, haría falta escalar el sistema ya que Cliper poco a poco ha ido ganando cada vez más clientes y, además, clientes grandes, sólo para tener una idea, Cliper realiza mantenimiento a los aires acondicionados de TELMEX, que es la compañía de telefonía más grande de México, también a Telefónica México, entre otros clientes empresariales de gran importancia. Escalar el sistema actual representa costos que la empresa debe asumir en contratar personal capacitado para extender el sistema actual, el cual, como se dijo anteriormente, sólo una persona en la empresa lo conoce técnicamente a profundidad. 

OpenERP es un sistema de gestión empresarial y contable de código abierto, disponible de manera gratuita en internet y en el que trabajan cientos de desarrolladores a nivel mundial, lo que garantiza por un lado estabilidad y escalabilidad, pues no es sólo una persona en el mundo quien conoce la herramienta técnicamente. Además, al ser de código abierto, garantiza adaptabilidad y una mayor transparencia en lo que es capaz de hacer la herramienta pues se tiene acceso al código fuente, y al estar disponible en internet, ahorra costos de licenciamiento en los que se incurre al utilizar tecnología basada en software privativo, es por ello que se planteó la opción de implementar la solución final utilizando OpenERP como plataforma ya que, al estar desarrollado en Python, también sigue la misma filosofía modular para ser extendido funcionalmente por lo que desarrollar módulos que añadan funcionalidad a OpenERP según las necesidades de negocio de un cliente en particular, resulta relativamente fácil. Mediante la implementación de OpenERP, se busca automatizar el proceso de facturación de contratos de mantenimiento, además de resolver los problemas de escalabilidad del sistema actual, cambiándolo por uno más estándar.

\section{Objetivos}
\subsection{Objetivo General}
\begin{itemize}
\item Desarrollar un Sistema de Gestión para Pólizas de Mantenimiento de Equipos de Refrigeración utilizando el Framework OpenObject
\end{itemize}

\subsection{Objetivos Específicos}
\begin{itemize}
\item Analizar el modelo de datos actual y modificarlo para aprovechar los modelos del Framework.
\item Adaptar los modelos del Framework a las necesidades del proyecto.
\item Crear los modelos nuevos, particulares del proyecto, para la extensión del Framework.
\item Generar la lógica para la facturación automatizada a partir del Sistema de Gestión de Pólizas.
\item Gestionar el esquema de Costos con Contabilidad Analítica.
\item Realizar la migración de los datos al nuevo modelo.
\item Generar los reportes y formatos necesarios para el análisis de los datos del sistema.
\end{itemize}
\newpage

\section{Descripción de la Empresa}
\lhead{Descripción de la Empresa}
En septiembre de 2009, Vauxoo se convirtió en el segundo partner oficial de OpenERP a través de una certificación Silver de todo el equipo de desarrollo de la herramienta.

Desde Septiembre de 2010 el crecimiento exponencial que tuvimos nos ha permitido ser una empresa dedicada a soluciones ERP de código Abierto absolutamente con OpenERP como plataforma principal de trabajo, es por esto que nuestro equipo que antes era solo un departamento en una empresa con múltiples líneas de negocio (Netquatro), se ha independizado para ser solamente especialistas en OpenERP, y dedicar el 100\% de nuestra plataforma de servicios al soporte a ésta herramienta, continuamos manteniendo, mejorando y certificando las localizaciones Venezolana, Mexicana y Colombiana, y esperando seguir aportando a todas las localizaciones de Latinoamérica como Bolivia y Panamá donde esperamos nuestros aportes sigan siendo consistentes, y convertir a OpenERP en el ERP de referencia a nivel Latinoamericano y a Vauxoo como la empresa líder en servicios relacionados a Soporte, Coaching, Entrenamientos y desarrollos de módulos legales, operativos y funcionales para el mercado latinoamericano.

Dentro de nuestra visión de mercado y negocios creemos que Latinoamérica está tendiendo a implementar cada vez de forma más común herramientas de Software Libre, por tal motivo creemos fielmente en el modelo de ayuda y colaboración a todos esos nuevos partners para que podamos compartir nuestra experiencia y de ésta manera, ayudarlos a crecer tal cual como crecimos nosotros en éste espacio geográfico, le ofrecemos servicios de Coaching, Guía de inicio de proyectos y estimación de propuestas, análisis de desarrollos para localizaciones, ajustes de las mismas, aprovechar eficiente de los servicios que presta OpenERP, S.A. comprender el modelo de negocios de la mano del editor, resolución de problemas legales, fiscales y operativos entre muchas otras áreas manejables o desarrollables por OpenERP.

Desde Marzo de 2011 Vauxoo con su CEO Nhomar Hernández se han convertido en los primeros CTP (Certified Training partners) de Latinoamérica permitiendo de esta manera realizar entrenamientos de la mano de OpenERP asegurando la mayor calidad y la ya que el contenido de los mismos es desarrollado y constantemente actualizado por el Editor y tropicalizado y traducido por el equipo de desarrolladores del mayor número de módulos libres en OpenERP en y para Latinoamérica, Vauxoo.

Permítenos ayudarte en tu implementación, soportarte en la planificación y procesos y de esta manera con nuestra filosofía abierta, de desarrollo transparente, ágil, libre, eficaz, eficiente y efectivo lograremos en conjunto construir el Mejor ERP del Mundo y asegurar el éxito.

De esta manera nos definimos como una empresa especializada en soluciones libres y de código abierto que busca la excelencia en el servicio prestado a sus clientes.

\newpage

\section{Metodología Empleada}
\lhead{Metodología Empleada}
La empresa Vauxoo, implementa una metodología de desarrollo bajo el esquema del Desarrollo Ágil, las metodologías ágiles son una forma novedosa de desarrollar software pues son metodologías que no pretenden predecir todo lo que va a ocurrir durante el desarrollo de un proyecto sino que, por el contrario, están diseñadas para adaptarse a los cambios lo mejor posible. Los principios del desarrollo ágil fueron enunciados por Kent Beck en el año 2001, en un documento llamado ``El Manifiesto Ágil" (The Agile Manifesto) el cual, se cita a continuación:

``Estamos descubriendo nuevas maneras de desarrollar software tanto por nuestra propia experiencia como ayudando a terceros. A través de esta experiencia hemos aprendido a valorar:

\begin{itemize}
\item \textbf{Individuos e interacciones} sobre procesos y herramientas.
\item \textbf{Software que funciona} sobre documentación exhaustiva.
\item \textbf{Colaboración con el cliente} sobre negociación de contratos.
\item \textbf{Responder ante el cambio} sobre el seguimiento de un plan.
\end{itemize}

Esto es, aunque los elementos a la derecha tienen valor, nosotros valoramos por encima de ellos a los que están a la izquierda".

Existes varias metodologías enfocadas al esquema ágil, Vauxoo implementa Scrum, la cual se describe a continuación:

\subsection{SCRUM}

SCRUM es una metodología creada por Jeff Sutherland y su equipo de desarrollo a principios de la década de 1990 (Pressman, 2010). Los principios de SCRUM están enmarcados dentro del Manifiesto Ágil y es un proceso que lleva el Desarrollo de Software a través de las siguientes actividades: requerimientos, análisis, diseño, evolución y entrega. Cada una de esas actividades son realizadas dentro de un patrón de trabajo llamado Sprint, todo el trabajo realizado dentro de un Sprint es adaptado al problema y frecuentemente modificado por el equipo de desarrollo a medida que las condiciones van cambiando.

SCRUM hace énfasis en la utilización de procesos de software que son efectivos en proyectos con tiempos cortos de entrega y requerimientos cambiantes. Esos procesos, en general, definen dos grandes actividades de desarrollo:

\begin{itemize}
\item \textbf{Backlog:} el backlog, constituye una lista priorizada de requerimientos que agregan valor de negocio al producto, estos requerimientos pueden ser agregados en cualquier momento y, de esta manera, se introducen los cambios en el proyecto (Pressman, 2010). El backlog puede ser, además, modificado en cualquier momento para adaptar las prioridades a los cambios del negocio.
\item \textbf{Sprints:} los Sprints constituyen paquetes de trabajo que son necesarios para desarrollar un requerimiento o un conjunto de ellos [14]. Los cambios no pueden ser introducidos dentro de un Sprint, de esta manera se asegura que el trabajo que se realiza es estable, pues los requerimientos que se seleccionan para ser desarrollados en un Sprint ya deben estar definidos y se debe tener la certeza de que, en caso de cambiar, será manejable.
\item \textbf{Scrum Meetings:} son reuniones cortas que, usualmente, se realizan todos los días durante un sprint (Pressman, 2010). Durante los Scrum Meetings se responden a tres preguntas básicas:
\begin{itemize}
\item ¿Qué has hecho desde la última reunión?.
\item ¿Cuáles obstáculos has encontrado?.
\item ¿Cuál es tu planificación hasta la próxima reunión?.
\end{itemize}
\item \textbf{Demos:} se van entregando los resultados de las funcionalidades desarrolladas al cliente para que puedan ser evaluados (Pressman, 2010). De esta manera, se va entregando Software Listo y Funcional que agrega valor al negocio del cliente en cada iteración.
\end{itemize}

De esta manera, SCRUM permite que los equipos trabajen de manera eficiente y estable en proyectos en los que la incertidumbre siempre está presente, además, resulta ideal para proyectos de pasantía ya que el desarrollador está en constante contacto con el cliente, además de que el tutor empresarial, lleva control de los tópicos que han detenido al pasante durante el desarrollo para darle soporte y guiarlo para resolver lo más pronto posible.

\section{Desarrollo}
\lhead{Desarrollo}
Previo al desarrollo del proyecto que se referencia en este informe, el pasante ya llevaba alrededor de un mes trabajando para Vauxoo, por lo que ya tenía dominio básico de Python como lenguaje de programación, OpenObject como RAD Framework y OpenERP como herramienta, por ello, realizar una inducción durante el período de ocho semanas de pasantía resultó innecesario

El desarrollo del proyecto se dividió en seis sprints de duración variable, tal como fue especificado en la Propuesta de Pasantía, con ``Scrum Meetings" al final de cada uno de los Sprints y una reunión inicial para explicar los requerimientos básicos del proyecto. A continuación se expone, nuevamente, el cronograma de trabajo presentado en el documento de propuesta de pasantía aprobado por la Escuela de Ingeniería Informática de la Universidad Católica Andrés Bello:

\begin{center}
    \begin{tabular}{ | p{5cm} | p{9cm} | }
        \hline
        \textbf{Período} & \textbf{Actividad} \\ \hline
        18/04/2011 – 29/04/2011 & Análisis e implementación de los modelos de datos. \\ \hline
        02/05/2011 – 06/05/2011 & Migración de los datos. \\ \hline
        09/05/2011 – 13/05/2011 & Implementación de la Facturación Automática. \\ \hline
        16/05/2011 – 20/05/2011 & Implementación del esquema de costos. \\ \hline
        23/05/2011 – 27/05/2011 & Generación de los reportes y formatos necesarios \\ \hline
        30/05/2011 – 10/06/2011 & Pruebas y reparación de bugs \\ \hline
    \end{tabular}
\end{center}

Respecto a las pruebas y reparación de bugs, fue una actividad que debió realizarse a lo largo del desarrollo debido a que la metodología que se aplicó era Iterativa e Incremental, por lo que en cada iteración debía probarse el entregable y reparar los errores.

\subsection{Primer Sprint: Análisis e implementación de los modelos de datos}
Como se indicó al inicio, Cliper ya contaba con un sistema implementado por lo que resulta lógico pensar que ya existía un modelo de datos implantado para gestionar y persistir todos los objetos de negocio necesarios para el funcionamiento de la empresa. Este modelo de datos, estaba implementado sobre Microsoft SQL Server 2005 y en el Anexo 1 puede observarse el diagrama provisto por SQL Server para los objetos de negocio que se relacionan con los Contratos de Pólizas de Mantenimiento de Equipos.

OpenObject provee unos modelos de datos por defecto que pueden ser extendidos para soportar las necesidades de información de un negocio particular en caso de que sea necesario, también permite la posibilidad de crear nuevos modelos de datos si alguno de los objetos de negocio no son compatibles o parecidos con los modelos por defecto de OpenObject. Además, siendo OpenObject un Stack Framework, provee Mapeo Objeto-Relacional (ORM) a través de OSV, que proporciona toda una plataforma para relacionar clases y objetos de dominio con estructuras a nivel de base de dato para hacerlas persistir. Durante este Sprint, todas las tablas implementadas en SQL Server 2005, fueron migrados a clases de dominio de OSV, analizando también el nivel de normalización del modelo de datos y realizando algunos ajustes para evitar duplicidad en la información y eliminar la existencia de atributos multivaluados. En el Anexo 2 puede observarse el nuevo modelo de datos basado en OpenObject. A continuación, se describe cuales de las tablas implementadas en SQL Server 2005 para el sistema anterior tienen correspondencia con alguno de los Modelos por defecto de OpenObject y además, cuales fueron implementados desde cero, ya que no existe modelo OpenObject por defecto.

A continuación se presenta una tabla con los modelos extendidos y creados, según el esquema de datos anterior:
\begin{center}
    \begin{tabular}{ | p{5cm} | p{5cm} | p{5cm} | }
        \hline
        \textbf{Modelo Anterior} & \textbf{Modelo Nuevo} & \textbf{Extendido} \\ \hline
        Viático & hr.expense & Si \\ \hline
        Deptos & res.users & Si \\ \hline
        Preventivo & project.project & Si \\ \hline
        Equipo & policy.equipment & No \\ \hline
        ContratoPoliza & policy.contract & No \\ \hline
        Vehiculo & policy.vehicle & No \\ \hline
    \end{tabular}
\end{center}

La tabla anterior presenta los modelos que extendidos, es decir, que fueron sustituidos por clases por defecto de OpenObject a las que se le agregaron atributos para hacer que se ajustaran al esquema de negocios de Cliper y los nuevos, es decir, los que fueron creados desde cero por no contar con una clase en OpenObject que permitiera gestionar conceptos similares.

En el diagrama mostrado en el Anexo 1, que corresponde con el esquema de base de datos anterior, provisto por la herramienta de diagramas de SQL Server 2005, de observan varias tablas que no aparecen representadas entre los modelos citados anteriormente. Estas son:
\begin{itemize}
    \item \textbf{DetViatico:} esta tabla, corresponde líneas de detalle del viático que se asignó a algún empleado. Entre los modelos extendidos, se observa que la tabla Viatico, fue sustituida por el modelo hr.expense que, automáticamente, también gestiona estos detalles.
    \item \textbf{CGasto, CG y ConceptoCG:} estas tres tablas del esquema de datos anterior, sirven para gestionar gastos realizados durante la reparación o mantenimiento de los equipos y que deben ser facturados al cliente o incluidos en una facturación de póliza. Para el registro en sistema de las facturas, se utilizaron los modelos account.invoice y account.invoice.line. Estos gastos que deben ser facturados al cliente, se manejan como líneas de factura.
    \item \textbf{EquipoTecnico:} no aparece en el nuevo esquema de datos pues se trata de una tabla intersección para romper una relación de tipo muchos a muchos existente entre los técnicos de la empresa y los equipos que están asegurados bajo un contrato de póliza pues, un técnico puede tener muchos equipos a su cargo y, a su vez, un equipo puede ser atendido por varios técnicos. Esto se resolvió con un campo de tipo many2many (provisto por OpenObject a través del API de OSV) que relacione el modelo policy.equipment con el modelo por defecto de OpenObject para Gestión de Empleados hr.employee. Como a través de este modelo se gestionan todos los empleados de Cliper, es necesario definir un dominio a la hora de asignar un empleado a un equipo para, de esta manera, restringir que el empleado sea de tipo ``Técnico".
    \item \textbf{ContratoTecnico:} no aparece en el nuevo esquema de datos pues se trata de una tabla intersección entre ContratoPoliza y los técnicos de la empresa, rompiendo, nuevamente, una relación muchos a muchos. Esto se resolvió igual que el ítem anterior, con un campo many2many para relacionar a los técnicos asignados para atender una póliza a través del modelo hr.employee, con los contratos de póliza, a través del modelo policy.contract.
\end{itemize}

De la misma manera, el manejo de clientes y proveedores se realiza a través del modelo por defecto de OpenObject res.partner, que fue diseñado para este fin.

También, luego de analizar el esquema de datos anterior, algunos atributos de varias entidades fueron migrados como tablas maestras de configuración pues pueden asumir diversos valores no predecibles, es decir, es un dominio acotado pero configurado por el cliente. De esta manera se busca evitar la repetición de un mismo valor escrito de manera diferente en varios registros. A continuación, se enumeran estos casos:
\begin{itemize}
    \item El atributo TipodeEquipo de la tabla Equipo del esquema de datos anterior, utilizado para clasificar cada equipo de Aire Acondicionado según su tipo, fue migrado como el modelo policy.equipment.type, que cumple el mismo fin.
    \item El atributo ServicioA de la tabla Equipo del esquema de datos anterior, utilizado para conocer el tipo de servicio que presta cada equipo de Aire Acondicionado, fue migrado como el modelo policy.equipment.service.type, que cumple el mismo fin.
    \item Los atributos ClaveArea, ClaveSubArea y ClaveDivision, presentes en varias tablas del esquema de datos anterior, fueron migrados a un modelo recursivo llamado policy.areas, que contiene un atributo ``tipo" para poder conocer si se trata de un área, una sub-área o una división, al ser recursivo, este modelo permitirá también conocer la jerarquía de localizaciones.
    \item El atributo Tipo, presente en la tabla Preventivo del modelo de datos anterior, utilizado para conocer el tipo de mantenimiento que se realiza a un equipo de Aire Acondicionado, fue migrado como el modelo project.project.type, que cumple el mismo fin.
    \item El atributo Cobertura, presente en la tabla ContratoTecnico del esquema de datos anterior, utilizado para conocer el tipo de cobertura del contrato de Póliza de Mantenimiento, fue migrado al modelo policy.contracto.coverage, que cumple el mismo fin.
    \item El atributo TipoPago, presente en la tabla ContratoPoliza del esquema de datos anterior, utilizado para conocer la frecuencia de pago para un contrato dado, fue migrado al modelo policy.payment.type, utilizado para el mismo fin.
\end{itemize}

\subsection{Segundo Sprint: Migración de los Datos}

Para cumplir con esta parte del proyecto, fue necesario hacer uso de diversas herramientas para exportar la información de la base de datos anterior e importarla al nuevo modelo de datos creado durante el primer sprint.

OpenERP permite que los módulos, al ser instalados, carguen registros referentes a los modelos de datos creados por el mismo, estos modelos de datos son, al final, tablas a nivel de base de datos. Estos registros deben estar serializados en formato XML para que el módulo pueda cargarlos al ser instalado. Para que OpenERP sepa dónde buscar esos datos y cargarlos, esos archivos con datos iniciales deben estar referenciados en el descriptor OpenERP del módulo, el cual es el archivo \_\_terp\_\_.py.

Debido a que el requerimiento que se atendió en este sprint fue la necesidad de que la información anterior estuviera presente en el nuevo sistema, debía importarse todos los datos vía XML como datos iniciales del módulo. Para ello, luego de explorar las opciones ofrecidas por Microsoft SQL Server, se siguió el siguiente procedimiento:
\begin{enumerate}
    \item Por cada modelo OpenERP, se construyó una consulta SQL para extraer los campos necesarios para completar la información requerida.
    \item Se recurrió a la opción ``Exportar datos utilizando una consulta SQL" para obtener un archivo de Microsoft Excel con los registros resultantes.
    \item Utilizando OpenOffice.org, una suite ofimática libre incluida en la gran mayoría de las distribuciones de Linux, se convirtieron esos archivos xls a archivos separados por caracteres (csv), donde el caracter separador era una coma.
    \item Utilizando los módulos de Python csv y ElementTree, diseñados para procesar, leer y escribir archivos csv y XML respectivamente, se procedió a escribir un script que leyera los archivos csv y los convirtiera a formato XML, siguiendo las especificaciones para archivos de carga de datos de OpenERP, también respetando el estándar ISO para las fechas (YYYY-MM-DD), convirtiendo las ocurrencias que estuvieran fuera de dicho estándar y, además, ajustando la codificación de caracteres a la implementada en la base de datos (UTF-8).
    \item Se produjo un archivo de inicialización de datos por cada modelo y se le hizo referencia en el \_\_terp\_\_.py para que fuera cargado por OpenERP al instalar el módulo.
\end{enumerate}

Durante este sprint, debido a la terminación temprana de las actividades, se empleó el tiempo también para atender algunas incidencias que debían ser solucionadas para poder implementar la facturación automática, estas incidencias no estaban dentro del alcance del proyecto de pasantía, por lo que no serán descritas en este informe.

\subsection{Tercer Sprint: Implementación de la Facturación Automática}
El requerimiento a ser atendido en este sprint fue la generación automática de facturas para los contratos de póliza de manera mensual y sin intervención humana en el proceso. Esto se logra mediante cambios de estado del documento, desde ``Borrador" es decir, cuando es creado, hasta ``Facturado", que es cuando efectivamente se emite la factura. Usualmente el flujo seguirá un ritmo normal, cambiando de estado periódicamente y generando documentos nuevos a menos que ocurra una anomalía, en ese caso un humano debe detener el proceso y realizar las modificaciones o anotaciones según sea el caso.

Desde el punto de vista administrativo, el documento factura tiene cinco estados descritos a continuación:
\begin{enumerate}
    \item \textbf{Borrador:} es el estado por defecto cuando el documento ha sido creado.
    \item \textbf{En Ejecución:} cuando el proceso que creó la factura está siendo realizado.
    \item \textbf{Pendiente por Facturar:} cuando el proceso que creó la factura finalizó, pero aún no se emite el documento.
    \item \textbf{Facturado:} cuando se emite el documento.
    \item \textbf{Cancelado:} cuando por alguna anomalía en el proceso real, debe ser interrumpida la generación automática de facturas.
\end{enumerate}
Técnicamente, la implementación de esta característica del sistema se realizó en el modelo policy.contract, uno de los modelos desarrollados desde cero para este módulo, ya que es a partir de un contrato de póliza desde donde se generan las facturas automáticas cada período determinado. Esta característica fue entregada a manera de prototipo funcional pues, los cambios de estado, deben darse de manera automática dependiendo de ciertas condiciones dadas por el modelo de negocios de Cliper, estas condiciones no fueron especificadas por el cliente, por lo que, por los momentos, la facturación es de manera semiautomática, se acordó tratar la implementación de las condiciones como una incidencia posteriormente.

Para desarrollar la Facturación Automática de contratos de póliza de mantenimiento, se realizaron las siguientes actividades:
\begin{enumerate}
    \item Se agregó un botón en la vista del modelo policy.contract para iniciar dar inicio al proceso de facturación.
    \item Se agregaron botones para el cambio de estado de la factura. Estos botones son visibles dependiendo de en cuál estado de los especificados anteriormente se encuentra el documento.
    \item Se escribió en el modelo policy.contract el método que dispara cada uno de los botones, estos métodos se describen a continuación:
    \begin{itemize}
        \item \textbf{do\_invoice:} es el método que dispara la generación de la factura a partir del contrato de póliza, toma todos los datos del contrato y genera la factura usándolos como punto de partida, busca la información de los productos y/o servicios a ser facturados para armar las líneas de factura (account.invoice.line), los ratos referentes al cliente en el modelo res.partner y finalmente, genera un objeto factura (account.invoice) que corresponde al documento que se puede imprimir.
        \item \textbf{to\_draft:} regresa una factura a estado borrador, puede hacerse sólo en estado ``Pendiente por Facturar" o ``En ejecución", por lo que únicamente es visible en esos estados.
        \item \textbf{to\_excecuting:} marca una factura como ``En Ejecución".
        \item \textbf{to\_pending:} marca una factura como ``Pendiente por Facturar".
        \item \textbf{to\_invoiced:} marca una factura como ``Facturado", una vez en este estado no puede modificarse.
        \item \textbf{to\_calceled:} cancela el proceso de facturación automática.
    \end{itemize}
    \item Siguiendo el principio ``Open-Close" del desarrollo de software, que establece que una vez terminada la implementación de una clase, por ejemplo, ésta debe quedar ``Cerrada para la modificación", lo que quiere decir que ese código que se escribió no debería ser cambiado, y ``Abierta para la extensión", es decir, que puede ser heredada y hacer sobre-escritura o sobrecarga de métodos. Se escribió un par de métodos en blanco para ser extendidos posteriormente, el objetivo de estos métodos es que sean heredados y sobreescritos por otro módulo, estos métodos son para generar automáticamente la información que se colocará en los comentarios de las líneas de factura y de la factura como tal. 
\end{enumerate}

En un punto posterior del ciclo de vida de este proyecto, se utilizará el motor de flujos de OpenObject para implementar las condiciones bajo las cuales se dará el cambio de estado de una factura determinada.

\subsection{Cuarto Sprint: Implementación del Esquema de Costos}
Esta tarea fue más de configuración que de desarrollo como tal, se debió estudiar el esquema de costos implementado en el sistema anterior y migrarlo a OpenERP a través del módulo account y el módulo account.analytic, que son los que controlan todo lo referente a contabilidad y contabilidad analítica, fue necesario migrar el plan de cuentas de costos al modelo account.account de OpenObject, configurar el módulo para el sistema americano de contabilidad y OpenERP se encarga de realizar los asientos contables en las cuentas correspondientes cada vez que se lleve a cabo una transacción.

\subsection{Quinto Sprint: Generación de Reportes y Formatos}
Para la fecha de la visita del Tutor Académico, la Prof. Rosaura Paladino, no había surgido la necesidad de implementar un reporte impreso más allá de los que incluye OpenERP por defecto. Sin embargo, el tiempo destinado para esta actividad fue invertido en atender incidencias fuera del alcance de este proyecto de pasantía, pero que fueron solicitadas por Cliper. Estas incidencias atendían a optimización de procesos y atención a bugs fuera del módulo de gestión de pólizas de mantenimiento de equipos de aire acondicionado.

\subsection{Sexto Sprint: Pruebas y Reparación de Bugs}
Debido a la naturaleza de la metodología empleada, el contacto con el cliente es constante ya que el mismo es considerado parte del equipo de desarrollo, la cantidad de bugs durante la ejecución del proyecto fue mínima y, la mayoría, no eran críticos y podían corregirse sobre la marcha. En esta iteración, sólo se corrigieron dos errores de programación de mayor índole:
\begin{itemize}
    \item Python, al igual que muchos lenguajes de programación, tiene ciertas limitaciones en cuanto al manejo de números de punto flotante (float) debido a la precisión que debe manejar. OpenERP sólo necesita dos o tres decimales, por lo que los números decimales debían redondearse para evitar errores dentro del sistema.
    \item Cuando se realizan operaciones en moneda extranjera, debe tomarse en cuenta un factor de paridad cambiaria. Cliper, factura en pesos mexicanos y en dólares americanos, por lo que esta característica debió ser incluida en esta etapa.
\end{itemize}

\newpage
\section{Resultados}
\lhead{Resultados}
Al finalizar el período establecido para el desarrollo del Módulo de Gestión de Pólizas de Mantenimiento de Aires Acondicionados, se obtuvo un software totalmente funcional en algunos aspectos y prototípico/demostrativo en otros. Gracias a la naturaleza Iterativa e Incremental de la metodología aplicada, las secciones del proyecto que eran culminadas, podían pasarse a un entorno de producción para ser sometidas a condiciones reales, por lo que muchas secciones del módulo, se encuentran ya en el ambiente de producción de Cliper.

Haciendo un recuento de los objetivos de la pasantía, se pueden resumir los resultados de la siguiente manera:
\begin{itemize}
    \item \textbf{Análisis e implementación de los modelos de datos:} Completado y funcionando en ambiente de Producción.
    \item \textbf{Migración de los datos:} Completado e instalado junto con la instancia del módulo.
    \item \textbf{Implementación de la facturación automática:} Completado a manera de prototipo debido a que las reglas de negocio no fueron especificadas a tiempo con claridad, se construyó esta característica pensando en la inclusión posterior de las reglas faltantes en otra iteración.
    \item \textbf{Generación de reportes y formatos:} No fue necesario durante el tiempo de ejecución de la parte del proyecto que se tomó como Proyecto de Pasantía.
    \item \textbf{Pruebas y reparación de bugs:} Satisfactorio, no se registró ningún bug crítico que comprometiera el desarrollo del módulo o la seguridad del sistema. La cantidad de errores de programación fue mínima.
\end{itemize}

A manera informativa, ya que escapa al alcance de lo que se planteó en principio como Proyecto de Pasantía, la característica de Paridad Cambiaria fue agregada y desarrollada como un módulo aparte, por lo que otro entregable producto de este proyecto es un módulo que permite configurar cuentas de ingreso y egreso por paridad cambiaria en cualquier moneda.

\newpage
\section{Conclusiones y Recomendaciones}
\lhead{Conclusiones y Recomendaciones}

OpenERP y su plataforma de desarrollo, OpenObject, son herramientas sumamente potentes para gestión empresarial y programación respectivamente. Gracias a la estructura modular de OpenERP, a la facilidad de traducción que proporciona y a su esquema libre y de código abierto, es posible extenderlo y adaptarlo a cualquier negocio, en cualquier lugar y por cualquier persona con conocimientos técnicos de programación. Por otra parte, OpenObject como herramienta de programación es sumamente potente, ya que provee un API ``Todo en uno" para el desarrollo rápido de aplicaciones, desde un ORM hasta un motor de flujos de trabajo, pasando obviamente por un motor de generación de vistas, también, gracias a lo intuitivo Python como lenguaje de programación, es posible programar o configurar prototipos semi-funcionales ``on the fly" para un cliente durante las entrevistas de análisis y levantamiento de requerimientos.

Debido a que OpenObject está diseñado utilizando el patrón de diseño MVC, mientras se está desarrollando el modelo, el programador, puede abstraerse de que hay una vista en alguna capa superior, también, gracias OSV, la herramienta ORM de OpenObject, el desarrollador puede abstraerse del motor de base de datos subyacente y concentrarse en la estructura que tendrá el modelo de datos, más allá de la implementación posterior y la persistencia a nivel de base de datos ya que estos tópicos son competencia del ORM, también, gracias a que OpenObject provee un motor para la generación de vistas GTK y Web, el desarrollador puede olvidarse de la manera como se va a presentar la información y concentrarse en qué información va a ser mostrada, lo que permite ahorrar tiempo y horas de investigación, ensayo y error y frustración a desarrolladores con poca experiencia en cuanto al diseño de interfaces gráficas de usuario.

Con todo lo expuesto anteriormente, puede observarse que la herramienta lleva a cabo prácticamente todo el trabajo, el desarrollador simplemente debe agregar la lógica y la ``inteligencia" de lo que va a hacer el módulo que está programando, sin embargo, para poder utilizar una herramienta de este tipo, es necesario tener muy claros y dominar los conceptos que está implementando para poder saber por qué la herramienta toma una decisión en un momento determinado o por qué implementa algún factor de una forma dada pues, muchas veces, una herramienta no es capaz de tomar la mejor decocción o de generar el código más optimizado para un caso determinado y corresponde al desarrollador (Ingeniero en Informática) llevar a cabo las correcciones pertinentes para mejorar el funcionamiento y el comportamiento del sistema que está desarrollando.

Una metodología iterativa e incremental como Scrum, la metodología implementada para el desarrollo del sistema, permite que el cliente pueda ver el avance del proyecto de primera mano, también, permite al equipo de desarrollo y al consultor a cargo tener más claras las reglas de negocio ya que el cliente forma parte del equipo y está disponible para cualquier consulta en cualquier momento. Sin embargo, es recomendable invertir algo más de tiempo en una etapa de análisis del negocio antes de pasar a la implementación, de manera que tanto el cliente como el equipo de desarrollo puedan tener bien claras las reglas de negocio, todo esto para evitar inconvenientes y retrasos como el de la característica de facturación automática de este proyecto que no pudo ser completada por falta de definición del requerimiento.

\newpage
\section{Bibliografía}
\lhead{Bibliografía}
\begin{itemize}
    \item Pressman, Roger. (2010). Software Engineering: a Practitioner's Approach. New York: McGraw Hill.
    \item Beck, Kent et al. Manifesto for Agile Software Development [Documento en línea]. Disponible: http://agilemanifesto.org/ [Consulta: 2011, Junio 22].
    \item OpenERP Comunity. Developer Book [Documento en línea]. Disponible: http://doc.openerp.com/v5.0/developer/index.html\#book-develop-link [Consulta: 2011, Junio, 22].
    \item OpenERP Comunity. OpenERP Tutorial [Documento en línea]. Disponible: http://doc.openerp.com/v5.0/book/index.html\#books-link [Consulta: 2011, Junio, 22].
    \item Chun, Wesley J. (2006). Core Python Programming. Prentice Hall.
    \item Saw, Zed. (2010). Learning Python the Hard Way [Documento en línea]. Disponible: http://learnpythonthehardway.org [Consulta: 2011, Junio, 22].
\end{itemize}

\end{document}