PROTOTIPO

JP SOLUCIONES (Venta De Compupartes)

‹ El presente prototipo, aplicación en VB.NET, describe el ingreso y mantenimiento de un

programa de ventas para una tienda de hardware.
‹ El diagrama de E-R fue diseñadas en el programa ERwin, a manera de referencia y posible
exportación de las mismas a SQL Server.

‹ Sin embargo, se optó paralelamente por la creación de las tablas y el código de

programación en SQL Server 2008, desde cero. Los pasos más importantes de este proceso
pasarán a ser descritos a continuación.
 CREACIÓN DE LA BD EN SQL SERVER - 2008

‹ Resguardando la consistencia de datos en la ejecución del código:

--====================================
CREANDO LA BASE DE DATOS
--====================================
*/
use master
go
--------------------------------------
if exists (select * from sysdatabases where name='JPSoluciones')
drop database JPSoluciones
go
create database JPSoluciones
go
use JPSoluciones
go

‹ Creación de las tablas:

‹ Se siguen patrones similares, tabla a tabla las restricciones y reglas especiales se
implementarán posteriormente.

--TABLA REGION
---------------
--Almacena los datos las regiones políticas del país
-----------------------------------------------------
if exists (select * from sysobjects where name='Region')
drop table Region
go
create table Region
( id int identity (1,1),
idRegion as RIGHT('00'+CAST(id as varchar(2)),2) persisted not
null,
NomRegion varchar(25) not null,
Detalle varchar(50) )
go

‹ La primera observación es referente al almacenamiento de datos de Clientes. Dicha

información se divide en dos tablas: ClienteH y ClienteM. La primera almacenará los datos
históricos de un cliente, los de referencia fija o más estáticos; la segunda guarda los datos
como tabla de movimientos, cuyas tuplas son más proclives a cambios y serán de hecho las
que se consultarán con frecuencia y se relacionarán con las demás tablas de la BD. Es por
eso que la otra tabla, ClienteH, aparece divorciada adrede del resto de tablas, como
veremos más adelante en el diagrama de entidades.

--TABLA CLIENTEH
if exists (select * from sysobjects where name='Clienteh')
drop table Clienteh
go
create table Clienteh
( id int identity (1,1),
 idCliente as 'CL'+ RIGHT('000'+CAST(id as varchar(4)),4)
persisted not null,
Dni char(8) not null,
Ruc char(11),
Nombres varchar(35) not null,
Apaterno varchar(25) not null,
Amaterno varchar(25) not null,
Sexo char(1) not null,
Fnacim date )
go

--TABLA CLIENTEM
if exists (select * from sysobjects where name='Clientem')
drop table Clientem
go
create table Clientem
( id int identity (1,1),
idCliente as 'CL'+ RIGHT('000'+CAST(id as varchar(4)),4)
persisted not null,
Dni char(8) not null,
Telefono varchar(12),
Email varchar(35),
Direccion varchar(50),
idDistrito varchar(5) )
go

‹ Otro punto en cuestión es el de los IDs o códigos de algunas tablas, que sirven como claves
primarias de las mismas. Las tablas con esta característica cuentan con un campo id entero
incremental, que nos servirá para calcular el ID que será la clave principal. Este campo
calculado se compone de dos letras iniciales, características de la tabla, y un número
consecutivo de cuatro cifras, logrado a partir del ID entero inicial.

id int identity (1,1),

idProveedor as 'PV'+ RIGHT('000'+CAST(id as varchar(4)),4)
persisted not null,

‹ Los primary key se crean posteriormente:

--==================================================
CREANDO LAS RESTRICCIONES PRIMARY KEY
--=================================================
*/

--TABLA REGION
---------------
if exists (select * from sysobjects where name='pk_region')
alter table Region
drop constraint pk_region
go
alter table Region
add constraint pk_region
PRIMARY KEY(idRegion)
go

‹ Igual con los foreign key, procurando asegurar que el eventual borrado o actualización de
filas se realice en cascada para evitar conflictos.
 --==============================================
CREANDO RESTRICCIONES FOREIGN KEY
--==============================================
*/

--TABLA DISTRITO
-----------------
if exists (select * from sysobjects where
name='fk_Distrito_Region')
alter table Distrito
drop constraint fk_Distrito_Region
go
alter table Distrito
add constraint fk_Distrito_Region
FOREIGN KEY(idRegion)
references Region(idRegion)
on delete cascade
on update cascade
go

‹ A continuación, las restricciones más importantes, CHECK y UNIQUE:

‹ Por ejemplo, asegurándonos que el campo Región en la tabla del mismo nombre resulta
ser único
--TABLA REGION
---------------
if exists (select * from sysobjects where
name='uniq_region_nomregion')
alter table Region
drop constraint uniq_region_nomregion
alter table Region
add constraint uniq_region_nomregion
UNIQUE(Nomregion)
go

‹ En la tabla de Cliente nos aseguramos de que el Sexo sea sólo M o F en sus dos variantes:
if exists (select * from sysobjects where name='ch_clienteh_sexo')
alter table Clienteh
drop constraint ch_clienteh_sexo
alter table Clienteh
add constraint ch_clienteh_sexo
CHECK (Sexo like '[mMfF]')
go

‹ Y finalmente, que el tipo de comprobante sólo acepte los ingresos de “Boleta” o “Factura”
alter table Comprobante
add constraint CH_Comprobante_Tipocomp
CHECK(TipoComp in ('Boleta','Factura'))
go

‹ Codificamos a continuación algunos procedimientos que nos servirán en el uso del

programa en VB.NET, cada cual con su propia utilidad. Para explayarnos en ellos, pasemos a
apreciar el funcionamiento del programa.
 APLICACIÓN EN VISUAL STUDIO .NET

‹ Ejecutamos el programa desde la aplicación en cuestión.

‹ Tras una ventana de bienvenida, codificada en el load de la ventana principal (form
Bienvenida, abrimos el menú maestro y desde él podremos acceder a las diferentes
ventanas del programa.
‹ El menú también ofrece facilidades para la navegación por teclado, sugiriendo
combinaciones de teclas con que abrir los formularios que deseemos.
 FORMULARIO VENTAS
TABLAS COMPROBANTE Y DETALLECOMP”

‹ Pasemos a explicar el funcionamiento de uno este formulario a manera de ejemplo:

 Las tablas COMPROBANTE y DETALLECOMP están íntimamente ligadas a nivel de

guardado de datos.
 El registro en ambas tablas se realiza mediante la siguiente secuencia:
o Con cada apertura de alguna ventana de ventas, se ejecuta el procedimiento
“verNuevoCodComprob”. Éste procedimiento devuelve el Código del último
comprobante registrado, más la unidad (Doc último + 1).

create procedure VerNvoComprobante

@idComprobante varchar(6) output
as
begin
 declare @ultid varchar(6) = (select MAX(idComprobante) from
Comprobante)
if @ultid is null
select @idComprobante='CO0001'
else
begin
select @idComprobante='CO' +

right('000'+cast((cast(right(@ultid,4) as int)+1)as varchar),4)

end
end
return
go

o El NroDoc se muestra en un lugar visible de la pantalla, como “Documento

Actual”, aún sin ser almacenado en tabla alguna.
o El botón AGREGAR (agregar venta) de cada categoría, actuará de manera
similar:
 Ejecuta el procedimiento “gDetalleComprobante”.
o Con “gDetalleComprobante” se almacena un nuevo registro en la tabla

(...)
insert into DetalleComp values (@idComprobante,@idprod,1,@costo,@Hora)
(...)

o DETALLECOMP, tanto como en el COMPROBANTE propiamente dicho.

o Las sub-ventas se van agregando en DETALLECOMP una a una, con cada clic en
el botón AGREGAR.
o El método vertotalcomprobante(), que utiliza el procedimiento
“VerCompporCodigo” muestra en el Datagrid correspondiente cada inserción
que se va realizando.
o Al mismo tiempo, el disparador (trigger) “ActTotalComprobante” actualiza en
el COMPROBANTE pertinente el monto Total, sumándole el Subtotal de cada
venta.

create trigger ActTotalComprobante

on DetalleComp
for insert
as
update Comprobante set Total=Total + (select Subtotal from
inserted)
where idcomprobante=(select idcomprobante from
inserted)
go

o El botón TERMINAR hace que un MsgBox muestre en pantalla el Total a pagar

(procedimiento “MostrarTotalComprobante”). Enseguida se cierra la ventana y
por consiguiente el COMPROBANTE, pues la apertura de cualquier otra
ventana generará un Nro nuevo de documento: para el usuario sería imposible
guardar, mediante el programa, ventas posteriores en un COMPROBANTE así
finalizado.
o Si el usuario cerrara el programa sin el botón TERMINAR (por el botón de Salir
o CANCELAR), se deja sin efecto la transacción y por ello los registros
insertados hasta el momento. Se ejecuta el procedimiento “CancelarVentas”.
create procedure CancelarVentas
@idComprobante varchar(6)
as
begin
delete from DetalleComp where idComprobante=@idComprobante
delete from Comprobante where idComprobante=@idComprobante
end
return
go
 SECUENCIA DE ALGUNOS PROCEDIMIENTOS ALMACENADOS

 gDetalleComprobante:
o Recibe:
 idComprobante
 TipoComp
 idCliente
 Fecha date
 idProducto
 Cantidad
 Subtotal
 FechaHora
o Devuelve:
 – –
o Operaciones:
 Verifica si idComprobante existe en COMPROBANTE:
 Si existe:
o Se insertan los datos pertinentes en DETALLECOMP.
 Si no existe:
o Se insertan los datos de nuevo documento en
COMPROBANTE.
o Se insertan los datos pertinentes en DETALLECOMP.

 VerCompporCodigo:
o Recibe:
 idComprobante
o Devuelve:
o Operaciones:

 MostrarTotalComprobante:
o Recibe:
 idComprobante
o Devuelve:
 Total
o Operaciones:

 CancelarVentas:
o Recibe: idComprobante
o Devuelve:
o Operaciones:
 Elimina de DETALLECOMP todos los registros con el idComprobante
ingresado.
 Elimina de la tabla COMPROBANTE el registro con el idComprobante
ingresado.