[Lux]

[color=#FFFFCC]Bancos

1. Nombre del banco
   
2. Clave del banco
   
3. Comentario

[color=#FFFFCC]Cuentas

1. Clave del banco
   
2. Sucursal
   
3. Clave de la cuenta
   
4. Num chequera
   
5. Titular 1
   
6. Titular 2
   
7. Titular 3
   
8. Fecha de apertura
   
9. Saldo mínimo
   
10. Fecha ultimo balance
    
11. Comentario
    
12. Responsable

[color=#FFFFCC]Movimientos

1. Tipo de movimiento – Amerita una tabla nueva
   
2. Clave de cuenta
   
3. Importe
   
4. Fecha del movimiento
   
5. Consecutivo id para identificación
   
6. Usuario que realizo movimiento
   
7. Comentarios – Puede crecer o ser mínimo

[color=#FFFFCC]Tarjetas

1. Clave cuenta
   
2. Numero plástico
   
3. Fecha de ultimo uso
   
4. Es adicional?
   
5. Titular en plástico

[color=#FFFFCC]Usuarios

1. Nombre
   
2. Puesto
   
3. Clave de acceso
   
4. Alias (similar a Novell, lo veremos en detalle después)
   
5. Comentario
   
6. Fecha de nacimiento
   
7. Nivel de acceso

Cabe destacar que tenemos como prioridad usar RAD, hacer algo rápido, que funcione y sea simple, claro y eficiente. Al hacer la relación anterior surgen otro tipo de detalles que no habíamos considerado, pero suelen ser pocas. En este caso son:

1. Los tipos de movimientos son fijos, deberían estar en tabla aparte
2. No todos los movimientos van a tener comentarios, considerar que puede crecer demasiado y ser motivo de crecimiento inútil de la tabla de movimientos.
3. El control de usuarios puede ser gigantesco, pero no es eso lo que nos interesa. Solo nos interesan ciertos datos.
4. En una empresa chica como esta podemos considerar usuarios con nivel de acceso por persona, y no por puesto. En una organización mayor, lo que tiene sentido es ligar puesto a nivel de acceso.

Para simplificar nuestro trabajo, haremos las pantallas antes de terminar el diseño de la base en sí, y consideraremos el modelo todo el tiempo como un prototipo hasta que quede lista la primera versión.

[color=#FFFFCC]Taller:

Como la mayor parte de los clientes usan escritorio de 800 * 600 a 16 millones de colores, usaremos de entrada un proyecto estándar exe, con un solo formulario, y le pondremos un control Microsoft Tabbed Control, y le pondremos un total de seis tabs, con un máximo de seis por línea. Usando F4 y las propiedades caption, pondremos los títulos a cada tab, de acuerdo a la frecuencia de uso esperada.

1. Movimientos
2. Cuentas
3. Tarjetas
4. Usuarios
5. Bancos
6. Tipos de movimientos.

Por lo general ordenar sobre la base de la frecuencia de uso esperada nos da también el orden de complejidad en programación. Lo que usan menos es lo más fácil.

Nuestra tabla de tipo de movimientos tiene que ser pequeña, y no tendrá mucho movimiento, no cualquiera debe poder cambiarlo, se supone que esto es un pendiente de verificación, y lo vamos a poner de entrada en un menú de pendientes, para que no se nos olvide.
La tabla de tipos de movimientos.

Los tipos de movimientos son obvios, como debe ser después de usar un poco de sentido común.

1. Depósitos en sucursal
2. Depósitos banca electrónica
3. Retiros de sucursal
4. Retiros en caja permanente
5. Compras y consumos en establecimientos
6. Iva a nuestro cargo
7. Intereses a nuestro cargo
8. Comisiones a nuestro cargo
9. Renovación y manejo de cuenta
10. Intereses a nuestro favor
11. Bonificaciones a nuestro favor
12. Retiros banca electrónica

Como ustedes verán no he puesto ordenados los cargos y abonos, sino por el orden en que los usará el usuario, poner al ultimo los depósitos sería un poco más difícil. Generalmente el usuario usa los primeros 5 elementos, y en este caso, se han puesto primero los elementos más usuales.

Sin embargo, es obvio que algunos se suman y otros se restan a nuestro saldo, y como las cuentas de banco son de activo ( ver el correo de contabilidad ), lo normal va a ser que se hagan cargos.

[color=#FFFFCC]Que queremos controlar aquí?

1. Clave del tipo
2. Descripción
3. Comentario
4. Si es de cargo o de abono

Como no sabemos que tipo de manejador de base de datos vamos a usar, vamos a considerar que vamos a usar una tabla de Access, recordarán de correos anteriores que es preferible que el nombre de las tablas sea de ocho caracteres máximo, y los campos de 10 caracteres máximo.

Como parte de RAD, de entrada usaremos solo campos tipo cadena o texto, y haremos los ajustes de tipo sobre la marcha.

Nombre de la tabla :


[color=#FFFFCC]TIPOSMOV

NOMBRE[color=#000000].........TIPO[color=#000000]...........LARGO[color=#000000]..........INDICE[color=#000000]........UNICO[color=#000000]...........NULO
-------------------------------------------------------------------------------------------------------
TM_CVE[color=#000000]..........Carácter[color=#000000].......03[color=#000000].............Sí[color=#000000]............Si[color=#000000]..............No
TM_DESC[color=#000000].........Carácter[color=#000000].......30[color=#000000].............No
TM_NOTA[color=#000000].........Carácter[color=#000000].......60[color=#000000].............No[color=#000000]............No[color=#000000]..............Sí
TM_CARGO[color=#000000]........Carácter[color=#000000].......01[color=#000000].............No

Describe[color=#000000].......De que[color=#000000].........Cuantos[color=#000000]........Vamos a[color=#000000]........Es único o[color=#000000].....Es
el campo[color=#000000].......tipo son[color=#000000].......espacios[color=#000000].......buscar por[color=#000000].....o puede[color=#000000]........obligatorio
[color=#000000]...............los datos?[color=#000000].....va a usar?[color=#000000].....este valor?[color=#000000]....repetirse

Obviamente el valor de TM_CARGO podría ser boolean y TM_CVE podría ser numérico. Sobre la marcha veremos el porqué de este planteamiento. Por cierto, los nombres de los campos indican automáticamente de que tabla son. Por regla general, solo debe usarse un máximo de 3 caracteres antes del guión bajo, si se fijan es mucho más claro TM_CVE Que TIPO_CVE.

Próximo correo, diferencias de ADO y DAO y un poquito de SQL.

-------------------------------
Alfonso Orozco - Marzo 2001