desarrollo de un aplicativo para generar la …
TRANSCRIPT
DESARROLLO DE UN APLICATIVO PARA GENERAR LA FACTURACIÓN EN LA EMPRESA SOFTWARE BUILDERS LTDA.
JULIO CESAR ROMANÍ LOYOLA
VLADIMIR ORTIZ VELÁSQUEZ
UNIVERSIDAD DE SAN BUENAVENTURA FACULTAD DE INGENIERÍA
PROGRAMA DE INGENIERÍA DE SISTEMAS BOGOTÁ D.C
2008
DESARROLLO DE UN APLICATIVO PARA GENERAR LA FACTURACIÓN EN LA EMPRESA SOFTWARE BUILDER LTDA.
JULIO CESAR ROMANÍ LOYOLA
VLADIMIR ORTIZ VELÁSQUEZ
PROYECTO DE GRADO PARA OPTAR AL TÍTULO DE INGENIERO DE SISTEMAS
ASESOR
INGENIERO: NELSON AUGUSTO FORERO PÁEZ
UNIVERSIDAD DE SAN BUENAVENTURA FACULTAD DE INGENIERÍA
PROGRAMA DE INGENIERÍA DE SISTEMAS BOGOTÁ D.C
2008
Nota de aceptación:
_____________________________________ _____________________________________ _____________________________________ _____________________________________ _____________________________________ _____________________________________ _____________________________________
_____________________________________
Firma del presidente del jurado
_____________________________________ Firma del jurado
_____________________________________ Firma del jurado
Bogotá, 27 de Noviembre de 2008
DEDICATORIA
Primero que todo agradezco a dios quien fue que me dio la vida y la sabiduría para
poder realizar este proyecto. Dedico este proyecto a mis padres quienes siempre me apoyaron en cada paso que di,
dedico también este proyecto a mi novia quien siempre me estuvo ayudando y
apoyando cada día en la labor de mi trabajo y proyecto, por ultimo agradezco a mi hermana
que con su alegría me motivo a continuar en un arduo trabajo
(Dedicatoria) Julio César Romani Loyola
(Dedicatoria)
Primero agradezco a Dios quien fue mi creador y me dio muchas bendiciones. Dedico este documento a mi Padre y a mi familia que siempre estuvieron allí presentes en este camino. Donde siempre conté con ellos y me apoyaron para llegar donde estoy. A mi novia que me motivaba cada día que pasaba en salir adelante para culminar estas metas propuestas. Para terminar, agradezco a mis amigos que estuvieron presentes en este proceso de adquirir el título de INGENIERO DE SISTEMAS. Gracias.
(Dedicatoria) Vladimir Ortiz Velásquez
AGRADECIMIENTOS
Estamos por el camino de optar el título de Ingeniero de sistemas, en el cual nos
hemos encontrado con muchos obstáculos a vencer y retos a superar, que nos hacen
cada día mejores personas. Logrando crecer como profesionales demostrando lo
aprendo en la Universidad San Buenaventura – sede Bogotá donde permanecimos 5
años de nuestras vidas compartiendo con amigos y profesores que dieron lo mejor de
ellos para hacer de esto una experiencia alegre.
En primera medida queremos agradecer a Dios que nos dio la vida, y la oportunidad
de venir a este mundo con muchas cualidades a compartir, aprender, gozando de
buena salud y lo más importante junto a una familia donde se encuentra un gran
amor.
En segundo lugar agradecer a la empresa Software Builders Ltda. que nos permitió
realizar las pasantías y nos ofreció la oportunidad de trabajar aportando nuestros
servicios profesionales realizando un proyecto en el cual se conto con el apoyo del
Ingeniero César Riaño que nos brindó la ayuda necesaria para logras los objetivos
propuestos.
Además hay que agradecer a Juan Carlos Valencia Ortiz que sin conocerlo muy bien
es más que un amigo ya que nos brindó su ayuda permitiendo culminar este proyecto
y llevarlo a la fase de implementación.
Por culminar agradecemos al Ingeniero Nelson Forero quien fue nuestro tutor de
proyecto pero más que un tutor fue un amigo que estuvo siempre pendiente de
nosotros y de que este proyecto se lleve a cabo con éxito.
CONTENIDO
Pág.
INTRODUCCIÓN 9
1. PLANTEAMIENTO DEL PROBLEMA 11
1.1 ANTECEDENTES 11
1.2 DESCRIPCIÓN Y FORMULACIÓN DEL PROBLEMA 12
1.3 JUSTIFICACIÓN 12
1.4 OBJETIVOS DE LA INVESTIGACIÓN 13
1.4.1 Objetivo General 13
1.4.2 Objetivos Específicos 13
1.5 ALCANCES Y LIMITACIONES DEL PROYECTO 13
2. MARCO DE REFERENCIA 14
2.1 MARCO TEÓRICO - CONCEPTUAL 14
2.2 MARCO LEGAL O NORMATIVO 27
3. METODOLOGÍA 30
3.1 ENFOQUE DE LA INVESTIGACIÓN 30
3.2 LÍNEA DE INVESTIGACIÓN DE USB/ SUB-LÍNEA DE FACULTAD/
CAMPO TEMÁTICO DEL PROGRAMA 30
3.3 TÉCNICAS DE RECOLECCIÓN DE INFORMACIÓN 30
3.4 HIPÓTESIS 31
3.5 VARIABLES 31
3.5.1 Variables Independientes 31
3.5.2 Variables Dependientes 31
4. DESARROLLO INGENIERIL 32
5. CONCLUSIONES 99
6. RECOMENDACIONES 100
BIBLIOGRAFÍA 101 GLOSARIO 102
ANEXO 104
LISTA DE TABLAS
Pág.
Tabla 1. Motores Base de Datos. ....................................................................................40
Tabla 2. Caso de Uso de Facturación..............................................................................45
Tabla 3. Caso de Uso de Comercial. ...............................................................................49
Tabla 4. Caso de Uso de Administración........................................................................53
Tabla 5. Caso de Uso de Contabilidad ............................................................................56
Tabla 6. Diccionario Base de Datos (ASIENTOS CONTABLES) ................................65
Tabla 7. Diccionario Base de Datos (CLIENTE)............................................................66
Tabla 8. Diccionario Base de Datos (CIUDAD).............................................................67
Tabla 9. Diccionario Base de Datos (DETALLE_PAGOS) ...........................................67
Tabla 10. Diccionario Base de Datos (DETALLE_FACTURA)....................................68
Tabla 11. Diccionario Base de Datos (FORMA_PAGO) ...............................................68
Tabla 12. Diccionario Base de Datos (PAGOS) .............................................................69
Tabla 13. Diccionario Base de Datos (TIPO_DEFINICIÓN) ........................................69
Tabla 14. Diccionario Base de Datos (PRODUCTOS Y/O SERVICIOS).....................70
Tabla 15. Diccionario Base de Datos (VALORES_DEFINICIONES) ..........................70
Tabla 16. Diccionario Base de Datos (CONCEPTO_CONTABLE)..............................71
Tabla 17. Diccionario Base de Datos (CONTRATO) ....................................................71
Tabla 18. Diccionario Base de Datos (DETALLE_CONTABLE).................................72
Tabla 19. Diccionario Base de Datos (PAÍS)..................................................................72
Tabla 20. Diccionario Base de Datos (FACTURA)........................................................73
Tabla 21. Diccionario Base de Datos (PERSONA)........................................................74
LISTA DE FIGURAS
Pág.
Figura 1. Ciclo de vida de un Software...........................................................................33
Figura 2. Ciclo de vida de un Software – Fase Estrategia. .............................................34
Figura 3. Ciclo de vida de un Software – Fase Análisis. ................................................41
Figura 4. Modelo Entidad Relación – versión 1. ............................................................42
Figura 5. Caso de Uso Facturación .................................................................................44
Figura 6. Caso de uso Comercial. ...................................................................................48
Figura 7. Caso de uso Administrador.............................................................................52
Figura 8. Caso de uso Contabilidad. ...............................................................................55
Figura 9. Diagrama de Funciones. ..................................................................................58
Figura 10. Diagrama de Funciones –jerárquico. .............................................................59
Figura 11. Diagrama de Funciones Global. ....................................................................60
Figura 12. Ciclo de vida de un Software – Fase Diseño. ................................................61
Figura 13. Modelo entidad relación - versión 2. ............................................................62
Figura 14. Modelo arquitectura de red............................................................................63
Figura 15. Ciclo de vida de un Software – Fase Construcción. ......................................65
Figura 16. Ciclo de vida de un Software – Fase Documentación. ..................................75
Figura 17. Ciclo de vida de un Software – Fase Transición. ..........................................76
Figura 18. Ciclo de vida de un Software – Fase Producción. .........................................77
Figura 19. Ciclo de vida de un Software – Pruebas. .......................................................79
10
INTRODUCCIÓN
Al paso de los años la humanidad ha encontrado la manera de almacenar información,
ya sea por considerarla como una simple actividad o por tener en cuenta su
importancia, la documentación y las tecnologías de la información han evolucionado
provocando la proliferación de líneas de investigación en este campo, por lo cual se ha
multiplicado la tendencia de analizar la información permitiendo generar resultados y
agilizar la toma de decisiones.
La información es un recurso vital para toda organización, el buen manejo y control
significa la diferencia entre el éxito o el fracaso para una empresa que se encuentre en
una etapa de crecimiento.
Los sistemas de información y las tecnologías han sufrido un cambio, donde los dos
están acoplados de una forma que evolucionan mutuamente. La documentación de
una organización es importante puesto que al automatizar los procesos aceleran el
intercambio de los datos, alcanzando objetivos o metas propuestas por cada empresa
donde sus ventajas se fortalecen ante los rivales.
Muchas empresas y organizaciones tienen éxito por la implementación y uso de los
sistemas de información, haciendo de sus áreas una integración sólida que permita
obtener resultados de modo que sea más eficiente.
La empresa Software Builders Ltda. almacena gran cantidad de papel por el volumen
de información que emplea en la compañía, por lo tanto se hace necesario desarrollar
un aplicativo que permita automatizar el proceso de facturación con el fin de tener el
control total sobre los datos para tomar decisiones en tiempo real.
11
1. PLANTEAMIENTO DEL PROBLEMA
1.1 ANTECEDENTES Desde 1993 se fundó Software Builders Ltda partiendo de la idea de sus creadores
Cesar Augusto Riaño y Clara Inés Rincón quienes tenían un pensamiento de dar
solución a la medida teniendo como propósito ser una de las mejores compañías a
nivel departamental, poco a poco fue creciendo y al cabo de cierto tiempo no se
convirtió solamente en una compañía a nivel departamental sino en una compañía
nacional e internacional. Desde los inicios de la empresa hasta la actualidad, Software
Builders Ltda ha generado el proceso de facturación manualmente teniendo como
problemas la búsqueda, almacenamiento e inconsistencia de la información lo que no
permitía tener los datos en tiempo real para toma de decisiones. En consecuencia el
proceso no era el más conveniente debido a que el gerente comercial no podía tener
informes contables para un balance general de la empresa.
“Actualmente la empresa Software Builders Ltda.1 trabaja para constituirse como
una de las empresas líderes en el sector de desarrollo y consultoría de software con
alta participación en el mercado, reconocida por sus clientes por prestar un servicio de
alta calidad y confiabilidad con procesos ágiles y estandarizados, contribuyendo
activamente al desarrollo tecnológico del país.
La compañía tiene como fin el desarrollo y la consultoría de Software, integrada por
un equipo de expertos en diferentes áreas, que ofrecen a sus clientes el diseño e
implementación de sistemas eficientes y confiables para sus empresas, utilizando las
últimas tecnologías y dando un acompañamiento permanente que garantiza una total
transferencia tecnológica. Los servicios que ofrece la compañía están orientados a tres
grandes áreas: Consultoría, Construcción y Capacitación en Sistemas de información
además de vender aplicativos y productos que permiten consolidar la información de
una empresa de un modo más ágil y eficaz”.
1 Disponible en: http://www.software-b.com/sb/ 05-Septiembre-2008 1:20 A.M
12
1.2 DESCRIPCIÓN Y FORMULACIÓN DEL PROBLEMA En la actualidad la empresa Software Builders Ltda. realiza su proceso de facturación
manualmente, conservando una gran cantidad de papel que ocupa espacio. Trayendo
como consecuencia la falta de control de acceso a los archivos que con el tiempo se
podrían perder o dañar según su manipulación. La asignación de privilegios sobre
estos documentos es una tarea casi imposible por lo consiguiente no tiene un registro
de facturación automatizado por lo tanto no permitirá a la empresa controlar y analizar
la información de una forma correcta.
Además el tiempo de respuesta no es el apropiado hacia sus clientes teniendo en
cuenta que la factura se elabora manualmente, presentando ciertos inconvenientes
como datos escritos erróneamente, productos y/o servicios que no se relacionan con
su valor, de una forma generando inconsistencia en el área de la contabilidad.
¿Qué características técnicas y funcionales debe tener un sistema de información para
la automatización del proceso de facturación en la empresa Software Builders Ltda.?
1.3 JUSTIFICACIÓN
Utilizando software libre sin costo de licenciamiento se realizara un aplicativo que
automatice el proceso de facturación en la empresa Software Builders Ltda. logrando
mejorar el tiempo de respuesta y controlar la información generando informes y
estadísticas que permitan manipular los datos de una forma eficiente en el área
contable de la empresa agilizando el desarrollo de una factura.
Este proyecto es importante porque el valor agregado es la implementación del
aplicativo “SIFAC” en las instalaciones de la empresa Software Builders Ltda. dando
solución al problema que presenta en la actualidad, mejorando el proceso de
facturación haciéndolo de una forma más amigable y eficiente.
13
1.4 OBJETIVOS DE LA INVESTIGACIÓN
1.4.1 Objetivo General
Desarrollar un sistema de facturación automatizado para la empresa Software Builders
Ltda.
1.4.2 Objetivos Específicos
Determinar los requerimientos funcionales y no funcionales del sistema de
facturación.
Diseñar la base de datos y las interfaces de usuarios que permita generar la
facturación.
Implementar los diseños propuestos utilizando herramientas de software libre.
Realizar pruebas de funcionamiento del sistema desarrollado.
1.5 ALCANCES Y LIMITACIONES DEL PROYECTO
Con el desarrollo de este proyecto se pretende llegar hasta la implementación del
aplicativo en las instalaciones de la empresa Software Builders Ltda.
Este desarrollo será pionero en las instalaciones de la empresa Software Builders
Ltda. automatizando las facturas y el manejo de la información, logrando una eficiencia
en la manipulación de dicha información.
El aplicativo está sujeto a la recolección de información de la empresa, lo que no
permitiría tener almacenado todos los datos que la empresa Software Builders Ltda.
requiere en un determinado tiempo.
14
2. MARCO DE REFERENCIA
En esta sección se tratarán conceptos fundamentales del proceso de facturación.
2.1 MARCO TEÓRICO - CONCEPTUAL
Persona Jurídica: Persona que para la realización de determinados fines colectivos,
las normas jurídicas les reconocen capacidad para ser titular de derechos y contraer
obligaciones.
Factura: Documento que refleja la entrega de un producto o la provisión de un
servicio, junto a la fecha de facturación, además de indicar la cantidad a pagar como
contraprestaciones.
Factura por Computador: La factura por computador es la que cumple con todos los
requisitos establecidos en los artículos 617 y 618 del Estatuto Tributario que permiten
al Software asociar la identificación del artículo o servicio con la tarifa del impuesto
sobre las ventas correspondiente.
Régimen Tributario: Refiere al concepto de persona (natural o jurídica) como sujeto
pasivo, contribuyente o responsable de impuestos. Dentro del régimen tributario se
encuentra el régimen común y el régimen satisfactorio.
Régimen Común: Son todas aquellas personas jurídicas y toda persona natural solo
será responsable del régimen común si no cumplen todos o uno de los requisitos que
la norma establece para poder formar parte del régimen simplificado.
Régimen Simplificado: Legislación especial que se aplica a personas con
características particulares, denominadas “pequeños comerciantes”, para determinar
el pago que éstas deben hacer, por concepto de impuesto al estado.
Contrato: Acuerdo entre empresario (cliente) y trabajador (vendedor) por el que el
trabajador presta una serie de servicios a cambio de una retribución (salario).
PUC: Registra el valor de las aceptaciones (bancarias) creadas por la entidad por
cuenta de sus clientes y las creadas por cuenta de ésta por sus corresponsales.
15
CIIU: Es una clasificación uniforme de las actividades económicas por procesos
productivos. Su objetivo principal es proporcionar un conjunto de categorías de
actividades que se pueda utilizar al elaborar estadísticas sobre ellas.
IVA: Impuesto nacional a los consumos que se aplica en cada una de las etapas del
proceso económico, en proporción al valor agregado del producto y la prestación de
servicios.
Retención de IVA: Consiste en que el comprador, al momento de causar o pagar la
compra, retiene al vendedor el 50% del valor del IVA.
Retención de ICA: Impuesto determinado por cada cuidad o municipio que se le
aplica a todos los comerciantes de la ciudad su porcentaje o tarifa varia según el
producto que este en transacción.
Retención en la fuente: Mecanismo que busca recaudar un determinado impuesto de
forma anticipada. De esta forma cada vez que ocurra un hecho generador de un
impuesto, se hace la respectiva retención.
Contrato
Un contrato es un acuerdo entre empresario (cliente) y trabajador (vendedor) por el
que el trabajador presta una serie de servicios a cambio de una retribución (salario).
Un contrato supone unos derechos para el trabajador, que se convierten en
obligaciones para el empresario. Al mismo tiempo, las obligaciones que contrae el
trabajador se convierten en derechos de su empresario.
Las modalidades de contratación son diversas y se clasifican según la manera como
se suscribe el mismo o el tiempo de duración que vaya a tener la prestación del
servicio personal al empleador. El contrato de trabajo es consensual, lo cual significa
que para su perfeccionamiento tan solo requiere del consentimiento de las partes.
Para que este sea válido no se requiere forma especial alguna. Predomina el principio
de la primacía de la realidad sobre la forma; de esta manera, cuando hay prestación
16
personal del servicio, subordinación o dependencia y remuneración, existe un contrato
de trabajo.
Los contratos laborales pueden clasificarse según su forma y su término de duración
como lo son:
• Contrato Verbal de trabajo: como su nombre lo indica es aquel que se
celebra de palabra y hace referencia al acuerdo verbal entre un empleador y un
trabajador sobre una determinada labor, el lugar de prestación del servicio y su
remuneración.
• Contrato escrito de trabajo: es el acuerdo entre trabajador y empleador que
se plasma en un documento. Se facilita de esta manera la prueba del contrato,
aunque no sobra advertir que para probar dentro de un proceso la existencia
de un contrato laboral se admiten los demás medios probatorios, tales como el
testimonio, la inspección judicial y reconocimiento de documentos.
• Contrato a término fijo: es aquel que tiene un límite en el tiempo. Las partes
determinan exactamente la fecha en que ha de terminarse el contrato.
Anteriormente, no podían ser inferiores a un año, salvo ciertas circunstancias
de las empresas como reemplazos temporales de trabajadores por licencias,
vacaciones.
• Contrato a término fijo inferior a un año: el trabajador vinculado de esta
manera tiene derecho a todas las prestaciones sociales y a vacaciones en
forma proporcional, sea cual sea el tiempo laborado. Sin embargo, este tipo de
contratos únicamente pueden prorrogarse hasta por tres veces, por periodos
iguales o inferiores, al cabo de los cuales el término de renovación no podrá
ser inferior a un año y así sucesivamente.
• Contrato a término indefinido: es el más común de los contratos laborales y
se caracteriza porque no tiene limitación en el tiempo, no prevé ninguna fecha,
condición o circunstancia que permita conocer desde su inicio el momento
hasta el cual habrá de tener vigencia el mismo.
• Contrato de obra: en este tipo de contrato la duración del mismo se encuentra
determinada por el tiempo necesario para la ejecución completa de una
determinada obra o labor. Es usado frecuentemente en el sector de la
construcción. Este contrato debe celebrarse por escrito, con el fin de dejar
17
constancia expresa de cuál es el objeto que se persigue con dicha
contratación.
• Contrato Ocasional o Transitorio: consiste en la ejecución de labores ajenas
a las actividades normales de una empresa y cuya duración no puede exceder
de treinta (30) días. En este tipo de contratación el trabajador solo tiene
derecho al pago del valor acordado por sus servicios y a que se le suministren
primeros auxilios en caso de ocurrir un accidente de trabajo. No tiene derecho
a ninguna otra prestación.
Orden de Compra
Una orden de compra es una solicitud escrita a un proveedor, por determinados
artículos a un precio convenido. La solicitud también especifica los términos de pago y
de entrega.
La orden de compra es una autorización al proveedor para entregar los artículos y
presentar una factura.
Todos los artículos comprados por una compañía deben acompañarse de las órdenes
de compra, que se enumeran en serie con el fin de suministrar control sobre su uso.
Por lo general se incluyen los siguientes aspectos en una orden de compra:
• Nombre impreso y dirección de la compañía que hace el pedido
• Número de orden de compra
• Nombre y dirección del proveedor
• Fecha del pedido y fecha de entrega requerida
• Términos de entrega y de pago
• Cantidad de artículos solicitados
• Número de catálogo
• Descripción
• Precio unitario y total
• Costo de envío, de manejo, de seguro y relacionados. Costo total de la
orden
• Firma autorizada
18
El original se envía al proveedor y las copias usualmente van al departamento de
contabilidad para ser registrados en la cuenta por pagar y otra copia para el
departamento de compras.
Contratación Estatal
La Ley 80 de 1993 compendia el Estatuto General de Contratación con el Estado y
otorga un tratamiento propio a los contratos que celebren las entidades estatales con
los particulares al cual se someten los contratos expresamente mencionados en el
Estatuto. Los demás, aun cuando sean celebrados por entidades estatales, se rigen
por las reglas previstas para los contratos privados.
Los principales contratos que existen en la contratación estatal son:
• Obra: dado por las entidades estatales para la construcción, mantenimiento,
instalación y, en general, para la realización de cualquier otro trabajo material
sobre bienes inmuebles, cualquiera que sea la modalidad de ejecución y pago.
• Consultoría: dado por las entidades estatales referidos a los estudios
necesarios para la ejecución de proyectos de inversión, estudios de
diagnóstico, prefactibilidad o factibilidad para programas o proyectos
específicos, así como a las asesorías técnicas de coordinación, control y
supervisión, interventoría, asesoría, gerencia de obra o de proyectos, dirección,
programación y la ejecución de diseños, planos, anteproyectos y proyectos.
• Prestación de Servicios: dado por las entidades estatales para desarrollar
actividades relacionadas con la administración o funcionamiento de la entidad.
Estos contratos sólo podrán celebrarse con personas naturales cuando dichas
actividades no puedan realizarse con personal de planta o requieran
conocimientos especializados.
• Concesión : dado por las entidades estatales con el objeto de otorgar a un
concesionario la prestación, operación, explotación, organización o gestión,
total o parcial, de un servicio público, o la construcción, explotación o
conservación total o parcial, de una obra o bien destinados al servicio o uso
público, así como todas aquellas actividades necesarias para la adecuada
prestación o funcionamiento de la obra o servicio por cuenta y riesgo del
19
concesionario y bajo la vigilancia y control de la entidad concedente, a cambio
de una remuneración.
Impuestos
La Retención en la fuente es una figura o mecanismo que busca recaudar
anticipadamente un impuesto. Mediante este sistema se asegura el recaudo de un
impuesto al momento de ocurrir el hecho generador. Pero existen algunos casos en
que la retención en la fuente no se debe practicar.
La retención en la fuente debe practicarla el comprador, es decir, quien hace el pago
(Agentes de retención) y en los siguientes casos no se debe efectuar:
No se practica retención en la fuente a la Nación, los Departamentos y sus
asociaciones, los Distritos, los Territorios Indígenas, los Municipios y las demás
entidades territoriales, las Corporaciones Autónomas Regionales y de Desarrollo
Sostenible, las Áreas Metropolitanas, las Asociaciones de Municipios, las
Superintendencias, las Unidades Administrativas Especiales, las Asociaciones de
Departamentos y las Federaciones de Municipios, los Resguardos2 y Cabildos
Indígenas, los establecimientos públicos y los demás establecimientos oficiales
descentralizados, siempre y cuando no se señalen en la ley como contribuyentes.
No se debe practicar retención en la fuente cando el vendedor del bien o prestador del
servicio es un autorretenedor, puesto que éste es el responsable de la retención y es
el mismo quien debe practicar la respectiva retención.
Impuesto a la renta y el Impuesto de industria y comercio, en el Impuesto a las ventas
también existe la figura de la Retención en la fuente. Esta figura se conoce
comúnmente como Reteiva.
La retención en la fuente por IVA consiste en que el comprador, al momento de causar
o pagar la compra, retiene al vendedor el 50% del valor del IVA.
2 Disponible en www.universia.net.co/index2.php?option=com_content&do_pdf=1&id=242
20 -11-2008 11:00 A.M.
20
La retención en la fuente por IVA se practica siempre y cuando el hecho u operación
económica supere la base mínima.
En Colombia son responsables del IVA tanto las personas naturales como jurídicas
que produzcan o vendan bienes o servicios excluidos, además los comerciantes y
quienes realicen actos similares a los de ellos, incluyendo a los importadores.
Cuando una persona natural es “Responsable del IVA”, esta tiene que definir si
actuara bajo la figura del “Régimen Simplificado” o bajo la figura del “Régimen
Común”.
Existen algunos agentes retenedores que lo son sin saberlo y que probablemente
están acumulando sanciones por no haber presentado sus declaraciones de retención
mensualmente, aún si haber practicado retenciones, de acuerdo con la Ley 1066 de
2006. A continuación presentamos algunas instrucciones básicas, con el ánimo de
orientar a algunos contribuyentes que pueden estar incumpliendo las normas vigentes.
No siempre la retención en la fuente es un anticipo del tributo. En algunas ocasiones
puede ser el impuesto a cargo del sujeto retenido. Ocurre con los tributos de
Gravamen a los Movimientos Financieros, Timbres y renta para no declarantes. En los
casos de Renta, IVA e ICA, el valor retenido al beneficiario del ingreso, lo podrá restar
del valor del impuesto a cargo en la respectiva declaración privada del tributo
correspondiente, excepto el caso de la retención que hace el régimen común al
régimen simplificado que se explicará adelante.
Las retenciones practicadas por tributos del orden nacional, se declaran y pagan
mensualmente, en un solo formulario por los agentes retenedores. Las retenciones
practicadas por los tributos del orden territorial, por ejemplo el ICA, se declaran y
pagan en cada jurisdicción municipal, por tratarse de un impuesto local.
La retención por IVA que le practica una persona natural responsable del régimen
común a otra persona natural responsable del régimen simplificado es teórica, por
cuanto no se descuenta del pago efectuado al beneficiario. Lo que se da aquí es un
mecanismo de control. En este caso, el IVA retenido se declara y paga junto con las
retenciones practicadas por los demás conceptos.
21
Facturación
La factura es un documento que refleja la entrega de un producto o la provisión de un
servicio, junto a la fecha de devengo, además de indicar la cantidad a pagar como
contraprestación.
En la factura se encuentran los datos del expedidor y del destinatario, el detalle de los
productos y servicios suministrados, los precios unitarios, los precios totales, los
descuentos y los impuestos.
Se la considera como el justificante fiscal de la entrega de un producto o de la
provisión de un servicio, que afecta al obligado tributario emisor (el vendedor) y al
obligado tributario receptor (el comprador). La factura3 correctamente cumplimentada
es el único justificante fiscal, que da al receptor el derecho de deducción del impuesto
(IVA).
En algunos países, la factura no tiene valor jurídico en un juicio a la hora de exigir el
pago de una deuda.
La facturación es quizás el punto de contacto con el cliente más amplio en una
empresa. Es el punto en el que el contacto con el cliente es más frecuente, aun que en
el de la venta. En el punto de facturación, el cliente que lleva crédito con una empresa,
debe de ser informado de sus posibilidades, por sus hábitos de consumo y sus hábitos
de paga. Esta información debe de ser aprovechada en forma amplia y extensiva.
Están obligados a expedir factura o documento equivalente por cada una de las
operaciones que realicen, todas las personas o entidades que tengan la calidad de
comerciantes, ejerzan profesiones liberales o presten servicios inherentes a éstas, o
enajenen bienes producto independientemente de su calidad de contribuyentes o no
contribuyentes de los impuestos administrados por la Unidad Administrativa Especial -
Dirección de Impuestos y Aduanas Nacionales.
3 Disponible en www.articulosinformativos.com/Orden_de_Compra-a862544.html
28- 10 – 2008 4:50 P.M
22
Las facturas pueden ser de tres tipos, entre las cuales están las:
• Ordinarias: documentan la operación comercial.
• Rectificativas: documentan correcciones de una o más facturas anteriores, o
bien devoluciones de productos, envases y embalajes o comisiones por
volumen.
• Recapitulativas: documentan agrupaciones de facturas de un período. Para
que esta factura tenga validez fiscal se han de anular las anteriores.
Además existen las siguientes variantes:
• Pro-forma: documenta una indicación de la forma exacta que tendrá la factura
tras el suministro. No tienen valor contable ni como justificante. Suele incluir la
fecha máxima de validez.
• Copia: documenta la operación para el emisor, con los mismos datos que el
original. Debe llevar la indicación de copia para permitir distinguirla del original.
• Duplicado: documenta la operación para el receptor, en caso de pérdida del
original. La expide el mismo emisor que expidió el original y tiene los mismos
datos que el original. Debe llevar la indicación de duplicado para permitir
distinguirla del original, especialmente para el caso de que reaparezca el
original.
Los empresarios o profesionales están obligados a expedir factura y copia de ésta por
las entregas de bienes y prestaciones de servicios que realicen en el desarrollo de su
actividad, incluidas las no sujetas y las sujetas pero exentas del impuesto. Esta
obligación incumbe asimismo a los empresarios o profesionales acogidos a los
regímenes especiales del impuesto sobre el valor agregado.
Aquellas en las que el destinatario sea un empresario o profesional que actúe como
tal, con independencia del régimen de tributación al que se encuentre acogido el
23
empresario o profesional que realice la operación, así como cualesquiera otras en las
que el destinatario así lo exija para el ejercicio de cualquier derecho de naturaleza
tributaria.
Proceso Facturación
Están obligados a expedir factura o documento equivalente por cada una de las
operaciones que realicen, todas las personas o entidades que tengan la calidad de
comerciantes, ejerzan profesiones liberales o presten servicios inherentes a éstas, o
enajenen bienes producto de la actividad agrícola o ganadera, independientemente de
su calidad de contribuyentes o no contribuyentes de los impuestos administrados por
la Dirección de Impuestos y Aduanas Nacionales.
Cuando se trate de factura cambiaria de compraventa, el documento llevará esta
denominación, entendiéndose cumplido así el requisito señalado en el literal a) del
artículo 617 del Estatuto Tributario.
Para efectos tributarios, la expedición de factura a que se refiere el artículo 615 del
Estatuto Tributario consiste en entregar el original de la misma, con el lleno de los
siguientes requisitos:
a) Estar denominada expresamente como factura de venta
b) Apellidos y nombres o razón social y NIT del vendedor o de quien presta
el servicio
c) Apellidos y nombres o razón social y NIT del adquirente de los bienes o
servicios, junto con la discriminación del IVA pagado
d) Llevar un número que corresponda a un sistema de numeración
consecutiva de facturas de venta
e) Fecha de su expedición.
f) Descripción específica o genérica de los artículos vendidos o servicios
prestados
g) Valor total de la operación
h) El nombre o razón social y el NIT del impresor de la factura
i) Indicar la calidad de retenedor del impuesto sobre las ventas
24
Al momento de la expedición de la factura los requisitos de los literales a), b), d) y h),
deberán estar previamente impresos a través de medios litográficos, tipográficos o de
técnicas industriales de carácter similar.
Cuando el contribuyente utilice un sistema de facturación por computador o máquinas
registradoras, con la impresión efectuada por tales medios se entienden cumplidos los
requisitos de impresión previa. El sistema de facturación deberá numerar en forma
consecutiva las facturas y se deberán proveer los medios necesarios para su
verificación y auditoría.
Elementos de Factura
La visualización de la factura es muy importante cuando se imprima, por tal razón los
elementos o atributos que debe contener la factura deben ser los más relevantes.
A continuación se detallará que elementos debe contener la factura.
• Logo de la empresa
• Nombre de la empresa
• Nit
• Dirección
• Teléfonos
• Fax
• Ciudad
• Número de la factura.
• Resolución de la DIAN
• Fecha de creación de la factura
• Nombre cliente o empresa
• Nit del cliente o empresa que se genera la factura
• Dirección cliente
• Teléfono Cliente
• Documento Fuente refiriéndose al número del contrato.
• Fecha de vencimiento de la facturación
• Código del producto o servicio
• Descripción
25
• Cantidad
• Valor unitario
• Valor Total
• Observaciones
• Subtotal
• IVA
• Total
• Menos Anticipo
• Neto
• Porcentaje IVA
• Porcentaje ICA
• Neto a pagar
• Sello y firma empresa generadora de la factura
• Firma y sello cliente
RÉGIMEN TRIBUTARIO
Respecto al Impuesto a las ventas existen dos responsables; el Régimen común y el
Régimen simplificado.
Se considera responsable del impuesto a las ventas toda Persona natural o Persona
jurídica que venda productos o preste servicios gravados con el IVA4.
Son responsables del Impuesto a las ventas pertenecientes al régimen común, todas las
personas jurídicas y aquellas personas naturales que no cumplan los requisitos para
pertenecer el Régimen simplificado. Toda Persona jurídica por el solo hecho de ser
jurídica pertenece al régimen común. Las personas naturales solo serán responsables
del régimen común si no cumplen todos o uno de los requisitos que la norma establece
para poder formar parte del Régimen simplificado.
4 Disponible en www.gerencie.com/retencion-en-la-fuente-por-iva-reteiva.html
03 – 09 -2008 6:30 A.M
26
Cuando el responsable del Régimen Simplificado deje de cumplir con alguno de los
requisitos señalados para pertenecer a este régimen, deberá de inmediato
inscribirse en el Régimen Común, mediante el diligenciamiento del formato RUT, y
cumplir con las obligaciones de dicho régimen, a partir del periodo siguiente, salvo
cuando celebre un contrato de venta de bienes y/o prestación de servicios gravados por
un valor individual superior a $63.660.000, deberá inscribirse anticipadamente en el
Régimen Común.
Cuando una persona natural en un periodo determinado deje de cumplir uno o varios de
los requisitos que le permiten estar en el Régimen simplificado, deberá actualizar el Rut
en el periodo siguiente y pasarse o inscribirse en el régimen común. Recordemos que
en el Impuesto a las ventas, el periodo es de dos meses, por lo que si supera los topes
en el periodo 4, en el periodo 5 ya debe ser responsable del régimen común y cumplir
con todas sus obligaciones.
Todo comerciante debe llevar Contabilidad de acuerdo a los Principios de contabilidad
generalmente aceptados, y esto supone inscribirse en el Registro mercantil, donde
también deberá inscribir los Libros de contabilidad o Libros de comercio.
Toda persona perteneciente al régimen común debe inscribirse en el Rut o actualizarlo
si ha estado inscrito antes como Régimen simplificado.
Todo responsable del régimen común está en la obligación de presentar
bimensualmente la respectiva declaración de IVA en los plazos que el gobierno señale.
Esta declaración se debe presentar así durante el periodo a declarar no se hayan
realizado operaciones económicas.
La declaración de IVA no es la única declaración que se debe presentar, puesto que
existen otras como al de Retención en la fuente y la del Impuesto de renta.
Toda Persona jurídica es Agente de retención y como tal debe declarar, y a partir de la
ley 1066 de 2006, todo agente de retención debe presentar al respectiva declaración así
se en cero. Adicionalmente, la declaración se debe presentar con pago, de lo contrario
se considera como no presentada.
27
Solo las juntas de acción comunal no están obligadas a presentar la declaración de
retención si en el respectivo mes no han practicado retenciones.
2.2 MARCO LEGAL O NORMATIVO
El proyecto “Automatización de Facturación” se diseñará bajo Open Source, software
que se comercializa de forma libre y gratuitamente.
Este tipo de software utiliza un software de código abierto con permisos específicos
para ser distribuidos en cualquier ámbito comercial, en la cuales se encuentra adecuado
a cualquier necesidad particular. Open Source está agregado a la licencia GPL
logrando hacer copia de los programas, inclusivamente pagar por aquel software, así
también como modificar el código fuente.
La normativa que preside el diseño de automatización de facturación esta
proporcionada por Oracle Express Edition en conjunto a la aplicación Oracle
Application Express totalmente gratuitos, dichos software libres están sujetos a una
exclusiva e intransferible licencia que solo se puede utilizar con fines de desarrollar
aplicaciones independientes de contratos u otros términos. Este tipo de contrato no
implica ningún tipo de derecho para los programas basados en Oracle.
Por otra parte El proyecto “Automatización de Facturación” precede de cierta normas y
artículos que si no son cumplidos no se podrá legalizar y realizar el proceso de
facturación, la cual componen los siguientes estatutos.
Una personas naturales, responsables del IVA régimen común, por operaciones con el
régimen simplificado. Literal e) artículo 437 E.T. y numeral 4 Artículo 437-2 E.T.
Las personas naturales pertenecientes al régimen común del impuesto sobre las ventas,
por el impuesto causado en la compra o adquisición de los bienes y servicios gravados
relacionados en el artículo 468-1del Estatuto Tributario, cuando éstos sean enajenados
o prestados por personas naturales no comerciantes que no se hayan inscrito en el
régimen común del impuesto sobre las ventas. Literal f) Artículo 437 E.T.
28
Las personas naturales comerciantes, por Impuesto de Timbre, por los instrumentos
públicos y documentos privados, incluidos los títulos valores, cuando concurran las
condiciones establecidas en el artículo 519 E.T.
El régimen común sin importar si está o no obligado a llevar Contabilidad5, debe expedir
factura con los requisitos establecidos en el artículo 617 del Estatuto tributario:
Articulo 617. Requisitos de la factura de venta. Para efectos tributarios, la expedición de
factura a que se refiere el artículo 615 consiste en entregar el original de la misma.
La ley 1111 de 2006, estableció que un Agente de retención puede presentar la
declaración de retención sin pago, siempre y cuando tenga un saldo a favor el cual sea
susceptible de compensación, y que el saldo a favor se hubiere generado antes de
presentar la respectiva declaración de retención. Adicionalmente, el contribuyente debe
solicitar tal compensación dentro de los 6 meses siguientes a la presentación de la
declaración. Si no lo hace dentro de ese plazo, la declaración se considerara como no
presentada.
El Ministerio de Comercio Industria y Turismo expidió el decreto 4270 de noviembre 11
de 2008 (que entra en vigencia desde esa misma fecha) a través del cual se amplía
hasta febrero 28 de 2009 la utilización de las denominadas “Facturas Cambiarias de
Compraventa” que fueron el título valor que solo se podía expedir hasta oct.17 de
2008 cuando entró en vigencia la ley 1231 de julio 17 de 2008.
De acuerdo con el parágrafo del artículo 1 de la ley 1231, el Gobierno Nacional
quedaba facultado para reglamentar la parte referente a la Factura Electrónica y sus
características para que operase como Título Valor, razón por la cual existe hoy día un
proyecto de decreto que contempla dicha reglamentación.
La ley 1231 dispuso que a partir de octubre 17 de 2008 los Títulos Valores que antes
se denominaron “Facturas Cambiarias de Compraventa” (regulados en los art.772 a
774 y 777 a 779 del Código de Comercio), tendrían que cambiar su denominación a
5 Disponible en www.cijuf.org.co/documentos/agentesretenedores 16-11-2008
6;30 P.M
29
“Facturas de Venta” pues se unificarían con la misma factura que se expide para fines
tributarios (ver artículo 774 del Código de Comercio y el 617 del Estatuto Tributario).
Tienen además que cumplir con todos los otros requisitos de forma que se exigen en
ese mismo artículo 617 del ET.
Como consecuencia de este cambio, la DIAN en su circular 96 de octubre 16 de 2008
había indicado que quienes en octubre 17 de 2008 tuvieran existencias de “Facturas
Cambiarias de Compraventa” impresas en papel, tendrían que anularlas, informar de
tal anulación a la entidad, y entrar a solicitar una nueva autorización de numeración de
facturación para las nuevas facturas que mandasen a imprimir con la denominación
que ahora ordenaba la ley.
La Ley 80 de 1993, Ley 1150 de 2007, el Decreto 066 de 2008 y demás normas
reglamentarios, compendian el Estatuto General de Contratación con el Estado y
otorgan un tratamiento propio a los contratos que celebren las entidades estatales con
los particulares al cual se someten los contratos expresamente mencionados en
dichos Estatutos.
30
3. METODOLOGÍA 3.1 ENFOQUE DE LA INVESTIGACIÓN El enfoque de investigación del proyecto es Empírico-Analítico con esto se analiza su
pretensión de explicación de los hechos humanos, su objetividad, su validez y sus
límites.
3.2 LÍNEA DE INVESTIGACIÓN DE USB/ SUB-LÍNEA DE FACULTAD/ CAMPO TEMÁTICO DEL PROGRAMA La línea de investigación del proyecto son las tecnologías actuales ya que pretende
desarrollar e implementar un sistema de información que mejore el tiempo de
respuesta de una empresa, la sub-línea de investigación son las base de datos esta
permitirá generar la facturación en un menor tiempo.
3.3 TÉCNICAS DE RECOLECCIÓN DE INFORMACIÓN Las técnicas de recolección de información a utilizar en este proyecto son las
encuestas, que permite saber cuales son las necesidades que los usuarios finales
necesitan, con esto se logrará un mejor tiempo de respuesta en la información que
necesiten en un determinado tiempo.
Se realizará encuestas a cada uno de los usuarios de la empresa Software Builders
Ltda. que harán parte del sistema de automatizado de facturación, esto permitirá
establecer el criterio a utilizara en el proceso de facturación.
31
3.4 HIPÓTESIS Con el proceso de automatización para la facturación en la empresa Software Builders
Ltda. se reducirá la pérdida de información y los tiempos de respuesta a los usuario
disminuirá.
3.5 VARIABLES
3.5.1 Variables Independientes
• Velocidad del procesamiento
• Tiempo de Respuesta
3.5.2 Variables Dependientes
• Proceso de Automatización
32
4. DESARROLLO INGENIERIL El desarrollo ingenieril de este proyecto comienza con la selección de la metodología
a utilizar. Las metodologías propuestas entre muchas fueron tres de las cuales se
escogió una, con la que se iba a seguir para desarrollar el aplicativo. Las tres
metodologías son las siguientes:
Metodología CRM: Básicamente, el CRM es una estrategia que permite a las
empresas identificar, atraer y retener a sus clientes, además de ayudarles a
incrementar la satisfacción de éstos y a optimizar así la rentabilidad de sus
negocios. Hablamos, por tanto, de CRM como estrategia, lo que implica no sólo
disponer del software adecuado que permita gestionar las relaciones con los
clientes, sino que además, supone un cambio en los procesos de la empresa y la
involucración de todos los empleados de la misma para que esta estrategia tenga
éxito.
El CRM es una importante estrategia de negocio, tanto para empresas de e-
business como para compañías tradicionales, a la hora de hacer frente a un
mercado cada vez más competitivo y exigente.
Metodología Metrica 3: Ofrece a las organizaciones un instrumento útil para la
sistematización de las actividades de un ciclo de vida del software.
1. Estudio de viabilidad del sistema.
2. Análisis del sistema de información.
3. Diseño del sistema de información.
4. Construcción del sistema de información.
5. Implantación y aceptación del sistema.
Una vez realizada una exhaustiva investigación de las metodologías existentes en el
mercado, se decidió realizar el aplicativo siguiendo la metodología Oracle Case por su
contenido.
33
ESTRATEGIA
ANÁLISIS
DISEÑO
ESTRATEGIA ESTRATEGIA
TRANSICIÓN
PRODUCCIÓN
1. Definición y análisis de los requerimientos del usuario.
2. Diseño del sistema y de la base de datos.
3. Implantación y prueba de módulos.
4. Integración y prueba del sistema.
5. Operación y mantenimiento.
Además contempla todo el proceso de vida de un software como se presentara a
continuación en donde se explica cada una de ellas y la forma como fue utilizada en el
desarrollo del aplicativo.
Metodología Oracle case: es la mejor base para el proceso de análisis y
desarrollo de software de tipo descendiente en un ciclo de vida de un sistema
que se compone de las siguientes etapas:
Figura 1. Ciclo de vida de un Software.
34
DIRECCIÓN CORPORATIVA
FUNCIONES DE LA
ORGANIZACIÓ
REQUERIMIENTOS DE
INFORMACIÓN
ANÁLISIS / MODELACIÓN
TECNOLOGÍA DISPONIBLES
NECESIDADES DE
SISTEMAS
SISTEMAS EXISTENTES
DEFINICIÓN DE LA
ARQUITECTURA
En la figura anterior se encuentra el ciclo de vida de software. Es un proceso que nos
da los mejores resultados en el desarrollo de un aplicativo. Cada fase de esta
metodología tiene una importancia y para lograr ser exitosos hay que llevarla a cabo
en la forma en que ilustra en la figura.
A continuación se explica fase por fase.
Fase 1. Estrategia
Esta es una de las etapas más importantes, tiene como objetivo lograr un
entendimiento claro de las necesidades de la organización y del ambiente en que
opera el sistema a implementar.
Con el fin de tener una visión desde el punto de vista del usuario final que utilizara el
aplicativo a desarrollar, se analiza las diferentes funciones y necesidades requeridas
por el área afectada. Durante esta etapa se realiza una serie de entrevistas
correspondientes. Así a partir de la información obtenida se realiza el primer modelo
de los requerimientos del sistema, posteriormente para la definición de una primera
versión de la arquitectura del sistema.
La fase de estrategia se puede plasmar en la siguiente figura donde se expresa de una
forma más amigable.
Figura 2. Ciclo de vida de un Software – Fase Estrategia.
35
Los resultados de esta etapa son, un conjunto de modelos en la empresa, un conjunto
de recomendaciones, y un plan acordado de los sistemas de factura en la compañía.
Dirección corporativa: en la empresa Software Builders Ltda. está compuesta por los
siguientes departamentos:
1. Contabilidad
2. Administrativa
3. Comercial
4. Gerencia
5. Tecnología
Cada uno de los departamentos mencionados anteriormente están involucrados en el
proceso de facturación.
Funciones de la Organización: la empresa Software Builders Ltda. realiza la función de
realizar consultoría, soporte y dar solución a la medida desarrollando aplicativos en
empresas del sector público y privado.
Requerimientos de información: Dar solución en primera medida al manejo de la
información puesto que con el paso de los años la compañía ha venido evolucionando
con el fin se posicionarse en la mejores compañías en desarrollo de software. Y
facilitar la generación de la facturas, controlando los pagos pendientes por los clientes.
Tecnologías disponibles: Uno de los requerimientos de la empresa en dar solución con
una tecnología de punta y que sea open source. Para lo cual se realizo una
investigación de los motores de base de datos. Como comparación se escogió para
seleccionar tres de ellos que son fuertes en este mercado. Los siguientes motores se
tuvieron en cuenta.
36
Mysql : es un SGBA(Sistema de gestión de base datos), multiusuario, relacional y
multihilo, desde comienzos de este año Sun Microsystem desarrolla MySQL como
Open Source en un diseño de licenciamiento dual.
1. El principal objetivo de MySQL es velocidad y robustez.
2. Resiste gran cantidad de tipos de datos para las columnas
3. Portabilidad entre sistemas, trabaja en diferentes plataformas y sistemas
operativos.
4. Posee un gran desarrollo multiproceso, debido a su implementación multihilo.
5. Fácil manejo en el sistema de contraseñas (passwords) y gestión de usuarios,
con un muy buen nivel de seguridad en los datos.
6. El servidor soporta mensajes de error en distintas lenguas.
7. Velocidad al realizar las operaciones, lo que le hace uno de los gestores con
mejor rendimiento.
PostgreSQL: es un servidor de base de datos relacional orientada a objetos de
software libre, publicado bajo la licencia BSD.
Como muchos otros proyectos Open Source, el desarrollo de PostgreSQL no es
manejado por una sola compañía sino que es dirigido por una comunidad de
desarrolladores y organizaciones comerciales las cuales trabajan en su desarrollo.
Dicha comunidad es denominada el PGDG.
Características:
1. Mejorar soporte.
2. Ahorro Considerables en costos de operación.
3. Estabilidad y confiabilidad.
4. Extensible.
5. Multiplataforma.
6. Diseñado para ambientes de alto volumen.
En el desarrollo del aplicativo, se escogió el motor de base de datos Oracle
Application Express. Su selección fue acorde a los beneficios que nos ofrece dicha
herramienta con respecto a las otras.
37
1. Drástica reducción de los costos. 2. Disponibilidad inmediata de la información.
3. Intercambio instantáneo de los resultados.
4. Rapidez en la toma de decisiones.
5. Actualización constante de la Base de Datos.
6. Mayor eficiencia.
7. Más y mejores servicios a los clientes.
8. Incremento en la eficiencia de la fuerza de venta.
9. Dominio del mercado.
10. Obtener clientes casuales u ocasionales.
11. Disminuir el tiempo de respuesta.
12. Ganarle clientes a la competencia.
13. Opera de una forma continua.
14. Tiene orientación hacia el futuro.
15. Analizar las ventas. Otra ventaja o valor agregado de esta herramienta es su tiempo que lleva en mercado
la cual es mínima si la comparamos con las otras dos, motores de base de datos.
Oracle siendo una compañía tan reconocida en todo el mundo por su eficiente motor
de base de datos y robustez decidió lanzar Oracle Express edition con licencia libre
para pequeñas empresas que se encuentren en proceso de crecimiento.
Oracle e-Pyme tiene como objetivos ofrecer soluciones tecnológicas simples y fáciles
a una parte estratégica en las economías Latinoamericanas. En el 2005 Oracle en el
OpenWorld presentó la campaña “PYMES”, esta campaña está dirigida a integrar los
productos y servicios que más se ajustan a las necesidades de las empresas,
ayudando a que sean más dinámicas en el sector donde se encuentre y que el
presupuesto sea el mínimo.
“A medida que las empresas medianas ganan clientes y tienen más
empleados, más proveedores, más líneas de productos, un mayor
número de transacciones y, también, más competencia, encuentran un
número creciente de presiones, a las que deben hacer frente con
recursos limitados. Los sistemas y los procesos informáticos se
38
complejizan y esto muchas veces termina produciendo información
incorrecta, afectando la productividad y disminuyendo las ganancias6”.
Oracle Express Edition: es una base de datos creada sobre código de Oracle Database 10g Release2 que puede desarrollarse, implementar y distribuirse sin
ningún costo. Es una excelente base de datos para:
1. Desarrolladores que trabajan en Java, .Net, XML, PHP y herramientas de
código abierto.
2. Administradores de base de datos una base de datos inicial y sin ningún costo
para la implementación y capacitación.
3. Vendedores de software independientes y proveedores de hardware que
desean de una base de datos inicial sin ningún costo.
4. Establecimientos educativos, estudiantes y personas independientes que
necesitan de una base de datos inicial sin ningún costo.
Teniendo en cuanta el motor de base de datos a utilizar en el desarrollo del
aplicativo. Se escogió la herramienta Oracle Application Express como
complemento de las interfaces.
Oracle Application Express brindar tres herramientas principales:
Application Builder: Crea base de datos dinámica impulsada por las
aplicaciones web.
SQL Workshop: Navega por la base de datos de objetos.
Utilidades: Permite que los datos sean cargados y descargado a través de
archivos planos y hojas de cálculo.
Oracle Application Express es una herramienta productiva para construir
aplicaciones que informen sobre la base de datos. Los informes suelen ser
hipertexto relacionado con otros informes que permite a los usuarios navegar a
6 Disponible en: http://mundo-contact.com/soluciones_detalle.php?recordID=432
20-octubre-2008 5:00 P.M
39
través de la base de datos de datos de la misma manera que navegar por sitios
web. Las columnas en los informes pueden ser fácilmente vinculado a otros
informes gráficos y formularios de entrada de datos. Una extensa cartografía del
motor permite consultas SQL que estan representadas gráficamente y que permite
que los datos se comuniquen de manera más eficaz. APEX también es muy hábil
en la edición de la base de datos de datos y apoya un gran número de controles de
forma declarativa incluido los grupos de radio, casillas de verificación, seleccione
las listas, lanzaderas, editores de texto, fecha y recolectores.
Para culminar la etapa de tecnología de la base de datos, se realizo el siguiente
cuadro comparativo donde se plasma las ventajas y desventajas de los tres
motores de base de datos mencionados anteriormente y se ilustra en la Tabla 1.
En lo correspondiente a requisitos se realizo un modelo ilustrado en la figura # que
permita distinguir en que sistema operativo puede ser instalado para cuando el
usuario final acceder al aplicativo sin ningún inconveniente.
Se menciona además en la arquitectura que hay un servidor de Aplicaciones y por
último se encuentra el servidor de base de datos donde se menciona en que
sistema operativo desea instalarlo.
40
Tabla 1. Motores Base de Datos.
MOTORES DE BASE
DE DATOS
VENTAJA DESVENTAJA INTEGRIDAD
REFERENCIAL TABLA
TEMPORAL VISTA
MATERIALIZADA TRANSANCCIONES
Mejor soporte que los
proveedores comerciales,
ahorro considerable en costos
de operación. Diseñado para
ambientes de alto volumen.
Consume gran
cantidad de memoria.
Disponibilidad en gran
cantidad de plataformas y
sistemas, conectividad,
seguridad.
No se pueden acceder
simultáneamente
múltiples usuarios.
Rendimiento, disponibilidad y
seguridad. Permite crear
aplicaciones web robustas
basadas en la base de datos
de Oracle.
41
ANÁLISIS DE FUNCIONES
ANÁLISIS DE DOCUMENTOS
ANÁLISIS DE DATOS
ENTREVISTAS
ANÁLISIS MODELACIÓN
DEFINICIÓN DE RESTRICCIONES
MODELO ENTIDAD/RELACIÓN
Fase 2. Análisis La etapa de análisis toma y verifica los descubrimientos de la etapa de estrategia,
posibilitando un fundamento sólido para el diseño, con participación de los
responsables de la operación de las funciones que serán automatizadas. Figura 3. Ciclo de vida de un Software – Fase Análisis.
Así, en esta etapa y como se ilustra en la figura 3, a partir de los modelos de la
organización obtenidos en la anterior y del producto del análisis de ésta, se genera el
modelado del sistema. Los modelos básicos de esta etapa son:
El de entidad relación, que modela mediante relaciones lógicas todos los datos
involucrados en el sistema, de tal manera que cualquier tipo de explotación (consulta o
modificación) sean posibles.
El funcional, que modela las diferentes servicios que ofrecerá el sistema mediante una
organización y clasificación de las diversas funciones y sub-funciones que fueron
identificadas en el análisis.
Como resultados de esta etapa, además del modelo de entidad relación y el funcional,
se definen las restricciones que tendrán el sistema y la estrategia que se seguirá en la
etapa de transición.
42
Figura 4. Modelo Entidad Relación – versión 1.
HERRAMIENTA# HERRAMIENTA_ID# HERRAMIENTA_ID* ACTIVO* ACTIVO* PORCENTAJE* PORCENTAJE* USUARIO_CREADOR* USUARIO_CREADOR* FECHA_CREACION* FECHA_CREACIONo USUARIO_MODIFICADORo USUARIO_MODIFICAo FECHA_MODIFICACIONo FECHA_MODIFICACIO
ASIENTO CONTABLE# ASIENTO_CONTABLE_ID# ASIENTO_CONTABLE_ID* CODIGO_ASIENTO_CONTABLE* CODIGO_ASIENTO_C* NOMBRE_ASIENTO_CONTABLE* NOMBRE_ASIENTO_C* CREDITO* CREDITO* DEBITO* DEBITO* OPERACION* OPERACION* USUARIO_CREADOR* USUARIO_CREADOR* FECHA_CREACION* FECHA_CREACIONo USUARIO_MODIFICADORo USUARIO_MODIFICADORo FECHA_MODIFICACIONo FECHA_MODIFICACION
FORMA PAGO# FORMA_PAGO_ID# FORMA_PAGO_ID* DESCRIPCION_PAGO* DESCRIPCION_PA* NUMERO_PAGO* NUMERO_PAGO* USUARIO_CREADOR* USUARIO_CREAD* FECHA_CREACION* FECHA_CREACIONo USUARIO_MODIFICADORo USUARIO_MOo FECHA_MODIFICACIONo FECHA_MODIF
DETALLE PAGO# DETALLE_PAGO_ID# DETALLE_PAGO_IDo VALOR_PAGOo VALOR_PAGOo USUARIO_CREADORo USUARIO_CREADORo FECHA_CREACIONo FECHA_CREACIONo USUARIO_MODIFICADORo USUARIO_MODIFICADOo FECHA_MODIFICACIONo FECHA_MODIFICACION
DETALLE FACTURA# DETALLE_FACTURA_ID# DETALLE_FACTURA_ID* DESCRIPCION* DESCRIPCION* CANTIDAD* CANTIDADo ANTICIPOo ANTICIPOo VALOR_IVAo VALOR_IVA* VALOR_UNITARIO* VALOR_UNITARIO* VALOR_TOTAL* VALOR_TOTAL* USUARIO_CREADOR* USUARIO_CREADOR* FECHA_CREACION* FECHA_CREACION...
DETALLE CONTABLE# DETALLE_CONTABLE_ID# DETALLE_CONTAB* VALOR_CREDITO* VALOR_CREDITO* VALOR_DEBITO* VALOR_DEBITO* USUARIO_CREADOR* USUARIO_CREADOR* FECHA_CREACION* FECHA_CREACIONo USUARIO_MODIFICADORo USUARIO_MODIFIo FECHA_MODIFICACIONo FECHA_MODIFICAC
FACTURA# FACTURA_ID# FACTURA_ID* FECHA_FACTURA* FECHA_FACTURA* DOCUMENTO_FUENTE* DOCUMENTO_FUENTE* ESTADO* ESTADO* FECHA_VENCIMEINTO* FECHA_VENCIMEINTOo PORCENTAJE_IVAo PORCENTAJE_IVAo PORCENTAJE_ICAo PORCENTAJE_ICAo PORCENTAJE_RETENCION_IVAo PORCENTAJE_RETENCION_IVAo PORCENTAJE_RENTAo PORCENTAJE_RENTAo RETENCION_IVAo RETENCION_IVAo RETENCION_ICAo RETENCION_ICAo RETENCION_RENTAo RETENCION_RENTAo VALOR_IVAo VALOR_IVAo VALOR_ANTICIPADOo VALOR_ANTICIPADO* VALOR_BRUTO* VALOR_BRUTO* VALOR_BRUTO_A_PAGAR* VALOR_BRUTO_A_PAGAR* SUBTOTAL* SUBTOTAL* VALOR_TOTAL* VALOR_TOTAL* OBSERVACIONES* OBSERVACIONES* USUARIO_CREADOR* USUARIO_CREADOR* FECHA_CREACION* FECHA_CREACION...
PAGO# PAGO_ID# PAGO_ID* FECHA_PAGO* FECHA_PAGO* TOTAL_PAGO* TOTAL_PAGO* USUARIO_CREADOR* USUARIO_CREAD* FECHA_CREACION* FECHA_CREACIONo USUARIO_MODIFICADORo USUARIO_MOo FECHA_MODIFICACIONo FECHA_MODIF
CIUDAD# CIUDAD_ID# CIUDAD_ID* NOMBRE_CIUDAD* NOMBRE_CIUDADo DEPARTAMENTOo DEPARTAMENTOo MUNICIPIOo MUNICIPIO* USUARIO_CREADOR* USUARIO_CREAD* FECHA_CREACION* FECHA_CREACIONo USUARIO_MODIFICADORo USUARIO_MOo FECHA_MODIFICACIONo FECHA_MODIF PAIS
# PAIS_ID# PAIS_ID* NOMBRE_PAIS* NOMBRE_PAISo CODIGO_PAISo CODIGO_PAISo INDICATIVO_PAISo INDICATIVO_PAISo GENTILICIOo GENTILICIO* USUARIO_CREADOR* USUARIO_CREADO* FECHA_CREACION* FECHA_CREACIONo USUARIO_MODIFICADORo USUARIO_MODo FECHA_MODIFICACIONo FECHA_MODIFIC
CONCEPTO CONTABLE# CONCEPTO_CONTABLE_ID# CONCEPTO_CONTABLE_ID* CONCPETO* CONCPETO* ACTIVO* ACTIVOo PORCENTAJEo PORCENTAJEo RETENCION_RENTAo RETENCION_RENTA* USUARIO_CREADOR* USUARIO_CREADOR* FECHA_CREACION* FECHA_CREACIONo USUARIO_MODIFICACIONo USUARIO_MODIFICACIONo FECHA_MODIFICACIONo FECHA_MODIFICACION
CLIENTE# CLIENTE_ID# CLIENTE_ID* NOMBRE_CLIENTE* NOMBRE_CLIENTE* RAZON_SOCIAL* RAZON_SOCIALo NITo NITo VERIFICACION_NITo VERIFICACION_NIT* DIRECCION* DIRECCION* TELEFONO_CLIENTE* TELEFONO_CLIENTE* CONTACTO_CLIENTE* CONTACTO_CLIENTE* TELEFONO_CONTACTO_NOMBRE_CLIENTE* TELEFONO_CONTACTO_NOMBRE_CLIENTEo FAX_CONTACTO_CLIENTEo FAX_CONTACTO_CLIENTEo CORREO_CONTACTO_CLIENTEo CORREO_CONTACTO_CLIENTE* CONTACTO_COBRO* CONTACTO_COBROo TELEFONO_CONTACTO_COBROo TELEFONO_CONTACTO_COBROo CORREO_CONTACTO_COBROo CORREO_CONTACTO_COBROo FAX_CONTACTO_COBROo FAX_CONTACTO_COBROo RETENEDOR_IVAo RETENEDOR_IVAo RETENEDOR_ICAo RETENEDOR_ICAo RETENEDOR_RENTAo RETENEDOR_RENTAo PORCENTAJE_RETENCION_IVAo PORCENTAJE_RETENCION_IVA* USUARIO_CREADOR* USUARIO_CREADOR...
CONTRATO# CONTRATO_ID# CONTRATO_ID* NUMERO_CONTRATO* NUMERO_CONTRATO* OBJETO_CONTRATO* OBJETO_CONTRATO* ACTIVO* ACTIVO* DURACION_MESES* DURACION_MESES* FECHA_INICIO* FECHA_INICIOo FECHA_FINALIZACIONo FECHA_FINALIZACION* VALOR_TOTAL* VALOR_TOTAL* USUARIO_CREADOR* USUARIO_CREADOR* FECHA_CREACION* FECHA_CREACION...
PRODUCTO SERVICIO# PRODUCTO_ID# PRODUCTO_IDo NOMBRE_PRODUCTOo NOMBRE_PRODUCTOo DESCRIPCIONo DESCRIPCIONo PORCENTAJE_IVAo PORCENTAJE_IVAo PORCENTAJE_RETENCION_VENTAo PORCENTAJE_RETENCION_VENTAo VALOR_REALo VALOR_REALo VALOR_VENTAo VALOR_VENTAo USUARIO_CREADORo USUARIO_CREADORo FECHA_CREACIONo FECHA_CREACIONo USUARIO_MODIFICADORo USUARIO_MODIFICADORo FECHA_MODIFICACIONo FECHA_MODIFICACION
VALOR DEFINICION# VALOR_DEFINICION_ID# VALOR_DEFINICION_ID* VALOR_DEFINICION* VALOR_DEFINICION* DESCRIPCION* DESCRIPCION* ACTIVO* ACTIVO* USUARIO_CREADOR* USUARIO_CREADOR* FECHA_CREACION* FECHA_CREACIONo USUARIO_MODIFICADORo USUARIO_MODIFICADORo FECHA_MODIFICACIONo FECHA_MODIFICACION
TIPO_DEFINICION# TIPO_DEFINICION_ID# TIPO_DEFINICION_ID* DESCRIPCION* DESCRIPCION* CLASE_DEFINICION* CLASE_DEFINICION* ACTIVO* ACTIVO* USUARIO_CREADOR* USUARIO_CREADOR* FECHA_CREACION* FECHA_CREACIONo USUARIO_MODIFICADORo USUARIO_MODIFICAo FECHA_MODIFICACIONo FECHA_MODIFICACIO
PERSONA# PERSONA_ID# PERSONA_ID* CODIGO_PERSONA* CODIGO_PERSONA* NOMBRE_PERSONA* NOMBRE_PERSONA* NUMERO_DOCUMENTO* NUMERO_DOCUMENTO* GENERO* GENERO* DIRECCION* DIRECCION* TELEFONO* TELEFONO* DIRECCION_CORREO* DIRECCION_CORREO* USUARIO_CREADOR* USUARIO_CREADOR* FECHA_CREACION* FECHA_CREACIONo USUARIO_MODIFICADORo USUARIO_MODIFICADORo FECHA_MODIFICACIONo FECHA_MODIFICACION
clasificado por
sector de
definido por
tipo de retención de
definido para
tipo de
transaccion de
parte de
relacionada en
implementación de
clasificado por
categoría de
clasificado por
tipo de producto de
identificado por
identidad de
cobro de
facturada en
Parte de
Compuesto de
contabilización de
compuesta de
realizado por
responsable de
expedida en
origen de
contabilización decompuesta de
parte de
compuesta de
relacion de
cancelada en
parte decompuesta de
relacionado con
facturado en
originado po
calculado para
elaborado por
facturador de
categorizada por
cargo de
parte de
compuesto de
generado para
facturado en
cobro deorigen de
generado paraparte de
firmado en
ubicacion de
ubicado en
residencia de parte de
compuesta de
43
Una vez realizada la etapa 1. Estrategia donde uno organiza las ideas y propone
soluciones, se recopila toda la información y se plantea un diseño de bases de datos
que supla las necesidades del usuario final o requerimientos propuestos por la
empresa.
Como se ilustra en la figura 4 se realizo el modelo entidad / relación donde quedo
plasmado todas las entidades y departamentos que componen la empresa Software
builders Ltda.
El siguiente modelo son casos de uso donde cada usuario se encuentra con un rol o
una tarea específica. En ellos podremos encontrar una breve descripción de lo que
representa cada caso en la factura como se ilustra en la figura 5,6,7 y 8..
Y por último el modelo de funciones el cual se realizo tres versiones, el objetivo de
realizar este modelo es aclarar la navegación o las tablas importantes que van hacer
pues el papel de papas y las tablas o entidades menos importantes serán la hijas, esta
etapa ayuda al momento de la construcción. Las tres versiones que se colocaron se
pueden ilustrar en la figura 9,10 y 11.
44
Figura 5. Caso de Uso Facturación
45
Tabla 2. Caso de Uso de Facturación
Aplicación: SIFAC - FACTURACIÓN
Cliente: SOFTWARE BUILDERS LT.D.A.
Caso de Uso ID: 1
Caso de Uso Nombre: Proceso de Facturación
Creado Por: VLADIMIR ORTIZ
JULIO ROMANI
Actualizado Por:
Fecha Creación: 12/09/2008 Fecha Actualización:
Actores:
Usuario Administrador,
Usuario Comercial,
Usuario de Gerencia,
Usuario de Contabilidad,
Usuario Administrativo
Descripción:
El Usuario Administrativo ingresa al sistema, la información
de contratos y/o ordenes de compras acordadas con los
Clientes. Por solicitud del responsable de cada contrato, el
Usuario Administrativo ingresa la información de los
productos entregados o servicios prestados en un lapso de
tiempo a un cliente determinado. En el ingreso de los
productos, el sistema trae la información de precios de lista y
permite su modificación o el ingreso de descuentos. Una vez
ingresada y validada esta información se genera la Factura
correspondiente, asignando un consecutivo ó número de
factura. Dicha factura es impresa y entregada al Cliente. Si
hay problemas con la información registrada en la factura,
una vez esta es impresa, el sistema permitirá su anulación.
46
El Usuario Administrativo registra los pagos u abonos
realizados por los Clientes a las facturas. El Usuario
Comercial podrá ingresar al sistema para consultar las
ventas realizadas por mes, por producto o por Cliente en un
periodo de tiempo dado. El Usuario de Gerencia podrá
consultar a través del sistema las estadísticas de ventas y de
pagos realizados por mes, productos y clientes en un periodo
de tiempo dado.
Evento:
1. El Usuario Facturador ingresa la información de cada
contrato y/o orden de compra relacionando el
número, el Cliente y el periodo de vigencia.
2. El Usuario Administrativo ingresa los datos de la
factura, tales como, fecha, información del cliente,
contrato relacionado y observaciones.
3. Luego como detalle de la factura ingresa uno a uno
los Productos y/o Servicios, con su cantidad y valor
unitario.
4. El sistema calcula valores totales e impuestos
asociados con los productos y/o servicios o asociados
con el Cliente.
5. El Usuario Administrativo valida la información
ingresada y genera la factura impresa.
6. Si la factura y su información no es correcta o no fue
impresa adecuadamente, el Usuario Administrativo
podrá marcar la factura como Anulada, de lo contrario
la factura deberá ser marcada como impresa.
7. El Usuario Administrativo ingresa a través del sistema
los pagos parciales o totales de las facturas,
realizados por los Clientes.
8. El Usuario Comercial ingresa al sistema y podrá
47
generar listados o gráficos de las ventas por mes,
cliente, producto o servicio.
9. El Usuario de Gerencia genera listados o gráficos
estadísticos de las ventas y/o pagos realizados a
través del sistema de facturación.
Precondiciones:
Creación de Perfiles y de Usuarios
Creación de Productos y/o Servicios
Creación de Clientes
Definición de Impuestos Asociados
Poscondiciones: Generación de Interface Contable
Flujo Alternativo:
Excepciones: Punto 1 y 2. Si la factura ya fue impresa, el sistema no
permitirá modificar su contenido, mostrando al usuario un
mensaje de error.
Prioridad: Media
Frecuencia de Uso: Mensual
Reglas de Negocio: • Toda factura debe estar relacionada con un cliente y
contrato.
• Una vez impresas las facturas no pueden ser
modificadas.
• La numeración de las facturas debe ser estrictamente
consecutiva. No se debe permitir la omisión o duplicidad
de los números.
Requerimientos
Especiales:
Para reportar a la Contabilidad se deben asociar los valores
de la factura con los conceptos contables correspondientes.
Asunciones: Los usuarios del sistema tienen ingreso al Sistema a través
de la Web.
Notas y Usos:
48
Figura 6. Caso de uso Comercial.
49
Tabla 3. Caso de Uso de Comercial.
Aplicación: SIFAC - FACTURACIÓN
Cliente: SOFTWARE BUILDERS L.T.D.A.
Caso de Uso ID: 2
Caso de Uso Nombre: Proceso Comercial
Creado Por: VLADIMIR ORTIZ
JULIO ROMANI
Actualizado Por:
Fecha Creación: 12/09/2008 Fecha Actualización:
Actores:
Usuario Administrador,
Usuario Comercial,
Usuario de Gerencia,
Usuario Vendedor
Descripción:
El usuario comercial es la persona encargada de promover
las ventas y distribución de productos y/o servicios ofrecidos
por la compañía. Por lo tanto podrá ingresar al sistema la
información necesaria para tenerla actualizada, El Usuario
Comercial podrá ingresar al sistemas e ingresar la
información del lugar donde se realizo la venta, fija los
precios y condiciones de venta con los Usuario de
Contabilidad y el Usuario de Gerencia. El Usuario Comercial
podrá ingresar al sistema los clientes a los cuales se realizo
la venta. El Usuario Vendedor podrá ingresa al sistema para
consultar, modificar e insertar los clientes. Además debe de
definir el territorio o la zona donde ofrecerá los productos y/o
servicios. Cuando se de la venta el Usuario Vendedor debe
50
generar un contrato de venta y cuando los términos del
contrato cumpla con las políticas de la empresa el Usuario
Gerente podrá Firma para hacerlo valido.
Evento:
1. El Usuario Comercial ingresa la información de cada
producto y/o Servicios que ofrece la compañía.
2. El Usuario Comercial define e ingresa la
información del lugar donde se realizara la venta.
3. Fija los precios y las condiciones de venta con los
Usuario de Contabilidad y el Usuario de Gerencia. El
sistema calcula valores totales e impuestos asociados
con los productos y/o servicios o asociados con el
Cliente.
4. El Usuario Comercial y el Usuario Vendedor validan
e ingresan la información de los clientes a la base de
datos para generar la factura en el momento indicado.
5. El Usuario Vendedor realiza ventas, por lo tanto la
información queda almacenada en la base de datos.
Dicha información es utilizada para generar las
facturas de la empresa.
6. El Usuario Comercial ingresa al sistema y genera los
contratos de venta según los criterios o parámetros
que se presenten.
7. El Usuario de Gerencia y el Usuario Vendedor una
vez creado el contrato se dispone a firmarlo genera
usuario listados o gráficos estadísticos de las ventas
y/o pagos realizados a través del sistema de
facturación.
Precondiciones: Creación de Perfiles y de Usuarios
Creación de Productos y/o Servicios
Creación de Clientes
Poscondiciones: Generación de Interface Área Comercial
51
Flujo Normal: 1.1 Definir Productos y/o Servicios.
1.2 Definir Territorio.
1.3 Definir precios.
1.4 Ingresar Clientes.
1.5 Definir parámetros de venta.
1.6 Realizar venta.
1.7 Generar contrato.
1.8 Firmar contrato.
Flujo Alternativo:
Excepciones:
Casos Incluidos:
Prioridad: Alta
Frecuencia de Uso: Diario
Reglas de Negocio: • Toda venta debe estar relacionada con un cliente
• Las ventas deben generar un contrato.
• Las ventas deben contener los datos obligatorios.
Requerimientos
Especiales:
Asunciones: Los usuarios de registro tienen ingreso al Sistema a través
de Internet
Notas y Usos:
52
Figura 7. Caso de uso Administrador.
53
Tabla 4. Caso de Uso de Administración.
Aplicación: SIFAC - FACTURACIÓN
Cliente: SOFTWARE BUILDERS L.T.D.A.
Caso de Uso ID: 3
Caso de Uso Nombre: Proceso Administración
Creado Por: VLADIMIR ORTIZ
JULIO ROMANI
Actualizado Por:
Fecha Creación: 12/09/2008 Fecha Actualización:
Actores:
Usuario Administrador.
Descripción:
El Usuario Administrador podrá ingresar al sistema para
crear, modificar, consultar y Borrar los perfiles ó Usuarios
que utilizaran la aplicación. El Usuario Administrador ingresa
al sistema y asigna los roles correspondientes a los perfiles
con el fin de controlar la información. Por último el Usuario
Administrador está encargado de realizar Backups en
periodos determinados. Debe de definir el medio de
almacenamiento y el tipo de Backup a realizar.
Evento:
1. El Usuario Administrador ingresa al sistema con los
permisos de Crear, Modificar, Consulta los perfiles
asignados en la empresa.
2. El Usuario Administrador crea, modifica, consulta los
roles pertinentes asignados en la empresa.
3. El Usuario Administrador está encargado de realizar
Backups en periodos determinados. Debe de definir
el medio de almacenamiento y el tipo de Backup a
4. realizar.
54
Precondiciones: Creación de Perfiles y de Usuarios
Definir el medio de almacenamiento donde alójala a la
información de los backups
Definir y asignar los roles de la mejor forma.
Poscondiciones: Generación de Interface para el Administrador.
Flujo Normal: 1. Perfiles.
2. Roles.
3. Backups.
Flujo Alternativo:
Excepciones:
Casos Incluidos:
Prioridad: Alta
Frecuencia de Uso: Diario
Reglas de Negocio: • Los perfiles deben de estar bien definidos
• Los roles deben estar asignados a los perfiles
• Los backups se realizan en los periodos establecidos
Requerimientos
Especiales:
Asunciones: Los usuarios de registro tienen ingreso al Sistema a través
de Internet
Notas y Usos:
55
Figura 8. Caso de uso Contabilidad.
56
Tabla 5. Caso de Uso de Contabilidad
Aplicación: SIFAC – FACTURACIÓN Cliente: SOFTWARE BUILDERS
L.T.D.A.
Caso de Uso ID: 4
Caso de Uso Nombre: Proceso Contabilidad
Creado Por: VLADIMIR ORTIZ
JULIO ROMANI
Actualizado Por:
Fecha Creación: 12/09/2008 Fecha Actualización:
Actores: Usuario Contabilidad.
Descripción: El Usuario Contabilidad podrá ingresar al sistema la
información necesaria para generar la facturación como son
los parámetros de impuestos, teniendo en cuenta los clientes
y proyectos. Además establecer los porcentajes que se
encuentran en la factura y los descuentos por abonos
establecidos.
El Usuario Contabilidad podrá generar reportes de las
cuentas de balance de la empresa en un determinado
tiempo para analizar y tomar decisiones.
Evento: 1. El Usuario Contabilidad establece y define los
parámetros de los impuestos que se debe cancelar.
2. El Usuario Contabilidad específica los porcentajes
que deben aportar los clientes teniendo en cuenta los
proyectos y el tipo de negocio se realiza.
3. El Usuario Contabilidad generará reportes de la
facturación realizada en un determinado tiempo.
Precondiciones: Creación de Perfiles y de Usuarios
Realizar un estudio exhaustivo de los impuestos vigentes,
tarea a realizar con frecuencia.
Realizar las operaciones matemáticas correspondientes para
que la factura sea lo más dinámica posible y las cifras a ser
57
utilizadas den como resultado una probabilidad de cero% de
error al generar la factura.
Poscondiciones: Generación de Interface para el Contabilidad.
Flujo Normal: 1. Definir parámetros de Venta
2. Establecer porcentajes.
3. Generar reportes.
Flujo Alternativo:
Excepciones:
Casos Incluidos:
Prioridad: Alta
Frecuencia de Uso: Diario
Reglas de Negocio: • Los perfiles deben de estar bien definidos
• Los impuestos deben estar actualizados
• Los clientes y proyectos deben satisfacer los requisitos
políticos de la empresa para realizar algún negocio.
Requerimientos
Especiales:
Asunciones: Los usuarios de registro tienen ingreso al Sistema a través
de Internet
Notas y Usos:
58
Figura 9. Diagrama de Funciones. Diagrama de Funciones
De acuerdo al proceso de facturación se ilustra en la figura anterior las diferentes
funciones que contempla el aplicativo que representan las tablas de la base de datos.
59
Figura 10. Diagrama de Funciones –jerárquico. Diagrama de Funciones jerárquico
De acuerdo al proceso de facturación se ilustra en la figura anterior las diferentes funciones jerárquicas o módulos que contempla el aplicativo en la forma de navegación.
60
Figura 11. Diagrama de Funciones Global. Diagrama de Funciones Global
Las funciones globales que se estableció para la construcción del aplicativo se tuvieron en cuenta, son los módulos mas macros que hacen parte de la navegación.
61
DISEÑO DE LA BASE DE DATOS
DISEÑO DE LA RED
DISEÑO DE LA APLICACIÓN
DISEÑO FINAL
DISEÑO AUDITORIA Y CONTROL
PLAN DE PRUEBAS
ARQUITECTURA DEL SISTEMA
ESPECIFICACIÓN DE LOS
PROGRAMAS
DISEÑO DE LA BASE DE DATOS
FASE 3. DISEÑO
La etapa de diseño toma los requerimientos y el modelado de la etapa de análisis y
determina la mejor manera de satisfacerlos, logrando niveles de servicios acordados,
dados el ambiente técnico y las decisiones previas en los niveles requeridos de
automatización. Es decir que del diseño conceptual se pasa al diseño final que será
utilizado para la implantación, por ejemplo en esta etapa, el modelo entidad-relación
será transformado en un diseño de base de datos, y en especificaciones de
almacenamiento y el modelo de funcional, en módulos y manuales de procedimientos.
El diseño final del sistema integra tres diseños, el de la base de datos, el de la
aplicación y el de la red además se elaboran los planes de prueba y de transición y se
realizan los diseños de los sistemas de auditoría y control, y el de respaldos y
recuperación. Los resultados de esta etapa lo constituyen, la arquitectura del sistema,
el diseño de la base de datos, la especificación de los programas, la especificación de
los manuales de procedimientos.
Figura 12. Ciclo de vida de un Software – Fase Diseño.
62
Figura 13. Modelo entidad relación - versión 2.
SIF_PRODUCTOS_SERVICIOS (SIFAC)
PRODUCTO_IDNOMBRE_PRODUCTOVALOR_DEFINICION_IDDESCRIPCIONPORCENTAJE_IVAPORCENTAJE_RETENCION_VENTAVALOR_REALVALOR_VENTAUSUARIO_CREADORFECHA_CREACIONUSUARIO_MODIFICADORFECHA_MODIFICACION
SIF_PERSONAS (SIFAC)
PERSONA_IDCODIGO_PERSONANOMBRE_PERSONAVALOR_DEFINICION_IDVALOCATEGORIZADA_PORNUMERO_DOCUMENTOGENERODIRECCIONTELEFONODIRECCION_CORREOUSUARIO_CREADORFECHA_CREACIONUSUARIO_MODIFICADORFECHA_MODIFICACION
SIF_PAGOS (SIFAC)
PAGO_IDCLIENTE_IDFECHA_PAGOTOTAL_PAGOUSUARIO_CREADORFECHA_CREACIONUSUARIO_MODIFICADORFECHA_MODIFICACION
SIF_HERRAMIENTAS (SIFAC)
HERRAMIENTA_IDFACTURA_IDVALOR_DEFINICION_IDACTIVOPORCENTAJEUSUARIO_CREADORFECHA_CREACIONUSUARIO_MODIFICADORFECHA_MODIFICACION
SIF_FORMAS_PAGOS (SIFAC)
FORMA_PAGO_IDCONTRATO_IDDESCRIPCION_PAGONUMERO_PAGOUSUARIO_CREADORFECHA_CREACIONUSUARIO_MODIFICADORFECHA_MODIFICACION
SIF_FACTURAS (SIFAC)
FACTURA_IDFECHA_FACTURACLIENTE_IDCIUDAD_IDPERSONA_IDCONCEPTO_CONTABLE_IDCONTRATO_IDDOCUMENTO_FUENTEESTADOFECHA_VENCIMEINTOPORCENTAJE_IVAPORCENTAJE_ICAPORCENTAJE_RETENCION_IVAPORCENTAJE_RENTARETENCION_IVARETENCION_ICARETENCION_RENTAVALOR_IVAVALOR_ANTICIPADOVALOR_BRUTOVALOR_BRUTO_A_PAGARSUBTOTALVALOR_TOTALOBSERVACIONESUSUARIO_CREADORFECHA_CREACIONUSUARIO_MODIFICACION
SIF_DETALLES_PAGOS (SIFAC)
DETALLE_PAGO_IDFACTURA_IDPAGO_IDVALOR_PAGOUSUARIO_CREADORFECHA_CREACIONUSUARIO_MODIFICADORFECHA_MODIFICACION
SIF_DETALLES_FACTURAS (SIFAC)
DETALLE_FACTURA_IDDESCRIPCIONPRODUCTO_IDFACTURA_IDFORMA_PAGO_IDCANTIDADANTICIPOVALOR_IVAVALOR_UNITARIOVALOR_TOTALUSUARIO_CREADORFECHA_CREACIONUSUARIO_MODIFICADORFECHA_MODIFICACION
SIF_DETALLES_CONTABLES (SIFAC)
DETALLE_CONTABLE_IDCONCEPTO_CONTABLE_IDPAGO_IDFACTURA_IDVALOR_CREDITOVALOR_DEBITOUSUARIO_CREADORFECHA_CREACIONUSUARIO_MODIFICADORFECHA_MODIFICACION
SIF_CONTRATOS (SIFAC)
CONTRATO_IDNUMERO_CONTRATOOBJETO_CONTRATOACTIVOCLIENTE_IDCIUDAD_IDDURACION_MESESFECHA_INICIOFECHA_FINALIZACIONVALOR_TOTALUSUARIO_CREADORFECHA_CREACIONUSUARIO_MODIFICADORFECHA_MODIFICACION
SIF_CONCEPTOS_CONTABLES (SIFAC)
CONCEPTO_CONTABLE_IDCONCPETOACTIVOPORCENTAJERETENCION_RENTAUSUARIO_CREADORFECHA_CREACIONUSUARIO_MODIFICACIONFECHA_MODIFICACION
SIF_CLIENTES (SIFAC)
CLIENTE_IDNOMBRE_CLIENTERAZON_SOCIALCIUDAD_IDVALOR_DEFINICION_IDNITVERIFICACION_NITDIRECCIONTELEFONO_CLIENTECONTACTO_CLIENTETELEFONO_CONTACTO_NOMBRE_CLIENFAX_CONTACTO_CLIENTECORREO_CONTACTO_CLIENTECONTACTO_COBROTELEFONO_CONTACTO_COBROCORREO_CONTACTO_COBROFAX_CONTACTO_COBRORETENEDOR_IVARETENEDOR_ICARETENEDOR_RENTAPORCENTAJE_RETENCION_IVAUSUARIO_CREADORFECHA_CREACIONUSUARIO_MODIFICADORFECHA_MODIFICACION
SIF_ASIENTOS_CONTABLES (SIFAC)
ASIENTO_CONTABLE_IDCODIGO_ASIENTO_CONTABLENOMBRE_ASIENTO_CONTABLECONCEPTO_CONTABLE_IDCONCEPTDEFINIDO_PARAOPERACIONCREDITODEBITOUSUARIO_CREADORFECHA_CREACIONUSUARIO_MODIFICADORFECHA_MODIFICACION
ADM_VALORES_DEFINICIONES (SIFAC)
VALOR_DEFINICION_IDVALOR_DEFINICIONTIPO_DEFINICION_IDDESCRIPCIONACTIVOUSUARIO_CREADORFECHA_CREACIONUSUARIO_MODIFICADORFECHA_MODIFICACION
ADM_TIPOS_DEFINICIONES (SIFAC)
TIPO_DEFINICION_IDDESCRIPCIONCLASE_DEFINICIONACTIVOUSUARIO_CREADORFECHA_CREACIONUSUARIO_MODIFICADORFECHA_MODIFICACION
ADM_PAISES (SIFAC)
PAIS_IDNOMBRE_PAISCODIGO_PAISINDICATIVO_PAISGENTILICIOUSUARIO_CREADORFECHA_CREACIONUSUARIO_MODIFICADORFECHA_MODIFICACION
ADM_CIUDADES (SIFAC)
CIUDAD_IDNOMBRE_CIUDADPAIS_IDDEPARTAMENTOMUNICIPIOUSUARIO_CREADORFECHA_CREACIONUSUARIO_MODIFICADORFECHA_MODIFICACION
SIFHER_SIFAC_FK
SIFAC_SIFPER_FK
SIFDETPAG_SIFAC_FK
SIF
DETP
AG_P
AG
_SIF
AC_F
K
SIFDETFAC_SIFPROSER_FK
SIF
DETF
AC_S
IFFO
RPAG_F
K
SIF
DETF
AC_S
IFAC_F
K
SIFDETCON_SIFAC_FK
SIFDETCON_PAG_SIFAC_FK
SIFFORPAG_CTO_FK
SIFAC_CTO_FK
SIF
DETC
ON_S
IFCONCON_F
K
SIF
AC_S
IFCONCON_F
K
SIF
AC_S
IFCLI
_FK
PAG_S
IFAC_S
IFCLI
_FK
CTO_SIFCLI_FK
SIF
ASIC
ON_S
IFCONTR
ANSAC
CIO
N_F
K
SIF
ASIC
ON_S
IFCONCO
N_F
K
SIFPROSER_ADMVALDEF_FK
SIFPER_ADMVALDIDENTIFICADO__FK
SIFPER_ADMVALDEF_FK
SIFHER_ADMVALDEF_FK
SIFCLI_ADMVALDEF_FK
ADMVALD
EF_
ADM
TIPDEF_
FK
SIFCLI_ADMCIU_FK
SIF
AC_A
DM
CIU
_FK
CTO
_ADM
CIU
_FK
ADMCIU_ADMPAIS_FK
63
Figura 14. Modelo arquitectura de red.
El modelo entidad relación se modifico varias veces por motivo que no satisfacía las
necesidades del usuario final. Después de muchas reuniones llegamos a una versión que cumplía con los requisitos mencionados en la etapa de estrategia, diseño de la base de datos con la que se desarrollo el aplicativo se ilustra en la figura #.
En el diagrama del modelo de arquitectura de red ilustrado en la figura # se destaca
la existencia de al menos una estación de trabajo y un servidor donde se aloja la base de datos y los componentes de la Web. Además se tendrá en cuenta las tecnologías que se hayan seleccionado de acuerdo al estudio de requerimientos.
Etapa de Pruebas Probar bien un sistema no es una actividad trivial para aprender. Algunos lo
consideran un arte y aprender a hacerlo bien requiere práctica y experiencia. El 50% del tiempo y esfuerzo del desarrollo de Software corresponde a la prueba.
Niveles de Prueba ¨ Prueba de módulo o de unidad ¨ Prueba de integración ¨ Prueba funcional ¨ Prueba del sistema y prueba de aceptación ¨ Prueba de instalación ¨ Prueba de vida
Tipos de Pruebas ¨ Pruebas estáticas.
64
¨ Pruebas dinámicas.
• Principios de la Prueba de Sistemas La prueba es el proceso de ejecutar un programa con la intención de encontrar
errores (parece un enfoque destructivo. Actitud correcta: una prueba exitosa es aquella que encuentra un error).
Auditoria: declare v varchar2(255) := null; c owa_cookie.cookie; begin c := owa_cookie.get('LOGIN_USERNAME_COOKIE'); 4_USUARIO_MODIFICADOR := c.vals(1); 4_FECHA_MODIFICACION := SYSDATE; exception when others then null;
end; declare v varchar2(255) := null; c owa_cookie.cookie; begin c := owa_cookie.get('LOGIN_USERNAME_COOKIE'); 4_USUARIO_CREADOR := c.vals(1); 4_FECHA_CREACION := SYSDATE; exception when others then null; end;
Código bloque anónimo nos permite controlar la auditoria del aplicativo, cada
bloque va en cada forma con el fin de saber que persona se conecto, quien inserto, actualizo con su respectiva hora en la cual se ejecuta la acción.
FASE 4. CONSTRUCCIÓN A partir del diseño final generado en la anterior etapa, en esta de construcción, se codificarán
y probarán los nuevos programas, usando herramientas apropiadas. Esta etapa involucra
planeación, diseño de la estructura del sistema, codificación de abajo a arriba (prueba de
unidades y enlaces), pruebas de arriba a abajo (prueba del sistema) y un enfoque disciplinado
en la realización del trabajo y en el control de versiones del sistema y pruebas. Los resultados
de esta etapa son los programas probados y la base de datos afinada.
65
DISEÑO DE LA BASE DATOS
ARQUITECTURA DEL SISTEMA
ESPECIFICACIÓN DE
LOS PROGRAMAS
CONSTRUCCIÓN
HERRAMIENTAS
PROGRAMAS PROBADOS
Figura 15. Ciclo de vida de un Software – Fase Construcción.
DICCIONARIO BASE DE DATOS Tabla 6. Diccionario Base de Datos (ASIENTOS CONTABLES) La siguiente tabla almacena la información de los códigos contables y sus respectivos
nombres que están relacionados con un impuesto.
ASIENTOS CONTABLES
66
Tabla 7. Diccionario Base de Datos (CLIENTE) La siguiente tabla almacena la información de los clientes a los cuales se les
suministra un producto y/o servicio y a los cuales se les genera la factura.
CLIENTE
67
Tabla 8. Diccionario Base de Datos (CIUDAD) La siguiente tabla almacena información de las ciudades que existen en las
cuales se ha realizado la venta.
CIUDAD
Tabla 9. Diccionario Base de Datos (DETALLE_PAGOS) La siguiente tabla almacena la información de los pagos realizados por una factura. DETALLE PAGOS
68
Tabla 10. Diccionario Base de Datos (DETALLE_FACTURA) La siguiente tabla almacena información acerca de la venta realizada, ingresando los
productos vendidos y los contratos a los cuales se encuentra relacionados.
DETALLE FACTURA
Tabla 11. Diccionario Base de Datos (FORMA_PAGO) La siguiente tabla almacena las diferentes formas de pagar una factura. FORMA PAGO
69
Tabla 12. Diccionario Base de Datos (PAGOS) La siguiente tabla almacena la información de los pagos realizados de la facturas en
sus respectivas ventas.
PAGOS
Tabla 13. Diccionario Base de Datos (TIPO_DEFINICIÓN) La siguiente tabla almacena la información de los diferentes tipos de datos que serán
utilizados en el aplicativo.
TIPO DEFINICIÓN
70
Tabla 14. Diccionario Base de Datos (PRODUCTOS Y/O SERVICIOS) La siguiente tabla se encuentra almacenada los datos de los productos que ofrece la empresa Software Builders Ltda. PRODUCTOS Y/O SERVICIOS
Tabla 15. Diccionario Base de Datos (VALORES_DEFINICIONES) La siguiente tabla almacena la información descriptiva del tipo definición que es utilizada en el aplicativo. VALORES DEFINICIONES
71
Tabla 16. Diccionario Base de Datos (CONCEPTO_CONTABLE) La siguiente tabla almacena la información de la contabilidad donde refleja las ventas y los pagos realizados. CONCEPTO CONTABLE
Tabla 17. Diccionario Base de Datos (CONTRATO) La siguiente tabla almacena los contratos realizados en la empresa Software Builders Ltda. CONTRATO
72
Tabla 18. Diccionario Base de Datos (DETALLE_CONTABLE) La siguiente tabla almacena la información de los impuestos que están relacionados con una factura. DETALLE CONTABLE
Tabla 19. Diccionario Base de Datos (PAÍS) La siguiente tabla almacena los países donde se ha realizado las facturas. PAÍS
73
Tabla 20. Diccionario Base de Datos (FACTURA) La siguiente tabla almacena los datos correspondientes a una factura. FACTURA
74
Tabla 21. Diccionario Base de Datos (PERSONA) La siguiente tabla almacena la información de las personas que participan en la venta de un producto y/o servicio.
PERSONA
FASE 5. DOCUMENTACIÓN Uno de los productos fundamentales para un uso y un mantenimiento efectivos y
eficientes de los sistemas programados son los manuales. Esta metodología
incluye una etapa dedicada a esta actividad tan importante y hace hincapié para
que en su elaboración se consideren el estilo de trabajo y las necesidades propias
de los usuarios que utilizarán y mantendrán el sistema. Esta etapa se realiza al
mismo tiempo que la de construcción.
Los manuales, resultados de esta etapa, se elaboran a partir de las
especificaciones de diseño, de los programas realizados y del análisis del estilo de
trabajo y nivel de competencia de los usuarios y operadores de los sistemas.
75
ESPECIFICACIÓN DE LOS
PROGRAMAS
PROGRAMAS PROBADOS
CONSTRUCCIÓN
ESTILO DE TRABAJO USUARIOS
MANUAL DE USUARIOS
MANUAL TÉCNICO
Figura 16. Ciclo de vida de un Software – Fase Documentación.
La documentación fue hecha a la medida de la construcción y cada una hace
parte de un documento.
Ver anexos:
Documento Manual de Usuario.
Documento Manual Técnico.
FASE 6. TRANSICIÓN
La implantación de sistemas no necesariamente implica la sustitución total de los
antiguos subsistemas y de sus bases de datos correspondientes. En ciertos casos,
por razones operativas y/o económicas, los nuevos sistemas integran algunos de
los antiguos; pero como quiera que sea, la introducción ya sea de un sistema
completamente nuevo o un sistema que integra ya existentes implica un nuevo tipo
de uso y de operación que deberá ser asimilado y aprendido por los usuarios y
operadores. Por esta razón, el desarrollo de un sistema no se termina con su
programación; antes de su liberación para su uso, se debe preveer un período de
transición que deberá incluir la alimentación de las nuevas bases de datos, la
capacitación de los usuarios y el desarrollo de pruebas.
76
NUEVO SISTEMA
DISEÑO FINAL
ALIMENTACIÓN DE
LA BASE DE CAPACITACIÓN PRUEBAS
REPORTE PRUEBAS
En esta metodología la transición conforma una de sus etapas y en ella se realizan
se realizan todas las tareas necesarias para la implementación y proporciona un
periodo inicial de soporte al sistema. La transición debe llevarse a cabo con una
interrupción mínima de la organización, y debe dejar a los usuarios confiados y
listos para explotar el nuevo sistema.
Figura 17. Ciclo de vida de un Software – Fase Transición.
El sistema que se creó es nuevo, ya que en las instalaciones de la empresa
software builders Ltda, no tenían sistematizado el proceso de facturación lo
realizaban manualmente. En la etapa de construcción de la aplicación se conto con
el apoyo del usuario final que sin saber nada de programación, pero si sabia para
que quería el aplicativo iba realizando pruebas a la medida de creación. El usuario
final tenía muy claro lo del proceso de facturación y como se encontró siempre
cerca a la construcción no fue tan necesaria la capacitación pues, en si ella fue
casi la creadora del diseño de los pantallazos. En un futuro si una persona lo
requiere se le dará una capacitación sin embargo con los manuales hechos será
muy fácil adaptarse al aplicativo.
77
NUEVO PROGRAMA PRODUCCIÓN
PRUEBA FINAL
SISTEMAS LISTO PARA SU
PRODUCCIÓN
FASE 7. PRODUCCIÓN
Finalmente, en la etapa de producción se asegura que el sistema funcione
correctamente en la mayoría de los casos, y con intervención mínima de los
administradores del sistema. Para esto se realizan nuevas pruebas, se
reevalúan los resultados y se hacen refinamientos del sistema, los cambios
necesarios deberán ser introducidos sin afectar a los usuarios, y deberá
conseguirse la máxima confianza de los usuarios. El resultado de esta etapa un
sistema listo para su operación.
Figura 18. Ciclo de vida de un Software – Fase Producción.
El aplicativo “SIFAC” nombre que recibió el proyecto quedo instalado, funcionando
con pruebas reales en las cuales se ingresaron datos del último mes y funciono
correctamente sin embargo se anexa una carta de aceptación por parte de la
empresa Software Builders Ltda. lo mejor del aplicativo es que se encuentra
hecho en una herramienta muy robusta y permite la estabilidad, usabilidad,
escalabilidad , por tal razón a dicho aplicativo se podrá agregar otros procesos en
los cuales fallan en la empresa por qué no se encuentran sistematizados.
Las pruebas finales se manejaron en un formato de la empresa Software Builders
Ltda. Se realizo una prueba por cada forma que consta la aplicación, las pruebas
fueron realizadas directamente por el usuario final.
78
Las pruebas realizadas fueron las siguientes:
La persona encargada de facturar en la empresa Software Builders Ltda. entro al
aplicativo y navego por el menú que propusimos, entrando por cada forma. La
prueba se basaba en la funcionalidad del aplicativo esto se logro haciendo
inserciones, actualizaciones, consultas y borrada de datos con el fin de mirar la
consistencia y la velocidad del proceso de ejecución.
Una vez realizada la prueba, la funcionaria de la empresa diligencia un formato
donde coloca la fecha en la cual se hizo la prueba, el nombre de la persona quien
realiza la prueba, modulo por donde navego, la forma donde realizo la prueba, se
describe que pruebas fueron las que se aplicaron, las inconformidades
encontradas son descritas, y por ultimo hay un campo de observaciones por si hay
alguna sugerencia de dicha forma.
Las pruebas hechas con su formato respectivo se ilustran a continuación:
79
PLAN DE PRUEBAS - SIFAC- PÁGINA: 79
Se realizaron pruebas de cada uno de los módulos que la empresa tendrá en el proceso de facturación A continuación se mostrará cada una de las pruebas que se hizo a SIFAC para comprobar la consistencia y estabilidad del aplicativo. Figura 19. Ciclo de vida de un Software – Pruebas. PRUEBA 1
FECHA DE EJECUCION 19-Nov-2008
ELABORADO POR Maritza Sandoval
MODULO Administración
FORMA(S) O REPORTE(S) Tipos Definiciones
PROCEDIMIENTO Consultar, Insertar, Actualizar, Borrar NO CONFORMIDADES DETECTADAS Ninguna
OBSERVACIONES Se inserto, actualizo y se borraron datos de tipos definiciones
80
PLAN DE PRUEBAS - SIFAC- PÁGINA: 2
PRUEBA 2
FECHA DE EJECUCION 19-Nov-2008
ELABORADO POR Maritza Sandoval
MODULO Administración
FORMA(S) O REPORTE(S) Valores Definiciones
PROCEDIMIENTO Consultar, Insertar, Actualizar, Borrar , Validar listas de valores NO CONFORMIDADES DETECTADAS Ninguna
OBSERVACIONES Se consulto, inserto, actualizo y se borraron datos de valores definiciones
81
PLAN DE PRUEBAS - SIFAC- PÁGINA: 3
PRUEBA 3
FECHA DE EJECUCION 19-Nov-2008
ELABORADO POR Maritza Sandoval
MODULO Administración
FORMA(S) O REPORTE(S) Herramientas
PROCEDIMIENTO Consultar, Insertar, Actualizar, Borrar, Validar listas de valores NO CONFORMIDADES DETECTADAS Quitar validaciones de javascript
OBSERVACIONES Se consulto, inserto, actualizo y se borraron datos de herramientas
82
PLAN DE PRUEBAS
- SIFAC- PÁGINA: 4
PRUEBA 4
FECHA DE EJECUCION 19-Nov-2008
ELABORADO POR Maritza Sandoval
MODULO Administración
FORMA(S) O REPORTE(S) Paises
PROCEDIMIENTO Consultar, Insertar, Actualizar, Borrar NO CONFORMIDADES DETECTADAS Quitar validaciones de javascript
OBSERVACIONES Se inserto, actualizo y se borraron datos de países
83
PLAN DE PRUEBAS
- SIFAC- PÁGINA: 5
PRUEBA 5
FECHA DE EJECUCION 19-Nov-2008
ELABORADO POR Maritza Sandoval
MODULO Administración
FORMA(S) O REPORTE(S) Ciudades
PROCEDIMIENTO Insertar, Actualizar, Borrar , Validar listas de valores NO CONFORMIDADES DETECTADAS Quitar validaciones de javascript
OBSERVACIONES Se consulto, inserto, actualizo y se borraron datos de ciudades
84
PLAN DE PRUEBAS
- SIFAC- PÁGINA: 6
PRUEBA 6
FECHA DE EJECUCION 19-Nov-2008
ELABORADO POR Maritza Sandoval
MODULO Administración
FORMA(S) O REPORTE(S) Productos
PROCEDIMIENTO Consultar, Insertar, Actualizar, Borrar , Validar lista de valores NO CONFORMIDADES DETECTADAS Quitar validaciones de javascript
OBSERVACIONES Se consulto, inserto, actualizo y se borraron datos de productos
85
PLAN DE PRUEBAS
- SIFAC- PÁGINA: 7
PRUEBA 7
FECHA DE EJECUCION 19-Nov-2008
ELABORADO POR Maritza Sandoval
MODULO Clientes
FORMA(S) O REPORTE(S) Clientes
PROCEDIMIENTO Consultar, Insertar, Actualizar, Borrar , Validar lista de valores NO CONFORMIDADES DETECTADAS Ninguna
OBSERVACIONES Se consulto, inserto, actualizo y se borraron datos de clientes
86
PLAN DE PRUEBAS
- SIFAC- PÁGINA: 8
PRUEBA 8
FECHA DE EJECUCION 19-Nov-2008
ELABORADO POR Maritza Sandoval
MODULO Clientes
FORMA(S) O REPORTE(S) Contratos
PROCEDIMIENTO Consultar, Insertar, Actualizar, Borrar , Validar lista de valores NO CONFORMIDADES DETECTADAS Ninguna
OBSERVACIONES Se consulto, inserto, actualizo y se borraron datos de contratos
87
PLAN DE PRUEBAS
- SIFAC- PÁGINA: 9
PRUEBA 9
FECHA DE EJECUCION 19-Nov-2008
ELABORADO POR Maritza Sandoval
MODULO Clientes
FORMA(S) O REPORTE(S) Forma Pagos
PROCEDIMIENTO Consultar, Insertar, Actualizar, Borrar , Validar lista de valores NO CONFORMIDADES DETECTADAS Ninguna
OBSERVACIONES Se consulto, inserto, actualizo y se borraron datos de forma de pagos
88
PLAN DE PRUEBAS
- SIFAC- PÁGINA: 10
PRUEBA 10
FECHA DE EJECUCION 19-Nov-2008
ELABORADO POR Maritza Sandoval
MODULO Personal
FORMA(S) O REPORTE(S) Personas
PROCEDIMIENTO Consultar, Insertar, Actualizar, Borrar , Validar lista de valores NO CONFORMIDADES DETECTADAS Ninguna
OBSERVACIONES Se consulto, inserto, actualizo y se borraron datos de personas
89
PLAN DE PRUEBAS
- SIFAC- PÁGINA: 11
PRUEBA 11
FECHA DE EJECUCION 19-Nov-2008
ELABORADO POR Maritza Sandoval
MODULO Contabilidad
FORMA(S) O REPORTE(S) Pagos
PROCEDIMIENTO Consultar, Insertar, Actualizar, Borrar , Validar lista de valores NO CONFORMIDADES DETECTADAS Ninguna
OBSERVACIONES Se consulto, inserto, actualizo y se borraron datos de pagos
90
PLAN DE PRUEBAS
- SIFAC- PÁGINA: 12
PRUEBA 12
FECHA DE EJECUCION 19-Nov-2008
ELABORADO POR Maritza Sandoval
MODULO Contabilidad
FORMA(S) O REPORTE(S) Detalles Pagos
PROCEDIMIENTO Consultar, Insertar, Actualizar, Borrar , Validar lista de valores NO CONFORMIDADES DETECTADAS Ninguna
OBSERVACIONES Se consulto, inserto, actualizo y se borraron datos de detalles pagos
91
PLAN DE PRUEBAS
- SIFAC- PÁGINA: 13
PRUEBA 13
FECHA DE EJECUCION 19-Nov-2008
ELABORADO POR Maritza Sandoval
MODULO Contabilidad
FORMA(S) O REPORTE(S) Conceptos Contables
PROCEDIMIENTO Consultar NO CONFORMIDADES DETECTADAS Ninguna
OBSERVACIONES Se consulto datos de detalles pagos
92
PLAN DE PRUEBAS
- SIFAC- PÁGINA: 14
PRUEBA 14
FECHA DE EJECUCION 19-Nov-2008
ELABORADO POR Maritza Sandoval
MODULO Contabilidad
FORMA(S) O REPORTE(S) Factura
PROCEDIMIENTO Consultar, Insertar, Actualizar, Borrar , Validar lista de valores NO CONFORMIDADES DETECTADAS Ninguna
OBSERVACIONES Se consulto, inserto, actualizo y se borraron datos de factura
93
PLAN DE PRUEBAS
- SIFAC- PÁGINA: 15
PRUEBA 15
FECHA DE EJECUCION 19-Nov-2008
ELABORADO POR Maritza Sandoval
MODULO Contabilidad
FORMA(S) O REPORTE(S) Detalle Factura
PROCEDIMIENTO Consultar, Insertar, Actualizar, Borrar , Validar lista de valores NO CONFORMIDADES DETECTADAS Ninguna
OBSERVACIONES Se consulto, inserto, actualizo y se borraron datos de detalle factura
94
PLAN DE PRUEBAS
- SIFAC- PÁGINA: 16
PRUEBA 16
FECHA DE EJECUCION 19-Nov-2008
ELABORADO POR Maritza Sandoval
MODULO Contabilidad
FORMA(S) O REPORTE(S) Forma de Impresión
PROCEDIMIENTO Validar que la factura sea impresa NO CONFORMIDADES DETECTADAS Fecha mascara formato Año-Mes-Día
OBSERVACIONES Se valido que la factura sea impresa
95
PLAN DE PRUEBAS
- SIFAC- PÁGINA: 17
PRUEBA 17
FECHA DE EJECUCION 19-Nov-2008
ELABORADO POR Maritza Sandoval
MODULO Contabilidad
FORMA(S) O REPORTE(S) Impresión
PROCEDIMIENTO Factura sea impresa NO CONFORMIDADES DETECTADAS Ninguna
96
OBSERVACIONES La factura fue impresa PLAN DE PRUEBAS
- SIFAC- PÁGINA: 18
PRUEBA 18
FECHA DE EJECUCION 19-Nov-2008
ELABORADO POR Maritza Sandoval
MODULO Calendario
FORMA(S) O REPORTE(S) Calendario Facturas
PROCEDIMIENTO Validar que las fecha de factura sean almacenadas en el calendario
NO CONFORMIDADES DETECTADAS Ingresar el monto del pago total
OBSERVACIONES Se mostró el nombre de los clientes dentro del calendario.
97
PLAN DE PRUEBAS - SIFAC- PÁGINA: 19
PRUEBA 19
FECHA DE EJECUCION 19-Nov-2008
ELABORADO POR Maritza Sandoval
MODULO Calendario
FORMA(S) O REPORTE(S) Calendario Pago
PROCEDIMIENTO Validar que las fecha de pagos sean almacenadas en el calendario
NO CONFORMIDADES DETECTADAS Ingresar el nombre y teléfono del contacto cobro
OBSERVACIONES Se mostró el nombre, valor a pagar y teléfono de los clientes dentro del calendario.
98
PLAN DE PRUEBAS - SIFAC- PÁGINA: 20
PRUEBA 20
FECHA DE EJECUCION 19-Nov-2008
ELABORADO POR Maritza Sandoval
MODULO Reporte
FORMA(S) O REPORTE(S) Reporte Asientos Contables
PROCEDIMIENTO Validar que aparezcan los conceptos contables con sus respectivos valores
NO CONFORMIDADES DETECTADAS Ninguna
OBSERVACIONES Se mostró el asiento contable que los clientes que hayan generado alguna facturación
99
5. CONCLUSIONES
• Para desarrollar e implementar un proceso de facturación es
necesario que existan procesos y procedimientos bien establecido en
la empresa Software Builders.
• La metodología de desarrollo Oracle Case implementada en este
proyecto cumplió satisfactoriamente en el desarrollo de la aplicación
lo que permitió obtener un producto de alta calidad y recursividad
para el proceso de facturación.
• El motor de la base de datos Oracle Express Edition conjunto a
Oracle Application Express se utilizó para desarrollar la aplicación
que ofreció un amplio recurso en el software para el desarrollo de
automatización.
100
6. RECOMENDACIONES
• Se recomienda a la empresa Software Builders hacer uso inmediato
del aplicativo para tener el sistema de facturación automatizado
logrando asi hacer el proceso mas eficiente.
• Los proceso con ciertas falencias en la empresa Software Builders
pueden ser solucionadas utilizando Oracle Express Edition
aprovechando que es una herramienta Open Source que permitirá
desarrolla aplicativos sin ningún costo.
• Cuando se desarrollen aplicativo a futuro se recomienda utilizar la
metodología Oracle Case la cual cumple con el proceso de ciclo de
vida de un software, cabe aclarar que la herramienta a utilizar
pertenece a productos Oracle.
101
BIBLIOGRAFÍA
Expert Oracle Database 10g Administration, Alapati, Sam R. (APRESS). 1200 páginas.
Estándares del Instituto Colombiano de Normas Técnicas (ICONTEC)
http://www.gs1co.org/
Oracle Database 10g Manual Del Administrador, autor Loney, Kevin & Bryla, Bob
(Editorial McGraw-Hill), editorial c1991. McGraw-Hill. 800 páginas. 1ª edición
(26/11/2005).
http://www.oracle.com/database/index.html
Oracle 10g. Administración Y Análisis De Bases De Datos. 2ª Edición, PEREZ, C.
(Editorial Ra-ma). 712 páginas.
http://www.mysql-hispano.org/
Sistemas de bases de datos. Conceptos fundamentales, R Elmasri, SB Navathe -
Addison-Wesley Iberoam, 2002
http://es.wikipedia.org/wiki/PostgreSQL
Diseno y Administracion de Bases de Datos, GW Hansen, JV Hansen - 1997 -
Prentice Hall.
Oracle database 10g express edition php web programming,mclaughlin, michael. 1ª
edición.
102
GLOSARIO
Atributos: Características de una entidad.
Base de Datos: Conjunto de entidades que permite almacenar datos de forma
detallada y precisa, los datos en cada tabla son relacionados que permite una consulta
más rápida y eficiente, las bases de datos además son un conjunto de datos
organizados que permite acceder fácil a ellos gestionarlos y consultarlos.
Base de datos estáticas: Base de datos de solamente lectura, fundamentalmente se
utiliza para almacenar datos de muchos años lo cual permitirá analizar el
procedimiento de los datos a través del tiempo y poder tomar decisiones.
Base de datos dinámicas: Base de datos donde la información es almacenada a
través del tiempo permitiendo ser actualizar y permitiendo adicionar datos, además de
ser consultada.
Base de datos relacional: Base de datos donde las tablas o entidades estan
relacionadas por medio de los registros, las bases de datos relacione tiene que pasar
los procesos de normalización.
Campo: Concierne al nombre la columna, es necesario que se única y tenga asociado
un tipo de dato.
Entidad: Conjunto de atributos que contiene información y que es identificado por una
única llave primaria, además está compuesta por dos estructuras campos y registros.
Factura: documento que refleja detalladamente la compra de un producto que se
hace a través de un vendedor hacia un destinatario permitiendo tener la constancia
de una venta , donde se especifica la fecha de la compra, el nombre del vendedor y
destinatario, y el precio de dicho producto o servicio.
103
Facturación: Proceso por el cual un entidad o empresa da por determinada una venta
permitiendo ejecutar un documento de constancia entre un vendedor y un destinatario
en la cual se reflejará en valor neto de la venta.
Llave primaria: Campo que identifica un registro de forma única, ningún otro registro
puede tener la misma clave primaria que el registro principal.
Registro: Concierne a cada fila de la tabla, allí se encuentran los registro, algunas
veces son nulos lo cual no tiene ningún dato asociado.
SGDB: “Sistema Gestores de Base de Datos” permite almacenar y acceder a los datos
de una forma organizada, sus propiedades son usadas para el ámbito informático,
también son utilizadas para almacenar información experimental.
104
ANEXOS
Manual de usuario
Manual Técnico