Organización de objetos en Dexterity

Microsoft Dynamics GP

Cuando se inicia un proyecto nuevo de Dexterity basado en un diccionario existente de Microsoft Dynamics GP, aparecen en el explorador de recursos todos los objetos disponibles de la aplicación. En el momento en que el programador crea recursos nuevos, aparecen en el listado junto con los recursos originales de la aplicación. Microsoft Dynamics GP solo en el diccionario de principal tiene más de 1800 formas, 1200 reportes, 1600 tablas, sin contar los tipos de datos, formatos, campos, las constantes, y muchos más tipos de objetos.

El hecho que los recursos propios estén mezclados con los originales de la aplicación vuelve un poco complicado la búsqueda. Claro que Microsoft Dynamics GP tiene organizado cada objeto con una nomenclatura basada en el módulo que deberíamos seguir. Por ejemplo, un resumen de alguno de los módulos que podemos ver son:

Sufijo Descripción
GL Contabilidad
IV Inventario
PA Proyectos
PM Cuentas por pagar
POP Compras
RM Cuentas por cobrar
SOP Ventas
SY Sistema

Podemos ver más detalle del listado de módulos en la documentación del SDK que se encuentra en el instalador de la aplicación (Recomiendo descargar el SDK actualizado de la página de Microsoft debido a que se actualiza con frecuencia con cada liberación y hotfix).

Las formas tienen un nombre técnico (Nota: no confundir formas de Dexterity con formas de Visual Studio. El equivalente de formas de Visual Studio en Dexterity son las ventanas que son los objetos que se encuentra dentro de las formas). El nombre técnico típicamente tiene la siguiente sintaxis:

MMM_xxxxxxxxxx_zzzzzzzzzz

En donde MMM representa el módulo, xxxxxxxxxx la operación y zzzzzzzzzz la acción. Por ejemplo, GL_Transaction_Entry, SOP_Item_Inquiry o POP_Invoice_Entry, sin embargo, no es una regla… encontrarán muchas excepciones también. Considero buena práctica seguir esta regla.

Los reportes tratan de seguir una sintaxis de sufijo por módulo, sin embargo, como el nombre del reporte es utilizado para visualizarlo al usuario final, se ven muchos nombres descriptivos, por lo que si no se conoce bien la aplicación puede ser un poco complicado encontrar un reporte en el listado. Puede ser organizado por serie el listado, pero también encontrarán muchos de ellos organizado por módulo. Aun así, considero buena práctica incluir el sufijo del módulo en el nombre del reporte.
Las tablas tienen una historia interesante. A diferencia de las formas y los reportes tienen 3 nombres. Un nombre técnico, uno de visualización y uno físico. A nivel de organización son importantes los nombres técnico y físico. No quiero decir con esto que el no colocar el prefijo en el nombre de visualización no es importante (es costumbre mía hacerlo para facilitar al usuario diferenciar las tablas). El nombre técnico generalmente tiene la siguiente sintáxis:

MMM_Xxxxxxxx_ZZZZ

En donde MMM representa el módulo, Xxxxxxxx la descripción y ZZZZ la utilidad. Ejemplos de la utilidad son HDR encabezado de transacciones, LINE líneas de detalle de transacciones, SETP configuración, MSTR datos maestros, WORK operaciones de trabajo, HIST operaciones históricos, etc…
El nombre físico es en donde viene la confusión. Es el nombre con el cual se ve la tabla representada en la base de datos y generalmente está representada por no más de 8 caracteres. Tiene su origen en las primeras versiones de Dexterity en donde se soportaba otras base de datos de tipo ISAM (Indexed Sequential Access Method) como C-Tree y Pervasive (Btrieve) que tenían sus datos basados en archivos en el file system en la época de FAT, por lo que los nombres de las tablas estaban limitados a 8 caracteres y su respectiva extensión. La nomenclatura standard utilizada es:

MMMXXZZZ 

En donde MMM representa el módulo, XX es 00 si se trata de una tabla de maestro, 10 de trabajo, 20 abierto, 30 histórico, 40 configuración y ZZZ un secuencial. Claro que si el programador desea utilizar el mismo nombre técnico como nombre físico también puede hacerlo, pero para ello debe habilitar una opción en Dexterity que habilita nombres de tablas largos. Pueden habilitar la opción en Edit->Options->Allow Long Physical Table Names.
Una vez visto estos pequeños tips de nomenclatura y definido el nombre del módulo o prefijo de la aplicación propia que se va a desarrollar, se puede organizar de mejor forma el programa. No recomiendo utilizar los mismos prefijos que utiliza Microsoft. Siempre definan sus propios prefijos para sus aplicaciones. Algunos ISV tienen siempre fijos el nombre de sus empresas como estándar.

Como último paso es definir los Worksets y asignarles los recursos. Esto consiste en crear áreas de trabajo personalizados para no tener mezclados los recursos propios o modificados con los originales de la aplicación. Se pueden definir cualquier cantidad de Worksets, sin embargo, tengo la costumbre de definir para proyectos no muy grandes uno para formas, uno para reportes y otro para tablas.

Worksets

Hay otras acciones que se realizan para organizar el código pero es de forma externa, debido a que programo mucho de forma híbrida, en donde utilizo Visual Studio Tools con C# y creo clases vinculandolos con los eventos de Dexterity. Pero este es un tema fuera de covertura porque ya se trata de Visual Studio. También está la creación de los stored procedures, que mantengo con la misma sintaxis.

Espero que estos tips les sirva de guía para mantener el código en Dexterity un poco más organizado. Cualquier sugerencia adicional es bienvenida!!!

Leave a Reply