Una explicación a manera de disculpa

Aunque no ha sido mi intención descuidar la lista, han sucedido una serie de detalles fuera de mi control, que me han obligado a hacerlo.

Por un lado, en la empresa que trabajaba desde noviembre, la del viaje a Brasil, estaba demorando los pagos de la nómina, y además cuando vieron el sistema de contabilidad que iba a presentar aquí, mismo que desarrollé hace años para un cliente, me salieron con que era propiedad de la empresa e iba a ser obligación de mi parte usarlo y adaptarlo para uno de sus clientes, aunque yo lo había hecho desde 1995.

Todo el proceso estructurado se fue a la basura, y he decidido a partir de hoy continuar con conciliaciones bancarias, porque puede usar mucho de los principios que vimos antes de contabilidad. Aunque el sistema de contabilidad es perfectamente válido y razonable, no pienso hacerle el trabajo a nadie que me trate de mal modo, sin cortesía, y que además demora los pagos.

Por otra parte los procesos legales que mencione antes, han quedado a medio resolver, solo queda pendiente el del derecho de uso de los programas que realicé en 1996 para las automotrices, y aunque ya probamos el uso sin permiso, y con premeditación y agravantes, aun estoy esperando la sentencia del juicio, misma que debe ser favorable y no pasar de unos tres meses.

Como es natural, el tiempo necesario para dar seguimiento a las diferentes instancias ha sido considerable, pero gracias al movimiento de la empresa de host, www.hostchess.com, puedo tomarme todo con cierta tranquilidad.

Sobre el viaje a Argentina y España, dependen de la terminación de los juicios, ya que por ahora debo estar aquí vigilante de mi \”centímetro cúbico de suerte\”.

Así que en resumen, volveré al tema de las bases de datos y su acceso, pero ahora desde el ejemplo de las conciliaciones bancarias, donde podremos usar lo anterior.

Saludos, y gracias.

Como ustedes recordarán el manejo de las bases de datos debe basarse en la sencillez, si es complicado no funciona o será muy difícil de aplicar o mantener.

Para crear una base de datos es indispensable tener una idea de lo que vamos a hacer, CONFIAR EN NUESTRO CRITERIO, y ser capaces de simplificar el proceso o modelo hasta que quede en una sola página, por lo general, o un máximo de 4 páginas, sin embargo, el 95% de los sistemas deben caber en una sola hoja.

Cada vez que me refiera a un modelo, sin excepción me voy a referir al modelo físico, NO a las relaciones lógicas. Esto es porque un problema de los modelos lógicos es que al poco tiempo se terminan midiendo peras con manzanas, y en un esquema físico resulta mucho más fácil observar los “colores diferentes”, y si se trabaja de manera ordenada, las ventajas del modelo lógico se siguen aplicando.

A partir de hoy usaré bastante seguido el término RAD, Desarrollo rápido de aplicaciones ( rapid applications development ) que es una metodología de trabajo y desarrollo creada por Microsoft, y aplicable sobre todo a su línea NET y VB. Aunque más adelante haremos comentarios sobre RAD, lo que ahora nos interesa es una serie de principios básicos que tienen que ver mucho con la calidad de los programas, su facilidad de uso, y la velocidad de desarrollo, en proyectos de tamaño mediano, aunque es aplicable a procesos chicos y grandes.

[color=#FFFFCC]Principios RAD

1. El programador tiene criterio y responsabilidad. Si hace algo que funciona y se ve bien, se queda.
2. Deben usarse componentes reutilizables, es decir, todo el código debe de ser usable en otros proyectos de ser posible.
3. Los buenos programas usan una sola pantalla de trabajo, y cuando mucho 5 a 10 pantallas o formularios propios. Usar una pantalla MDI con chorro mil ventanitas es molesto para los usuarios, y un infierno para mantener. Es válido usar muchos módulos de código, pero pantallas de trabajo, pocas.
4. El acceso a las bases de datos debe hacerse en una sola función, así si debe cambiarse el modo de acceso o la tecnología, solo debe hacerse modificación en pocos lugares.
5. Los nombres de tablas, campos y registros, deben ser simples, claros y construidos de acuerdo a un esquema predecible.
6. Lo anterior significa cortos, directos y en español. No se vale carta84b.doc por ejemplo.
7. Los programas deben tener mucho sentido común. Es mal programa si se necesita manual para encontrar donde se hace un alta.
8. En un proyecto estándar se usan solo dos bases de datos como mucho. Aquellas que usen mas de tres, deben revisarse prácticamente desde cero.

Una vez que tenemos estos principios básicos, podemos continuar.

La teoría de las conciliaciones bancarias es sencilla. Cuando se realizan operaciones con un banco, cada cierto tiempo este nos entrega cartas de resumen o estados de cuenta de los movimientos más recientes, pero frecuentemente los datos no cuadran, ya sea porque nos cobran de mas, nos pagan intereses, etc.

Una regla práctica a considerar es que cada banco ofrece varios tipos de cuentas, y en ocasiones uno tiene con ellos mas de un servicio contratado.

Otro comentario, es que en la facultad de contabilidad, un maestro nos dio un excelente consejo, que dice “Nunca se debe tener cuentas en solo un banco, o en mas de cuatro”. Esto se debe a fines de control, por un lado, y segundo que si falla el único banco que usamos, que hacemos? Tener cuentas en varios bancos permite procesos alternos.

Planteamiento del problema:

Vamos a suponer que nuestro programa lo van a usar en una empresa de 10 personas, para llevar control de tarjetas de crédito, de débito, de cuentas de cheques, y de inversiones y pagarés bancarios a la vista y a plazo fijo, Una de las tarjetas de crédito es usada por el director, y una adicional por el contador, con un numero de tarjeta diferente, pero es la misma cuenta, y hay tres personas autorizadas a firmar en la chequera principal, pero los cheques siempre los firman dos.

Reto RAD: Tenemos una semana para hacer un programa que funcione y lleve ABC, respaldos, restaurar y reportes básicos.

[color=#FFFFCC]Solución:

1. Empezar a actuar

[color=#FFFFCC]Prediseño:

[color=#FFFFCC]Palabras clave:

1. Tarjetas, cuentas, usuarios, chequera, bancos, salidas de dinero, entradas de dinero.

[color=#FFFFCC]Tablas necesarias:

1. Banco
2. Cuentas
3. Usuarios
4. Tarjetas
5. Movimientos ( entradas y salidas )

Nota: Las chequeras dependen de cuentas de cheques, es decir, no son independientes. Las cuentas tienen una chequera, nunca dos.

[color=#FFFFCC]Organigrama de tablas:

Banco[color=#000000]…[color=#000000]…Cuentas[color=#000000]…<--[color=#000000]...Usuarios
[color=#000000]…|[color=#000000]…………………|
Tarjetas[color=#000000]…….Movimientos

Antes de continuar, vamos a ver que elementos queremos, sugiero ordenar las tablas por orden alfabético.