BUENAS PRÁCTICAS EN DYNAMICS NAV
INTRODUCCIÓN
Últimamente me encuentro instalaciones de clientes con Dynamics NAV en las que han participado diferentes perfiles de una empresa de Consultoría. Por regla general, estos perfiles tiene diferentes niveles de conocimiento y experiencia respecto a la aplicación. Debido a las grandes presiones que suelen sufrir los perfiles con más experiencia para cumplir objetivos, es muy común que la comunicación entre las personas de un proyecto sea deficiente, muy deficiente. Esta situación, unida a la (demasiado normal) falta de experiencia en programación en C/AL de los personas encargadas de realizar las modificaciones en la aplicación, provocan que el cliente sufra, en muchísimas ocasiones, aplicaciones e instalaciones muy deficientes.
En la actualidad, uno de mis clientes sufre esta situación. En el código de la aplicación me he encontrado con rutinas y funciones programadas de forma muy descuidada y sin el menor interés ni organización a la hora de realizar determinadas tareas.
Dynamics NAV es una aplicación aparentemente muy fácil de programar, con un lenguaje de alto nivel muy claro y simple, pero la lógica de negocio y la lógica de gestión de datos que subyace en la aplicación provoca que esa “fácil” programación se convierta en algo bastante más complejo. Sin embargo, siguiendo una serie de pautas, es posible realizar programas rápidos y acordes a la lógica de negocio de Dynamics NAV y conseguir clientes contentos (de esos que sólo se pelean contigo por el precio y no por la chapuza de instalación que les has dejado).
Me gustaría comenzar una serie de entradas en las que poder documentar esas “malditas” buenas prácticas desarrollando en Dynamics NAV que nunca tenemos en cuenta, pero que son imprescindibles a la hora de realizar modificaciones en la aplicación.
BUENAS PRÁCTICAS I
Mi primera entrada obligatoriamente tiene que hacer referencia a la más simple y la que todos deberíamos saber tras estudiar programación, pero que muy poca gente conoce: “Los datos se ordenan antes de filtrarlos y buscarlos”.
Imaginemos que estamos en un almacén lleno de facturas de proveedores guardadas en cajas y ordenadas por fechas. Venga, ¿ahora quién es el guapo que busca una factura de un proveedor concreto sin saber la fecha?
Esta bien, podemos decir que SQL Server hace el trabajo por nosotros, pero esto no es del todo verdad. Debemos acostumbrarnos a ordenar los datos de una tabla antes de filtrarlos, hacerlo directamente siempre traerá problemas.
Lo mejor es ilustrarlo con un ejemplo:
Queremos obtener todos los movimientos de producto de un producto durante el año 2014.
Sabemos cuál es la tabla: 32 Item Ledger Entry.
Sabemos los nombres de los campos: “Item No.”, “Posting Date”.
Qué se suele programar:
rItemLedgerEntry.SETFILTER("Item No.", '%1', cItem);
rItemLedgerEntry.SETFILTER("Posting Date", '%1..%2', 010114D, 311214D);
rItemLedgerEntry.FIND('-');
Qué deberíamos haber programado:
CLEAR(rItemLedgerEntry);
rItemLedgerEntry.SETCURRENTKEY("Item No.", "Posting Date");
rItemLedgerEntry.SETFILTER("Item No.", '%1', cItem);
rItemLedgerEntry.SETFILTER("Posting Date", '%1..%2', 010114D, 311214D);
rItemLedgerEntry.FIND('-');
O incluso mejor:
CLEAR(rItemLedgerEntry);
rItemLedgerEntry.SETCURRENTKEY("Item No.", "Posting Date");
rItemLedgerEntry.SETRANGE("Item No.", cItem);
rItemLedgerEntry.SETRANGE("Posting Date", 010114D, 311214D);
rItemLedgerEntry.FINDSET(False, False);
Es imprescindible cumplir siempre con estos criterios:
1) Si filtras primero ordena
2) Si vas a usar un filtro asegúrate de que la variable esté inicializada correctamente.
Espero que pueda servir de ayuda.