Módulo de Acceso - Consideraciones

Considerar lo siguiente para la creación de la pantalla de acceso a las diferentes herramientas que hagamos en VB.Net 2010

• Ya que haremos Módulos Independientes para diferentes funciones, considerar que debe de ser portable. Por ejemplo, se está trabajando en ClienteReport (Zepeda) y en CalzadoDeck (Landeta). El módulo deberá de ser sencillo de insertar en cada nuevo proyecto. Se me ocurre mandarlo a llamar con alguna función y que si regresa falso no continuar con la ejecución de la herramienta.

• No podemos utilizar la contraseña que asigna Maxicomercio porque desconocemos la forma en que se encriptó.

• Utilizaremos una columna que acabo de crear en la tabla tuser y que la nombre ut_altpass la hice varchar con 32 de longitud.

• Desde Maxicomercio NO activaré que se pueda escribir o ver este password, así que necesito una interfaz que nos permita acceder a la lista de usuarios y podamos desde ahí agregar el password que nosotros queramos y que (ya lo pensé bien) NO SE ENCRIPTE, para que, si a alguien se le olvida ESE el password podamos revisar cual es fácilmente desde el Dreamcoder. Para acceder a la parte donde podamos agregar estas contraseñas puedes utilizar "Admin" y el password que tenemos actualmente en el Maxicomercio, pero por favor, este que no esté a la mano. El de conecta.txt está muy obvio para conocer la contraseña de Root. A ver que se te ocurre para esconderlo y que no sea facil de hackear.

• Al abrir el módulo me gustaría ver primeramente una lista de los usuarios existentes similar al CalzadoDeck y con ese mismo campo para buscar. Que al buscar busque de los campos: UserID y UserName de la tabla tuser.

• En la pantalla anterior no es que me haya faltado el botón agregar. Recuerda que los usuarios deberán de crearse desde Maxicomercio.

• El Editar el elemento se deberá presentar un diálogo mostrándonos:
• Usuario
• Nombre
• Si está bloqueado o no, con opción a bloquearlo o desbloquearlo
• Dos campos para el código alterno y su confirmación. Si el elemento ya tiene asignado un password que nos permita escribir en los campos pero que nunca se muestre el contenido. Que salgan asteriscos.
• Mensaje
• Notas
• Un listado de los módulos a los que tiene acceso y que ahí nos permita agregar o quitar. Inicialmente solo deseo controlar si tiene acceso o no. En un futuro podríamos pensar en si les damos acceso de lectura, escritura, etc pero ahorita no es necesario. Lo que quiero controlar es que no puedan entrar a todos los módulos con su contraseña.

• La captura de este Password Alternativo, al momento de escribirlo NO DEBE PODERLO VER LA PERSONA QUE LO ESCRIBE, pero deberá de confirmarlo dos veces antes de grabarlo por eso deberá de presentarse con asteriscos ese campo.

• El Acceso a los módulos, es por supuesto acceso a NUESTROS módulos. Para ello se deberá crear otra tabla. No la cree yo por falta de tiempo a través del creador de tablas de Maxicomercio. Me gustaría que se enlazara a tuser pero utilizando el Sys_GUID. Es eso posible??? Toma en cuenta que en un futuro replicaremos la tabla de acceso a módulos a las tiendas y es posible que cambie el Sys_PK. 

• Para administrar los accesos se ocupan dos tablas. La tabla de accesos y la tabla que contendrá el listado de módulos. Lo visualizo de la siguiente manera:

Tabla 1: ut_mismodulos

* Campos normales que agrega Maxicomercio +

ut_codigo

ut_nombre

Tabla 2: ut_accesos

* Campos normales que agrega el Maxicomercio +

ut_folio

ut_PKUser

ut_PKModulo

ut_Status

Comentarios: El folios sería un número consecutivo además del Sys_PK para llevar nuestro control de relaciones.

El PKUser y el PKModulo son  los que hacen el enlace entre el nombre del módulo y el usuario.

Status sería si está activo o no. En este caso sería Booleano.

• Si tienes alguna idea de como hacerlo de alguna manera más fácil lo comentamos. El chiste sería no limitar la cantidad de módulos y que estos puedan ser variables.

• La otra opción es hacer perfiles, tal y como lo maneja Maxicomercio, al perfil es a quien le dices a qué módulos tienes acceso y luego relacionas el perfil con el usuario. Pero eso debemos comentarlo. Piensalo.

• En donde sale el Grid de usuarios podría agregarse el botón para Crear y Editar el Listado de Módulos (Nosotros al hacer el módulo deberemos identificarlo para que se valide contra algún folio o código que definamos)

Espero que haya podido plasmar mis ideas, seguimos en contacto!

Características de un "Grandioso" Software

Hace poco leí por ahí que existen unos lineamientos para hacer los programas de Mac.

Estos lineamientos se encuentran en el sitio Mac OS X Developer Library:
Apple Human Interface Guidelines

Yo me pregunto... ¿Porqué no aplicarlo en las aplicaciones que hagamos en Windows?

Algo que me llamó mucho la atención fueron las características que debe de tener un "grandioso" software y que todos los que hacemos herramientas para usuarios deberíamos de adoptarlas.

1. Alto Desempeño
2. Facilidad de Uso
3. Apariencia Atractiva
4. Confiabilidad
5. Adaptabilidad
6. Interoperabilidad
7. Mobilidad

Los invito a leer la definición de cada uno en la siguiente liga: http://goo.gl/CnsKl

* Aunque la traducción literaria de Great Software sería Gran Software yo quise nombrarlo Grandioso porque GRAN literalmente podría interpretarse en términos de volumen.

No sale Pedido en el Crystal Report - Fareli Pagos

Cuando no aparece un pedido en el reporte de Crystal Reports de Pagos, revisar que los modelos incluidos en el pedido tengan correctamente asignado al proveedor en el campo "marca" ya que si es incorrecto no lo despliega.

Consideraciones para la Creación de Modelos en Maxicomercio

Tablas Principales

ut_cmcalzado
Tabla creada por el Módulo de Calzado desarrollado por Maxicomercio. Contiene el producto agrupador que también podemos llamarlo Modelo Padre, Producto Padre, Modelo Agrupador. La tabla se relaciona con varias de las tablas auxiliares para crear la definición del Modelo Padre que se requieren en una empresa comercializadora de calzado. 

ut_colorcalzado
También creada por el Módulo de Calzado. Esta tabla se considera principal porque almacena los colores que un Modelo Padre puede tener.

productos
Esta es la tabla que utilizará Maxicomercio para Vender, Comprar, Inventarios, Etc. Básicamente es la tabla más importante ya que las dos tablas anteriores solo tienen la función se facilitar la creación de nuevos modelos y agrupar productos para presentar reportes y datos estadísticos.

La relación gráfica de las tres tablas es de la siguiente manera:

• ut_cmcalzado puede incluir (agrupar) muchos registros de la tabla productos.
• ut_colorcalzado también agrupa muchos registros de la tabla productos.
• Un registro en la tabla de productos solo puede hacer referencia a uno de los registros de ut_cmcalzado y a otro de ut_colorcalzado.

Tablas Secundarias

ut_cmsecciones - Secciones (Ej. Zapato Colegial, Vestir Caballero, Deportivo Dama, Vestir Dama, etc)

ut_deptocalzado - Departamento (Ej. Mocasín, Tenis Urbano, Tenis Deportivo, Dama Tacón 12cm, etc)
ut_generocalzado - Género (Ej. Dama, Caballero, Bebes, Juvenil, etc)
ut_lineacalzado - Línea. Agrupador Complementario (Ej. Otoño, Primavera)
ut_materialcalzado - Material (Ej. Piel, Coagulado, Tela, etc)
ut_temporadacalzado - Temporada. El más importante para realizar estadísticos. (Ej. Primavera Verano 2010, etc)
ut_tipocalzado - Tipo, que se utiliza actualmente para indicar en qué página del catálogo aparece
marca - La marca para nosotros es el nombre comercial del proveedor. (Ej. King, Ragga, Suave Caminar, etc)

Estas tablas son utilizadas para incrementar el detalle informativo de un Modelo Padre todas tienen relación con ut_camcalzado.



La relación gráfica de las tablas es la siguiente: (Clic en la imagen para verla ampliada)

Captura de un Modelo Padre nuevo

Al capturar un Modelo Padre nuevo, la captura inicial se hace en base a la plantilla de ut_cmcalzado haciendo relación a las diferentes características de las tablas secundarias. 

Los campos obligatorios son: Código, Descripción,  Línea, Marca, Temporada, Tipo, Material, Genero, Departamento, Sección, Talla Inicial, Talla Final, Si tiene medios números o no.

Como opcionales, pero que el sistema tiene que ADVERTIRNOS de que no debemos dejarlos en ceros tendremos: Costo, Precio1, Precio2, Precio3, Precio4, Precio5.

Los campos que se deben de llenar AUTOMATICAMENTE por el software son: Impuesto, Inventariable, Valuación, Divisa.

Como opcionales sin ningún problema o mensaje tendremos: Proveedor1, Proveedor2, Proveedor 3, Referencia e Imagen.  

Una vez que hayamos capturado los datos principales, se procede a crear los colores únicos y exclusivos para este modelo. Se hace la captura en base plantilla: Código y Descripción como obligatorios y Equivalencia como opcional.

Con lo anterior, el sistema ya tiene para crear los modelos individuales en la tabla producto.

Si por ejemplo:

Capturo el modelo 25000

Talla Inicial 20

Talla Final 25

Sin Medios

Colores: Azul (A), Verde (V)

El sistema deberá de crear en la tabla producto 10 registros (está asumido que heredará características del modelo padre a los productos creados)

25000A20

25000A21

25000A22

25000A23

25000A24

25000A25

25000V20

25000V21

25000V22

25000V23

25000V24

25000V25

Sí, así es. Un registro por cada talla y por cada color. Como ven, el ut_cmcalzado es solo para permitirnos crear el Modelo Padre de la Matriz de Calzado.

Se denomina Matriz de Calzado, porque posteriormente, cuando realicemos alguna consulta, alguna captura o algún otro movimiento que involucre a TODOS los productos del Modelo Padre el sistema deberá de realizar su programación de manera grupal.

Por ejemplo, cuando consultemos la existencia el sistema deberá de mostrar algo similar a esto:

Pero estos detalles los veremos más adelante en un segundo Post. Solamente hay tener en mente la forma en que tendremos que presentar la información al usuario para considerarlo en la programación.