El objetivo de esta cápsula es, en primer lugar comprender como se estructura Microsoft Dynamics AX 2012 R3. Para ello hablaremos de la Arquitectura física y la Arquitectura lógica del sistema. Para comprender estas dos arquitecturas, veremos los componentes físicos necesarios para poder trabajar con Dynamics AX y el papel que juega cada uno de ellos en el sistema. También veremos las agrupaciones lógicas que tenemos disponibles en Dynamics AX y que podemos utilizar para organizar los objetos durante el desarrollo. Estas agrupaciones podremos realizarlas gracias a las capas, los proyectos y los modelos. Este último, es un concepto añadido a partir de la versión 2012 de AX, por lo que será nuevo para aquellos que venís de la versión 2009 o anteriores.

Por último, daremos un vistazo por el entorno de desarrollo integrado de AX 2012 R3, así como por el entorno de desarrollo Visual Studio, necesario desde la versión 2012 de AX para realizar una serie de tareas.

En esta cápsula, nos ponemos como objetivo conocer los tipos de datos con los que trabaja Dynamics AX 2012 R3. Esto es fundamental para trabajar de forma correcta con el modelo de datos de la aplicación, puesto que todos los campos de las tablas se basan en estos tipos de datos.

Los tipos de datos en Dynamics AX se dividen en tres grandes grupos: Tipos de datos primarios, como pueden ser los números enteros, los números decimales o las fechas. Tipos de datos secundarios, como los arrays o los contenedores. Y tipos de datos extendidos, que son un tipo de datos definidos por el usuario. 

También veremos como declarar variables basadas en estos tipos de datos y algunas funciones del sistema que nos facilitan el trabajo con ellas.

El objetivo de este apartado es aprender a trabajar con las tablas dentro de Microsoft Dynamics AX 2012 R3. Las tablas son los objetos que forman los cimientos de la aplicación, y son las encargadas de almacenar los datos utilizados por el sistema. De ahi la importancia de conocer estos objetos a la perfección, ya que cualquier desarrollo o modificación que realicemos, por ser AX un ERP, se basará siempre en el manejo de los datos.

Veremos como crear nuevas tablas y todos los elementos que la componen. Estos elementos son los campos, grupos de campos, indices, relaciones, acciones de borrado y métodos; También hablaremos de las tablas temporales, y de como desde la versión 2012 se ha incluido la compatibilidad con las tablas temporales de Microsoft SQL Server.
Al finalizar la cápsula seremos capaces de crear nuestro propio modelo de datos con todas las tablas necesarias y las relaciones entre ellas.

El contenido de esta cápsula nos permitirá ser capaces de trabajar con tres objetos importantes para el manejo de datos dentro de AX 2012 R3: Los mapas, las vistas y las queries.
Veremos como crear y utilizar los mapas, objeto muy útil para la reutilización de código cuando tenemos que trabajar con una serie de tablas que comparten un mismo comportamiento en algunos de sus campos, lo que nos permitirá tener un código mucho más simple y consistente.

Con el uso de las vistas, seremos capaces de obtener los datos de una o más tablas relacionadas según los requerimientos exigidos por el proyecto, y podremos servirnos de ellas para mostrar estos datos ya formateados por ejemplo en informes o consultas.
Por último, vamos a ver el objeto Query. En AX podemos crear queries bien desde el AOT, o bien utilizando el lenguaje de programación X++. En esta cápsula nos centraremos en crear queries para guardarlas en el AOT, lo que nos permitirá reutilizarlas en informes y formularios.

Con la llegada de Microsoft Dynamics AX 2012 se introdujo un nuevo concepto en el sistema: La herencia de tablas.
AX 2012 R3 nos permite crear tablas derivadas desde una tabla base. Estas tablas derivadas heredarán los campos, métodos y propiedades de su tabla base, y además, podrán extender la funcionalidad con campos y métodos adicionales de forma que podremos crear una serie de tablas específicas que compartan cierta funcionalidad gracias a la tabla de la que heredan.

También hablaremos de cuando es aconsejable utilizar este tipo de tablas.

A lo largo de esta cápsula, veremos la principal forma que tienen los usuarios para interactuar con Microsoft Dynamics AX 2012 R3, los formularios. Para ello, veremos las principales partes que componen un formulario de Dynamics AX y aprenderemos a crear y mantener nuevos formularios con el objetivo de ser capaces de consultar e introducir datos dentro del sistema. Todo esto sin necesidad de escribir una línea de código.

También seremos capaces de crear formularios con varias tablas relacionadas dentro del origen de datos, consiguiendo la funcionalidad de un formulario de tipo "maestro" / "detalle".

Por último, hablaremos de los objetos Menu y Menu Item, para ser capaces de referenciar el formulario dentro de los menús del entorno funcional de AX 2012 R3. De este modo los usuarios serán capaces de acceder al formulario y gestionar los datos que contienen.

Microsoft Dynamics AX 2012 R3 nos brinda la posibilidad de crear nuevos formularios basados en plantillas.
Para crear un formulario, primero debemos elegir un patrón de diseño, que no es más que una serie de directrices que se encargan de estandarizar la apariencia y la funcionalidad de este.
Para conseguir que un formulario implemente un patrón de diseño concreto, en AX 2012 R3 utilizamos las plantillas de formularios. Una plantilla, genera un nuevo formulario que tiene la estructura y componentes básicos especificados por un patrón de diseño. De este modo, reducimos el número de pasos que tenemos que seguir para crearlo.

Microsoft Dynamics AX 2012 R3 cuenta con las siguientes plantillas de formularios:

- DetailsFormMaster: Esta plantilla la utilizamos para crear formularios para ver y editar datos maestros.
- DetailsFormTransaction: Usamos la plantilla para crear formularios de detalles con líneas para ver y editar datos maestros que contienen líneas.
- Dialog: Se utiliza para crear ventanas de diálogos que proporcionan una interacción rápida con el usuario.
- DropDialog: Utilizamos esta plantilla para crear un pequeño formulario en forma de diálogo cuando se necesita introducir o actualizar una pequeña cantidad de datos.
- ListPage: Esta es la plantilla que se utiliza como entrada principal en cada uno de los módulos. Veremos con más detalle este tipo de formularios en la próxima cápsula.
- SimpleList: Utilizamos esta plantilla para crear una lista simple en la que ver y editar los datos.
- SimpleListDetails: Utillizamos esta plantilla para crear una lista simple en la que ver y editar datos y los detalles del registro seleccionado
- TableOfContents: Esta plantilla se utiliza para crear formularios que utilizamos para guardar datos de configuración.

En la cápsula anterior vimos los distintos formularios que tenemos en AX 2012 R3 gracias a las plantillas de formularios.
Ahora, vamos a centrarnos en una de las mas importantes. Las List Pages.
Los formularios tipo List Page son el principal modo de mostrar los datos que hay en cada uno de los módulos de AX. Este formulario nos permite visualizar los campos principales de los maestros de cada módulo y tener un acceso rápido a datos relacionados con estos maestros, así como a poder ejecutar las acciones más comunes sobre ellos.
Veremos las partes que componen este tipo de formularios y sus características principales, así como la diferencia entre lo que podemos llamar list page primario y list page secundario.
Por último, seremos capaces de crear y modificar formularios ya existentes con el fin de ampliar la funcionalidad de estos.

El sistema de seguridad de Microsoft Dynamics AX 2012 R3 implementa un modelo de seguridad basado en roles. Cada uno de estos roles tendrá asociados una serie de privilegios y permisos sobre los datos y las acciones a realizar en Dynamics AX.
Como desarrolladores, veremos, utilizando el AOT que un rol es una agrupación de especificaciones de seguridad, que están diseñadas para permitir que los usuarios puedan realizar una serie de trabajos dentro del ERP.
Desde el punto de vista del Administrador del sistema, veremos como asignar roles a los usuarios, de forma que los usuarios podrán adquirir permisos para realizar esa serie de tareas.

Como hemos dicho, cada usuario del sistema tendrá asignados uno o varios roles. Un Rol de seguridad representa el patrón de comportamiento que una persona tiene dentro de la empresa, como puede ser Gestor de clientes, gestor de proveedores, Administrador del sistema... Cada uno de estos roles estará definido por un conjunto de deberes.
Un deber es la responsabilidad de realizar una o más tareas para un trabajo. Los deberes corresponden con partes dentro del proceso de negocio, por ejemplo, el rol de gestor de proveedores puede estar compuesto de deberes mantener el maestro de proveedores, gestionar las órdenes de compra... Cada uno de estos deberes incluirá uno o más privilegios.
Un privilegio especifica el acceso que se requiere para cumplir con una tarea determinada. Por ejemplo, Mantener el maestro de proveedores necesita una serie de privilegios como pueden ser mantener las direcciones de los proveedores o mantener las cuentas bancarias de proveedores. Cada uno de estos privilegios se basa en una serie de permisos. Estos permisos incluyen el nivel de acceso sobre ciertos objetos que se requieren para llevar a cabo la función asociada a un punto de entrada. En el caso de gestionar la información de las cuentas bancarias de proveedores, necesitaremos permisos totales sobre el formulario de cuentas bancarias del proveedor y acceso desde el punto de entrada, que será un menú item.