UNIVERSIDAD POLITÉCNICA SALESIANA

SEDE CUENCA

CARRERA DE COMPUTACIÓN

ANÁLISIS Y DESARROLLO DE UN SISTEMA WEB UTILIZANDO ODOO PARA LA

GESTIÓN DE ACTIVOS FIJOS DE LA UNIVERSIDAD POLITÉCNICA SALESIANA

Trabajo de titulación previo a la obtención del

título de Ingeniero en Ciencias de la Computación

AUTORES: BRYAM WILSON GUZMÁN CABRERA

ADRIÁN RODRIGO TENE GUAMÁN

TUTOR: ING. MAURICIO SERGIO ORTIZ OCHOA, MGS.

Cuenca - Ecuador

2022
 CERTIFICADO DE RESPONSABILIDAD Y AUTORÍA DEL TRABAJO DE

TITULACIÓN

Nosotros, Bryam Wilson Guzmán Cabrera con documento de identificación N° 0106786031 y

Adrián Rodrigo Tene Guamán con documento de identificación N° 0105609127; manifestamos

que:

Somos los autores y responsables del presente trabajo; y, autorizamos a que sin fines de lucro

la Universidad Politécnica Salesiana pueda usar, difundir, reproducir o publicar de manera total

o parcial el presente trabajo de titulación.

Cuenca, 22 de julio del 2022

Atentamente,

--------------------------------------- ------------------------------------
Bryam Wilson Guzmán Cabrera Adrián Rodrigo Tene Guamán
0106786031 0105609127
 CERTIFICADO DE CESIÓN DE DERECHOS DE AUTOR DEL TRABAJO DE

TITULACIÓN A LA UNIVERSIDAD POLITÉCNICA SALESIANA

Nosotros, Bryam Wilson Guzmán Cabrera con documento de identificación N° 0106786031 y

Adrián Rodrigo Tene Guamán con documento de identificación N° 0105609127, expresamos

nuestra voluntad y por medio del presente documento cedemos a la Universidad Politécnica

Salesiana la titularidad sobre los derechos patrimoniales en virtud de que somos autores del

Proyecto Técnico: “Análisis y desarrollo de un sistema web utilizando ODOO para la gestión

de activos fijos de la Universidad Politécnica Salesiana”, el cual ha sido desarrollado para optar

por el título de: Ingeniero en Ciencias de la Computación, en la Universidad Politécnica

Salesiana, quedando la Universidad facultada para ejercer plenamente los derechos cedidos

anteriormente.

En concordancia con lo manifestado, suscribimos este documento en el momento que hacemos

la entrega del trabajo final en formato digital a la Biblioteca de la Universidad Politécnica

Salesiana.

Cuenca, 22 de julio del 2022

Atentamente,

--------------------------------------- ------------------------------------
Bryam Wilson Guzmán Cabrera Adrián Rodrigo Tene Guamán
0106786031 0105609127
 CERTIFICADO DE DIRECCIÓN DEL TRABAJO DE TITULACIÓN

Yo, Mauricio Sergio Ortiz Ochoa con documento de identificación N° 0103667754, docente de

la Universidad Politécnica Salesiana, declaro que bajo mi tutoría fue desarrollado el trabajo de

titulación: ANÁLISIS Y DESARROLLO DE UN SISTEMA WEB UTILIZANDO ODOO

PARA LA GESTIÓN DE ACTIVOS FIJOS DE LA UNIVERSIDAD POLITÉCNICA

SALESIANA, realizado por Bryam Wilson Guzmán Cabrera con documento de identificación

N° 0106786031 y por Adrián Rodrigo Tene Guamán con documento de identificación N°

0105609127, obteniendo como resultado final el trabajo de titulación bajo la opción Proyecto

Técnico que cumple con todos los requisitos determinados por la Universidad Politécnica

Salesiana.

Cuenca, 22 de julio del 2022

Atentamente,

-----------------------------------------------
Ing. Mauricio Sergio Ortiz Ochoa. Mgs.
0103667754
Dedicatoria

Esta tesis va dedicada a mis padres Wilson Guzmán y Magaly Cabrera, que, a más de brindarme

todos los recursos necesarios para yo salir adelante y cumplir mis metas, a pesar de encontrarse

lejos, jamás me dejaron solo y me dieron todo el amor, cariño y apoyo cuando más lo necesitaba,

esto es por ellos y para ellos. Esto es para mi familia, entre ellos mi enamorada, quien, siempre

me ayudo en los peores momentos de mi vida y ha sido un pilar fundamental en mi crecimiento

profesional y personal, ha estado presente en cada etapa, y siempre me brindo su apoyo

incondicional

Bryam Wilson Guzmán Cabrera.

Esta Tesis va dedicada a mis padres Rodrigo Tene y María Inés Guamán, sin ellos no hubiese

logrado nada, Sus Bendiciones a Diario a lo largo de este camino, al trabajo de ustedes,

sacrificio paciencia y amor este trabajo es en honor a ustedes, también esto va para mis

hermanos Mauricio, Paúl y David, sin su apoyo no lo hubiera logrado, a mis sobrinos Leslie,

Mauricio y Milena, por todo el apoyo incondicional que fue fundamental para este logro.

Adrián Rodrigo Tene Guamán.

Agradecimientos

Agradezco a mis padres Wilson Guzmán y Magaly Cabrera por formarme como una persona

de principios y valores, por el amor incondicional que me brindaron, jamás me dejaron solo, y

aunque todo este tiempo se encontraron lejos, siempre velaron por mi bienestar y estuvieron

presentes en cada etapa de mi vida, gracias infinitas.

Bryam Wilson Guzmán Cabrera.

Agradezco a Dios por haberme dado una familia maravillosa, a mis padres Rodrigo y María

Inés, quienes siempre han creído en mí, por su apoyo incondicional, dándome ejemplo de

superación, humildad y que por su sacrificio hicieron posible este magnífico logro, Espero

siempre contar con su apoyo incondicional.

Adrián Rodrigo Tene Guamán.

Resumen

El presente proyecto tiene objetivo principal el análisis e implementación de un módulo que

permita la gestión de activos fijos mediante el uso del marco de trabajo que ofrece Odoo y las

tecnologías Api REST de Spring Framework como herramienta de integración con otros S.I

con el fin de automatizar la administración de los procesos que giran alrededor de los bienes.

El aplicativo web por realizar tiene como función principal la creación de activos fijos de

manera conjunta con sus parámetros, tipo de activo, tabla de amortización, etc. Permitirá la

generación de vistas dinámicas con diferentes tipos de parámetros y el uso de graficas

estadísticas como barras y pasteles para mejorar la experiencia de usuario y ser de utilidad en

análisis y presentación de resultados por el personal pertinente

También el módulo cuenta con una gestión de perfiles muy rigurosa que permitirá o restringirá

ciertas funcionalidades de acuerdo con el grupo de usuario y compañía a la que pertenezca, con

el objetivo de priorizar la integridad de la información debido a su alto grado de sensibilidad

El módulo maneja una arquitectura de dos capas, uno de los componentes es Odoo, que en su

marco de trabajo permite trabajar conjuntamente con la capa de presentación y la capa de lógica

de negocio, para ello provee características como las vistas y los modelos, en donde se realizará

el diseño de interfaces y las funcionalidades de procesos como el cálculo de la tabla de

depreciaciones de los bienes; en cuanto a la capa de datos, se cuenta por defecto con la única

base compatible hasta el momento con el ERP, PostgreSQL, la misma que permite el

almacenamiento de datos. Además, se adiciona una capa extra de la generación de servicios

web para la integración con otros sistemas mediante Spring boot

Palabras Claves

Odoo, Activos Fijos, ERP, Transferencia. Bajas, Parámetros, Depreciación, Python, Spring
Abstract

The main objective of this work is the development of a module that allows the management of

fixed assets using the framework offered by Odoo and the Api REST technologies of Spring

Framework as an integration tool with other Information Systems to automate the

administration of processes that revolve around assets.

The main function of the web application to be carried out is the creation of fixed assets together

with their parameters, type of asset, amortization table, etc. It will allow the generation of

dynamic views with different types of parameters and the use of statistical graphs such as bars

and pies to improve the user experience and help in the decision-making

The module also has a very rigorous profile management that will allow or restrict certain

functionalities according to the user group and company to which it belongs, in order to

guarantee the confidentiality and integrity of the information due to the high degree of

sensitivity and Importance of data for the educational establishment.

The module manages a two-tier architecture in terms of development, one of the components

is Odoo, which in its framework allows working together with the presentation layer and the

business logic layer, for this it provides features such as views and the models, where the design

of interfaces and the functionalities of processes will be carried out, such as the calculation of

the depreciation table of the assets; regarding the data layer, by default it has the only base

compatible up to now with the ERP, PostgreSQL, the same one that allows data storage. In

addition, an extra layer of web services generation is added for integration with other systems

through Spring boot

Keywords

Odoo, Fixed Assets, ERP, Transfer, Derecognition, Parameters, Depreciation, Python, Spring
 Índice de contenido.

Resumen ............................................................................................................................... 7

Abstract ................................................................................................................................ 8

1. Introducción ............................................................................................................. 15

2. Problema................................................................................................................... 17

2.1 Antecedentes ......................................................................................................... 17

2.2 Justificación .......................................................................................................... 17

2.3 Grupo Objetivo .................................................................................................... 18

3. Objetivos específicos y generales ............................................................................ 19

3.1 General .................................................................................................................. 19

3.2 Específicos ............................................................................................................. 19

4. Revisión de la literatura .......................................................................................... 20

4.1 ERP........................................................................................................................ 20

4.2 Activos Fijos ......................................................................................................... 20

4.3 Sistemas de Información ..................................................................................... 20

4.4 Patrón de diseño ................................................................................................... 21

4.5 DTO ....................................................................................................................... 21

4.6 Software de Administración de Proyectos (PMS) ............................................. 21

4.7 Herramientas de Desarrollo ................................................................................ 22

4.7.1 API REST ...................................................................................................... 22

 4.7.2 Odoo ............................................................................................................... 22

4.7.3 Spring Boot.................................................................................................... 23

4.8 Metodología de desarrollo Scrum....................................................................... 23

4.8.1 Product Owner .............................................................................................. 24

4.8.2 Scrum Master ................................................................................................ 24

4.8.3 Equipo de Desarrollo .................................................................................... 24

5. Marco metodológico ................................................................................................ 25

5.1 Propuesta de Solución.......................................................................................... 25

5.2 Metodología .......................................................................................................... 27

5.2.1 Roles Scrum: ................................................................................................. 28

5.2.2 Scrum Team: ................................................................................................. 28

5.3 Gestión tareas Scrum Team ................................................................................ 28

5.4 Descripción de actividades .................................................................................. 29

5.5 Sprints ................................................................................................................... 30

5.5.1 Sprint 1 (24/04/2022) .................................................................................... 31

5.5.2 Sprint 2 (05/05/2022) .................................................................................... 31

5.5.3 Sprint 3 (22/05/2022) .................................................................................... 32

5.5.4 Sprint 4 (26/06/2022) .................................................................................... 32

5.5.5 Sprint 5 (10/07/2022) .................................................................................... 32

6. Resultados................................................................................................................. 33

6.1 Especificación de Requerimientos ...................................................................... 33

 6.1.1 Requerimientos Funcionales ........................................................................ 33

6.1.2 Requerimientos de Interfaz ......................................................................... 39

6.2 Diseño .................................................................................................................... 45

6.2.1 Diagrama de componentes ........................................................................... 45

6.2.2 Modelo de datos ............................................................................................ 47

6.2.3 Diagrama de actividades .............................................................................. 50

6.3 Desarrollo.............................................................................................................. 55

6.3.1 Pruebas Funcionales y de Interfaz .............................................................. 55

6.3.2 Desarrollo código .......................................................................................... 65

6.3.3 Fase de aceptación ........................................................................................ 68

7. Cronograma ............................................................................................................. 73

8. Presupuesto .............................................................................................................. 77

9. Conclusiones ............................................................................................................. 78

10. Recomendaciones ..................................................................................................... 81

Referencias bibliográficas ................................................................................................. 82

Anexos ................................................................................................................................. 85
 Índice de Ilustraciones

Ilustración 1. Arquitectura Web. ........................................................................................ 25

Ilustración 2. Servicio Api Rest. .......................................................................................... 26

Ilustración 3. Conexión Módulo y Aplicación. ................................................................... 26

Ilustración 4. Tablero de Actividades. ................................................................................. 28

Ilustración 5. Diagrama de Componentes............................................................................ 46

Ilustración 6. Diagrama Entidad Relación 1. ....................................................................... 47

Ilustración 7. Diagrama Entidad Relación 2. ....................................................................... 48

Ilustración 8 Diagrama Entidad Relación 3. ........................................................................ 49

Ilustración 9. Diagrama de Actividades Registro de Activo Fijo. ....................................... 50

Ilustración 10. Diagrama de Actividades Creacion de Activos Fijos. ................................. 51

Ilustración 11. Diagrama de Actividades Registro de Activo Fijo 2. .................................. 52

Ilustración 12. Diagrama de Actividades Transferencia o Baja. ......................................... 53

Ilustración 13. Diagrama de Actividades Generar Reporte. ................................................ 54

Ilustración 14. Estructura del Proyecto. .............................................................................. 66

Ilustración 15. Lista de Archivos. ........................................................................................ 66

Ilustración 16. Repositorio GitHub. .................................................................................... 67

Ilustración 17. Pregunta 1. ................................................................................................... 68

Ilustración 18. Pregunta 2. ................................................................................................... 69

Ilustración 19. Pregunta 3. ................................................................................................... 70

Ilustración 20. Pregunta 4. ................................................................................................... 71

Ilustración 21. Pregunta 5. ................................................................................................... 71

 Índice de Tablas

Tabla 1. Objetivo Específico 1. ........................................................................................... 29

Tabla 2. Objetivo Específico 2. ........................................................................................... 30

Tabla 3. Objetivo Específico 3. ........................................................................................... 30

Tabla 4. Actividades Sprint 1. ............................................................................................. 31

Tabla 5. Actividades Sprint 2. ............................................................................................. 31

Tabla 6. Actividades Sprint 3. ............................................................................................ 32

Tabla 7. Actividades Sprint 4. ............................................................................................. 32

Tabla 8. Actividades Sprint 5. ............................................................................................. 32

Tabla 9. Cronograma de Actividades. ................................................................................. 73

Tabla 10. Presupuesto del Proyecto. .................................................................................... 77

 Índice de Anexos.

Anexo 1. Pantalla de Login. ................................................................................................ 85

Anexo 2. Estilos Login ........................................................................................................ 85

Anexo 3. Wizard Crear Activos. ......................................................................................... 86

Anexo 4. Grupos Filtros Activos Fijos. ............................................................................... 86

Anexo [Link] Histograma Activos Fijos. ....................................................................... 87

Anexo 6. Gráfico de Pasteles Activos Fijos. ....................................................................... 87

Anexo 7. Validar Transferencias. ........................................................................................ 88

Anexo 8. Baja Activo Fijo. .................................................................................................. 88

Anexo 9. Parámetros Reporte de Activos Fijos. .................................................................. 88

Anexo 10. Python Depreciación Automática. ..................................................................... 89

Anexo 11. Cuadre y Cierre de Activos Fijos. ...................................................................... 89

Anexo 12. Suma de Activos Fijos Activos. ......................................................................... 90

Anexo 13. Suma Activos Fijos Inactivos. ........................................................................... 90

1. Introducción

Los procesos contables de un establecimiento son de suma importancia y manejan un flujo

muy grande de datos con los diferentes tipos de transacciones que se pueden realizar en el

diario funcionamiento del negocio; para este fin se utiliza varias herramientas o medios, uno

de ellos son los activos fijos, que son bienes tangibles e intangibles que van desde un

escritorio hasta una supercomputadora; su principal objetivo es ser utilizado por el usuario

para el desarrollo de una tarea pequeña o de gran magnitud, también representa una parte

del patrimonio que posee una empresa, por lo tanto, es de muy alta prioridad tener una

herramienta que garantice la correcta gestión de los bienes y permita llevar un seguimiento

eficaz de cada uno de ellos.

Con el crecimiento de la tecnología y la creación de diferentes herramientas y marcos de

trabajo para la creación de aplicaciones y sistemas informáticos, el campo del desarrollo de

software es muy extenso y facilita la utilización de una herramienta distinta para cada área

y modelo de negocio, en este caso, Odoo es un software empresarial abierto destinado a la

contabilidad de pequeños y grandes negocios que permite la libre creación de módulos a

partir de una estructura que tiene sus bases muy asentadas y estables, gracias a su evolución

,la gran comunidad que se encuentra trabajando día a día en mejorarlo y la fácil adaptación

de un nuevo componente en el ERP, se convierte en el software ideal para el manejo contable

de una entidad comercial o financiera

En el presente trabajo de titulación se llevará a cabo el diseño y desarrollo de un módulo de

activos fijos para la institución educativa superior “Universidad Politécnica Salesiana”, con

el fin de automatizar los procesos de gestión de los bienes que posee el establecimiento,

haciendo uso del marco de trabajo que ofrece Odoo con lenguaje de programación Python,

15
y tecnologías de maquetación como HTML, CSS y JavaScript para la customización del

módulo en base a las características principales de la institución

Una de las características esenciales que ha de tener el aplicativo web, es que permitirá el

mantenimiento de los activos fijos del establecimiento, lo cual, facilitara la creación masiva

de bienes y su asignación de forma individual a cada trabajador de la compañía, cabe

recalcar, que Odoo ofrece un módulo de administración de empleados, el mismo que, ha de

servir como base para el mantenimiento del personal de trabajo y la concesión de cada uno

al bien creado con la utilización del módulo de activos fijos

La institución educativa cuenta con un Sistema Informático para la administración de sus

procesos, por lo tanto, se requiere relacionarlo con el módulo de Activo Fijos a desarrollar,

para ello se plantea la utilización del framework Springboot, que mediante el uso de

tecnologías Api REST, permite la producción de servicios web para la integración con otros

SI o servicios backend y será publicado en un servidor web del establecimiento con el fin

de relacionar el aplicativo web con el S.I de manera responsable por el personal autorizado

El aplicativo web tendrá una arquitectura con dos capas para el módulo de activos fijos, las

cuales tienen que ver con el software Odoo y la base de datos PostgreSQL respectivamente,

Odoo cuenta con un marco de trabajo establecido que permite realizar tanto presentación

como la lógica de negocio, así mismo, por motivos de integración antes mencionados, se ha

agregado una capa extra para la creación de servicios web que se comunica de manera

directa con el ERP

La última etapa del desarrollo será la validación de los requerimientos por parte del personal

financiero de la institución, por lo tanto, se ha de realizar pruebas funcionales que permitan

asentar el estado de aprobado a cabalidad de cumplir con cada detalle solicitado

16
2. Problema

En esta sección se va a hablar de la importancia del proyecto, así como, de la problemática

que ha dado origen para su desarrollo

2.1 Antecedentes

Hoy en día existen entidades que carecen de automatización en sus procesos

financieros, debido a la poca o nula información acerca de los beneficios que

conlleva tener una herramienta tecnológica que permita sistematizar sus actividades

de gestión de activos fijos; por lo que malgastan recursos en la realización de estos

procesos de forma mecánica y desorganizada. Por lo tanto, según (Hamidian &

Ospino, 2015) “se debe utilizar procedimientos operativos para maximizar la

eficiencia, información precisa de toda la empresa o institución”, bajo este concepto,

el proyecto a realizarse busca crear un sistema web que cumpla con la correcta

administración de activos fijos con el principal objetivo de agilizar y optimizar la

organización del sistema financiero de la Universidad Politécnica Salesiana

2.2 Justificación

Con la implementación del Módulo de Activos Fijos se estima marcar un hito en los

procesos de la universidad y crear un punto de inicio para la implementación de

nuevos módulos utilizando esta herramienta que tiene grandes ventajas como lo

declara el autor (Perdanakusuma, Dickson, & Puspitasari, 2020) “la personalización

de nuevos módulos en Odoo es fácil de implementar. así como, la integración con

los módulos de contabilidad, recursos humanos, inventario, otros, todo esto, gracias

a que es un software de código abierto y cuenta con una extensa comunidad de

desarrolladores en todo el mundo, que en cada versión se esmera por mejorar el

ERP”

17
 2.3 Grupo Objetivo

El módulo de Activos fijos inicialmente será enfocado para la célula de Contabilidad

de la Universidad Politécnica Salesiana, pero gracias a su fácil adaptación con otros

módulos del Software ERP Odoo, el CORE podría ser puesto en marcha en cualquier

tipo de empresa, y no necesariamente deberían tener el mismo giro de negocio que

el establecimiento

Después de exponer el problema y los argumentos a favor de la utilización de la herramienta

ODOO para resolver la problemática, se procede a presentar los objetivos del desarrollo del

módulo de activos fijo

18
3. Objetivos específicos y generales

A continuación, se enumera los objetivos del desarrollo del proyecto técnico, y cabe destacar

que cada uno de ellos, al finalizar, deberán ser resueltos con las metodologías de desarrollo

adecuadas

3.1 General

Analizar y desarrollar un sistema web utilizando ODOO para la gestión de activos

fijos de la Universidad Politécnica Salesiana

3.2 Específicos

• OE1. Estudiar y analizar fundamentos de software ERP Odoo, Spring boot

y el modelo de negocio del módulo de activos fijos del sistema financiero de

la Universidad Politécnica Salesiana

• OE2. Diseñar y desarrollar un sistema web utilizando ERP ODOO mediante

su integración con Springboot que permita la administración de activos fijos

de un sistema financiero con la finalidad de automatizar procesos contables

• OE3. Diseñar y realizar pruebas funcionales del sistema web

19
4. Revisión de la literatura

En la siguiente sección se hablará sobre los conceptos planteados durante el desarrollo del

proyecto.

4.1 ERP

“ERP es un sistema de clase mundial que involucra las mejores prácticas con

estándares de excelencia, y que la organización que adopte esta filosofía, podrá como

resultado obtener una reducción significativa de costos, un aumento de la

productividad, planificar y realizar la automatización de sus procesos, así como la

integración completa del negocio e incorporar las mejores prácticas mundiales de la

industria (Díaz, Gonzales, & C., 2005)”.

4.2 Activos Fijos

Según (MEIGS, 2016), un activo es “un recurso económico propiedad de la entidad

que se espera que rinda beneficios futuros a través de sus operaciones. Se menciona

que los activos fijos en una organización denotan la mayor parte del activo total, por

ejemplo, en una planta la instalación de esta y su valor representa el 60 o 70% de los

activos totales”.

4.3 Sistemas de Información

Según (O'Leary, Timothy, & Linda., 2008) un Sistema de información es “un

conjunto de componentes interrelacionados que recolectan (o recuperan), procesan,

almacenan y distribuyen información para apoyar la toma de decisiones y el control

de una organización. Además de apoyar la toma de decisiones, la coordinación y el

control, los sistemas de información también pueden ayudar a los gerentes y

20
trabajadores a analizar problemas, a visualizar asuntos complejos y a crear productos

nuevos”.

4.4 Patrón de diseño

Según (Johansen, 2006), “Un patrón de diseño es una plantilla de solución concebida

previamente para un problema específico.”. Así mismo existen una infinidad de

opciones que se pueden aplicar, al momento de diseñar un sistema, en este caso se

ha optado por DTO.

4.5 DTO

El patrón DTO, según (Sancho, 2020), “se centra en reducir el número de accesos

que se realizan a base de datos para solicitar información. Para ello se establecen una

serie de DTO que consistirán básicamente en objetos creados para almacenar

distintos campos de la base de datos dentro de sus atributos”.

4.6 Software de Administración de Proyectos (PMS)

Según (Wikipedia, 2020) PMS es “un término utilizado en la ingeniería de software

que cubre varios tipos de software, entre ellos el utilizado para la planificación de

proyectos, manejo y control de presupuesto, asignación de recursos, software para

colaboración, software para comunicación, manejo de la calidad y documentación o

administración de sistemas, los cuales son usados para manejar la complejidad que

conlleva un proyecto grande”; para el caso de la administración de tareas e

incidencias del equipo, se ha utilizado el software Trello, que es una de las

alternativas que podemos encontrar de PMS’s

21
4.7 Herramientas de Desarrollo

4.7.1 API REST

Según (IBM, 2021) API REST “es un conjunto de reglas que determinan

cómo las aplicaciones o los dispositivos pueden conectarse y comunicarse

entre sí. Un API REST es un API que se ajusta a los principios de diseño

de REST, un estilo de arquitectura también denominado transferencia de

estado representacional.”, de esta forma una aplicación tiene la

posibilidad de conectarse directamente con servicios internos o externos.

En el proyecto según (Vicente, 2019), “Se fundamenta en la construcción

de un sistema informático orientado a la web, utilizando la arquitectura

REST como base para la lógica de negocio y aplicación del software”.

4.7.2 Odoo

Según (OpenERP, 2021), “Odoo es un completo sistema de gestión

empresarial (ERP) de código abierto y sin coste de licencias que cubre las

necesidades de las áreas de: Contabilidad y Finanzas, Ventas, RRHH,

Compras, Proyectos, Almacenes (SGA), CRM y Fabricación entre otras,

este software permite la gestión empresarial de una empresa, la

arquitectura que maneja facilita la integración con otros productos para la

automatización en la toma de decisiones de una entidad empresarial, sin

importar la magnitud de la misma.”

En el proyecto de (Pavón & Baró, 2018) se menciona a ERP Odoo como

“una alternativa de desarrollo de un sistema para la reducción de ciclo de

cierre contable, aprovechando diversos módulos que se ofrece.”

22
 Según se menciona en el proyecto realizado por (Perdanakusuma,

Dickson, & Puspitasari, 2020), “Odoo ERP integra fácilmente con

módulos de contabilidad, recursos humanos e inventarios”

4.7.3 Spring Boot

Spring boot es un marco de trabajo basado en lenguaje de programación

Java, permite el desarrollo de servicios REST y trabaja con la arquitectura

MVC, que es una de las más utilizadas en cuanto al desarrollo (López, O.

G., & Vázquez, 2018); una gran ventaja es que ofrece un ambiente listo

para el desarrollo, evitando los inconvenientes y el tiempo que conlleva

configurar la aplicación. Además, se puede implementar tanto en

aplicaciones monolíticas como en arquitecturas de microservicios.

Mediante el proyecto (Haro, Guarda, & Peñaherrera, 2019) , se menciona

que Spring “es un framework de la plataforma de Java que provee soporte

para el desarrollo de aplicaciones Java ya que se encarga del manejo de la

infraestructura permitiendo que el desarrollador se enfoque en la

aplicación”

4.8 Metodología de desarrollo Scrum

“Scrum es una metodología ágil orientada al trabajo en equipo entre el cliente y

proveedor con el único fin de lograr la entrega de un producto de calidad en el

mercado (Trigas, 2018)”.

De acuerdo lo que menciona (Trigas, 2018), la metodología scrum está conformada

por la siguiente estructura:

23
4.8.1 Product Owner

“Es la persona que toma las decisiones, y es la que realmente conoce el

negocio del cliente y su visión del producto. Se encarga de escribir las

ideas del cliente y ordena por prioridad (Trigas, 2018)”.

4.8.2 Scrum Master

“Es el encargado de comprobar que el modelo y la metodología funciona.

Eliminará todos los inconvenientes que hagan que el proceso no fluya e

interactuara con el cliente y los gestores (Trigas, 2018)”.

4.8.3 Equipo de Desarrollo

“Suele ser un equipo pequeño de unas 5-9 personas, estas personas tienen

autoridad para organizar y tomar decisiones para lograr el objetivo

(Trigas, 2018)”

24
5. Marco metodológico

En este capítulo se va a detallar, una propuesta de solución para este proyecto.

5.1 Propuesta de Solución

En la ilustración 1 se va a presentar el modelo principal de la arquitectura del sistema

web, detallando cada parte del proceso de la implementación del proyecto:

Ilustración 1. Arquitectura Web.

La primera etapa va dedicada a estudiar los fundamentos de desarrollo del software

ERP Odoo, fundamento de programación del framework Springboot y el modelo de

negocio del proceso de activos fijos del Sistemas Transaccional del establecimiento,

para de esta manera sentar las bases del proyecto y clarificar cualquier idea ambigua

25
 Ilustración 2. Servicio Api Rest.

La Ilustración 2 presenta la segunda etapa del proyecto, la cual estará destinada a

establecer el patrón de diseño a utilizar en la parte del Servicio Api REST, cabe

recalcar que para este fin se utilizará DTO; consecuentemente se diseñará la base de

datos en el motor de BD PostgreSQL que se ajuste al modelo de negocio del

establecimiento; y como punto final se realizará el diseño del módulo de Activos

Fijos dentro del software ERP Odoo.

Ilustración 3. Conexión Módulo y Aplicación.

26
En la tercera etapa se ha de poner en práctica todo los revisado en las fases

anteriores; se llevará a cabo la construcción del módulo de activos fijos desde cero

dentro de Odoo. En esta fase se desarrollarán los diferentes módulos del sistema,

como el registro de parámetros de activo fijo, registro de bienes, registro de bajas,

la depreciación, el cuadre y cierre de activo fijo; cabe recalcar que cada uno de los

módulos mencionados son una parte fundamental del producto final y se relacionan

estrictamente entre sí; de forma paralela se desarrollaran los servicios Api REST

que permitan la integración correcta del módulo de Activos Fijos con módulos

externos, sin importar la tecnología o lenguaje de programación que se encuentre

desarrollado el cliente

La cuarta fase estará destinada al proceso de experimentación, done se ha de

implementar un plan de pruebas funcionales que deje en evidencia el correcto

funcionamiento del Sistema Web.

5.2 Metodología

Como metodología de desarrollo el quipo se ha decantado por Scrum, un marco de

trabajo que permite el trabajo en paralelo de los miembros del proyecto;

estrictamente el proyecto contara con un Product Owner, quien se ha de encargar

de establecer el proceso de la administración de Activos Fijos y dejar asentado las

necesidades que se van a resolver con este sistema; así mismo, el Scrum Master ha

de ser el responsable de la organización del equipo y de definir los sprint que se

llevaran a cabo cada semana para verificar y validar el correcto desempeño de los

desarrolladores. Cada tarea tendrá un nivel de prioridad, los cuales se detallarán en

el cronograma de actividades

27
 5.2.1 Roles Scrum:

• Product Owner: Ing. Mauricio Ortiz (MO)

• Scrum Master: Bryam Guzman (BG)

5.2.2 Scrum Team:

• Desarrollador 1: Adrián Tene (AT)

• Desarrollador 2: Bryam Guzman (BG)

5.3 Gestión tareas Scrum Team

Esta parte de la metodología de desarrollo fue fundamental para la organización del

equipo, puesto que, además de facilitar el trabajo en paralelo, permitió un mejor

seguimiento por parte del Scrum Owner (Mauricio Ortiz)

Ilustración 4. Tablero de Actividades.

En el tablero de actividades, se han utilizado 4 lista, las cuales fueron:

• Por hacer: en esta lista agregamos todas las tarjetas relacionadas a los

requerimientos y cada miembro del equipo se hace cargo de su cumplimiento

• Realizando: en esta sección se encuentran las tarjetas que se están en

proceso de desarrollo, aquí se asignaron las respectivas fechas de

vencimiento para cada actividad, así como su responsable

28
 • Bloqueado: esta lista ha servido para ingresar incidencias que ocasionaban

estancamientos en el desarrollo, por ejemplo, la falta de información de

cierto submódulo

• Hecho: en esta sección se arrastran las tarjetas que han sido validadas por el

Scrum Owner, esto le permite verificar la evolución del producto, cabe

destacar que este rol solo tiene privilegios de lectura

5.4 Descripción de actividades

A continuación, se lista las actividades realizadas de acuerdo con los objetivos

planteados en un inicio.

• OE1: Estudiar y analizar fundamentos de software ERP Odoo, Springboot

y el modelo de negocio del módulo de activos fijos del sistema financiero

de la Universidad Politécnica Salesiana

Tabla 1. Objetivo Específico 1.

No. Actividad

1 Estudio de los fundamentos de software ERP Odoo

2 Estudio de los fundamentos de desarrollo de framework Springboot

3 Estudio del modelo de negocio de la gestión de activos fijos del

establecimiento

• OE2: Diseñar y desarrollar un sistema web utilizando ERP ODOO

mediante su integración con Springboot que permita la administración de

activos fijos de un sistema financiero con la finalidad de automatizar

procesos contables

29
 Tabla 2. Objetivo Específico 2.

No. Actividad

1 Diseñar la arquitectura del sistema web, servicios Springboot Api REST y

Base de datos

2 Establecer los ambientes de desarrollo para los miembros del equipo

3 Desarrollar un módulo para la gestión de usuarios

4 Diseñar y desarrollar el módulo de registros de parámetros para activos fijos

5 Diseñar y desarrollar el módulo de registro de bienes

6 Diseñar y desarrollar el módulo de registro de bajas

7 Diseñar y desarrollar el módulo de depreciación

8 Diseñar y desarrollar el módulo de cuadro y cierre de activo fijo

• OE3: Diseñar y realizar pruebas funcionales del

sistema web

Tabla 3. Objetivo Específico 3.

No. Actividad

1 Diseño de plan de pruebas funcionales

2 Diseño de plan de pruebas no funcionales

3 Ejecución de los planes de prueba en el Sistema Web

5.5 Sprints

Después de hacer un listado de actividades por objetivos, se procedió a dividir por

Sprints de manera conjunta con el Scrum Owner, donde se pudo establecer tiempos

de entregas, lo que permitió corregir incidencias desde el inicio del desarrollo y de

esta manera, evitar pérdidas en cuanto a los tiempos

30
 5.5.1 Sprint 1 (24/04/2022)

Tabla 4. Actividades Sprint 1.

SPRINT 1

ACTIVIDADES

1 Estudio de los fundamentos de software ERP Odoo

2 Estudio de los fundamentos de desarrollo de framework Springboot

3 Estudio del modelo de negocio de la gestión de activos fijos del

establecimiento

5.5.2 Sprint 2 (05/05/2022)

Tabla 5. Actividades Sprint 2.

SPRINT 2

ACTIVIDADES

1 Diseñar la arquitectura del sistema web, servicios Springboot Api REST y

Base de datos

2 Establecer los ambientes de desarrollo para los miembros del equipo

3 Desarrollo de Modulo de Gestión de Usuarios

31
 5.5.3 Sprint 3 (22/05/2022)

Tabla 6. Actividades Sprint 3.

SPRINT 3

ACTIVIDADES

1 Diseñar y desarrollar el módulo de registro de parámetros de activos fijos

2 Diseñar y desarrollar el módulo de registro de bienes

3 Diseñar y desarrollar el módulo de registro de parámetros de bajas

5.5.4 Sprint 4 (26/06/2022)

Tabla 7. Actividades Sprint 4.

SPRINT 4

ACTIVIDADES

1 Diseñar y desarrollar el módulo de depreciación

2 Diseñar y desarrollar el módulo de cuadro y cierre de activos fijos

5.5.5 Sprint 5 (10/07/2022)

Tabla 8. Actividades Sprint 5.

SPRINT 5

ACTIVIDADES

1 Diseño de plan de pruebas funcionales

2 Diseño de plan de pruebas no funcionales

3 Ejecución de los planes de prueba en el Sistema Web

32
 6. Resultados

En este apartado se hablará sobre el desarrollo del módulo de Activos Fijos, empezando con

el listado de requerimientos, en este caso, únicamente se enlistarán, pues, desde un inicio el

departamento de desarrollo de software de la UPS contaba con la información necesaria

para empezar con la implementación

6.1 Especificación de Requerimientos

6.1.1 Requerimientos Funcionales

Se detallan los requerimientos, los cuales deben ser cumplidos, se

encuentran con sus respectivas características y lineamientos.

Código Nombre
Registro de parámetros para activo fijo
001-001

Descripción: El registro de parámetros de activos fijos permite definir el conjunto de

parámetros necesarios.

Datos de Entrada: Se tendrá como datos de entrada el parámetro de activo fijo, el tipo
de parámetro, y el tipo de activo fijo.

Proceso: Se registrará el parámetro en la base de Datos, con el tipo de activo fijo registrado

Salida: Se podrá visualizar la lista de parámetros registrados por el usuario.

Prioridad: Alta

33
 Código Nombre
Registro de Bienes
001-002

Descripción: Los Bienes son el concepto principal de activo fijo, ya que los
procedimientos giran en torno a este concepto.

Datos de Entrada: Como datos de entrada se tendrá, la cantidad de ejemplares,

parámetros, custodio, centro de costo, Empresa, descripción, fecha de alta, valor de alta,
valor de reposición, depreciación.

Proceso: Se realizará el registro de bienes en la base de datos, la cantidad de ejemplares

que el usuario ha registrado.

Salida: Se podrá visualizar la lista de bienes registrados por el usuario.

Prioridad: Alta

Código Nombre
Depreciación
001-003

Descripción: La depreciación del Activo Fijo representara la devaluación del bien, esta se
calcula de manera uniforme a lo largo de un tiempo de vida, hasta llegar a su fin.

Datos de Entrada: Como datos de entrada se tendrá, la cantidad de ejemplares,

parámetros, custodio, descripción, fecha de alta, valor de alta, valor de reposición,
depreciación
.
Proceso: Se procederá a ingresar el número de meses de vida útil, cada mes se identificará
el valor depreciado, Una vez haya cumplido el bien su vida útil se dará de baja de forma
automática
.
Salida: Se podrá visualizar la lista de bienes registrados por el usuario, su valor depreciable
por mes, valor total depreciado.

Prioridad: Alta

34
 Código Nombre
Registro de Bajas
001-004

Descripción: Existen causas definidas por las cuales se puede dar de baja un activo fijo,
lo que implica un cambio de estado y calcular su valor de baja de acuerdo al estado de
depreciación.

Datos de Entrada: Como datos de entrada se tendrá: fecha de baja, bien.

Proceso: Se procederá a ingresar el bien a dar de baja, la fecha de baja, se cambiará el

estado del bien de activo a inactivo, así mismo conforme al rol del usuario se procede a
dar por valido la baja del bien.

Salida: Se podrá visualizar la lista de bienes activos e inactivos, así mismo si el usuario
cuenta con el rol correspondiente podrá dar por valido la baja.

Prioridad: Alta

Código Nombre
Cuadre y Cierre de Activo Fijo
001-005

Descripción: Existen causas definidas por las cuales se puede solicitar reportes de bajas
y altas de los bienes en un cierto tiempo determinado, así mismo se pide que el reporte
solicitado cuente con el logo de la Universidad.

Datos de Entrada: Como datos de entrada se tendrá: fecha de inicio, fecha fin, centro de
costo, tipos de activos fijos

Proceso: Se procederá a ingresar la fecha de inicio, fecha de fin, el centro de costo, y el

tipo de activo fijo seleccionado, conforme a los ingresado se podrá descargar el reporte
solicitado en donde contaran los valores totales del valor de alta y valor de bajas.

Salida: Se podrá descargar el reporte de bajas y altas del bien solicitado.

Prioridad: Alta.

35
 Código Nombre
Transferencias
001-006

Descripción: Existen causas definidas por las cuales se puede solicitar realizar
transferencias de custodios de un activo fijo.

Datos de Entrada: Como datos de entrada se tendrá: fecha de transferencia, bien

seleccionado, custodio destino.

Proceso: Se procederá a ingresar el bien, fecha de transferencia, custodio destino, una vez
ingresado, se crea la transferencia con estado inactivo, si el usuario cuenta con el rol
permitido podrá cambiar el estado ha validado y se realiza la transferencia solicitada, caso
contrario se espera a que un usuario con los permisos necesarios de por valido la
transacción.

Salida: Se podrá visualizar la lista de bienes con sus transferencias realizadas.

Prioridad: Alta

Código Nombre
Gestión de Usuarios
001-007

Descripción: Se solicita la gestión de Usuarios en el sistema, donde se tendrá el Loguin

de usuarios, los diferentes roles y sus funcionalidades.

Datos de Entrada: Como datos de entrada se tendrá el rol de usuario, y compañías activas.

Proceso: El sistema contara con los siguientes roles:

• Contador tendrá acceso a todas las funcionalidades del módulo, únicamente
según al centro de costo al que pertenezca.
• Director General tendrá acceso a todas las funcionalidades del módulo,
independientemente al centro de costo al que este pertenezca.
• Auditor tendrá acceso a exportación de archivos y generación de reportes de
cierre de bienes.

Salida: Se podrá realizar las diferentes funcionalidades dependiendo al grupo de usuarios

al que se pertenezca

Prioridad: Alta

36
 Código Nombre
Colores de Pantalla del Sistema
001-008

Descripción: Se solicita que los colores de las diferentes pantallas del módulo lleven el
mismo que los de la Universidad.

Datos de Entrada: Se ingresan los colores de la Universidad

Proceso: Se podrá observar en las diferentes pantallas del sistema los colores
significativos de la Universidad.

Salida: El Usuario podrá visualizar de manera óptima los colores establecidos

Prioridad: Media

Código Nombre
Customizar Pantalla Inicio de Sesión
001-009

Descripción: Se solicita que la pantalla de Inicio de Sesión cuente con el logo de la

Universidad.

Datos de Entrada: Se ingresa el logo de la Universidad

Proceso: Se podrá observar en la Pantalla de Inicio de Sesión el logo Distintivo de la

Universidad.

Salida: El Usuario podrá visualizar de manera óptima el logo de la Universidad.

Prioridad: Media

37
 Código Nombre
Realización de Diagrama de Pasteles y de Barras
001-010

Descripción: Se solicita realizar una Pantalla en donde se pueda realizar un informe con
diagramas de barras y pastel.

Datos de Entrada: Se ingresa parámetros como custodio, centro de costo, fecha.

Proceso: Se deberá observar gráficos de barras y de pastel según los parámetros que se
hayan ingresado como fecha, custodio, centro de costo.

Salida: El Usuario podrá visualizar de manera óptima el informe de diagramas solicitados

Prioridad: Alta

38
 6.1.2 Requerimientos de Interfaz

En la siguiente subsección se detalla las interfaces de Usuario, que fueron

proporcionadas por los stakeholder para la realización del proyecto,

basado de un sistema obsoleto que se encuentra desarrollado en otras

tecnologías.

Registro de Parámetros para Activos Fijos

El registro de Parametros para Activo Fijo permite definir el conjunto de parametros necesarios

necesarios, se tiene los siguientes datos de entrada:

• tipo de caracateristica

• tipo de activo fijo

Posteriormente se procedera a visualizar el parametro de activo fijo registrado.

Cabe recalcar, que la descripcion se habilitara según el tipo de caracateristica escogido, los cuales

pueden ser:

• numero

• cadena de texto

• fecha

• archivo

39
 Registro de Tipo de Activo

Los tipo de activo son la agrupacion de activos, estos tienen ligada la vida util de cada activo;

pueden tener un activo padre.

Es necesario ingresar la descripcion del tipo de activo(unica), la abreviatura (unica), codigo

contable, si es depreciable, la vida util y tienen 4 cuentas contables, las mismas que seran:

• activo

• depreciación acumulada

• depreciación

• cuenta de baja

40
 Registro de Bienes

Los Bienes son el concepto principal de Activo Fijo, debido a que, los procedimientos giran

entorno a estre proceso. Como datos de entrada se tienen la cantidad de ejemplares, parametros de

activo fijo, custodio, codigo contable, estado de depresiacion, valor de alta, valor de reposicion,

vida util restante,

Se crea con estado borrador, y una vez que sea validada por el usuario con los privilegios

necesarios, cambiara a validado; en este estado ya no es posible la modificacion de los activos

creados y se crea la lista de depreciaciones

El usuario podra visualizar la lista de bienes registrados por el usuario.

41
 Depreciación

La depreciacion del Activo Fijo representara la devaluacion del bien; como datos de entrada se

tendra, la cantidad de ejemplares, parametros, custodio, descripcion, fecha de alta, valor de alta,

valor de reposicion, y el tiempo que el bien va a ser depresiado.

Se procedera a ingresar el numero de meses de vida util, cada mes se identificara con el valor

depresiado

Una vez haya cumplido el bien su vida util se dara de baja de manera automática.

42
 Transferencias

Existen causas definidas por las cuales se puede solicitar la realizacion de transferencias de

custodios de un activo fijo.

Se tendrá como entrada la fecha en la que se realizara la transferencia de activo, el custodio de

origen como el custodio destino, posteriormente se creara la transferencia donde se tendra en estado

inactivo, una vez un usuario con los permisos necesarios ingrese, podra dar como valido la

transferencia y se podrá visualizar.

43
 Colores de Pantalla del Sistema

Se Solicita que los colores de las diferentes pantallas del modulo lleven el mismo que los de la

Universidad, donde se tendra un distintivo ante los diferentes modulos que existen en la web.

Customizar Pantalla de Inicio Sesión

• Se Solicita que en la Pantalla de Inicio de Sesion cuente con el logo distintivo de la

Universidad Politecnica Salesiana, para de esta manera, asociar al modulo con el

establecimiento educativo.

• Cambiar colores que vienen por defecto

44
Esta fase de los resultados se ha dedicado netamente al levantamiento y especificación de los

requerimientos, tanto funcionales, como los de interfaz, a continuación, se va a presentar el

diseño del módulo de Activos Fijos

6.2 Diseño

En este apartado se va a revisar la documentación necesaria para el desarrollo del

módulo, con el diseño de los diagramas que se encuentran a continuación, se

pretende describir de forma gráfica los objetivos y procesos que son la base del

proyecto

6.2.1 Diagrama de componentes

Con el diseño de este diagrama se puede apreciar las partes físicas que

van a estar inmiscuidas en el desarrollo, en este caso se cuenta con los tres

pilares fundamentales del proyecto:

• Odoo ERP

• Base de Datos PostgreSQL

• Api Rest Springboot

45
 Ilustración 5. Diagrama de Componentes.

Como se observa en la figura, la plataforma Odoo ERP, interactúa

directamente con la base de datos que ha sido diseñada e implementada

en el motor PostgreSQL, cada proceso realizado para el módulo de activos

fijos ha sido netamente con el marco de trabajo que ofrece Odoo; en el

caso de Springboot, ha sido utilizado para la producción de servicios por

medio de su integración por Api Rest con otros módulos, este componente

interactúa con la base de datos, mas no, con el componente de Odoo`

46
6.2.2 Modelo de datos

Este diagrama es la base del desarrollo, sobre todo en el marco de trabajo

de Odoo, pues cada, actividad, gira en torno al modelo, por esto, es de las

fases más importantes del diseño, contiene los tipos de datos, las tablas y

relaciones que conforman la base de datos, a continuación, se presenta el

diagrama agrupado en tres segmentos:

• La ilustración 6 presenta los modelos que permiten la creación de

bienes y cada uno de ellos se encuentra relacionado, y dependen

netamente del otro, como se puede observar en la figura

Ilustración 6. Diagrama Entidad Relación 1.

47
• El la Ilustracion 7. se presenta el modelo de Activo Fijo, Baja de

Activo Fijo y Transferencia; es totalmente necesario que exista

un bien para poder realizar la operación de Baja o Transferencia.

Ilustración 7. Diagrama Entidad Relación 2

48
• La Ilustracion 8. muestra el segmento donde se encuentra los

modelos de Carcateristica, Lista de Caracteristicas y

Caracteristicas de Activo Fijo, estos modelos muestran los

parametros de activos fijos, ejemplo: color, dimension, documento

de descripcion, etc.

Ilustración 8 Diagrama Entidad Relación 3.

49
6.2.3 Diagrama de actividades

Es necesario detallar los procesos que conllevan los requerimientos del

sistema, en su interacción con el usuario, por ello, se han diseñado

diagramas que demuestran los procesos necesarios para llevar a cabo una

actividad, los mismos que se detallan a continuación

• En la Ilustración 9 se presentar el proceso para el registro de los

parámetros del activo fijo

Ilustración 9. Diagrama de Actividades Registro de Activo Fijo.

50
• El registro del tipo de activo fijo es esencial para la creación del

activo fijo, en la Ilustración 10 se detalla el proceso para su

creación

Ilustración 10. Diagrama de Actividades Creacion de Activos Fijos.

51
• En este caso se presenta la base del desarrollo del módulo, los

activos fijos, su creación es la más importantes, pues, toda gira en

torno a este proceso, que en la figura se la puede apreciar

Ilustración 11. Diagrama de Actividades Registro de Activo Fijo 2.

52
• En la figura se presenta la verificación de la transferencia, que esto

dependerá del rol del usuario, primero se hace la respectiva

validación de los grupos de usuario a los que pertenece

Ilustración 12. Diagrama de Actividades Transferencia o Baja.

53
 • Para generar el reporte nada más se necesita ingresar los

parámetros descritos anteriormente y el sistema devuelve un

reporte generado, como sucede en la figura

Ilustración 13. Diagrama de Actividades Generar Reporte.

Una vez presentados el diseño del sistema, se puede exponer los resultados del desarrollo

realizado, que contara con evidencias de la correcta implementación y aceptación de cada una

de las partes desarrolladas

54
 6.3 Desarrollo

Después de haber realizado el correcto diseño, se procede al desarrollo, se ha de

comenzar con la presentación de resultados y las aprobaciones de los requerimientos

descritos en un principio

6.3.1 Pruebas Funcionales y de Interfaz

A continuación, se adjunta evidencias de la correcta resolución y

aprobación de los requerimientos

Prueba Funcional 1

Requerimiento:

Registro de Parámetros de activos fijos permite definir el conjunto de parámetros necesarios,

en esta fase el usuario deberá registrar el dato de entrada del parámetro de activo fijo, el tipo

de parámetro y el tipo de activo fijo, si el parámetro es obligatorio y su orden de

visualización.

Prueba Aprobada

Resultado Obtenido

55
 Prueba Funcional 2

Requerimiento:

Se deberá realizar el registro de bienes, según los parámetros ingresados como son el tipo de

activo fijo, descripción, fecha de alta, número de unidades a ingresar, centro de costo, calor

de alta, vida de útil restante y el valor de reposición, si el usuario tiene rol permitido para dar

como valido, caso contrario, el estado quedará como inactivo, hasta que se pueda cambiar a

valido dicho registro de bien.

Prueba Aprobada

Resultado Obtenido:

56
 Prueba Funcional 3

Requerimiento:

Se deberá realizar el registro de depreciación, de esta forma se representará un listado de las

futuras depreciaciones que le quedan desde que se dio de alta y de acuerdo a los parámetros

ingresado, de esta forma, el valor de la depreciación se ha de calcular conforme a los meses

de vida útil, valores de alta, valores de reposición, y su valor de depreciación, cuando se haya

depreciado hasta su total, se procederá a dar de baja el activo fijo de manera automática.

Prueba Aprobada

Resultado Obtenido

57
Prueba Funcional 4

Requerimiento:

Existen causas definidas por las cuales se pueden de dar de baja a un activo de forma manual,

por lo tanto, implica un cambio de estado y proceder con el cálculo del valor de baja de

acuerdo con el valor que se ha depreciado hasta el momento que se ha decidido dar de baja

al bien. Cabe mencionar que se ha de dar como validada la baja, si el usuario que la realizó

tiene el rol permitido, caso contrario, se esperara a que un usuario de rol permitido pueda dar

como validada dicha baja y esta se ha de crear con estado borrador.

Prueba Aprobada

Resultado Obtenido

58
Prueba Funcional 5

Requerimiento:

El proceso permitirá obtener reportes de bajas y altas de los bienes con diferentes parámetros

como: tipo de activo, centro de costo, fecha de inicio y fecha fin, así mismo, el reporte debe

contar con el logo de la Universidad y los valores totales de egresos e ingresos

Prueba Aprobada

Resultado Obtenido

59
60
Prueba Funcional 6

Requerimiento:

Se procederá a ingresar el bien, fecha de transferencia, custodio destino, una vez ingresado,

se crea la transferencia con estado inactivo, si el usuario cuenta con el rol permitido podrá

cambiar el estado ha validado y se realiza la transferencia solicitada, caso contrario, se espera

a que un usuario con los permisos necesarios de por valido la transacción.

Prueba Aprobada

Resultado Obtenido

61
Prueba Funcional 7

Requerimiento:

Se solicita que los colores de las diferentes pantallas del módulo tengan que ver con el logo

de la Universidad Politécnica Salesiana, azul de preferencia, no se permite otro diseño

Prueba Aprobada

Resultado Obtenido

Prueba Funcional 8

Requerimiento:

Se solicita realizar una pantalla de Inicio de Sesión donde se encuentre el logo de la

Universidad Politécnica Salesiana y los colores vayan acorde al mismo, también es necesario

que estos colores sean parametrizables dentro del marco de trabajo Odoo.

Prueba Aprobada

Resultado Obtenido

62
Prueba Funcional 9

Requerimiento:

Se solicita realizar una pantalla donde se pueda realizar un informe de los activos fijos de

forma dinámica con gráficos estadísticos, se ingresaran parámetros como son el custodio,

centro de costo y fechas, al realizar esto el usuario podrá visualizar gráficos de barras y de

pastel, acorde a los parámetros ingresados.

Prueba Aprobada

Resultado Obtenido

63
64
6.3.2 Desarrollo código

En este apartado se presenta la principal estructura del código fuente que

se ha utilizado para el cumplimiento de los requerimientos.

La actividad inicial fue preparar un ambiente de desarrollo eficiente para

la implementación del módulo, para ello, el IDE utilizado fue PyCharm

Community Edition, la cual, es una herramienta que provee un ambiente

ideal para el desarrollo de Python permitiendo realizar Debug, lo que es

muy útil al momento de codificar y verificar la correcta ejecución de

procesos en cualquier lenguaje de programación.

Como se puede observar en la Ilustración 14, se encuentra la estructura la

estructura básica de un proyecto en Odoo, la misma que cuenta, con la

siguiente estructura:

• Controllers: Lugar donde se alojan los controladores encargados

de tomar el control entre las vistas y los modelos.

• Demo: Se encuentra la data que ayuda a entender el

funcionamiento del módulo.

• Models: Guarda toda la lógica de los modelos.

• Security: Se encuentran los diferentes permisos de los diferentes

usuarios creados.

• Views: Guarda todos los archivos XML, que serán las vistas de

cada módulo.

• _init_py: Se importa las carpetas con archivos Python, que se van

a hacer uso dentro del módulo.

• _manifest_py: Se encuentra la presentación del módulo.

65
 Ilustración 14. Estructura del Proyecto.

Los modelos son la parte esencial de Odoo ERP, por lo tanto, en la

Ilustración 15 se puede observar la lista de archivos que pertenecen a cada

entidad de la base de datos, cabe recalcar que ha sido necesario un reajuste

del modelo de datos para motivos de resolución de ciertos requerimientos,

como la creación de activos fijos y generación de reportes de cuadre y

cierre

Ilustración 15. Lista de Archivos.

66
Para alojamiento del código fuente de la aplicación se ha optado por

utilizar la herramienta de GitHub, donde pueden trabajar de manera

conjunta los desarrolladores, a la vez de facilitar un control de versiones

adecuando para la elaboración del proyecto en equipo, como se puede

observar en la Ilustración 16 a continuación

Ilustración 16. Repositorio GitHub.

Link Repositorio GitHub: [Link]

67
 6.3.3 Fase de aceptación

Como punto final del desarrollo, se tiene la fase de aceptación, la cual

consiste en presentar los resultados de una encuesta realizada a cinco

miembros del departamento de Desarrollo de la Universidad Politécnica

Salesiana.

Por temas de confidencialidad se ha obviado de mencionar sus nombres,

a continuación, los resultados.

1. ¿Tiene conocimiento de ERP Odoo?

Si No

Ilustración 17. Pregunta 1.

Según el resultado de la Ilustración 17 se puede denotar que cuatro de los

seis desarrolladores, tienen conocimiento del ERP Odoo, facilitando la

integración y mantenimiento del módulo en el establecimiento educativo

68
2. ¿Le gustaría tener un módulo personalizado para el manejo de

Activos de Activos Fijos para la Institución?

0
Si No

Ilustración 18. Pregunta 2.

La Ilustración 18, muestra que tres desarrolladores están de acuerdo con

tener un módulo de activos fijos para la institución en Odoo.

69
3. ¿Cree Ud., que es de optimo automatizar mediante el ERP Odoo

procesos en cuanto al registro y procedimientos de Activos Fijos

de la Universidad Politécnica Salesiana?

0
Si No

Ilustración 19. Pregunta 3.

Según la Ilustración 19, cinco desarrolladores, opinan que, si se podrá

automatizar en cuanto a procesos de procedimientos de Activos Fijos de

la “Universidad Politécnica Salesiana”, por lo tanto, la materialización del

proyecto técnico será de gran ayuda.

70
4. ¿Cuenta la Universidad con un Módulo para la gestión de

procesos de Activos Fijos?

6
5
4
3
2
1
0
Si No

Ilustración 20. Pregunta 4.

En torno a la Ilustración 20, la Universidad Politécnica Salesiana no

cuenta con un módulo de activos fijos actualmente.

5. ¿El módulo de Activos Fijos expuesto, cumple con las

características necesarias para poder ejercerse en la Universidad

Politécnica Salesiana?

6
5
4
3
2
1
0
Si No

Ilustración 21. Pregunta 5.

71
De acuerdo con la Ilustración 21, se puede denotar que el módulo

realizado, acorde a los desarrolladores de la Universidad Politécnica

Salesiana, cumple para poder ejercerse y ser de ayuda para la

automatización de estos procesos.

72
7. Cronograma

Tabla 9. Cronograma de Actividades.

Nombre de la tarea

Actividades Responsable Duraciòn Comienzo Fin

Total de horas por objetivo: 70
Actividad Nº1: Estudio de los fundamentos de
Objetivo
software ERP Odoo B.G -A.T 20 11/04/2022 14/04/2022
Especifico Nº1:
Actividad Nº2: Estudio de los fundamentos de B.G -A.T 20 15/04/2022 18/04/2022
Sprint:1
desarrollo de framework Springboot

Actividad Nº3: Estudio del modelo de negocio

de la gestión de activos fijos del establecimiento B.G -A.T 30 19/04/2022 23/04/2022

Total de horas por objetivo: 430

Objetivo Actividad Nº1: Diseñar la arquitectura del

Especifico Nº2: sistema web en Frontend, Backend y Base B.G - A.T 25 24/04/2022 29/04/2022

Sprint:2 de datos

Actividad Nº2: Establecer los ambientes de

73
 desarrollo para los miembros del equipo B.G - A.T 25 30/04/2022 05/05/2022

Actividad Nº3: Desarrollar un módulo para la B.G - A.T 40 06/05/2022 13/05//2022

gestión de usuarios

Sprint: 3 Actividad Nº4: Diseñar y desarrollar el módulo B.G - A.T 60 14/05/2022 22/05/2022

de registros de parámetros para activos fijos

Actividad Nº5: Diseñar y desarrollar el módulo B.G - A.T 60 23/05/2022 31/05/2022

Sprint: 4 de registro de bienes

Actividad Nº6: Diseñar y desarrollar el módulo

de registro de bajas B.G - A.T 60 01/06/2022 09/06/2022

Actividad Nº7: Diseñar y desarrollar el módulo

Sprint: 5 de depreciación B.G - A.T 65 09/06/2022 17/06/2022

Actividad Nº8: Diseñar y desarrollar el B.G – A.T 65 18/06/2022 26/06/2022

módulo de cuadro y cierre de activo fijo

Actividad Nº9: Diseño y Revisión del informe B.G - A.T 30 27/06/2022 30/06/2022

74
 - MO

Total de horas por objetivo: 100

Objetivo Actividad Nº1: Diseño de plan de pruebas B.G - A.T 25 01/07/2022 04/07/2022

Especifico Nº3: funcionales

Sprint 6 Actividad Nº2: Diseño de plan de pruebas no B.G - A.T 25 05/07/2022 08/07/2022

funcionales

Actividad Nº3: Ejecución de los planes de

prueba en el Sistema Web B.G - A.T 25 09/07/2022 12/07/2022

Actividad Nº4: Diseño y Revisión del informe B.G - A.T 25 13/07/2022 16/07/2022

MO

Total de horas 600

75
Total de horas: 600
Horas completadas por Tene Guamán Adrián Rodrigo: 300 horas
Horas completadas por Guzman Cabrera Bryam Wilson: 300 horas
Fecha de inicio: Lunes 05-04-2022
Fecha de finalización: Sábado 16-07-2022

76
8. Presupuesto

Tabla 10. Presupuesto del Proyecto.

Costo
Cant. Costo total
Denominación unitario

Unidades Dólares Dólares

1. Tecnológico

Computador portátil 2 $1000,00 $2000,00

Computador escritorio 1 $800,00 $800,00

Monitor 1 $150,00 $150,00

2. Servicios

Servicio de internet 6 $28,00 $168,00

Almacenamiento en la nube 1000GB $0,023 $23,00

Servidor aplicación 6 $25,00 $150,00

3. Personal

Estudiante/Desarrollador 600 horas $20,00 $12.000,00

4. Otros

Imprevisto 1 $250,00 $250,00

TOTAL $15.541,00

77
9. Conclusiones

Como fase inicial del desarrollo del proyecto ha sido necesario el estudio de los fundamentos

del software Odoo ERP, el mismo que provee un marco de trabajo que tiene sus bases en el

modelo de datos levantado en el diseño del software, y su lenguaje de programación es Python,

por lo tanto, es indispensable poseer conocimientos para el desarrollo eficaz del módulo y el

uso de buenas prácticas; por otra parte, para la implementación del módulo de activos fijos ha

sido esencial el estudio de los procesos contables que se utilizan en la gestión de activos fijos,

por ejemplo, la generación de la tabla de amortización de un bien, la cual requiere de conceptos

y operaciones contables complejas.

El objetivo general se centra en el desarrollo de un módulo de activos fijos destinado a la

institución educativa superior “Universidad Politécnica Salesiana” mediante el uso del marco

de trabajo que ofrece el software ERP Odoo, el cual ha sido cumplido con cabalidad en su

totalidad satisfaciendo las necesidades y requerimientos planteados al inicio del proyecto.

El desarrollo del módulo de registro de parámetros de activos fijos y módulo de registro de

bienes es la base de todos los procesos contables que se realizan en el proyecto técnico, por lo

tanto, ha sido de alta prioridad un reajuste al modelo de datos con respecto a los procesos, pues,

en el marco de trabajo de Odoo, las interfaces y procesos están netamente ligados con las clases

que contienen a los modelos del sistema; un caso muy particular fue la creación masiva de

activos fijos, la cual consistía en ingresar la información básica de un activo y de acuerdo con

la cantidad ingresada, se generaban varios registros de los mismo con diferente código, para

lograr este objetivo, se implementó una relación maestro-detalle, en la cual la cabecera actúa

como asistente de creación y los detalles son los registros que estarán ligados a cada procesos

contable como la transferencia, baja y depreciación.

78
Los procesos contables que se llevan a cabo en el subsistema de gestión de activos fijos son la

depreciación y baja, por esta razón, ha sido indispensable el correcto desarrollo de estos; por

lo tanto, para satisfacer la generación de la tabla de amortizaciones se utilizó la formula

establecida de depreciación lineal, la cual genera varios registros de la depreciación del bien

basándose en el tiempo de vida del tipo de activo fijo de manera mensual y uniforme hasta que

su valor se anula y cambia su estado automáticamente a inactivo dejando de estar disponible

para el usuario; este proceso de baja de activo también se puede realizar de manera manual

tomando el valor real del bien en base a la tabla de amortización con respecto a la depreciación

acumulada y tendrá el mismo fin que en el proceso antes mencionado.

La generación de transferencia de activos fijos tiene su importancia en casos de desahucio de

un custodio o empleado de la institución, por lo tanto, el sistema permite realizar este proceso

de forma intuitiva mediante la selección del activo fijo y el custodio destino, logrando así,

cambiar la responsabilidad de un custodio a otro sobre un bien, sin necesidad de darlo de baja.

Conforme a la encuesta realizada, podemos decir que la mayoría de los desarrolladores tienen

conocimiento sobre Odoo, por lo que la implementación de este módulo no será muy compleja,

en cuanto a capacitación del equipo técnico del establecimiento; así mismo, en cuanto a la

aceptación del producto, a un gran porcentaje los usuarios de la célula contable le agrada la

idea de tener un módulo personalizado que facilite la gestión del manejo de activos fijos, por

lo que el desarrollo de este proyecto ha de ayudar con la automatización de diversos procesos

de activos fijos y podría ser el inicio de una migración total del sistema financiero actual de la

“Universidad Politécnica Salesiana” hacia el software ERP Odoo gracias a los beneficios que

ofrece en cuanto al rápido aprendizaje técnico y un excelente comunidad que respalda cada

desarrollo que se encuentra en este marco de trabajo.

79
Finalmente, en base a las ideas planteadas y los fundamentos emitidos, se puede llegar a la

conclusión de que el trabajo invertido ha sido totalmente fructífero, logrando así, materializar

el producto final del proyecto de titulación: Análisis y desarrollo de un sistema web utilizando

ODOO para la gestión de activos fijos de la Universidad Politécnica Salesiana.

80
10. Recomendaciones

Con respecto al desarrollo del módulo de activos fijos, es esencial el estudio de los fundamentos

del Odoo, así mismo la implementación de las mejores prácticas entorno al lenguaje de

programación Python, pues, al inicio es un poco complejo entender la estructura que maneja

Odoo; sin embargo, la clave se encuentra en las clase que pertenecen a los modelos y las vistas,

pues, cada vista generada es en base a los modelos de datos, y en ciertas ocasiones será

necesario modificar la estructura de la BD inicial para satisfacer un requerimiento.

En los procesos contables es indispensable el manejo de números, pues, una décima podría

generar un descuadre total y ser el responsable de causar inconvenientes al establecimiento,

por lo tanto, se recomienda manejar operaciones y procedimientos precisos en su totalidad y

ser cuidadoso con las fórmulas que se han de utilizar para resolver un requerimiento, por

ejemplo, la generación de la tabla de amortización de un activo fijo

Cuando se realice la implementación de un módulo o funcionalidad nueva en el proyecto Odoo

ERP, se sugiere al desarrollador, analizar el software y verificar si existe una implementación

similar a la que se desea realizar, debido a que, este es un ERP muy extenso con una amplia

comunidad que se encuentra todo el tiempo implementando nuevas funcionalidades o tratando

de mejorarlas y, gracias a esto, permite la reutilización de módulos y acoplamiento de acuerdo

a las necesidades de cada empresa y localización

El desarrollo del módulo de activos fijos para la “Universidad Politécnica Salesiana” ha sido

culminado con éxito, por lo tanto, se recomienda al establecimiento la utilización de este

proyecto base para la implementación de nuevos módulos contables o de cualquier índole, y en

un futuro realizar la migración total del Sistema Financiero actual hacia el software Odoo ERP

81
Referencias bibliográficas

Díaz, A., Gonzales, J., & C., &. R. (2005). Implantación de un sistema ERP en una

organización. RISI.

Hamidian, B., & Ospino, G. (2015). ¿Por qué los sistemas de información son esenciales? .

Haro, E., Guarda, T., & Peñaherrera, Z. (2019). Desarrollo backend para aplicaciones web,

Servicios Web Restful: [Link] vs Spring Boot. Brasil: ProQuest.

IBM. (6 de Abril de 2021). Obtenido de IBM: [Link]

apis

Johansen, E. (2006). Patrones de diseño. Revista ABB.

Laudon C., L. J. (2016). Sistemas de Información General. México: Pearson.

López, T., O. G., L. d., & Vázquez, S. (2018). Capa de Servicios para la Plataforma de

Procesamiento de Datos Educativos Masivos de. La Habana.

MEIGS, R. F. (2016). Las bases para decisiones gerenciales - 11va edicion. Spuner.

O'Leary, Timothy, & Linda. (2008). Computing Essentials Introductory .

OpenERP. (2021). Que es ODoo. Obtenido de Que es ODoo:

[Link]

%20y%20Fabricaci%C3%B3n%20entre%20otras.

Pavón, Y., & Baró, L. (2018). En el proyecto de (Yanelis Pavón González, Liber Puente

Baró, Marta Infante Abreu, Jeffrey Blanco González, 2018) se menciona a ERP Odoo

como una alternativa de desarrollo de un sistema para la reduccion de ciclo de cierre

contable, aprovechando diversos . Chile: scielo.

82
Perdanakusuma, Dickson, & Puspitasari. (2020). Utilizing Open ERP for Creating Medical

Record System in Smart Hospital: A Case Study. 2020 IEEE International

Conference on Industry 4.0; Artificial Intelligence, and Communications Technology

(IAICT).

Puerta González, J. (2014). Desarrollo de una API para la descripcion y gestion de servicios

WEb REST. Obtenido de

[Link]

sequence=1&isAllowed=y

R. Singh, M. P. (2018). Chatbot using TensorFlow for small Businesses. 2018 Second

International Conference on Inventive Communication and Computational

Technologies (ICICCT), pp. 1614-1619.

Sancho, G. (2020). Desarrollo de un software de gestión de inventario. Universitat

Politècnica de València.

Schwaber K., S. J. (2020). La Guía Scrum.

Torres, M. M.-B. (2020). Asistente virtual académico utilizando tecnologías cognitivas de

procesamiento de lenguaje natural. Revista Politécnica, 85-96.

Trigas Gallegos, M. (s.f.). Metodología Scrum. Obtenido de

[Link]

[Link]

Trigas, M. (2018). Metodología Srcum.

Vicente, G. J. (2019). Desarrollo de un Dashboardpara automatizar los procesos

académicos y administrativos de las IES del Ecuador. Yantzaza: Instituto Superior

Tecnológico Primero de Mayo.

83
Wikipedia. (2020). Wikipedia. Obtenido de Software de administración de proyectos:

[Link]

84
Anexos

Anexo 1. Pantalla de Login.

Anexo 2. Estilos Login

85
 Anexo 3. Wizard Crear Activos.

Anexo 4. Grupos Filtros Activos Fijos.

86
Anexo [Link] Histograma Activos Fijos.

Anexo 6. Gráfico de Pasteles Activos Fijos.

87
 Anexo 7. Validar Transferencias.

Anexo 8. Baja Activo Fijo.

Anexo 9. Parámetros Reporte de Activos Fijos.

88
Anexo 10. Python Depreciación Automática.

Anexo 11. Cuadre y Cierre de Activos Fijos.

89
Anexo 12. Suma de Activos Fijos Activos.

Anexo 13. Suma Activos Fijos Inactivos.

90