[color=#FFFFCC]Mas de Principios RAD

En ocasiones anteriores hemos mencionado algunas cosas sobre RAD (diseño rápido de aplicaciones). Sin embargo, hace un mes mas o menos me pasó algo curioso, me contrató una empresa para hacer un trabajo free-lance referente precisamente a conciliaciones bancarias en una serie de programas realizados en Visual Basic 4.0 a 16 bits, utilizando el SDE, que viene siendo una especie de sistema para cambiar Clipper a Windows, pero menos logrado que Visual Objects o que el mismo Five Win.

Creo que es importante mencionar algunas cosas que me di cuenta que para mi eran obvias, pero nunca las había puesto por escrito, y permitirán entender mejor las lecciones que siguen; estoy trabajando en el motor de ayuda para que lo puedan consultar fuera de linea.

1. Debe tratar de tenerse un máximo de diez formularios en todo momento; en raras excepciones 20. Los que trabajaban conmigo en Nieto recordarán que el sistema de Visual que hice para todos los sistemas era de un solo formulario por programa, y el nuevo suministros era de mas de 30. Ustedes saben lo que provocaba en facilidad de uso y control de versiones.
2. No usar controles ajenos a Microsoft en la medida de lo posible, por muy bonitos que sean. Evitan reusar el código, y posiblemente hay algo mas moderno y mejor de Microsoft. Citando otra vez a Nieto, recuerden el problema de los dirvers de Merant para accesar DBFs en lugar de Utilizar ADO.
3. En la medida de lo posible, traten de liberar muchos cambios chicos seguidos que un cambio grande con todos; la curva de aprendizaje del usuario es mejor, y además permite corregir errores que no nos hubieramos dado cuenta.
4. En el desarrollo rápido de aplicaciones, debe tratar de burocratizarse lo menos posible el diseño. En muchos lugares el analista es el jefe del programador, o es un analista diferente al que hace el código, pero … es tremendamente frustrante, y tonto encontrar al 80% del trabajo un error garrafal de diseño que uno tiene que arreglar rehaciendo todo de cero.
5. Si tienen un empleado o usuario Beta, o documentan código para otro uso, traten de comentar el código; me refiero a No decir : Esto simplifica el código, sino a decir que cambia de una versión a otra.
6. En la medida de lo posible, deben tener una representación del modelo físico en lugar del modelo lógico; el modelo físico es mucho menos suceptible a confundir procesos con personas. En el modelo lógico pueden encontrar el proceso Usuarios, cuando este es una persona.

[color=#000000]………6a) Usando el modelo físico, si ven facturas lo mas probable es que se refieran a facturas, pero en un modelo lógico se pueden encontrar con que facturas se refiere a entradas de cuentas por pagar o por cobrar, y nada que ver con facturas.

1. 7 Como regla general, si una Tabla tiene menos de 100 registros, NO NECESITA INDICES.
2. 8 El número de indices debe de ser razonable. Alguno de ustedes recuerda aquellos programas originales de clipper, o el Sae de ASPEL que tenían indices hasta en la sopa? He manejado bases de datos de 700 megas con 4 indices, pero he visto sistemas con archivos de 10 registros y siete indices, y programadores que se quejan de que con Clipper/foxpro es dificil abrir mas de 15 indices a la vez.(¿?)
3. 9 Los procesos ABC deben estar en una sola pantalla del mismo catálogo. Los cambios y altas son muy parecidos, no tiene caso tenerlos en otra.
4. 10 Los reportes de preferencia deben estar en un archivo aparte TODOS; esto facilita usar un solo formulario de impresion de reportes, o hacer cambios rapidos a todos los reportes.
5. 11 Las pantallas para fijar acceso deben ser congruentes. Tener 10 pantallas para pedir diferentes tipos de acceso podría hacerse con una forma general bien hecha.
6. 12 Puede usarse una función global de contraseñas; para solicitar en diferentes lugares del programa, en lugar de tener tres formularios diferentes con distinto texto y contraseña Hard Coded.

Ahora les voy a describir el sistema principal de esa empresa. Era un equivalente a SAE, programa administrativo de control de chequeras, producción, bancos, insumos , cuentas por pagar y cobrar, busqueda de clientes , proveedores , etc etc etc.

Un total de 220 formularios MAS archivos FRX, haciendo una relación de que era que, resultó que 175 correspondían a busquedas, grids y reportes de ABC, que se podían reducir a 65. Además manejaban reportes casi idénticos para cuentas por cobrar y por pagar, pero en diferentes formularios. Y por ultimo… tenian que correr en maquinas con 256 MB de ram por la memoria disponible; programados por Accesos a funciones SDE y algo de RDO. ( esto lo vi en el año 2000 pero seguro que hoy por hoy hay programas equivalentes)

Y lo peor es que este tipo de programas no son nada infrecuentes. Como dato general, teniendo la estructura de base de datos, la conciliación bancaria quedó en dos tardes de trabajo, me embolsé 400 dolares, y les presenté una propuesta para pasar todo a ADO por 1000 dolares con una entrega a un mes.

El estimado que tengo es que ese sistema se puede hacer en 30 formularios, y eso porque controla una cantidad de procesos que tiene que ver con barcos y bodegas. Que creen que sea mas facil y rápido, controlar 30 formularios o 220 ?

Algo que debemos considerar siempre es la posibilidad de que se vaya la luz a media operación, asi que un sistema bien diseñado debe tener el menor numero posible de tablas y bases abiertas, o les pasa lo que sucede con los tristemente célebres programas de ASPEL, COI, NOI, y SAE. A los que conocen mi trabajo recordarán que cuando se va la luz los sistemas se recuperan de manera transparente.

Para poder conseguir esto, lo mejor es abrir y cerrar las bases y/o tablas cada operación excepto en procesos intensos, y rara vez abrir a la vez dos tablas. Claro que ayuda tener no breaks fiables en la medida de lo posible.

Sin embargo, eso está fuera del alcance de este tema, aunque mas adelante lo veremos PARCIALMENTE cuando veamos ADO.

Antes de codificar, vamos a ver a grandes rasgos que pasa cuando alguien da un alta de datos en una tabla, DE LO QUE SEA:

[color=#FFFFCC]PASOS PARA DAR UN ALTA

[color=#000000]….1. Deshabilitar las opciones de altas, bajas y cambios en los menús para evitar problemas por doble click. Habilitar opciones de cancelar y guardar cambios.
[color=#000000]….2. Revisar si ya existe el dato que queremos dar en esta tabla.
[color=#000000]….3. Si existe

1. Avisar y restablecer botones
2. Cancelar el proceso

[color=#000000]….4. Verificamos que existan los datos obligatorios, TODOS.
[color=#000000]….5. Si faltan

1. Avisar
2. Llevar a donde falta el dato
3. Cancelar el proceso

[color=#000000]….6. Revisar si hay datos duplicados que no deban serlo ( que en la columna unico de nuestra tabla tengan si )

1. Si hay avisar, llevar, restablecer botones y cancelar proceso

[color=#000000]….7. Si todo es correcto, guardar. ( Si algo falla preferentemente interceptar )
[color=#000000]….8. Restablecer botones y refrescar pantalla

[color=#FFFFCC]PASOS PARA DAR UNA BAJA

[color=#000000]….1. Deshabilitar las opciones de altas, bajas y cambios en los menús para evitar problemas por doble click rapido.
[color=#000000]….2. Revisar si el dato que queremos ya esta seleccionado
[color=#000000]….3. Si no

1. Pedir que se seleccione
2. Restablecer botones
3. Cancelar el proceso

[color=#000000]….4. Verificamos si esta ligado a otra tabla, si es así, avisamos que no se puede borrar (no podemos borrar un banco si tiene cuentas, por ejemplo)
[color=#000000]….5. Continuamos SOLO si ya no hay datos ligados
[color=#000000]….6. Si procede lo demas, preguntamos si queremos borrar, dando por default no.
[color=#000000]….7. Si deciden borrar, borrar
[color=#000000]….8. Restablecer botones y refrescar pantalla

Para hacer esto es necesario tratar de convertir todo a código. Es importante mencionar que no todos los pasos se hacen con el mismo botón en altas, solo el primer boton corresponde a altas, y todo lo demas al boton de guardar cambios.

Si se fijan todos los pasos anteriores son elementales. Vamos a referirnos ahora a el código de tiposmovimentos, específicamente de sus botones, lo que nos lleva al evento click de cmdtiposmov.

Nota: Cuando Comenté que se usaran las propiedades index, la finalidad es simplificar la programación. Esto se debe a que si no manejamos un arreglo de botones , tendriamos seis eventos de controles DIFERENTES, y además de tener que repetir código, sería dificil de mantener. De esta manera usaremos un solo procedimiento, para altas, bajas y cambios por cada tabla.

Veremos un ejemplo, que en lo personal es mi base para la mayoría de las veces, porque con hacer unas cuantas modificaciones, terminamos un módulo ABC completo en cuestión de minutos. A varios que me conocen, les consta que en una hora puedo sacar 6 o 7 módulos completos con reportes, aunque no se suele necesitar esa velocidad.

Después de ver el ejemplo veremos varios de esos procesos obvios, son los que tienen un link dentro del documento.

Vean este ejemplo código de un programa de productos, noten que hay procesos obvios por el nombre (con un link a donde está el código) pero que no son ordenes validas, por ejemplo, resaltacontrol. El ejemplo incluye también el manejo de cambios pero eso lo veremos en tres correos o mas junto con las ordenes que faltan, por ejemplo, la explicación de que es DataClass. Si Usan ahora es bajo su propio riesgo.

NOTA: Las líneas que empiezan con // deben ir al final de la línea anterior. Mas adelante subiré el c&oacutedigo en el proyecto, pero necesito que lo vean ahora por referencia.

[code]Private Sub cmdProd_Click(Index As Integer)
Dim strprov As String
Dim strsubc As String
cmdProd(Index).Enabled = False
Select Case Index

[color=”#FFFFCC”]Case 0: ‘ altas

‘ tomamos proveedor
strprov = lstProv.List(lstProv.ListIndex)
If strprov = “” Then

Antes de proseguir, voy a pedir a los que no han leído los correos anteriores, que vean las páginas

Acceso a Datos 03: Bases, Formatos y Motores

datos03 que contiene las diferencias entre ADO y DAO, y

Acceso a Datos 06: Acceso a campos y ABC DAO Simple

datos06.htm que trae ejemplos de cómo accesamos a los datos en DAO.

Lo que sigue va a suponer que ya lo leyeron. A grandes rasgos DAO era una forma de accesar datos que diseñó Microsoft, que evolucionó después en ADO.

Tipo de Acceso: [color=#FFFFCC]DAO

[color=#FFFFCC]Ventajas:

1. Sistema de búsqueda muy robusto
2. Permite modificar tablas dinámicamente

[color=#FFFFCC]Desventajas:

1. Lentitud relativa

Tipo de Acceso: [color=#FFFFCC]ADO

[color=#FFFFCC]Ventajas:

1. Rapidez
2. Muy portable

[color=#FFFFCC]Desventajas:

1. Deben seleccionarse los drivers con cuidado
2. No permite modificar dinámicamente tablas SQL SERVER (con ADOX si es posible)
3. Sistema de búsqueda No SQL menos poderoso.
4. Mucha funcionalidad extra que no se necesita ( objetos stream y record )

Sin embargo, aunque ADO y DAO son muy parecidos, surge mucho el problema de elegir cual es mejor. La respuesta es simple. ADO es mejor, y si necesitamos por algo en especial las ventajas de DAO, podemos usar los dos en un solo sistema, en la actualidad lo normal es usar consultas SQL desde código Visual Basic para suplir las desventajas de ADO en cuanto a motor.

Técnicamente es posible hacer un programa DAO estructurado de tal manera que podamos hacerlo ADO sin esfuerzo. Lo veremos ya que programaremos en DAO, y finalmente haremos ajustes que realicen el cambio. Esto es característico de los buenos programadores. No Necesito decir nombres, pero todos conocemos a programadores que se tardan semanas, a veces meses y años, en cambiar sus sistemas en metodologías de acceso, simplemente porque no están bien estructurados. En otro correo hablábamos de los programas ABC, es decir, los procesos de altas, bajas y cambios de todos los módulos de un proceso determinado. En el correo 06, vimos que era posible accesar a los datos a través de un recordset, o conjunto de resultados, que se transformaban, ordenaban y modificaban en base a una sola cadena SQL. Aunque más adelante veremos con mas detalle SQL, vamos a ver muy rápidamente lo que es la sintaxis de la apertura de recordsets.

1. Debe usarse en DAO un openrecordset.
2. Toda consulta de registros empieza con un “select”, seguido por el nombre del campo o campos a consultar, terminando con una orden from que va a decir de donde es la tabla a usar. El orden de los campos en la declaración, será el orden en los resultados. Puede sustiuirse el nombre de los campos por un asterisco, pero esto llama todos los campos, no solo los solicitados.

1. Select NOMBRE,DIRECCION from ALUMNOS
2. Select DIRECCION,EDAD from ALUMNOS

1. Podemos filtrar con la cláusula where

1. Select NOMBRE,TELEFONO from ALUMNOS where TELEFONO=’5678-1234’
2. Select TELEFONO,EDAD from ALUMNOS where EDAD > 18

1. Y podemos ordenar en base a una cláusula order by.

1. Select NOMBRE,APELLIDO from ALUMNOS order by APELLIDO
2. Select * from ALUMNOS where EDAD <18 order by EDAD

Lo interesante es que el secreto de SQL es mantener las ordenes sencillas, no complicadas, y sobre todo evitar usar el asterisco en lugar del nombre de los campos. Esto se debe a que en una tabla con muchos campos, es más eficiente cargar solo los necesarios y usar asterisco los carga todos.

Una vez que sabemos que consultar, tenemos que saber como revisar si hay o no resultados a nuestra pregunta. ADO y DAO nos ofrecen dos métodos, uno usando la palabra clave nomatch que no entra en el espíritu de SQL, y la orden según SQL.

Vamos a suponer que pedimos los alumnos mayores a 18 años en una escuela primaria. Casi seguramente no hay resultados, no?

Un ejemplo de código sería:

[code]Dim db as DAO.database
Dim rs as DAO.Recordset
Set db= OpenDatabase(“alumnos.mdb”) ‘ esto abre la base de datos en Access
Set RS= db.openrecordset(“Select * from ALUMNOS where EDAD <18 order by EDAD”) ‘ abre
With rs

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.

Antes que empiecen a pensar otra cosa, les recuerdo que vamos por PASOS, mas adelante veremos ADO y bases relacionales, pero creo que aquí viene información interesante para todos.

Para los que no recuerden las diferencias básicas, habíamos dicho antes que DAO era bueno para labores en un solo lugar, su principal ventaja es ser fácil de entender, pero si hay una maquina fuera, por ejemplo, en otra ciudad, es un poco lento de ejecución.

Si bien originalmente DAO era rápido, le faltaba cierta conectividad. En su versión original, nosotros usábamos una propiedad llamada Fields para referirnos al contenido de los datos. En unos dias veremos como funcionaba esa conectividad.

Pongamos como ejemplo la tabla CUENTA.

Habíamos dicho que CUENTA tenia los siguientes campos:

CTA_NUM
CTA_NOMBRE
CTA_TIPO
CTA_DESCRIP
Como pueden ver, todos empiezan con CTA, lo que nos indica fácilmente que todos son propiedades de un mismo conjunto.

Si bien nosotros podemos Abrir la tabla de diversos modos según si usamos DAO, ADO o lo que sea, siempre hay tres formas de referirnos a CTA_NUM, para leer o escribir los datos:

[color=#00FF00]Lectura Tradicional

La primera forma y mas utilizada es :

Para leer
Valor= Cuenta!CTA_NUM

Para Escribir:
Cuenta!CTA_NUM = Valor

Cual es su problema?

En una sola llamada ( un solo campo ) no tiene gran problema, pero si estamos leyendo Dos o mas campos, si.

Ejemplo:
Valor= Cuenta!CTA_NUM
Valor2= Cuenta!CTA_NOMBRE
Pues muy simple, se carga dos VECES Cuenta!, esto significa que dos o mas veces se carga la tabla o su estructura, cuando una sola puede manejarse con otro de los dos métodos.

Otro problema es la dificultad del uso de arreglos.

[color=#00FF00]Lectura ORDINAL (depende del orden)

Para leer
Valor= Cuenta.Fields(0) ‘ nos regresa CTA_NUM,por ser el primer campo

Para Escribir:
Cuenta.fields(0) = Valor
Problema:

Pues que resulta muy difícil de mantener. A lo mejor en ocho días no nos acordamos que el campo CUENTA.Fields(3) era igual a cuenta!Descrip

No tiene el problema de cargar dos veces, porque puede usarse un bucle with de este modo:

[code]with cuenta

Lo que voy a explicar a continuación es un método similar a lo que utiliza Elías Lara Flores, según se enseñaba hace 10 años; no es necesariamente una información que ponen como buena en un examen, pero lo importante es la idea general, por ahora.

Cualquier duda estoy a su disposición, pero la idea está expresada claramente y de manera correcta.

Recuerden que en el próximo correo regresamos a la programación.

[color=#00FF00]Origen:

La contabilidad surge de la necesidad de las personas de llevar un control de bienes propios o ajenos, de la necesidad de llevar una “cuenta”, ya sea de cuanto dinero se debe, o de cuanto dinero se ganó. Con el paso del tiempo se usaron diversos sistemas para contar, donde se manejaba una relación separada, una cuenta, para cada tipo de cosas o de usuario, pero era muy difícil realizar comparaciones en términos aceptables. Por ejemplo, en Egipto se usaba en el siglo 1 una moneda que eran los talentos, y en Roma se usaban los denarios entre otras.

Sin embargo, todas las anotaciones no siempre se hacían en la misma moneda, por ejemplo, una persona podía anotar en una relación de bienes ocho vacas, y luego sumarle una casa o tres gallinas. A mediados del siglo 15, un monje franciscano , Fray Luca Paccioli, fue encargado por el superior de la orden religiosa de llevar a cabo un recuento de los bienes de la misma a nivel mundial.

Uno de los detalles que notó el padre, era que cada monasterio llevaba varias relaciones, o cuentas, y que a la hora de hacer comparaciones, resultaba bastante difícil. Y como algunos llevaban cientos de cuentas, el realizó lo que algunos llaman el esquema de cuentas y subcuentas, aunque es mas conocido por el famoso concepto de la “partida doble”, que dice, a todo cargo corresponde un abono.

De manera adicional, es el primero que se dio cuenta de la necesidad de una técnica que permitiera registrar, clasificar y resumir las actividades de una persona o negocio.

[color=#00FF00]Definición:

Así que llegamos a la definición de Contabilidad: Es una técnica que se ocupa de registrar clasificar y resumir las operaciones [mercantiles] de un negocio.

Sus objetivos son:

Procesar información de manera razonada y resumida
Con procedimientos preestablecidos y uniformes
Facilitar la consulta de resultados necesarios en planificación y toma de decisiones

[color=#00FF00]Subtipos

Algunas personas hacen la distinción entres los contadores públicos y los privados, o entre los contadores y los tenedores de libros.

Los tenedores y los contadores privados, son personas que están entrenados en los procedimientos de registro y resumen de operaciones.

Se dice normalmente que la teneduría se encarga de Registrar y resumir, y la contabilidad de analizar y comparar, pero realmente depende de la persona. Puede haber un contador privado o tenedor que incluso de seguimiento al cumplimiento de lo programado, por lo que la contabilidad en sí es solo el registro, y mas específicamente la Teneduría es el proceso de registro en base a un procedimiento establecido en base a principios contables generalmente aceptados.

Lo que las personas hagan con la información es otra cosa, pero no es contabilidad sino toma de decisiones.

[color=#00FF00]Los Principios contables

Hay ciertos principios contables que cambian de tiempo en tiempo, pero el conjunto es tradicionalmente el mismo en todos los países. Si bien el IVA es un impuesto en cada país, cada país puede manejar varias tasas, cada principio puede ser de forma o de interpretación.

Los principios de forma son los métodos que debe usarse al registrar: Ejemplo, la partida doble. Y transgredirlo puede causar prisión. Son casi siempre internacionales.

Los principios de interpretación solo ameritan sanción menor, y quedan a elección de la empresa cuando hay varias alternativas legales. Por ejemplo, existen dos sistemas de depreciación, depreciación acelerada y normal.

[color=#00FF00]Los Procedimientos contables

Son los principios de forma.

La idea básica se trata que todos los bienes tienen un dueño o un conjunto de dueños. Si el bien es nuestro, es un bien propio, y si no, se lo debemos a alguien.

En términos de contabilidad, los bienes se dividen en tres grandes tipos:

Activo: La suma de todos los bienes que están a nuestro cuidado. (cuentas de banco, efectivo, etc)
Pasivo: La suma de todo lo que debemos (deudas)
Capital: Aquellos bienes sobre los que solo nosotros tenemos derechos. (reservas de dinero para casarse por ejemplo)
Así que, el Activo son los bienes, y las deudas son llamadas pasivos.

Y llegamos a la formula Básica de la contabilidad, la partida doble. “A todo cargo corresponde un abono”. Esto se explica fácilmente con esta formula

A= ACTIVO

P= PASIVO

C= CAPITAL

A= P + C ( ACTIVO es igual a PASIVO Mas Capital ).

Y la idea es esta. Si entra dinero, debe entrar por un concepto, y si sale también. La partida doble consiste en que cada movimiento debe verse reflejado en su contrario, es decir, si entran 100 pesos que nos prestaron, 100 pesos sube el activo, y 100 pesos el pasivo, por lo que quedan iguales.

Ese registro se hace en un libro al que llamamos LIBRO DIARIO.

Vamos a ver una primer borrador de libro diario:

[code]CTA

Nombre Cuenta

Cargo

Abono

101

Caja

100

203

En el correo anterior comentábamos que era necesario crear una Base de Datos para trabajar, y que nuestro proyecto de libro diario de contabilidad necesitaba Tres Tablas.

En el próximo correo definiremos lo que debe hacer el programa, y veremos nociones sencillas de Contabilidad, asi que la estructura de las tablas se explicará después.

Por simplicidad usaremos tablas de Access 97, en un formato muy simplificado. Estoy consiciente que hay un asistente para “cuentas” en Access y los contadores saben que esa definición de campos no funciona.

Para crear una tabla de Access es posible crearla de cuatro modos diferentes:

1 Uno, por código ( que el programa la cree por si mismo )
2 Por el asistente ( que es un soberano relajo )
3 Realizando una edición manual.
4 Importando por otro metodo
Si no saben crear la tabla, no se preocupen, en el siguiente correo viene un link de donde la pueden bajar.

ATENCIÓN: [color=#00FF00]Es importante hacer notar que el nombre de los campos y de las tablas está en mayúsculas. Tiene su razón de ser; primero por legibilidad de código, y segundo, porque si estamos haciendo programación para SQL Server, podemos tener serios problemas al cambiar de version de 6.5 a 7.0. Aunque es posible crear campos mas largos en cuanto a Nombre, suelen ser mas confusos que nombres cortos de 10 caracteres MAXIMO, así que todos los ejemplos usarán nombres de campos de 10 caracteres, y las bases maximo de 8 caracteres mas extensión. Las Tablas DBF DEBEN tener los campos en mayúsculas para trabajar con Clipper, asi que es otra razón mas para usarlas.

Son tres las Tablas que vamos a crear en nuestra base de datos. La Base de datos se llamará CONTABIL.MDB , noten que el nombre es muy claro y que no mide 10 caracteres. Las tres Tablas se llaman CUENTA, MOVIM, y REFER, que contienen información de la cuenta, de movimientos y de referencia.

Por simplicidad pondré todos los campos como tipo TEXTO. (entrar en análisis de tamaño de campos numéricosen cada soporte fisico o tipo de base de datos sale del alcance del tema)

CUENTA
[code]NOMBRE CAMPO

La vez anterior mencionabamos que necesitamos controlar los datos para hacer Altas, Bajas o Cambios, y en alguna ocasión sacar reportes y respaldos.

Pero lo mas importante es guardar los datos. No podemos dar de alta diariamente miles de clientes cada dia los mismos, ni sería lógico capturar a diario nuestra agenda. Entonces, los datos se guardan en un dispositivo físico, como serían los diskettes, discos duros, etc.

Hay términos que suenan un poco raro, pero vamos a tratar de irlos explicando con calma, aunque quizá no de la manera mas exacta posible.

Primero, una [color=#00FF00]PLATAFORMA es una computadora en la cual corre un sistema operativo. Por ejemplo, las PC son una plataforma, pero las MAC, INDY también. No hay que confundir sistema operativo con Plataforma.

Los [color=#00FF00]Sistemas Operativos son programas que GUARDAN los datos en un dispositivo físico. Sean los datos fotos , imagenes o lo que sea. Ejemplos, Windows 95 y 98, DOS, NT, Linux, etc.

Por razones prácticas, ya que hemos decidido hablar de VB, siempre nos referiremos a la Plataforma PC y sistemas Operativos Windows 95, 98 o NT (a estas versiones las llamaremos Windows de manera Genérica, ignorando temporalmente win 3.1).

Dentro de Windows existen muchos programas, pero para que ellos puedan compartir información, es necesario que hablen un mismo idioma, para fines prácticos un mismo tipo de archivo, aunque pueden usarlo con métodos diferentes.

Cada uno de estos métodos es llamado por algunos tecnologías y por algunos Motor de base de datos. Siempre que usemos el término [color=#00FF00]MOTOR Nos referiremos a la tecnología que usamos en nuestros programas para acceder a los datos.

Para explicar que es una tabla y que es una base de datos, haremos un ejemplo que irá evolucionando conforme avencemos, y será un ejemplo de un libro diario de contabilidad.

Los datos que queremos almacenar en este caso son de tres Grupos: Cuentas ( con número, nombre y descripción ). Movimientos ( entre las cuentas, requerimos saber si se carga o abona, y número de la cuenta). Por ultimo, necesitamos un tercer grupo que sea comentarios sobre los movimientos, y que incluya la fecha.

Entonces tenemos tres grupos, que son: Cuentas, Movimientos y referencia. Cada grupo es algo aparte, y lo llamaremos [color=#00FF00]TABLA, y las tablas del programa actual en conjunto forman una [color=#00FF00]Base de datos. En teoría cualquier programa que no interactue con otros, solo necesita una base de datos, aunque esté formada por varias tablas.

Por ejemplo, en el caso de una agenda de telefonos, se usaría una sola tabla, que a lo mejor es la única de la base de datos.

Para poder usar los datos, sea el motor que sea, tenemos que pasarlos a un [color=#00FF00]Soporte físico o Formato de archivo, popularizado por un “programa padre”, que es llamado por algunos “tipo de soporte”. Los archivos básicos son de tipo DBF ( Formato dBase III ), MDB ( Access 97 y otras ), y por ultimo, los llamados SQL ( usados por SQL Server, Oracle, Informix, etc ). Todos estos tipos de archivos pueden ser usados por VB, definiendo la tecnología dentro del programa. A grandes rasgos estas son las características de los formatos de archivo y de los motores de bases de datos:

[color=#00FF00]dBASE III

Suele ser lo mejor para proyectos pequeños. Cada archivo es una tabla, y el directorio donde está los archivos es la Base de datos. Las tablas Pueden crearse desde código. En lo personal las recomiendo también para proyectos medianos de carga intensiva de red, o que usen programas en MSDOS ( complementa a Clipper si esta bien diseñado)

Extensión DBF
Programa Clipper
DBase III Plus
Motor datos DAO (recomiendo no usar ODBC, ADO ni RDO, pero es posible)

[color=#00FF00]Access

A menos que sea indispensable, usar siempre el formato Access 97 (predeterminado) porque pueden crearse problemas si el usuario no tiene la misma versión. Guarda todas las tablas en el mismo archivo, y ese archivo es llamado la Base de datos.

[color=#00FF00]MUY INESTABLE Y PROBLEMATICO en procesos con carga mediana de red ( bases de datos de 10 a 100 mb o mas de 5 usuarios REALES simultáneos).
Extensión MDB
Programa Visual Basic,
Access 95,97 y 2000
Motor datos DAO, ODBC, ADO, RDO (recomiendo solo DAO o ADO)

[color=#00FF00]MSSQL

En este formato todos los datos se guardan en un servidor y no es posible accesarlos por sistema operativo. Ridiculo usarlo en proyectos medianos o chicos si el cliente no tiene el programa \”Servidor\”, que en promedio vale mil dolares por cinco usuarios.

Extensión N/A
Programa Sql Server 6.5, 7.0, etc.
Motor datos DAO, ODBC ,RDO y ADO

[color=#00FF00]Tecnologías de Acceso a la base de datos
[color=#00FF00]DAO Muy sencillo, fácil de usar y práctico; para proyectos chicos a medianos. Espera que usemos acceso local, y usar acceso remoto es muy complicado. Multiusuario, y soporta Bases ISAM
[color=#00FF00]JET Es un subconjunto de DAO, que por default usa a Access. Por cierto, suele ser mejor olvidarse de el y usar ADO.
[color=#00FF00]OLE Es una tecnología para intercambio de información pero era lo máximo hace 7 años ( en tiempos de Excel 5 ), sugiero usar ActiveX y ADO en su lugar.
[color=#00FF00]ODBC
Muchos programadores de vb5 lo utilizan en lugar de ADO, permite sin mucho problema hacer conexiones remotas o locales a casi cualquier tipo de dispositivo, pero tiene el inconveniente de que debe registrarse en el panel de control la base de datos, y a mi juicio es por lo mismo mas susceptible a fallas. Es un poco mas rápida que DAO, y sabiendo DAO es fácil portarlo a ODBC, pero en sistemas multiusarios de uso intensivo, o con mas de 32 usuarios conectados al mismo tiempo, es una bomba de tiempo incluso sin el uso de transacciones ( creanme, lo digo por experiencia ).

[color=#00FF00]RDO
Solo está disponible en la versión empresarial ( enterprise ) de vb5; es el método que recomendaba Microsoft ANTES de Visual 6 (e incluso cuando me certifiqué los instructores comentaban que era mejor esperar que se liberara ADO ). Es excelente en acceso remoto, con el “pequeño” problema que debe reescribirse casi todo el código porque no es compatible ni con DAO, ADO u ODBC Direct. Además es difícil echar a andar en una estación local, porque está pensado mas que nada para multisuario. Mi consejo es pasar a ADO a la brevedad posible. En lo personal, solo he intervenido en un programa que utilizaba esta tecnología y era en un fragmento especializado de doce líneas de código. Debe usarse un parche especial de Microsoft en varios casos.

[color=#00FF00]ADO
Quita Varias características de ODBC, pero aumenta la velocidad, y ya está preparada para acceso remoto. Puede configurarse para usar cualquier base de datos que windows reconozca, y no es necesario ingresar el DSN en el panel de control. El principal problema que tiene es la dificultad de CREAR bases de datos vacías, pero es un inconveniente menor. Puede usarse con Visual Basic 5, pero es necesario instalar un archivo llamado MDACTYPE.EXE o MDAC_TYP.EXE en la PC del programador. En algunos casos puede ser mejor usar ADOR, pero solo con VB5. A mediano plazo será posible hacer aplicaciones WEB con este motor.(.net pero no le veo mucho futuro como lenguaje)

[color=#00FF00]ADOR
Usa archivos del Internet Explorer 4 en adelante, y aunque puede ser util por ser una version mas reducida de ADO, la mayor parte de las veces solo sirve de dolor de cabeza para el programador, que termina pasando su información a tecnología ADO.

Siguiente:

Crearemos una tabla y base de datos, haremos un pinino de programa, y veremos los tres principios fundamentales para evitar trabajar de balde con Visual Basic

Antes de empezar es importante entender para que queremos programar, y que queremos obtener como resultado. Podemos encontrar mucho mas de lo que esperamos, pero tenemos que tener un punto de partida para medir nuestro avance, sea en la vida, o en el desarrollo de un programa.

No importa si somos Programadores, hackers, o lideres de proyecto, o si no tenemos nada que ver con el mundo de la computación, programar puede darnos aumentos de sueldo, viajes, y ahorrar tiempo. Este ahorrar tiempo lo trataré mas adelante.

Antes de poder hacer ALGO eficiente es necesario por lo menos tener una idea de que quieren hacer.

Por lo general las computadoras se usan para manejo de datos, por ejemplo de agendas de teléfonos, y si es manejo de datos, por lo general queremos hacer con ellos uno de tres procesos.

Si usamos el ejemplo de la agenda de telefonos, necesitamos tres opciones, que son los procesos.

Poner nuevas personas, es decir, un [color=#00FF00]ALTA
Borrar una persona, es decir, una [color=#00FF00]BAJA
Modificar el Telefono o nombre, es decir, un [color=#00FF00]CAMBIO
Existen dos procesos mas que no son propiamente de ACCESO a los datos, que serían Reportes y Respaldos. Para Fines Prácticos, cuando hablemos de un programa ABC, nos referimos a un programa Sencillo que solo hace [color=#00FF00]Altas [color=#00FF00]Bajas y [color=#00FF00]Cambios, y si nos referimos a un programa COMPLETO, es un programa que por lo menos hace [color=#00FF00]ABC mas reportes y respaldos.

Para fines de control, vamos a suponer que nuestros procesos los vamos a usar en redes LOCALES y PC solitarias, no hablaremos sobre Aplicaciones WEB, todavía.

Aunque suene obvio, el objetivo básico de un programa es simplificar Procesos, a esto se le llama “La navaja de OCCAM”, por su creador, un monje medieval que según recuerdo se llamaba Guillermo Occam.

La navaja de Occam es una regla de sentido común.Un proceso eficiente es lo mas sencillo posible. Mas complicado, menor eficiencia.

Por otra parte, la simplicidad de un programa le da siempre valor de supervivencia, en una maquinaria mientras menos piezas tenga, es menos probable que algo falle. ( Mas piezas = mayor riesgo de fallas )

Mañana:

Que es un motor de base de datos, una tabla, una base, una plataforma, y lo que muchos me preguntaron, cual es la diferencia entre ADO, RDO, OLE, SQL y DAO, y porqué es importante establecer con que versión de Visual Basic ( De aquí en adelante VB ) estamos trabajando.

Doy la bienvenida a los nuevos miembros de la Lista. En estos momentos, como habíamos acordado empezaremos un pequeño curso de 20 dias aprox sobre manejo de bases de datos con un lenguaje de programación.

Usaremos Visual Basic como base, version 5.0 con Service Pack 3, y Visual Basic Version 6.0 en Ingles sin Service Pack.

Porque Visual Basic? Pues porque la mayoria de los usuarios de PC usan actualmente Windows 95,98 o 2000, y porque BASIC es bastante portable a otros sistemas, con esto quiero decir que con Visual Basic, o un subconjunto, es posible programar para WEB, o para Palm Pilot.

Empezaremos a partir de hoy, y por simplicidad, pondré en las cabeceras el numero de Correo, si se fijan este es el correo Acceso a Datos: 01

En promedio usaremos un correo diario, y mas adelante estara disponible en el sitio.

Saludos.