TESIS PUCP Esta obra ha sido publicada bajo la licencia Creative Commons Reconocimiento-No comercial-Compartir bajo la misma licencia 2.5 Perú. Para ver una copia de dicha licencia, visite http://creativecommons.org/licenses/by-nc-sa/2.5/pe/ PONTIFICIA UNIVERSIDAD CATÓLICA DEL PERÚ FACULTAD DE CIENCIAS E INGENIERÍA ANÁLISIS Y DISEÑO DE UN SISTEMA DE TRÁMITE DE DOCUMENTOS DE PAGO A PROVEEDORES VÍA INTRANET Tesis para optar por el Título de Ingeniero Informático, que presenta el bachiller: Dorila Sarita Carrera Jimenez ASESOR: Ing. Carlos Salvador Saleme Velarde Lima, abril del 2009 RESUMEN La presente tesis propone el análisis y diseño un sistema de trámite de documentos de pago a proveedores vía Intranet, que puede ser implementado en cualquier institución organizada en unidades. La organización de este documento, guía al lector en el conocimiento gradual del problema, el análisis y diseño de la alternativa de solución. Así, en el primer capítulo, se presenta la definición y el marco conceptual del problema, y se describe y sustenta la alternativa de solución. En el segundo capítulo, se detalla la metodología a utilizar, los requerimientos identificados y el análisis de los mismos. En el tercer capítulo, se diseña la alternativa de solución. Finalmente, en el cuarto capítulo, se incluyen las observaciones, conclusiones y recomendaciones. El sistema brinda las siguientes funcionalidades: • Registro de documentos en la institución vía Intranet a través de una interfaz de usuario amigable e intuitiva, generándose lo que en adelante denominaremos “documento de trámite”; aquí se define el flujo de aprobación que debe seguir el documento. • Registro del documento digitalizado, el cual se adjunta al documento de trámite, para evitar el tránsito a través de las oficinas de la institución para su aprobación. • Aprobación del documento de trámite en cada nivel del flujo, a cargo de la unidad correspondiente. • Devolución del documento de trámite, en caso se encuentre algún dato erróneo, o cuando el flujo que está siguiendo el documento deba ser cambiado. • Anulación del trámite del documento, en caso el documento no deba continuar el trámite y deba ser devuelto al proveedor. • Contabilización y reversión de la contabilización del documento de trámite. • Interfaz con el sistema de pagos institucional, lo que permitirá conocer el estado del trámite de los documentos de pago a proveedores en dicho sistema. • Búsqueda de documentos de trámite, según el perfil de cada usuario. • Envío de mensajes de alerta por correo electrónico, a los responsables del nivel, para continuar con la atención del documento de trámite. • Envío y recepción de los documentos físicos, a través de lo que en adelante se denominará “lote de documentos”. • Búsqueda de lotes de documentos, según el perfil de cada usuario. • Extranet de proveedores, la cual permitirá que los proveedores puedan consultar el estado del trámite de los documentos de pago que ha emitido a la institución. A manera de aplicación práctica se presentan el análisis y diseño para la Pontificia Universidad Católica del Perú, institución que recibe un promedio diario de cuatrocientos cincuenta documentos de sus proveedores, los cuales son consecuencia de la adquisición de bienes y servicios que realizan las diferentes unidades que la conforman. A Dios A Sarita Colonia A mi familia A todos mis amigos AGRADECIMIENTOS A Dios, por darme la vida. A Sarita Colonia, por guiar mis pasos. A mis padres, Raymundo y Luspicia, por haberme dado una educación basada en valores y por apoyarme siempre. Al ingeniero Hernán Blanc, por haber confiado en mí y por haberme apoyado durante toda mi carrera universitaria. Al ingeniero Carlos Saleme, por su apoyo y esmerado asesoramiento. A los ingenieros Ina Cueva, Javier Agreda, Zkenia Vásquez, Carlos Córdova y Mauricio Navarrete, por su apoyo en las diferentes etapas de este proyecto. A Catherine Díaz por alentarme a concluir este documento, y José Luis Soria por su apoyo activo para culminar el presente documento de tesis. A todos mis familiares y mis amigos que directa o indirectamente contribuyeron a alcanzar este logro. I INDICE 1. Generalidades.....................................................................................................1 1.1. Definición del problema................................................................................1 1.1.1. Definición de la situación actual del caso práctico................................3 1.2. Marco conceptual.........................................................................................6 1.2.1. Identificación de conceptos...................................................................6 1.2.2. Roles del negocio .................................................................................8 1.3. Estado del arte .............................................................................................9 1.3.1. Soluciones existentes ...........................................................................9 1.4. Descripción y sustentación de la solución .................................................12 1.4.1. Objetivos.............................................................................................12 1.4.2. Alcance ...............................................................................................13 1.4.3. Reingeniería de los procesos del negocio ..........................................14 1.4.3.1. Recepción de documentos de pago a proveedores ....................14 1.4.3.2. Trámite del documento en un nivel de registro............................15 1.4.3.2.1. Registro del documento ..........................................................16 1.4.3.2.2. Revisión del documento..........................................................17 1.4.3.2.3. Anulación del trámite del documento ......................................18 1.4.3.2.4. Envío del documento ..............................................................18 1.4.3.3. Trámite de documentos en un nivel unidad.................................18 1.4.3.3.1. Revisión del documento..........................................................19 1.4.3.3.2. Aprobación del documento .....................................................20 1.4.3.3.3. Devolución del documento......................................................20 1.4.3.3.4. Anulación del trámite del documento ......................................20 1.4.3.4. Trámite de documentos en un nivel contable ..............................21 1.4.3.4.1. Registro de documentos .........................................................21 1.4.3.4.2. Revisión del documento..........................................................21 1.4.3.4.3. Contabilización del documento ...............................................22 1.4.3.4.4. Reversión de la contabilización del documento ......................22 1.4.3.4.5. Aprobación del documento .....................................................23 1.4.3.4.6. Devolución del documento......................................................23 1.4.3.4.7. Anulación del trámite del documento ......................................24 1.4.3.5. Trámite de los documentos físicos ..............................................24 II 1.4.3.5.1. Registro y envío de lotes de documentos con documentos físicos al nivel de archivo ...........................................................................24 1.4.3.5.2. Registro y envío de lotes de documentos con documentos físicos por anulación del trámite.................................................................24 1.4.3.5.3. Recepción de lote de documentos..........................................25 1.4.3.5.4. Anulación de lote de documentos. ..........................................25 1.4.4. Ventajas de la solución propuesta ......................................................27 2. Análisis..............................................................................................................29 2.1. Metodología a utilizar .................................................................................29 2.2. Requerimientos del sistema.......................................................................32 2.2.1. Visión del proyecto..............................................................................32 2.2.1.1. Introducción .................................................................................32 2.2.1.2. Posicionamiento ..........................................................................33 2.2.1.2.1. Oportunidades de negocio ......................................................33 2.2.1.2.2. Definición del problema...........................................................33 2.2.1.2.3. Declaración de posicionamiento del producto ........................33 2.2.1.3. Descripción de los usuarios.........................................................34 2.2.1.3.1. Perfiles de usuarios.................................................................34 2.2.1.3.2. Demografía del mercado.........................................................34 2.2.1.4. Vista general del sistema.............................................................35 2.2.1.4.1. Perspectiva del sistema ..........................................................35 2.2.1.4.2. Beneficios del sistema ............................................................36 2.2.1.4.3. Dependencias del sistema ......................................................36 2.2.2. Requerimientos funcionales................................................................37 2.2.3. Requerimientos no funcionales...........................................................38 2.3. Análisis de la solución................................................................................39 2.3.1. Casos de uso......................................................................................39 2.3.1.1. Actores ........................................................................................39 2.3.1.2. Casos de uso relacionados al documento...................................41 2.3.1.2.1. Caso de Uso: CU01 Consultar documento .............................41 2.3.1.2.2. Caso de Uso: CU02 Registrar documento..............................42 2.3.1.2.3. Caso de Uso: CU03 Registrar documento en contabilidad.....44 2.3.1.2.4. Caso de Uso: CU04 Administrar documento ..........................46 2.3.1.2.5. Caso de Uso: CU05 Administrar documento en contabilidad .48 2.3.1.2.6. Caso de Uso: CU06 Administrar documento en contabilidad master…….................................................................................................50 2.3.1.2.7. Caso de Uso: CU07 Consultar documento vía extranet .........50 III 2.3.1.3. Casos de uso relacionados al lote de documentos .....................52 2.3.1.3.1. Caso de Uso: CU08 Consultar lote de documentos ...............52 2.3.1.3.2. Caso de Uso: CU09 Administrar lote de documentos.............53 2.3.1.4. Matriz de trazabilidad...................................................................56 2.3.2. Diagrama de clases ............................................................................57 2.3.3. Especificación de las clases del sistema............................................57 2.3.4. Diagrama de estados..........................................................................59 2.3.4.1. Diagrama de estados del documento ..........................................59 2.3.4.2. Diagrama de estado del lote de documentos ..............................59 3. Diseño ...............................................................................................................60 3.1. Arquitectura del sistema.............................................................................60 3.1.1. Arquitectura WEB ...............................................................................60 3.1.2. Patrón de diseño.................................................................................62 3.1.3. Diagrama de componentes.................................................................62 3.1.4. Diagramas de interacción ...................................................................65 3.1.4.1. Diagramas de secuencia: CU01 Consultar documentos .............66 3.1.4.2. Diagramas de secuencia: CU02 Registrar documento................68 3.1.4.3. Diagramas de secuencia: CU03 Registrar documento en contabilidad ...................................................................................................69 3.1.4.4. Diagrama de secuencia: CU04 Administrar documento..............70 3.1.4.5. Diagramas de secuencias: CU05 Administrar documento en contabilidad ...................................................................................................71 3.1.4.6. Diagramas de secuencias: CU08 Consultar lote de documentos72 3.1.4.7. Diagramas de secuencias: CU09 Administrar lote de documentos... ................................................................................................73 3.2. Modelo físico de datos ...............................................................................74 3.2.1. Especificación del modelo físico de datos ..........................................77 3.3. Prototipos del sistema................................................................................86 3.3.1. Pantallas: CU01 Consultar Documento ..............................................86 3.3.2. Pantallas: CU02 Registrar Documento ...............................................88 3.3.3. Pantallas: CU03 Registrar Documento en Contabilidad .....................89 3.3.4. Pantallas: CU04 Administrar documento ............................................90 3.3.5. Pantallas: CU05 Administrar documento en contabilidad...................91 3.3.6. Pantallas: CU07 Consultar documento vía extranet ...........................94 3.3.7. Pantallas: CU08 Consultar lote de documentos .................................94 3.3.8. Pantallas: CU09 Administrar lote de documentos ..............................96 4. Observaciones, conclusiones y recomendaciones ...........................................99 IV 4.1. Observaciones ...........................................................................................99 4.2. Conclusiones ...........................................................................................100 4.3. Recomendaciones ...................................................................................101 Bibliografía V INDICE DE TABLAS Tabla 1.1. Deficiencias detectadas en instituciones con procesos manuales. .......2 Tabla 1.2. Deficiencias detectadas en instituciones con sistemas informáticos de gestión del trámite de documentos de pago a proveedores..................3 Tabla 1.3. Resumen de deficiencias detectadas en la PUCP. ...............................5 Tabla 1.4. Conceptos necesarios para entender el problema planteado y su solución. ................................................................................................6 Tabla 1.5. Roles del negocio. .................................................................................8 Tabla 1.6. Módulo de tramite documentario SICOP...............................................9 Tabla 1.7. SAP Enterprise Buyer Professional.....................................................10 Tabla 1.8. Workflow de aprobación de Documentos Tributarios..........................11 Tabla 1.9. Deficiencias que serán superadas con el sistema de trámite de documentos de pago a proveedores vía intranet ................................27 Tabla 2.1. Marco de trabajo organizado por flujos de trabajo fundamentales del Proceso Unificado, aplicado en proyecto. ...........................................31 Tabla 2.2. Marco de trabajo organizado por fases del Proceso Unificado, aplicado en el proyecto. .....................................................................................32 Tabla 2.3. Requerimientos funcionales ................................................................37 Tabla 2.4. Requerimientos no funcionales ...........................................................38 Tabla 2.5. Actores del sistema .............................................................................40 Tabla 2.6. Caso de Uso: Consultar documento....................................................41 Tabla 2.7. Caso de Uso: Registrar documento ....................................................42 Tabla 2.8. Caso de Uso: Registrar documento en contabilidad ...........................44 Tabla 2.9. Caso de Uso: Administrar documento.................................................46 Tabla 2.10. Caso de Uso: Administrar documento en contabilidad........................48 Tabla 2.11. Caso de Uso: Administrar documento en contabilidad master............50 Tabla 2.12. Caso de Uso: Consultar documento vía extranet ................................50 Tabla 2.13. Caso de Uso: Consultar lote de documentos ......................................52 Tabla 2.14. Caso de Uso: Administrar lote de documentos ...................................53 Tabla 2.15. Matriz de trazabilidad ..........................................................................56 Tabla 2.16. Clases del sistema ..............................................................................57 Tabla 3.1. Capas de la Arquitectura WEB............................................................61 Tabla 3.2. Diagrama de componentes .................................................................63 Tabla 3.3. Componentes del proyecto según el patrón de diseño MVC. .............63 Tabla 3.4. Estereotipos de clases para el diseño de procesos de software.........65 VI INDICE DE GRÁFICOS Gráfico 1.1. Diagrama de actividades de la recepción de documentos de pago a proveedores. ...................................................................................15 Gráfico 1.2. Diagrama de actividades del trámite del documento en un nivel de registro ............................................................................................17 Gráfico 1.3. Diagrama de actividades del trámite de documentos en un nivel unidad .............................................................................................19 Gráfico 1.4. Trámite de documentos en un nivel contable..................................23 Gráfico 1.5. Diagrama de actividades del lote de documentos enviado hacia el nivel de archivo contable. ...............................................................25 Gráfico 1.6. Diagrama de actividades del lote de documentos enviado hacia el nivel de registro...............................................................................26 Gráfico 2.1. Ciclo de vida RUP. ..........................................................................31 Gráfico 2.2. Esquema de la arquitectura del Campus Virtual (intranet) de la PUCP..............................................................................................36 Gráfico 2.3. Diagramas de actores .....................................................................39 Gráfico 2.4. Diagrama de casos de uso relacionados al documento..................41 Gráfico 2.5. Diagrama de casos de uso relacionados al lote de documentos ....52 Gráfico 2.6. Diagrama de clases.........................................................................57 Gráfico 2.7. Diagrama de estados del documento..............................................59 Gráfico 2.8. Diagrama de estados del lote de documentos ................................59 Gráfico 3.1. Arquitectura WEB de 3 capas: presentación, lógica de negocio y acceso a datos................................................................................61 Gráfico 3.2. Patrón de diseño MVC aplicado al proyecto ...................................62 Gráfico 3.3. Esquema de la comunicación WEB del proyecto............................64 Gráfico 3.4. Diagrama de secuencia: Consultar documentos.............................66 Gráfico 3.5. Diagrama de secuencia: Abrir documento ......................................67 Gráfico 3.6. Diagrama de secuencia: Registrar documento ...............................68 Gráfico 3.7. Diagrama de secuencia: Registrar documento en contabilidad ......69 Gráfico 3.8. Diagrama de secuencia: Aprobado documento en lote ..................70 Gráfico 3.9. Diagrama de secuencias: Contabilizar documento .........................71 Gráfico 3.10. Diagrama de secuencias: Consultar lote de documento.................72 Gráfico 3.11. Diagrama de secuencias: Registrar lote de documento..................73 Gráfico 3.12. Modelo entidad relación general del sistema..................................74 Gráfico 3.13. Modelo entidad relación para el documento ...................................75 VII Gráfico 3.14. Modelo entidad relación para el lote ...............................................76 Gráfico 3.15. Modelo entidad relación para el flujo y nivel ...................................76 Gráfico 3.16. Pantalla: Consultar documentos .....................................................86 Gráfico 3.17. Pantalla: Resultado de la consulta de documentos. .......................86 Gráfico 3.18. Pantalla: Abrir documento - Datos generales..................................87 Gráfico 3.19. Pantalla: Visualizar documento digitalizado....................................87 Gráfico 3.20. Pantalla: Abrir documento - Flujo de aprobación. ...........................88 Gráfico 3.21. Pantalla: Registrar documento ........................................................88 Gráfico 3.22. Pantalla: Registrar datos generales ................................................89 Gráfico 3.23. Pantalla: Registrar datos contables.................................................89 Gráfico 3.24. Pantalla: Registrar datos de la distribución .....................................90 Gráfico 3.25. Pantalla: Aprobar documento en lote ..............................................90 Gráfico 3.26. Pantalla: Aprobar documento individual..........................................91 Gráfico 3.27. Pantalla: Documentos por contabilizar............................................91 Gráfico 3.28. Pantalla: Contabilizar documento....................................................92 Gráfico 3.29. Pantalla: Editar documento – Datos Contables...............................92 Gráfico 3.30. Pantalla: Editar documento - Distribución .......................................93 Gráfico 3.31. Pantalla: Editar documento – Asiento contable...............................93 Gráfico 3.32. Pantalla: Consultar documentos vía extranet..................................94 Gráfico 3.33. Pantalla: Resultado de la consulta de documentos vía extranet.....94 Gráfico 3.34. Pantalla: Consultar lote de documentos..........................................94 Gráfico 3.35. Pantalla: Resultados de consultar lote de documentos ..................95 Gráfico 3.36. Pantalla: Abrir lote de documentos .................................................95 Gráfico 3.37. Pantalla: Registrar lote ....................................................................96 Gráfico 3.38. Pantalla: Registrar lote - Después que se consultan los documentos que se pueden agregar al lote ........................................................96 Gráfico 3.39. Pantalla: Registrar lote con los documentos físicos seleccionados. ........................................................................................................97 Gráfico 3.40. Pantalla: Lote de documentos registrado........................................97 Gráfico 3.41. Pantalla: Lotes de documentos por recibir ......................................98 Gráfico 3.42. Pantalla: Recibir lote de documentos..............................................98 Gráfico 3.43. Pantalla: Lote recibido.....................................................................98 1 1. Generalidades 1. 1. A continuación se explican los conceptos necesarios para comprender el problema que se desea resolver a través del desarrollo del presente proyecto, luego se mencionan algunas alternativas de solución existentes en el mercado, y finalmente se presenta la alternativa de solución que se plantea como parte del proyecto de tesis. 1.1. Definición del problema La gran mayoría de empresas a lo largo del ejercicio de su actividad económica, realizará adquisiciones de bienes y necesitará la prestación de diversos servicios como parte de la cadena de suministro, es decir, tendrá proveedores. Los proveedores emiten comprobantes de pago por los bienes entregados o servicios prestados, y la empresa debe encargarse de verificar que el detalle de cada documento sea el correcto, para luego proceder a su pago. Las pequeñas empresas y aquellas que tienen pocos proveedores, pueden manejar la revisión y aprobación de estos documentos con métodos manuales sin problemas. 2 En las medianas y grandes empresas, en especial si se encuentran organizadas en diversas áreas, el trámite de documentos de pago a proveedores puede ser complejo y puede necesitar de una o más revisiones y aprobaciones antes de llegar a la contabilidad de la empresa. Por este motivo un proceso manual obliga que el documento físico deba ser enviado sucesivamente a diversas oficinas. Por otra parte, si la institución cuenta con sistemas para realizar la solicitud de bienes y solicitud de prestación de servicios, sistema presupuestal y de pago, será necesario que estos sistemas se encuentren integrados al sistema de trámite de documentos de pago a sus proveedores. Sin embargo también se pueden presentar deficiencias. Tabla 1.1. Deficiencias detectadas en instituciones con procesos manuales. Deficiencia Descripción Confidencialidad. No se garantiza la confidencialidad de la información contenida en los documentos, ya que el documento es manipulado por diverso personal operativo, antes de llegar a manos del personal administrativo encargado de revisarlo y aprobarlo. Tiempo del trámite. El tiempo que toma la revisión y aprobación de los documentos no depende sólo del personal administrativo de cada una de las unidades involucradas, si no que, adicionalmente, depende del tiempo de envío, transporte y recepción del documento por las unidades que transite el documento. Conservación de los comprobantes de pago. El tránsito del documento a través de la institución ocasiona su maltrato, y en el peor de los casos, su extravío; lo que puede acarrear problemas de índole tributario con la Superintendencia de Administración Tributaria (SUNAT). Disponibilidad de los documentos Los documentos de pago a proveedores son requeridos después de su pago por unidades administrativas internas para algún análisis inherente a sus labores, por lo cual deben ser solicitados al archivo contable. 3 Tabla 1.2. Deficiencias detectadas en instituciones con sistemas informáticos de gestión del trámite de documentos de pago a proveedores. Deficiencia Descripción Se limitan sólo al registro y contabilización de los documentos. No proporcionan las funcionalidades necesarias para la revisión y aprobación. Funcionalidades insuficientes o deficientes Estas funcionalidades son muy restrictivas o limitadas. Interfases con los sistemas existentes. Deficiencias en la estandarización de interfases con los sistemas de adquisición de bienes y servicios, y con los sistemas de pago. Disponibilidad de los documentos. Las unidades administrativas requieren consultar los documentos físicos de pago a proveedores, durante o después del pago (para algún análisis relacionado a sus labores), por lo cual deben buscar el documento, durante el proceso de trámite, en la unidad en que se encuentre, o, después del trámite, en el archivo contable. 1.1.1. Definición de la situación actual del caso práctico El caso de aplicación práctica que se presenta es el realizado en la Pontificia Universidad Católica del Perú, la que en adelante denominaremos PUCP, institución educativa con más de 90 años de trayectoria en nuestro país. La PUCP es una institución que: • Se encuentra organizada en doscientos setenta y un unidades y sub-unidades (áreas). • En el 2008 ha adquirido bienes y servicios de catorce mil proveedores diferentes. • Recibe cuatrocientos cincuenta documentos de pago diarios en promedio, nueve mil documentos mensuales en promedio y más de cien mil documentos de pago a proveedores en el año 2008. • Sus documentos de pago a proveedores son tramitados a través de un sistema informático, sin embargo presenta deficiencias debido a nuevos requerimientos que no son soportados actualmente. 4 Los documentos de pago a proveedores son recibidos en la Oficina de Trámite Documentario en el campus universitario, o en las mesas de parte de las instalaciones externas de la universidad. En cada una de esas oficinas existe personal autorizado para el registro de estos documentos en el sistema existente. Este personal es el encargado de seleccionar el flujo de aprobación que debe seguir el documento, dependiendo adicionalmente del punto de registro del documento y del monto del documento Los documentos de pago que provienen de la solicitud de algún bien o servicio por alguno de los sistemas existentes en la institución deben ser enviados directamente a la oficina de contabilidad que le corresponda contabilizar el documento, a este recorrido se le conoce como “Flujo corto”. Los documentos de pago que no provienen de una solicitud vía sistema pasan por diversas oficinas, tales como la unidad responsable del documento, la Dirección de Administración, la Dirección de Servicios Económicos y en algunos casos Rectorado antes de llegar a la oficina de contabilidad correspondiente, es decir pasa por diferentes niveles de aprobación. A este recorrido se le conoce como “Flujo largo”. Algunas instalaciones externas de la universidad cuentan con una mesa de partes, y un representante de la oficina de contabilidad. La persona encargada de la mesa de partes cuenta con varios usuarios del sistema para simular que un documento sigue un flujo largo: ingresa al sistema con un usuario para registrar el documento, sale del sistema e ingresa nuevamente con otro usuario para aprobar el documento; esto lo realiza por cada nivel del flujo. Otras instalaciones externas sólo cuentan con una oficina de contabilidad. El encargado de la contabilidad cuenta con dos usuarios del sistema: ingresa al sistema con un usuario para registrar el documento, sale del sistema e ingresa nuevamente con otro usuario para contabilizarlo. En la PUCP se van a desarrollar nuevos sistemas de solicitudes de bienes y servicios, los cuales tendrán que alimentar el proceso de trámite de documentos de 5 pago a proveedores y los tipos de flujos de aprobación no son flexibles para poder cumplir con los requerimientos de integración necesarios. La Oficina de Contabilidad por su parte requiere descentralizar las tareas contables de aprobación de documentos de pago, para lo cual destaca personal contable a otras unidades de la institución para que desarrollen esta labor. El sistema actual permite que se creen nuevos flujos de aprobación, donde se pueden configurar nuevas oficinas contables, pero la confidencialidad de la información es pobre, ya que todos los usuarios con permisos contables pueden visualizar los documentos de todos los niveles contables del sistema. De forma paralela, se envían los documentos de pago a proveedores, a cada unidad de su flujo de aprobación, por lo cual los documentos son manipulados por personal operativo antes de llegar a manos del personal administrativo encargado de la revisión y aprobación. El tránsito de los comprobantes de pago por las unidades de la institución ocasionan su maltrato y en el peor de los casos su extravío. Los sistemas existentes de adquisición de bienes y servicios se han integrado al sistema de trámite documentario, cada interfaz brinda distintas facilidades, por lo cual se hace necesario que las interfases se estandaricen. Ante esta situación se decide plantear un nuevo sistema de trámite de documentos de pago a proveedores, el cual permita cubrir las deficiencias existentes y que proporcione escalabilidad, lo cual le permitirá adaptarse a futuros requerimientos. Tabla 1.3. Resumen de deficiencias detectadas en la PUCP. Deficiencia Descripción Confidencialidad. • No se garantiza la confidencialidad de la información registrada. Cualquier usuario con acceso al sistema puede consultar los documentos registrados. • Los comprobantes de pago además son enviados para su revisión y aprobación a cada unidad involucrada, siendo manipulados por personal operativo. Tiempo del trámite. • Los comprobantes de pago son enviados para su revisión y aprobación a cada unidad involucrada, generando demora en trámite. 6 Conservación de los comprobantes de pago. • El tránsito de los comprobantes de pago por las unidades de la institución ocasionan su maltrato y en el peor de los casos su extravío. Funcionalidades insuficientes o deficientes • El sistema existente permite la revisión y aprobación de documentos, sin embargo, los flujos de aprobación no cubren la demanda de nuevos flujos que requiere la institución. • Los flujos existentes no reflejan la realidad del flujo de aprobación que debe seguir el documento dentro de la institución. Interfases con los sistemas existentes. • Es necesaria la estandarización del proceso de integración con los sistemas de solicitudes de bienes y servicios existentes en la institución. Disponibilidad de los documentos. • Las unidades administrativas requirieren consultar los documentos físicos de pago a proveedores para algún análisis inherente a sus labores, por lo cual deben buscar el documento, durante el proceso de trámite, en la unidad en que se encuentre, o, después del trámite, en el archivo contable. 1.2. Marco conceptual En esta sección se presenta la teoría fundamental básica necesaria para entender el problema y la solución que plantea el presente proyecto de tesis. 1.2.1. Identificación de conceptos A continuación se presentan los conceptos necesarios para entender el problema y la solución propuesta. Tabla 1.4. Conceptos necesarios para entender el problema planteado y su solución. Concepto Descripción Unidad Área que forma parte integrante de la institución. Cada unidad es creada con una finalidad, por lo que tiene la responsabilidad y la capacidad de administrar eficientemente los recursos que se les asigna. Sub-unidad Área dependiente de una Unidad. Cada sub-unidad ha sido creada para poder distribuir las funciones que realiza cada unidad, con la finalidad de facilitar la administración de la misma. En adelante se usará solo el término unidad para referirse tanto a unidad como sub-unidad. Actividad Cada unidad realiza una serie de actividades, las cuales deben cuantificarse. Una actividad es un centro de costos en donde se registrarán todos los ingresos y egresos vinculados a la misma. 7 Centro de costo Es una unidad o subdivisión mínima en el proceso de registro contable en la cual se acumulan los gastos en la actividad productiva de la empresa con el fin de facilitar la medición de los recursos utilizados y los resultados económicos obtenidos. Unidad Responsable Unidad que solicitó el bien o servicio. Es la unidad que se encargó de las coordinaciones con el proveedor. Nivel Representación dentro del sistema de la unidad de la institución que debe revisar y aprobar los documentos de pago a proveedores durante su trámite. Documento físico Comprobante de pago emitido por el proveedor de la institución. Documento de trámite Es el registro en el sistema de trámite de documentos de pago a proveedores del comprobante de pago emitido por el proveedor. Documento de referencia Número que relaciona un documento de pago a proveedores con la solicitud realizada a través de un sistema de solicitudes de bienes o servicios existentes en la institución. Sistema de referencia Sistema de solicitudes de bienes o servicios que tiene interfaz con el sistema de trámite de documentos de pago a proveedores. Lote de documentos Agrupación de documentos de trámite, usado para el transporte de los documentos físicos a través de la institución. Flujo de aprobación Secuencia ordenada de niveles por el cual debe pasar el documento de trámite para su revisión y aprobación. Asiento contable Registro en el sistema de un hecho económico que generalmente provoca una modificación en el patrimonio de la institución. Asiento de extorno Asiento que permite el registro de la devolución, retorno, reintegración, etc. En el caso práctico se utiliza este tipo de asiento para registrar la reversión de la contabilización del documento. Cuenta contable Representación y medida de un elemento patrimonial, que capta la situación inicial de éste y las variaciones que se vayan produciendo en el mismo. Partida presupuestal Clasificación de cada rubro al que se le asignará un monto de dinero dentro del presupuesto. Compromiso presupuestal Reserva de dinero del presupuesto por haber solicitado la compra de algún bien o servicio. Contabilizar Acción de registrar el asiento contable de provisión de pago del bien o servicio que adquiere la institución, se realiza en los niveles contables. Descontabilizar Acción que permite revertir la acción de Contabilizar mediante el registro de un asiento de extorno. Periodo contable Período de tiempo al que se refiere la información contenida en el balance, cuenta de pérdidas y ganancias.. Gravar Imponer un tributo a la adquisición de un bien o servicio. 8 Retención Mecanismo diseñado por la SUNAT para mejorar la recaudación tributaria sin tener que ampliar la base de empresas supervisadas. Para el proyecto la retención representa el monto que la PUCP como agente de retención recauda en nombre del estado. Campus Virtual Herramienta de apoyo al proceso de enseñanza-aprendizaje integrada al sistema de información académico-administrativo de la PUCP. 1.2.2. Roles del negocio A continuación se presentan los roles del negocio. Tabla 1.5. Roles del negocio. Rol Descripción Registrador Rol encargado de la recepción de los documentos de pago a proveedores, de registrarlos en el sistema de trámite de documentos. Encargado de Unidad Rol encargado de la revisión y aprobación del documento de trámite en una unidad dentro de la institución. Este rol representa tanto al encargado de aprobar el trámite en la unidad responsable de las coordinaciones con los proveedores, y a los encargados de aprobar el trámite dentro de las unidades administrativas de la institución, tales como Dirección de Administración, Dirección de Servicios Económicos, etc. Asistente Rol encargado del registro, envío y recepción de lotes de documentos. Contador Rol encargado de la última revisión del documento de trámite, encargado de registrar la información contable inherente al documento, contabilizar y enviar el documento al área encargada del pago. Proveedor Rol que permite consultar los documentos emitidos por un proveedor a la institución. Supervisor Rol que representa las autoridades administrativas de la institución que necesiten supervisar el proceso de trámite de documentos de pago a proveedores tales como auditores o altos directivos. 9 1.3. Estado del arte En la PUCP, la institución del caso práctico, se resuelve el problema planteado a través de un sistema cliente servidor de trámite de documentos a proveedores y de un proceso manual paralelo para la aprobación de estos documentos. A continuación se presentan algunas alternativas de solución existentes en el mercado y sus principales características. Estas opciones cumplen algunas de las necesidades existentes en la institución o brindan mayor funcionalidad que la requerida. La presente tesis es la mejor alternativa de solución pues cumple con todas las necesidades actuales de la institución. 1.3.1. Soluciones existentes Tabla 1.6. Módulo de tramite documentario SICOP Producto Módulo de tramite documentario, Sistema Contable Presupuestal, SICOP Autor Top Level Corporation Descripción general del sistema. Sistema que permite el registro de documentos de pago a proveedores. Ofrece un grupo de flujos de trámite por los que puede ser aprobado el documento y la posterior contabilización de los documentos. Es el sistema que utiliza actualmente la PUCP. Funcionalidades relacionadas al trámite de documentos de pago a proveedores • Registro de documentos de pago. • Aprobación de documentos de acuerdo a flujos de aprobación. • Integración con el sistema que gestiona los pagos de la institución. Observaciones Se presentan las deficiencias presentadas en el punto 1.1 Definición del problema. 10 Tabla 1.7. SAP Enterprise Buyer Professional Producto SAP Enterprise Buyer Professional Autor SAP Descripción general del sistema El sistema cuenta con las facilidades para realizar ofertas electrónicas y subastas inversas, procesos de licitaciones, manejo de contratos, gestión de contenidos de los catálogos digitales, manejo de procesos de compras directas end-to-end, entre otros. Además, contempla los procesos de manejo de los catálogos de proveedores en línea, selección de automática y manual de proveedores, la generación de requisiciones por el usuario final, su aprobación vía Workflow. Cubre también la ejecución completa del proceso de aprovisionamiento, desde el pedido, elaboración de órdenes de compra, seguimiento de las mismas, recepción del bien o servicio, envío y recepción de documentos al proveedor vía Internet, facturación y pago. Los proveedores sólo necesitan disponer de un navegador WEB para tener acceso a los procesos de esta aplicación. Permite la integración con el ERP de la organización. Funcionalidades relacionadas al trámite de documentos de pago a proveedores • Recepción de documentos de pago vía intranet. • Integración con el ERP o sistema encargado de gestionar los pagos de la institución. • El proveedor puede consultar los documentos de pago emitidos a la institución. Observaciones Este sistema presenta una alternativa de solución interesante para la gestión de la logística de la institución. Sin embargo para el caso práctico que presenta la institución no constituye una alternativa viable de solución debido a que las funcionalidades que soportan el trámite de aprobación de los documentos de pagos son pobres o inexistentes. 11 Tabla 1.8. Workflow de aprobación de Documentos Tributarios Producto Workflow de aprobación de Documentos Tributarios Autor MICROSYSTEM Descripción general del sistema Sistema que permite la aprobación, recepción y gestión de compras y pago de proveedores, que permite cubrir de manera integral el ciclo completo desde la solicitud de compra hasta la aprobación del documento tributario en forma electrónica y en tiempo real. Administra el ciclo completo en tiempo real y en forma virtual, sin mover los documentos físicos, controlando cada una de las actividades del proceso, generando las alarmas correspondientes. Se puede plantear la integración del Workflow con los sistemas internos de cada organización. Funcionalidades relacionadas al trámite de documentos de pago a proveedores • Aprobación de los documentos tributarios de la institución. • Gestión del pago a proveedores. Observaciones Este sistema presenta una alternativa de solución interesante para la gestión de la logística y pago a proveedores de la institución. Para el caso práctico puede ser una alternativa de solución, será necesario que la institución se adecue al Workflow que propone el sistema, o que este se modifique de tal forma que se ajuste a las necesidades de la institución. 12 1.4. Descripción y sustentación de la solución La presente tesis propone solucionar el problema planteado con un sistema de “Trámite de documentos de pago a proveedores vía Intranet”. Este sistema será la alternativa al sistema informático existente y de un proceso manual paralelo para la aprobación de estos documentos que tiene la institución. El sistema puede ser implementado dentro de cualquier institución organizada en unidades. Permite el registro, revisión, aprobación y contabilización de los documentos de pago a proveedores, a través de un flujo de aprobación organizado por niveles, que facilite el adecuado y oportuno seguimiento por parte de las unidades involucradas de la institución y de los proveedores. La institución tendrá la facilidad de definir los flujos de aprobación que debe seguir cada documento, de acuerdo al tipo de sistema por el que se haya solicitado el bien o servicio y la unidad responsable de la solicitud. Podrá definir la centralización o descentralización de cada etapa del trámite según sus necesidades, para proporcionar seguridad y confidencialidad de la información. 1.4.1. Objetivos El objetivo del presente trabajo de tesis es desarrollar una aplicación vía Intranet que permita el trámite de documentos de pago a proveedores, que podría ser implementada dentro de cualquier institución organizada en unidades. A manera de aplicación práctica se presentará el análisis y diseño del sistema para la Pontifica Universidad Católica del Perú. Los objetivos específicos del presente proyecto son: • Elaborar el análisis y diseño del sistema que cubra todos los requerimientos establecidos que será implementado bajo una arquitectura Web J2EE orientada a objetos. • Diseñar un sistema que brinde las facilidades para definir los flujos de aprobación que sean necesarios dentro de la institución en cualquier momento, 13 evite la pérdida y/o deterioro de los documentos físicos y evite la duplicidad de documentos a tramitar. 1.4.2. Alcance • El sistema será desarrollado en la Intranet de la institución, de esta manera permitirá a los usuarios acceder al sistema desde cualquier plataforma, en cualquier momento y lugar. • El sistema permitirá la digitalización, registro, revisión, aprobación y contabilización de documentos de pago a proveedores dentro de una institución organizada en unidades, mediante una interfaz de usuario amigable e intuitiva. • El sistema permitirá a las unidades involucradas realizar el seguimiento del documento durante todo el proceso de trámite, desde que el documento se registra en este sistema hasta que es pagado en el sistema de pagos de la institución. También permitirá que el proveedor conozca el estado del trámite de los documentos que le emite a la institución. • El sistema permitirá que se adjunte el documento digitalizado al trámite, para evitar el maltrato o extravío del documento de pago físico durante su tránsito a través de las oficinas de la institución. • El sistema permitirá el envío de mensajes electrónicos cuando un documento deba ser revisado por el nivel correspondiente dentro del flujo de aprobación. • El sistema permitirá que los flujos de trámite sean definidos por la institución según sus necesidades, con los niveles de aprobación que considere conveniente. • El sistema contemplará las interfaces y validaciones necesarias para la integración con los sistemas de compras de bienes y adquisición de servicios existentes en la institución, y con el sistema de pagos institucional. 14 • El sistema generará reportes que permitan conocer el estado de los documentos de pago en cualquier nivel del flujo de aprobación, con diferentes niveles de detalle y según perfil de usuario que los consulte. 1.4.3. Reingeniería de los procesos del negocio Se propone cambios en los procesos del negocio con la finalidad de ordenarlos, para que con la ayuda del sistema propuesto se logre el éxito del proyecto. Cada flujo de aprobación estará conformado por uno o más niveles, cada nivel estará a cargo de una unidad de la institución. Los permisos de usuarios otorgados en el sistema serán por nivel. Los niveles pueden ser del tipo registro, unidad o contable. El flujo se iniciará en un nivel de registro o contable y puede contener uno o más niveles del tipo unidad. El nivel final del flujo de aprobación en este sistema debe ser un nivel contable donde se procede con la contabilización del comprobante. Se guardará la información de la oficina de donde se realizará el pago del documento, se denominará nivel tesorería, y servirá como parte de la interfaz con el sistema de pagos. Un nivel puede formar parte de uno o más flujos de aprobación. 1.4.3.1. Recepción de documentos de pago a proveedores La recepción de documento de pagos es un proceso manual, el responsable de este proceso es el rol registrador. Ver Gráfico 1.1 Este proceso se inicia cuando el documento físico llega a la mesa de partes, u oficina destinada para la recepción de documentos de pago a proveedores, de manos del proveedor. Si el documento de pago tiene referencia, es decir es consecuencia de una solicitud realizada mediante alguno de los sistemas de adquisición de bienes o servicios de la institución, el registrador verifica que el proveedor haya indicado el número de documento referencia, si no tuviera el número el documento no se recibe. 15 Si el documento no tiene referencia, el registrador debe verificar si el proveedor se encuentra en el listado proporcionado por la institución de proveedores autorizados. Si el proveedor es autorizado el registrador debe verificar que el proveedor haya indicado cual es la unidad responsable del documento, si no tiene el código de la unidad responsable el documento no se recibe. Este proceso de verificación es manual porque el listado de proveedores autorizados varía de manera constante. Los documentos que son recibidos son marcados mediante un dispositivo de timbrado, que le coloca un número correlativo de recepción. Gráfico 1.1. Diagrama de actividades de la recepción de documentos de pago a proveedores. Nivel Registro - Registrador Verificar si es documento autorizado Recibir y Timbrar documento Rechazar documento Solicitar codigo de unidad responsable Solicitar número de referencia Proveedor Inicio Presentar el documento de pago [sin numero]/Rechazar [con numero]/Recibir [sin código]/Rechazar[con codigo]/Recibir [no autorizado]/Rechazar [tiene referencia]/Solicitar [no tiene referencia]/ Verificar [autorizado]/ Solicitar 1.4.3.2. Trámite del documento en un nivel de registro El trámite de documentos en la oficina de registro o nivel de registro es un proceso soportado por el nuevo sistema, el responsable de este proceso es el rol registrador. Ver Gráfico 1.2. Este proceso tiene las siguientes actividades: Verificar número de r f r i Verificar código de i r l 16 1.4.3.2.1. Registro del documento Se registran los dígitos del número de timbrado para completar los 4 últimos caracteres del número de documento de trámite. El número de trámite está conformado por 2 últimos caracteres del año, 2 caracteres del mes, 3 caracteres del código del nivel y los 4 últimos consecutivos por nivel. El sistema registra como fecha de recepción el día actual y la fecha de pago a 30 días, esta fecha puede variar según el tipo de documento físico. Si el documento tiene número de documento de referencia: El registrador selecciona el sistema de referencia e ingresa el número de documento de referencia (será posible realizar una búsqueda de los documentos registrados en el sistema de referencia seleccionado). El sistema mostrará la siguiente información de la interfase con el sistema de referencia correspondiente: el tipo de documento físico, el R.U.C. y razón social del proveedor, la moneda, el monto total del documento y la unidad responsable. El registrador ingresa la serie y número, la fecha de emisión y se adjunta el documento físico; , la clasificación del trámite y si desea ingresa alguna observación. Si el documento no tiene referencia: El registrador indica que no se tiene sistema de referencia, selecciona el tipo de documento físico e ingresa la serie y número, la fecha de emisión y se adjunta el documento físico, ingresa además el R.U.C. y razón social del proveedor, la moneda y el monto total del documento, la unidad responsable, la clasificación del trámite y si desea ingresa alguna observación. El sistema seleccionará el flujo de trámite que debe seguir el documento dependiendo del nivel de registro en que se encuentre, del tipo de documento de referencia al que se encuentre relacionado (también existe un flujo cuando el documento no tiene referencia) y a la unidad responsable del documento. El registrador es el encargado de adjuntar el documento digitalizado al documento de trámite. Para apoyar en el registro de los datos, se tendrá la funcionalidad de búsqueda de documentos en cada uno de los sistemas de referencia. 17 Gráfico 1.2. Diagrama de actividades del trámite del documento en un nivel de registro Nivel Registro - Registrador Registrar documento Anular trámite del documento Inicio Fin Enviar documento - Envia el documento hacia el siguiente nivel del flujo (nivel del tipo unidad o nivel contable). - Envío de correo automático al nivel destino. - Correo automático al nivel donde se encuentra el documento fisico para tramitar la devolución del documento al proveedor. Revisar documento [error en documento]/ Anular [documento ok]/ Enviar 1.4.3.2.2. Revisión del documento Si el documento tiene número de documento de referencia: Si los datos mostrados, provenientes de la interfase con el sistema de referencia, no coinciden con el documento de referencia o la información del documento de referencia no se encuentra en la interfase, no se graba el documento de trámite. El registrador coordina con la unidad responsable para que corrija la información del sistema de referencia o coordine el cambio del documento con el proveedor (en este caso el documento deberá ser anulado) para intentar nuevamente su registro. Si toda la información es correcta, el registrador procede a grabar la información. El flujo de aprobación de los documentos sólo puede ser cambiado desde el nivel de registro del documento, por tal motivo el registrador es el encargado de cambiar 18 este dato en el documento de trámite si fuera necesario (por lo general en caso de devolución) 1.4.3.2.3. Anulación del trámite del documento El registrador puede anular el trámite de un documento, si el documento físico debe ser entregado al proveedor. 1.4.3.2.4. Envío del documento El registrador envía virtualmente el documento de trámite al siguiente nivel del flujo de aprobación. El sistema informa que deben proseguir el trámite vía correo electrónico a los usuarios del siguiente nivel. El flujo de aprobación es una secuencia ordenada de niveles, el sistema decide cual es el siguiente nivel al que se enviará el documento evaluando si el monto del documento se encuentra en el rango que revisa y/o autoriza dicho nivel, caso contrario envía el documento hacia el nivel contable del flujo de aprobación correspondiente. 1.4.3.3. Trámite de documentos en un nivel unidad Un nivel unidad representa tanto a las unidades responsables de las coordinaciones con los proveedores, como a las unidades administrativas de la institución tales como la Dirección de Administración, Dirección de Servicios Económicos, etc. El documento de trámite debe ser revisado y aprobado en las unidades correspondientes al flujo de aprobación por el encargado de la unidad. Es posible también que el encargado de la unidad devuelva el documento al nivel de registro o anule el trámite del documento. Ver Gráfico 1.3. Este proceso tiene las siguientes actividades: 19 Gráfico 1.3. Diagrama de actividades del trámite de documentos en un nivel unidad Nivel Unidad - Encargado de Unidad Revisar documento Aprobar documento Devolver documento Anular trámite del documento Fin - Es devuelto al nivel de registro para la corrección de los datos y/o cambio de flujo. - Correo automático al nivel destino. Recibe el documento desde un nivel de registro o unidad - Envia el documento hacia el siguiente nivel del flujo (unidad o contable). - Correo automático al nivel destino. - Correo automático al nivel donde se encuentra el documento fisico para tramitar la devolución del documento al proveedor. [documento ok]/Aprobar [error en registro]/Devolver [error en documento]/Anular 1.4.3.3.1. Revisión del documento El encargado de la unidad verifica que los datos del documento de trámite coincidan con el documento digitalizado adjunto. Si encuentra alguna diferencia debe devolver virtualmente el documento al nivel de registro correspondiente para que se realice el cambio de flujo de aprobación. Si el nivel unidad tiene permisos para acceder a la información presupuestal, puede registrar y/o revisar la distribución del cargo, donde debe distribuir el monto total del documento sin impuestos entre las unidades/actividades (centros de costos) que se vieron beneficiadas con el bien o servicio, en la partida presupuestal correspondiente. 20 1.4.3.3.2. Aprobación del documento El encargado de la unidad aprueba el documento de trámite. El sistema envía virtualmente el documento de trámite al siguiente nivel del flujo de aprobación. El sistema informa vía correo electrónico a los usuarios del siguiente nivel que deben proseguir el trámite. El flujo de aprobación es una secuencia ordenada de niveles, el sistema decide cual es el siguiente nivel al que se enviará el documento evaluando si el monto del documento se encuentra en el rango que revisa y/o autoriza dicho nivel, caso contrario envía el documento hacia el nivel contable del flujo de aprobación correspondiente. 1.4.3.3.3. Devolución del documento Si los datos del documento físico, que pueden ser visualizados en el sistema gracias al documento digitalizado, no coinciden con los datos del documento de trámite el encargado de unidad puede devolver virtualmente un documento de trámite a su nivel de registro para que sea corregido. El sistema informa a los usuarios del nivel de registro vía correo electrónico que deben corregir el documento para proseguir el trámite. 1.4.3.3.4. Anulación del trámite del documento El encargado de unidad puede anular el trámite de un documento, si el documento físico debe ser entregado al proveedor. El sistema informa a los usuarios del nivel donde se encuentra el documento físico vía correo electrónico que deben enviar el documento al nivel de registro para entregarlo al proveedor. 21 1.4.3.4. Trámite de documentos en un nivel contable El documento de trámite debe ser revisado y procesado contablemente en el nivel contable correspondiente al flujo de aprobación por el rol contador. Es posible también que el contador devuelva o anule un documento de trámite. El rol registrador contable se encarga del registro de los documentos en el nivel contable. Ver Gráfico 1.4. Este proceso tiene las siguientes actividades: 1.4.3.4.1. Registro de documentos El registrador contable se encarga del registro de los documentos en el nivel contable. La funcionalidad de registro en el nivel contable sólo debe ser usada en casos excepcionales, por ejemplo en algún pago urgente; el registro de documentos debe realizarse a través de un nivel de registro. El registro de los datos generales del documento es similar al del nivel de registro. El registrador contable además puede registrar datos contables adicionales para la contabilización del documento (que serán explicados en la revisión contable). 1.4.3.4.2. Revisión del documento El contador revisa el documento de trámite en última instancia en la oficina contable y verifica que los datos del documento de trámite coincidan con el documento digitalizado adjunto. El contador debe registrar los siguientes datos contables: el origen del documento, si es nacional o extranjero, la forma sugerida de pago, el indicador de pago (si el documento está ingresando el trámite para regularización y ya ha sido pagado, o si se encuentra por pagar), el tipo de transacción contable, sólo si se desea cambiar el asiento estándar que se genera por el tipo de documento ingresado, si el documento debe ser pagado a una persona jurídica diferente al proveedor, puede ingresar el valor de venta, el porcentaje o importe del impuesto correspondiente al tipo de documento, un monto que permita ajustar algunas diferencias entre los montos que figuran en el documento, y el monto total del documento que debe coincidir con el monto total original ingresado en los datos generales del documento. También debe registrar las retenciones que se le deban aplicar al 22 documento, indicando el tipo de retención, el porcentaje e importe de la retención, el tipo de bien y el tipo de operación. Si el documento no tiene referencia: El contador debe registrar la siguiente información de la distribución del cargo del asiento (que contiene información contable-presupuestal y actualmente se conoce como distribución): cuenta contable, partida presupuestal, gravación, importe por cada unidad/actividad (centro de costo). El monto distribuido corresponde al monto total sin impuestos. Si el documento tiene número de documento de referencia: El sistema le muestra la siguiente información de la distribución del cargo del asiento: cuenta contable, partida presupuestal, importe por cada unidad/actividad. El contador podrá modificar esta información y debe registrar la gravación por cada unidad/actividad. Adicionalmente si es necesario distribuir el abono del asiento el contador debe registrar la siguiente información: cuenta contable, importe por cada unidad/actividad (centro de costo). El monto distribuido corresponde al monto total (incluyendo a impuestos). 1.4.3.4.3. Contabilización del documento El contador procede a contabilizar el documento cuando toda la información se encuentra completa. El sistema generará el asiento contable de provisión del pago según la información ingresada, principalmente la distribución contable presupuestal, la distribución del abono del asiento, y la transacción seleccionada en los datos contables si existiera. 1.4.3.4.4. Reversión de la contabilización del documento El contador procede a revertir la contabilización del documento cuando se deba realizar alguna corrección en la información contable. El sistema registra un asiento de extorno. 23 Gráfico 1.4. Trámite de documentos en un nivel contable Nivel Contable - Contador Revisar documento Devolver documento Contabilizar documento Anular trámite del documento Fin - Es devuelto al nivel de registro para la corrección de los datos y/o cambio de flujo. - Correo automático al nivel destino. - Es enviado hacia la tesorería correspondiente Recibe el documento del nivel de registro o unidad. Fin Enviar documento Nivel Contable - Registrador Inicio Registrar documento - Correo automático al nivel donde se encuentra el documento fisico para tramitar la devolución del documento al proveedor. [error en registro]/ Devolver [error en documento]/Anular[documento ok]/ Contabilizar [contabilización ok] [error al contabilizar]/Descontabilizar 1.4.3.4.5. Aprobación del documento El contador aprueba el documento de trámite, el sistema envía virtualmente el documento de trámite al nivel de pago correspondiente. El sistema informa vía correo electrónico a los usuarios del nivel de pago que deben procesar el pago del documento. 1.4.3.4.6. Devolución del documento Si los datos del documento físico no coinciden con los datos del documento de trámite el contador puede devolver virtualmente un documento de trámite a su nivel de registro para que sea corregido. El sistema informa a los usuarios del nivel de registro vía correo electrónico que deben corregir el documento para proseguir el trámite. 24 1.4.3.4.7. Anulación del trámite del documento El contador puede anular el trámite de un documento, si el documento físico debe ser entregado al proveedor. El sistema informa a los usuarios del nivel donde se encuentra el documento físico vía correo electrónico que deben enviar el documento al nivel de registro para entregarlo al proveedor. 1.4.3.5. Trámite de los documentos físicos Los documentos físicos sólo viajarán dentro de la institución cuando formen parte de un lote de documentos. Ver Gráfico 1.5 y 1.6. Este proceso tiene las siguientes actividades: 1.4.3.5.1. Registro y envío de lotes de documentos con documentos físicos al nivel de archivo El asistente del nivel de registro crea un lote de documentos para enviar los documentos físicos al nivel contable encargado del archivo contable de la institución. 1.4.3.5.2. Registro y envío de lotes de documentos con documentos físicos por anulación del trámite. El asistente del nivel contable (encargado del archivo contable de la institución) crea un lote de documentos que se encuentra en el archivo contable, para ser enviados al nivel de registro, porque el documento de trámite fue anulado y el documento físico debe ser entregado al proveedor. 25 1.4.3.5.3. Recepción de lote de documentos. El asistente del nivel destino del lote de documentos es el encargado de recibir los lotes, para realizar esta acción debe esperar que el lote con los documentos físicos llegue a su nivel, ya que debe indicar en el sistema explícitamente que documentos llegaron dentro del lote. En caso uno o más documentos no hayan llegado, no se deben marcar para que ese documento pueda ser enviado en otro lote de documentos desde el nivel origen. 1.4.3.5.4. Anulación de lote de documentos. El asistente del nivel origen puede anular un lote de documentos de trámite si no se seguirá con el trámite de dicho lote. Gráfico 1.5. Diagrama de actividades del lote de documentos enviado hacia el nivel de archivo contable. Nivel de Registro o Nivel Contable - Asistente Registrar lote con documento(s) Anular lote Enviar lote Fin - Impresión opcional. - Envío de correo automático al nivel destino. - Se deben enviar los documentos fisicos al nivel destino. Inicio Nivel Contable: Contabilidad Campus - Asistente Recibir lote con documento(s). Fin - Deben esperar a que lleguen los documentos físicos para realizar esta actividad. - Es necesario marcar los documentos que se han recibido, antes de Recibir el lote. Los documentos que no sean marcados deberán ser enviados en otro lote. [lote ok]/Enviar[error en lote]/Anular 26 Gráfico 1.6. Diagrama de actividades del lote de documentos enviado hacia el nivel de registro Nivel Contable: Contabilidad Campus - Asistente Inicio Registrar lote con documentos (s) Anular lote Enviar lote Fin Nivel Registro: Of. Trámite Documentario - Asistente Recibir lote con documento(s) [error en lote]/Anular [lote ok]/Enviar Fin 27 1.4.4. Ventajas de la solución propuesta El sistema propuesto plantea solucionar las deficiencias existentes tanto en los sistemas encontrados en el mercado, como en el caso práctico. La siguiente tabla contiene el detalle de las deficiencias que serán superadas y las características del nuevo sistema que las superan. Tabla 1.9. Deficiencias que serán superadas con el sistema de trámite de documentos de pago a proveedores vía intranet Deficiencias superadas Características que permiten que la deficiencia sea superada. Confidencialidad • Los documentos físicos no son enviados a través de las unidades involucradas en el flujo de aprobación, por lo que el personal operativo de cada unidad no tendrá acceso a estos documentos. • El documento digitalizado adjunto al documento de trámite sirve para la verificación de la información ingresada en el sistema, por lo que son visualizados sólo por el personal administrativo correspondiente. • Los perfiles de usuario del sistema, permitirán que sólo el personal involucrado en el trámite de cada documento tenga acceso a la información del mismo. • Los documentos físicos son enviados del nivel de registro al nivel encargado del archivo contable mediante un lote de documentos. • Los usuarios del sistema consultan la información inherente a su perfil de usuario. Cada usuario tiene acceso a la información de uno o más niveles. Tiempo del trámite • El documento de trámite es aprobado en el sistema y no se necesita del documento físico para ello ya que cuenta con el documento digitalizado adjunto. Por este motivo no se espera a que el documento físico llegue a cada unidad involucrada, esto disminuirá el tiempo de trámite del documento. • El tiempo de trámite dependerá del tiempo que tome el registro y digitalización del documento, más el tiempo que tome su aprobación en cada unidad. Conservación de los comprobantes de pago • Los documentos físicos no son enviados a través de las unidades involucradas, evitando su deterioro o pérdida. • Los documentos físicos son enviados dentro de un lote de documentos, del nivel de registro al nivel de archivo contable para su cuidado y conservación. • El documento físico es enviado del nivel de archivo contable al nivel de registro, para ser entregado al proveedor. • Sentadas las bases para el archivo digital de documentos, cuando alguna unidad necesite el documento físico no será necesario solicitarlo al archivo. 28 Funcionalidades insuficientes o deficientes • Se permite la creación de nuevos flujos de trámite, los cuales podrán ser creados en cualquier momento, según las necesidades de la institución. • Se adjunta el documento digitalizado al documento de trámite. • La estructura del sistema permitirá su desarrollo incremental, beneficiando a la institución ante el surgimiento de nuevos requerimientos. Interfases con los sistemas existentes. • Se define el esquema de integración para estandarizar las interfases con los sistemas existentes de solicitud de bienes y servicios, el mismo que será usado con los nuevos sistemas. Disponibilidad de los documentos • Los documentos de trámite y los documentos digitalizados son consultados desde cualquier computadora con conexión a Internet, mediante el acceso a la intranet institucional. • Se conoce el estado del documento de trámite y el nivel en el que se encuentra en cualquier momento. • Se sientan las bases para el archivo digital de documentos de la institución, lo que permitirá la consulta de los documentos sin necesidad de extraer los documentos físicos de los archivos. Optimización de los procesos de negocio • Los procesos del negocio son organizados y soportados con las herramientas que ofrece el sistema. 29 2. Análisis 2. A continuación se explica la metodología a utilizar, los requerimientos funcionales y no funcionales, obtenidos a través de reuniones con los usuarios involucrados en las acciones que afectará el sistema (stakeholders), y se presentan los siguientes artefactos: Casos de Usos, Diagrama de clases y Diagramas de estados. 2. 2.1. Metodología a utilizar En el desarrollo de este proyecto se empleó una metodología Orientada a Objetos (OO), basándose en el Proceso Unificado de Desarrollo de Software RUP (Rational Unified Process en inglés). RUP se basa en los siguientes 6 principios [Shuja, Krebs]: • Establece un conjunto de fases adaptables al contexto y necesidades de cada proyecto. • Permite balancear las prioridades de las partes interesadas. • Promueve la colaboración a través de equipos. • Permite obtener productos en cada iteración del proyecto. Permite la evaluación al terminar cada iteración, para redefinir e iniciar la siguiente iteración. 30 • Promueve elevar el nivel de abstracción durante el proyecto, lo cual motiva el uso de conceptos reutilizables, el análisis de soluciones arquitectónicas, la reutilización del código y la representación visual del proyecto mediante el Lenguaje Unificado de Modelado (UML), como en este proyecto. Este principio evita que el ingeniero de software vaya directamente de los requisitos a la codificación. • Controla la calidad en todos los aspectos de cada iteración. Esta metodología fue seleccionada por los siguientes motivos: • Es un marco de trabajo que permite el desarrollo exitoso de software iterativo e incremental [Larman]. • Junto con UML, constituye la metodología estándar más utilizada para el análisis, diseño e implementación de sistemas orientados a objetos. • El proyecto se desarrolla de acuerdo a los principios que plantea esta metodología. • Esta metodología es utilizada para el desarrollo de software dentro de la institución donde se aplica el caso práctico. El proyecto abarca las dos primeras fases del ciclo de vida del proceso unificado. Ver gráfico 2.1. Iniciación: fase en la que se definen los diferentes alcances del proyecto y se describen con los casos de uso. Elaboración: fase en la que se realiza la planificación del proyecto, se especifican en detalle los casos de uso y se realiza el diseño de la arquitectura del sistema sin llegar a la especificación del método de programación. Se presenta a continuación 2 tablas con los marcos de trabajos seguidos durante este proyecto, el primer marco de trabajo organizado por flujos de trabajo del proceso unificado y el segundo marco de trabajo organizado por fases del proceso unificado, en ambos marcos se pueden visualizar los artefactos obtenidos. 31 Gráfico 2.1. Ciclo de vida RUP. Tabla 2.1. Marco de trabajo organizado por flujos de trabajo fundamentales del Proceso Unificado, aplicado en proyecto. Flujo de trabajo fundamental Artefacto Modelado del negocio Procesos del negocio Diagrama de actividades Requerimientos Visión del proyecto. Diagrama de casos de uso y Especificación de casos de uso. Análisis Diagrama de clases. Diagrama de secuencia de sucesos. Diagrama de estados. Diseño Diagrama de componentes. Modelo entidad relación. Prototipo. Implementación No es parte de la presente tesis. Pruebas No es parte de la presente tesis. 32 Tabla 2.2. Marco de trabajo organizado por fases del Proceso Unificado, aplicado en el proyecto. Fase Artefacto Inicio Modelado del negocio - Procesos del negocio Modelado del negocio - Diagramas de actividades Requerimientos - Visión del proyecto. Requerimientos - Diagrama de casos de uso. Elaboración Requerimientos - Diagrama de casos de uso y Especificación de casos de uso. Diseño - Prototipo. Análisis - Diagrama de clases. Análisis - Diagrama de secuencia de sucesos. Análisis - Diagrama de estados. Diseño - Diagrama de componentes. Diseño - Modelo entidad relación. Construcción No es parte de la presente tesis. Transición No es parte de la presente tesis. 2.2. Requerimientos del sistema A continuación presentamos el documento de visión del proyecto, los requerimientos funcionales y no funcionales del sistema, obtenidos a través de reuniones con los usuarios involucrados en las acciones que afectará el sistema (stakeholders) tales como: Oficina de Trámite Documentario, Dirección de Administración y la Oficina de Contabilidad de la PUCP. 2.2.1. Visión del proyecto 2.2.1.1. Introducción Se desea contar con un nuevo Sistema de Trámite de Documento de Pagos a Proveedores vía intranet, que permita la flexibilidad de soportar las necesidades descritas en las reglas del negocio y futuros requerimientos, y que brinde satisfacción a los usuarios finales. 33 2.2.1.2. Posicionamiento 2.2.1.2.1. Oportunidades de negocio Existen en el mercado sistemas de pagos a proveedores que permiten el registro de los documentos de pago a proveedores con el fin único de su procesamiento en la contabilidad de la institución. En el mercado actual son pocos los sistemas que permiten la revisión y aprobación previa a la contabilización y al pago de los documentos de pago a proveedores, y los sistemas existentes permiten poca o ninguna flexibilidad al momento de elaborar las rutas por la cual el documento debe transitar para su revisión, aprobación y contabilización dentro de la institución. 2.2.1.2.2. Definición del problema El sistema de trámite de documentos de pago existente en la institución no es flexible (funcionalidades insuficientes o deficientes y falta de estándares en la integración con los demás sistemas existentes en la institución, son sus principales problemas), lo que ha generado que se utilice un proceso paralelo y manual de aprobación de documentos de pago a proveedores. Los problemas generados son los siguientes: deficiente confidencialidad de la información, incremento del tiempo del trámite, problemas de conservación de los comprobantes de pago, problemas en las interfases con los sistemas existentes, dificultad en la disponibilidad de los documentos, entre otros. 2.2.1.2.3. Declaración de posicionamiento del producto El sistema propuesto reemplazará al sistema informático y el proceso manual paralelo utilizados en la PUCP para el trámite de documentos de pago a proveedores. El sistema de Trámite de Documento de Pagos a Proveedores vía intranet permitirá realizar la revisión, aprobación y contabilización de estos documentos de manera 34 flexible, según las necesidades que surjan en la institución, además de establecer estándares para la integración con los demás sistemas existentes. 2.2.1.3. Descripción de los usuarios Los usuarios son miembros de la institución educativa, que realizan labores administrativas y entre sus funciones se encargan directamente del proceso de registro, revisión, aprobación y contabilización de los documentos de pago a proveedores. Además se considera la necesidad de contar con un usuario que realice las labores de supervisión de todo este proceso. Los usuarios poseen educación técnica y/o superior y tienen conocimientos básicos en el uso de un computador e Internet. 2.2.1.3.1. Perfiles de usuarios Los usuarios del sistema de Trámite de Documento de Pagos a Proveedores vía intranet se clasifican en cuatro perfiles: • Registrador • Encargado de Unidad • Asistente • Contador • Supervisor • Proveedor 2.2.1.3.2. Demografía del mercado Los usuarios pueden utilizar el sistema desde dentro o fuera de la institución. El único requisito es que el computador que utilicen para acceder al sistema cuente con conexión a la red Local LAN (Local Area Network) de la institución o conexión a Internet. 35 2.2.1.4. Vista general del sistema En esta sección se describen las capacidades del sistema así como su integración con la Intranet institucional. 2.2.1.4.1. Perspectiva del sistema El sistema proveerá una alternativa al sistema de trámite de documentos de pago a proveedores existente en la institución. El sistema de Trámite de Documentos de Pago a Proveedores vía intranet estará integrado al Campus Virtual institucional como uno de los sistemas de apoyo administrativo que se ofrece. El acceso al Campus Virtual, se puede realizar a través de un navegador WEB, a través de la conexión de los computadores a la LAN dentro del campus universitario, o desde cualquier computador con conexión a la Internet. La arquitectura Campus Virtual PUCP está conformada por tres capas [DIRINFO]: Front-end: con aplicaciones livianas que se ejecutan sobre diversos sistemas operativos (Windows, Linux, Apple MAC, PalmOS, WinCE, etc.). Por este motivo un computador requiere sólo un navegador estándar porque la tecnología que se ha utilizado para las aplicaciones es HTML, DHTML, CSS y Javascript. Middle-tier: corresponde a los servidores de aplicaciones que corren en sistema operativo Windows. El software para el servicio de gestión Internet (HTTP), balanceo de carga y contenedor de aplicaciones es el Websphere Aplication Server (IBM) y sobre éste corren las aplicaciones desarrolladas con tecnología Java (servlets, JSP y Java Beans). Back-end: es un servidor de base de datos con sistema operativo AIX (IBM) sobre el que corre el DBMS (sistema de administración de base de datos) ORACLE versión 10g. Sobre éste corren aplicaciones desarrolladas con tecnología Oracle (procedimientos almacenados en PL/SQL y en Java Stored Procedures). 36 Gráfico 2.2. Esquema de la arquitectura del Campus Virtual (intranet) de la PUCP 2.2.1.4.2. Beneficios del sistema • Confidencialidad en el manejo de la información. • Reducción del tiempo del trámite. • Mejoras en la conservación de los comprobantes de pago. • Funcionalidades que satisfagan las expectativas de los usuarios. • Mejoras en las interfases con los sistemas existentes. • Disponibilidad de los documentos en todo momento. • Optimización de los procesos de negocio. 2.2.1.4.3. Dependencias del sistema • La disponibilidad del sistema dependerá de la disponibilidad de los servidores del Campus Virtual y del manejador de base de datos de la institución. • Los usuarios del sistema Web necesitarán de un navegador Web que sea soportado por el Campus Virtual sin importar el sistema operativo del computador. • El tiempo de conexión dependerá del tipo de conexión que tenga el usuario a Internet y del tráfico existente en la red. 37 2.2.2. Requerimientos funcionales Un requerimiento funcional es la descripción de lo que el sistema debe hacer o una funcionalidad que debe proveer [Arlow, Neustadt]. A continuación se listan los requerimientos funcionales del sistema. Tabla 2.3. Requerimientos funcionales Referencia Requerimiento RF01 El registrador es un perfil de un nivel de registro, debe ingresar la información del documento de pago a proveedores en el sistema y adjuntar el documento digitalizado. RF02 El registrador contable es un perfil del nivel contable, debe ingresar la información del documento de pago a proveedores en el sistema y adjuntar el documento digitalizado. RF03 Si el documento de trámite tiene un documento de referencia el sistema debe mostrar la información contenida en la interfase con el sistema de referencia correspondiente. RF04 El sistema seleccionará el flujo de trámite que debe seguir el documento dependiendo del nivel de registro en que se encuentre, del tipo de documento de referencia al que se encuentre relacionado (también existe un flujo cuando el documento no tiene referencia) y a la unidad responsable del documento. RF05 El flujo de aprobación que deberá seguir el documento de trámite será definido por el sistema. RF06 El registrador puede cambiar los datos generales del documento de trámite en caso de error de registro. RF07 El registrador envía el documento de trámite al siguiente nivel del flujo de aprobación cuando concluye satisfactoriamente el registro. RF08 El encargado de unidad es un perfil del nivel unidad, pueden revisar y aprobar los documentos de trámite que lleguen a su nivel. RF09 El encargado de unidad envía el documento de trámite al siguiente nivel del flujo de aprobación cuando concluye satisfactoriamente la revisión. RF10 El contador es un perfil del nivel contable, y debe contabilizar y extornar la contabilización del documento de trámite. RF11 El contador master es un perfil del nivel contable, y debe contabilizar y revertir la contabilización del documento de trámite. Adicionalmente tiene autorización para cambiar datos tales como la fecha de pago del documento y el tipo de documento físico. RF12 El documento de trámite puede ser devuelto desde cualquier nivel al nivel de registro correspondiente. 38 RF13 El trámite del documento puede ser anulado en cualquier nivel. RF14 Los documentos de trámite deben ser enviados al siguiente nivel del trámite si el monto total del documento se encuentra dentro de la escala de montos que se encarga de revisar y aprobar. RF15 Los documentos de trámite después de ser contabilizados en el nivel contable deben ser enviados al sistema de pagos, en el módulo de tesorería correspondiente (como parte de la interfaz con el sistema de pagos institucional). RF16 Los usuarios pueden consultar los documentos que se encuentran en alguno de los niveles en los que su perfil tenga permisos, o los documentos que han transitado por dichos niveles. De esta forma se permite a los usuarios conocer el estado del trámite del documento desde su registro hasta su pago (como parte de la interfaz con el sistema de pagos institucional) RF17 El asistente del nivel debe registrar el lote de documentos y enviar el lote de documentos al nivel destino. RF18 El asistente del nivel de destino debe recibir el lote de documentos, para lo cual debe marcar cada documento que haya llegado en el lote como recibido. RF19 Los usuarios pueden consultar los lotes de documentos que fueron registrados o enviados a alguno de los niveles en los que su perfil tenga permisos. RF20 Los usuarios de cada nivel pueden visualizar el historial del flujo de aprobación de un documento de trámite. 2.2.3. Requerimientos no funcionales Un requerimiento no funcional es la especificación de cómo debe ser implementado el sistema [Arlow, Neustadt]. A continuación se listan los requerimientos no funcionales del sistema. Tabla 2.4. Requerimientos no funcionales Referencia Requerimiento RNF01 El sistema debe tener una interfaz de usuario amigable e intuitiva. RNF02 Se debe poder acceder al sistema desde cualquier computador, sin importar el sistema operativo o navegador de Internet. RNF03 El tiempo de respuesta del sistema no debe exceder el time-out que el navegador WEB tiene para respuestas HTTP, y debe estar dentro de los límites de la intranet institucional. 39 2.3. Análisis de la solución 2.3.1. Casos de uso A continuación se presentan los casos de uso del sistema, los cuales describen la secuencia de eventos que el sistema realiza para interactuar con los actores [Arlow, Neustadt]. Primero se presenta el diagrama de actores, y luego se presentan los diagramas de casos de uso que se han agrupado en 2 diagramas, el primero para los casos de uso relacionados al documento, y el segundo los casos de uso relacionados al lote de documentos. 2.3.1.1. Actores Un actor representa un rol de una entidad externa que interactúa con el sistema [Arlow, Neustadt]. En este proyecto los actores representaran los roles de usuarios del sistema. Gráfico 2.3. Diagramas de actores Encargado de Unidad Asistente Contador Contador Master Registrador Registrador Contable Usuario Genérico Supervisor Proveedor 40 Tabla 2.5. Actores del sistema Actor Descripción Asistente Es el encargado del registro, envío y recepción de lotes de documentos. Participa en los siguientes casos de uso: • CU07 Consultar lote de documentos • CU08 Administrar lote de documentos Contador Es el encargado de contabilizar, revertir la contabilización, anular el trámite, devolver y editar los documentos que son enviados al nivel contable. Participa en el siguiente caso de uso: • CU05 Administrar documento en contabilidad Contador Master Se encarga de las actividades del contador, con atribuciones especiales que le permiten cambiar la fecha de pago del documento de trámite, y el tipo de documento físico. Participa en el siguiente caso de uso: • CU06 Administrar documento en contabilidad - master Encargado de Unidad Es el encargado de aprobar, anular el trámite, devolver y enviar los documentos que son revisados en el nivel unidad. Participa en el siguiente caso de uso: • CU04 Administrar documento Proveedor Se encarga de consultar los documentos que ha enviado a la institución. Participa en el siguiente caso de uso: • CU09 Consultar documento vía extranet Registrador Es el encargado de registrar, editar y anular el trámite un documento de pago a proveedores en el sistema en un nivel de registro. Participa en el siguiente caso de uso: • CU02 Registrar documento Registrador Contable Es el encargado de registrar, editar y anular el trámite un documento de pago a proveedores en el sistema en un nivel contable. Participa en el siguiente caso de uso: • CU03 Registrar documento en contabilidad Supervisor Es el encargado de consultar todos los documentos registrados en el sistema. Participa en los siguientes casos de uso: • CU01 Consultar documento • CU07 Consultar lote de documentos Usuario Genérico Es el encargado de consultar los documentos en los que tenga autorización. Participa en el siguiente caso de uso: • CU01 Consultar documento 41 2.3.1.2. Casos de uso relacionados al documento Gráfico 2.4. Diagrama de casos de uso relacionados al documento Registrador Contable Contador Registrar documento en Contabilidad Administrar documento en Contabilidad Consultar documento Buscar proveedor Buscar documento de referencia«include» «include» «include» Contador Master Administrar documento Registrar documento «extend»Registrador Administrar documento en Contablidad - Master Encargado de Unidad Usuario Genérico «extend» Supervisor Consultar documento vía extranetProveedor 2.3.1.2.1. Caso de Uso: CU01 Consultar documento Tabla 2.6. Caso de Uso: Consultar documento CU01 Consultar documento Descripción El caso de uso permite consultar los documentos en los que tenga autorización el usuario. Actores Usuario genérico, Supervisor. Precondición El usuario debe encontrarse dentro del sistema. 42 Flujo Básico Consultar documento 1. El caso de uso comienza cuando el usuario ingresa a la opción Documento > Consulta. 2. El sistema le muestra un formulario con los siguiente criterios de búsqueda: a. Número de documento físico (tipo, serie y número del documento físico) b. Periodo de emisión del documento. c. Número de documento de referencia (tipo y número del documento de referencia) d. Proveedor. Incluir “Buscar proveedor”. e. Número de trámite f. Estado g. Unidad del documento h. Clasificación del trámite i. Número de lote. 3. El usuario selecciona uno o más criterios. 4. El usuario selecciona la opción “Consultar”. 5. Si el usuario colocó el número de documento físico el sistema automáticamente le mostrará la información del documento indicado y el caso de uso se da por finalizado. 6. Si el usuario colocó el número de trámite el sistema automáticamente le mostrará la información del documento indicado y el caso de uso se da por finalizado. 7. Si el usuario colocó el número de documento de referencia el sistema automáticamente le mostrará la información del documento indicado y el caso de uso se da por finalizado. 8. Caso contrario el sistema mostrará un listado con los documentos que cumplan los criterios seleccionados. Este listado mostrará los siguientes datos: a. Número de trámite b. Número de documento de referencia (tipo y número). c. Proveedor (R.U.C. y razón social). d. Número de documento físico (tipo, serie y número). e. Moneda f. Importe g. Nivel actual h. Estado actual. 9. El usuario selecciona el número de trámite que desea visualizar. 10. El sistema le mostrará toda la información del documento indicado, y se da por finalizado el caso de uso. Poscondición El usuario visualiza el documento deseado. 2.3.1.2.2. Caso de Uso: CU02 Registrar documento Tabla 2.7. Caso de Uso: Registrar documento CU02 Registrar documento Descripción El caso de uso permite registrar, editar y anular el trámite de un documento de pago a proveedores en el sistema. Actores Registrador. Precondición El usuario debe encontrarse dentro del sistema, y tener accesos a un nivel de registro. 43 Flujo Básico Registrar documento 1. El caso de uso comienza cuando el usuario ingresa a la opción Documento > Registro. 2. El sistema le muestra un formulario donde le sugiere los siguientes campos: a. Número de trámite, que es el identificador del documento dentro del sistema, le sugiere el correlativo que son los 4 últimos dígitos, los cuales pueden ser modificados. b. Fecha de recepción, que contendrá la fecha actual. c. Fecha de pago, inicialmente será la fecha actual más 30 días. Los días cambian con el tipo de documento físico que se utilice. d. Siguiente nivel, este campo será sugerido por el sistema después que el usuario haya seleccionado el Flujo permitido. 3. El usuario debe ingresar los siguientes datos: a. Nivel, el sistema le mostrará un listado de niveles donde puede registrar un documento b. Número de documento de referencia, compuesto por el tipo de documento de referencia y el número de documento. Incluir “Buscar documento de referencia”. c. Número de documento físico, compuesto por el tipo de comprobante o documento de pago sólo si no fue sugerido por el sistema después de seleccionar el documento de referencia (sólo se sugiere en caso se cuente con interfaz con el sistema correspondiente), serie y número del documento físico enviado por el proveedor. d. Fecha de emisión del documento físico. e. Archivo, que contenga el documento digitalizado. f. Observaciones, este campo será llenado si el usuario desea. Si el documento de referencia pertenece a algún sistema con el que se ha implementado una interfaz para compartir datos, estos campos serán colocados automáticamente por el sistema, caso contrario deben ser ingresados por el usuario: a. Proveedor, código de RUC. Incluir “Buscar proveedor”. b. Monto total, compuesto por el tipo de moneda (soles y dólares) y el monto que figura en el documento enviado por el proveedor. c. Unidad del documento, unidad de la institución responsable de las coordinaciones con el proveedor. d. Clasificación del trámite. 4. El sistema seleccionará el flujo de trámite que debe seguir el documento dependiendo del nivel de registro en que se encuentre, del tipo de documento de referencia al que se encuentre relacionado (también existe un flujo cuando el documento no tiene referencia) y a la unidad responsable del documento. 5. El usuario selecciona la opción “Grabar”. 6. El sistema verifica que todos los datos obligatorios sean llenados, en caso exista algún campo con un valor inválido el sistema enviará un mensaje de alerta. 7. Si todas las verificaciones son correctas el sistema almacenará la información. Poscondición El documento es almacenado en el sistema y se encuentra en estado REGISTRADO. Flujo Alternativo Editar documento 1. El usuario se encuentra visualizando un documento y selecciona la opción “Editar”. 2. El sistema le muestra un formulario donde le permite modificar los siguientes datos: a. Número de documento de referencia b. Número de documento físico, se puede modificar la serie y número del documento; sólo se puede modificar el tipo de documento de pago si no ha sido sugerido por el sistema. c. Fecha de emisión. d. Flujos permitidos. e. Archivo. f. Observaciones. 44 Si el documento de Referencia pertenece a algún sistema con el que se ha implementado una interfaz para compartir datos, estos campos serán colocados automáticamente por el sistema y no podrán ser modificados, caso contrario el usuario puede modificar los siguientes campos: a. Proveedor. b. Monto total. c. Unidad del documento. d. Clasificación del trámite. 3. El usuario realiza los cambios que crea conveniente. 4. El usuario selecciona la opción “Grabar”. 5. El sistema verifica que todos los datos obligatorios sean llenados, en caso exista algún campo con un valor inválido enviará un mensaje de alerta. 6. Si todas las verificaciones son correctas el sistema almacenará la información modificada. Poscondición El documento es modificado. Flujo Alternativo Enviar documento 1. El usuario se encuentra visualizando un documento y selecciona la opción “Enviar”. 2. El sistema le solicita que confirme que desea enviar el documento hacia el siguiente nivel del flujo correspondiente. 3. El usuario selecciona la opción “Aceptar”. 4. El sistema es enviado hacia el siguiente nivel del flujo correspondiente y se muestra el documento con el estado EN PROCESO. Poscondición El documento se encuentra en el siguiente nivel del flujo correspondiente en estado EN PROCESO. Flujo Alternativo Anular el trámite del documento 1. El usuario se encuentra visualizando un documento y selecciona la opción “Anular”. 2. El sistema le solicita que confirme que desea anular el trámite del documento. 3. El usuario selecciona la opción “Aceptar”. 4. El sistema muestra el documento con el estado ANULADO. Poscondición El documento se encuentra en estado ANULADO. 2.3.1.2.3. Caso de Uso: CU03 Registrar documento en contabilidad Tabla 2.8. Caso de Uso: Registrar documento en contabilidad CU03 Registrar documento en contabilidad Descripción El caso de uso permite registrar, editar y anular el trámite de un documento de pago a proveedores en el sistema. Esta funcionalidad es una alternativa de registro que debe ser usada excepcionalmente en casos urgentes. Actores Registrador contable. Precondición El usuario debe encontrarse dentro del sistema, y tener accesos a un nivel contable. 45 Flujo Básico Registrar documento en contabilidad 1. Este flujo alternativo extiende el flujo básico del caso de uso “CU02 Registrar documento” en el punto 3. El usuario debe ingresar adicionalmente los siguientes datos: DATOS CONTABLES: a. Origen del documento. b. Indicador de Pago c. Forma sugerida de pago d. Transacción, seleccionar en caso el asiento deba generarse con alguna otra plantilla. e. Girar a, o persona a la cual se le debe pagar por el documento en caso sea diferente al proveedor. f. Valor de Venta g. Porcentaje de Impuesto 1 (el nombre de impuesto se mostrará según el tipo de documento físico que se esté tramitando) h. Importe del Impuesto 1 i. Servicios/Ajuste, donde se colocará el monto positivo o negativo que permita que el importe total sea exactamente igual al importe original. j. Importe total k. Indicador de abono Si el documento de referencia pertenece a algún sistema con el que se ha implementado una interfaz para compartir datos, estos campos serán colocados automáticamente por el sistema, caso contrario deben ser ingresados por el usuario: DISTRIBUCIÓN: Por cada línea de distribución del cargo. a. Cuenta b. Partida c. Unidad d. Actividad e. Importe f. Tipo de Gravación. Si el usuario selecciona el indicador de abono deberá llenar los siguientes datos: ASIENTO CONTABLE: Por cada línea de distribución del abono. a. Cuenta b. Partida c. Unidad d. Actividad e. Importe 2. El caso de uso continúa en el punto 4 del flujo básico del caso de uso “CU02 Registrar documento”. Poscondición El documento es almacenado en el sistema y se encuentra en estado REGISTRADO. 46 2.3.1.2.4. Caso de Uso: CU04 Administrar documento Tabla 2.9. Caso de Uso: Administrar documento CU04 Administrar documento Descripción El caso de uso permite aprobar, anular el trámite, devolver y enviar los documentos que son revisados en el nivel unidad en el que se encuentre el actor. Actores Encargado de Unidad Precondición El usuario debe encontrarse dentro del sistema, y tener accesos a un nivel del tipo unidad. Flujo Básico Aprobar documento en lote 1. El caso de uso comienza cuando el usuario ingresa a la opción Documento > Aprobación. 2. El sistema le muestra un listado de documentos que deben ser aprobados. Este listado mostrará los siguientes datos: a. Número de trámite. b. Número de documento de referencia. c. Proveedor. d. Número de documento físico e. Moneda f. Importe 3. El usuario selecciona uno o más documentos. 4. El usuario selecciona la opción “Aprobar”. 5. El sistema le solicita que confirme que desea aprobar los documentos seleccionados. 6. El usuario selecciona la opción “Aceptar”. 7. El sistema el registro de la aprobación de cada documento en el nivel en el que se encuentra, y envía a cada documento al siguiente nivel del flujo correspondiente. 8. El caso de uso continúa en el punto 2. Poscondición El o los documento(s) son enviados al siguiente nivel del flujo correspondiente y se encuentra(n) en estado EN PROCESO. Flujo Alternativo Aprobar documento individual 1. El usuario se encuentra visualizando un documento, y selecciona la opción “Aprobar”. 2. El sistema le solicita que confirme que desea aprobar el documento. 3. El usuario selecciona la opción “Aceptar”. 4. El sistema guarda el registro de la aprobación del documento en el nivel en el que se encuentra, envía el documento al siguiente nivel del flujo correspondiente. 5. El sistema muestra el documento aprobado. Poscondición El documento es enviado al siguiente nivel del flujo correspondiente y se encuentra en estado EN PROCESO. 47 Flujo Alternativo Anular el trámite del documento 1. El usuario se encuentra visualizando un documento, y selecciona la opción “Anular”. 2. El sistema le solicita que confirme que desea anular el trámite del documento. 3. El usuario selecciona la opción “Aceptar”. 4. El sistema muestra el documento con el estado ANULADO, y notifica al nivel donde se encuentre el documento físico que debe gestionar la entrega al proveedor. Poscondición El documento se encuentra en estado ANULADO. Flujo Alternativo Devolver documento 1. El usuario se encuentra visualizando un documento, y selecciona la opción “Devolver”. 2. El sistema le solicita que confirme que desea devolver el documento al nivel de registro correspondiente. 3. El usuario selecciona la opción “Aceptar”. 4. El sistema muestra el documento con el estado REGISTRADO en el nivel de registro, y lo marca como DEVUELTO. Poscondición El documento es devuelto al nivel de registro, se encuentra en estado REGISTRO y marcado como DEVUELTO Flujo Alternativo Editar documento 1. El usuario se encuentra visualizando un documento, y selecciona la opción “Editar”. 2. El sistema le muestra un formulario con los siguientes datos modificables: DATOS GENERALES: a. Observaciones, este campo será llenado si el usuario desea Si el nivel permite modificar la distribución, podrá editar la siguiente sección: DISTRIBUCIÓN: Por cada línea de distribución del pago a. Partida b. Unidad c. Actividad d. Importe 3. El usuario realiza los cambios que crea conveniente. 4. El usuario selecciona la opción “Grabar”. 5. El sistema verifica que todos los datos obligatorios sean llenados, en caso exista algún campo con un valor inválido enviará un mensaje de alerta. 6. Si todas las verificaciones son correctas el sistema almacenará la información modificada. Poscondición El documento es modificado. 48 2.3.1.2.5. Caso de Uso: CU05 Administrar documento en contabilidad Tabla 2.10. Caso de Uso: Administrar documento en contabilidad CU05 Administrar documento en contabilidad Descripción El caso de uso permite contabilizar, revertir la contabilización, anular el trámite, devolver y editar los documentos que son enviados al nivel contable en el que se encuentre el actor. Actores Contador. Precondición El usuario debe encontrarse dentro del sistema, y tener accesos a un nivel contable. Flujo Básico Contabilizar documento 1. El caso de uso comienza cuando el usuario ingresa a la opción Documento > Aprobación. 2. El sistema le muestra un listado de documentos que se encuentran en estado RECIBIDO en el nivel contable en el que se encuentra. Este listado mostrará los siguientes datos: a. Número de trámite b. Número de documento de referencia c. Proveedor d. Número de documento físico e. Moneda f. Importe 3. El usuario selecciona el número del documento que desea aprobar. 4. El sistema abre el documento indicado. 5. El usuario selecciona la opción “Contabilizar”. 6. El sistema marca el documento como CONTABILIZADO. Poscondición El documento se encuentra en estado EN PROCESO y marcado como CONTABILIZADO. Flujo Alternativo Anular el trámite del documento 1. El usuario se encuentra visualizando un documento, y selecciona la opción “Anular”. 2. El sistema le solicita que confirme que desea anular el trámite del documento. 3. El usuario selecciona la opción “Aceptar”. 4. El sistema muestra el documento con el estado ANULADO. Poscondición El documento se encuentra en estado ANULADO. 49 Flujo Alternativo Devolver documento 1. El usuario se encuentra visualizando un documento que no ha sido registrado en el nivel contable, y selecciona la opción “Devolver”. 2. El sistema le solicita que confirme que desea devolver al nivel de inicio el documento. 3. El usuario selecciona la opción “Aceptar”. 4. El sistema muestra el documento con el estado REGISTRADO en el nivel de REGISTRO, y es marcado como DEVUELTO. Poscondición El documento es devuelto al nivel de registro inicial con estado REGISTRADO y marcado como DEVUELTO. Flujo Alternativo Deshacer contabilización del documento 1. El usuario se encuentra visualizando un documento marcado como CONTABILIZADO y selecciona la opción “Descontabilizar”. 2. El sistema le solicita que confirme que desea deshacer la contabilización del documento. 3. El usuario selecciona la opción “Aceptar”. 4. El sistema muestra el documento sin la marca de CONTABILIZADO. Poscondición El documento se encuentra en estado EN PROCESO Flujo Alternativo Editar documento 1. El usuario se encuentra visualizando un documento en estado EN PROCESO y selecciona la opción “Editar”. 2. El sistema le muestra un formulario con los siguientes datos modificables: DATOS GENERALES: a. Observaciones, este campo será llenado si el usuario desea. DATOS CONTABLES: a. Origen del documento. b. Indicador de pago c. Forma sugerida de pago d. Transacción, seleccionar en caso el asiento deba generarse con alguna otra plantilla. e. Girar a, o persona a la cual se le debe pagar por el documento en caso sea diferente al proveedor. f. Valor de venta g. Porcentaje de impuesto 1 (el nombre de impuesto se mostrará según el tipo de documento físico que se esté tramitando) h. Importe del impuesto 1 i. Servicios/Ajuste, donde se colocará el monto positivo o negativo que permita que el importe total sea exactamente igual al importe original. j. Importe total k. Indicador de abono DISTRIBUCIÓN: Por cada línea de distribución del cargo. a. Cuenta b. Partida c. Unidad d. Actividad e. Importe f. Tipo de Gravación. Si el usuario selecciona el indicador de abono podrá editar la siguiente sección. ASIENTO CONTABLE: Por cada línea de distribución del abono. a. Cuenta 50 b. Partida c. Unidad d. Actividad e. Importe 3. El usuario realiza los cambios que crea conveniente. 4. El usuario selecciona la opción “Grabar”. 5. El sistema verifica que todos los datos obligatorios sean llenados, en caso exista algún campo con un valor inválido enviará un mensaje de alerta. 6. Si todas las verificaciones son correctas el sistema almacenará la información modificada. Poscondición El documento es modificado. 2.3.1.2.6. Caso de Uso: CU06 Administrar documento en contabilidad master Tabla 2.11. Caso de Uso: Administrar documento en contabilidad master CU06 Administrar documento en contabilidad - master Descripción El caso de uso extiende el caso de uso Administrar documento en contabilidad. Actores Contador Master. Precondición El usuario debe encontrarse dentro del sistema, y tener accesos a un nivel contable. Flujo Alternativo Editar documento 1. Este flujo alternativo extiende el flujo alternativo “Editar documento” del caso de uso “CU05 Administrar documento en contabilidad” en el punto 2. DATOS GENERALES: muestra modificable adicionalmente los siguientes campos: a. Fecha de pago b. Tipo de documento físico 2. El caso de uso continúa en el punto 3 del flujo alternativo “Editar documento” del caso de uso “CU05 Administrar documento en contabilidad”. Poscondición El documento es modificado. 2.3.1.2.7. Caso de Uso: CU07 Consultar documento vía extranet Tabla 2.12. Caso de Uso: Consultar documento vía extranet CU07 Consultar documento vía extranet Descripción El caso de uso permite consultar los documentos en los que tenga autorización el usuario. Actores Proveedor. Precondición El usuario debe encontrarse dentro del sistema. 51 Flujo Básico Consultar documento 1. El caso de uso comienza cuando el usuario ingresa a la opción Documento > Consulta. 2. El sistema le muestra un formulario con los siguiente criterios de búsqueda: e. Número de documento físico (tipo, serie y número del documento físico) f. Periodo de emisión del documento. 11. El usuario selecciona uno o más criterios. 12. El usuario selecciona la opción “Consultar”. 13. Caso contrario el sistema mostrará un listado con los documentos que cumplan los criterios seleccionados. Este listado mostrará los siguientes datos: a. Número de documento físico (tipo, serie y número). b. Proveedor (R.U.C. y razón social). c. Moneda d. Importe e. Nivel actual f. Estado actual. g. Forma de pago. h. Fecha de pago, si el estado de los documentos es REGISTRADO o EN PROCESO DE PAGO se mostrará la fecha estimada de pago, si el documento se encuentra PAGADO se muestra la fecha en que efectivamente se realizó el pago. i. Número de trámite j. Número de documento de referencia (tipo y número). 14. El usuario selecciona el número de trámite que desea visualizar. 15. El sistema le mostrará toda la información del documento indicado, y se da por finalizado el caso de uso. Poscondición El usuario visualiza el documento deseado. 52 2.3.1.3. Casos de uso relacionados al lote de documentos Gráfico 2.5. Diagrama de casos de uso relacionados al lote de documentos Administrar lote de documentos Consultar lote de documentos Asistente Supervisor 2.3.1.3.1. Caso de Uso: CU08 Consultar lote de documentos Tabla 2.13. Caso de Uso: Consultar lote de documentos CU07 Consultar lote de documentos Descripción El caso de uso permite consultar los lotes de documentos que hayan sido registrados o enviados a este nivel. Actores Asistente, Supervisor. Precondición El usuario debe encontrarse dentro del sistema. Flujo Básico Consultar lote de documentos 1. El caso de uso comienza cuando el usuario ingresa a la opción Lote > Consulta. 2. El sistema le muestra un formulario con los siguiente criterios de búsqueda: a. Número de lote b. Estado del lote c. Nivel origen. d. Nivel destino. e. Clasificación del lote. f. Observaciones g. Periodo en el que se haya registrado el lote. h. Periodo en el que se haya enviado el lote. i. Periodo en el que se haya recibido el lote. j. Número de trámite que pueda estar contenido en un lote. 3. El usuario selecciona uno o más criterios. 4. El usuario selecciona la opción “Consultar”. 5. Si el usuario colocó el número de lote el sistema automáticamente le mostrará la información del lote indicado y el caso de uso se da por finalizado. 6. Caso contrario el sistema mostrará un listado con los lotes que cumplan los criterios seleccionados. Este listado mostrará los siguientes datos: a. Número de Lote b. Total de documentos. c. Los primeros n documentos contenidos en el lote. d. Nivel origen. e. Nivel destino. f. Estado del lote. g. Fecha de registro 53 h. Fecha de envío. i. Fecha de recepción. 7. El usuario selecciona el número del lote que desea visualizar. 8. El sistema le mostrará la información del lote indicado, el caso de uso se da por finalizado. Poscondición El usuario visualiza el lote de documento deseado. 2.3.1.3.2. Caso de Uso: CU09 Administrar lote de documentos Tabla 2.14. Caso de Uso: Administrar lote de documentos CU08 Administrar lote de documentos Descripción El caso de uso permite registrar, editar, enviar y anular un lote de documentos registrado en el nivel en que se encuentra el usuario, y recibir los documentos que son enviados a este nivel. Actores Asistente. Precondición El usuario debe encontrarse dentro del sistema. Flujo Básico Registrar lote de documentos 1. El caso de uso comienza cuando el usuario ingresa a la opción Lote > Registro. 2. El sistema le muestra un formulario donde le sugiere los siguientes campos: a. Registrador, código y nombre del usuario. b. Fecha de registro, fecha actual. 3. El usuario debe ingresar los siguientes datos: a. Nivel de origen b. Nivel de destino. c. Clasificación del lote. d. Observaciones, es opcional. 4. El sistema le muestra algunos criterios que le permitirán encontrar los documentos que puede seleccionar para agregar al lote, los criterios son los siguientes: a. Proveedor b. Unidad del documento. c. Clasificación del documento de trámite. d. Periodo en que se puede encontrar la fecha de registro del documento. 5. El usuario selecciona alguno de los criterios. 6. El usuario selecciona la opción “Consultar”. 7. El sistema le muestra los documentos físicos que se encuentran en el nivel origen y que cumplan con los demás criterios seleccionados. 8. El usuario selecciona los documentos que desee y los agrega al listado de documentos seleccionados. 9. El usuario puede seleccionar la opción “Limpiar” para volver a escoger criterios, volviendo al paso 6. 10. El usuario puede eliminar algún documento seleccionado. 11. Si el usuario cambia de nivel de origen perderá todos los documentos seleccionados. Se le mostrará un mensaje para confirmar que desea cambiar el nivel origen. 12. El usuario selecciona la opción “Grabar”. 13. El sistema verifica que se haya seleccionado el nivel de destino, la clasificación del lote y que se encuentre seleccionado por lo menos un documento. En caso exista algún campo con un valor inválido el sistema enviará un mensaje de alerta. 14. Si todas las verificaciones son correctas el sistema almacenará la información. 54 Poscondición El lote de documento es almacenado en el sistema y se encuentra en estado REGISTRADO. Flujo Alternativo Editar lote de documentos 1. El usuario se encuentra visualizando un lote en estado REGISTRADO en el nivel de origen, y selecciona la opción “Editar”. 2. El usuario puede modificar los siguientes campos: a. Nivel de destino: si el usuario cambia el nivel de destino perderá todos los documentos seleccionados. Se le mostrará un mensaje para confirmar la acción. b. Clasificación del lote. c. Observaciones. 3. El sistema le muestra algunos criterios que le permitirán filtras los documentos que puede seleccionar para agregar al lote, los criterios son los siguientes: a. Proveedor b. Unidad del documento. c. Clasificación del trámite. d. Periodo en que se puede encontrar la fecha de registro del documento. 4. El usuario selecciona alguno de los criterios. 5. El usuario selecciona la opción “Consultar”. 6. El sistema le muestra los documentos físicos que se encuentran en el nivel origen y que cumplan con los demás criterios seleccionados. 7. El usuario selecciona los documentos que desee y los agrega al listado de documentos seleccionados. 8. El usuario puede seleccionar la opción “Limpiar” para volver a escoger criterios, regresa al paso 6. 9. El usuario puede eliminar algún documento seleccionado. 10. Si el usuario cambia de nivel de origen perderá todos los documentos seleccionados. Se le mostrará un mensaje para confirmar que desea cambiar el nivel origen. 11. El usuario selecciona la opción “Grabar”. 12. El sistema verifica que se haya seleccionado el nivel de destino, la clasificación del lote y que se encuentre seleccionado por lo menos un documento. En caso exista algún campo con un valor inválido el sistema enviará un mensaje de alerta. 13. Si todas las verificaciones son correctas el sistema almacenará la información. Poscondición El lote del documento es modificado. Flujo Alternativo Enviar lote de documentos 1. El usuario se encuentra visualizando un lote en estado REGISTRADO en el nivel de origen, y selecciona la opción “Enviar”. 2. El sistema le solicita que confirme que desea enviar el lote. 3. El usuario selecciona la opción “Aceptar”. 4. El sistema procesa todos los documentos, registra el momento en que fueron enviados al siguiente nivel. El sistema muestra el lote con el estado ENVIADO. Poscondición El lote de documentos se encuentra en estado ENVIADO. 55 Flujo Alternativo Anular lote de documentos 1. El usuario se encuentra visualizando un lote en estado REGISTRADO en el nivel de origen, y selecciona la opción “Anular”. 2. El sistema le solicita que confirme que desea anular el lote. 3. El Registrar selecciona la opción “Aceptar”. 4. El sistema muestra el lote con el estado ANULADO. Poscondición El lote de documentos se encuentra en estado ANULADO. Flujo Alternativo Recibir lote de documentos 1. El caso de uso comienza cuando el usuario ingresa a la opción Lote > Recepción. 2. El sistema le muestra un listado de lotes de documentos que han sido enviados al nivel destino al que pertenece el usuario. Este listado mostrará los siguientes datos: a. N° de lote. b. No total de documentos contenidos en el lote. c. Los primeros n documentos contenidos en el lote. d. Nivel de origen e. Nivel destino f. Clasificación del lote. g. Estado h. Fecha de Registro i. Fecha de Envío 3. El usuario selecciona el N° del lote que desea procesar. 4. El sistema le mostrará la información del lote indicado, se muestra si el documento fue previamente marcado como recibido o no. 5. El usuario marca como recibido o desmarca uno o más documentos. 6. Si desea guardar las marcas ingresadas hasta ese momento selecciona la opción “Guardar”. 7. El sistema guardará la información de los documentos que están siendo marcados como recibidos. 8. El usuario selecciona la opción “Recibir”. 9. El sistema le solicita que confirme que serán recibidos sólo los documentos marcados, y los que no se encuentren marcados serán considerados que no llegaron en el lote. 10. El usuario selecciona la opción “Aceptar”. 11. El sistema registra la recepción en el nivel destino de los documentos físicos de aquellos documentos de trámite que fueron marcados, y no así los documentos físicos de los documentos de trámite que no fueron marcados (se considera que permanecen en el nivel origen). 12. El sistema muestra el lote con el estado RECIBIDO Poscondición El lote de documentos se encuentra en estado RECIBIDO. 56 2.3.1.4. Matriz de trazabilidad Para confirmar que los casos de uso presentados cumplen con los requerimientos funcionales del sistema, se presenta la siguiente matriz de trazabilidad, donde se marca con una ‘X’ un recuadro cuando el caso de uso satisface el requerimiento de la fila correspondiente. Tabla 2.15. Matriz de trazabilidad Casos de uso UC01 UC02 UC03 UC04 UC05 UC06 UC07 UC08 UC09 RF01 X RF02 X RF03 X X RF04 X X RF05 X RF06 X RF07 X RF08 X RF09 X RF10 X RF11 X RF12 X X X RF13 X X X X RF14 X X RF15 X X RF16 X X RF17 X RF18 X RF19 X R e q u e r i m i e n t o s f u n c i o n a l e s RF20 X 57 2.3.2. Diagrama de clases A continuación se presenta el diagrama de clases de análisis o también denominado Modelo del Dominio [Larman], donde se presentan las clases principales del sistema y la relación existente entre ellas. Gráfico 2.6. Diagrama de clases 2.3.3. Especificación de las clases del sistema A continuación se presenta la especificación de las clases del sistema, donde se detalla la relación que las une. Tabla 2.16. Clases del sistema Clase Descripción Documento Es la clase base del sistema, es la representación del documento físico dentro del sistema. 58 Documento Referencia Es la clase que representa el documento de referencia. Un objeto de la clase Documento “tiene referencia” con cero o un objeto de la clase DocumentoReferencia; un objeto de la clase DocumentoReferencia “tiene referencia” con cero o un objeto de la clase Documento. Proveedor Es la clase que representa al proveedor que emite el documento. Un objeto de la clase Documento “es emitido por” un objeto de la clase Proveedor; un objeto de la clase Proveedor “emite” muchos objetos de la clase Documento. Unidad Es la clase que representa las áreas de la institución. Unidad Responsable Es una generalización de la clase unidad, y es la representación de la unidad responsable del documento de trámite. Un objeto de la clase Documento “es tramitado por” un objeto de la clase UnidadResponsable, y un objeto de la clase UnidadResponsable “tramita” muchos objetos de la clase Documento. Asiento Es la clase que representa al asiento contable. Un objeto de la clase Documento “genera” un objeto de la clase Asiento; un objeto de la clase Asiento “es generado” por un objeto de la clase Documento. Historial Aprobacion Esta clase es parte de la clase Documento, y representa la distribución contable presupuestal del importe del documento. Un objeto de la clase Documento “contiene” uno o más objetos de la clase HistorialAprobacion; un objeto de la clase HistorialAprobacion “está contenido en” un objeto de la clase Documento. Distribución Cargo Esta clase es parte de la clase Documento, y representa la distribución contable presupuestal del importe del documento. Un objeto de la clase Documento “contiene” uno o más objetos de la clase DistribucionCargo; un objeto de la clase DistribucionCargo “está contenido en” un objeto de la clase Documento. Distribución Abono Esta clase es parte de la clase Documento, y representa a la distribución del abono del asiento. Un objeto de la clase Documento “contiene” cero o más objetos de la clase DistribucionAbono; un objeto de la clase DistribucionAbono “está contenido en” un objeto de la clase Documento. Compromiso Presupuestal Esta clase es parte de la clase Documento, y representa a la distribución del cargo del asiento. Un objeto de la clase Documento “contiene” cero o más objetos de la clase CompromisosPresupuestal; un objeto de la clase CompromisosPresupuestal “está contenido en” un objeto de la clase Documento. Tipo Documento Esta clase representa el tipo de documento. Un objeto de la clase Documento “se clasifica en” un objeto de la clase TipoDocumento; un objeto de la clase TipoDocumento “clasifica a” muchos objetos de la clase Documento. TipoTramite Esta clase representa los tipos de trámite que tiene el sistema. Sistema Referencia Esta clase representa a los sistemas de bienes o servicios, también llamados sistemas de referencia. Un objeto de la clase SistemaReferencia “es tramitado a través de” muchos objetos de la clase TipoTramite. Un objeto de la clase TipoTramite “tramita” muchos objetos de la clase SistemaReferencia. NivelXTramite Esta clase es la asociación de la clase Nivel y la clase Trámite. 59 Nivel Esta clase representa a un nivel de aprobación dentro del sistema. Un objeto de la clase Nivel “es administrado por” un objeto de la clase Unidad. Un objeto de clase Unidad “administra” un objeto de la clase Nivel. Flujo Esta clase representa los flujos de aprobación del sistema. Un objeto de la clase Nivel “pertenece” a uno o más objetos de la clase Flujo; y un objeto de clase Flujo “contiene” uno o más objetos de la clase Nivel. LoteDe Documentos Es la clase que representa el lote de documentos. Un objeto de la clase Documento “está contenido en” en uno o más objetos de la clase LoteDeDocumentos; un objeto de la clase LoteDeDocumentos “contiene” uno o más objetos de la clase Documento. 2.3.4. Diagrama de estados A continuación se presentan los diagramas de estados del sistema, los cuales representan los eventos y estados de un objeto [Larman]. Primero se presenta el diagrama de estados del documento, y luego se presentan el diagrama de estados del lote de documentos, clases principales del sistema. 2.3.4.1. Diagrama de estados del documento Gráfico 2.7. Diagrama de estados del documento Inicio REGISTRADO EN PROCESO DE PAGO ANULADO Registro en el sistema Envío al flujo de aprobación Anulación del documento Fin Devolución del documento Anulación del documento Fin Envío a Tesorería Registro en el sistema PAGADO 2.3.4.2. Diagrama de estado del lote de documentos Gráfico 2.8. Diagrama de estados del lote de documentos REGISTRADO ENVIADO Enviar lote Fin al nivel destino Inicio Registrar en nivel origen RECIBIDO ANULADO Anular lote Fin 60 3. Diseño 3. 3. 3.1. Arquitectura del sistema En esta sección se muestran la arquitectura WEB, el patrón de diseño y el esquema de comunicación WEB que serán utilizados para el desarrollo del sistema y para cumplir con los requerimientos establecidos. 3.1.1. Arquitectura WEB Para este proyecto se va a utilizar una arquitectura WEB basada en una arquitectura de aplicaciones de tres capas, en donde se separa la presentación, la lógica del negocio y el acceso a los datos, las cuales se describen a continuación: 61 Tabla 3.1. Capas de la Arquitectura WEB Capa Descripción Presentación Esta capa contiene la representación gráfica o visual del sistema, gestiona la navegabilidad de la interfaz gráfica de usuario, validación de datos de entrada y el formateo de los datos de salida. Lógica de negocio Esta capa contiene el conjunto de reglas y pasos establecidos para representar las necesidades que el negocio ha establecido. Es la base del sistema. Acceso a datos Esta capa gestiona los aspectos relacionados a la manipulación y persistencia de los datos que se manejan en el negocio. Para su gestión con el administrador de base de datos relacional (RDBMS) se diseñan operaciones de creación, consulta, actualización y eliminación de los datos de cada entidad utilizando los servicios que proporcionan el framework JDBC de J2EE. Gráfico 3.1. Arquitectura WEB de 3 capas: presentación, lógica de negocio y acceso a datos. 62 3.1.2. Patrón de diseño Se utiliza el patrón diseño Modelo-Vista-Controlador (MVC) el cual permite un diseño flexible y escalable, mediante una separación absoluta de la presentación, la lógica del negocio y el acceso a datos. Gráfico 3.2. Patrón de diseño MVC aplicado al proyecto 3.1.3. Diagrama de componentes Un componente es una de las partes “físicas” y reemplazables del sistema [Rumbaugh]. Se dice que es una parte física porque vive en el mundo de bits y se dice que es reemplazable porque puede ser sustituido por un nuevo componente que mejore la funcionalidad o añada alguna otra, sin que afecte a otros componentes. A continuación se presentan y describen los componentes del sistema. 63 Tabla 3.2. Diagrama de componentes Tabla 3.3. Componentes del proyecto según el patrón de diseño MVC. Componentes Descripción Servlet (Controlador) Recibe la solicitud del usuario y según la acción indicada dirige la solicitud hacia el “bean de acción” adecuado. Se tiene un único servlet por aplicación. JavaBeans (Modelo) Maneja la lógica del negocio y la información almacenada en la base de datos. Existen tres tipos de JavaBeans. Bean de Datos Almacena los datos. Se tiene un bean de este tipo por cada entidad de la base de datos involucrada. Bean de Función Almacena los métodos que permitan obtener y transformar los datos, y además permite la comunicación con la base de datos. Bean de Acción Administra la conexión con la base de datos, procesa la solicitud del usuario y decide la siguiente página JSP a mostrar o la siguiente acción a realizar. Permite llevar a cabo funciones de validación, seguridad y autorizaciones sobre la aplicación, y luego invoca la lógica del negocio. Utiliza las funciones y datos de los “bean de función” y “bean de datos” respectivamente. Se tiene un bean de este tipo por cada acción que el usuario puede solicitar al sistema. JSP (Vista) Muestra el resultado del procesamiento de la solicitud HTTP del usuario mediante una página HTML que será mostrada por el navegador WEB. Pagina HTML En el caso de la vista, las clases de interfaz son implementadas mediante archivos JSP la cuales dan el formato a las páginas HTML que serán mostradas por el navegador WEB del usuario. Archivo JS Almacenan funciones en lenguaje javascript que permiten realizar validación de datos de entrada desde en el navegador sin invocar al servidor. Servlet Bean de Acción Bean de Datos Bean de Función JDBC JSP Navegador WEB Base de Datos Página HTML JS 64 El esquema de comunicación WEB del proyecto es el siguiente: 1. El usuario realiza alguna tarea con la pagina HTML, la cual puede realizar algunas validaciones en el navegador utilizando javascript, que puede estar incluido en la pagina HTML o en un archivo JS. 2. Desde la página HTML se realiza una petición HTTP a un Servlet. 3. En el servidor correspondiente responde el Servlet invocado, el cual crea una instancia del bean de acción que atiende la acción solicitada. 4. El bean de acción obtiene una conexión a base de datos. 5. Luego el bean de acción instancia: a. Beans de funciones y/o b. Beans de datos, según sea necesario. 6. Los beans de funciones se comunican con la base de datos al ejecutar los métodos que el bean de acción les indique, almacena la información en los beans de datos. 7. La información que luego debe ser presentada en el navegador WEB, es guardada en el ámbito Request del Servlet. Finalmente, la acción indica el Java Servlet Page (JSP) que será mostrado por el navegador WEB. 8. El Servlet envía la petición hacia el JSP indicado en la acción. 9. El JSP, usando los objetos recientemente almacenados en el ámbito del Request del Servlet, permite mostrar la página HTML de respuesta, la cual es enviada al navegador WEB que inició el pedido. Gráfico 3.3. Esquema de la comunicación WEB del proyecto. 65 3.1.4. Diagramas de interacción Los diagramas de interacción son una parte clave en la realización de los casos de uso, por lo que muestran el diseño de los diagramas de casos de uso [Arlow, Neustadt]. Por este motivo en cada diagrama de secuencia se indica la referencia al caso de uso correspondiente. Estos diagramas muestran la interacción de los objetos, la cual se realiza mediante el envío de mensajes a través del tiempo. A continuación se muestran los estereotipos de clases que se utilizaron para diseñar los diagramas [Rumbaugh]. Tabla 3.4. Estereotipos de clases para el diseño de procesos de software. Estereotipo Descripción Gráfico Boundary Class Representa objetos que implementen la presentación o vista de las interfases o sistemas, por lo que también se les llama bordes o fronteras. En el proyecto se utiliza para representar a los JSPs del sistema. Control Class Representa objetos que se encargan de manejar las interacciones del sistema. En el proyecto se utiliza para representar a los Beans de Acción. Class Esta es la representación clásica de un objeto. En el proyecto se utiliza para representar al Servlet. Entity Class Representa objetos que son pasivos, y no inician ninguna interacción. En el proyecto se utiliza para representar a los Beans de Datos y Beans de Función en conjunto. A continuación se muestran los diagramas de secuencias de los principales flujos de los casos de uso del sistema. 66 3.1.4.1. Diagramas de secuencia: CU01 Consultar documentos Gráfico 3.4. Diagrama de secuencia: Consultar documentos 67 Gráfico 3.5. Diagrama de secuencia: Abrir documento 68 3.1.4.2. Diagramas de secuencia: CU02 Registrar documento Gráfico 3.6. Diagrama de secuencia: Registrar documento 69 3.1.4.3. Diagramas de secuencia: CU03 Registrar documento en contabilidad Gráfico 3.7. Diagrama de secuencia: Registrar documento en contabilidad 70 3.1.4.4. Diagrama de secuencia: CU04 Administrar documento Gráfico 3.8. Diagrama de secuencia: Aprobado documento en lote 71 3.1.4.5. Diagramas de secuencias: CU05 Administrar documento en contabilidad Gráfico 3.9. Diagrama de secuencias: Contabilizar documento 72 3.1.4.6. Diagramas de secuencias: CU08 Consultar lote de documentos Gráfico 3.10. Diagrama de secuencias: Consultar lote de documento 73 3.1.4.7. Diagramas de secuencias: CU09 Administrar lote de documentos Gráfico 3.11. Diagrama de secuencias: Registrar lote de documento 74 3.2. Modelo físico de datos A continuación se muestra el diseño físico de la base de datos general del sistema a través del modelo entidad-relación, para lo cual se utilizará la notación IDEF1X. Gráfico 3.12. Modelo entidad relación general del sistema 75 Vista funcional que muestra las entidades relacionadas con la entidad documento. Gráfico 3.13. Modelo entidad relación para el documento 76 Vista funcional que muestra las entidades relacionadas con la entidad lote. Gráfico 3.14. Modelo entidad relación para el lote Vista funcional que muestra las entidades relacionadas con la entidad flujo y nivel. Gráfico 3.15. Modelo entidad relación para el flujo y nivel 77 3.2.1. Especificación del modelo físico de datos A continuación se presenta la especificación del modelo físico de datos, la cual incluye la descripción de las tablas y sus columnas ordenadas alfabéticamente. Clasificación Clasificación que se le otorga a un documento o a un lote. Atributo Descripción clasificacion Código de identificación de la clasificación descriClasificacion Descripción de la clasificación indActividad Indica si la clasificación está activa A, inactiva I indDocumento Indica si la clasificación se usa para los documentos, 1 verdadero, 0 falso. indLote Indica si la clasificación se usa para los lotes 1 verdadero, 0 falso. CompromisosDocumento Compromisos presupuestales que generaron los sistemas de referencia. Atributo Descripción actividad Actividad que ha generado el compromiso presupuestal año Año del documento correlativoCp Correlativo de los compromisos registrados para el documento correlativoDoc Correlativo del documento mes Mes del documento monto Monto o importe del compromiso nivelOrigen Nivel origen del documento partida Partida presupuestal en la que se realizó el compromiso tipoTramite Tipo del trámite del documento unidad Unidad a la que pertenece la actividad que ha generado el compromiso presupuestal DetalleLote Documentos contenidos en un lote. Atributo Descripción añoDoc Año del documento añoLot Año del lote correlativoDoc Correlativo del documento correlativoLot Correlativo del lote mesDoc Mes del documento nivelOrigenDoc Nivel origen del documento nivelOrigenLot Nivel origen del lote seguimiento Código de identificación del seguimiento que se realiza al lote tipoTramiteDoc Tipo del trámite del documento 78 DistribucionAbono Distribución del monto total del documento en las unidades/actividades correspondientes (centros de costo). Atributo Descripción actividad Actividad a la que se distribuirá el abono ano Año de la cuenta año Año del documento correlativoAbo Correlativo del abono correlativoDoc Correlativo del documento cuenta Cuenta en la que se registrará el abono indPagar Indicador de pago mes Mes del documento monto Monto o importe del abono nivelOrigen Nivel origen del documento tipoTramite Tipo del trámite del documento unidad Unidad a la que pertenece la actividad a la que se le distribuirá el abono DistribucionCargo Distribución del monto total sin impuestos del documento en las unidades/actividades correspondientes (centros de costo). Atributo Descripción actividad Actividad a la que se distribuirá el cargo ano Año de la cuenta año Año del documento correlativoCar Correlativo del cargo correlativoDoc Correlativo del documento cuenta Cuenta en la que se registrará el cargo gravacion Código de identificación de la gravación que se aplica al cargo mes Mes del documento monto Monto o importe del cargo nivelOrigen Nivel origen del documento partida Partida presupuestal a la que afectará el cargo tipoTramite Tipo del trámite del documento unidad Unidad a la que pertenece la actividad a la que se le distribuirá el cargo Documento Documento Atributo Descripción año Año del documento archivoDigitalizado Documento digitalizado. clasificacionDoc Clasificación del documento correlativoDoc Correlativo del documento estado Estado del documento fechaEmision Fecha de emisión del documento físico fechaFinSusp Fecha fin de la suspensión del cobro de impuesto 79 fechaInicioSusp Fecha de inicio de la suspensión del cobro de impuesto fechaPago Fecha de pago del documento fechaRecepcion Fecha de recepción del documento físico flujoActual Flujo actual del documento forma_pago Código de identificación la forma de pago sugerida importeBruto Importe bruto o sin impuestos importeImpuesto Importe del impuesto importeTotal Importe total indContabilizado Indica si el documento ha sido contabilizado indDevolucion Indica si el documento ha sido devuelto al nivel de registro mes Mes del documento nivelActual Nivel actual del documento nivelOrigen Nivel origen del documento nroAdicReferencia Número adicional del documento de referencia nroDocFisico Número del documento físico nroDocReferencia Número del documento de referencia nroOperacionSusp Número de operación que suspende el cobro de un impuesto num_documento_id Número que relaciona el documento de tramite con el documento de pago origen Origen del documento periodo Periodo personaGiro Persona a la que se girará el pago, sólo si fuera diferente al proveedor porImpuesto Porcentaje de impuestos proveedor Proveedor serieDocFisico Serie del documento físico serviciosAjuste Monto o importe generado por servicios o ajustes en los cálculos de los importes parciales del documento siguienteNivel Siguiente nivel del flujo de aprobación al que debe pasar el documento sistemaReferencia Sistema de referencia tipoDocumento Tipo de documento tipoPersonaGiro Tipo de persona a la que se girará el pago, sólo si fuera diferente al proveedor tipoPersonaProveedor Tipo de persona del proveedor. tipoTramite Tipo de tramite, el proyecto será el primer tipo de tramite, esto servirá para que sistema pueda manejar el tramite de otro tipo de documentos tipoTransaccion Tipo de transacción que reemplazará al tipo de asiento por defecto del documento unidadDocumento Unidad responsable del documento Estado Estado del documento o lote. Atributo Descripción descriEstado Descripción del estado del documento estado Código que identifica el estado del documento indActividad Indica si el estado se encuentra activo A, inactivo I 80 Flujo Flujo de aprobación que siguen los documentos en el sistema. Atributo Descripción descriFlujo Descripción del flujo de aprobación flujo Código que identifica el flujo de aprobación tipoFlujo Código que identifica el tipo de flujo GENERAL.Personatural Persona que será usuaria del sistema. Esta tabla parte de la base de datos institucional PUCP, esquema GENERAL. Atributo Descripción apematerno Apellido materno de la persona apepaterno Apellido paterno de la persona codigo Código de la persona natural, en esta tabla se encuentran todos los usuarios de la intranet de la institución nombres Nombres de la persona Grabación Tipos de gravación que se le puede imponer al detalle de distribución del cargo. Atributo Descripción descriGravacion Descripción de la gravación Grabación Código que identifica el tipo de gravación IndAfecto Indica si es afecto 1 o no afecto 0. HistorialDocumento Historial de todas las acciones realizadas sobre un documento. Atributo Descripción Año Año del documento correlativoDoc Correlativo del documento correlativoHis Correlativo del historial fecha Fecha en que se realizó la acción flujoHistorico Flujo histórico del documento mes Mes del documento mostrarEnFlujo Indica si se debe mostrar en el historial del flujo de aprobación nivelHistorico Nivel histórico del documento nivelOrigen Origen del documento observacion Observación seguimiento Seguimiento de la acción que se realizó tipoTramite Tipo de trámite del documento usuario Usuario que realizó la acción 81 Impuesto Impuestos, valor y fecha de vigencia del impuesto. Atributo Descripción correlativo Correlativo del impuesto fechaFinVigencia Fecha de fin de vigencia del valor del impuesto fechaInicioVigencia Fecha de inicio de la vigencia del valor del impuesto impuesto Código que identifica el impuesto valor Valor del impuesto Lote Lote de documentos Atributo Descripción año Año del lote de documento clasificacionLot Clasificación del lote correlativoLot Correlativo del lote estado Estado del lote fechaAnulacion Fecha de anulación del lote fechaEnvio Fecha de envío del lote fechaRecepcion Fecha de recepción del lote fechaRegistro Fecha de registro del lote nivelDestino Nivel destino del lote nivelOrigen Nivel origen del lote observaciones Observaciones usuarioAnulacion Usuario que anula el lote usuarioEnvio Usuario que envió el lote usuarioRecepcion Usuario que recibe el lote usuarioRegistro Usuario que registró el lote Nivel Nivel, un nivel puede pertenecer a muchos flujos de aprobación. Atributo Descripción correlativoLote Correlativo del lote, que será usado para generar los códigos de lote correrlativoDocument o Correlativo del documento, que será usado para genera los códigos de los documentos descriNivel Descripción del nivel indActividad Indica si el nivel está activo A, inactivo I nivel Código que identifica al nivel tipoNivel Código que identifica el tipo de nivel unidadResponsable Unidad responsable del nivel 82 NivelXFlujo Relación de niveles que pertenecen a un flujo de aprobación. Atributo Descripción escalaFinal Importe o monto final o máximo que se encarga de revisar este nivel escalaInicial Importe o monto inicial que se encarga de revisar este nivel flujo Flujo de aprobación al que se relaciona el nivel indActividad Indica si el nivel del flujo está activo A, inactivo I nivel Código que identifica al nivel orden Orden de nivel dentro del flujo de aprobación Origen Origen de un documento. Ej.: nacional o extranjero. Atributo Descripción descriOrigen Descripción del origen del documento indActividad Indica si el origen está activo A, inactivo I origen Código que identifica el origen del documento Seguimiento Acción realizada sobre un documento, sirve para dar seguimiento al historial del documento. Atributo Descripción descripcion Descripción del seguimiento indActividad Indica si el seguimiento está activo A, inactivo I. indHistorial Indica si el seguimiento es usado para documentos - en su historial. indLote Indica si el seguimiento es usado para lotes de documentos. seguimiento Código que identifica el seguimiento o acción que se realiza sobre el documento o lote SICOP.mae_actidad Actividad o centro de costo de la institución. Esta tabla pertenece a la base de datos institucional, y sirve de integración con el sistema contable presupuestal PUCP. Esquema SICOP. Atributo Descripción actividad Código que identifica la actividad unidad Código que identifica la unidad a la que pertenece la actividad SICOP.mae_subtipoasiento Sub tipo de asiento contable. Esta tabla pertenece a la base de datos institucional, y sirve de integración con el sistema contable presupuestal PUCP. Esquema SICOP. Atributo Descripción asiento_subtipo Código que identifica el subtipo de asiento contable asiento_Tipo Código que identifica el tipo de asiento contable 83 SICOP.mae_cuenta Cuenta contable. Esta tabla pertenece a la base de datos institucional, y sirve de integración con el sistema contable presupuestal PUCP. Esquema SICOP. Atributo Descripción ano Año de la cuenta cuenta Código que identifica una cuenta contable SICOP.mae_forma_pago Forma de pago de los documentos. Esta tabla pertenece a la base de datos institucional, y sirve de integración con el sistema contable presupuestal PUCP. Esquema SICOP. Atributo Descripción forma_pago Código que identifica la forma de pago del documento SICOP.mae_partida Partida presupuestal. Esta tabla pertenece a la base de datos institucional, y sirve de integración con el sistema contable presupuestal PUCP. Esquema SICOP. Atributo Descripción partida Código que identifica la partida SICOP.mae_persona Persona. Esta tabla pertenece a la base de datos institucional, y sirve de integración con el sistema contable presupuestal PUCP. Esquema SICOP. Atributo Descripción persona Código que identifica la persona en el sistema contable presupuestal tipoPersona Código que identifica el tipo de persona del sistema contable presupuestal SICOP.mae_unidad Unidad o área de la institución. Esta tabla pertenece a la base de datos institucional, y sirve de integración con el sistema contable presupuestal PUCP. Esquema SICOP. Atributo Descripción unidad Código que identifica la unidad SICOP.tes_cab_docpag Documento de pago, es la interfase a donde debe llegar el documento de trámite para que sea pagado. Esta tabla pertenece a la base de datos institucional, y sirve de integración con el sistema contable presupuestal PUCP. Esquema SICOP. 84 Atributo Descripción num_documento_id Código que identifica el documento en el sistema de pagos SistemaReferencia Sistema de adquisición de bienes o servicios que interactúa con el sistema de trámite de documentos. Atributo Descripción DescriReferencia Descripción del sistema de referencia IndAdjuntar Indica si debe adjuntar o no documento digitalizado sistemaReferencia Código que identifica el sistema de referencia de adquisición de bienes o servicios TipoDocumento Tipo de documento. Atributo Descripción abreviatura Abreviatura del tipo de documento asiento_subtipo Subtipo de asiento que se debe generar por tipo de documentos asiento_Tipo Tipo de asiento que se debe generar por tipo de documentos codigoSunat Código SUNAT del documento descriImpBruto Descripción del importe bruto para el tipo de documento descriImpTotal Descripción del importe total para el tipo de documento descripcion Descripción del tipo de documento descripcionCorta Descripción corta del tipo de documento diasPlazoPago Días de plazo para realizar el pago del documento tipoDocumento Código que identifica el tipo de documento tipoTramite Tipo de trámite que se encargará de tramitar el tipo de documento TipoFlujo Tipo de flujo. Atributo Descripción descriTipoFlujo Descripción del tipo de flujo tipoFlujo Código que identifica el tipo de flujo de aprobación TipoNivel Tipo de nivel. Atributo Descripción descriTipoNivel Descripción del tipo de nivel indDatosContables Indica si se debe mostrar la sección de datos contables en la aplicación indDistribucionAbono Indica si se debe mostrar la sección de distribución de abono en la aplicación indDistribucionCargo Indica si se debe mostrar la sección de distribución de cargo en la aplicación indFlujoAprobacion Indica si se debe mostrar la sección de flujo de aprobación en la aplicación tipoNivel Código que identifica el tipo de nivel 85 TipoTramite Tipo de trámite. Atributo Descripción descripcion Descripción del tipo de trámite tipoTramite Código que identifica el tipo de trámite TipoFlujoxSisReferencia Tipos de flujo de aprobación que se relaciona con un sistema de referencia. Atributo Descripción sistemaReferencia Sistema de referencia tipoFlujo Tipo de flujo TipoTransaccion Tipo de transacción, se usa cuando el asiento del documento no se va a generar de acuerdo el tipo de asiento correspondiente al tipo de documento Atributo Descripción asiento_subtipo Subtipo de asiento asiento_Tipo Tipo de asiento descriTipoTransaccion Descripción de tipo de transacción tipoTransaccion Código que identifica el tipo de transacción UnidadesPermitidasxFlujo Unidades permitidas por flujo de aprobación, para restringir el flujo de documentos según la unidad responsable. Atributo Descripción flujo Flujo de aprobación unidad Unidad permitida UsuarioXNivel Usuarios por nivel, aquí se detallan los roles y permisos que tiene en cada nivel. Atributo Descripción indActividad Indica si el usuario está activo A, inactivo I indAsistente Indica si es Asistente 1 o no 0. indContador Indica si es Contador 1 o no 0. indEncargado Indica si es Encargado de unidad 1 o no 0. indRegistrador Indica si es Registrador 1 o no 0. montoMaxAprobacion Monto máximo que puede aprobar un usuario en el nivel, solo tipo nivel unidad nivel Nivel en el que está autorizado el usuario usuario Código de usuario 86 3.3. Prototipos del sistema Los prototipos del sistema han sido diseñados cumpliendo el requerimiento no funcional RNF01 que indica que la interfaz de usuario debe ser sencilla e intuitiva. En las siguientes páginas se presentaran las pantallas del sistema, agrupadas según el caso de uso que las generó. 3.3.1. Pantallas: CU01 Consultar Documento Gráfico 3.16. Pantalla: Consultar documentos Gráfico 3.17. Pantalla: Resultado de la consulta de documentos. 87 Gráfico 3.18. Pantalla: Abrir documento - Datos generales. Gráfico 3.19. Pantalla: Visualizar documento digitalizado Clic para descargar y visualizar el documento digitalizado 88 Gráfico 3.20. Pantalla: Abrir documento - Flujo de aprobación. 3.3.2. Pantallas: CU02 Registrar Documento Gráfico 3.21. Pantalla: Registrar documento 89 3.3.3. Pantallas: CU03 Registrar Documento en Contabilidad Gráfico 3.22. Pantalla: Registrar datos generales Gráfico 3.23. Pantalla: Registrar datos contables 90 Gráfico 3.24. Pantalla: Registrar datos de la distribución 3.3.4. Pantallas: CU04 Administrar documento Gráfico 3.25. Pantalla: Aprobar documento en lote 91 Gráfico 3.26. Pantalla: Aprobar documento individual Esta pantalla también sirve para acceder a las funcionalidades de editar, devolver y anular. 3.3.5. Pantallas: CU05 Administrar documento en contabilidad Gráfico 3.27. Pantalla: Documentos por contabilizar 92 Gráfico 3.28. Pantalla: Contabilizar documento Esta pantalla también sirve para acceder a las funcionalidades de editar, devolver y anular. Gráfico 3.29. Pantalla: Editar documento – Datos Contables 93 Gráfico 3.30. Pantalla: Editar documento - Distribución Gráfico 3.31. Pantalla: Editar documento – Asiento contable 94 3.3.6. Pantallas: CU07 Consultar documento vía extranet Gráfico 3.32. Pantalla: Consultar documentos vía extranet Gráfico 3.33. Pantalla: Resultado de la consulta de documentos vía extranet. 3.3.7. Pantallas: CU08 Consultar lote de documentos Gráfico 3.34. Pantalla: Consultar lote de documentos Ingresa un número de lote o selecciona algún criterio de búsqueda. 95 Gráfico 3.35. Pantalla: Resultados de consultar lote de documentos Gráfico 3.36. Pantalla: Abrir lote de documentos 96 3.3.8. Pantallas: CU09 Administrar lote de documentos Gráfico 3.37. Pantalla: Registrar lote Gráfico 3.38. Pantalla: Registrar lote - Después que se consultan los documentos que se pueden agregar al lote Ingresa los datos generales del lote. Se ingresa uno o más criterios para encontrar los documentos disponibles. Selecciona uno o varios documentos disponibles. 97 Gráfico 3.39. Pantalla: Registrar lote con los documentos físicos seleccionados. Gráfico 3.40. Pantalla: Lote de documentos registrado 98 Gráfico 3.41. Pantalla: Lotes de documentos por recibir Gráfico 3.42. Pantalla: Recibir lote de documentos Gráfico 3.43. Pantalla: Lote recibido Seleccionar los documentos físicos que llegaron en el lote. 99 4. Observaciones, conclusiones y recomendaciones 4. 4. 4.1. Observaciones En esta sección se busca dar énfasis a los siguientes puntos vistos en el proyecto: • Investigación realizada Para llevar a cabo el proyecto se realizó la investigación y estudio de las últimas versiones de la metodología RUP y el lenguaje UML, para el análisis y diseño en la Ingeniería de Software. • Metodología utilizada La elección de la metodología fue un punto clave para el éxito del proyecto. Para la presente tesis se escogió RUP, y gracias a su flexibilidad fue adaptado a las necesidades de este proyecto. RUP promueve que se dé prioridad a las principales necesidades de las partes interesadas, por lo que los principales requerimientos obtenidos fueron considerados en el presente proyecto. 100 • Obtención de requerimientos La adecuada captura de requerimientos es la base para las siguientes etapas del desarrollo del software, por este motivo los requerimientos del proyecto se obtuvieron en las reuniones sostenidas con los usuarios involucrados en los procesos del negocio. • Elaboración de los casos de uso En la elaboración de casos de uso se evitó la creación de casos de uso complejos o muy pequeños, y se optó por crear casos de usos que represente las funcionalidades que cada actor puede realizar sobre el sistema, de estar forma se promueve una adecuada comprensión del sistema. • Diseño de los prototipos Durante la fase de diseño se eligió una arquitectura WEB basada en el modelo MVC. En base a la arquitectura y a los requerimientos funcionales se elaboraron los prototipos del sistema, los cuales fueron presentados a los usuarios que participaron en la fase de análisis, lo que permitió refinar los requerimientos iniciales y descubrir nuevos requerimientos, los cuales serán atendidos en próximas iteraciones del proyecto. 4.2. Conclusiones Como consecuencia del trabajo realizado se ha llegado a las siguientes conclusiones: • Se ha cumplido con el objetivo de realizar el análisis y diseño de un sistema de Trámite de Documentos de Pago a Proveedores vía Intranet, con el fin de apoyar las labores administrativas de una institución organizada en unidades como la PUCP, institución del caso práctico. • Se realizó el análisis y diseño del sistema en base a los procesos principales del negocio. Los requerimientos se determinaron a través del levantamiento de información en las reuniones sostenidas con el personal involucrado en los 101 procesos del negocio de cada unidad, y fueron refinados con la participación de ellos en el diseño de los prototipos. La participación de los “stakeholders” y futuros usuarios del sistema durante el proceso de desarrollo de software es de suma importancia para alcanzar los propósitos de la institución. • Se controló el seguimiento del flujo de aprobación de un documento de pago a proveedores, el cual se realiza desde el registro del documento, revisión en cada una de las unidades de la institución que conforman el flujo de aprobación que debe seguir el documento, hasta la contabilización del documento. • Se logró brindar la funcionalidad que permite la creación de flujos de aprobación de documentos de acuerdo a las necesidades de la institución, de manera flexible, quedando a criterio la centralización o descentralización de cada nivel de trámite de los documentos, así como la elección de los niveles involucrados en cada flujo. • Se mejoró el proceso de trámite de los documentos de pago a proveedores, y la implementación del sistema se realizará en base al análisis y diseño realizado en la presente tesis. 4.3. Recomendaciones La metodología RUP promueve el desarrollo iterativo e incremental de los proyectos de desarrollo de software, por lo que la ampliación de lo expuesto en la presente tesis es completamente viable. Entre las posibles extensiones de la investigación realizada se recomiendan las siguientes: • Interfase que permita al sistema tramitar documentos electrónicos de pago a proveedores: El sistema de emisión electrónica es un mecanismo desarrollado por la SUNAT, el cual permite actualmente la emisión electrónica de Recibos por Honorarios y Notas de Crédito, y se extenderá a otro tipo de documentos, a través de su portal WEB, 102 aún se encuentra en fase piloto, por lo que esta interfaz no fue considerada dentro del alcance del proyecto. Este sistema permite que el contribuyente se afilie y emita documentos electrónicos. La afiliación es opcional, y además se le permite al contribuyente que emita documentos tanto físicos como virtuales. Será necesario que los documentos electrónicos puedan integrarse al sistema de Trámite de documentos de Pago vía Intranet. Cada institución cuenta también con un usuario que le permite ingresar al portal WEB de la SUNAT donde puede visualizar todos los documentos electrónicos que le son emitidos, la interfase contribuiría a ingresar los documentos al sistema, para que puedan seguir el flujo de aprobación que le corresponda. • Ampliación de la extranet de proveedores Como primera parte de este módulo se ha planteado en la presente tesis la funcionalidad que permite que los proveedores puedan consultar el estado del trámite de los documentos de pago que le ha emitido a la institución. El uso de la Internet se ha incrementado vertiginosamente, por este motivo cada vez más empresas tienen acceso a la red, por lo que se podrá involucrar activamente al proveedor dentro del proceso de trámite. Este módulo puede permitir adicionalmente el registro de los documentos de trámite directamente por el proveedor. • Minería de datos El procesamiento de la data histórica almacenada por el sistema permitirá obtener estadísticas sobre el tiempo que toma la atención de los documentos de trámite por tipo de documento, por tipo de flujo, por nivel, entre otros. La información que se obtenga a través de estas estadísticas le servirá a cada unidad de la institución para plantear sus indicadores de gestión, los cuales son necesarios para la implementación de un sistema de gestión de la calidad como ISO 9001:2000. 103 • Elaboración de reportes Reportes que muestren la relación de la información del sistema de Trámite de Documentos de Pago a proveedores con la información de los sistemas de solicitudes de adquisición de bienes y servicios, y con el sistema de pagos de la institución, entre otros. Bibliografía Libros [Arlow, Neustad] JIM ARLOW, ILA NEUSTADT, “UML and the Unified Process: Practical Object-Oriented Analysis & Design”, Addison-Wesley 2002. [Larman] CRAIG LARMAN, “Applying UML and patterns: and introduction to object-oriented analysis and design and iterative development”, 3ra Edición, Pearson Educación 2007. [Lizonde] AMADOR LIZAONDE, “Casos prácticos de asientos contables: teoría y práctica”, OCAE 1992. [Rumbaugh] JAMES RUMBAUGH, IVAR JACOBSON, GRADY BOOCH, “The Unified Modeling Language Reference Manual”, Addison-Wesley 2000. [Sánchez] JOSÉ LUIS SÁNCHEZ FERNÁNDEZ DE VALDERRAMA, “Teoría y práctica de la contabilidad”, Pirámide 2005. [Shuja,Krebs] AHMAD K. SHUJA, JOCHEN KREBS, “IBM® Rational Unified Process® Reference and Certification Guide: Solution Designer”, IBM Press 2007. [Sommerville] IAN SOMMERVILLE, “Software Engineering”, 7ma Edición. Pearson Educación 2004. Referencias de fuentes electrónicas [DIRINFO] http://difinfo.pucp.edu.pe [MICROSYSTEM] http://www.ibm.com/expressadvantage/cl/solutions/workflow_doc.phtml?ca=Workflow_de_ap robacion_de_Documentos_Tributarios_MICROSYSTEM&me=W&met=inli [SAP] http://www.sap.com [UML] http://www.uml.org