Cómo Administrar las Personalizaciones en Dynamics GP

Recientemente un cliente se acercó a nosotros con preguntas sobre cómo debería desplegar un reporte particular a los usuarios. Luego de explicar los detalles y opciones relacionadas, me percato de que muchos usuarios (y su personal de soporte de TI) no están completamente claros de cómo deben administrar sus personalizaciones en sus empresas. Esta falta de conocimiento puede desembocar en personalizaciones o reportes perdidos cuando un computador es reemplazado o cuando se realiza una actualización de sistemas. Este artículo explica las opciones disponibles y los pros y contras de cada una de ellas.

Anteriormente escribí una serie de artículos que discuten las diferentes opciones de personalización disponibles para usuarios de GP, así que no voy a entrar en esos detalles aquí. En esta ocasión me voy a enfocar en las personalizaciones más sencillas y populares las cuales generalmente involucran reportes o ventanas modificadas con Report Writer o Modifier. Estas personalizaciones crean diccionarios (archivos) que residen en algún lugar de su red y los cuales deben ser accedido cada vez que el usuario corre un reporte modificado o abre una ventana modificada. El lugar donde se almacenen estos diccionarios, así como la forma en que se distribuyen a los usuarios puede afectar el rendimiento del sistema, aumentar o disminuir el riesgo de perder una personalización valiosa, y hacer más fácil o difícil darle mantenimiento a las personalizaciones existentes.

Por defecto, los reportes y las ventanas modificadas están almacenadas localmente en el directorio Data de Dynamics GP, en cada una de los computadores que tienen el sistema instalado. Cualquier cambio que se haga en un computador particular (como modificar un reporte o una ventana) será almacenado localmente y no afectará a ningún otro usuario. Alternativamente, puede configurar su sistema de forma tal que los diccionarios de las personalizaciones estén almacenaos en una localización compartida accesible por todos los usuarios. Si este es el caso, entonces los cambios realizados en cualquier computador, afectarán a todos los demás computadores.

Siempre recomiendo mantener los diccionarios de las personalizaciones almacenados localmente. Esto significa que debemos tener algún mecanismo de "despliegue" para que cada nuevo cambio sea copiado a cada uno de los computadores de la empresa. Usted puede verificar si el cliente de GP está configurado para almacenaje local o compartido de las personalizaciones, viendo el archivo Dynamics.set en cada computador. También recomiendo que todos los usuarios tengan siempre las mismas personalizaciones de forma tal que exista una estandarización de las mismas en toda la empresa. Puede que sea útil bajo alguna circunstancia el tener el mismo reporte modificado en forma diferente para dos usuarios, pero esto es usualmente un requerimiento excepcional, y no la regla. Mantener todas las personalizaciones estandarizadas para todos los usuarios elimina el proceso de tratar de adivinar qué usuario tiene cuáles personalizaciones y reduce el riesgo de perder importantes personalizaciones durante un proceso de actualización de Dynamics GP, por ejemplo. Idealmente, entonces, usted quiere tener un solo juego de personalizaciones que pueda desplegar a todos los usuarios.

Entonces, ¿Cuáles son mis opciones para despliegue de las personalizaciones? En resumen, las siguientes:


  1. Diccionarios compartidos: Diccionarios almacenados en una localización compartida por todos los usuarios.
    • Pros:
      • Simplifica el despliegue — Usted coloca un diccionario en el directorio compartido, y todos los usuarios accederán a las mismas personalizaciones.
      • Todos los usuarios tienen las mismas personalizaciones, todo el tiempo. No hay que adivinar quién tiene qué.
    • Cons:
      • No puede modificar los diccionarios mientras están siendo utilizados. Se requiere un computador de desarrollo configurado con las personalizaciones localmente para poder hacer los cambios allí antes de desplegarlos. Luego, copiar los diccionarios resultantes a la localidad compartida de forma tal que todos tengan acceso a los nuevos cambios. Esto puede ser más fácil de decir que de hacer pues todos los usuarios deben salir del sistema para poder reemplazar los diccionarios viejos con los nuevos.
      • Crea tráfico de red innecesario. Piense en un formato de factura modificado, o en un cheque. Cada vez que alguien imprima una factura o un cheque, el sistema tiene que buscar el formato modificado en la localidad compartida. Si usted tiene muchos usuarios en su sistema, esto puede agregar una cantidad de tráfico significativo.
      • Los diccionarios de personalizaciones compartidos son más propensos a corrupción al estar siendo accedidos por múltiples usuarios a la vez.

  1. Diccionarios locales: Esta es la forma cómo instala GP por defecto.
    • Pros:
      • Debido a que las personalizaciones residen localmente, las operaciones relacionadas con los mismos se realizan más rápidamente, y hay menos posibilidad de corrupción o problemas. Cuando el usuario imprime una factura o un cheque modificado, los formatos están almacenados localmente, así que todo es fácil y rápido.
      • Los reportes y las ventanas pueden ser modificadas en cualquier momento, ya que estos diccionarios no están siendo compartidos con ningún otro usuario.
    • Cons:
      • Usted debe contemplar una estrategia de despliegue así como de copiado de resguardo. Cuando se hace el despliegue de diccionarios modificados, básicamente hay que copiar los diccionarios a cada una de las estaciones (o exportar los diccionarios en un "paquete" de personalizaciones para luego importarlo a cada computador). Esto puede ser tedioso si tiene muchos usuarios. Yo siempre recomiendo crear paquetes con todas las personalizaciones y aplicar alguna técnica de versiones en caso de que se requiera volver a una personalización anterior si algo no sale como esperábamos.
      • Debido a que cada computador tiene su propio juego de personalizaciones, puede que se presente una situación en la que un usuario "creativo" cambie algo en su computador y luego nadie más tiene este cambio. Peor aún, cuando se actualice a todo el mundo con una nueva versión de las personalizaciones, posiblemente es cambio particular que hizo el usuario se pierda.

  1. Solución "Híbrida": En nuestros clientes de mayor tamaño, hemos implementados una solución muy exitosa que permite obtener los mejor de los dos mundos anteriormente descritos. La solución consiste en almacenar los diccionarios de personalizaciones localmente (que es la configuración por defecto al instalar GP). Por otro lado, mantenemos una "copia maestra" de todos los diccionarios en algún lugar compartido al cual todos los usuarios tienen acceso de lectura/escritura. Finalmente, creamos un script en el dominio de la empresa aplicable a todos los usuarios que tengan Dynamics GP instalado. Este script corre cada vez que el usuario hace login al dominio, y su función es copiar los diccionarios "maestros" al directorio local por defecto del usuario en su computador, en esencia reemplazando los diccionarios locales con la copia maestra. Bajo este esquema, los clientes de Dynamics GP están usando los diccionarios localmente, los cuales se refrescan cada vez que el usuario hace login al dominio. Cualquier cambio a los diccionarios "maestros" se hace en un ambiente de desarrollo, y cuando un nuevo cambio está listo y aprobado, los diccionarios maestros son actualizados con las nuevas versiones. Esta solución trabaja muy bien en un ambiente donde la instalación de GP está estandarizada para todos los usuarios (todos los usuarios tienen instaladas las mismas funcionalidades de GP), lo cual es una mejor práctica de todos modos.
    • Pros:
      • Aún cuando toma un poco de esfuerzo y organización inicialmente, esta solución envuelve lo mejor de las opciones local/compartida discutidas anteriormente.
      • Como las personalizaciones son locales, las operaciones relacionadas con ellas son fáciles y rápidas.
      • Todos los usuarios tienen las mismas personalizaciones instaladas.
      • Las modificaciones se hacen fuera de línea hasta que se prueban y aprueban, lo cual es una mejor práctica.
      • Si un usuario hace cambios (o digamos que hasta daña) un reporte o una ventana modificada, el simple proceso de hacer logoff del dominio y volver a hacer login disparará el proceso que "refrescará" sus diccionarios, corrigiendo el problema.
      • Igualmente, para el despliegue de nuevos cambios, solo hay que pedir a los usuarios que hagan logoff/login para obtener las nuevas modificaciones.

  • Cons:
    • Toma un poco de esfuerzo y organización implementar esta solución, pues involucra la creación de scripts y organización de los usuarios en grupos de dominio, entre otros.
    • Debe designarse un ambiente de desarrollo, lo cual para clientes pequeños puede ser simplemente una PC, mientras que para los más grandes posiblemente sea su ambiente estándar de pruebas y desarrollo para GP.

Cuidar de sus personalizaciones y mantener un estándar operativo y de copiado de resguardo para los fines, son una parte importante de su estrategia de mantenimiento de Dynamics GP. Entender cómo administrar las personalizaciones en Dynamics GP es un gran paso para evitar confusiones sobre quién tiene qué instalado, y también evitar problemas cuando haga actualizaciones a su ambiente Dynamics GP.

Si tiene preguntas sobre como administrar las personalizaciones en su ambiente Dynamics GP, ¡Contáctenos!