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.
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.
No hay comentarios:
Publicar un comentario