EL MOTIVO

El motivo de realizar un programa de gestión empresarial completo es por la necesidad de satisfacerme del hecho de saberlo hacer, en segundo lugar por que no acabo de encontrar en el mercado ningún programa que me satisfaga lo suficiente como para podérselo ofrecer a mis clientes con total y absoluta confianza y garantías de funcionamiento, en tercer lugar por no tener que estar dependiente de terceras empresas y o personas, que hoy pueden parecerte maravillosas y mañana no serlo. Además debía demostrarme a mi mismo mi capacidad como programador, ya que hacía unos años que no la había practicado, dejándome más a las faenas administrativas y de asesoramiento que a las propias de diseño y programación. Y le debía a dos individuos el convencimiento que la ingeniería es un título que puede uno doctorarse en la universidad de la vida y por sí mismo y por su propia voluntad, interés y capacidad.

Una vez alcanzado el punto de convencimiento comienza el primer quebradero de cabeza, se trata de elegir la plataforma sobre la cual desarrollar todo el invento. No voy a abrumar a nadie con mis tribulaciones y mis asesoramientos sobre tal o cual sistema, cual era más sencillo y cual más complejo, pero a la vez con mayores posibilidades. También hay que valorar que los posibles usuarios del aplicativo tendrían que gastarse más o menos dinero en licencias ajenas a mi entorno. Al final la elección de plataforma fue Access y en su versión 2003. Solo voy a dar los puntos de ventaja del mismo frente a otras posibilidades.
1º Lo conocía lo suficiente para no dudar en cuanto a definiciones.
2º Permite sin problemas hacer aplicativos Front-End
3º Es lo suficientemente conocido para no crear la incertidumbre de lo desconocido.
4º Su plataforma es barata.
5º Compatibiliza sin problemas bases de datos propias con otras de SQL Server.
6º Por que es lo suficientemente potente y flexible para poderse acomodar a cualquier entorno.
7º A la hora de migrar los viejos aplicativos no tendré problemas de compatibilidades.

Así ahora que ya tenemos el motivo y la plataforma solo hay que poner el cerebro a funcionar a tope y afinar los dedos para cometer cuantos menos errores mejor. Así que ahora voy con mis primeros pensamientos. He de decir que llevo ya muchas horas de programación metidas, pero no hay nada definitivo. El Proyecto va tomando cuerpo, pero como buen alfarero, todavía mantengo fresco el primer barro que puse en el torno.

EL BOCETO DE LA EMPRESA

Que labores administrativas realiza una empresa. Y en cuales debemos influir. Tras un rato rascando la cabeza, llego a la conclusión que hay dos apartados como mínimo que toda empresa tiene: Clientes a quien venderle algo y el algo que se les vende a los clientes. En un segundo pensamiento decido que ese algo que se les vende a los clientes, puede ser que lo compremos a otros (proveedores) o que nosotros seamos los creadores del algo. Ya me canso de llamarlo algo, he decidido llamarlo Artículos. Así que en solo dos pensamientos ya tenemos todos los elementos básicos que necesita una empresa para llamarse así.
Proveedores. Son aquellas personas o entidades que nos proporcionan los artículos o los suministros necesarios para llevar a cabo la labor de empresa.
Artículos. Son los elementos con los cuales la empresa negocia y obtiene la rentabilidad suficiente para su desarrollo.
Clientes. Son aquellas personas o entidades a las que les proporcionamos Artículos.
Así termina la primera parte del primer envite. Ya he definido los tres pilares básicos de una buena Gestión empresarial. Al tener tres patas todo lo que construyamos sobre esta base se supone que será estable.
Una vez definidos los pilares básicos, debemos definir la forma, es decir el grosor, la altura, la carga que van a soportar, la rigidez, la esbeltez, los accesorios que podrán llevar, las filigranas con las que los remataremos para que sean atractivos.
Una vez que tenemos el trípode vamos a asentar el invento con una cuarta pata. Esta no va a estar en ninguna esquina nueva, sino en el centro del triángulo que conforma la base. Este es el pilar Empresa, en el se definen los parámetros de funcionamiento de los otros tres. Y conjuntamente a este pilar central le vamos a acompañar con dos tirantes de sujeción para que la estructura aguante cualquier tempestad. Estos tirantes van a ser los usuarios y los puestos de trabajo o terminales. A los usuarios se les asignarán los poderes de manejo de información, y a los terminales se les dotará de características de funcionamiento especializadas.
Una vez definida la súper estructura, es tiempo para pensar en las interconexiones que tendrán estos pilares.
Vamos a pensar en cómo ayudar en dichas labores empresariales, para que dejen de ser tediosas para el personal de la misma y la Gestión Empresarial, se convierta en la herramienta que se encargue de mantener encajadas todas las piezas, pero de flexibilidad al sistema para poderse adaptar a todas las tecnologías que se nos puedan presentar.
Hemos dicho que los artículos son con lo que la empresa negocia, puede negociar en dos vertientes comprándolos o fabricándoselos y vendiéndoselos o alquilándoselos a los clientes. Por ello hemos divido el programa en tres zonas, la zona izquierda son las ventas, la zona derecha las compras y son casi simétricas a las ventas. Y la zona central está ocupada con los artículos y sus controles.
En la zona de ventas tendremos a los clientes, las ofertas, los pedidos de venta, los albaranes, la facturación, las facturas y la cartera de cobros.
En la zona de compras tenemos a los proveedores, las plantillas de compra, los pedidos de compras, los albaranes, las facturas y la cartera de pagos.
En la zona artículos están además de ellos mismos, los movimientos de almacén, inventarios, tarifas de precios y fabricación.
Así queda definido en grandes pinceladas el boceto de la Gestión Empresarial. Ahora queda el iros contando como es por dentro, las características de los procesos y las razones por que está cada cosa en su sitio y no en otro. Esto puede ser muy largo y denso, así que poneos cómodos y si necesitáis algo, me lo hacéis saber con vuestros comentarios.

LOS ARTICULOS

Puesto que se trata de aquello con lo que la empresa negocia. Hay mimarlo al extremo, pero también hay que pensar en la persona que tiene que ponerse al otro lado de la pantalla. Debemos hacer que el manejo de los artículos sea robusto, pero a la vez ágil, intuitivo y elegante. La primera premisa es cómo liberar al usuario, usuario es la persona que maneja el ordenador y el programa, de la tediosa tarea de la codificación. Ya que para que el ordenador identifique a un artículo en concreto éste debe estar codificado, es decir, debe tener una identidad propia y única que lo haga diferente del resto de los artículos. La solución es que la ardua tarea de codificar la haga el programa. Bien primera cualidad la de auto-codificación. Una vez alcanzada esta brillante solución surge una segunda pregunta. ¿Qué sistema de auto-codificación empleamos? Tras sopesar varias posibilidades hemos elegido el sistema llamado “Famility” o agrupación familiar. Es decir, los artículos los agruparemos en familias, y dentro de éstas se utilizará un sistema de numeración correlativa. Pero como en toda buena familia que se precie existen dos apellidos, hemos ampliado el método “Famility” ampliando a “Double famility”. Convertido a términos del proyecto los artículos se agruparán en Familias y subfamilias, usando una numeración correlativa tanto las subfamilias dentro de las familias, como los artículos dentro de las subfamilias. Y para terminar este galimatías de términos no hemos querido encorsetar a un número fijo de familias y subfamilias y artículos, con lo cual los valores de longitud de familia, subfamilia y artículo los hemos dejado que cada Empresa los asigne como quiera. Eso si. Una vez establecidos serán inamovibles. Así el estándar que recomiendo es una longitud de familia de dos dígitos del 0 al 99. La longitud para subfamilia también de dos dígitos del 0 al 99. Y la longitud de artículo de cuatro dígitos. Ello nos daría una longitud del código del artículo individual de ocho dígitos, suficiente cantidad para almacenar cien millones de artículos sin que se repitan.
Ya tenemos los dos primeros cimientos de los artículos: Las familias y subfamilias. Pero ahora que hemos resuelto el problema de la auto-codificación que hacemos con los códigos de los artículos, que los señores del almacén se saben los códigos de memoria de tanto utilizarlos. ¿Borrón y cuenta nueva? Si eliges esta opción más de uno se va a cagar en tus muelas. Decidimos aprovecharnos de ello, dado que las empresas antiguas ya tienen sus propias codificaciones de artículos hechas a base de experiencia, no conviene desaprovechar esta valiosa fuente de información. Decidimos crear un segundo código de artículo que llamamos Alias. Al igual que el código del artículo este dato servirá para localizar el artículo, por ello en la base de datos le damos la característica de índice único. Para los artículos nuevos simplemente volveremos a escribir el código del artículo en este campo y problema solventado.
El nombre del artículo no debería presentarnos problemas aparentes. Vaya pues si. Que ingenuo pensar que el nombre no iba a presentar nuevos retos. ¿Cuales? El primero fue decidir la longitud idónea, tras unos cuantos pensamientos sobre ello llegué a la conclusión que cualquiera que fuese la longitud, seguro encontraba un artículo que la superase. Si hacía la longitud muy grande el tamaño de las bases de datos podría ser enorme, con lo cual su manejo y rendimiento a la larga iría decayendo. La decisión fue salomónica: Dividirlo en dos partes. La primera haría la función de nombre del artículo y tiene 128 caracteres alfanuméricos de longitud. La segunda parte se trata de un campo memo, el cual no tiene limitación de caracteres. Pero como no todos los artículos tendrán esta segunda parte decidí colocarla en una tabla auxiliar del artículo, con lo cual el rendimiento en la base de datos está garantizado. Dicha tabla auxiliar se llama Ficha técnica. Y en dicho campo se puede almacenar cualquier información relativa al artículo. Pero hete aquí que el problema solo lo había solventado parcialmente. Hay empresas que venden y compran sus productos en el extranjero, o en diferentes Comunidades Autónomas. Si la empresa quiere conquistar los mercados foráneos debe hablar como ellos para entenderse correctamente. De esta forma surge la cláusula de múltiples idiomas. ¿Cómo hacemos que los nombres de los artículos puedan aparecer en otros idiomas? ¿Y en cuantos idiomas? Otro quebradero de cabeza. ¿Dos, tres, cuatro idiomas? La solución es montar una tabla de idiomas y que la empresa decida cuantos da de alta. La solución en los artículos pasa por sacar mas rendimiento a la tabla de ficha técnica, añadiendo el código del idioma y la descripción del artículo en el idioma que se quiera. Así ya tenemos la capacidad de poder pedir o vender los artículos con los que comerciamos en otros leguajes diferentes al nuestro.