¿Qué se necesita para ser un experto en Microsoft Dynamics NAV (Navision)?

Seguro que muchos de vosotros, consultores y programadores, os habéis preguntado qué se necesita para ser expertos en Navision. Yo también me lo he preguntado alguna vez. Así que intentaré darle respuesta.

Lo primero es que la mayoría de los que trabajamos con Navision somos “todo terrenos”: somos consultores, programadores y sabemos configurar la herramienta.

El ERP Dynamics NAV está orientado a pequeñas y medianas empresas, por lo que una de las características de Navision es su facilidad de configuración. Esto hace que en la mayoría de ocasiones no se requiere de un consultor “puro”, como si necesitan otros ERPs más complejos.

Lo que un experto en el ERP Microsoft Dynamics NAV (Navision) debe tener:

Accede al curso de Dynamics NAV

Conocimientos funcionales: ¿Cómo se trabaja con Navision?
Navision es una herramienta que dispone de muchísima funcionalidad estándar.
A un programador habitualmente se le pide que amplíe esa funcionalidad. El experto en Navision primero debe conocer que es lo que ya hace Navision y cómo.

Conocimientos técnicos: Programación en C/AL
Programar en Navision usando el lenguaje de programación C/AL no es difícil. Es más, diría que hasta es fácil. Ok, siempre están esos pequeños trucos que después de años sigues descubriendo, pero lo más usual (que no básico) se aprende rápido.

Conocimientos técnicos: SQL, .NET , WebServices, Reporting Services, conectores, etc.
Hace tiempo que Navision ya no está solo. La familia crece. Así que saber administrar un SQL Server, exponer o consumir WebServices, conectar Navision con terceras aplicaciones, etc. es trabajo habitual del programador. El experto no puede centrarse únicamente en Navision.

Conocimientos empresariales: Procesos de Negocio
El experto en Navision debe hablar el lenguaje del usuario, y saber a qué se refiere cuando usa los términos propios de su área. No se pueden configurar Grupos Contables sin tener ni idea de contabilidad. No se puede tocar la cartera sin saber qué es un efecto. No se pueden configurar ubicaciones de almacén según productos ABC si no sabemos lo que son.
Esta es, según mi punto de vista, la parte más importante que debe dominar el experto. Conocer el negocio. Conocer los procesos. Conocer los flujos. Conocer las prácticas habituales en las distintas áreas de la empresa.

Salut!
Laura Nicolàs
Autora del libro Implementing Microsoft Dynamics NAV 2013

Aunque parezca fácil, piénsalo dos veces

Cualquier desarrollo, aunque parezca muy fácil, se tiene que pensar dos veces. A ser posible, además, comentarlo con un compañero. Cuatro ojos ven más que dos. Es la mejor forma de diseñar un desarrollo coherente, integrado y – a ser posible - sin futuros errores.

Os pongo en antecedentes:

En Navision, el informe que crea el fichero del modelo 347 mira los movimientos de IVA y los agrupa por CIF/NIF. Sin embargo el sistema permite registrar una factura aunque el CIF/NIF no esté informado. Lo habitual es no darse cuenta de esto hasta que se ejecuta el informe del 347. En este punto la solución pasa por poner manualmente el CIF/NIF en todos los movimientos de IVA que se han quedado con el campo en blanco. Dependiendo del volumen este puede ser un trabajo bastante laborioso.

Requerimientos para el desarrollo:

Poner un control para evitar que se registre un documento si no tiene el CIF/NIF informado.

Accede al curso de Dynamics NAV

Propuesta de desarrollo:

Versión 1

En el OnValidate el código de cliente/proveedor de Sales Header y Purchaser Header, poner un TESTFIELD. Así solo se puede seleccionar un cliente/proveedor si el CIF/NIF está informado en su ficha. Problema: Mucha gente usa un “cliente varios” y “proveedores varios” para registrar tiquets i cosas por el estilo. En estos casos es interesante dejar el CIF/NIF en blanco. Versión 2 En lugar de usar un TESTFIELD, poner un CONFIRM. Problema: Si el volumen de estos clientes y proveedores es muy grande, al usuario lo vamos a bombardear con CONFIRMs constantes. Versión 3 Poner un campo “Omitir en 347” en la ficha del cliente y del proveedor para marcar expresamente aquellos que queremos dejar en blanco. Escogemos este nombre para el campo porque los clientes / proveedores varios no deben declararse en el 347, además en la ficha de las cuentas contables ya existe un campo llamado así. Problema: Con este nombre de campo podemos confundir al usuario. Lo que hace este campo es no obligar a tener un CIF/NIF informado al crear un documento… no excluir ese cliente / proveedor de la declaración. Versión 4 Llamar al campo “Omitir CIF/NIF en documentos”. Bingo! Esta parece la solución ideal!
Aunque haya resultado pesado de leer, en realidad pasar por las 4 versiones de propuesta de desarrollo no nos llevó más de 5 minutos. Pero lo importante no es el tiempo, sino el hecho. Este es un desarrollo pequeño y poco importante, pero haber implementado una de las tres primeras versiones hubiera sido un error y una fuente de insatisfacción de cara al usuario. Es por esto que digo: aunque
parezca fácil, piénsalo dos veces.

Y vosotros, ¿qué sistema usáis para asegurar un buen desarrollo?

Salut!
Laura Nicolàs
Autora del libro Implementing Microsoft Dynamics NAV 2013