UNIVERSIDAD SALESIANA DE

BOLIVIA
CARRERA: Contaduría Pública

MATERIA: DESARROLLO DE SISTEMA DE INFORMACIÓN

CONTABLE
INTEGRANTES:
 Alanis López Ana
 Effeng Anzaldo Maria René
 Mamani Acosta Florencio
 Patiño Martinez Nayder
 Rodas Padilla Neveisa
DOCENTE: Ing. Amalia Y. Subelza M
FECHA: 31 de agosto de 2019
Introducción
Para la pequeña o mediana empresa es fundamental crear un sistema de trabajo
para poder organizar y atender al cliente.

Con un sistema contable se desea lograr abrir un comercio o tienda, resulta

fundamental llevar la contabilidad para después hacer la correspondiente
declaración fiscal ante la administración u órgano competente cabe destacar que en
todo negocio esta se realiza de manera obligatoria. Para ello será necesario llevar
un control de las compras y ventas, es decir de los gastos e ingresos de nuestra
tienda.

Aunque la fiscalidad de una tienda puede seguir realizándose con el método

tradicional, con papel y bolígrafo que nos dificulta al momento de realizar la
fiscalidad por lo que se quiere llegar a trabajar con un software o programa
informático de contabilidad para que sea más llevadera hacer la fiscalidad.

Además de la parte fiscal también se quiere llegar a:

 Predecir los flujos de dinero.

 Ayudar a realizar una buena planificación y control
 Ayudar a tomar decisiones en temas de inversión
 Evaluar la administración
 Controlar las operaciones financieras
 Evaluar los beneficios que se obtienen (pérdidas o ganancia)
 Brindar seguridad de los datos financieros que son lo más valioso de una
empresa evitando la perdida de los mismos datos.
 CAPÍTULO I

ANTECEDENTES
1. Antecedentes
En este capítulo se desarrollarán los antecedentes de la empresa, en el año
2014 se inicia las actividades de venta de variedades de productos en el mini
mercado Doña Elvia; inicialmente con un contrato de alquiler por 2 años de
una caseta en el mercado 22 de noviembre, ubicado en Bulo Bulo, barrio
Comercial, entre la calle Cochabamba y calle Comercial, el mini mercado
empezó sus actividades con poca mercadería, pero en ese entonces con
bastante clientela; a principios del año 2015 por incumplimiento de contrato
por parte del arrendatario, los propietarios Elvia García y su esposo Arandu
Rocha, se vieron obligados a realizar el traslado del mini mercado a su
residencia, ubicado actualmente en Bulo Bulo, en el departamento de
Cochabamba, Provincia Carrasco, sobre la carretera Ruta Nacional 4, Santa
Cruz-Cochabamba a 191 kilómetros de la ciudad de Santa Cruz de la Sierra;
las dimensiones actuales del establecimiento son 15X10 y 4 metros de alto,
cuenta con dos depósitos de 5X4 metros contando con un espacio más
grande, se vio la necesidad de incrementar el capital para la compra de
mercadería. Actualmente el mini mercado Doña Elvia cuenta con un cajero,
un personal de limpieza, un acomodador o reponedor de productos y la
administración a cargo de Elvia García y su esposo Arandu Rocha.
La colaboración social a la población es abastecer con los productos básicos
que requiera la población y así mismo proporcionar facilidad de pedidos a las
empresas que están establecidas en la zona.

2. Definición del problema

- No se cuenta con un sistema de información contable.
- Falta de control del efectivo en la caja por concepto de productos vendidos.
- Los informes del día no son fiables, es decir no son dignos de confianza
debido a que el cajero puede alterar las ventas para beneficios personales.
- Es cansador y al mismo tiempo tedioso para los administradores realizar
revisiones semanales y/o mensualmente sobre los informes de las ventas,
los cuales actualmente están en libros, escrito a mano.
- No existe un adecuado control en el inventario de los productos que se
encuentran en los depósitos.
- Inversión innecesaria para la compra de productos a pedido por parte de
algunos clientes.
- No existe un registro de ingresos y egresos.
-
3. Situación problemática
Es necesario la implementación de un sistema contable que ayude al control
adecuado de todos los ingresos y egresos, para el mejor manejo de la
contabilidad del mini mercado; además pueda registrar los diferentes
proveedores y al final del día pueda proporcionar a los dueños una
información oportuna y confiable.

4. Situación deseada

El mini mercado “Doña Elvia” requiere la implementación de un sistema

contable fiable para el mejor control de los ingresos y egresos anuales al

mismo tiempo cuantificar con exactitud las pérdidas o utilidades que se
produjeron en cada gestión.

5. Objetivos
5.1. Objetivo General
Desarrollar un sistema contable idóneo para el adecuado control de los

ingresos y egresos del mini mercado “Doña Elvia”.

5.2. Objetivo Especifico

 Desarrollar e implementar un sistema de información contable
 Realizar el adecuado control de los ingresos por concepto de productos
vendidos.
 Veracidad de los informes emitidos por el cajero
 Incorporar respaldos de las ventas que se realizan
  En el sistema contable, incorporar un resumen de los ingresos por ventas
de manera mensual o semestral.
 Realizar codificaciones de los productos que se encuentran en los
depósitos, para tener un mejor control de la cuantificación de los mismos.
 Evitar la inversión innecesaria para realizar la compra de algunos
productos que son pedidos por terceras personas.

6. Justificación

El mini mercado “Doña Elvia” presenta problemas como la falta e

implementación de un sistema contable que pueda llevar un manejo idóneo

y adecuado de sus ingresos y egresos al momento de realizar las ventas y
compras de sus productos.
El desarrollo del sistema de información contable, en el mini mercado “Doña
Elvia” es importante debido al crecimiento económico y desarrollo de la
población, ya que actualmente existe un nivel notable en la demanda de los
productos, por lo que se ve la necesidad de la implementación de un sistema
contable, para brindar información sobre los ingresos y egresos de manera
oportuna y confiable.

7. Alcance
El sistema de información contable permitirá a los administradores y dueños

del mini mercado “Doña Elvia” controlar con exactitud y confiabilidad las

transacciones contables que realiza diariamente.

Usuario
- Registrar usuario
- Modificar usuario
- Eliminar usuario
- Generar copia de seguridad
 Ventas y Compras
- Ingresa al sistema
- Registro de ventas
- Emite nota de ventas
- Registro de datos de facturación
- Ingresa al sistema
- Registro de compras
- Actualizar stock
- Control del registro de facturación

Ingresos y Egresos
- Registro de egresos
- Modificación de egresos
- Eliminar registro de egresos
- Registro de ingresos
- Modificación de ingresos
- Eliminar registro de ingresos

Gestión
- Crear gestión
- Modificar gestión
- Eliminar gestión

Libro diario
- Registro de la gestión
- Registro de la fecha
- Registro de los detalles
- Registro de numero de folios
- Registro de los montos del debe
- Registro de los montos del haber
- Registro de sumas iguales del debe y el haber
- Registro de la glosa

Libro mayor
- Registro de las cuentas del deudor y el acreedor
- Registro de las diferencias contables
- Registro de sumas y saldos

Balance inicial
- Registro de cuentas corrientes
- Registro de cuentas no corrientes
- Registro pasivo corriente
- Registro pasivo no corriente
- Registro de las cuentas del patrimonio
- Registro de sumas de activos y patrimonio
- Registro total activo y patrimonio

EERR de pérdidas y ganancias

- Registro de ventas de los productos
- Registro de costos de producción
- Registro de gastos
- Registro de ingresos
- Registro de utilidad de gestión

Reportes
- Registro de ingresos y egresos
- Registro de libro diario
- Registro de libor mayor
- Registro de estado de resultado de pérdidas y ganancias

8. Metodología de Desarrollo
 Para el Desarrollo del Sistema Contable se utilizará el Proceso Unificado de
Desarrollo de Software (PUDS), junto con el Lenguaje Unificado de modelado
(el UML), ya que es una de las herramientas más emocionantes en el mundo
actual del Desarrollo del Sistema. Esto se debe a que permite a los creadores
de sistema generar diseños que capturen sus ideas en una forma
convencional y fácil de comprender para comunicarlas a otra persona.
9. El Proceso Unificado de Desarrollo de Software (RUP)
El Proceso Unificado es un proceso de software genérico que puede ser
utilizado para una gran cantidad de tipos de software, para diferentes áreas
de aplicación, diferentes tipos de organizaciones, diferentes niveles de
competencia y diferentes tamaños de proyectos.
Provee un enfoque disciplinado en la aplicación de tareas y
responsabilidades dentro de una organización de desarrollo. Su meta es
asegurar la producción de software de muy alta calidad que satisfaga las
necesidades de los usuarios finales, dentro de un calendario y presupuesto
predecible.
10. Planificación de Proyecto
 El diagrama de Gantt transcrito en números queda expresado en forma de la
siguiente tabla:

ID TAREA DURACIÓN FECHA FECHA FIN PREDECESORES

INICIO
1 Requisitos 12 Días 03/08/2019 15/08/2019

2 Análisis 15 Días 16/08/2019 31/08/2019 1

3 Diseño 18 Días 01/09/2019 19/09/2019 2

4 Implementación 35 Días 20/09/2019 25/10/2019

5 Prueba 10 Días 26/10/2019 05/11/2019

La duración de cada tarea es aproximada

CAPÍTULO II

CAPTURA DE
REQUISITOS
1. Requerimientos del Sistema
El primer paso para cumplir el objetivo general de desarrollar un Sistema de
Gestión Contable para el "Mini Mercado Doña Elvia", es la captura de
requisitos del Sistema.
Siguiendo la metodología (PUDS), escogida para el desarrollo del Sistema
de información computarizado, se procede a la captura de requerimientos.

2. Lista de Requerimientos
La lista de características del sistema constituye los requisitos candidatos.
De cada característica se registra:
 Estado. - Propuesto, aprobado, incorporado, validado.
 Propuesto: Los requerimientos en este estado, corresponden a
las sugerencias dadas por el mejor funcionamiento del sistema.
 Incorporado: Son los requerimientos que están incluidos en el
sistema actual de la organización
 Aprobado: Representa los requerimientos exigidos por la
organización, aunque no se encuentren incorporados en el
sistema actual.
 Costo. - Es un valor que especifica el coste de desarrollo del requerimiento
expresado den días/hombre.
 Prioridad. - Especifica la necesidad de contar con este requisito en el
sistema y pueden ser: critica, importante, asesoría.
 Riesgo. - Es el nivel del riesgo asociado al desarrollo e implementación de
los requisitos y estos pueden ser: critico, significativo, normal.
N° DESCRIPCIÓN ESTADO COSTO PRIORIDAD RIESGO
1 Modificar asientos Propuesto 1 Importante Normal
2 Comenzar nueva gestión Propuesto 1 Importante Normal
3 Registrar datos del balance inicial Propuesto 1 Asesoría Normal
4 Registrar datos de los libros diarios Propuesto 2 Importante Normal
5 Registrar de los libros mayores Aprobado 1 Importante Normal
6 Generar las sumas y saldos Propuesto 1 Asesoría Normal
7 Generar reportes del libro diario Aprobado 2 Importante Normal
8 Generar comprobación de sumas y Propuesto 1 Asesoría Normal
saldos
9 Generar el estado de resultados de Propuesto 1 Asesoría Normal
perdidas/ganancias

3. Contexto del Sistema

Un modelo de negocio es más amplio. Describe los procesos con el objetivo
de comprenderlos. El modelado de negocio especifico, que procesos de
negocios soportará el sistema.

4. Modelo de Negocio
En el modelo de negocio se describe los procesos de negocio a través de
diagramas de actividades, para comprender mejor el contexto del sistema.
 5. Modelo de Casos de Uso (Casos de Uso General)
En la figura # 2 se muestra el modelo de casos de uso mediante el cual se
puede apreciar las relaciones entre los casos de uso del sistema de
información en la contabilidad.
Este modelo se encuentra a partir del diagrama de actividades del modelo
de negocio visto anteriormente en la figura # 1

Caso de Uso Gestiona el pedido

Actor Principal Administrador Usuario

Participantes e Administrador: Desea realizar una venta, crear un producto, modificar un

Intereses producto o eliminar un producto.
Usuario: Desea realizar una venta.
Precondiciones 1. El usuario debe haber seleccionado la opción realizar venta, ingresar
stock, crear producto, modificar producto o eliminar producto.
2. El usuario debe leer el código de barra del producto o ingresar el código
del producto.
Postcondiciones El sistema indicara si existe o no el producto.
Escenario principal 1. El sistema ofrece la opción de crear el producto
2. El sistema llama a la función buscar proveedor en el caso de estar en un
ingreso de stock.
Extensiones 1.1 El usuario acepta la opción.
1.1.1 El sistema abre re direcciona a la interfaz de crear producto.
Requisitos No hay requisitos especiales.
Especiales
Frecuencia de Alta
Ocurrencia
Caso de Uso Gestiona Ventas
Actor Principal Vendedor Usuario

Participantes e Vendedor: Gestiona ventas, genera informe, registra clientes.

Intereses Usuario: Desea registrar una venta.

Precondiciones Acceso al sistema

Postcondiciones Buscar módulo de ventas

Escenario principal 1. Vendedor ingresa al sistema
2. Se loguea con sus usuarios y contraseñas
3. Vendedor busca el módulo de ventas
4. El vendedor ingresa al módulo

Extensiones 1.1 si el vendedor no tiene usuario solicita un login

2.1 si el vendedor ingresa mal el usuario o la contraseña, sistema da aviso
3.1 en caso de olvidar su contraseña se pide cambio del mismo

Requisitos En el caso de ser una venta el usuario debe verificar que tiene permisos de
Especiales administrador.
El paso 2 del escenario principal debe indicar que no exista el producto.
Frecuencia de
Ocurrencia Alta
Caso de Uso Crear Producto
Actor Principal Contador Usuario

Participantes e Contador: Desea registrar un producto, registrar una venta o ingresar stock.
Intereses Usuario: Desea registrar una venta.

Precondiciones 1. El usuario debe tener privilegios de administrador.

2. El usuario debe haber ingresado en la opción de gestionar productos,
realizar venta o ingresar stock, e ingresar un producto desconocido para la
base de datos.
Postcondiciones Por pantalla se indica que el producto fue creado exitosamente.
Escenario principal 5. El Usuario ingresa código de barra del producto.
6. El sistema verifica el producto.
7. El Usuario ingresa y selecciona los datos del producto que desea crear.
8. El usuario selecciona la opción guardar.
9. El sistema guarda el producto en la base de datos.
Extensiones 1.1 El usuario ingresa letras en el código del producto.
1.1.1 El sistema le pide que lo reintente y que ingrese solo caracteres
numéricos.
2.1 El sistema llama a la función Buscar Producto.
3.1 El usuario ingresa letras en los precios, margen o stock.
3.1.1 El sistema le pide que lo reintente y que ingrese solo caracteres
numéricos.

Requisitos En el caso de ser una venta el usuario debe verificar que tiene permisos de
Especiales administrador.
El paso 2 del escenario principal debe indicar que no exista el producto.
Frecuencia de
Ocurrencia Alta
 6. Actores

Durante la captura se pudo identificar los siguientes actores:

 (Administrador) Propietaria: Encargada del Control de las ventas.

 (Usuario) Empleados: Realiza las ventas

 Contador: Emite informes contables.

7. Casos de Uso
Los casos de uso dentro del proceso unificado de desarrollo son una parte
muy importante, pues el sistema está dirigido por los casos de uso desde el
principio y final, es por ello que estos deben ser identificados en la fase de la
captura de requisitos.
Los siguientes son algunos de los casos de uso que fueron identificados
durante la captura de requisitos.
1. Gestiona el pedido
2. Compra del producto
3. Actualizar stock
4. Gestionar base de datos
5. Gestionar productos
6. Gestionar ventas
7. Genera informe
8. Registra clientes
9. Controlar inventario
10. Registrar datos del balance inicial
11. Registrar datos de libros diarios
12. Registrar datos de libros mayores
13. Supervisar las ventas
14. Generar el estado de resultado de pérdidas y ganancias
 8. Captura de Requisitos como Casos de Uso
La captura de requisitos como casos de uso es muy importante en el marco
del desarrollo de un sistema el cual se realiza mediante los casos de uso,
identificados en la captura de requisitos.
En la tabla #1 se muestra la lista de requerimientos en un formato de
especificación para los casos de uso.
A continuación, se detallarán algunos casos de uso utilizando el formato de
la tabla #2:

Caso de Uso Nombre del caso de uso

Actores Lista de actores

Propósito Intención del caso de uso

Resumen Repetición del caso de uso de alto nivel

Curso normal evento Es una parte importante del formato expandido de

presentación; describe los detalles de interacción entre
los actores y el sistema. Explica la secuencia más común
de los eventos, no incluye situaciones alternas.

Diagrama Representación gráfica del caso de uso

9. Actividad: Analizar un Caso de Uso

Analizamos un caso de uso para:

 Identificar las clases del análisis cuyos objetos son necesarios para llevar a
cabo el flujo de suceso del caso de uso.

 Distribuir el comportamiento del caso de uso entre objetos del análisis que
interactúan.

 Capturar requisitos especiales sobre la realización del caso de uso.

CAPÍTULO III

ANALISIS DE
REQUISITOS
 1. Introducción
Durante el análisis, analizamos los requisitos que se describieron en la
captura de requisitos, refinándolos y estructurándolos. El objetivo de hacerlo
es conseguir una comprensión más precisa de los requisitos y una
descripción de los mismos que sea fácil de mantener y que nos ayude a
estructurar el sistema enero, incluyendo su arquitectura.
Comparación del modelo de casos de usos con el modelo del análisis: el
lenguaje que utilizamos en el análisis se basa en un modelo de objetos
conceptuales, que llamamos modelo de análisis. El modelo de análisis nos
ayuda a refinar los requisitos.

2. Identificación de paquetes de análisis

2.1. Identificación de paquetes de servicios
Los paquetes proporcionan un medio para organizar el modelo de
análisis en piezas más pequeñas y manejables.

La identificación de paquetes de servicios se suele hacer cuando el trabajo de

análisis está avanzado, cuando se comprenden bien los requisitos funcionales, y
existen la mayoría de las clases del análisis.
 - Identificar un paquete de servicios por cada servicio opcional.
- Identificar un paquete de servicios por cada servicio que podría hacerse
opcional, incluso aunque todos los clientes siempre lo quieran.

La identificación de paquetes de red es una representación visual de una red de

computadoras o telecomunicaciones, muestra los componentes que conforman una
red y cómo interactúan.

2.2. Definición de dependencias entre paquetes del análisis

Deben definirse dependencias entre los paquetes del análisis si sus
contenidos están relacionados. La dirección de la dependencia debería
ser la misma (navegabilidad) dirección de la relación.
Para hacer más claras las dependencias puede ser útil estratificar el
modelo de análisis haciendo que los paquetes específicos de la relación
queden en una etapa de nivel superior y lo paquetes generales queden
en una capa inferior.
 2.3. Identificación de clases de entidad obvias
Pueden identificarse una lista de clases entidad candidatas basadas en
las clases de dominio o las entidades del negocio. Sin embargo, la
mayoría de las clases se identificarán al crear las realizaciones de caso
de uso. Por lo cual es conveniente con un esgozo inicial de las clases
significativas para la arquitectura.

Plan de
Cuentas Gestión Usuario

Ventas Compras Producto

Ingresos Egresos

2.4. Identificación de requisitos especiales

Un requisito especial es un requisito que aparece durante el análisis y que
es importante anotar de forma que pueda ser tratado adecuadamente en
las subsiguientes actividades de diseño e implementación.

Como ejemplos podemos citar restricciones sobre:

Persistencia Alta, baja, normal

Distribución y concurrencia La concurrencia es importante, ya que en la
concurrencia se deben de juntar todos los datos
y que no exista error donde se puedan perder
los datos.

Características de seguridad
Tolerancia a fallos
Gestión de transacciones
3. Analizar un caso de uso
3.1. Identificación de clases de análisis
La distribución, los datos puedan ser enviando
a varios lugares a la vez todos los datos.
Debe de existir una copia de seguridad de los
datos. Manejo de usuario, backup.
Como se va a usar red la tolerancia a fallos debe
de ser mínima, no puede haber o existir fallas.
La gestión transacciones debe de ser simple y
directa, porque no se pueden perder datos del
sistema contable.
3.2. Descripción de las interacciones entre objetos del análisis
 3.3. Captura de requisitos especiales

Plan de cuentas Nombre, código, tipo

Gestión Nombre de la empresa, fecha
Usuario Nombre, CI, dirección, funciones que desempeña,
pasword, código de usuario
Ventas Nombre de boleta, precio, cantidad, fecha
Compras Precio, cantidad, fecha
Producto Nombre, precio, código, cantidad
Ingreso Nombre de la cuenta, código de cuenta, saldo
Egreso Nombre de la cuenta, código de cuenta, saldo

4. Analizar un paquete

Plan de cuentas: Es un listado que presenta las cuentas necesarias para

registrar los hechos contables; para facilitar el reconocimiento de cada una
de las cuentas, el plan de cuentas sueles ser codificado.

El plan de cuentas se relaciona directamente con el paquete de gestión.

Gestión: Ayuda a la empresa a recabar información, clasificarla, ordenarla y

presentar un informe para mejorar la toma de decisiones, control y
planificación.

El paquete de gestión se relaciona directamente con el plan de cuentas y de

forma indirecta con el paquete de usuario.

Usuario: Un usuario es aquella persona que utiliza un dispositivo y realiza

múltiples operaciones indicando las funciones que desempeña.

El usuario se relaciona con el paquete de gestión y compras.

Ventas: El registro de ventas ayuda a saber qué nivel de ventas se tiene,

esto para poder abastecer el inventario para seguir comercializando los
productos que se ofrece; también obtener la información del precio y cantidad
de cada producto.
 La venta se relaciona con el paquete ingreso.

Compras: Nos permitirá registrar el precio del producto, la cantidad y la fecha

específica de la operación económica, brindando mayor seguridad de la
información.

La compra se relaciona directamente con los egresos e indirectamente con

el paquete de productos.

Producto: A través de esta clase se podrá obtener información detallada del

producto como también sus características y precio.

El producto se relaciona con las compras y ventas.

Ingreso: se podrá almacenar información contable de las ventas realizadas

a Diario, son cuentas que reflejan la entrada u obtención de dinero en la
empresa. El ingreso se relaciona con las ventas realizadas.

Egreso: Es el registro de los gastos que realiza la empresa de manera

detallada. El paquete de egresos se relaciona con las compras que se
realizan.

5. Plan de Cuentas del Mini Mercado “Doña Elvia”

1. ACTIVOS
1.1. ACTIVO CORRIENTE
1.1.1. DISPONIBLE
1.1.1.1. Caja
1.1.1.2. Banco
1.1.2. EXIGIBLE
1.1.2.1. Cuentas por cobrar (clientes)
1.1.2.2. IVA Crédito fiscal
1.1.2.3. Anticipo a Proveedores
1.1.3. BIENES DE CONSUMO
1.1.3.1. Materia prima e insumos
1.1.3.1.1. Abarrotes
1.1.3.1.1.1. Arroz
1.1.3.1.1.2. Fideo
1.1.3.1.1.3. Aceite
 1.1.3.1.2. Panadería y pastelería
1.1.3.1.2.1. Pan casero
1.1.3.1.2.2. Queques
1.1.3.1.3. Carnicería
1.1.3.1.3.1. Carne de res
1.1.3.1.3.2. Embutidos
1.1.3.1.4. Lácteos
1.1.3.1.4.1. Yogurt
1.1.3.1.4.2. Leche
1.1.3.1.5. Bebidas
1.1.3.1.5.1. Agua mineral
1.1.3.1.5.2. Coca - cola
1.1.3.1.6. Licores
1.1.3.1.6.1. Cerveza paceña
1.1.3.1.6.2. Coñac
1.1.3.1.7. Útiles de aseo
1.1.3.1.7.1. Champú
1.1.3.1.7.2. Pasta dental
1.1.3.1.8. Frutas y verduras
1.1.3.1.8.1. Manzana
1.1.3.1.8.2. Zanahoria
1.1.3.1.9. Confitería
1.1.3.1.9.1. Hilos
1.1.3.1.9.2. Botones
1.1.3.1.10. Librería
1.1.3.1.10.1. Cuadernos
1.1.3.1.10.2. Lápices
1.2. ACTIVO NO CORRIENTE
1.2.1. ACTIVO FIJO
1.2.1.1. Vehículo
1.2.1.2. Maquinaria
1.2.1.3. Vitrinas
1.2.1.4. Lector de códigos
1.2.1.5. Caja registradora
1.2.1.6. Equipos de computación
1.2.1.7. Terreno
1.2.1.8. Edificio
2. PASIVO
2.1. PASIVO CORRIENTE
2.1.1. Cuentas por pagar
2.1.2. Cuentas por pagar a proveedores
 2.1.3. Otras cuentas por pagar
3. PATRIMONIO
3.1. Capital social
3.2. Ajuste de capital
4. INGRESO
4.1. Ventas
4.2. Ventas de bienes
5. EGRESO
5.1. COSTO
5.1.1. Costo de inversión
5.1.2. Compras
6. GASTO
6.1. GASTOS ADMINISTRATIVOS
6.1.1. Sueldos y salarios
CAPÍTULO IV

DISEÑO
 1. Introducción
Durante el diseño modelamos el sistema y su arquitectura para que soporte
los requisitos funcionales y no funcionales. Una entrada esencial al diseño
es el modelo de análisis.
El diseño es el centro de atención al final de la fase de elaboración y
comienzo de las interacciones de construcción.

2. Diseño de la Arquitectura
- Subsistemas e interfaces
Los subsistemas constituyen un medio para organizar el modelo de diseño en piezas
manejables. Pueden identificarse inicialmente como forma de dividir el trabajo de
diseño, o bien pueden irse encontrando a medida que el modelo de diseño
evoluciona.
Subsistema de aplicación: son las capas superiores de la aplicación y pueden
derivarse directamente de los paquetes de análisis.

2.1. Pantalla Principal del Sistema

INICIO DE SESIÓN
Se encarga de registrar el nombre y contraseña del contador y el propietario para ingresar
al sistema.
MENÚ PRINCIPAL
Se encarga de dar opciones para ingresar al módulo deseado

VENTAS
Este módulo encarga de registrar todas las ventas del producto detalladamente
USUARIO
El usuario se encarga de registrar los datos personales para ingresar al sistema principal

EGRESOS
Este módulo se encarga de registrar los nombres, códigos y mostrar el saldo
correspondiente

PRODUCTO
Este módulo se encarga de la búsqueda del producto deseado y te da toda la
característica del producto
PLAN DE CUENTAS
Este módulo se encarga de registrar el tipo, nombre y código de cuenta para ingresar a
las cuentas correspondientes

GESTIÓN
Este módulo nos permite observar de manera general la situación económica y financiera
de empresa

COMPRAS
Este módulo se encarga de registrar todas las compras del producto detalladamente
INGRESOS
Este módulo se encarga de registrar los nombres y códigos de la cuenta y el saldo

3. Diseño de un caso de uso

 4. Diseño de una Clase

PLAN DE CUENTAS GESTIÓN USUARIO

Nombre Fecha Nombre
Detalle
Código Código de gestión C.I.
Tipo Registrar Dirección
Registrar Modificar Funciones
Modificar Password
Eliminar Buscar empleados
Crear empleados
Modificar empleados
Eliminar empleados
 VENTAS COMPRAS PRODUCTO
Nombre de la boleta Precio Nombre
Precio Cantidad Precio
Cantidad Precio Código
Fecha Calcular total Cantidad
Calcular total Registrar compra Buscar producto
Ventas diarias Compras diarias Crear producto
Ventas mensuales Compras mensuales Modificar producto
Ingresar ventas Eliminar producto
Actualizar stock

INGRESOS EGRESOS
Nombre de cuenta Nombre de cuenta
Código de cuenta Código de cuenta
Saldo Saldo
Añadir ingresos Añadir egresos
Modificar ingresos Modificar egresos
Registrar ingresos Registrar egresos
 5. Diseño de un subsistema
5.1. Diagrama de Clases

PLAN DE CUENTAS GESTION

Nombre Fecha
Código 1 n Detalle
Tipo 1 1 Código de Gestión
Registrar Registrar
Modificar 1 Modificar
Eliminar
m
m 1

1 n

LIBRO DIARIO LIBRO MAYOR USUARIO

Fecha Fecha Nombre
Detalle n Detalle C.I.
Código de cuenta Código de cuenta Dirección
Nombre de cuenta 1 Nombre de cuenta Funciones
Glosa Saldo Password
1 1
Saldo Registrar Buscar empleados
1
Registrar 1 Modificar Crear empleados
Modificar 1 1 Eliminar Modificar empleados
Eliminar Eliminar empleados
1 1

1 n

INGRESOS EGRESOS
n
Nombre de cuenta Nombre de cuenta
Código de cuenta Código de cuenta
1
Saldo Saldo
Añadir ingresos Añadir egresos
Modificar ingresos Modificar egresos
Registrar ingresos Registrar egresos

1 n 1 n

1 1 1 1
1
VENTAS 1 COMPRAS
1 Nombre de la boleta Precio
1 Precio Cantidad
Cantidad Precio
Fecha Calcular total
Calcular total Registrar compra
Ventas diarias Compras diarias
Ventas mensuales Compras mensuales
Ingresar ventas
1
m
1

PRODUCTO n
n
Nombre
1 Precio 1
Código
Cantidad
Buscar producto
Crear producto
Modificar producto
Eliminar producto
Actualizar stock