miércoles, 25 de febrero de 2009

Diagrama E-R 3.100

Sentencias DDL
Script para la creación de la base de datos
-- Database: "InvCyD"
-- DROP DATABASE "InvCyD";
CREATE DATABASE "InvCyD"
WITH OWNER = postgres
ENCODING = 'WIN1252';
Script para la creación de las tablas
Tabla Persona
-- Table: "Persona"
-- DROP TABLE "Persona";
CREATE TABLE "Persona"
(
"IDPersona" character varying(15) NOT NULL,
"Nombre1" character varying(20) NOT NULL,
"Nombre2" character varying(20),
"Apellido1" character varying(20) NOT NULL,
"Apellido2" character varying(20),
"Sexo" character(1) NOT NULL,
"FechaNac" date NOT NULL,
"Direccion" character varying(50),
"Email" character varying(50),
CONSTRAINT "PKPersona" PRIMARY KEY ("IDPersona"),
CONSTRAINT "CHKPersona" CHECK ("Sexo" = 'H'::bpchar OR "Sexo" = 'M'::bpchar)
)
WITH (OIDS=FALSE);
ALTER TABLE "Persona" OWNER TO postgres;
Tabla Empleado
-- Table: "Empleado"
-- DROP TABLE "Empleado";
CREATE TABLE "Empleado"
(
-- Heredado: "IDPersona" character varying(15) NOT NULL,
-- Heredado: "Nombre1" character varying(20) NOT NULL,
-- Heredado: "Nombre2" character varying(20),
-- Heredado: "Apellido1" character varying(20) NOT NULL,
-- Heredado: "Apellido2" character varying(20),
-- Heredado: "Sexo" character(1) NOT NULL,
-- Heredado: "FechaNac" date NOT NULL,
-- Heredado: "Direccion" character varying(50),
-- Heredado: "Email" character varying(50),
"Puesto" character varying(30),
CONSTRAINT "PKEmpleado" PRIMARY KEY ("IDPersona"),
CONSTRAINT "FKEmpleado" FOREIGN KEY ("IDPersona")
REFERENCES "Persona" ("IDPersona") MATCH SIMPLE
ON UPDATE CASCADE ON DELETE SET DEFAULT,
CONSTRAINT "CHKPersona" CHECK ("Sexo" = 'H'::bpchar OR "Sexo" = 'M'::bpchar)
)
INHERITS ("Persona")
WITH (OIDS=FALSE);
ALTER TABLE "Empleado" OWNER TO postgres;


Tabla Cliente
-- Table: "Cliente"

-- DROP TABLE "Cliente";
CREATE TABLE "Cliente"
(
-- Heredado: "IDPersona" character varying(15) NOT NULL,
-- Heredado: "Nombre1" character varying(20) NOT NULL,
-- Heredado: "Nombre2" character varying(20),
-- Heredado: "Apellido1" character varying(20) NOT NULL,
-- Heredado: "Apellido2" character varying(20),
-- Heredado: "Sexo" character(1) NOT NULL,
-- Heredado: "FechaNac" date NOT NULL,
-- Heredado: "Direccion" character varying(50),
-- Heredado: "Email" character varying(50),
"Tipo_Cliente" character varying(30),
CONSTRAINT "PKCliente" PRIMARY KEY ("IDPersona"),
CONSTRAINT "FKCliente" FOREIGN KEY ("IDPersona")
REFERENCES "Persona" ("IDPersona") MATCH SIMPLE
ON UPDATE CASCADE ON DELETE SET DEFAULT,
CONSTRAINT "CHKPersona" CHECK ("Sexo" = 'H'::bpchar OR "Sexo" = 'M'::bpchar)
)
INHERITS ("Persona")
WITH (OIDS=FALSE);
ALTER TABLE "Cliente" OWNER TO postgres;

Tabla Usuario
-- Table: "Usuario"
-- DROP TABLE "Usuario";
CREATE TABLE "Usuario"
(
"IDUsuario" character varying(30) NOT NULL,
"Contrasena" character varying(30) NOT NULL,
"IDEmpleado" character varying(15) NOT NULL,
CONSTRAINT "PKUsuario" PRIMARY KEY ("IDUsuario"),
CONSTRAINT "FKUsuario" FOREIGN KEY ("IDEmpleado")
REFERENCES "Empleado" ("IDPersona") MATCH SIMPLE
ON UPDATE CASCADE ON DELETE SET DEFAULT
)
WITH (OIDS=FALSE);
ALTER TABLE "Usuario" OWNER TO postgres;
Tabla Modulo
-- Table: "Modulo"
-- DROP TABLE "Modulo";
CREATE TABLE "Modulo"
(
"IDModulo" integer NOT NULL,
"Descripcion" character varying(30) NOT NULL,
"AClientes" boolean,
"AEmpleados" boolean,
"AProductos" boolean,
"ABodegas" boolean,
"AUsuarios" boolean,
"AModulos" boolean,
"APedidos" boolean,
"AFacturas" boolean,
"AIngresos" boolean,
"AInventario" boolean,
"RVentas" boolean,
"RClientes" boolean,
"RPedidos" boolean,
CONSTRAINT "PKModulo" PRIMARY KEY ("IDModulo"),
CONSTRAINT "UModulo" UNIQUE ("Descripcion")
)
WITH (OIDS=FALSE);
ALTER TABLE "Modulo" OWNER TO postgres;
Tabla Bodega
-- Table: "Bodega"
-- DROP TABLE "Bodega";
CREATE TABLE "Bodega"
(
"IDBodega" integer NOT NULL,
"Nombre" character varying(30) NOT NULL,
CONSTRAINT "PKBodega" PRIMARY KEY ("IDBodega"),
CONSTRAINT "UBodega" UNIQUE ("Nombre")
)
WITH (OIDS=FALSE);
ALTER TABLE "Bodega" OWNER TO postgres;

Tabla Producto
-- Table: "Producto"
-- DROP TABLE "Producto";

CREATE TABLE "Producto"
(
"IDProducto" integer NOT NULL,
"Nombre" character varying(30) NOT NULL,
"PrecioUnitario" money NOT NULL,
"CostoUnitario" money NOT NULL,
"UnidadMed" character varying(15),
CONSTRAINT "PKProducto" PRIMARY KEY ("IDProducto")
)
WITH (OIDS=FALSE);
ALTER TABLE "Producto" OWNER TO postgres;
Tabla Pedido
-- Table: "Pedido"
-- DROP TABLE "Pedido";
CREATE TABLE "Pedido"
(
"IDPedido" integer NOT NULL,
"FechaPed" date NOT NULL,
"IDEmpleado" character varying(15) NOT NULL,
"IDCliente" character varying(15) NOT NULL,
CONSTRAINT "PKPedido" PRIMARY KEY ("IDPedido"),
CONSTRAINT "FKPedido" FOREIGN KEY ("IDCliente")
REFERENCES "Cliente" ("IDPersona") MATCH SIMPLE
ON UPDATE CASCADE ON DELETE SET DEFAULT,
CONSTRAINT "FKPedido2" FOREIGN KEY ("IDEmpleado")
REFERENCES "Empleado" ("IDPersona") MATCH SIMPLE
ON UPDATE CASCADE ON DELETE SET DEFAULT
)
WITH (OIDS=FALSE);
ALTER TABLE "Pedido" OWNER TO postgres;
Tabla Factura
-- Table: "Factura"
-- DROP TABLE "Factura";
CREATE TABLE "Factura"
(
"IDFactura" integer NOT NULL,
"FechaFactura" date NOT NULL,
"ISV" money,
"Total" money,
"IDEmpleado" character varying(15) NOT NULL,
"IDPedido" integer NOT NULL,
CONSTRAINT "PKFactura" PRIMARY KEY ("IDFactura"),
CONSTRAINT "FKFactura" FOREIGN KEY ("IDEmpleado")
REFERENCES "Empleado" ("IDPersona") MATCH SIMPLE
ON UPDATE CASCADE ON DELETE SET DEFAULT,
CONSTRAINT "FKFactura2" FOREIGN KEY ("IDPedido")
REFERENCES "Pedido" ("IDPedido") MATCH SIMPLE
ON UPDATE CASCADE ON DELETE SET DEFAULT
)
WITH (OIDS=FALSE);
ALTER TABLE "Factura" OWNER TO postgres;
Tabla Ingreso
-- Table: "Ingreso"
-- DROP TABLE "Ingreso";
CREATE TABLE "Ingreso"
(
"IDIngreso" integer NOT NULL,
"FechaIngreso" date NOT NULL,
"Total" money,
"IDEmpleado" character varying(15) NOT NULL,
CONSTRAINT "PKIngreso" PRIMARY KEY ("IDIngreso"),
CONSTRAINT "FKIngreso" FOREIGN KEY ("IDEmpleado")
REFERENCES "Empleado" ("IDPersona") MATCH SIMPLE
ON UPDATE CASCADE ON DELETE SET DEFAULT
)
WITH (OIDS=FALSE);
ALTER TABLE "Ingreso" OWNER TO postgres;
Tabla Inventario
-- Table: "Inventario"
-- DROP TABLE "Inventario";
CREATE TABLE "Inventario"
(
"Correlativo" integer NOT NULL,
"FechaInv" date NOT NULL,
"IDProducto" integer NOT NULL,
"Tipo_Operacion" character varying(15),
"CantIni" integer NOT NULL,
"CantIngresos" integer NOT NULL,
"CantSalidas" integer NOT NULL,
"CantFinal" integer NOT NULL,
"IDIngresos" integer,
"IDPedidos" integer,
"IDBodega" integer NOT NULL,
CONSTRAINT "PKInventario" PRIMARY KEY ("Correlativo", "FechaInv", "IDProducto"),
CONSTRAINT "FKInventario" FOREIGN KEY ("IDBodega")
REFERENCES "Bodega" ("IDBodega") MATCH SIMPLE
ON UPDATE NO ACTION ON DELETE NO ACTION,
CONSTRAINT "FKInventario2" FOREIGN KEY ("IDIngresos")
REFERENCES "Ingreso" ("IDIngreso") MATCH SIMPLE
ON UPDATE CASCADE ON DELETE SET DEFAULT,
CONSTRAINT "FKInventario3" FOREIGN KEY ("IDPedidos")
REFERENCES "Pedido" ("IDPedido") MATCH SIMPLE
ON UPDATE NO ACTION ON DELETE NO ACTION,
CONSTRAINT "FKInventario4" FOREIGN KEY ("IDProducto")
REFERENCES "Producto" ("IDProducto") MATCH SIMPLE
ON UPDATE NO ACTION ON DELETE NO ACTION
)
WITH (OIDS=FALSE);
ALTER TABLE "Inventario" OWNER TO postgres;
Tabla Accesa
-- Table: "Accesa"
-- DROP TABLE "Accesa";
CREATE TABLE "Accesa"
(
"IDUsuario" character varying(30) NOT NULL,
"IDModulo" integer NOT NULL,
CONSTRAINT "PKAccesa" PRIMARY KEY ("IDUsuario", "IDModulo"),
CONSTRAINT "FKAccesa" FOREIGN KEY ("IDUsuario")
REFERENCES "Usuario" ("IDUsuario") MATCH SIMPLE
ON UPDATE NO ACTION ON DELETE NO ACTION,
CONSTRAINT "FKAccesa2" FOREIGN KEY ("IDModulo")
REFERENCES "Modulo" ("IDModulo") MATCH SIMPLE
ON UPDATE NO ACTION ON DELETE NO ACTION
)
WITH (OIDS=FALSE);
ALTER TABLE "Accesa" OWNER TO postgres;
Tabla DetallePedido
-- Table: "DetallePedido"
-- DROP TABLE "DetallePedido";
CREATE TABLE "DetallePedido"
(
"IDPedido" integer NOT NULL,
"Cantidad" integer NOT NULL,
"IDProducto" integer NOT NULL,
CONSTRAINT "PKDetPed" PRIMARY KEY ("IDPedido", "IDProducto"),
CONSTRAINT "FKDetPed" FOREIGN KEY ("IDPedido")
REFERENCES "Pedido" ("IDPedido") MATCH SIMPLE
ON UPDATE NO ACTION ON DELETE NO ACTION,
CONSTRAINT "FKDetPed2" FOREIGN KEY ("IDProducto")
REFERENCES "Producto" ("IDProducto") MATCH SIMPLE
ON UPDATE NO ACTION ON DELETE NO ACTION
)
WITH (OIDS=FALSE);
ALTER TABLE "DetallePedido" OWNER TO postgres;
Tabla DetalleFactura
-- Table: "DetalleFactura"
-- DROP TABLE "DetalleFactura";
CREATE TABLE "DetalleFactura"
(
"IDFactura" integer NOT NULL,
"Cantidad" integer NOT NULL,
"IDProducto" integer NOT NULL,
CONSTRAINT "PKDetFact" PRIMARY KEY ("IDFactura", "IDProducto"),
CONSTRAINT "FKDetFact" FOREIGN KEY ("IDFactura")
REFERENCES "Factura" ("IDFactura") MATCH SIMPLE
ON UPDATE NO ACTION ON DELETE NO ACTION,
CONSTRAINT "FKDetFact2" FOREIGN KEY ("IDProducto")
REFERENCES "Producto" ("IDProducto") MATCH SIMPLE
ON UPDATE NO ACTION ON DELETE NO ACTION
)
WITH (OIDS=FALSE);
ALTER TABLE "DetalleFactura" OWNER TO postgres;
Tabla DetalleIngreso
-- Table: "DetalleIngreso"
-- DROP TABLE "DetalleIngreso";
CREATE TABLE "DetalleIngreso"
(
"IDIngreso" integer NOT NULL,
"IDProducto" integer NOT NULL,
"Cantidad" integer NOT NULL,
CONSTRAINT "PKDetIng" PRIMARY KEY ("IDIngreso", "IDProducto"),
CONSTRAINT "FKDetIng" FOREIGN KEY ("IDIngreso")
REFERENCES "Ingreso" ("IDIngreso") MATCH SIMPLE
ON UPDATE NO ACTION ON DELETE NO ACTION,
CONSTRAINT "FKDetIng2" FOREIGN KEY ("IDProducto")
REFERENCES "Producto" ("IDProducto") MATCH SIMPLE
ON UPDATE NO ACTION ON DELETE NO ACTION
)
WITH (OIDS=FALSE);
ALTER TABLE "DetalleIngreso" OWNER TO postgres;
Tabla Telefonos
-- Table: "Telefonos"
-- DROP TABLE "Telefonos";
CREATE TABLE "Telefonos"
(
"IDPersona" character varying(15) NOT NULL,
"Telefono" character varying(10) NOT NULL,
CONSTRAINT "PKTelefonos" PRIMARY KEY ("IDPersona", "Telefono"),
CONSTRAINT "FKTelefonos" FOREIGN KEY ("IDPersona")
REFERENCES "Persona" ("IDPersona") MATCH SIMPLE
ON UPDATE NO ACTION ON DELETE NO ACTION
)
WITH (OIDS=FALSE);
ALTER TABLE "Telefonos" OWNER TO postgres;

Segunda Entrega de Proyecto

Esquema Relacional

Persona(IDPersona, Nombre1, Nombre2, Apellido1, Apellido2, Sexo, FechaNac, Direccion, Email).

Empleado(IDPersona, Puesto).

Cliente(IDPersona, Tipo_Cliente).

Usuario(IDUsuario, Contrasena, IDEmpleado).

Modulo(IDModulo, Descripcion, AClientes, AEmpleados, AProductos, ABodegas, AUsuarios, AModulos, APedidos, AFacturas, AIngresos, AInventario, RVentas, RClientes, RPedidos).

Bodega(IDBodega, Nombre).

Producto(IDProducto, Nombre, PrecioUnitario, CostoUnitario, UnidadMed).

Pedido(IDPedido, Fecha, IDEmpleado, IDCliente).

Factura(IDFactura, FechaFactura, ISV, Total, IDEmpleado, IDPedido).

Ingreso(IDIngreso, FechaIngreso, Total, IDEmpleado).

Inventario(Correlativo, FechaInv, IDProducto, TipoOperacion, CantIni, CantIngresos, CantSalidas, CantFinal, IDIngresos, IDPedido, IDBodega).

Accesa(IDUsuario, IDModulo).

DetallePedido(IDPedido, Cantidad, IDProducto).

DetalleIngreso(IDIngreso, Cantidad, IDProducto).

DetalleFactura(IDFactura, Cantidad, IDProducto).

Telefonos(IDPersona, Telefono).

martes, 10 de febrero de 2009

jueves, 5 de febrero de 2009

Lista de Entidades en el Sistema

 

Persona: La entidad persona es una entidad de la cual se va a especializar el cliente y el empleado, creamos esta entidad con el fin de no tener dos entidades con muchos de sus atributos similares, esto en el caso de cliente y empleado que de ellos debemos almacenar muchos atributos similares, por eso los especializamos.

Empleado: especialización de persona, para definir a los empleados por medio de sus puestos esta entidad es importante, debido a que necesitamos saber quién es el que hace los pedidos, las facturas o quien ingresa productos al inventario.

Cliente: esta entidad que es una especialización de persona, nos sirve para almacenar información de los clientes, para llevar un control de nuestro clientes, acerca de las facturas que le hacemos y los pedidos pendientes que tenemos con ellos.

Usuario: esta entidad nos sirve para manejar el control de personas que ingresan al sistema, para poder limitar cierta información que solo debe puede acceder por ciertos usuarios.

Modulo: en esta entidad registramos los módulos que puede tener este sistema, ósea que tipos de usuarios acceden a estos y que restricciones o privilegios tienen estos con respecto a la información.

Pedido: es la entidad donde almacenamos los productos que los clientes nos piden, para luego revisarlo en el inventario si está disponible para facturarlo al cliente.

Factura: esta entidad sirve para almacenar las facturas que se hacen a los clientes, donde especificamos los productos que se le facturan, importante y fundamental en el desarrollo del sistema.

Producto: entidad maestra donde almacenamos los detalles del producto, esta entidad es importante porque, nos sirve para definir cada producto que será almacenado en el inventario, y del cual se va a facturar.

Inventario: esta entidad debe ser la principal aunque sea débil, debido a que el sistema se basa en el control de un inventario de productos para facturación, es débil con respecto a producto debido a que no tiene suficientes atributos como para poder formar una clave propia. En esta entidad se almacena una descripción de los productos que ingresan y salen, así como la cantidad de productos disponible en el momento.

Lista de Atributos por Entidad

Persona: IdPersona, Nombre, Apellido, Sexo, Dirección, FechaNac, Email, Teléfonos.

Empleado: IdPersona, Puesto.

Cliente: IdPersona, TipoClient.

Usuario: IdUsuario, Contraseña.

Modulo: IdModulo, Descripción.

Pedido: IdPedido, FechaPed.

Factura: IdFactura, FechaFact.

Producto: IdProducto, Nombre, Precio, UnidadMedida, PrecioCosto.

Inventario: Fecha, Bodega, CantInicial, CantIngresos, CantSalidas, CantidadFinal.

 

Relaciones o Vínculos

Inventario-Producto: esta relación es necesaria debido a que el inventario es débil con respecto a producto, además todo inventario tiene productos, que indican lo que esta disponible.

Empleado-Inventario: esta relación esta creada con el fin de que como un empleado ingresa productos al inventario estos se registren de manera de que sepamos que empleado ingreso dichos productos, y además en que fecha.

Pedido-Inventario: esta relación sirve para revisar si los productos que están en el pedido están disponibles en el inventario, en caso de estar disponibles, estos generarían una factura.

Pedido-Producto: esta relación es el detalle del pedido, para especificar la cantidad de todos los productos que están en el pedido.

Cliente-Pedido: esta relación nos sirve para almacenar información de los clientes con respecto a los pedidos, debido a que el cliente es el que hace los pedidos a un empleado.

Empleado-Pedido: como un pedido debe ser creado por un empleado, con esta relación se registraría el empleado que creó el pedido tomado del cliente.

Factura-Pedido: toda factura se crea o depende de un pedido ya que las facturas no se pueden crear si no existe un pedido para este.

Factura-Producto: este es el detalle de la factura donde almacenamos los detalles de la factura, como la cantidad de cierto producto que facturamos.

Empleado-Factura: toda factura debe ser creada por un empleado que este se registra en la factura, para mantener un control de facturación.

Usuario-Empleado: todo empleado es un usuario del sistema, ósea que un usuario es usado por un empleado para acceder al sistema.

Usuario-Modulo: esta relación sirve para registrar los módulos de los usuarios, con esta relación sabemos que usuarios pueden acceder a ciertos módulos.

 

Restricciones de llave primaria para las entidades

Persona: para esta entidad la clave primaria que le asignamos es el idpersona, debido a que este es único.

Empleado: como esta entidad es una especialización de persona la clave primaria es idpersona.

Cliente: esta entidad tiene como llave primaria a idpersona, debido a que es una especialización de persona.

Usuario: como llave primaria en esta entidad tenemos a idusuario, que es el nombre con el que las personas entrarían al sistema.

Modulo: para cada modulo tenemos un idmodulo que especifica el tipo de modulo.

Pedido: el idpedido es la llave primaria para esta entidad debido a que necesitamos un código o numeración para identificar los pedidos.

Factura: como llave primaria de esta entidad tenemos el idfactura, donde esta sirve para registrar todas las facturas de los clientes, incluso si este compra el mismo día y el mismo producto.

Producto: el atributo clave de esta entidad es el código de producto, idProducto.

Inventario: al ser una entidad débil la clave es la combinación de la clave de producto, debido a que inventario es débil con respecto a este, además la clave la conformaría la fecha del inventario estos juntos para formar la superclave, ósea IdProducto y Fecha.

 

Relaciones de cardinalidad de las relaciones identificadas

Inventario-Producto: la relación de cardinalidad en esta relación es de 1 a N, 1 en el lado de productos y N en el lado de inventario, esto porque la entidad inventario es débil con respecto a producto, además tiene participación total inventario con respecto a producto, esto porque inventario es débil con producto.

Empleado-Inventario: la cardinalidad en esta relación es de N a N, esto porque queremos que esta relación se convierta en tabla para poder registrar los ingresos de productos al inventario que hacen los empleados.

Pedido-Inventario: la cardinalidad en esta relación es de N a N, porque queremos que se convierta en una tabla donde revisemos si los producto que están en el pedido, estén en el inventario disponible, y necesitamos esta tabla para poder acceder al inventario.

Pedido-Producto: una cardinalidad de N a N, porque esta se convierte en una tabla donde almacenamos los detalles del pedido.

Cliente-Pedido: la cardinalidad en esta relación es de 1 a N, donde 1 está en el lado de cliente y N en el lado de pedido, esto porque queremos que en el pedido se almacene el código del cliente que hace el pedido, esta relación tiene una participación total en el lado de pedido, debido a que el pedido no puede existir si un cliente no lo hace.

Empleado-Pedido: esta relación contiene una cardinalidad de 1 a N, 1 en el lado de empleado y N en el lado de pedido, para que en el pedido se almacene el código del empleado que hace el pedido.

Factura-Pedido: la cardinalidad en esta relación es de 1 a 1, con participación total en el lado de factura, esto para que en factura guardemos el idpedido para llevar un control de que las facturas se hagan con respecto a los pedidos previamente hechos.

Factura-Producto: en esta relación la cardinalidad es de N a N, porque esto se convierte en una tabla donde almacenamos el detalle de la factura.

Empleado-Factura: la cardinalidad en esta relación es de 1 a N, con participación total en el lado de factura, que esta tiene el N, y empleado tiene 1, esto para que en la factura se almacene el código del empleado.

Usuario-Empleado: relación con cardinalidad de 1 a 1, con participación total en el lado de usuario, para que en usuario se almacene el código del empleado que tiene ese usuario.

Usuario-Modulo: relación con cardinalidad de N a N, para registrar que usuarios pueden acceder a ciertos módulos, esto es para limitar el acceso a la información por parte de los usuarios.

martes, 3 de febrero de 2009

Diagrama Entidad Relacion

Este es el diagrama E-R , que hemos hecho. existen algunas modificaciones con respecto al primero, pequenos cambios que hemos considerado.

domingo, 25 de enero de 2009

Diseño de Diagrama Entidad Relación.

Cambio de Herramientas de Desarrollo.

Las herramientas a utilizar ahora son java (Netbeans 6.1)  y PostgreSQL. Lo único que cambiamos con respecto a las herramientas iníciales es el lenguaje java por VB.NET, debido a que íbamos a trabajar con la versión express, la cual no permite la conexión con postgreSQL, ni a ningún otro que no sea de Microsoft, solo puede conectarse con Microsoft Access y SQL Server. Por eso decidimos cambiar de lenguaje utilizando el compilador de Netbeans 6.1.

 

Descripción de Los Reportes.

Reporte de Ventas: Este reporte muestra las ventas de alguna fecha en particular o de un margen de tiempo, ejemplo: reporte diario de ventas, semanal, mensual y/o anual.

Reporte de Existencias: En este reporte lo que muestra es la cantidad de productos en existencia en bodega, para las diferentes consultas se puede filtrar por tipo de producto o bodega.

Reporte de Clientes: Este reporte genera una lista con los detalles acerca de los clientes, los pedidos que han hecho y/o las ventas que estos han hecho.

Reporte de Usuarios: Los registros de accesos que los usuarios han hecho, las actualizaciones y demás transacciones que hayan hecho, así como el modulo al que pertenece.

domingo, 18 de enero de 2009

Proyecto para la Realización de un sistema de bases de datos


Descripción del Sistema.


La empresa solicita la creación de un sistema para el manejo de inventario de productos, este sistema inicia desde que un cliente hace un pedido, el cual es tomado en el departamento de ventas, este ultimo lo ingresa al sistema donde en la bodega de productos revisaran en el inventario este pedido, para ver si está disponible. En el caso de que no esté disponible todos los productos que pidió el cliente, bodega manda una nota a ventas con la información de los productos disponible con respecto al pedido del cliente, ventas se comunica con el cliente donde le informa de los productos disponible, si el cliente acepta el pedido que está disponible ventas manda de nuevo el pedido a bodega. Después bodega envía a ventas la confirmación de el pedido entregada, para que ventas genere la factura al cliente.la información de los clientes será almacenada, información de contacto compras etc. Además el sistema debe ser capaz de generar reportes para los diversos usuarios, la cantidad de reportes se explica más adelante…el sistema debe funcionar en red, con las restricciones en cuanto a los accesos. Y debe alimentar el sistema de inventarios a diario, por medio de los usuarios que están en bodega.



Cantidad de Reportes.


La cantidad de reportes necesarios en el sistema son de 6: Reporte diario: este reporte lo pueden hacer los usuarios de ventas, donde les dará información acerca de las ventas diarias. Reporte semanal: este reporte igual que el diario, solo que la información es de la última semana de ventas. Reporte mensual: reporte mensual de ventas. Reporte anual: es el reporte de todas las ventas del año. Reporte en Excel: este reporte sirve para alimentar otro sistema de contabilidad, igual que el reporte diario, solo que este creara un archivo de Excel para luego ser ingresado al otro sistema. Reporte de Inventario disponible: reporte que crean los usuarios de bodega, para saber que productos están disponibles en el momento, y luego este puede ser enviado a ventas.

Alcance del Proyecto.


El proyecto a desarrollar seria realizado en una arquitectura de cliente servidor, debido a que la empresa cuenta con una red de comunicación interna donde el sistema se comunicara entre departamentos, el sistema pretende administrar y actualizar un inventario de productos, que genere reportes de ventas, además que se creen pedidos de clientes, en el caso de que no hubiera esto disponible en bodega, este ultimo mandaría un reporte con los productos disponibles. También tendrá la opción de generar reportes y exportarlos a Excel. Debe además guardar información de los clientes, de sus compras y datos personales.


Observaciones.


La empresa actualmente maneja este inventario en papel y algunos reportes de ventas lo hacen en Excel para llenar el sistema de contabilidad.la empresa posee una red interna lo cual es ideal para desarrollar el sistema con la arquitectura de cliente servidor.

Herramientas de Desarrollo (Tecnología).

Las herramientas de desarrollo para la creación de este sistema son: Visual Basic.Net 2005 express edition, como lenguaje y compilador para la creación del sistema, Postgresql, como manejador de bases de datos, además de otras herramientas para el manejo de reportes. La elección de estas herramientas de desarrollo se deben a que el proyecto debe trabajarse con productos “open source”, para que la empresa no incurra en gastos de licencia por software.