Blog


  • February / 2017
  • Data Management en Dynamics 365 for Operations: Importación de datos maestros

    Ya tenemos aquí la nueva versión llamada Dynamics 365 for Operations, que recibimos con emoción y curiosidad a partes iguales, ya que, parte de lo que engancha de esta profesión, es que hay que estar en constante aprendizaje porque el ERP no para de evolucionar; así que nos toca “ponernos las pilas” y dominar la aplicación lo antes posible, averiguando dónde están campos y formularios, investigando el funcionamiento de los procesos, etc.

    Para ello, hoy quiero hablaros de como importar el Plan General Contable en Dynamics 365 for Operations a través de DMF (DIXF), lo que os resultará práctico para importar los datos maestros en una empresa de nueva creación de forma rápida y sencilla.

    Hay que situarse en los Espacios de trabajo (Workspaces) de Dynamics 365 for Operations – Administración de datos (Data management).

    Seguidamente se pulsa en Importar.

    Se completan los datos del formulario Importar, especificando la siguiente información:

    Formato de datos de origen, para este ejemplo concreto, Excel.

    Nombre entidad, Main account.

    Cargar archivos de importación, se elige el Excel con el plan general contable.

    Búsqueda de hojas, se pulsa en el desplegable y se elige 'Cuenta principal$'.

    En cuanto al Excel ya no es necesario generar el Excel desde el propio DMF, como pasaba en Dynamics 2012 R3, para que genere el código de la hoja de Excel, que posteriormente había que indicar en el campo Búsqueda de hojas, sino que directamente es una hoja de Excel normal que contiene los datos que necesitamos para la importación.

    A continuación, se pulsa en Ver asignación para comprobar que la relación de los datos de origen a la tabla temporal sea correcta, sino se realizan las modificaciones necesarias y se guarda.

    Se puede visualizar la asignación de forma más practica desde Detalles de la asignación.

    Una vez que se ha comprobado que la asignación es correcta, se pulsa en Importar, en el panel de acción.

    Después se actualiza la página, donde el sistema informará del estado del proceso y su conclusión.

    Es posible que os de error la importación, debido al campo Type del Plan Contable, es decir, donde se especifica que la cuenta contable es de tipo total, activo, pasivo, etc. En ese caso, hay que cambiar los valores de ese campo por el correspondiente valor numérico al que hace referencia el Enumerado DimensionLedgerAccountType en el AOT.

    Hasta aquí el proceso de importación del Plan General Contable mediante DIXF en Dynamics 365 for Operations.

    Agradecimientos a mi compañero Hugo de Jesús por su ayuda en la investigación del nuevo Dynamics 365.

     

    “Pregúntate si lo que estás haciendo hoy te acerca al lugar en el que quieres estar mañana.” - Walt Disney.

    Read More..
  • December / 2016
  • Actualización automática del tipo de cambio en Dynamics AX 2012 R3

    A muchos de nosotros durante el proceso de implantación o en la realización de análisis de mejoras en los clientes que trabajan con multidivisas, se nos ha planteado la posibilidad de automatizar el proceso de actualización de los tipos de cambio, pues bien, en versiones anteriores la única forma era realizando un desarrollo, pero en la versión actual de AX 2012 R3 tenemos la opción de automatizar este proceso en tres sencillos pasos, que se detallan a continuación.  

    Paso 1. Contabilidad General/ Configurar/ Divisas/ Configurar proveedores de tipo de cambio.

    Una vez dentro del formulario de “Configurar proveedores de tipo de cambio” pulsamos Agregar y desplegamos la lista de nombre, seleccionamos la opción de Banco Central Europeo y pulsamos Aceptar.

    Al elegir esta opción directamente rellenan los campos de clave y valor con una URL que es la que permitirá el interface para conectarse con el Banco Central Europeo.

    Cerrar el formulario.

    Una vez realizado el paso anterior, hay que proceder a ejecutar el proceso de importación de los tipos de cambio, para ello, vamos al apartado de Periódico dentro de Contabilidad general y pinchamos en Importar tipos de cambio de divisas, tal y como aparece en el siguiente paso.

    Paso 2. Contabilidad General/ Periódico/ Importar tipos de cambio de divisa

    Se abre el siguiente formulario:

    Al desplegar tipo de cambio tendremos que elegir la misma opción que configuramos para el tipo de cambio de divisa. En nuestro ejemplo seleccionamos Predeterminado

    Al desplegar Proveedor de tipos de cambio te trae el proveedor que acabamos de configurar en el paso 1. Por lo que seleccionamos Banco Central Europeo.

    En el apartado "Importar a partir de:", tenemos varias opciones, importar el tipo de cambio del día o poner una fecha concreta a partir de la cual quieres que se importen todas las fechas indicando la opción de intervalo de fechas.

    Además te recomiendo que marques los dos apartados de crear pares de divisas así como invalidar tipos de cambio existentes para que la importación sea más completa.

    Pulsar Aceptar.

    Tras estos sencillos pasos, si accedes de nuevo a los tipos de cambio de divisa y revisas cualquier divisa, podrás observar que todos están actualizados. Un ejemplo del proceso creado el día 12/12

    Si tu actividad te exige que la divisa esté actualizada a diario, lo más eficaz sería generar un lote para que este proceso de importación sea automático y se genere por ejemplo todos los días a las 6 de la mañana.

    Paso 3. Contabilidad General/ Periódico/ Importar tipos de cambio de divisa/ Lote

    Marcar procesamiento por lotes e indicar la periodicidad con la que queremos que se ejecute el lote, diario, semanal,… como se desee y pulsar Aceptar para generar el Lote.

    Espero que este blog os sea de utilidad y recuerda “Vive como si fueras a morir mañana. Aprende como si fueras a vivir siempre”. - Mahatma Gandhi.

    Read More..
  • ¿Problemas con el fichero 340 extraído de Dynamics AX al subirlo a Hacienda?

    Todos los que nos dedicamos a trabajar con ERPs, ya seamos cliente final o partners, en mayor o menor medida hemos tenido que lidiar con la problemática de los ficheros ASCII cuando generamos los impuestos, a la hora de subirlos al portal de Hacienda. En la mayoría de casos se tiene que modificar dicho fichero porque, algunas filas o columnas no corresponden con el orden en el que deberían estar para subirlas al portal de Hacienda o algún carácter no corresponde, etc. Desde mi experiencia, a continuación, os dejo una guía con los pasos a seguir en la configuración del modelo 340, para que cuando se genere el fichero ASCII y se suba al portal de Hacienda todo funcione correctamente.

    En España están obligados a presentar el modelo 340 los sujetos pasivos inscritos en el Registro de devolución mensual del IVA-IGIC, que deban presentar autoliquidaciones o declaraciones correspondientes al Impuesto sobre Sociedades, al Impuesto sobre el Valor Añadido (IVA) o al Impuesto General Indirecto Canario (IGIC) por medios telemáticos, están obligados a presentar una “Declaración informativa de operaciones incluidas en los libros registros” (modelo 340), por lo que en este caso sin previo requerimiento de Hacienda se deben presentar las operaciones registradas en los libros del IVA.

    La declaración 340 incluirá, además de los datos del obligado fiscal y datos generales (identificación, período, número total de registros, etc.), los Libros Registro que establece el Reglamento del IVA. Con carácter general los siguientes:

    • Libro registro de facturas expedidas.
    • Libro registro de facturas recibidas.
    • Libro registro de bienes de inversión.
    • Libro registro de determinadas operaciones intracomunitarias.
     

    En relación a las operaciones intracomunitarias y aquellas en las que se realice la inversión del sujeto pasivo destacar que, en la parte de la compra se realiza el juego impositivo +/- tipo impositivo (por ejemplo +21% y -21% = 0% aplicado a la base imponible) y en la venta, no se realiza dicho juego impositivo, sino que directamente se aplica un 0% a la base imponible. De esta manera cuando se genere el archivo ASCII para hacienda, los caracteres se mostrarán en el fichero en su sitio correcto.

    Por tanto, en relación con lo expuesto anteriormente para la configuración del modelo 340 en Microsoft Dynamics AX 2012 R3, es necesario tener en cuenta las siguientes peculiaridades:

    Primero. Hay que configurar los códigos de impuesto, grupos de impuestos y grupo de impuestos de artículos (Contabilidad general – Configurar – Impuestos) referidos a IVA, bienes de inversión, bienes exentos y operaciones intracomunitarias, así como las distintas modalidades que pueda haber en cada uno de ellos, ya que, posteriormente dichos impuestos serán utilizados en las transacciones que, a su vez, serán incluidas en el modelo 340.

    Segundo. Hay que situarse en el formulario Parámetros por país o región (Contabilidad general – Configurar – Impuestos – Externo) e incluir aquellos países con los que se va a tener una relación comercial, incluido España.

    Tercero. En Administración de la organización – Configurar – Comercio Exterior – Parámetros de comercio exterior – Propiedades de país/ región, hay que especificar aquellos países con los que se va a tener una relación comercial, incluido España.

    **Es importante que los formularios Parámetros por país o región y Propiedades de país/ región, estén bien configurados ya que, a la hora de generar el archivo ASCII para hacienda, dicho archivo requiere de la información contenida en ambos formularios por lo que, en caso contrario el archivo ASCII generará errores a la hora de subirlo al portal de Hacienda.

    Cuarto. Cuando llegue el periodo oportuno para presentar el modelo 340 (será mensual o trimestral, dependiendo de la empresa) en Contabilidad general – Configurar – Impuestos – España – Libros de IVA españoles, se crea un libro nuevo incluyendo aquellos códigos de impuestos que se incluyen en dicho modelo y se pulsa en Informes de IVA españoles.

    Quinto. En el formulario Informes de IVA españoles se pulsa en Crear nuevo, dónde el sistema nos muestra un formulario de consulta para cumplimentar los datos necesarios para filtrar la información acorde al modelo 340, cómo libro de IVA, descripción, periodo de liquidación, desde fecha, método de numeración, etc., y se pulsa Aceptar.

    Sexto. A continuación, en el formulario Informes de IVA españoles, tenemos una línea nueva con el libro nuevo del modelo 340 que se termina de crear.

    En este formulario encontramos las opciones:

    Líneas de informe de IVA, Para ver las transacciones que contiene el libro de IVA que se ha terminado crear.

    Totales, se visualiza el total de las transacciones que contiene el libro del IVA.

    Salida, para exportar los datos del libro de IVA en formato ASCII o imprimir. Para el formato ASCII es necesario cumplimentar ciertos datos en la pestaña general, del informe de IVA, antes de lanzar dicho formato, como Persona de contacto, Teléfono, Número de documento de la declaración y Código electrónico.

     

    Resumen, el sistema muestra un resumen del libro de IVA en formato informe.

     

    Hasta aquí el proceso de configuración del modelo 340 en España para Microsoft Dynamics AX 2012 R3.

     

    “Pregúntate si lo que estás haciendo hoy te acerca al lugar en el que quieres estar mañana.” - Walt Disney.

    Read More..
  • November / 2016
  • Autoliquidación de facturas en AX 2012 R3 (3 pasos en 1)

    Amig@s contables ¿Cuántas veces tenemos que llevar a cabo la gestión de contabilización de una factura de proveedores y luego ir al diario de pago para liquidarla cuando el pago se ha realizado con una tarjeta de crédito y por lo tanto se tiene la misma fecha que la factura? Seguro que infinitas, consumiendo tiempo muy valioso y que nunca sobra en un departamento financiero... pues bien esto se puede solucionar con Microsoft Dynamics AX simplemente configurando de una manera correcta, una condición de pago tal y como os muestro a continuación.

    1. Creamos una nueva condición de pago T01 para contabilizar todas aquellas facturas que estén domiciliadas o pagadas con una tarjeta bancaria XXXX. En Método de pago seleccionamos contra reembolso y marcamos el chek de pago en efectivo. Además en el campo Efectivo del apartado Registro tenemos que seleccionar una cuenta puente donde queremos llevar la liquidación (en el ejemplo 5550010) OJO es solo contabilidad no afecta a gestión por lo que no sirve para liquidar facturas que vayan directamente contra el banco así que, si ponéis una cuanta 572 no os la va a llevar al módulo de Bancos. Esto viene muy bien para hacer el seguimiento de las tarjetas de crédito.

    1. Contabilizar la factura

    En el siguiente ejemplo voy a contabilizar una factura del proveedor Noelia Gámez cuyo pago tengo domiciliado en la tarjeta de crédito XXXX y que se ha liquidado en la fecha de la factura por importe de 100€ IVA incluido.

    Este ejemplo lo he realizado desde un Diario de Facturas pero se puede seleccionar también desde un pedido de compra, desde la cabecera del pedido en el apartado de Precio y descuento tal y como se muestra a continuación.

    Cuando yo registro la factura el asiento que me genera es el siguiente.

    He marcado los que corresponden a la factura para que veáis claramente que se genera la factura y la liquidación de la misma en el mismo asiento.

    Si analizamos los movimientos del proveedor quedan de la siguiente manera:

    Ahora bien tenemos en nuestra cuenta puente un saldo en el Haber por el importe de la liquidación como podemos ver a continuación.

    1. Liquidación del saldo de la cuenta puente

    Este saldo de la cuenta puente se liquidará cuando contabilicemos el cargo de la tarjeta. El asiento sería de la siguiente manera:

    Después de contabilizar el cargo del banco el saldo de la cuenta puente debería de quedar saldado. Si tienes más importe del cargo (DEBE) que importes abonados (HABER) es que te falta alguna factura por contabilizar.

    Puedes crearte una condición de pago por cada una de las tarjetas que tengas. Seguro que así tienes mucho más controladas las temibles cuentas de tarjetas y además una vez que metas la factura te olvidas de ella porque sabes que va a estar liquidada en el momento de la contabilización, evitando así dejar saldos pendientes en los proveedores.

     

    Espero que este blog os sea de utilidad y recuerda “Vive como si fueras a morir mañana. Aprende como si fueras a vivir siempre”. - Mahatma Gandhi.

    Read More..
  • Baja de un Activo Fijo en el Nuevo Dynamics AX (Dynamics 365 for Operations)

    En este artículo vamos a explicar el proceso de baja de un activo fijo en el Nuevo Dynamics AX, que completa el ciclo que comenzamos en anteriores entradas de nuestro blog (podeis consultarlas en los siguientes enlaces: Adquisición de un activo fijo en el Nuevo Dynamics AX y Depreciación de un activo fijo en el Nuevo Dynamics AX).

    Se va a realizar la baja del activo 2160 (Estantería), el cual se encuentra en estado Abierto porque todavía le quedan depreciaciones por realizar, es decir, aún tiene vida útil. pero también podría estar en estado abierto por lo que faltaría depreciación por realizar.

    Para el proceso de baja no supone ningún problema que el estado del activo sea Cerrado o Abierto, lo único que en caso de que el activo esté en estado abierto, el sistema en el asiento de cancelación o baja realizará una regularización por la depreciación que hubiese pendiente, por el contrario, si el activo estuviese en estado cerrado, el sistema no realizará regularización ninguna.

    Primero se visualiza el modelo de valor del activo a cancelar y los saldos, para que cuando se termine el proceso de baja, se vea claramente como el sistema realiza los cambios pertinentes en la información del activo.

    En el formulario Modelos de valor del activo fijo seleccionado en el panel de acción se visualizan las opciones pertinentes para seguir la trazabilidad de los activos fijos, como por ejemplo las transacciones, saldo, perfil etc.

    En el activo fijo que se ha seleccionado para el ejemplo de baja, como se visualiza en la siguiente imagen, del apartado Transacciones, se adquirió el 01/01/2016 por 400$, tiene depreciaciones hasta septiembre de 2016, por lo que aún tiene vida útil y en consecuencia el asiento de baja hará una regularización por el importe que queda pendiente de amortizar.

    En el Perfil se visualiza una simulación de la amortización que queda pendiente el activo fijo seleccionado hasta su completa amortización, en este caso se utiliza una amortización lineal mensual en 4 años, es decir 48 periodos.

    A continuación, hay que situarse en Activos fijos – Activos fijos – Entradas del diario – Diario de activos fijos.

    A continuación, se crea un nuevo diario, en este caso he configurado un nombre de diario y secuencia numérica específica para la baja (igual que se realizó para la adquisición y la amortización) para tener bien diferenciado cada operación que se realice con el activo fijo.

    Una vez situados en la Líneas del diario se especifica que el tipo de transacción es Cancelación, en Cuenta se señala el activo fijo a cancelar, se cambia de campo para que el sistema complete automáticamente el apartado modelo de valor (si no se cumplimenta en la línea, el campo modelo de valor el sistema no nos deja realizar la propuesta de cancelación), o directamente sin especificar ninguna línea de asiento se pulsa en Propuestas – Cancelación.

    En el formulario de cancelación se especifica un Motivo para la cancelación si se quiere, en el Filtro se señala el activo a cancelar y se pulsa Aceptar.

    No se especifica nada en los campos débito y crédito. Seguidamente se pulsa en Validar y Registrar.

    En el diario se comprueba como el sistema ha realizado los ajustes de depreciación y la cancelación del activo. Para visualizar el detalle contable de dicha transacción hay que pulsar en Asiento, ya que, desde el Diario el sistema no muestra todos los movimientos contables que ha realizado:

    El sistema realiza todas las cancelaciones pertinentes según la parametrización que se haya definido en los Perfiles de contabilización.

    En Activos fijos – Modelos de valor, se visualiza como el estado del activo fijo ha pasado a ser “Dado de baja” y la fecha de cancelación

    A continuación, consultamos los saldos y las transacciones del activo fijo, para ver de forma más clara el proceso de cancelación que ha realizado el ERP.

    Hasta aquí el proceso de Baja/Cancelación de los activos fijos.

     

    Hay que tener en cuenta que este ejemplo se ha realizado con los datos que proporciona por defecto Contoso, por lo que habrá diferencias en la forma de contabilizar dependiendo del país de origen de los usuarios.

     

    “Pregúntate si lo que estás haciendo hoy te acerca al lugar en el que quieres estar mañana.” - Walt Disney.

    Read More..
  • September / 2016
  • Tiempo y Asistencia en AX7: Configuración Básica - Parte II

    Vamos a continuar con la configuración básica del módulo de Tiempo y Asistencia que comenzamos en la anterior entrada de nuestro blog. Ahora trataremos la parametrización y configuración de los perfiles, las ausencias, las categorías y actividades indirectas, y los acuerdos de sueldo.

     

    TIPOS DE PERFIL Y PERFILES

    Los tipos de perfil proporcionan la base para crear perfiles de tiempo de trabajo. Los perfiles abarcan todo un día y los tipos de perfil definen cómo se divide un período de 24 horas en diferentes horarios de trabajo.

    Los perfiles se utilizan para definir las horas de trabajo estándar de los trabajadores. Los perfiles deben cubrir todas las horas de trabajo en una semana laboral para poder calcular las horas de trabajo y el tiempo salarial de cada trabajador.

    Empezaremos a parametrizar los tipos de perfiles, para ello hay que posicionarse en Tiempo y asistencia - Perfiles de tiempo – Tipos de Perfil.

    Dicho proceso se puede realizar de distintas maneras. A continuación, se explicará una de las formas para configurar los tiempos reales de trabajo, cada usuario deberá elegir la forma que mejor se adapte a sus necesidades.

    Durante la ejecución del asistente se obtuvieron algunos tipos de perfil estándar, pero para obtener toda la funcionalidad necesaria, se tendrán que crear algunos más como, por ejemplo:

    • Descanso
    • Descanso pagado
    • Hora de Entrada
    • Hora de Salida
    • Horas extra
    • Hora estándar
    • Horario Flexible-
    • Horario Flexible+
     
    • Crear un perfil estándar

    Para un perfil estándar se espera que los registros del reloj de entrada y salida tengan, por ejemplo, la siguiente estructura:

    • Horario de entrada 09:00 – 09:00.
    • Horario estándar 09:00 a 14:00.
    • Horario de comida 14:00 – 15:00.
    • Horario estándar 15:00 – 18:30.
    • Horario de salida 18:30 – 18:30.
    • Horas extras 18:30 – 23:59.

    Otros perfiles que se pueden crear serían, por ejemplo, jornada intensiva, media jornada, por horas, etc.

    Después de la creación de un día, éste se puede copiar para el resto de los días de la semana mediante el uso de la función de Copiar día.

    Es conveniente comprobar siempre la opción Día de la hora del perfil, para ver las horas de trabajo totales para ese día, y Total de la hora del perfil para ver las horas durante toda la semana.

    • Los perfiles que necesitan aprobación por las horas extraordinarias

    Como no queremos que el sistema proporcione automáticamente a los usuarios, las horas extraordinarias si se inscriben antes o después de reloj de entrada / salida, ya que esto tiene un gran impacto económico. Se utilizan los códigos de cambio y un tipo de perfil secundario ya que se introduce un paso de aprobación para dicha acción. El usuario puede entrar antes, pero tiene que introducir un código de cambio para obtener el tiempo extra. Los códigos de cambio se configuran con el parámetro de aprobación activa y disponible para ser registrado.

    Los nuevos códigos de cambio se sitúan en las categorías de actividades indirectas (Tiempo y asistencia – Configurar – Categorías de actividades indirecta), se selecciona el grupo de Actividad indirecta que se vaya a utilizar y se pulsa en Actividades, para ver los códigos de dicho grupo, crear o modificar algunos de ellos.

    Es posible utilizar las vacaciones como el tipo de perfil por defecto, ya que esto no tiene ningún pago asociado. Así que en el caso de que el empleado trabaje después de su hora de salida, no se activa ningún pago.

    • Crear un perfil sin reloj de restricciones de entrada / salida

    El tipo de perfil más simple es el que no tiene reloj de entrada ni de salida. Esta solución es más rápida de instalar y cubre a cualquier persona que entre en cualquier momento del día. Se utiliza sobre todo para los "autónomos" (trabajadores externos). Con este perfil no se va a solicitar al usuario códigos de ausencia.

    Las líneas son cronológicas, la primera línea dura hasta las 24:00 y la segunda línea discurre desde las 24:00 hasta 08:00 del día siguiente. De esta forma cualquier persona puede entrar durante el día de entre de 00:00 a 23:59 y trabajar hasta las 23:00 del día siguiente sin ningún problema. Es importante comprobar la "Hora del perfil" para controlar las horas que el sistema imputa a dicho perfil.

    • Preparar la planificación del trabajo

    Por último, es posible asignar un color a cada perfil de tiempo para una mejor comprensión y visualización de los mismos. Por ejemplo, el color verde para el horario estándar.

     

    CONFIGURACIÓN DE LAS AUSENCIAS

    La ausencia de inscripción se puede hacer por los usuarios en el registro de tiempo. Si el reloj de entrada o de salida no coincide con el perfil de usuario, se solicita al usuario con un diálogo ausencia para que éste pueda registrarse por la razón por la que haya llegado tarde o temprano.

    Para empezar a parametrizar las ausencias hay que situarse en Tiempo y asistencia – Configurar – Grupos – Grupos de ausencias.

    Crear los grupos en relación con la nómina. Por ejemplo, si es una ausencia remunerada o no, vacaciones, etc. Posteriormente la nómina será más sencilla de configurar si se sigue una misma directriz en la configuración de dicho módulo.

    • Si hay trabajadores con horas de trabajo flexibles, active la casilla Reducir horario flexible para reducir el saldo de horas flexibles para los trabajadores que registran una ausencia mediante un código de ausencia en el grupo de ausencias.
    • Si hay trabajadores que realizan horas de trabajo extras, active la casilla de Deducir horas extra para reducir las horas extras para los trabajadores que registran una ausencia mediante un código de ausencia en el grupo de ausencias.
    • Se selecciona la casilla Registro para permitir a los trabajadores que especifiquen un registro de ausencia mediante los códigos de ausencia del grupo de ausencias.

    A continuación, se crean los códigos de ausencias para cada grupo, para ello, hay que seleccionar el grupo de ausencias que se quiera y pulsar en la opción Códigos de ausencias del menú de acción del formulario. Por ejemplo, se selecciona el grupo de ausencias Enfermedad y se pulsa en la opción Códigos de ausencias, para ver que códigos tiene asociados dicho grupo, así como crear, eliminar y modificar aquellos códigos que nos interesen, como se muestra en la imagen siguiente:

    Los códigos de ausencia indican los motivos de ausencias del trabajador. Para cada código de ausencia, también puede configurar diferentes motivos posibles, los cuales indican la naturaleza concreta de la usencia y así, tener más información detallada de la ausencia.

    A continuación, se van a especificar las funciones más relevantes del formulario Códigos de ausencias:

    • Método: Se indica si el registro de la ausencia, debe contarse en función de las horas de sueldo o los días de sueldo.
    • Registro: Esta opción habilita el registro para la actividad. Para que esté disponibles fasttab asistencia.
    • Continuar Ausencias: Esta casilla indica que los registros de ausencia que están asignados al código de ausencia deben continuar en el siguiente registro de hora de entrada.
    • Tipo de sueldo: Se establece un tipo de pago para el código de ausencia. Se puede hacer aquí si es el mismo tipo de pago para todos los empleados. Si difieren para algunos empleados, esta especificación se hace en la configuración del acuerdo de pago posterior.
    • Días: El número de días que se registrarán como ausencias si el trabajador no ha realizado un registro de hora de entrada.

    Por cada código de ausencia, desde la opción Coste, del panel de acción del formulario, se puede especificar el precio de coste de actividad indirecto.

    Hay que repetir el proceso de configuración de ausencias, explicado anteriormente, por cada código de ausencia que se quiera agregar al grupo de ausencia seleccionado.

     

    CATEGORIAS Y ACTIVIDADES INDIRECTAS

    Los trabajadores utilizan las actividades indirectas para crear registros de trabajos que no están directamente relacionados con ningún pedido de producción ni proyecto, por ejemplo, reuniones de personal, trabajos de limpieza, trabajos de reparación, seminarios y cursos.

    Las actividades indirectas también se pueden utilizar para registrar descansos, actividades de entrega y códigos de cambio. Los códigos de cambio se pueden utilizar para activar una bonificación o para cambiar un registro por otro.

    Las actividades indirectas se agrupan en categorías que sólo pueden contener actividades del mismo tipo de registro.

    Para seguimiento general de los trabajadores, es suficiente sólo con la creación de actividades indirectas, sin necesidad de parametrizar más secciones del módulo. También se puede configurar los costes para las diferentes actividades indirectas.

    Primero es necesario crear las categorías y posteriormente asignarle actividades, para ello hay que acceder a Tiempo y asistencia – Configurar – Categorías de actividad indirecta.

    Las actividades indirectas incluyen los siguientes tipos de registro:

    • Trabajo (trabajos generales y tareas del sistema). Actividades que no están relacionadas con un pedido de producción o proyecto concreto.
    • Descanso. Este tipo de actividad se utiliza si los trabajadores registran descansos.
    • Código de cambio. Este tipo de registro se utiliza para cambiar un registro por otro registro o para activar determinadas líneas de pago en un acuerdo de sueldo.
    • Llamada al deber. Las actividades de este tipo son necesarias cuando un empleado, que no está trabajando, es llamado al trabajo por alguna urgencia o incidente concreto (ej. Malfuncionamiento de un máquina). El sistema registra este evento que puede ser utilizado posteriormente para un pado especial.

    Se puede tener solo un tipo de registro por cada categoría, ahora bien, se pueden tener diferentes actividades por cada categoría. También se puede permitir el registro de la categoría mediante la activación del parámetro de registro del formulario de la actividad.

    Destacar que, en relación con las actividades algunas ya han sido creadas por el asistente de configuración. Dichas actividades son especificas del sistema y están relacionas con una función del sistema de tipo Trabajo, en consecuencia, este campo solo está activo para actividades indirectas con el tipo de registro Trabajo, dicho valor es estándar de este campo.  Si la actividad indirecta es un trabajo o tarea habituales con una duración determinada, como una reunión o un trabajo de reparación de una máquina, seleccione Trabajos en este campo.

    Las funciones del sistema son:

    • Trabajos
    • Hora de entrada
    • Hora de salida
    • Iniciar ayudante
    • Detener ayudante
    • Cambiar responsable
    • Enviar los registros
    • Borrar
    • Sistema en espera
    • Detener el descanso
    • Información
    • Cambiar modo de agrupación de trabajos
     
    • Actividades de descanso

    Para crear una categoría de descanso hay que elegir un tipo de registros de descanso. A continuación, se podrán crear actividades de descanso relacionadas a la categoría, pulsando en la opción Actividades del formulario de la categoría, como descansos pagados o no.

    Señalar que en el campo Tolerancia de descanso se especifica el número de minutos, una vez transcurrido el descanso, un trabajador puede crear un registro de fin de descanso antes de que se le efectúe la deducción salarial.

    Por ejemplo, los descansos se definen con una duración de 15 minutos y la tolerancia de descanso es de 3 minutos. Si un trabajador crea un registro de fin de descanso 18 minutos después de que haya comenzado el descanso, no se le efectuará la deducción salarial. Sin embargo, si el trabajador crea un registro de fin de descanso 25 minutos después de que haya comenzado el descanso, se le deducirán siete minutos del sueldo por hora.

    • Cambiar de actividad con el código de cambio

    Los códigos de cambio se utilizan para alternar diferentes tipos de acuerdos de pago y tipos de perfil en el perfil.

    La opción Aprobar el código de cambio se utiliza cuando se requiera la aprobación manual de un supervisor o director.

    El botón Excluir códigos de cambio en el panel de acción de la actividad sirve para configurar combinaciones de códigos de cambio no válidas. Éstas son combinaciones de códigos que no se pueden registrar el mismo día. Esto garantiza que un trabajador no pueda realizar registros en dos códigos de cambio en la misma fecha de perfil, que no se deban utilizar en la misma situación laboral.

    Por ejemplo, un código de cambio puede activar un pago doble de horas extra cuando el departamento de producción pide a los trabajadores que trabajen horas extra para responder a la demanda. Otro código de cambio puede utilizarse para convertir las horas extra en horas flexibles.

    • Llamada al deber

    Si desea realizar un seguimiento sobre las veces que se llama a un trabajador fuera de su turno de trabajo para acudir a un trabajo especial, deberá crear este tipo de actividades. El trabajador debe registrarse a la llegada.

    Si el usuario activa esto en cualquier momento durante un cambio, todo el tiempo de trabajo será "marcado" con esta actividad "Llamada al deber".

    En consecuencia, ésta actividad se utiliza para que el usuario obtenga un tipo de pago agregado, especial, a cada hora de trabajo. Por ejemplo, si un trabajador tiene que ir al trabajo en medio de la noche debido a que una máquina se ha detenido.

     

    TIPOS Y ACUERDOS DE SUELDO

    • Tipos de sueldo

    Para empezar, hay que crear los tipos de sueldo y para ello hay que situarse en Tiempo y asistencia – Configurar – Nómina - Tipos de sueldo.

    Los tipos de sueldo se usan para configurar acuerdos de sueldo, por ejemplo, se incluyen el salario por horas y la bonificación por horas extra, pero se pueden establecer numerosos tipos de bonificaciones e incentivos.

    Es posible establecer un tipo de sueldo como cantidad fija o porcentaje de otro tipo de sueldo. Por ejemplo, puede establecerse una bonificación por horas extra como porcentaje del salario por horas.

    Los trabajadores pueden tener coeficientes específicos para cada tipo de sueldo, que a su vez pueden configurarse para que sean válidos durante un período limitado solamente.

    Los índices de los trabajadores están relacionados con la tasa genérica de cada tipo de pago.

    Se puede establecer un porcentaje de desviación del tipo de pago genérico o establecer una tasa específica.

    En el panel de acción se encuentra la opción Cambiar sueldo el cual se identifica con un aumento salarial, a través de un aumento de índice, porcentaje o estableciendo un índice nuevo. Este cambio de sueldo actualizará las tasas correspondientes y los trabajadores genéricos.

    • Acuerdos de sueldo

    Se establece un acuerdo de sueldo para cada grupo de trabajadores remunerados según el mismo acuerdo general.

    Es posible pagar a los trabajadores según el mismo acuerdo de sueldo y que estos reciban índices o bonificaciones diferentes. Por ejemplo, una bonificación puede estar relacionada con la antigüedad, una operación concreta o una actividad.

    Los acuerdos de sueldo definen los tipos de sueldo que utilizan para las horas de trabajo especificadas para los tipos de perfil. Los tipos de horas de trabajo, o tipos de perfil, más comunes son el tiempo estándar, las horas extra y las bonificaciones. También se pueden utilizar el horario flexible en los acuerdos de sueldo, mediante la configuración de líneas de acuerdo de sueldo que utilicen los tipos de salario Horario flexible+ y Horario flexible-. El sueldo no se genera automáticamente para estos tipos de salario.

    Los cálculos de sueldo también vienen determinados por la configuración de los parámetros de cálculo.

    Es necesario poner en un período de validez en la cabecera para poder utilizar el acuerdo de pago.

    Hay que tener en cuenta que el tiempo registrado y el límite del rango del perfil del tipo de pago tienen que cubrir todos los diferentes perfiles. En la imagen, del formulario de las líneas de acuerdo de sueldo, el tipo de pago 1201 se genera por todo el tiempo que esté activado.

    La relación entre el tipo de salario y las transacciones están configuradas en los parámetros de cálculo. Hay que tener en cuenta que, como parte de la configuración estándar las horas extraordinarias también activan la hora estándar. Esto se puede cambiar en los parámetros de cálculo (Tiempo y asistencia> Configuración> Parámetros de cálculo).

    Las líneas del acuerdo de sueldo tienen una configuración día por día, así como un "día especial". Esta configuración se realizada en el calendario del perfil que define si un día es un día especial. Navidad podría caer en un martes, así que esto es muy importante tener en cuenta.

    Para este proceso habrá que situarse en Tiempo y asistencia – Configurar – Perfiles de tiempo – Días especiales, (Antes habrá que crear el grupo de ausencia y código de ausencia pertinente para después asociarlo a la creación del día especial) después se asociará el día especial creado al calendario del perfil.

     

    CONFIGURACIÓN ACUERDOS DE SUELDO

    A menudo hay diferencias entre los tipos de sueldo de los empleados dentro de una organización, aunque exista una estandarización de sueldos por perfil, pueden existir de forma adicional bonos anuales,  pagos adicional, primas, etc.. Para facilitar la asignación de los diferentes tipos de sueldo y dar cobertura a las particularidades de cada empleado, disponemos de la opción de delimitación de los acuerdos de sueldo para ajustarlos a las características de cada empleado.

    Esta funcionalidad se ubica en el módulo de tiempo y asistencia, en el formulario Acuerdos de sueldo, en concreto en las líneas de acuerdo de sueldo.

    A continuación, vamos a mencionar los parámetros más relevantes del formulario Líneas de acuerdo de sueldo.

    • Tipo de sueldo

    Es un campo obligatorio en este formulario. Se especifica el tipo de sueldo que el sistema debe aplicar para la línea del acuerdo de sueldo seleccionado.

    • Factor

    Utilice esta opción para añadir más o menos porcentaje por cada hora de trabajo. Por ejemplo, cuando se quiere añadir un 25% más de pago por hora a un empleado que realizó horas extras.

    • Tiempos

    Los tiempos sólo se aplican durante un cierto período, comprendido entre los campos Desde/Hasta. Estos campos se pueden dejar sin completar y utilizar los perfiles para que controlen la jornada del trabajador.

    • Criterios

    Se utiliza para activar el tipo de sueldo a partir de una cantidad, especificar un máximo o acotar el mismo en un intervalo concreto. Por ejemplo, se paga una bonificación si el trabajador trabaja más de 12 horas.

    • Intervalo de la fecha

    Se utiliza para activar los tipos de sueldo entre ciertos periodos, como el verano o el invierno. No debe utilizarse para días festivos, o casos similares, que serían días especiales.

    • Antigüedad

    La antigüedad se calcula en base a la fecha de antigüedad de los empleados y la configuración de asistencia. La fecha de antigüedad puede ser diferente de la fecha de contratación, no es un campo obligatorio, pero si se va a utilizar esta opción habrá que asegurarse de completar la fecha de antigüedad, en el formulario del trabajador, antes de utilizar esta función.

    • Redondear

    Se especifica la forma y los decimales que vayan a utilizar para el redondeo.

    • Unidad de recuento

    Son las medidas que se establecen dentro de un período. La unidad de recuento se pone a cero al comienzo de cada período. Si la unidad de recuento está entre los valores mínimos y máximo, se activa el tipo de pago. Esto se utiliza sobre todo para limitar la cantidad de transacciones dentro de un período.

    • Código de cambio

    Se utilizan para cambiar el perfil que esté establecido por defecto por un perfil secundario. También se puede utilizar para seleccionar qué tipo de pago puede ser activado. Por ejemplo, para la construcción de una cuenta de "tiempo libre" (en lugar de utilizar la flexibilidad horaria), cuando el usuario no debería tener tiempo extra, pero está fuera de las horas normales de trabajo.

    • Delimitación

    Operaciones: Se utiliza en las operaciones de fabricación. Si un usuario debe recibir una prima por cada hora que hace una determinada operación, este campo se activa. Identificación de proyectos y actividades:Se utiliza para proyectos internos estándar o si un cliente paga extra por un proyecto, también si un tipo de actividad del proyecto o categoría debería dar una prima de serie a través de múltiples proyectos, en este caso se deberían utilizar las delimitaciones.

    Actividad: Se trata de las actividades indirectas de tipo Trabajo, es decir, una tarea habitual con una duración determinada, como una reunión o un trabajo de reparación de una máquina.

    Código de ausencia: Los códigos de ausencia indican los motivos de ausencias del trabajador. En este campo se puede especificar un código de ausencia concreto para el acuerdo de sueldo seleccionado.

    Actividad a la entrega: Cuando los trabajadores utilizan las actividades de indirectas, con el tipo de registro A la entrega, deben registrar este tipo de actividad indirecta cuando entran a trabajar. Al registrar una actividad de entrega, el registro tendrá la hora de entrada como la hora de inicio y la hora de salida como la hora de finalización. El trabajador puede realizar registros en trabajos concretos durante este período. Las actividades de entrega se utilizan a menudo para generar bonificaciones específicas, pero también se pueden utilizar para mantener un seguimiento de la hora de entrega.

    Perfil: Como se ha explicado en anteriores blogs los perfiles se utilizan para definir las horas de trabajo estándar de los trabajadores. Este campo se suele usar si más de un perfil activa el mismo tipo de pago. También es útil para establecer primas para diferentes turnos de trabajo, por ejemplo, un turno de noche.

    Aptitud: Hace referencia a las habilidades o capacidades que tiene un trabajador en relación con su puesto de trabajo. Éstas se establecen de forma individual por cada trabajador. También se pueden utilizar para relacionar primas con alguna aptitud en concreto.

    Tipo de certificado: Este campo hace referencia a la especialización laboral de los trabajadores, por lo que es útil para la separación individual de los mismos, así como para la agrupación de empleados por especialización. Aunque también se puede utilizar las habilidades para este fin. La diferencia es que la habilidad se nivela y las certificaciones pueden caducar.

    Día especial: En este campo se especifica si hay algún día especial para el acuerdo de pago, ya que, podría ocurrir que algún día entre semana por alguna razón fuera un día especial, dando lugar a una prima especial para ese día en particular.

    • Varios

    Invertir signo: Una cantidad positiva pasa a ser negativa.

    Cancelar el pago: Si esta casilla de verificación está activada, el sistema utiliza el coste, pero no genera una transacción de pago. Si no se usa el cálculo del coste en tiempo y asistencia, este campo no aplica.

    Índice por hora / Trabajo a destajo: Puede seleccionar ambos o uno u otro.

    Tipo de perfil: Este apartado es importante ya que se especifica el tipo de perfil que se va a utilizar para el acuerdo de sueldo por cada línea de dicho acuerdo, por lo que se puede obtener un gran nivel de detalle en base a un acuerdo de sueldo general, desglosado por líneas de sueldo y a su vez diferenciando por los tipos de perfil.

     

    En próximas entregas continuaremos con el resto de configuraciones del Módulo de tiempo y asistencia.

     

    “Pregúntate si lo que estás haciendo hoy te acerca al lugar en el que quieres estar mañana.”

    Walt Disney

    Read More..
  • August / 2016
  • Tiempo y Asistencia en AX7: Configuración Básica - Parte I

    Esta primera parte sobre la configuración básica del módulo de tiempo y asistencia se divide en tres apartados: el asistente de configuración, los parámetros generales y la configuración de los trabajadores. De esta manera se obtendrá una mejor comprensión sobre la parametrización que hay que llevar a cabo en dicho módulo y se seguirá un orden, en la configuración, para no dejar nada en el tintero.

    ASISTENTE DE CONFIGURACIÓN

    Como se comentó en el bolg anterior este módulo se utiliza principalmente para medir el tiempo y la asistencia de los trabajadores, incluyendo qué puestos de trabajo y tareas están realizando durante un día de trabajo. Por otra parte, también se pueden configurar acuerdos de pago, para que los registros de tiempo y asistencia sean utilizados como base para el cálculo del pago de la nómina.

    Para empezar, hay que ejecutar el Asistente de configuración de tiempo y asistencia, el cual ayudará a crear el número de trabajo necesario para dicho módulo (reloj de entrada / salida, tiempo de espera, abortar pausa, etc.), datos predeterminados y propuesta de configuración.

    A continuación, se muestran una serie de pantallazos para que se ubique bien dónde encontrar el asistente de configuración y los pasos que éste contiene.

                      

    Después, nos situamos en Tiempo y asistencia – Configurar – Perfiles de tiempo – Perfiles.

    Los perfiles de tiempo de trabajo se crean para definir el tiempo de trabajo estándar para los trabajadores. Un perfil de tiempo de trabajo debe cubrir todas las horas de trabajo de una semana. Éste también puede incluir varios tipos de perfil para un día de trabajo, por ejemplo, la hora de entrada, la hora de salida, tiempo estándar, y las horas extraordinarias.

    Se realiza la misma operación con los días de la semana que sean laborables, es decir, de lunes a viernes, aunque variará dependiendo del modelo de negocio y sector empresarial. En este caso los sábados y domingos se estipulan como horas extras.

    Seguidamente, se crean los grupos necesarios. Para ello hay que situarse en Tiempo y asistencia – Configurar – Perfiles de tiempo – Grupos de perfiles.

    Los grupos de perfiles se pueden utilizar para configurar uno o varios perfiles de tiempo de trabajo en el mismo grupo, por ejemplo, se usan para calcular el tiempo de trabajo y las horas extra de un trabajador en función de su hora de entrada.

    Al configurar trabajadores como trabajadores con registro de horas, éstos posteriormente se asignan a los grupos de cálculo, grupos de aprobación, grupos de perfil y grupos de horario flexible, y así poder registrar las ausencias o el tiempo que pasan en trabajos concretos.

    A continuación, hay que situarse en el formulario trabajadores (Recursos humanos - Trabajadores> Trabajadores). En el apartado "Tiempo" del panel de acción, en el grupo de "Mantener", se pulsa en "Activar en terminales de registro" y se completan los campos obligatorios, los cuales hacen referencia a los grupos creados previamente.

    Por último, se inicia la Hora de entrada y salida del reloj de marcaje. Para ello nos situamos en el módulo Común – Común - Tiempo y asistencia – Hora de entrada/salida (reloj de marcaje).

    Es posible dejar la contraseña en blanco si no se ha establecido una previamente. En este caso, se ha especificado como número personal, el número del trabajador de Arnie Mondloch: 000014, que se ha utilizado en éste ejemplo, se pulsa en Iniciar sesión y, por último, en Aceptar.

    Hasta aquí el proceso de configuración previa en relación con la asistencia y ausencias de los trabajadores.

     

    PARÁMETROS GENERALES

    Este formulario se utiliza para la configuración de los parámetros generales que se deben definir con anterioridad en el módulo de tiempo y asistencia, para un correcto funcionamiento del mismo y también una correcta integración con el módulo de recursos humanos ya que, algunos parámetros se relacionan con el registro de horas, la usabilidad de las tarjetas de hora electrónica de los trabajadores (entradas, salidas, etc) y la gestión de los costes para el cálculo de las nóminas.

    Los parámetros generales se ubican en Tiempo y asistencia – Configurar – Parámetros de tiempo y asistencia.

    Primero vamos explicar brevemente las ocho secciones generales que aparecen en el formulario Parámetros de Tiempo y asistencia:

    • General: Incluyen, por ejemplo, los ajustes de uso de la contraseña o ID de tarjetas, las tasas de refresco para el formulario de registro de empleo (utilizado para la hora de entrada / hora de salida inscripciones en el tiempo y asistencia), y Dimensiones para el registro de ausencia.
    • Proyecto: Los parámetros que son relevantes en el caso de que los trabajadores hagan inscripciones en los proyectos. El registro del proyecto no está incluido en esta sección.
    • Actividades indirectas: Se especifica un diario utilizado para comunicar el registro de actividades indirectas, definir el uso de la categoría de costes y el control dimensional.
    • Precio de coste: Si utiliza pago actual (coste real) cuando se calculan los registros de los trabajadores, se especifica qué categorías a pagar deben ser incluidas en los precios de coste en esta sección.
    • Nómina: Se indica el infolog que muestra el sistema cuando el usuario pretende revertir las transacciones del salario que se han exportado a un archivo, para un sistema externo de nóminas.
    • Opciones de presentación: Esta sección se refiere a los registros efectuados en la tarjeta de horas electrónica.
    • Secuencias Numéricas: Configuración de las secuencias de numéricas que se utilizarán en el Tiempo y asistencia.
    • Restaurar valores: Como su propio nombre indica, se restaurará los valores como los valores predeterminados.

    A continuación, se hará especial mención en aquellos parámetros generales de uso frecuente, dentro de las secciones que se han explicado anteriormente. Hay muchas formas de parametrizar dicho módulo, en función de las necesidades de cada empresa, por lo que en éste blog se hará mención a una forma de configuración, cada uno deberá elegir la más adecuada para su entidad.

    • General

    El apartado Insertar autom.horario flexible+/ausencias, sirve para seleccionar el trabajo que se insertará automáticamente durante el cálculo de los registros, en el caso de que el trabajador registre menor tiempo del habitual de un día laborable. Por ejemplo, un trabajador tiene 7,5 horas al día laborable, pero solo ha registrado 6,5 horas de trabajo el lunes. Por lo tanto, la hora de trabajo que falta se registra para el trabajo que se ha seleccionado en este campo.

    Con frecuencia el apartado Insertar automáticamente flexión / ausencia se deja en blanco para que cuando se realice la aprobación del horario laboral, el sistema ofrezca un infolog de advertencia en el caso de que no se haya cumplido con el horario laboral.

    El campo Usar contraseña, se activa si los trabajadores deben usar una contraseña para la identificación. Si se desactiva la casilla, el número de personal del trabajador se usa como la identificación del trabajador.

    Utilizar ID de tarjeta no está activado porque la mayoría de las empresas no tienen un buen número de secuencia numérica de empleado. Si se desactiva la casilla, el número de personal se usa como la identificación del trabajador.

    En el Formato de horas se recomienda el uso de céntimos de hora, ya que posteriormente es más fácil relacionarlo con la nómina. Se establece el modo en que se muestra la hora en segundos, horas de 60 minutos, céntimos de hora y minutos.

    En la opción Reiniciar la hora de entrada se establece en Sí. El trabajo se reinicia la próxima vez que el trabajador registre la hora de entrada.

    Si se configura el reloj en Automático se está indicando que un registro de salida se realizó, cuando los minutos de trabajo del trabajador exceden el número de minutos que especifica en el campo Número máximo de minutos de trabajo. Si se desactiva la casilla, el trabajador tendrá que facilitar la fecha y la hora de salida la próxima vez que se registre. Por lo general, el siguiente registro se realiza cuando el trabajador entra.

    En Ajuste de inventario, se selecciona el diario de inventario que se usa para registrar el consumo de material que no está relacionado con un pedido de producción. En este campo se puede dejar el nombre de diario que vienen por defecto o establecer uno propio.

    • Proyecto

    En cuanto al nombre de diario de la Hora, se recomienda tener diferentes nombres de diario para Hora, cuota y artículo, y así poder identificar claramente los distintos diarios de tiempo y asistencia.

    Registrar automáticamente, se establece en Sí, para registrar los diarios de horas automáticamente cuando se transfieren los registros.

    Dimensión, se especifica de qué manera las dimensiones deben ser heredadas.

    • Trabajo: se aplican las dimensiones que se asignan al trabajo.
    • Trabajador: se aplican las dimensiones que se asignan al trabajador.
    • Trabajo -> trabajador: se aplican las dimensiones que se asignan al trabajo. Si las dimensiones no se asignan al trabajo, se aplican las dimensiones que se asignan al trabajador.
    • Trabajador -> trabajo: se aplican las dimensiones que se asignan al trabajador. Si las dimensiones no se asignan al trabajador, se aplican las dimensiones que se asignan al trabajo.

     

    • Actividades indirectas

    Diario contable, se selecciona el diario contable que se usa para registrar el tiempo que se ha empleado en actividades indirectas.

    En el apartado Categoría de coste, calcula el coste basado en las categorías de coste que se aplican a las actividades indirectas. Si desactiva la casilla, el coste se calcula en función de las transacciones de nómina que se generan.

    Dimensión, lo más común es una jerarquía de "Trabajador -> Trabajo".

    • Trabajo: se aplican las dimensiones que se asignan al trabajo.
    • Trabajador: se aplican las dimensiones que se asignan al trabajador.
    • Trabajo -> trabajador: se aplican las dimensiones que se asignan al trabajo. Si las dimensiones no se asignan al trabajo, se aplican las dimensiones que se asignan al trabajador.
    • Trabajador -> trabajo: se aplican las dimensiones que se asignan al trabajador. Si las dimensiones no se asignan al trabajador, se aplican las dimensiones que se asignan al trabajo.

     

    • Precio de coste

    En Tiempo y Asistencia se pueden utilizar las categorías de costes u obtener el precio de coste de las transacciones de nómina. Si éstas se van a utilizar habrá que agregar los rangos de los tipos de pago, y así tener el coste de una forma más precisa.

    En esta configuración se seleccionan aquellos aspectos que se añaden al precio de coste.

    • Nómina

    Nómina, se especifica si el usuario puede revertir los registros una vez que las transacciones de sueldo se han exportado a un archivo.

    • Error: el usuario recibe un mensaje de error y la inversión no se lleva a cabo.
    • Advertencia: el usuario recibe un mensaje de advertencia antes de que se lleve a cabo la inversión.
    • Aceptar: se realiza la inversión. No se muestra ningún mensaje al usuario.

     

    • Opciones de presentación

    En las Opciones de presentación se especifican la configuración sobre la tarjeta de hora electrónica para los registros del trabajador. Estos campos se parametrizarán si se va a usar dicha modalidad.

    • Secuencias numéricas

    Permite seleccionar la secuencia numérica que desea asociar con la referencia actual.

    • Restaurar Valores

    Para concluir los parámetros generales se encuentra el apartado Restaurar valores, el cual restaurará la configuración a la configuración por defecto.

     

    CONFIGURACIÓN TRABAJADORES

    Una vez que se han establecido los parámetros básicos en el módulo de tiempo y asistencia, pasamos a la configuración de los trabajadores, para ello nos situamos en Recursos humanos – Trabajadores – Trabajadores. En el panel de acción del formulario del trabajador se pulsa en la opción Activar en terminales de registro.

    A continuación, el sistema muestra el formulario para la creación del registro de horas de dicho trabajador.

    Los campos obligatorios se han configurado previamente tal y como se ha explicado con anterioridad en este blog.

    Se cumplimentan los campos obligatorios y aquellos que se consideren necesarios para el registro de horas del trabajador y se pulsa Aceptar. Para modificar estos campos hay que situarse en la pestaña Empleo del formulario del trabajador y pulsar en Editar. A continuación, os amplío la información sobre el apartado Empleo.

    Seguidamente, se van a repasar los parámetros que tiene el usuario que estamos utilizando para dicho ejemplo, en relación con el registro de horas que se termina de configurar. Para ello nos situamos en el formulario del trabajador en la opción Empleo.

    Identificación: Se recomienda que la identificación esté activada por motivos de seguridad. Recordar que la identificación se activa en los parámetros de tiempo y asistencia.

    ID de sueldo: Anula el ID de empleado en el caso de la exportación de transacciones de nómina y coge la información de éste campo para el cálculo del sueldo.

    ID de tarjeta: La identificación de la tarjeta se utiliza como un método de autenticación alternativo de identificación del empleado. Sólo se puede optar por utilizar el uno o el otro, es decir identificación por número de usuario o identificación a través de la tarjeta del registro de horas. Estás opciones se configuraban en los parámetros de Tiempo y asistencia.

    Versión de tarjeta: Hace referencia a una comunicación interna que tiene el sistema con la tarjeta de horas para mantenerse al día con la versión de la misma, en el caso de que se haya optado por esta opción de identificación.

    Activo: Se marca esta opción y se especifica una fecha de activación, para activar al usuario para el registro de horas. También se puede desactivar el registro de horas del usuario de tiempo y asistencia si no se selecciona esta casilla.

    Grupo de cálculo, Grupo de aprobación, Perfil estándar, Grupo perfiles y Grupo de cálculo predeterminado son campos obligatorios, los cuales han sido establecidos en el paso previo cuando se ha cumplimentado la información en el formulario Activar en terminales de registro, por ello el sistema ha traído dicha información a los campos del Registro de horas.

    Nueva agrupación de trabajos: Se establece el modo de trabajo por defecto para la actividad agregada, ya sea secuencial o por tarea. Es útil para la parte de ejecución de la fabricación.

    Categoría: Se especifica la categoría estándar para la presentación de Proyectos. Este campo se cumplimenta en caso de que se utilice el módulo de proyectos.

    Utilizar tarjeta de registro: Se utiliza esta opción para que el trabajador pueda crear registros en la tarjeta de registro electrónica desde Tiempo y asistencia.

    Configuración: Se selecciona el formulario de registro que se muestra cuando el trabajador inicia el formulario Registro del trabajo de Control de producción.

    Opciones de supervisor: Permite al usuario visualizar el menú de opciones del supervisor en el momento de la autenticación en un terminal.

    Acuerdo de sueldo: Se indica el acuerdo de sueldo que se vaya aplicar al trabajador, el cual es específico de cada empleado.

    Antigüedad: Esta fecha se utiliza para la delimitación de acuerdos salariales. Este campo se suele confundir con la antigüedad de la tarjeta del empleado.

    Código del período: Es el grupo donde se calcula la frecuencia de pago para el usuario.

    Horario flexible permitido: Se activará esta opción si el usuario se incluye en éste tipo de perfil. Las opciones Id de grupo de horario flexible, Saldo de horario flexible de apertura, Fecha de horario flexible y saldo de horario flexible sirven para establecer normas y límites para dicho perfil.

     

    Hasta aquí la primera parte de la configuración básica del módulo de tiempo y asistencia.

     

    “Pregúntate si lo que estás haciendo hoy te acerca al lugar en el que quieres estar mañana.”

    Walt Disney

    Read More..
  • July / 2016
  • Tiempo y Asistencia en AX7:

    Funcionamiento básico del módulo

    El módulo de Tiempo y Asistencia puede ser complejo a la hora de entender su funcionamiento por ello a continuación, se especifica un resumen de la usabilidad de dicho módulo, así como un mapa conceptual para facilitar la comprensión del mismo.

    • Entrada de datos:

    Se especifican y procesan los registros de tiempo y asistencia. Se crean múltiples puestos de trabajo para cada operación de producción en función de la configuración, es decir, un puesto de trabajo para cada proyecto y actividad del proyecto, un trabajo para cada actividad indirecta, código de ausencia y el grupo ausencia.

    • El cálculo de los tiempos de trabajo:

    Se realiza el cálculo / aprobación en los perfiles de tiempo para la gestión de las horas ya que, el sistema crea la cabecera y transacciones del diario de tiempo a partir de los registros iniciales. El diario puede cambiar, por lo que puede ser revertido de nuevo a sus transacciones originales mediante la importación de las operaciones de registro iniciales. El sistema requiere que haya ausencias para que el cálculo sea identificado.

    Durante el cálculo, los registros de los trabajadores se calculan frente al perfil de tiempo de trabajo utilizado para el trabajador. Cualquier falta de los registros de ausencias serán detectadas en el proceso de cálculo, esto es posible ya que las horas de registro son supervisadas por norma general por un encargado o jefe de equipo.

    Un grupo de cálculo puede contener un grupo de trabajadores que trabajan en el mismo equipo o por turnos. El cálculo se realiza para validar registros de los trabajadores, dicha tarea es generalmente realizada por un jefe de equipo o supervisor. Los grupos se establecen para proporcionar la opción de calcular los registros de varios trabajadores de una sola vez.

    • El cálculo de los parámetros y los acuerdos de sueldo:

    Los acuerdos de sueldo se utilizan para establecer la base de lo que se les va a pagar a los trabajadores, en función de los tipos de sueldo que se vayan a generar.

    A continuación, los tiempos de trabajo se calculan y se aprueban, los cuales a su vez se ejecutan a través de los parámetros de cálculo, donde los tipos de perfiles se corresponden con los registros iniciales que generan tipos de sueldo, basados en los ajustes de los parámetros de cálculo y acuerdos de sueldo.

    • Transferir:

    Destacar que la misma persona que aprueba y transfiere los registros también puede ser, por ejemplo, un director o un empleado de recursos humanos. Durante la transferencia, los registros de los cálculos se colocan en los pertinentes puestos de trabajo y tareas, en los distintos módulos relacionados con tiempo y asistencia de Microsoft Dynamics, por lo que se genera una base de nómina.

    Cuando los registros se han calculado y aprobado, la transferencia sólo puede fallar si faltan datos en otros módulos de Microsoft Dynamics relacionados con el módulo de tiempo y asistencia. Por ejemplo, los registros de ausencias no pueden ser enviados al módulo de recursos humanos, si no se han creado previamente diarios ausencias.

    Hasta aquí la introducción de Tiempo y Asistencia, en próximas entradas comenzaremos con la parametrización de dicho módulo.

     

    “Pregúntate si lo que estás haciendo hoy te acerca al lugar en el que quieres estar mañana.”

    Walt Disney

     

    Read More..
  • Depreciación de un Activo Fijo en el Nuevo Dynamics AX (AX7)

    Toda empresa está compuesta por elementos o activos de carácter duradero y temporal. Con el paso del tiempo, los activos duraderos (un móvil, un portátil o un camión) van perdiendo valor. En otras palabras, sufren una amortización o depreciación.

    Cuando queremos estimar la pérdida de valor de un activo fijo, tenemos que tener en cuenta los siguientes factores:

    • El valor amortizable. Es decir, el precio de adquisición o construcción.
    • Su vida útil, es decir, cuánto tiempo se utilizará el activo fijo.
    • Su valor remanente o valor que tendrá al finalizar su vida útil.
     

    Para la amortización de los activos fijos hay diferentes métodos, como pueden ser:

    • Amortización lineal: Este método amortiza constantemente a lo largo de la vida del activo. Así la cuota de amortización se calcula atendiendo a la siguiente fórmula;

    Cuota de amortización anual = Importe inicial - Valor remanente / Años de vida útil

    • Amortización creciente: Supone que a medida que transcurren los años la depreciación va aumentando. Su aplicación suele realizarse a través del método de suma de dígitos creciente, que se distingue del decreciente en que al primer ejercicio de amortización se le asigna el número uno, y a los ejercicios siguientes se le asignan valores numéricos sucesivamente crecientes en una unidad. Se definen una serie de números naturales desde 1 hasta n (número de periodos) con incrementos de una unidad. El sumatorio de la serie cumple con la fórmula;

    Amortización del ejercicio = Valor amortizable x 1 / Vida útil

    • Amortización decreciente: Estima que la mayor depreciación se produce en los primeros ejercicios, disminuyendo a lo largo de su vida. Su aplicación puede realizarse mediante dos métodos:

    - Método de porcentaje contstante, que consiste en aplicar un porcentaje constante a los valores que quedan pendientes de amortizar cada ejercicio económico, por lo que la cantidad que cada año se destina a amortizaciones irá disminnuyendo progresivamente.

    - Método de suma de dígitos decreciente. Para aplicar este método es necesario determinar el periodo de amortización del bien y asignar, al primer ejercicio de amortización, el valor numérico correspondiente al número de años que forman este periodo. A los ejercicios siguientes se les asignarán valores numéricos sucesivamente decrecientes en una unidad, hasta llegar al último que tendrá un valor igual a uno. Posteriormente se calculará la suma de los dígitos mediante la adición de los valores numéricos asignados a cada año, y se dividirá el valor amortizable del bien entre la suma de los dígitos para obtener la "cuota por dígito". Finalmente en cada ejercicio se dotará la amortización que resulte de multiplicar la "cuota por dígito" por el valor numérico asignado a dicho ejercicio.

     

    Vamos a ver cómo se lleva a cabo dicho proceso en el Nuevo Microsoft Dynamics AX.

     

    Señalar, que para realizar la depreciación de un activo fijo he utilizado la amortización lineal.

    Primero es importante tener bien configurado el método de depreciación que se va a utilizar. Para ello nos situamos en Activos fijos – Configurar – Depreciación – Método de depreciación.

     

    En segundo lugar, se configuran los libros de amortización para que posteriormente se pueda obtener informes relacionados a la depreciación del activo fijo.

    Una vez que se ha realizado la configuración básica de la amortización del activo fijo, pasamos a realizar la depreciación del mismo. Hay que situarse en Activos fijos – Diarios – Activos fijos:

    • Se pulsa en Nuevo.
    • Nombre: AF-DEP.
    • Descripción: Amortización Activos fijos.
    • Se pulsa en Líneas.

    Una vez en el asiento del diario, cumplimentamos los campos de la línea, como se ve en la imagen, y se pulsa en Propuestas – Propuesta de depreciación.

    En la propuesta de depreciación, se indica la fecha hasta el 31/12/2016 y se pulsa en Filtro, para filtrar por el activo fijo que nos interesa amortizar, en el ejemplo que nos ocupa es el 2170-01, y se pulsa en Aceptar, para que el sistema nos traslade la información solicitada a la línea del asiento del diario.

    A continuación, se borra la línea que teníamos previamente en el asiento, porque el sistema al trasladar la información de la propuesta, crea automáticamente las líneas nuevas necesarias.

    Se especifica la contrapartida, se pulsa valida y registrar.

    Las cuentas contables no coinciden con el PGC español, ya que para ésta demostración se ha utilizado Contoso.

    A continuación, se pulsa en Asiento para visualizar el asiento contable que ha realizado el sistema.

    Por último, nos situamos en el formulario del activo fijo y comprobamos como el estado del mismo es Cerrado, ya que se ha amortizado completamente.

     

    Hasta aquí el proceso de depreciación de activos fijos, en próximos artículos seguiremos viendo el ciclo de vida útil del activo fijo en el Nuevo Microsoft Dynamics AX, como la venta y baja de los activos.

     

    “Pregúntate si lo que estás haciendo hoy te acerca al lugar en el que quieres estar mañana.”

    Walt Disney

     

    Read More..
  • June / 2016
  • Configurar tu propio workspace para la gestión de proyectos en AX7

    Como ya hemos anticipado en otras ocasiones, el Nuevo Microsoft Dynamics AX, en adelante AX7 (disculpad a los que no les gusta este nombre “oficial”), permite configurar y personalizar diferentes espacios de trabajos (workspace).

    En versiones anteriores era muy común utilizar el Role Center para cubrir este tipo de necesidad, pero ahora podremos configurarlo de una forma muy sencilla con la posibilidad de incorporar componentes de PowerBI en el panel derecho del mismo.

    Imaginemos que dentro de la sección Administración de Proyectos queremos incluir un nuevo apartado para identificar por ejemplo los nuevos proyectos que se están creando dentro de la aplicación. El workspace por defecto que el sistema muestra en la sección Administración de Proyectos es el siguiente:

    Para modificar el workspace será tan sencillo como acceder al formulario global donde se ubican todos los proyectos que gestiona AX y hacer un filtro por aquellos criterios que queramos. En nuestro caso es muy sencillo puesto que el objetivo es filtrar por aquellos cuya Etapa del proyecto sea Creado, pero por supuesto que vamos a poder seguir utilizando los filtros avanzados para combinar criterios de búsquedas mucho más complejos.

    Para configurar filtros avanzados si fuera necesario, se accedería a la pestaña Opciones y se indicaría de forma muy similar a otras versiones:

    Una vez reflejado el filtro con los resultados esperados, vamos a poder asignarlo al espacio de trabajo. Para ello de nuevo dentro de la pestaña Opciones, tenemos una opción denominada Agregar al Espacio de Trabajo, en donde indicaremos el workspace donde queremos vincularlo reflejando si lo queremos identificar mediante icono o lista.

    Si pinchamos al botón configurar nos dará la opción de indicar el Nombre del icono y si queremos que muestre un recuento para posteriormente Aceptar la operación.

    Con esto y de forma realmente sencilla hemos podido incluir dentro de nuestro Worspace de Administración de Proyectos esta nueva sección.

     

    Read More..
  • Uso del módulo de almacenes avanzados en AX 2012 R3 sin usar Matrículas de Almacén (Pallets)

    Recientemente a un colega, un cliente le solicitó usar la nueva funcionalidad de dispositivos móviles en el almacén para controlar los movimientos de inventario, pero en su caso sin utilizar los pallets ya que en la realidad no estaban trabajando con ellos.

    El nuevo módulo de almacenes de R3 está basado en la utilización de pallets (o matriculas de almacén como ahora se llaman) por lo que configurar AX para trabajar sin ellos se hacía complejo.

    Estuvimos dándole vueltas ya que nunca se nos había planteado esta casuística, y después de hacer varias pruebas conseguimos una solución “mixta” que creemos válida para este modelo y por ello hemos querido compartirla con todos vosotros.

    Lo primero que quiero recalcar, es que este módulo NECESITA el pallet, y aunque existan opciones que permitan deshabilitarlos, en la práctica va a pedir su uso.

    Empecemos por las Dimensiones de inventario. Para poder activar la funcionalidad de Almacenes avanzados, tenemos que crear un grupo de dimensiones exprofeso que lo habilite:

    Como podéis ver en la imagen, la dimensión “License plate” se habilita y no permite cambiarla, eso sí, también se habilita “recepción en blanco” y “emisión en blanco” lo que nos da ya la posibilidad de transaccionar sin indicar pallet.

    Lo siguiente que haremos es configurar los diferentes perfiles de ubicación:

    /Warehouse management/Setup/Warehouse Setup/Location profiles:

    Vamos a configurar dos perfiles distintos, la ubicación de recepción (en donde recibimos la mercancía por defecto, esto se indica dentro del almacén “Default receipt location”) y ubicaciones de tipo “Suelo” en donde vamos a ubicarlo posteriormente. Podríamos indicar ubicaciones de tipo pasillo, estantería, balda, etc., pero para este ejemplo cuanto más sencillo mejor.

    • Perfil de ubicación de recepción:

    Como veis en la imagen hemos activado el uso del pallet y podríamos pensar que con no activarlo sería suficiente, pero ¿qué pasa si no lo activamos? Si no activamos el uso de pallet y hacemos una recepción, el mensaje que recibiremos es este:

    Por lo tanto, no usar pallet en la recepción no es una opción. Ahora bien, dado que estamos haciendo un pick y un put, desde la ubicación de recepción a una ubicación de tipo suelo, ¿por qué no eliminamos la necesidad de pallet en la ubicación de destino?

    • Perfil de ubicación de almacenaje en suelo:

    Hecho esto, tendremos que crear algunas ubicaciones de tipo Floor_NOLP y asignarlas a las directivas de ubicación:

    /Warehouse management/Setup/Warehouse Setup/Locations:

    /Warehouse management/Setup/Location directives -> Purchase Orders:

    Dentro de las acciones “Edit Query”:

    Hecho esto ya podemos crear un pedido de compra contra el almacén 24, lo confirmamos y procedemos a la recepción:

    Una vez presionamos “enter” en la cantidad, el sistema nos pide un pallet (recordemos que es obligatorio para la ubicación de tipo RECV)

    Ahora terminamos la recepción ubicando el producto en su nueva ubicación de tipo “Suelo” (usamos la opción del menú “Put away”):

    • Seleccionamos el pallet:

    • El sistema nos indica el origen:

    • Confirmamos ubicación destino:

    Y terminamos el movimiento.

    Si ahora vamos al pedido de compra y desde ahí a los trabajos, vemos lo siguiente:

    El trabajo está completado, el sistema indica que el pallet movido es el LP99, pero ¿cómo ha quedado el disponible de ese pallet?

    Como veis, el pallet LP99 no tiene stock, y si vamos a la ubicación Floor_NOLP vemos lo siguiente:

    Lo que quiere decir que nuestra mercancía está en esta ubicación, pero sin número de pallet.

     

    Con esto podríamos terminar, pero una de las cosas que podemos hacer además (y así lo usuarios no se quejarán ;-) es indicar de forma automática el pallet en la recepción. El sistema nos asignará un numero de pallet al confirmar la cantidad de recepción sin que el usuario de almacén tenga que indicar nada más.

    Para ello vamos a:

    /Warehouse management/Setup/Mobile Device/Mobile Device menú ítems y seleccionamos nuestro menú de recepción de compras:

    Indicamos “Generate license plate” y estamos listos.

    Ahora durante la recepción, el sistema no nos pedirá el pallet y cuando veamos los trabajos veremos un número de pallet generado automáticamente (según nuestra secuencia numérica) de la siguiente forma:

    Esta es la solución que nosotros hemos propuesto, permite al usuario de almacén recepcionar sin indicar pallet (aunque el sistema lo cree automáticamente) y ubicar la mercancía sin pallet, tendremos luego que configurar todos los movimientos de salida y transferencia, y todas las ubicaciones, sin pallet para cubrir el ciclo completo.

     

    Agradecer a mi colega y ex compañera en Chile, Cristina Martínez por su colaboración inestimable en la realización de este artículo. Cristina es Consultora Senior especializada en SCM y Producción y participa en proyectos de referencia en toda Latinoamérica.

     

    "El conocimiento acrecienta nuestro poder en la misma proporción en que disminuye nuestro orgullo."

    - Tristán Bernard (1866-1947) Comediógrafo y novelista francés -

    Read More..
  • Adquisición de un Activo Fijo en el Nuevo Dynamics AX (AX7)

    Los activos fijos en Dynamics AX son artículos de valor, como edificios, vehículos, tierras y equipos, que posee una persona o una organización. Por tanto, desde el Nuevo Microsoft Dynamics AX (AX7 en adelante) es posible configurar y especificar información de adquisición para los registros de activos fijos, así como, gestionar dichos activos depreciándolos y configurando un umbral de capitalización para determinar la depreciación. También es posible calcular los ajustes para los activos fijos y desecharlos.

    En Dynamics AX7 para realizar la adquisición de un activo fijo, habrá que realizar los siguientes pasos:

    Primero es importante tener bien parametrizados los nombres de diarios, es decir, nos situamos en Contabilidad General –> Configuración de diario –> Nombres de diarios, y configuramos aquellos nombres de diarios que se vayan a utilizar, en relación con el ciclo de vida útil del activo fijo (adquisición, amortización y baja), con el tipo de diario “Registrar activos fijos”.

    En segundo lugar, se configuran las secuencias numéricas propias a utilizar para los activos fijos, por lo que a través de las mismas identificaremos a primera vista, que se trata de una transacción de activos fijos. Desde el formulario Nombres de diarios, nos posicionamos en el campo Series de asientos y en la flecha desplegable se hace click en el botón derecho del ratón y se pulsa Ver detalles. A continuación, el sistema nos muestra el formulario secuencias numéricas, donde se creará una nueva personalizada para la adquisición de activos fijos.

    En tercer lugar, nos situamos en los Perfiles de contabilización de activos fijos y especificamos la cuenta contable que se va a utilizar en la Adquisición.

    NOTA: En la cuenta principal y contrapartida se especificarán las cuentas contables del plan general español, en éste ejemplo se ha utilizado la información de contoso, por ello las cuentas contables no son las correctas.
     

    En cuarto lugar, nos situamos en el formulario Modelos de valor (Activos fijos –> Configurar –> Modelos de valor), y comprobamos que tenemos asignado el modelo de valor de depreciación, que se utilizará a lo largo de la vida útil de los activos fijos. En nuestro caso hemos configurado el modelo lineal, ya que es el más común.

    El método de depreciación previamente ha sido configurado en Activos fijos –> Configurar –> Métodos de depreciación.

    En quinto lugar, daremos de alta el activo fijo desde Activos fijos –> Activos fijos –> Nuevo.

    Una vez creado el activo fijo, en la pestaña modelos de valor del activo fijo, se comprueba que el estado del mismo es “no adquirido todavía”.

    Una vez que se ha realizado la configuración básica del activo fijo, pasamos a realizar la adquisición del mismo. Hay que situarse en Activos fijos –> Entradas del diario –> Diario de Activos fijos:

    • Se pulsa en Nuevo.
    • Nombre: AF-ADQ.
    • Descripción: Adquisición Activos fijos.
    • Se pulsa en Líneas.

    Una vez situados en el formulario Diario de activos fijos, cumplimentamos los campos pertinentes en la línea:

    • Cuenta: 2170-01.
    • Descripción: Adquisición pantalla.
    • Débito: 250€.               
    • Cuenta contrapartida: Banco.

    Se valida y registra el asiento de diario para desplegar efectos en la contabilidad.

    Una vez que se ha adquirido el bien, en el formulario Asiento de diario, pulsamos en el icono de la lupa, en el panel de acción, escribimos Asiento y a continuación, el sistema muestra las transacciones del asiento que se ha realizado.

    Por último, se comprueba como desde el formulario del activo fijo 2170-01 en la opción Modelos de valor, el estado del mismo ha cambiado a Abierto.

    Hasta aquí el proceso de adquisición de activos fijos, en próximos artículos seguiremos viendo el ciclo de vida útil del activo fijo en Dynamics AX7, como la depreciación, venta y baja.

     

    “Pregúntate si lo que estás haciendo hoy te acerca al lugar en el que quieres estar mañana”

    Walt Disney

    Read More..
  • May / 2016
  • Buscar objetos en el AOT del Nuevo Microsoft Dynamics AX (AX7)

    Pues sí, hoy vamos a hablar de una característica que ha sido añadida en esta nueva versión de Microsoft Dynamics AX, y que, aunque puede parecer algo trivial, es una herramienta que nos va a ayudar a todos los que nos dedicamos a la parte técnica de este ERP. Esta herramienta es el buscador que se ha añadido dentro del panel Application Explorer y que nos permitirá realizar búsquedas de objetos dentro del AOT de una forma rápida y sencilla.

    Como ya sabéis, hasta ahora, cuando hemos necesitado buscar cualquier objeto (tabla, clase, formulario…) no nos quedaba otra que acceder al AOT e ir navegando por los distintos nodos hasta encontrarlo. Pues esta tarea se ha acabado con la llegada de AX7 gracias a este buscador. Ahora vamos a ver cómo funciona.

    Lo primero que necesitamos es tener visible el Application Explorer si no lo tenemos ya. Para eso, accediendo a Visual Studio, podemos mostrarlo desde la barra de herramientas View, opción Applicatión Explorer o con la combinación de teclas Ctrl+E.

    Una vez que lo tenemos, podemos identificar el buscador del que hablamos en la parte superior de este panel.

    Ahora solo nos quedaría introducir el texto por el que queremos buscar, y automáticamente nos aparecerán todos los objetos que contengan el texto introducido en el nombre.

    Pero ahí no queda todo, aparte de realizar la búsqueda por el nombre, somos capaces también de realizar una serie de filtros en la búsqueda que nos va a permitir conseguir el objeto que buscamos de una forma más efectiva y precisa.

    Si hacemos clic en la flecha que aparece a la derecha de la lupa del buscador, nos va a aparecer un desplegable en el que, aparte de las últimas búsquedas realizadas, se mostrarán una serie de filtros posibles, como son filtrar por tipo, por modelo, por nombre, por fecha de modificación, así como por punto de extensión.

    Ahora, solo tendríamos que pulsar en la opción que queramos realizar, por ejemplo, en el tipo, y se añadirá lo siguiente a la cadena de búsqueda:

    Poniendo entre comillas el tipo por el que queremos filtrar, ya vemos como el resultado de búsqueda es distinto, ahora nos aparecen aquellos objetos que contienen el nombre que hemos indicado y que pertenecen al tipo que hemos puesto.

    Como decíamos al principio, es algo muy sencillo y aparentemente no se trata de una gran novedad de esta versión, pero estoy seguro que más de un programador agradecerá tener este buscador en su día a día.

    ¡Saludos y hasta el próximo post!

    Read More..
  • Secuenciación de la producción en la planificación maestra con el Nuevo Dynamics AX

    Todos aquellos que han trabajado con planificación maestra saben que, los pedidos planificados generados desde este módulo, son creados en base a la configuración del grupo de cobertura usando la fecha de requisito.

    Si agrupamos por periodo, AX crea las órdenes planificadas dentro de este periodo y las ordena por antigüedad siendo la fecha de requisito la misma. Luego, dependiendo de la capacidad del recurso seremos capaces o no de cubrir toda la demanda.

    Este modelo puede ser válido en ciertos escenarios, pero existen otros en los que se hace muy necesario priorizar unos productos sobre otros a la hora de producir, bien porque hay productos prioritarios a la hora de cumplir las fechas de entrega, bien porque existe un orden de producción que optimiza el uso de recursos (por cambio de moldes, por configuración de la máquina, por equipo humano especifico, por equipo auxiliar necesario…)

    Para poder parametrizar estos escenarios, en AX contamos con la Secuenciación, gracias a ella podremos definir un orden dentro de un grupo de productos y un orden entre estos grupos de productos, siempre para un recurso concreto. Si además usamos las propiedades del recurso, podremos también asignar intervalos de capacidad a ciertos productos en un recurso específico.

    Vamos a utilizar la siguiente lista de productos para nuestro ejemplo:

    • Chocolate Negro
    • Chocolate con Leche
    • Chocolate Negro Almendras
    • Chocolate con Leche Almendras
    • Chocolate Blanco
    • Chocolate Blanco Almendras

    Es importante recalcar que la secuenciación solo funciona para los productos con fórmulas y no con lmats.

    Lo primero que vamos a generar es un presupuesto de ventas de estos productos para que el MRP genere las OPP, vamos a hacerlo con la misma cantidad y fecha para que a priori ninguno priorice sobre los otros.

    Una vez realizado, ejecutamos la planificación maestra con el siguiente resultado:

    Estos pedidos se han programado en base a la fecha de requisito (que es igual para todos) y en base a la capacidad del recurso. El orden a priori es aleatorio dentro de la misma fecha del requisito.

    A partir de aquí podemos configurar la secuenciación para establecer el orden preferido, para ello, lo primero que debemos hacer es crear es una Secuencia y sus valores:

    En este caso creamos dos secuencias, una para el chocolate Negro y con leche ya que vamos a crear un orden mezclando ambos productos y otro con el Chocolate blanco que debe ser siempre anterior al resto dado que una gota de chocolate negro en la máquina estropearía el chocolate blanco y no a la inversa (así optimizamos el tiempo de limpieza de la máquina entre productos)

    En cada secuencia, debemos crear los valores de ordenación, en el campo Categoría indicaremos un número, siendo el menor número el producto más prioritario.

    Una vez creadas las dos secuencias, debemos asignar los valores de secuencia a los distintos productos.

    Dentro de cada Secuencia, debemos asignar un valor a cada artículo, Grupo de Artículo o a todos los artículos (esto sería útil para asignar a varios productos un nivel alto de priorización y al resto de artículo un nivel bajo, sin necesidad de especificar artículo por artículo).

    Como se puede apreciar en la pantalla, lo que hemos hecho es asignar un nivel alto al Chocolate Negro, un nivel Medio al Chocolate con Leche y un nivelo Bajo al Chocolate, ya sea Negro o Con leche, con Almendras. Para el Chocolate blanco también hemos asignado este orden. Lo que no hemos realizado hasta ahora, es priorizar el Chocolate Blanco sobre el resto.

    Para hacer esto, debemos crear un Grupo de Secuencias:

    Dentro del Grupo de Secuencias, añadimos nuestras secuencias y les asignamos un orden. Al realizar esta configuración lo que estamos haciendo es priorizar de la siguiente manera:

    1. Chocolate Blanco
    2. Chocolate Blanco Alm.
    3. Chocolate Negro
    4. Chocolate con Leche
    5. Chocolate Negro Alm. & Chocolate Leche Alm.

    Una vez realizada la configuración debemos parametrizar los recursos para que tengan en cuenta esta secuenciación:

    Finalmente, para terminar la configuración debemos modificar ciertos parámetros en el plan maestro:

    Una vez activados los parámetros de secuenciación debemos indicar el horizonte de la capacidad para la programación de la secuenciación (en nuestro ejemplo 180 días). Si en ese horizonte el sistema no puede encontrar capacidad suficiente cancelará la secuenciación.

    Así mismo debemos configurar los ciclos de secuenciación (cada cuánto tiempo se repite la secuencia). En nuestro ejemplo hemos definido ciclos de un mes.

    Ahora ya podemos volver a ejecutar la planificación maestra, el resultado será el mismo que cuando lo ejecutamos al principio del artículo.

    Ejecutada, nos quedaría ejecutar la secuenciación. Es importante recalcar que la secuenciación no cambia las fechas de los pedidos planificados, lo que hace es, en una tabla temporal, proponer una nueva planificación usando los mensajes de acción para adelantar o retrasar cada pedido, y hasta que estas acciones no son aprobadas no se transfieren como fechas planificadas a los pedidos.

    Primero ejecutamos la secuenciación seleccionando el plan maestro:

    Y una vez ejecutada podemos ver la propuesta de secuenciación:

    Como podéis apreciar, el orden es distinto al de los pedidos originales, y usando las acciones, el sistema propone adelantar o retrasar las órdenes para cumplir con las prioridades. Además, podréis apreciar la columna “Campaña” que hace referencia a los ciclos de secuenciación que configuramos antes.

    Si estamos de acuerdo con esta planificación, podemos seleccionar los pedidos y “Aceptarlos” para que estas nuevas fechas de programación se trasladen a los pedidos planificados:

    Fijaros que existe una columna “Secuencia” que indica que se ha actualizado mediante la secuenciación.

     

    Por terminar, comentaros que esta funcionalidad se puede completar con las propiedades de los recursos. Por ejemplo, si además del orden, queremos que una serie de productos se fabriquen en las dos primeras semanas del mes y otros en las dos siguientes, pero cada grupo con un orden, usando las propiedades y las secuencias podremos configurarlo.

     

    "El conocimiento acrecienta nuestro poder en la misma proporción en que disminuye nuestro orgullo."

    - Tristán Bernard (1866-1947) Comediógrafo y novelista francés -

    Read More..
  • Mejoras vs. Revalorización de Activos Fijos en AX 2012 R3

    En este artículo voy a hablar sobre la diferencia entre los procesos de mejoras de activos fijos y revalorización, en Dynamics AX 2012 R3, ya que dichos procesos nos pueden llevar a confusión y mezclar conceptos.

     

    En cuanto a las mejoras en los activos hay dos formas de llevarlas a cabo en el ERP:

    1. A través de los Diarios de Adquisición

    Por ejemplo, tenemos un portátil (número de activo 2171-0004) en la empresa al cual se le realiza una mejora. Para identificar con claridad los cambios que realiza el sistema en los saldos, vamos a visualizar, los saldos del activo en cuestión antes de realizar la mejora. Para ello, nos situamos en Activos fijos –> Modelos de valor –> Consulta –> Saldos.

    Comprobamos que está en estado abierto, es decir, aún le queda vida útil, se adquirió por 1.400€, tiene una depreciación de -115,07€ y el valor neto en los libros es de 1.284,93€.

    Después nos situamos en los diarios de activos fijos y realizamos un Diario de adquisición por el importe de la mejora, sobre el activo 2171-0004. La mejora que se le ha realizado al activo asciende a 60€.

    • Tipo transacción: Adquisición.
    • Cuentas: 2171-0004.
    • Descripción: Mejora activo fijo.
    • Débito: 60€.
    • Tipo de cuenta de contrapartida: Contabilidad.
    • Cuenta de contrapartida: 77100001 Beneficios inmovilizado material.
    • Se valida y registra el diario.
     

    Volvemos a situarnos en los saldos del activo fijo y comprobamos como la adquisición ha pasado a ser de 1.460€, y el valor neto en los libros también ha aumentado a 1.344,93€ puesto que el sistema ha sumado en ambos campos los 60€ de la mejora.

    En las Transacciones también se visualizan los cambios realizados por el sistema con el detalle contable.

    2.   A través de los Diarios de ajustes de adquisición

    En el mismo activo fijo vamos a realizar otra mejora de 30€ a través de un diario de ajuste de adquisición. Para ello nos situamos en Activos fijos –> Diarios –> Activos fijos.

    • Tipo transacción: Ajuste de adquisición.
    • Cuentas: 2171-0004.
    • Descripción: Mejora activo fijo.
    • Débito: 30€.
    • Tipo de cuenta de contrapartida: Contabilidad.
    • Cuenta de contrapartida: 77100001 Beneficios inmovilizado material.
    • Se valida y registra el diario.

    Volvemos a situarnos en los saldos del activo fijo y comprobamos como la adquisición sigue siendo de 1.460€, como estaba en el ejemplo anterior, en el campo Ajuste de adquisición se especifican los 30€ de la mejora y el valor neto en los libros también se ha modificado a 1.374,93€, puesto que el sistema ha sumado los 30€ de la mejora del ajuste de adquisición.

    En las Transacciones también se visualizan los cambios realizados por el sistema con el detalle contable.

     

    La revalorización se utiliza para crear asientos con la funcionalidad “Propuesta de revalorización” de activos fijos, cuyos modelos de valor estén asociados a un grupo de revalorización. Los campos que se muestran en la forma puede variar, dependiendo de las selecciones que realice en el formulario de consulta.

    Las transacciones propuestas se crean de acuerdo con la información de la fecha y el factor establecido para cada grupo de revalorización.

    En primer lugar, hay que crear el grupo de revalorización y posteriormente asociarlo al formulario del activo fijo al que se vaya aplicar. El factor del grupo de revalorización puede ser tanto positivo como negativo, es decir, es posible aumentar el valor del activo o disminuirlo.

    Los grupos de revalorización están ubicados en Activos fijos –> Configurar –> Grupos de revalorización. Para el ejemplo se han parametrizados dos grupos, uno con factor positivo y otro negativo.

    Para asociar el grupo de revalorización al activo, nos situamos en el formulario del activo 2171-0005, en la opción Modelos de valor –> Pestaña General.

    • En este apartado en el campo Grupo de revalorización, se asocia el grupo de revalorización, en este ejemplo vamos a utilizar el GR01, con factor 0.5, para ver los cambios que realiza el sistema.

    Es importante destacar los checks: Permitir el valor neto en los libros superior a los costes de adquisición y Permitir un valor neto en los libros negativo, puest que es conveniente activarlos si el activo está asociado a un grupo de revalorización, ya que dependiendo de la revalorización que se realice puede que el valor neto supere el coste de adquisición o sea negativo, y si no están activados dichos checks nos dará error el sistema.

    Visualizamos previamente los saldos del activo 2171-0005, para que posteriormente se distingan bien los cambios que realiza el sistema.

    A continuación, nos situamos en los Diarios de activos fijos para realizar el ejemplo de propuesta de revalorización con el grupo GR01.

    En la propuesta de revalorización se filtra por el activo 2171-0005 y se pulsa aceptar, de forma que el sistema muestra los datos indicados en el asiento de diario.

    Se valida y registra el diario.

    Volvemos a situarnos en los saldos del activo para comprobar que cambios ha realizado el sistema.

    Verificamos como el sistema ha restado la revalorización indicada de 0,05 del grupo GR01, en el campo revalorización, así como también ha disminuido el valor neto en los libros por dicha cantidad.

    • Ahora se va a realizar el ejemplo con el Grupo de revalorización, GR02, con factor 5, para ver cómo se comporta el sistema, con el activo 2171-0006.

    Nos situamos en el formulario del activo 2171-0006, en la opción Modelos de valor – Pestaña General, para cambiar el Grupo de revalorización a GR02.

    Comprobamos los saldos del activo fijo 2170-0006.

    A continuación, nos ubicamos en los Diarios de activos fijos para realizar el ejemplo de propuesta de revalorización con el grupo GR02 con factor 5.

    Se valida y registra el asiento.

    Volvemos al formulario de los saldos del activo para comprobar los cambios que ha realizado el sistema.

    El sistema muestra la revalorización con el factor 5 en el campo Revalorización y lo suma al valor neto en los libros.

     

    Hasta aquí la diferenciación de procesos entre las mejorar y las revalorizaciones de un activo fijo en Microsoft Dynamics AX 2012 R3.

     

    “Pregúntate si lo que estás haciendo hoy te acerca al lugar en el que quieres estar mañana”

    Walt Disney

    Read More..
  • April / 2016
  • Días positivos y negativos en Planificación Maestra en Dynamics AX

    En ocasiones, cuando intervengo en algún proyecto en el que ya se está utilizando la Planificación Maestra, veo que los días positivos y negativos de los planes de cobertura tienen los valores por defecto que AX propone. Normalmente esto significa que, o bien no se les ha dado la debida importancia a estos campos o que incluso se desconoce su uso, lo que finalmente origina confusión a la hora de analizar los pedidos planificados resultantes de estos grupos de cobertura.

    En el artículo de hoy, vamos a tratar el uso de estos días positivos y negativos y como afectan al resultado final. Intentaré poner algún ejemplo práctico real que ayude a su mejor comprensión.

    Empezaré con los días negativos; imaginemos el siguiente escenario, en el que, gracias a nuestra correcta parametrización del MRP hemos obtenido la siguiente planificación:

    En el gráfico podréis observar cómo, partiendo de una fecha de entrega al cliente, y teniendo en cuenta todos los plazos de entrega y fabricación, el sistema ha calculado la fecha de puesta en firme del pedido de compra (14/04).

    A día de hoy (22/4) el proveedor nos llama y nos indica que no va a poder entregar la mercancía en la fecha programada del 29/4, retrasándola hasta el 1/5 debido a problemas con el transporte. A partir de aquí surgen dos opciones:

    1. Buscar una alternativa utilizando un proveedor diferente con un plazo de entrega menor (normalmente utilizando un medio de transporte más rápido, aunque más costoso)
    2. Asumir el retraso y dejar que este retraso impacte en las fechas de los pedidos planificados subsiguientes (producción y pedido de venta)

    Dependiendo cual sea nuestra estrategia dentro de la compañía querremos que el sistema nos proponga una de las dos alternativas, pero esta decisión dependerá de la cantidad de días que estemos dispuestos a asumir como retraso. En nuestro ejemplo, el retraso tendrá un impacto de 2 días en la fecha de entrega quedando de la siguiente forma:

    Por lo tanto, los días negativos los utilizaremos para definir el retraso que estamos dispuestos a asumir antes de buscar alternativas. En nuestro ejemplo, fijando los días negativos en 2, el sistema nos habría indicado el retraso utilizando los mensajes de futuro y actualizado las fechas de entrega de los subsiguientes pedidos, pero sin tomar ninguna acción adicional.

    Si, por el contrario, el retraso hubiera sido de 3 días, el sistema, utilizando los mensajes de acción, nos hubiera “recomendado” cancelar el pedido de compra y hubiera generado un nuevo requisito para ser cubierto con un nuevo pedido de compra planificado con un periodo de entrega menor.

     

    Respecto a los días positivos, su uso quizás sea el más complejo de entender, ya que va a estar ligado a la rotación del inventario y tiempo de vida de los productos.

    Los días positivos se utilizarán para que el sistema tenga en cuenta un inventario disponible en el tiempo. ¿Qué quiere decir esto? Imaginemos que trabajamos con productos perecederos, cuya vida máxima es de 3 meses, ¿tiene sentido que la planificación maestra tenga en cuenta un inventario disponible de un producto que después de 3 meses no va a existir?

    Siguiendo este ejemplo, pongamos que mi límite de cobertura es de 6 meses, y tengo un pedido de venta para ser servido dentro de 5 meses, a día de hoy, tengo el stock y por lo tanto si no he configurado bien mis días positivos, el sistema no va a generar ningún pedido de compra para cubrir ese pedido de venta. Llegado el momento de servir ese pedido, esas unidades ya no existirán por que estarán caducadas y fallaremos en la entrega.

    Si queremos que nuestra planificación maestra no tenga en cuenta el inventario disponible después de 3 meses, tendremos que fijar los días positivos en 90 días, independientemente que nuestro límite de cobertura será de 180 días. Haciendo esto, el sistema nos creará un requisito de compra para cubrir ese pedido de venta, 3 meses antes y siempre que exista stock disponible, nos propondrá su cancelación.

    Es importante recalcar, que si hemos reservado la mercancía desde el pedido de venta (manual o automáticamente), los días positivos dejarán de tener sentido, ya que estamos fijando una mercancía que está en stock a un pedido de venta, caduque posteriormente o no.

     

    Esta vez el artículo ha sido corto, y no como el de los planes de compensación :-) de hace unas semanas, espero que aun así os resulte práctico.

     

    "Defiende tu derecho a pensar, porque incluso pensar de manera errónea es mejor que no pensar."

    Hipatia (355 d. C.-415 d. C.) Filósofa y maestra neoplatónica grieg​a

    Read More..
  • “Hello World!” Empezando a programar con el Nuevo Microsoft Dynamics AX (AX7)

    A estas alturas, todos sabemos que la nueva versión de Microsoft Dynamics AX, también conocido como AX7, ya ha sido liberada, por lo que ya podemos empezar a “jugar” con ella para ver todos los cambios (muchos) que se presentan a nivel técnico.

    Aunque no es el objetivo de este post el listar todos y cada uno de ellos, sí que nombraremos el más importante de todos: El entorno de desarrollo integrado MorphX desaparece dejando paso a Visual Studio. En la versión anterior ya trabajábamos con Visual Studio para la creación de informes entre otros, pero en esta nueva versión trabajaremos con este IDE para todo lo relacionado con las tareas de desarrollo (personalmente, considero que es un avance enorme para los desarrolladores).

    Una vez nombrado esto, vamos a pasar a realizar un pequeño Hello world! dentro de nuestro nuevo AX. Para ello, lógicamente, lo primero que haremos será abrir Visual Studio 2015:

    Podemos identificar rápidamente como seguimos teniendo el AOT dentro del Application Explorer. El AOT sigue manteniendo prácticamente la misma organización que en versiones anteriores, aunque con algunos cambios.

    Nota: Si no ves el AOT, solo tienes que ir a View / Application Explorer.

    Lo primero que vamos a hacer es crear un Proyecto de Dynamics AX para organizar los elementos de nuestro desarrollo, tal y como hacíamos en versiones anteriores.

    Seleccionamos el tipo de proyecto como un Proyecto de Dynamics AX, indicamos el nombre del mismo, y pulsamos Ok.

    Ahora, ya podemos ver dentro del Solution Explorer como se ha creado una nueva solución que contiene nuestro proyecto, por lo que ya podemos comenzar a añadir nuevos objetos.

    Seguimos el proceso creando nuestra primera Runnable Class (antiguos Jobs) para así poder generar nuestro primer ¡Hola Mundo! desde el nuevo Dynamics AX. Para ello, añadimos un nuevo Item al proyecto.

    Seleccionamos Runnable Class (Job) dentro de la agrupación Code y le indicamos un nombre.

    Automáticamente, al darle al botón Add, se añade la clase a nuestro proyecto, y se abre en el editor de código, donde vemos que contiene el método main, en el cual podremos añadir nuestro código X++ del mismo modo que si estuviésemos trabajando con un Job dentro de MorphX.

    Una vez añadido nuestro código (en este caso es un código bastante simple pero que cumple con el objetivo del post), solo nos quedará guardar, compilar y ejecutar para ver el resultado. Por lo tanto, guardamos el proyecto (Ctrl + S) y compilamos el código desde Build / Build Solution.

    Cuando en la ventana Output aparezca el mensaje Dynamics AX build completed, indicará que el proyecto ha sido compilado y podemos continuar con la ejecución de la clase que hemos creado. Para poder ejecutar este Job, necesitamos establecer la clase como Startup Object, haciendo clic con el botón derecho sobre la clase marcándola para ello.

    Solo queda ejecutar el código para ver el resultado. Esto lo hacemos desde la barra de herramientas Debug / Start Without Debugging

    Et voilà!

    Aquí tenéis el resultado de la ejecución de esta sencilla clase que hemos utilizado para introducirnos en AX7. Un buen ejemplo para ir abriendo boca ¿no creéis? :)

    Read More..
  • Planes de Compensación Fijos en Dynamics AX 2012 R3 (Parte II)

    Continuamos con la segunda parte de la funcionalidad de Planes de Compensación Fijos que comenzamos en la anterior entrada del blog. 

    Una vez creado el plan de compensación tendremos que indicar al sistema cuales son los criterios por los que un empleado puede o no tener un plan asignado. Esta información se configura dentro de las “Reglas de Idoneidad” en Periódico -> Compensación -> Reglas de idoneidad:

    En nuestro ejemplo, el plan de compensación es aplicable a cualquier empleado de Madrid, pero podemos restringirlo mucho más.

    Lo primero que haremos es indicar las fechas de vigencia de esta regla y el tipo de plan (fijo en nuestro caso), elegiremos el plan para el que estamos creando la regla y a partir de este punto podemos hacer la selección:

    • Departamento: Esta información se encuentra en la posición (o puesto) del empleado

                    Estos significa que solo se aplicará el plan a aquellos empleados que estén asignados a posiciones o puestos de este departamento.

    • Sindicato: También esta información se encuentra en la posición

    • Ubicación: Hace referencia a la zona o región de compensación y también se encuentra en la posición

    • Trabajo: Hace referencia al trabajo vinculado a la posición

    ​ 

    • Función: En este caso esta información es propia del trabajo y no de la posición

    • Tipo: Al igual que con la función es información relativa al trabajo

    La utilización o no de los diferentes campos dependerá de cómo tengo estructurada mi información en recursos humanos. Imaginemos que estoy creando un plan de compensación para aquellos empleados que pertenecen a Madrid, que trabajan en el departamento de administración y cuya función es contable. En este caso puede que tengamos un trabajo “Contable” o puede que nuestro trabajo sea más específico y usemos la función del trabajo para catalogarlo como “contable”. Si es este segundo caso, tendremos que crear una regla utilizando el departamento “administración”, la ubicación “Madrid” y la función “Contable”. El sistema revisará todos los empleados que estén asignados a una posición de esa zona y ese departamento y cuyo trabajo posea la función contable.

    Finalmente podemos habilitar el check de “Habilitar Niveles” para crear esta regla solo para trabajos con una banda salarial concreta:

    Esta banda salarial está indicada en el trabajo:

    Nota: Normalmente, y dado que la matriz incorpora los salarios por niveles, no es necesario crear reglas por nivel, pero es importante conocer la opción por si se requiriese.
     

    Con la regla creada solo nos queda una última configuración; las acciones de compensación. Las acciones de compensación funcionan de manera similar a las acciones de personal. Sirven para catalogar y habilitar que acciones referentes a compensaciones podemos ejecutar con un empleado. Existen diferentes tipos:

    Los más utilizados son:

    • Contratar o recontratar
    • Merito
    • Promoción
    • General.

    En el caso de Merito, es el único que permite ajustar el salario bien por % o bien por importe cuando ajustamos a un solo empleado.

     

    Configuradas las acciones de compensación ya podremos contratar o asignar el plan a un empleado. Es importante recalcar que, dado que para aplicar la regla de idoneidad necesitamos una posición, no se puede asignar un plan de compensación a un empleado que no tenga una posición activa.

    Si lo hacemos durante la contratación: Común -> Trabajadores -> Trabajadores -> Contratar un trabajador nuevo:

    Indicaremos la opción “Asignar a un puesto” y buscaremos un puesto que cumpla nuestros requisitos (en nuestro caso solamente que sea de la región de compensación Madrid)

    Dado que tenemos las acciones de personal activas, se nos abrirá la siguiente pantalla donde podremos indicarle el plan y el importe de su salario:

    La acción de compensación fija solo podrá ser de tipo “Contratación o recontratación” y los planes seleccionables solo serán aquellos que cumplan nuestras reglas de idoneidad y pertenezcan a la misma entidad legal que la usada para contratar al empleado.

    Indicamos un importe de 90.000 € y al grabar el sistema nos indicará lo siguiente:

    Esto es así dado que el nivel salarial del trabajo relacionado con la posición era el nivel más bajo y dado que en el plan de compensación le hemos indicado una tolerancia fuerte no nos dejará continuar actualizando el campo salario a el valor más alto posible (14.000)

    Una vez contratado podremos revisar su plan dentro del trabajador en la pestaña Compensación -> Plan fijo:

    En esta pantalla podemos apreciar los factores de conversión de los que hablamos anteriormente. El sistema nos indica el equivalente mensual y horario según los factores que indicamos en las frecuencias de pago.

    Dentro de esta misma pantalla podremos asignar un nuevo plan a este empleado o realizar cambios sobre el plan actual utilizando el botón de “Cambiar compensación”:

    Utilizando una acción de tipo “merito” podremos indicar un porcentaje de incremento o un importe. Aceptamos y el sistema nos habrá creado una nueva línea:

    Nota: Tuve que cambiar el plan a una opción flexible para permitirme superar el máximo de 14.000
     

    Este aumento que hemos realizado ha sido totalmente aleatorio, el proceso más habitual es realizarlos durante un cambio de puesto, para ello dentro de un empleado, presionamos “Transferir trabajador”:

    Nos abrirá una nueva pantalla donde seleccionar la nueva posición de destino y el nuevo plan o salario:

    Realizado volvemos a comprobar los planes de compensación:

     

    Una vez revisado todo el proceso solo quedaría explicar los eventos de compensación que se utilizan para realizar cambios masivos, tanto de planes fijos como en variables. Dada la longitud de este articulo dejaré para futuras entregas tanto los planes de compensación variables como los eventos de compensación.

    Espero que os haya parecido interesante esta información. 

     

    "Defiende tu derecho a pensar, porque incluso pensar de manera errónea es mejor que no pensar."

    Hipatia (355 d. C.-415 d. C.) Filósofa y maestra neoplatónica grieg​a

    Read More..
  • March / 2016
  • Planes de Compensación Fijos en Dynamics AX 2012 R3 (Parte I)

    Recientemente hemos participado en un proyecto de AX 2012 de Recursos Humanos para una compañía de más de 3.000 empleados en más de 7 países de 3 continentes distintos.

    Una de las premisas de este proyecto era poder controlar la información salarial de cada empleado en cada país y en la medida de lo posible, preparar AX para la estandarización salarial en base a la estructura organizativa.

    Como todos sabéis, AX posee un módulo de payroll para el pago de la nómina que podría servir para llevar este control, pero este módulo solo está homologado para Estados Unidos ya que toda la configuración de impuestos se descarga automáticamente solo para este país, además en esta compañía (como en la mayoría que nos encontramos) el cálculo y pago está externalizado por lo que su uso no tenía sentido.

    Por esta razón, decidimos utilizar la funcionalidad de planes de compensación, tanto fijos como variables, para gestionar la información salarial de los empleados.

    En este artículo, por lo tanto, hablaré de los planes de compensación fijos, dejando para artículos posteriores los planes de compensación variables.

     

    Antes de describir la configuración de estos planes me gustaría dedicar unas líneas a explicar la estructura de recursos humanos en AX 2012 ya que la forma de organizar la información afecta directamente a la manera de enfocar el proyecto.

    Empezaré comentado que este módulo posee dos tipos de información de forma estándar:

    • Entidades comunes a todas las compañías:
      • Empleados
      • Puestos o posiciones
      • Trabajos
      • Departamentos
      • Entidades legales
      • Jerarquías
      • Niveles de Compensación
      • Regiones de Compensación
     
    • Entidades específicas de cada compañía:
      • Planes de compensación
      • Acciones de compensación
      • Cuadriculas de compensación
      • Reglas de elegibilidad
      • Frecuencias de pago

    Toda esta información será explicada más adelante, pero por el momento es importante tener en mente que información es compartida y cual es propia de cada empresa.

    Otro de los factores importantes es la manera en que se relacionan las distintas entidades entre sí. Las entidades principales a la hora de implementar recursos humanos son:

    • Empleados
    • Entidades legales
    • Puestos o Posiciones
    • Trabajos
    • Departamentos

    Un empleado a nivel organizativo estará asignado a una o varias posiciones. A su vez las posiciones estarán vinculadas con los trabajos de los cuales heredan información y por lo tanto un trabajo tendrá varias posiciones relacionadas. Así mismo una posición estará asignada a un departamento y a una (o varias) jerarquías de posiciones. Finalmente, un empleado estará asociado a una (o varias) entidades legales que serán las que paguen a este empleado. Es importante destacar, que una posición NO depende de una entidad legal.

    Por poner un ejemplo sencillo, imaginemos que tenemos un grupo de compañías en las que tenemos un director de recursos humanos por cada una de ellas, y a su vez tenemos un director de recursos humanos corporativo que es común para todas las compañías. En este caso deberemos crear un trabajo (Director de Recursos Humanos) que contenga toda la información relacionada con este trabajo (conocimientos, capacidades, cursos, títulos, etc.) Así mismo crearemos n posiciones “Director de Recursos Humanos Local” para cada Director de cada empresa y una posición “Director de Recursos Humanos Corporativo” para el Director corporativo. Todas estas posiciones tendrán el trabajo “Director Recursos Humanos” asociado.

    Por último, asociaremos cada posición a su departamento correspondiente y elegiremos que posición es a la que reporta (en el caso de los directores locales reportarían al CEO local y en el caso del director corporativo, reportaría al Presidente)

    Como podéis ver, en ningún caso hemos especificado la empresa pagadora ya que esa información es propia del empleado. En nuestro ejemplo es sencillo identificar que los directores locales serán pagados por la empresa en la que realizan su labor (la empresa local) pero ¿quién paga al director corporativo? Seguramente exista una empresa matriz que se encargue de estas posiciones (presidente, directores corporativos, etc.) pero podría ser cualquier otra compañía del grupo, incluso una empresa local que tenga su propio director local de RH, quien se encargue de la nómina de esta persona (luego  sus costes tendrán que ser distribuidos entre el resto de compañías) Esto es muy común en aquellas empresas que se internacionalizan y cuya matriz es así mismo la empresa local del país de origen, compartiendo oficinas para la operativa local y para los servicios compartidos.

     

    Una vez aclarados estos conceptos podemos revisar la funcionalidad de los planes de compensación.

    Los planes de compensación fijos, definen una matriz salarial de referencia compuesta por niveles y columnas. El concepto “de referencia” es muy importante ya que esta matriz indica el rango salarial que un empleado puede tener en base a los criterios que veremos más adelante, pero el salario real del empleado es indicado en el propio empleado y por lo tanto puede ser diferente a los valores de esta matriz.

    Para definir esta matriz deberemos primero configurar los niveles, para ello vamos a (siempre dentro de Recursos Humanos) Configurar -> Compensación -> Niveles:

    Existen 3 tipos de niveles (Grupo, Categoría y Paso). Su uso dependerá del nivel de detalle que tengamos en la escala.

    Por ejemplo, Grupo es el más genérico y se suele utilizar para bandas salariales (Operarios, Administrativos, Directivos). Categoría sería un nivel más detallado (Operario 1, Operario 2, Administrativo 1…) y Paso tendría aplicación en planes de carrera mucho más detallado en donde se sigue un orden de crecimiento. En mi caso que trabajo en consultoría aplicaría perfectamente (Junior 1, Junior 2, Consultor 1, Consultor 2, Consultor Senior, Gerente)

    Nota: Es importante ordenar los niveles utilizando los botones de Arriba y Abajo del formulario.
     

    Una vez creados los niveles, tendremos que configurar los puntos de referencia. Los puntos de referencia se utilizan para definir las columnas de nuestra matriz (el nivel serían las filas). Un ejemplo de su uso podría ser el clásico Mínimo, Objetivo y Máximo, pero existen casos en los que solo se crea una columna como referencia o solo dos columnas (máx. y mín.) etc.

    Al contrario que los niveles que se comparten entre todas las empresas, los puntos de referencia se deberán crear por empresa y para cada tipo de nivel, para ello iremos a Configurar -> Compensación -> Configuraciones de puntos de referencia:

    Deberemos crear un tipo de puntos de referencia para cada tipo de nivel utilizado (Grupo, Categoría y Paso). Una vez creada la cabecera entraremos en Puntos de Referencia y crearemos las distintas columnas:

    Terminada esta configuración deberemos crear las Regiones de Compensación y las Frecuencias de Pago.

    Las regiones de compensación se utilizan para separar las posiciones en distintas regiones, de esta forma dos posiciones iguales en distintas regiones podrán tener distinto salario sin tener que especificarlo por empresas. Configurar -> Compensación -> Regiones de compensación:

    Por último, deberemos configurar las frecuencias de pago. Estas frecuencias se utilizan para especificar si el salario que introduciremos en el empleado es anual, mensual, etc., y no para la frecuencia real de pago que dependerá del módulo de payroll o en este caso de una empresa externa. Configurar -> Compensación -> Frecuencias de pago:

    En esta pantalla introduciremos todas las opciones que nuestra empresa maneje, si fijamos salarios anuales y por horas en nuestras compañías solo será necesario crear estos dos tipos. Como veréis en la pantalla adjunta tendremos que indicar la conversión entre los distintos valores, por ejemplo, en un periodo anual tendremos que indicar en Anual “1” y “0,08333” en mensual, ya que cada mes es 0,08333 años o lo que es lo mismo 1/12. De la misma forma lo haremos en semanas 1/52 y en horas 1/1920… Si estamos introduciendo semanas entonces las formulas son 52 semanas en un año, 52/12 para meses, 52/52 para semanas y 52/1920 para horas (si nuestra jornada es de 1920 horas anuales)

    Existe una opción especial que es la de mensual (13) sirve para especificar un periodo mensual con 13 meses en el año, como veréis en la pantalla las conversiones serían: 13/1, 13/12, 13/52, 13/1920

    Todos estos factores de conversión se utilizarán para que el sistema muestre la conversión del salario en los diferentes periodos (veremos esta pantalla más adelante).

    Con toda esta información configurada podremos crear nuestro plan de compensación. Periódico -> Compensación -> Planes de compensación fija:

    Lo primero que tendremos que tener en cuenta antes de crear los planes es el universo de aplicación. ¿Vamos a crear un plan para todos los empleados de una zona? ¿Vamos a crear un plan para los empleados de determinada zona, para un tipo de trabajo o posición? ¿Por departamento? Todos estos factores se deben tener en cuenta antes de crear los planes ya que posteriormente tendremos que crear estas reglas de aplicación y si no lo hemos diseñado correctamente tendremos que eliminarlos y volver a crearlos.

    En nuestro caso vamos a crear un plan basado en Grupos salariales para todos los empleados de la zona de Madrid:

    • Fechas de vigencia: Fechas en las que el plan será válido, la fecha de vencimiento es opcional.
    • Código de Divisa: Divisa en la que indicamos el salario.
    • Frecuencia: Indicaremos que el salario que vamos a introducir para el empleado está calculado en base a esta frecuencia.
    • Tipo: Nivel que usaremos para crear la cuadricula (Grupo, Categoría o Paso)
    • Indicador de cotización del mercado: En la mayoría de los casos, los valores de referencia son muy diferentes por cada país y por lo tanto utilizaremos nuestra cuadricula del plan de compensación para indicarlos. Aun así, existe la opción de indicar estos valores de referencia dentro del trabajo (en este caso deberíamos tener trabajos por país o por zona):

    • Marcando el check el sistema tendrá en cuenta estos valores del trabajo a la hora de avisarnos de que el salario introducido está dentro o no de este rango. Solo se aplica a los tipos de niveles “Grupo”
    • Estructura de Compensación se creará automáticamente en el siguiente paso una vez creado el plan.
    • Habilitar Reglas: La habilitación de las reglas se utiliza para configurar el tipo de aviso o restricción a la hora de introducir el salario y compararlo con la cuadricula.
      • Recomendación: Habilita el control del salario introducido vs la cuadricula cuando ejecutemos eventos de cambio de salario (los eventos de cambio de salario se utilizan para cambios masivos que veremos en posteriores artículos). Si está habilitado el sistema nos indicará que el salario no es el adecuado, aunque podremos ignorarlo.
      • Fuera del intervalo de tolerancia: Aplica cuando asignamos a un empleado único a un plan de forma manual (distinto que los eventos de cambio masivo) y al igual que con la recomendación, compara el valor introducido con los valores de la matriz.
        • Ninguno: No hay recomendaciones.
        • Débil: No hay restricciones, pero el sistema nos avisa
        • Fuerte: No podemos introducir un salario que no esté en el intervalo.
      • Reglas de contratación: Se utiliza para indicar como calculamos los incrementos por mérito en procesos automáticos.
        • Ninguno: Se utiliza el año completo para el calculo
        • Porcentaje: Se utilizan las fechas de contratación para el cálculo.
    • Matriz de intervalo de aprovechamiento: Se utiliza para estandarizar los salarios de los empleados dentro de la matriz. Dado que podemos tener empleados para un mismo nivel con salarios diferentes, esta matriz sirve para indicar que empleados deben tener mayores incrementos y cuales menores, de tal forma que podamos con el tiempo igualarlos, para ello utilizaremos:
      • Porcentaje de utilización: Los empleados que estén dentro de este porcentaje del rango (ejemplo: empleados que estén en un 20% del rango salarial, si el rango tiene un nivel mínimo de 10.000 euros anuales y máximo de 20.000 euros anuales, significaría aquellos empleados que estén cobrando entre 10.000 y 12.000 euros anuales.)
      • Porcentaje del modificador de incremento: Valor utilizado para incrementar su salario sobre el incremento general. (ejemplo: Si aplicamos un 2% de incremento a todos los empleados de este plan, podemos indicar que a los empleados dentro del 20% inferior se les aplique un adicional sobre ese incremento general)

    Una vez creado el plan deberemos grabar (ctrl + S) para que se habilite el botón “Configurar compensación”:

    En esta pantalla dispondremos de 3 opciones para crear nuestra matriz.

    • Crearla desde cero
    • Copiarla de una matriz existente
    • Utilizar una matriz existente

    En nuestro ejemplo crearemos una matriz de cero, para ello indicamos el punto de referencia a utilizar (Min_OBJ_MAX) y presionamos aceptar. Se nos abrirá una nueva pantalla con nuestra nueva matriz ya creada:

    En esta pantalla tendremos que indicar para cada nivel los valores salariales:

    Una de las opciones con las que contamos en esta pantalla, es la de cambio masivo, esta opción nos permite hacer incrementos o modificaciones de nuestra matriz:

    Podremos indicarle incrementos porcentuales o de importe fijo y podremos indicar que niveles y que puntos de referencia están sujetos al incremento (en el caso de los niveles seleccionando las líneas de la cuadricula y en el caso de los puntos de referencia utilizando el desplegable)

    Por último, podremos volver al plan de compensación e indicar en el campo “punto de control” un punto de referencia objetivo, en nuestro caso utilizaremos “Objetivo”.

     

    Hasta aquí la primera parte del proceso, que quedará completo con la siguente entrada del blog. Espero que os resulte de utilidad.

     

    "Defiende tu derecho a pensar, porque incluso pensar de manera errónea es mejor que no pensar."

    Hipatia (355 d. C.-415 d. C.) Filósofa y maestra neoplatónica grieg​a

    Read More..
  • Depreciación de un Activo Fijo en AX 2012 R3

    Toda empresa está compuesta por elementos o activos de carácter duradero y temporal. Con el paso del tiempo, los activos duraderos (un móvil, un portátil o un camión) van perdiendo valor. En otras palabras, sufren una amortización o depreciación.

    Cuando queremos estimar la pérdida de valor de un activo fijo, tenemos que tener en cuenta los siguientes factores:

    • El valor amortizable. Es decir, el precio de adquisición o construcción.
    • Su vida útil, es decir, cuánto tiempo se utilizará el activo fijo.
    • Su valor remanente o valor que tendrá al finalizar su vida útil.
     

    Para la amortización de los activos fijos hay diferentes métodos, como pueden ser:

    • Amortización lineal: Este método amortiza constantemente a lo largo de la vida del activo. Así la cuota de amortización se calcula atendiendo a la siguiente fórmula;

    Cuota de amortización anual = Importe inicial - Valor remanente / Años de vida útil.

    • Amortización creciente: Supone que a medida que transcurren los años la depreciación va aumentando. Su aplicación suele realizarse a través del método de suma de dígitos creciente, que se distingue del decreciente en que al primer ejercicio de amortización se le asigna el número uno, y a los ejercicios siguientes se le asignan valores numéricos sucesivamente crecientes en una unidad. Se definen una serie de números naturales desde 1 hasta n (número de periodos) con incrementos de una unidad. El sumatorio de la serie cumple con la fórmula;

    Amortización del ejercicio = Valor amortizable x 1 / Vida útil.

    • Amortización decreciente: Estima que la mayor depreciación se produce en los primeros ejercicios, disminuyendo a lo largo de su vida. Su aplicación puede realizarse mediante dos métodos:

    - Método de porcentaje contstante, que consiste en aplicar un porcentaje constante a los valores que quedan pendientes de amortizar cada ejercicio económico, por lo que la cantidad que cada año se destina a amortizaciones irá disminnuyendo progresivamente.

    - Método de suma de dígitos decreciente. Para aplicar este método es necesario determinar el periodo de amortización del bien y asignar, al primer ejercicio de amortización, el valor numérico correspondiente al número de años que forman este periodo. A los ejercicios siguientes se les asignarán valores numéricos sucesivamente decrecientes en una unidad, hasta llegar al último que tendrá un valor igual a uno. Posteriormente se calculará la suma de los dígitos mediante la adición de los valores numéricos asignados a cada año, y se dividirá el valor amortizable del bien entre la suma de los dígitos para obtener la "cuota por dígito". Finalmente en cada ejercicio se dotará la amortización que resulte de multiplicar la "cuota por dígito" por el valor numérico asignado a dicho ejercicio.

     

    En Microsoft Dynamics AX 2012 R3 para realizar la depreciación de un activo fijo he utilizado la amortización lineal.

    Nos situamos en el entorno de AX 2012 R3 y seguimos los siguientes pasos para realizar la depreciación del activo fijo:

    Primero es importante tener bien configurado el método de depreciación que se va a utilizar. Para ello nos situamos en Activos fijos – Configurar – Depreciación – Método de depreciación.

    En segundo lugar, se configuran los libros de amortización para que posteriormente se pueda obtener informes relacionados a la depreciación del activo fijo.

    Una vez que se ha realizado la configuración básica de la amortización del activo fijo, pasamos a realizar la depreciación del mismo. Hay que situarse en Activos fijos – Diarios – Activos fijos:

    • Se pulsa en Nuevo.
    • Nombre: AF-AMO.
    • Descripción: Amortización Activos fijos.
    • Se pulsa en Líneas.

    Una vez en el asiento del diario, cumplimentamos los campos de la línea, como se ve en la imagen, y se pulsa en Propuestas – Propuesta de depreciación.

    En la propuesta de depreciación, se indica la fecha hasta el 31/12/2015 y se pulsa en Seleccionar, para filtrar por el activo fijo que nos interesa amortizar, en el ejemplo que nos ocupa es el 2170-01, y se pulsa en Aceptar, para que el sistema nos traslade la información solicitada a la línea del asiento del diario.

    A continuación, se borra la línea que teníamos previamente en el asiento, porque el sistema al trasladar la información de la propuesta, crea automáticamente una línea nueva.

    Se valida y registra el asiento.

    Este proceso se realizará de forma mensual, la frecuencia de amortización dependerá del proceso de amortización que se haya elegido, para los activos fijos de la empresa.

     

    Hasta aquí el proceso de depreciación de activos fijos.

     

    “Pregúntate si lo que estás haciendo hoy te acerca al lugar en el que quieres estar mañana”

    Walt Disney

    Read More..
  • Atajos de Teclado en Formularios de Dynamics AX 2012 R3

    Todos los que trabajamos en nuestro día a día con herramientas informáticas, sabemos lo útil que puede ser dejar un poco de lado el ratón y trabajar con el teclado cuando estamos haciendo una serie de tareas rutinarias. El simple hecho de aprender a trabajar con los atajos de teclado (también llamados “teclas rápidas”, “teclas de acceso rápido”, etc.) puede provocar directamente un aumento en nuestra productividad reduciendo el tiempo necesario para realizar nuestro trabajo diario.

    Como no podía ser de otra manera, los usuarios de Microsoft Dynamics AX también tienen la posibilidad de utilizar estos pequeños trucos para facilitar su día a día. Imaginemos, por ejemplo, que un usuario tiene que crear cientos de pedidos de compra/venta al día. Puede ser una tarea muy tediosa y que lleve muchas horas, y gracias al uso de estos atajos de teclado, podemos ahorrar mucho tiempo al final del día.

    ¿Cómo funcionan estas teclas rápidas en los formularios de AX? Muy sencillo, solo tenemos que pulsar la tecla “Alt” cuando estemos dentro de un formulario, y automáticamente nos aparecerán unos pequeños recuadros amarillos con la tecla correspondiente a cada uno de los procesos (N para Nuevo, M para Mantener, A para archivos adjuntos…). Pues, una vez que tenemos estos recuadros, si pulsamos la tecla, se ejecutará la opción o proceso correspondiente del mismo modo que si hiciésemos clic con el ratón.

    Como podéis ver en la imagen anterior, hay algunas letras que se repiten. Si pulsamos sobre esa tecla (una o varias veces). Iremos moviéndonos por las distintas opciones que hay, coloreando en naranja la opción activa, para, una vez que estemos sobre la que nosotros queremos, pulsemos “Enter” y se ejecute el proceso concreto.

    Ahora bien, ¿qué ocurre con los desarrollos hechos a medida? ¿nos aparecerá también esta ayuda para mejorar nuestro día a día? Pues la respuesta es sí, podemos imitar esta poderosa funcionalidad de una forma muy sencilla. Simplemente tenemos que rellenar la propiedad KeyTip del elemento que queramos ejecutar desde el teclado con la letra que queramos asociarle, tal y como se ve en la siguiente imagen.

    Espero que resulte útil este pequeño consejo ;)

    Read More..
  • Funcionalidad nueva en AX7 con el módulo de Contabilidad General (Parte II):

    Tras el evento virtual de lanzamiento con más de 4.000 asistentes virtuales, en donde AXAZURE colaboró con unos 80 contactos registrados, os seguimos contando más novedades funcionales dentro del ámbito de la Contabilidad General en AX7:

    • Capas de registro: Hasta ahora eran bien conocidas la capa Actual, Operaciones e Impuestos. Con la nueva versión de AX, se han añadido capas adicionales para poder cubrir diferentes tipos de necesidades sobre todo relacionado con el Reporting. Todas las nuevas capas que se han incluido (hasta 7 capas personalizadas) estarán habilitadas para que puedan ser explotadas a través de la herramienta Management Reporter.

    • Estructura contable simplificada: El proceso de creación, edición y mantenimiento de esta entidad ha sido simplificado en AX7, incluso se ha incorporado la posibilidad de exportar la propia estructura contable a Microsoft Excel. En nuevo formulario web soporta visualizar tanto las reglas avanzadas como la configuración del formulario de Contabilidad en la misma pantalla, por tanto esto mejora considerablemente la comprensión de su configuración.

    • Abrir en Excel: AX7 trabaja directamente con una app de Microsoft Office (os puede sonar similar al add-in que ya existía pero bastante mejorado), de tal manera que desde los propios Diarios Generales el sistema es capaz de abrir un Excel desde donde se le permite al usuario realizar toda la inserción de datos desde Excel en lugar de hacerlo en AX.

    • Ajustes del periodo de cierre: El balance general en AX7 proporciona la opción de poder visualizar los ajustes de cierre separados de las transacciones de cierre. Este cambio permitirá ayudar al equipo financiero a mejorar la información sobre los ajustes que puedan ser ordenados por los auditores durante el cierre contable.

    • Diseño para la planificación de presupuestos: Herramientas que Microsoft tenía anexas (como Forecaster) cubrían una necesidad que tenía AX para poder elaborar correctamente los presupuestos de las empresas. Con AX7 seremos capaces por fin de poder diseñar un formato concreto para la introducción de los presupuestos anuales de la compañía tanto desde el propio AX como desde Excel.

    • Asientos Relacionados: La mejora de la pantalla sobre los Asientos Relacionados es innegable, ya que por fin mostrará asientos intercompany relacionados. Aunque aparentemente no le deis mucha importancia, cada vez los proyectos de AX son más internacionales teniendo subsidiarias por varios países y es por ello que este tipo de información puede llegar a ser crucial.

     

    Read More..
  • Funcionalidad nueva en AX7 con el módulo de Contabilidad General (Parte I):

    En gran medida, prácticamente toda la funcionalidad que teníamos en la versión AX 2012 R3 se replica en el Nuevo Microsoft Dynamics AX, aunque a lo largo de estos últimos meses sí que hemos podido identificar algunas mejoras en diferentes módulos.

    En este blog, intentaremos desglosar aquellas que nos han llamado más la atención dentro de Contabilidad General.

    • Workspaces: Como podéis identificar en algún vídeo que ya hemos comentado esta nueva característica de AX7, la versión que subió Microsoft como Technical Preview, identificaba los espacios de trabajo con pequeñas imágenes que se han sustituido por unos iconos planos mucho más visuales y agradables a la vista. Los 2 workspaces principales en Contabilidad General serán “Cierre del periodo financiero” y “Procesamiento de diarios generales” como se identifican a continuación (no se entrará en detalle de cada uno de ellos puesto que serán explicados en sus pertinentes cursos):

    • Dimensiones Financieras: Por fin, volvemos a tener varias columnas para indicar las dimensiones financieras, recuperamos la visión que teníamos en AX 2009 pero por supuesto sin tener que licenciarlas como se hacía en aquella época. La decisión en 2012 de tener un campo que englobaba todas las dimensiones financieras generó bastante problemática tanto a usuarios a la hora de introducir datos como responsables de control de gestión a la hora de extraer información de dichas dimensiones.

    • Actualización de los tipos de cambio: Cuántas veces hemos tenido que desarrollar un servicio web para consultar los tipos de cambio y traerlos a AX. Con el Nuevo Microsoft Dynamics AX puedes utilizar una subscripción con la empresa OANDA, que nos permitirá configurar las divisas y la frecuencia de actualización de los tipos de cambio para su ejecución tanto manual como automática (lote).

    • Calendarios del libro mayor: Con AX7 el departamento de control de gestión será capaz de poder organizar según desee los estados asociados a un mismo calendario fiscal afectando a varias entidades legales o compañías. De esta forma tanto el mantenimiento como el cierre de periodos se podrá llevar a cabo de una forma globalizada para todas las empresas que puedan formar parte de la instalación AX.

    • Diario General Global: Existirá un nuevo Diario General que trabajará de forma globalizada, es decir, para aquellas empresas que centralizan servicios a través de una filial les será muy útil puesto que no tendrán que estar cambiando entre empresas en AX. Por tanto, esto permitirá imputar asignaciones contables a diferentes empresas desde la comodidad de trabajar con el mismo formulario, seleccionando la empresa al crear el diario. Por supuesto, toda esta funcionalidad respetará los roles de seguridad de tal manera que los usuarios que no puedan visualizar información de otras empresas, se seguirá controlando.

    • Nuevo módulo para Impuestos: Los impuestos están consolidados en un nuevo módulo siendo este ubicado de forma distinta de la sección de contabilidad general, la única pega es que han incluido dentro del grupo denominado Impuestos indirectos tanto la configuración de los Impuestos tradicionales como las propias retenciones que se puedan configurar. Este tipo de nomenclatura de grupo puede resultar algo ambiguo para un fiscalista ya las retenciones no se tienen porqué considerar como un impuesto indirecto.

    • Nuevos Informes Financieros: Esta vez y de forma transparente para el usuario, podremos consumir Management Reporter directamente desde AX a través de los Informes Financieros. Ya no será necesario una integración aislada como sucedía con AX 2012 lo que nos permite ampliar de forma considerable el abanico del reporting financiero teniendo toda la trazabilidad desde la propia aplicación. Los filtros que se han incluido en cada uno de los informes basados en Atributos, Dimensiones financieras y Situaciones sin necesidad de tener que definir esto de forma previa en el diseño del informe a través del Management Reporter, será también una característica que guste mucho.

    • Cambios en el workflow: Ese color amarillo tan intuitivo que veíamos a la hora de poder Enviar Flujos de Trabajo, desaparece, y ahora encontraremos un botón un tanto menos “provocador” para poder Enviar, Aprobar, Delegar…

    • Mejora de integración de PowerBI para la información de análisis financieros: AX7 proporciona una función que permitirá consumir el paquete de contenido “Dynamics AX – Rendimiento Financiero”, que facilitará el despliegue de PowerBI en el propio AX creando un potente panel o cuadro de mandos sin necesidad de salirse del sistema.
    Read More..
  • February / 2016
  • Configuración de Royalties o Regalías en AX 2012 R3

    La verdad es que la traducción al castellano para llevar a cabo la configuración de Royalties en AX 2012 R3  no es que sea de las más intuitivas, pero la funcionalidad de las “Regalías” puede llegar a ser verdaderamente interesante.

    Como sabéis el derecho que hay que pagar al titular de una patente por utilizarla o explotarla comercialmente se denomina Royalty. Pues bien, esta funcionalidad se puede llevar a cabo perfectamente desde AX con funcionalidad “out of the box” o estándar. Para ello en primer lugar accederemos al módulo de Proveedores, concretamente a Parámetros de Proveedores / Agente y regalías para poder parametrizar toda la configuración requerida, sobre todo, nombres de diarios y cuentas contables:

    NOTA: Antes de trabajar con esta funcionalidad, por favor confirma que en la configuración de la licencia de tu AX, concretamente en la sección Acuerdos Comerciales, tienes marcado el check de “Regalías”.

     

    Configurado dicho formulario se accederá dentro del módulo de Proveedores / Común / Regalías y en concreto a “Acuerdos de regalías”.

    A nivel de cabecera, este formulario se caracteriza porque permitirá configurar el Acuerdo de royalty que tienes definido con el Proveedor en cuestión permitiendo elegir el tipo de fecha de cálculo y el criterio de acumulación (Factura, semanal, etc.).

    A nivel de línea, la parte más interesante se basa en la pestaña Selección, desde donde se elegirá un producto al que se le pueda aplicar el royalty (ojo tiene que estar en concordancia con la categoría de compra definida a nivel de Parámetros).

    Y en la pestaña Importes de regalías, que permitirá indicar el porcentaje de Royalty a aplicar dependiendo del importe.

    Con esta configuración realizada, será necesario lanzar el proceso de Validación del Acuerdo de regalía, indicando el código de Empleado que lo valida.

    A partir de esta configuración, cualquier Pedido de Venta que se facture y coincida con el Producto indicado en la pestaña Selección estando dentro de los importes de regalías, generará de forma automática un registro en el formulario denominado Reclamaciones de Regalías (Royalty Claims) con estado Calculado.

    Para cambiar de estado Calculado a Aprobado, se revisará dicho registro, y se pulsará “Aprobar regalías”.

    Una vez que el Royalty calculado ha sido aprobado, se procederá a llevar a cabo el proceso para lanzar el cálculo y registro mediante el botón “Procesar regalías” que llevará a cabo la generación de una nueva factura al proveedor del royalty, con el consiguiente registro contable.

    A partir de este momento, el procedimiento para realizar el pago de la factura al proveedor será como cualquier otra liquidación de deuda de un proveedor.

    Read More..
  • Baja de un Activo Fijo en AX 2012 R3

    En este caso vamos a explicar el proceso de baja de un activo fijo en Microsoft Dynamics AX 2012 R3.

    Se va a realizar la baja del activo 2170-12 (Teclado Normal), el cual se encuentra en estado Cerrado porque se ha depreciado completamente, pero también podría estar en estado abierto por lo que faltaría depreciación por realizar. Para el proceso de baja no supone ningún problema que el estado del activo sea Cerrado o Abierto, lo único que en caso de que el activo esté en estado abierto, el sistema en el asiento de cancelación o baja realizará una regularización por la depreciación que hubiese pendiente.

    Primero se visualiza el modelo de valor del activo a cancelar y los saldos, para que cuando se termine el proceso de baja, se vea claramente como el sistema realiza los cambios pertinentes en la información del activo.

    Comenzamos el proceso de baja situándonos en el módulo de Activos fijos – Diarios – Activos fijos.

    Una vez en el formulario de Diarios de activos fijos, realizamos los siguientes pasos.

    • Se pulsa en Nuevo.
    • Se elige el Nombre de diario: Baja Activos Fijos.
    • Se pulsa en Líneas.

     

    En el formulario Asiento del diario se cumplimentan los siguientes campos:

    • Fecha: Es importante que la fecha de baja, sea posterior a la última depreciación del activo, sino el sistema nos mostrará un error.

    • Tipo de transacción: Cancelación.
    • Cuenta: Se elige la cuenta del activo fijo que se va a dar de baja.
    • Modelo de valor: Se completa automáticamente por el sistema, ya que así se ha parametrizado. En éste ejemplo la empresa trabaja con el modelo de depreciación Lineal.
    • Descripción: Se indica un enunciado breve, que haga referencia a la operación que se está llevando a cabo.
    • Crédito: En anteriores versiones de Microsoft Dynamics AX se señalaba un uno, debido a que el sistema requería que se especificara un dígito en el Crédito. En el caso de Dynamics AX 2012 R3, no es necesario.
    • Tipo de cuenta de contrapartida: Contabilidad. Se completa por defecto por el sistema.
    • Cuenta de contrapartida: 55500004. Se completa por defecto por el sistema.

    Por último, se valida y se registra el diario.

    En el formulario asiento del diario, pulsamos en ConsultasAsiento, para comprobar como el sistema ha utilizado las cuentas contables pertinentes para la cancelación, es decir, cancela las cuentas de adquisición y amortización, y utiliza las cuentas puente de baja que se han parametrizado 55500003 y 55500006.

    Por otra parte, si nos situamos en el formulario Saldos de activos fijos (situado en Activos fijos - Modelo de valor – Consultas – Saldos), para comprobar si se ha realizado alguna modificación, en este ejemplo como se amortizó completamente el activo antes de su cancelación, los campos Cancelación y Pérdidas/ganancias, están a cero.

    El estado del activo fijo también cambia a Dado de baja.

    Si se hubiese realizado el proceso de baja con un activo fijo, que aún tuviese vida útil, y se da de baja porque se ha producido un robo en la empresa o se reemplaza el activo por un modelo nuevo, aparecerían las cantidades pertinentes en los campos Cancelación y Pérdida/ganancia del formulario Saldos de activos fijos.

    Por ejemplo, vamos a ver los saldos del activo 2170-06, que es un monitor de pantalla, en el cual se ha realizado el diario de baja, porque se va a cambiar por un modelo nuevo.

     

    • Estado del activo antes del Diario de baja. Es Abierto, aún le queda vida útil al activo.

    • Saldos antes del diario de baja.

    • Asiento Cancelación/Baja. Se comprueba como el sistema realiza los ajustes de amortización precisos para cancelar lo que queda pendiente de depreciar de dicho activo.

    En ConsultasAsiento, se aprecia mejor los cambios en las partidas contables.

    • Estado del activo tras la cancelación y saldos.

    El sistema ya ha cambiado el estado ha Dado de baja y en los Saldos el sistema muestra la depreciación, el ajuste de depreciación y la pérdida que se ha obtenido por la baja de dicho activo.

    Hasta aquí el proceso de baja o cancelación de un activo fijo en Microsoft Dynamics AX 2012 R3.

     

    “Pregúntate si lo que estás haciendo hoy te acerca al lugar en el que quieres estar mañana”

    Walt Disney

    Read More..
  • January / 2016
  • Instalación y Configuración de Analysis Services en Dynamics AX 2012 R3

    Muy buenas a todos,

    Actualmente nos encontramos inmersos en la producción de un nuevo curso para consultores técnicos sobre Dynamics AX, este curso tratará sobre todo lo relacionado con el Reporting para Microsoft Dynamics AX 2012 R3. Es por ello que nos encontramos ante la necesidad de instalar y configurar SQL Server Analysis Services (aka SSAS) en nuestro entorno de desarrollo con el objetivo de poder trabajar con los cubos OLAP que nos proporciona el sistema. Por ello, vamos a aprovechar para escribir este artículo con los pasos a seguir para una correcta instalación y configuración de SSAS.

    Lo primero que tenemos que hacer es instalar Analysis Services en nuestro servidor, siempre y cuando no lo tengamos ya instalado. Para ello, realizaremos una instalación desde cero, o añadiremos el componente a una ya existente, en función de nuestras necesidades.

     

    Una vez instalado, y estando seguros de que el servicio de SSAS está en ejecución, continuamos añadiendo el componente de SSAS para Dynamics AX a nuestro entorno de desarrollo, para ello, ejecutamos el instalador de Dynamics AX y seguimos los siguientes pasos:

    • Seleccionamos añadir un nuevo componente a nuestra instalación.

    • Marcamos “Configuración de Analysis Services”.

    • Hay que asegurarse de que cumplimos todos los requisitos previos, y en caso de no cumplir alguno solucionarlo para poder continuar.

    • Seleccionamos la instancia de SSAS que acabamos de instalar para configurarla en AX.

    • Indicamos el AOS y la Base de Datos sobre la que vamos a trabajar.

    • Comienza el proceso de instalación, en el que podemos ver el progreso de la misma, hasta que nos aparece la pantalla Instalación finalizada correctamente.

     

    • Una vez finalizado, podemos ver el informe resumen de configuración. En este podemos ver que la instalación finalizó correctamente y nos indica que pasos debemos seguir a continuación.

    El siguiente paso sería configurar el servidor de SSAS en Dynamics AX. Para ello:

    • Verificamos la configuración de la Divisa y el Tipo de cambio desde Administración del Sistema / Configurar / Parámetros del sistema. Aquí debemos tener configurados la divisa y el tipo de cambio del sistema.

    • También podemos verificarlo accediendo a Administración del Sistema / Configurar / Business Inteligence / Analysis Services / Servidores de análisis. Una vez en este formulario seleccionamos nuestro servidor, y hacemos clic en Información de tipo de cambio.

    Por último, nos quedaría implementar los cubos existentes desde los proyectos de AX para poder procesarlos directamente en SSAS.

    • Desde el cliente de AX vamos a Archivo / Herramientas / Herramientas de Business Intelligence (BI) / Asistente para proyecto de SQL Server de Analysis Services y seguimos los pasos que se ven en las siguientes imágenes.

          

    • Una vez finalizado, ya tendremos disponibles los cubos OLAP que encontramos de forma estándar en el sistema para realizar el análisis de la información.

    Espero que os resulte de utilidad, ¡feliz día!

     

    Read More..
  • Venta de un Activo Fijo en AX 2012 R3

    Cada país tiene sus propios periplos en lo que a la materia contable se refiere, España entre ellos, por lo que para abordar la venta de un activo fijo en Dynamics AX 2012 R3 o AX7, vamos a comenzar explicando brevemente la definición de activo fijo según el Ministerio de Hacienda, y posteriormente nos centraremos en el proceso de venta de dicho activo en el ERP.

    En España se entiende por Activo fijo (inmovilizado) en sentido genérico, el conjunto de elementos patrimoniales reflejados en el activo, con carácter permanente y que no están destinados a la venta.

    Las notas que caracterizan al inmovilizado vienen dadas por:

    - ser un elemento de activo,

    - tener carácter de permanencia en el tiempo,

    - no estar destinados a la venta.

    Estas características deben ser consideradas en su conjunto y son aplicables a todos los bienes y derechos que constituyen el inmovilizado de un ente.

    No son inmovilizado, por tanto, las existencias que, aun siendo elementos del activo, carecen de nota de permanencia, y su destino es, precisamente, la venta.

     

    En Microsoft Dynamics AX 2012 R3 o en AX7 se entienden por activo fijos los artículos de valor, como edificios, vehículos, tierras y equipos que posee una organización.

    La forma de gestionar los activos fijos se debe corresponder con los estándares de contabilidad internacional y la legislación de contabilidad en cada país/región. Los requisitos deben incluir reglas para registrar transacciones de uso y cancelación, depreciación, tiempo de vida útil, revalorizaciones y devaluaciones de los activos fijos.

     

    Para realizar la venta de un activo fijo y recuperar parte del valor de dicho bien, o incluso obtener beneficios por dicha transacción, dependiendo de la situación, habrá que realizar los siguientes pasos:

    El activo fijo a utilizar para realizar la venta, parte de la siguiente situación:

    La adquisición de una televisión para la sala de reuniones de la empresa. El total de la compra ascendió a 1.300€. Posteriormente se ha realizado la amortización correspondiente al mes de diciembre, y por último se va a realizar la venta de la misma.

    Para llevar a cabo la venta de un activo sin que se vincule a una factura propiamente, nos situamos en Activos fijos – Diarios – Activos fijos.

    • Se pulsa en Nuevo.
    • Se despliega la pestaña Nombre y se escoge Venta activos fijos.
    • Se hace clic en Líneas.

    En el formulario Asiento del diario seguimos las siguientes instrucciones:

    • En Tipo de transacción se escoge Venta.
    • Cuenta, se señala el activo fijo que se a vender.

    • Modelo de valor: Se cumplimenta por defecto por el sistema, ya que así se ha parametrizado. En nuestro caso se trabaja con el modelo de valor lineal para la depreciación de los activos fijos.
    • Descripción: Se especifica una definición que identifique la operación que se está realizando.
    • Crédito: Se señala el importe de la venta.
    • Tipo de cuenta de contrapartida: Contabilidad.
    • Cuenta de contrapartida: 55500000.

     

    Hemos utilizado diferentes cuentas puente (5550000) para diferenciar cuando utiliza el sistema cada una de ellas. Aunque también puede ser una misma cuenta para representar la pérdida o ganancia de la venta del activo.

    A continuación, se valida y registra el asiento del diario para que despliegue efectos en la contabilidad.

     

    Seguidamente en el asiento del diario, se pulsa en Consultas – Asiento:

    Comprobamos como el sistema cancela las partidas contables pertinentes, la amortización, adquisición y la venta en la cuenta puente 555000 que se parametrizó para tal efecto.

     

    Desde las Transacciones del asiento se puede ver con más detalle el recorrido del activo fijo:

    En el formulario Saldos de activos fijos, tras la venta, quedan de la siguiente manera:

    Por último, destacar que si se quiere registrar la factura de la venta de un activo imputando impuestos y demas, habrá que realizar la operación desde el módulo de Clientes – Facturas de servicios ya que, a través de los Diarios de activos fijos, no tenemos la opción de poder indicar ningún cliente asociado.

    Por tanto, destacar que cuando se vaya a crear la factura de servicios, en la fast tab Detalles de línea, hay que especificar el activo que se va a vender.

    En el encabezado de la factura de servicios, en la opción Diario de facturas – Vista previa/imprimir – Vista previa de original, el sistema muestra la factura.

    Hasta aquí el proceso de venta de activos fijos, en próximos artículos seguiremos viendo el ciclo de vida útil del activo fijo en Microsoft Dynamics AX 2012 R3.

     

    “Pregúntate si lo que estás haciendo hoy te acerca al lugar en el que quieres estar mañana”

    Walt Disney

    Read More..
  • December / 2015
  • Acceso a Datos con Validez en el Tiempo con el Date Effective Framework de AX 2012 R3

    Hoy vamos a hablar de la posibilidad de dar acceso a datos con validez en el tiempo en función del rol de seguridad que tenga asociado un usuario concreto.

    Como ya sabemos, el framework de seguridad ha cambiado en Microsoft Dynamics AX 2012 pasando a ser un modelo de seguridad basado en roles. Pues en cada uno de estos roles, podemos definir el acceso a datos vigentes, pasados o futuros para una tabla con validez en el tiempo gracias al nuevo Date Effective Framework que incluye esta versión.

    Podemos ver, como accediendo a las propiedades de un rol de seguridad concreto, tenemos las opciones PastDataAcces, CurrentDataAccess y FutureDataAccess. Con estas propiedades podemos configurar el acceso a los registros pasados, vigentes y futuros dentro de estas tablas. Cada una de estas propiedades tiene los valores que vemos aquí.

    Hoy vamos a hablar de la posibilidad de dar acceso a datos con validez en el tiempo en función del rol de seguridad que tenga asociado un usuario concreto.

    Como ya sabemos, el framework de seguridad ha cambiado en Microsoft Dynamics AX 2012 pasando a ser un modelo de seguridad basado en roles. Pues en cada uno de estos roles, podemos definir el acceso a datos vigentes, pasados o futuros para una tabla con validez en el tiempo gracias al nuevo Date Effective Framework que incluye esta versión.

    Podemos ver, como accediendo a las propiedades de un rol de seguridad concreto, tenemos las opciones PastDataAcces, CurrentDataAccess y FutureDataAccess. Con estas propiedades podemos configurar el acceso a los registros pasados, vigentes y futuros dentro de estas tablas. Cada una de estas propiedades tiene los valores que vemos aquí.

    Propiedades rol de seguridad

    Cuando trabajamos con la actualización de datos en una tabla con validez en el tiempo, podemos distinguir tres formas distintas de actualización. Pues por este motivo, tenemos el valor Update, que hará referencia a la actualización en registros que tienen el modo CreateNewPeriod, y el valor Correct que se utiliza en las actualizaciones para registros que tienen el modo Correction o EffectiveBased. De esta forma podemos indicar el acceso que tiene un rol concreto a los registros de este tipo de tablas.

    Por otro lado, también tenemos que tener en cuenta el acceso a datos desde X++. Para ello, debemos utilizar el método RecordLevelSecurity() que tenemos dentro de las tablas para asegurarnos que se cumplen las limitaciones de accesos.

    tabla.recordLevelSecurity(true);

    Si quieres saber más sobre este y otros Frameworks de desarrollo para AX 2012 no dudes en visitar el curso destinado para ello que puedes encontrar en nuestra plataforma de e-learning entrando en AXAZURE.com

    Read More..
  • Adquisición de un Activo Fijo en AX 2012 R3

    Cada país tiene sus propios periplos en lo que a la materia contable se refiere, España entre ellos, por lo que, para abordar la adquisición de un activo fijo en Dynamics AX 2012 R3, vamos a comenzar explicando brevemente la definición de activo fijo según el Ministerio de hacienda, así como también la definición desde el propio ERP Dynamics AX 2012 R3, y posteriormente nos centraremos en el proceso de adquisición de dicho activo.

    En España se entiende por Activo fijo (inmovilizado) en sentido genérico, el conjunto de elementos patrimoniales reflejados en el activo con carácter permanente y que no están destinados a la venta.

    Las notas que caracterizan al inmovilizado vienen dadas por:

    • ser un elemento de activo,
    • tener carácter de permanencia en el tiempo,
    • no estar destinados a la venta.

    Estas características deben ser consideradas en su conjunto y son aplicables a todos los bienes y derechos que constituyen el inmovilizado de un ente.

    No son inmovilizado, por tanto, las existencias que, aun siendo elementos del activo, carecen de nota de permanencia y su destino es precisamente la venta.

     

    Los activos fijos en AX 2012 R3 son artículos de valor, como edificios, vehículos, tierras y equipos, que posee una persona o una organización. Puede configurar y especificar información de adquisición para los registros de activos fijos y, a continuación, gestionar dichos activos depreciándolos y configurando un umbral de capitalización para determinar la depreciación. Puede calcular ajustes para los activos fijos y también desecharlos.

    Al utilizar Contabilidad general con Activos fijos, también se puede ver el valor actual de todos los activos fijos. La forma de gestionar los activos fijos se debe corresponder a los estándares de contabilidad internacional y a la legislación de contabilidad en cada país/región. Los requisitos deben incluir las reglas para registrar transacciones de uso y cancelación, depreciación, tiempo de vida útil, revalorizaciones y devaluaciones de los activos fijos. La función de activos fijos incorpora muchos de estos estándares y reglas.

     

    En Microsoft Dynamics AX 2012 R3 para realizar la adquisición de un activo fijo habrá que realizar los siguientes pasos:

    Primero es importante tener bien parametrizados los nombres de diarios, es decir, nos situamos en Contabilidad General – Configurar – Diarios – Nombres de diarios, y configuramos aquellos nombres de diarios que se vayan a utilizar, en relación con el ciclo de vida útil del activo fijo (adquisición, amortización y baja), con el tipo de diario “Registrar activos fijos”.

    En segundo lugar, se configuran las secuencias numéricas propias a utilizar para los activos fijos, por lo que a través de las mismas identificaremos a primera vista, que se trata de una transacción de activos fijos. Nos situamos en el módulo de Activos fijos – Configurar – Parámetros de activos fijos – Secuencias numéricas.

    En tercer lugar, nos situamos en los Perfiles de contabilización de activos fijos y especificamos la cuenta contable que se va a utilizar en la Adquisición. También se puede parametrizar la contrapartida de Gasto que se desea vincular en el propio momento de la adqusición.

    En cuarto lugar, nos situamos en el formulario Modelos de valor (Activos fijos – Configurar – Modelos de valor), y comprobamos que tenemos asignado el método de depreciación, que se utilizará a lo largo de la vida útil de los activos fijos. En nuestro caso hemos configurado el modelo lineal, ya que es el más común.

    El método de depreciación previamente ha sido configurado en Activos fijos – Configurar – Depreciación – Métodos de depreciación.

    En cuarto lugar, daremos de alta el activo fijo desde Activos fijos – Común – Activos fijos – Nuevo.

    Una vez que se ha realizado la configuración básica del activo fijo, pasamos a realizar la adquisición del mismo. Hay 5 formas diferentes de realizar la adquisición de un activo: Diario general, Diario activos fijos, Diario inventario a activos fijos, Diario de facturas y Pedido compra. En este blog explicaremos el relacionado a Activos fijos – Diarios – Activos fijos:

    • Se pulsa en Nuevo.
    • Nombre: AF-ADQ.
    • Descripción: Adquisición Activos fijos.
    • Se pulsa en Líneas.

    Una vez situados en el formulario Asiento del diario, cumplimentamos los campos pertinentes en la línea:

    • Cuenta: 2170-02.
    • Descripción: Adquisición monitores PC.
    • Débito: 1.300€.
    • Cuenta contrapartida: Banco 1.

     

    Se valida y registra el asiento de diario para desplegar efectos en la contabilidad.

    Una vez que se ha adquirido el bien, en el formulario Asiento de diario, pulsamos en ConsultasAsientos, donde comprobamos como el sistema imputa las cuentas contables correctas que se han parametrizado previamente 21700000 de Equipos informáticos y una de gasto.

     

    Hasta aquí el proceso de adquisición de activos fijos, en próximos artículos seguiremos viendo el ciclo de vida útil del activo fijo en Microsoft Dynamics AX 2012 R3, como la depreciación, venta y baja.

     

    “Pregúntate si lo que estás haciendo hoy te acerca al lugar en el que quieres estar mañana”

    Walt Disney

    Read More..
  • Fórmulas para el cálculo de Stock mínimos en Dynamics AX

    Hola a todos,

    Muchas veces durante la implantación del módulo de MRP los clientes me han preguntado si el sistema te propone los stock mínimos, y aunque todos los que trabajamos con este módulo sabemos que la respuesta es afirmativa normalmente nos ponemos a temblar con la siguiente pregunta ¿Y cómo realiza este cálculo? ¿Cuál es la fórmula que utiliza?

    En su momento me costó mucho conseguirla, pero finalmente encontré la información y he querido compartirla con todos vosotros aun corriendo el riesgo que ya dispongáis de ella.

    Por completar el contenido de este blog creo relevante repasar el funcionamiento de los diarios de stock mínimo antes de ver el detalle de la formulación.

    Dentro de Planificación Maestra, en diarios, disponemos del Diario de Existencias de seguridad:

    Desde aquí creamos el diario en cuestión:

    Lo primero que hay que tener en cuenta es que el sistema solo calculará los valores de stocks mínimos para aquellos productos que tengan transacciones de al menos 3 meses.

    Por lo tanto, una vez creado el diario, dentro de las líneas, en “Líneas de diario” presionaremos “Crear Líneas”:

    A partir de aquí tenemos dos áreas importantes:

    • Busca emisiones para los meses: Como comentaba anteriormente el sistema necesita al menos tres meses de transacciones para hacer el cálculo, pero podremos elegir un periodo más amplio. Esto dependerá de la estacionalidad o lo constante que sean las ventas de los productos cada mes.
    • Calcular la desviación estándar: Si vamos a utilizar la opción de % de entregas a tiempo (o nivel de servicio) debemos marcar esta opción ya que la fórmula que veremos más adelante utiliza este valor.

    Al aceptar, el diario se rellenará con las líneas de los productos seleccionados:

    Como se ve en la imagen el sistema nos muestra el mínimo actual y la nueva cantidad propuesta. La propuesta aparece en cero ya que todavía no hemos seleccionado la fórmula de cálculo. Como el diario también permite hacer cambios manuales masivos, el campo nuevo mínimo permanece activo para asignar esta nueva cantidad sin ningún cálculo por parte de AX.

     

    Antes de realizar el cálculo, podemos analizar la información que AX va a tomar dentro de las formulas, en la pestaña “Estadísticas” tendremos las emisiones medias por mes, la desviación estándar y la emisión media por plazo, que será cero si el plazo de entrega o de fabricación es cero (podremos ver este valor en la pestaña “general”):

    Los cálculos que realiza en estos casos son:

    • Emisiones medias por mes: (suma de las salidas de todos los periodos/número de meses)
    • Emisión media por plazo: (Emisiones medias por mes * plazo de entrega)/30
    • Desviación estándar mensual: Raíz cuadrada (suma (Emisiones medias por mes – Total salidas por cada mes)2)

     

    Revisada esta información procedemos al cálculo, para ello dentro de “Líneas de diario” seleccionamos “Calcular Propuesta”:

    La primera opción que vamos a revisar es “Utilizar el promedio de emisión durante el plazo”. En esta primera opción el sistema realizará el siguiente cálculo:

     [(Plazo de entrega + Margen de seguridad) / 30 * Emisiones medias por mes] * Factor de multiplicación
    • El margen de seguridad se utiliza para incrementar el tiempo que tardamos en servir el producto por razones administrativas
    • El factor de multiplicación  es un mecanismo de seguridad manual para incrementar por este valor el cálculo propuesto.

     

    Por lo tanto, si tomamos el ejemplo de la materia prima en donde la emisión media es de 25 ud (línea 3 de nuestro diario)  sin añadir un margen de seguridad adicional ni factor de multiplicación, el resultado sería el siguiente:

    [(1+0) / 30 * 25]* 1 = 0,83

    En este caso el stock mínimo propuesto es igual a la media mensual de salidas de producto ya que no estamos incrementando márgenes de seguridad algunos.

     

    La siguiente opción “Utilizar nivel de servicio” es más compleja ya que usa la desviación estándar y un “Nivel de servicio” basado en un %. Este valor lo que indica es el % de entregas a tiempo que queremos tener, o dicho de otra manera, el nivel de roturas de stock. A mayor nivel, mayor cantidad de stock deberemos tener para asegurar las entregas en el plazo establecido.

    Desviación mensual estándar * Raíz cuadrada [(Plazo de entrega + margen de seguridad) / 30]* factor de servicio seleccionado:

    Siguiendo nuestro ejemplo, el resultado, seleccionando un factor del 95%, sería:

    82,92 * SQRT (1+0)/30)* 1,65 = 24,98

    El factor relacionado con el % de entregas es realmente un misterio para mí y no he podido encontrar la lógica exacta detrás de esto. Aunque la fórmula es totalmente coherente ya que está utilizando la desviación estándar para tener en cuenta los picos de venta puntuales y utilizando un mayor factor cuanto mayor es el % de entregas a tiempo, el porqué del valor con exactitud lo desconozco. Si alguno de vosotros tiene conocimiento acerca de esto le estaría muy agradecido si pudiera compartirlo.

     

    Por terminar el proceso de forma completa, deberemos marcar la opción “Propuesta=Nuevo mínimo” para que el sistema nos rellene el campo “Nuevo mínimo” con el cálculo realizado, una vez hecho, podremos registrar el diario.

     

    Quiero concluir este blog, comentando que en todos los años nunca un cliente ha tenido una formula exactamente igual a la que AX utiliza, pero tampoco he visto a dos clientes iguales. Deciros, que cada vez que el cliente me ha indicado que no le valía la fórmula de AX, hemos realizado simulaciones entre su fórmula y la del sistema y las variaciones en la mayoría de los casos han sido mínimas, ya que pese a las variaciones en las fórmulas estas suelen mantener un núcleo común. Por lo tanto, no hay una fórmula ideal para todos los clientes en general (como tampoco lo hay con los criterios de reparto de indirectos) y por lo tanto lo mejor siempre es realizar la simulación en Excel para que el cliente pueda contrastar si las diferencias son asumibles.

    Espero que esta información os sea de utilidad.

     

    "Defiende tu derecho a pensar, porque incluso pensar de manera errónea es mejor que no pensar."

    Hipatia (355 d. C.-415 d. C.) Filósofa y maestra neoplatónica grieg​a

    Read More..
  • Excepciones de Concurrencia Optimista (OCC) en Dynamics AX 2012 R3

    Cuando estemos trabajando con la actualización de datos, es necesario que el sistema realice una serie de bloqueos de los registros con los que estamos trabajando para asegurar que las transacciones se procesan de forma precisa y con un alto nivel de concurrencia, pero cuantos más registros y transacciones se encuentren bloqueadas, peor será el rendimiento de la base de datos.

    Con Dynamics AX y SQL Server tenemos dos modelos de concurrencia para controlar los bloqueos de los registros.

    • Control de concurrencia pesimista: Bloquea los registros desde el momento en el que los obtiene de la base de datos, hasta el momento de la actualización
    • Control de concurrencia optimista: Solo bloquea los registros en el momento en el que se realiza la actualización real.
    • Las ventajas de utilizar este segundo modelo son que, los registros permanecen bloqueados menos tiempo, lo que nos lleva a necesitar menos recursos para mantener los bloqueos durante el proceso de actualización, y que los registros permanezcan disponibles para otros procesos si estos han sido seleccionados, pero todavía no actualizados. Todo esto hace que mejore el rendimiento de la base de datos.

    La desventaja que tiene este modelo de concurrencia, es claramente, que un usuario puede lanzar una actualización de un registro que había sido previamente seleccionado por otro usuario, lo que puede causar inconsistencia en los datos, porque, imaginemos:

    El usuario 1, selecciona el registro del cliente 1, seguidamente, el usuario 2 selecciona el mismo registro. Esto nos lo permite el sistema el sistema puesto que todavía no estaría bloqueado. Ahora, el usuario 1, cambia un dato de ese registro, y actualiza, y seguidamente, el usuario 2 cambia otro dato del mismo registro y actualiza. Lo que tendríamos es que el usuario 2 está machacando las modificaciones que ha realizado el usuario 1.

    Para evitar esta inconsistencia, lo que ocurre es que, el sistema lanzará cuando detecte este tipo de cambio, una excepción de conflicto de actualización.

    Para ello lo que hace el sistema, es comparar el valor del campo RecVersion, que como sabemos, cambia su valor automáticamente siempre que se ejecuta un update.

    De este modo, cuando va a actualizar, si el valor del RecVersion que tenemos en el registro difiere del valor real que tiene el RecVersion dentro de la base de datos, significa que ha habido una actualización desde que obtuvimos el registro de la base de datos hasta el momento en el que intentamos actualizar, por lo que el sistema lanzará una excepción de conflicto de actualización, y lo que hay que hacer es reintentar la ejecución del código o informar al usuario de los pasos a seguir.

    Para que una tabla trabaje con el modelo de concurrencia optimista, la tabla debe tener la siguiente propiedad activada:

    Propiedad OccEnabled activada en tablas

    O bien indicárselo por código eligiendo una de las dos formas posibles:

    // Método concurrencyModel desde el buffer
    tabla.concurrencyModel(ConcurrencyModel::Optimistic);
     
    // Propiedad optimisticLock en la sentencia select
    select optimisticLock firstOnly tabla;

    Aquí podemos ver un ejemplo de manejo de excepciones de conflicto de actualización desde X++:

    #OCCRetryCount
    CustTable custTable;
     
    try
    {
        ttsbegin;
     
        // Ejecución de código
     
        ttsCommit;
    }
    catch (Exception::Deadlock)
    {
        // retry si ocurre un deadlock
        retry;
    }
    catch (Exception::UpdateConflict)
    {
        // intentar resolver el conflicto
        if (appl.ttsLevel() == 0)
        {
            if (xSession::currentRetryCount() >= #RetryNum)
            {
                throw Exception::UpdateConflictNotRecovered;
            }
            else
            {
                retry;
            }
        }
        else
        {
            throw Exception::UpdateConflict;
        }
    }
    Read More..
  • November / 2015
  • ¡HORROR, EN AX7 NO SE UTILIZA EL ASTERISCO!

    Es conocido por todos que el “nuevo” Microsoft Dynamics AX (este es el nombre oficial, al final todas las porras sobre AX7, AX 365, AX 2016, AX online, AX AZURE ups!:)… han perdido… aunque en adelante me referiré a él como AX7 porque si no, nos vamos a liar) trae un fuerte cambio a nivel técnico, tanto a nivel de arquitectura como a nivel de metodología de desarrollo, pero desde AXAZURE, con este post, queremos empezar a comentar aquellos cambios que desde nuestro punto de vista funcional nos han llamado más la atención de inicio.

    Estos son comentarios a título personal que hemos identificado como claves cuando hemos comenzado a utilizar la preview del producto hace algunos meses. Evidentemente veréis mucha comparativa con nuestras arraigadas tradiciones desde AXAPTA 3.0, por tanto mis disculpas si alguien no ha trabajado con versiones antiguas.

    Os haré unas preguntas:

    ¿Eras bueno usando CTRL + G para tener tu filtro por cuadrícula?

    ¿El filtro por selección o campo eran de tus prioridades?

    ¿Qué me dices de comandos como el asterisco, los dos puntos o el interrogante?

     

    Bien para empezar a abrir boca, decirte que te puedes olvidar de esto. Pero no te asustes, ya no es necesario, las búsquedas son realmente sencillas desde el propio campo. Simplemente escribiendo parte del nombre de un cliente, o parte de su código de cliente, el sistema te permitirá encontrar todos los registros que encuentre asociados. Aquí ves un ejemplo con la palabra Whale:

    Imaginaros que en lugar del nombre, sabéis el código de cliente o parte del mismo, al ir tecleando la búsqueda es realmente rápida como podéis ver:

    ¿Los Usuarios estaban en Administración del Sistema o en Administración de la Organización?

     

    Ese gran dilema que hemos sufrido tantos años los consultores para ubicar donde está concretamente cierto formulario se soluciona de una forma muy sencilla (¡por fin!) gracias al fabuloso buscador que han diseñado:

    ¿Te gustaría realizar acciones en el ERP simplemente escribiéndolo?

     

    Parece ciencia ficción ¿verdad? Os imagináis diciendo a Cortana, “Por favor registra la factura que está en pantalla, que me voy a tomar un café.” Pues no estamos tan lejos de interactuar así con el ERP, Microsoft ya está trabajando en esta línea y comienza a haber comandos de ejecución para Cortana :)

    Lo que si podemos hacer desde ya en AX7 el Ribbon de arriba indicado es especificar la acción a realizar, por ejemplo “Registrar” y el sistema nos presentará el comando para ejecutarlo.

     

    La intención es que si lo deseas no tengas que utilizar el ratón para imputar transacciones en el ERP, además como os podéis imaginar si estás trabajando con una Surface podrás hacer Zoom con la pantalla por si algo no terminas de verlo correctamente.

    ¿Tienes muchos manuales perfectamente documentados de todos tus procesos empresariales en AX?

     

    Creo que puedes tirarlos. El grabador de tareas se convertirá en la mejor herramienta de formación y testing para poder llevar a cabo interactivamente los pasos a seguir… sí… he dicho interactivamente, es decir, o pasas por el camino o ruta que te especifique el grabador o no podrás avanzar, lo que significa cero incidencias en el procedimiento.

    En cuanto saquemos un poco más de tiempo comenzaremos a contaros algo que nos ha fascinado a nivel funcional y es por fin planificar un proceso de cierre financiero en el sistema, planificando tareas, asignándolas al equipo, viendo el grado de avance… Y en otro hueco hablaremos un poco más sobre los Workspaces (espacios de trabajo) de cada role y, desde nuestro punto de vista la maravilla, de integrar la herramienta de PowerBI  para que sea consumida desde el propio ERP.

    Ir pensando en el reto que supone AX7 a nivel profesional, a los nuevos clientes creo que les va a encantar,

    pero ¿cómo creéis que les encajará a los clientes tradicionales de AX?

     

    ¡Seguimos en contacto!

    Read More..
  • Modelo 303 en Dynamics AX 2012 R3

    Os presento el siguiente artículo sobre la implantación del modelo 303 en Microsoft Dynamics AX 2012 R3.

    MODELO 303

    Se trata de un único modelo de autoliquidación del IVA.

    El IVA o Impuesto sobre el Valor Añadido es un tipo de impuesto que básicamente recae sobre el consumo y “grava las entregas de bienes y prestaciones de servicios efectuadas por empresarios y profesionales, las adquisiciones intracomunitarias y las importaciones de bienes “en España.

    En Microsoft Dynamics AX 2012 R3 el modelo 303 requiere una configuración especial en los códigos de impuestos.

    Nos situamos en Contabilidad general – Configurar – Impuestos – Externo – Códigos de notificación de impuestos.

    Los códigos de notificación de impuestos se asocian a los códigos de impuestos que se han definido previamente. De tal manera que se lanzará un informe que recoja los códigos de impuestos, con las asociaciones de los códigos de notificación de impuestos que se hayan parametrizado.

    Para llevar a cabo un ejemplo del proceso nos ubicamos en el formulario Códigos de impuestos (Contabilidad general – Configurar – Impuestos – Códigos de impuestos), y nos centramos en los códigos CNORS Y VNORS.

    Dentro del formulario en el apartado Configuración del informe (apartado compra) y Configuración del informe – Nota de abono (apartado compra) en CNORS, hay que destacar los valores que se han señalado en los apartados:

    Compra gravable: 28, que se corresponde con BI Compras OP Interiores.

    Impuestos soportados: 29, son cuotas soportadas de OP Interiores.

    Nota de abono de compras gravables: 40, son BI Facturas Rectificativas – Compras.

    Impuesto sobre la nota de abono de compras: 41, son Impuestos facturas rectificativas – compras.

    Hemos seguido el mismo procedimiento para el código de impuesto VNORS (en el apartado Venta de Configuración del informe), en consecuencia habría que seguir también el mismo proceso con el resto de códigos de impuestos que vayan destinados para configurar los criterios del modelo 303.

    Una vez realizado el proceso de parametrización de los impuestos, estamos en disposición de lanzar la declaración del modelo 303.

    Nos situamos en Contabilidad general – Informes – Transacciones – Agrupaciones – Pago de impuestos por código, indicamos el Período de liquidación y se pulsa Aceptar.

    A continuación el sistema nos muestra el informe del modelo 303, con la información de los códigos de notificación que se han parametrizado previamente.

    Recordar que tenéis toda esta información con mucho más detalle en el curso de Contabilidad General, en concreto en la cápsula 11 Modelo Español 347, 349 y 303.

     

    “Pregúntate si lo que estás haciendo hoy te acerca al lugar en el que quieres estar mañana”

    Walt Disney

    Read More..
  • UnitOfWork: Inserción masiva de registros en AX 2012

    La clase UnitOfWork apareció con la versión 2012 de Dynamics AX para facilitar la tarea de inserción o modificación de datos de forma masiva, ya que esta tarea se complicó con el cambio del patrón de modelado de datos, debido a las relaciones basadas en claves subrogadas.

    Desde la versión 2012, Microsoft recomienda que las relaciones entre tablas se lleven a cabo por medio de las claves subrogadas para mejorar el rendimiento de la base de datos. Estas claves deben estar formadas por una variable entera de 64 autoincremental, justo el funcionamiento que tiene el campo estándar RecId.

    Esta recomendación, no se hacía con versiones anteriores, puesto que para un usuario, sería difícil comprender los datos cuando realizase un lookup de una clave externa, para seleccionar datos de la tabla relacionada, lo que se solucionó introduciendo el concepto de clave de sustitución, de modo que, cuando el usuario vea el campo que hace la relación de las tablas, no verá realmente la clave primaria, si no, que aparecerá el campo que indiquemos dentro de la clave de sustitución, el cual tiene que ser una clave alternativa de campo único.

    Debido a todo esto, la inserción masiva de datos se complica, ya que al ser el RecId el campo por el que se va a realizar la relación, no se sabrá su valor hasta que el campo esté realmente insertado, lo que obliga a ir insertando los registros de uno en uno, e ir consultando el valor del RecId una vez insertado para poder relacionar los registros.

    Es por este motivo por el que aparece la clase UnitOfWork. Su funcionamiento es el siguiente:

    • Se relacionan los registros que queremos insertar utilizando las variables
    • Al insertar, el sistema se encarga de guardar los registros de forma ordenada, con sus relaciones, y va actualizando los RecId de los campos relacionados teniendo en cuenta la integridad de la transacción.

    Imaginando el siguiente ejemplo en el que hay dos tablas relacionadas, una tabla padre y una tabla hija, que están relacionadas por el RecId de la tabla padre.

    Relación de tablas por RecId

    Esta sería la forma de insertar datos de la tabla padre e hija de forma masiva mediante la clase UnitOfWork, lo que lleva a una gran mejora de rendimiento.

    // Variables de tipo buffer
    AXZParentTable  parentTable;
    AXZChildTable   childTable;
     
    // Instancia de UnitOfWork (Obligatoriamente ejecutar en servidor)
    UnitofWork      unitOfWork  = new UnitofWork();
     
    parentTable.clear();
    parentTable.initValue();
    parentTable.ParentId    = "Padre";
    parentTable.Name        = "Name Padre";
    parentTable.Description = "Description padre";
    unitOfWork.insertonSaveChanges(parentTable);
     
    childTable.clear();
    childTable.initValue();
    childTable.AXZParentTable(parentTable);
    childTable.ChildId      = "Hijo";
    childTable.Name         = "Name Hijo";
    childTable.Description  = "Description Hijo";
    unitOfWork.insertonSaveChanges(childTable);
     
    unitOfWork.saveChanges();

     

    En distintos ejemplos que hemos llevado a cabo, hemos obtenido resultados en los que, realizando una inserción de unos 15.000 registros, al utilizar la clase UnitOfWork, el tiempo de ejecución se reduce prácticamente a la mitad en comparación con la inserción registro a registro.

    Importante: La clase UnitOfWork solo puede utilizarse desde el servidor, por lo que no podemos ejecutar este código desde el cliente. Si necesitamos ejecutarlo desde un Job por ejemplo, que se ejecuta desde cliente, para realizar alguna prueba, deberemos desde este Job llamar a métodos de una clase que se ejecuten en servidor..

     

    Si quieres saber más sobre esta nueva característica de AX, no dudes en visitar la plataforma e-learning de AXAZURE.com

    Read More..
  • Modelo 349 en Dynamics AX 2012 R3

    Lo prometido es deuda, en aras de que fluya el conocimiento, os dejo el siguiente artículo sobre la implantación del modelo 349 en Microsoft Dynamics AX 2012 R3.

     

    MODELO 349

     

    El modelo 349 es una declaración informativa en la que empresarios individuales y empresas en España, que realicen operaciones intracomunitarias, deben detallar dichas operaciones a la hacienda pública.

    En este caso es importante que en Microsoft Dynamics AX 2012 R3 el campo NIF, dentro de la ficha de los clientes, esté bien informado, es decir, que la dirección y país de origen se correspondan, y por último que los códigos de impuestos estén bien parametrizados, porque hay una dependencia directa de la transacción que se genera desde el cliente o proveedor con el código de impuesto, para que el sistema tenga el conocimiento necesario para enlazar dicha transacción al 349 o no.

    Por ejemplo, accedemos al módulo de Proveedores – Facturas – Diarios de facturas y elegimos un proveedor de la unión europea, para realizar el ejemplo de forma clara y sencilla, e ir comprobando como el sistema va enlazando los impuestos.

    En el formulario Impuestos registrados, vemos los impuestos que trae aparejada dicha transacción, son CINTRAV Y CINTRAC.

    A continuación en la pestaña Factura del formulario del asiento del diario, está el apartado Comercio exterior.

    El campo Código de la lista: Comercio en UE hace que el sistema coja esa información de manera automática, en el momento en que se trabaja con clientes o proveedores de la UE.

    Ahora bien si en el formulario Códigos de impuestos (Contabilidad general – Configurar – Impuestos – Códigos de impuestos), en el apartado “Configuración del informe” de los impuestos CINTRAV Y CINTRAC está activado el check Excluido, no lo tendrá en cuenta en el modelo 349, aunque en el código de lista de la pestaña factura, en el asiento de diario, se especifique que es Comercio en UE. Por el contrario si dicho check está desmarcado, el sistema sí que tendrá en cuenta la información del cliente o proveedor para el modelo 349.

    Es un campo vital para el código de impuesto 349.

    Una vez que hemos repasado los parámetros pertinentes en relación con los impuestos, tanto en la factura del proveedor como en contabilidad general en los códigos de impuestos, estamos en disposición de lanzar el proceso del modelo 349.

    Nos situamos en el módulo Administración de la organización – periódico – Comercio exterior – Listas de ventas de la UE.

    Pulsamos en Transferir y en el siguiente formulario elegimos que tipo de informe e información de la factura queremos trasladar a la declaración del 349. En el ejemplo hemos marcado todas las casillas y hacemos clic en Transferir nuevamente.

    En la página de lista del formulario Listas de ventas de la UE tenemos las transacciones que el sistema nos ha traído a colación para enviarlas a la declaración del 349.

    A continuación validamos para comprobar que no hayamos cometido errores y pulsamos en la opción Notificación para indicar la fecha y opciones de exportación del Informe, como vemos en la imagen siguiente.

    Por último pulsamos en Aceptar y tenemos preparada nuestra declaración del modelo 349.

    Recordar que tenéis toda esta información con mucho más detalle en el curso de Contabilidad General, en concreto en la cápsula 11 Modelo Español 347, 349 y 303.

     

    “Pregúntate si lo que estás haciendo hoy te acerca al lugar en el que quieres estar mañana”

    Walt Disney

    Read More..
  • Novedades en el Query Framework de Microsoft Dynamics AX 2012: QueryFilter y QueryHavingFilter

    Hoy vamos a ver las novedades que se han incluido en el framework de consultas desde la versión 2012 de Microsoft Dynamics AX.

    Para ello, vamos a hablar de las clases QueryHavingFilter y QueryFilter.

    QUERYHAVINGFILTER

    La clase QueryHavingFilter, como decíamos, ha sido añadida en Microsoft Dynamics AX 2012. Como podemos imaginar, esta clase se encargará añadir filtros dentro de la sentencia having de una select estándar.

    Hasta ahora no teníamos forma de realizar este tipo de filtros, ni por sentencias SQL de X++, ni con el objeto Query creado desde el AOT, por lo que si nos encontramos ante la necesidad de utilizarlo se deberá recurrir a la creación de queries mediante este framework.

    Imaginemos que necesitamos obtener un listado de los clientes que tienen más de 5 pedidos de venta en el sistema.

    La select que deberíamos realizar sería algo así:

    SELECT CUSTACCOUNT, COUNT(*) FROM SALESTABLE
        GROUP BY CUSTACCOUNT
        HAVING COUNT(*) > 5

    En versiones anteriores, hubiésemos sido capaces de obtener un listado de clientes y el número de pedidos de venta de cada cliente realizando un count sobre el RecId de la tabla y un group by por la cuenta del cliente, pero no hubiésemos podido filtrar por este count.

    En AX 2012, gracias a esta nueva clase, podemos obtener este mismo resultado por medio del Query Framework, y para conseguirlo tendríamos que hacer la siguiente consulta:

    static void AXZQueryHaving(Args _args)
    {    
        Query                   query;
        QueryBuildDataSource    qbds;
        QueryBuildRange         qbr;
        QueryHavingFilter       qhf;
        QueryRun                queryRun;
        SalesTable              salesTable;
       
        query   = new Query();
        qbds    = query.addDataSource(tableNum(SalesTable));
        qbds.addSelectionField(fieldNum(SalesTable, RecId), SelectionField::Count);
        qbds.orderMode(OrderMode::GroupBy);
        qbds.addGroupByField(fieldNum(SalesTable, CustAccount));
       
        qhf     = query.addHavingFilter(qbds, fieldStr(SalesTable, RecId), AggregateFunction::Count);
        qhf.value(">5");
       
        queryRun = new QueryRun(query);
        while (queryRun.next())
        {
            salesTable = queryRun.get(tableNum(SalesTable));
            info(strFmt("Cliente: %1 - Nº Pedidos: %2", salesTable.CustAccount, salesTable.RecId));
        }
    }

     De este modo conseguimos filtrar por el valor que obtenemos de realizar el count(RecId).

     

    QUERYFILTER

    La clase QueryFilter, es la segunda novedad de la que vamos a hablar dentro del Query Framework en Dynamics AX 2012. Esta clase nos da la posibilidad de obtener resultados de una unión externa de tablas diferente a lo que podemos obtener mediante sentencias SQL de X++.

    La clase QueryFilter se encarga de añadir filtros la cláusula where de una select estándar que utiliza el outer join entre dos tablas. La diferencia que tiene utilizar esta clase con respecto a utilizar la ya conocida QueryBuilRange es que esta segunda añade el filtro dentro de la palabra reservada on de la cláusula join. Por lo que, por medio del QueryFilter, seremos capaces de aplicar filtros una vez que ya se ha realizado el join con sus filtros.

    La mejor forma de entender este concepto y la diferencia con el QueryBuilRange es por medio de ejemplos, así que vamos a ello:

    Tenemos una consulta que nos da la tabla de Clientes (CustTable) y la tabla de Transacciones (CustTrans), que tienen una relación por la cuenta de cliente (CustAccount).

    SELECT * FROM CUSTTABLE
        OUTER JOIN CUSTTRANS ON CUSTTRANS.CUSTACCOUNT = CUSTTABLE.ACCOUNTNUM

     Esta consulta nos devolverá un listado de todos los clientes, y para aquellos que tengan transacciones, también saldrán todas las transacciones. Por ser un outer join, como decimos, obtendremos todos los clientes, tengan o no transacciones.

    Imaginemos ahora, que queremos obtener todos los clientes junto con las transacciones que hayan sido aprobadas únicamente, pero igual que antes, queremos seguir recibiendo aquellos clientes que bien no tienen transacciones o bien estas transacciones todavía no han sido aprobadas. Necesitaríamos generar una select como esta:

    SELECT * FROM CUSTTABLE
        OUTER JOIN CUSTTRANS ON CUSTTRANS.CUSTACCOUNT = CUSTTABLE.ACCOUNTNUM AND CUSTTRANS.APPROVED = 1

    Esta es la select que obtenemos al incluir el filtro dentro de un QueryBuildRange. Si en lugar de utilizar el QueryBuilRange optásemos por el QueryFilter, la select obtenida sería la siguiente:

    SELECT * FROM CUSTTABLE
        OUTER JOIN CUSTTRANS ON CUSTTRANS.CUSTACCOUNT = CUSTTABLE.ACCOUNTNUM
        WHERE CUSTTRANS.APPROVED = 1

     

    Y el resultado de ejecutar esta select sería distinto, ya que el where, se encarga de aplicar los filtros una vez que el outer join ha sido ejecutado con los filtros pertinentes, por lo que, una vez que tengamos el resultset que resulta de realizar la primera parte de la select, es cuando se aplica el filtro de la cláusula where, por lo que finalmente nos quedaríamos únicamente con aquellos clientes que tienen alguna transacción aprobada, y desecharíamos el resto de clientes.

    Aquí tenemos un job en el que podemos ver claramente la diferencia entre el resultado obtenido al utilizar un QueryBuildRange o un QueryFilter, simplemente con ejecutarlo comentando una u otra línea podremos verlo.

    static void AXZQueryFilterVSQueryBuildRange(Args _args)
    {
        Query                   query;
        QueryBuildDataSource    qbdsCustTable, qbdsCustTrans;
        QueryRun                queryRun;
        QueryBuildRange         qbrApproved;
        QueryFilter             qfApproved;
        CustTable               custTable;
        CustTrans               custTrans;
     
        query           = new query();
        qbdsCustTable   = query.addDataSource(tableNum(CustTable));
        qbdsCustTrans   = qbdsCustTable.addDataSource(tableNum(CustTrans));
        qbdsCustTrans.relations(true);
        qbdsCustTrans.joinMode(JoinMode::OuterJoin);
        qbdsCustTrans.addLink(fieldNum(CustTable, AccountNum),
                              fieldNum(CustTrans, AccountNum));
       
     
        // QueryBuildRange
        qbrApproved     = qbdsCustTrans.addRange(fieldNum(CustTrans, Approved));
        qbrApproved.value(queryValue(NoYes::Yes));
       
        // QueryFilter
        qfApproved      = query.addQueryFilter(qbdsCustTrans, fieldStr(CustTrans, Approved));
        qfApproved.value(queryValue(NoYes::Yes));
     
        queryRun        = new queryRun(query);
       
        while (queryRun.next())
        {
            custTable   = queryRun.get(tableNum(CustTable));
            custTrans   = queryRun.get(tableNum(CustTrans));
      
            info (strFmt("Cliente: %1, Asiento: %2",
                            custTable.AccountNum,
                            custTrans.Voucher));
        }
     
        info (strFmt("Total: %1 registros", SysQuery::countLoops(queryRun)));
    }

    Read More..
  • October / 2015
  • Modelo 347 en Dynamics AX 2012 R3

    Nuestro estimado legislador con mayor o menor acierto, se empeña en gravar la capacidad económica tanto de las personas físicas como de las jurídicas, con impuestos varios, entre ellos encontramos los modelos 347, 349 y 303. Posteriormente estos impuestos, entre otros, hay que implantarlos en los diferentes ERPs del ámbito empresarial, y es ahí, donde entran en acción las legiones de programadores y consultores, pues bien, para facilitar la tarea y hacer que fluya el conocimiento, os  dejo con la explicación de la implantación de la declaración del 347 en Microsoft Dynamics AX 2012 R3. En próximos artículos os hablaré también de los modelos 349 y 303.

    MODELO 347

     

    El Modelo 347 es una declaración anual informativa de operaciones con terceras personas. Los empresarios y profesionales en España, están obligados a la presentación del Modelo 347 siempre que hayan realizado operaciones con terceros por importe superior a 3.005,06 euros durante el año natural, computando de forma separada las entregas y las adquisiciones de bienes y servicios.

    Para llevar a cabo este proceso en Microsoft Dynamics AX 2012 R3 hay que llevar a cabo previamente tres parametrizaciones.

    • La primera parametrización se realiza en el módulo Gestión de almacenes:

    Nos situamos en el módulo de Gestión de almacenes – Configurar – Configuración del almacén – Almacenes, en éste módulo se indica la cuenta del proveedor asociada al almacén, para el caso en que haya almacenes propiedad del proveedor.

    • La segunda parametrización se revisa el criterio de caja:

    Hay que situarse en el módulo de Contabilidad general – Configurar – Parámetros de contabilidad general.

    En el formulario de parámetros de contabilidad general, en el apartado Impuestos, tiene que estar activado el chec “Régimen especial del criterio de caja”.

     

    También hay que activar dicho check en la ficha del proveedor que se quiera acoger al criterio de caja.

    En el módulo de Proveedores – Común - Todos los proveedores, en la pestaña Factura y entrega, encontramos el check en cuestión “Régimen especial del criterio de caja”. 

    Activamos los checks del Régimen especial del criterio de caja porque, “las operaciones q se acojan al criterio de caja se harán constan de forma separada de otras operaciones en el momento del devengo, como hasta hora, y además se volverán a declarar en el momento en el que se produzca el devengo total y parcial conforme al nuevo criterio de caja".

    • La tercera parametrización tiene impacto directo en la generación del modelo 347:

    Se configura la Lista de validación, ubicada en Contabilidad general – Configurar – España – listas de validación 347.

    En éste formulario especificamos aquellos códigos de impuestos que queramos excluir del 347, por ejemplo entregas y adquisiciones de bienes que supongan envíos entre el territorio peninsular español o las islas Baleares y las islas Canarias, Ceuta y Melilla, operaciones enmarcadas dentro del ámbito del impuesto del IRPF, etc.

    Una vez que hemos llevado a cabos éstas tres parametrizaciones, estamos en condiciones de generar el modelo 347 en Microsoft Dynamics AX 2012 R3.

    Nos situamos en el módulo de Contabilidad general  - Periódico – Informe 347 - Declaración 347.

     

    Se completan los datos de la Declaración 347 acorde con la entidad en la que trabajamos, en la imagen visualizamos un ejemplo, pulsamos en Aceptar y seguidamente el ERP nos enseña una simulación del modelo 347, para que comprobemos que los datos son correctos.

     

    Una vez que hemos validado la información se hace cilc en SalidaExportar al archivo ASCII o Imprimir, con la opción Exportación al archivo ASCII, podemos mandarlo telemáticamente a la hacienda pública.

     

     

    En las imágenes vemos como el sistema nos muestra la declaración 347 en ambos formatos.

     

    Recordar que tenéis toda esta información con mucho más detalle en el curso de Contabilidad General, en concreto en la cápsula 11 Modelo Español 347, 349 y 303.

     

    “Pregúntate si lo que estás haciendo hoy te acerca al lugar en el que quieres estar mañana”

    Walt Disney

     

    Read More..
  • HERRAMIENTAS DE INGENIERÍA INVERSA EN MICROSOFT DYNAMICS AX 2012 R3

    Como ya sabéis, tenemos disponible un sitio web con una serie de diagramas entidad relación que nos permiten tener documentadas ciertas partes del modelo de datos de Microsoft Dynamics AX 2012: Microsoft Dynamics AX 2012 R2: AxErd.

    Gracias a este WebSite se puede consultar rápidamente las relaciones existentes entre ciertas tablas centrales del sistema, así como ver a que módulo corresponde una tabla concreta.

    A parte de este sitio, en Microsoft Dynamics AX 2012 disponemos de una serie de herramientas de ingeniería inversa que nos permite generar los siguientes diagramas dado una serie de tablas o clases:

    • Modelo de datos de Visio UML
    • Modelo de objetos de Visio UML
    • Modelo de datos Entidad-Relación (ER) ERX

    Por lo tanto, podremos utilizar estas herramientas para comprender mejor como está creado un modelo de datos/objetos concreto, bien estándar o bien desarrollado por otras personas, así como para documentar un desarrollo que hayamos realizado nosotros mismos.

    Vamos a ver un ejemplo de cómo generar un modelo de objetos UML desde una serie de tablas relacionadas que han sido desarrolladas por nuestro equipo técnico.

    Lo primero, es tener todos los objetos que queremos que aparezcan en el documento, incluidos en un mismo proyecto.

    Como vemos en la imagen, tenemos la tabla de ficheros AXZFilesTable y la tabla de descargas AXZDownloadsTable que tiene una relación directa, por un lado, con los ficheros mediante el campo RecId de la primera tabla, y, por otro lado, con la tabla de clientes CustTable por el campo CustAccount.

    Una vez que tenemos nuestro modelo de datos organizado en un proyecto, hacemos click con el botón derecho sobre el proyecto y vamos a Complementos / Utilizar técnicas de ingeniería inversa.

    Nos aparecerá la siguiente ventana, en la que tendremos que indicar la ruta donde guardaremos el archivo .vsd y su nombre, seleccionaremos el tipo de modelo que vamos a generar, en nuestro caso, Modelo de datos Visio UML, y por último daremos a Aceptar.

    Automáticamente el sistema generará el documento indicado y nos abrirá Microsoft Office Visio para que podamos trabajar con él.

    Nota: Este ejercicio se ha realizado con Microsoft Office Visio 2010, puesto que con el 2013 han sido eliminadas ciertas funcionalidades y no funciona esta herramienta.

     

    Una vez que tenemos Visio abierto, podemos ver los objetos que teníamos en el proyecto desde el Explorador de objetos.

    Arrastramos las tablas hacia el dibujo, y se nos presentarán las relaciones existentes entre ellas automáticamente.

    Como veis, la tabla estándar CustTable está formada por una gran cantidad de campos, y para el caso que estamos tratando puede dificultarnos la visibilidad de las relaciones. Lo que podemos hacer para obtener un modelo más legible es, haciendo click derecho sobre la tabla, ir a Opciones de presentación de formas, y en el formulario que vemos a continuación, marcar la opción para Suprimir los Atributos del dibujo.

    De esta forma, nos quedaremos únicamente con la definición de la tabla y sus relaciones como podéis ver en la última imagen.

     

     

    Read More..
  • September / 2015
  • Diferencias entre Empleado y Trabajador en Microsoft Dynamics AX 2012 R3.

    Dadas las múltiples dudas existentes entre estas 2 entidades en el ERP Microsoft Dynamics AX 2012 R3, vamos a intentar explicar las diferencias entre ambas entidades.

    Cómo sabéis dentro del módulo de Recursos Humanos encontramos estos 3 formularios en la sección común:

    En primer lugar deciros que los Trabajadores pueden ser creados con 2 tipologías, o bien que pertenezcan a la empresa y estén en nómina o bien que sea simples trabajadores externos o subcontratistas.

     

    ¿Cómo AX diferencia entre uno y otro?

     

    Es simple para ello existe el formulario Empleado o el formulario Contratista respectivamente. Por tanto, un Empleado en AX simplemente es un tipo de Trabajador, y un Contratista será otro tipo de Trabajador para el sistema.

    Obviamente, si el Contratista no pertenece a la empresa no tiene sentido que tengamos funcionalidad asociada para configurar nada relacionado con la Nómina, con esto quiero decir que todo lo relacionado en el módulo de Recursos Humanos de AX 2012 denominado Nómina no aparecerá para contratistas.

     

    ¿Pero qué sucede entre Trabajador y Empleado?

     

    La respuesta es muy sencilla, cuando accedáis al módulo de Empleados y hagáis doble click sobre uno de ellos, mirar el formulario que se abre.

    ¡Sorpresa! Vuelve a ser el formulario de Trabajador.

    Ni existe diferencias que si uno pertenece a todas las empresas y otro no, ni nada similar, puesto que si quieres que un trabajador pueda operar en más de una empresa (por ejemplo esto es muy útil para que un empleado contratado en una empresa pueda crear solicitudes de compra para otras distintas) será tan sencillo cómo acceder a su ficha (da igual si vas por empleado o trabajador, vas a llegar al mismo sitio a Trabajador), sección Empleo y pinchar en Nuevo para asignarle otra empresa. Con esta configuración el empleado/trabajador podrá crear solicitudes de compra para más de una entidad jurídica.

    Por defecto cuando se crea en AX un trabajador el sistema lo predetermina como empleado. La lógica interna de AX es almacenar todo en una misma tabla denominada HcmEmployment en donde hay funciones del tipo isContractor() o isWorker() en otra tabla HcmWorker para identificar si es de un tipo o de otro.

     

    ¿Entonces cuál es la diferencia entre uno y otro?

     

    Ninguna, solo hay diferencia entre Trabajador y Contratista, pero un Empleado a todos los efectos se comporta como un Trabajador.

     

    ¿Por qué se creó así el modelo de datos?

     

    Para tener un formulario global en donde encontrar a los empleados de la empresa y a los contratistas denominado Trabajadores y luego poder disgregar información en 2 formularios distintos. Pensar que la información de los empleados siempre puede ser más sensible a efectos de la protección de datos y seguridad que la de los contratistas y de esta manera será más sencillo poder configurar mejor los accesos en el sistema.

    Read More..
  • July / 2015
  • Microsoft Dynamics Lifecycle Services, una herramienta en Azure cada vez más presente en proyectos AX.

    Durante el evento Microsoft Dynamics AX Technical Conference de este año 2014 (hashtag  #AXTech2014) el foco o protagonista fue Microsoft Dynamics AX 2012 R3 junto con todas las novedades más destacables que vienen con dicho release:

    Dentro de este evento se recalcó varias veces de la utilidad/necesidad de operar y utilizar la plataforma Microsoft Dynamics Lifecycle Services (en adelante LCS), pero… ¿realmente los consultores o jefes de proyecto sabemos qué es esto?

    LCS es un espacio colaborativo basado en una solución Cloud (concretamente Azure como era de esperar) en la que clientes y partners pueden gestionar y optimizar proyectos Microsoft Dynamics AX desde la fase de preventa hasta la propia implantación.

    Desde la matriz del fabricante nos recomiendan que a partir de ahora coordinemos nuestros proyectos a través de este espacio colaborativo ya que nos puede facilitar mucho la vida. A continuación os indico algunas de sus características principales por las cuales su utilidad es manifiesta:

     

    • Espacio de trabajo colaborativo (Collaborative Project workspace)

    Es posible crear diferentes tipologías de proyectos tanto de implantación, evolutivos, preventa… Este espacio puede ser utilizado para definir al equipo de implantación de proyecto, crear un plan de proyecto, gestionar documentos de proyecto, utilizar y modificar checklists, procesos de modelado de negocios, seguimiento de incidencias y análisis de desarrollos. Además las herramientas de servicios de diagnóstico de sistemas están disponibles para ayudar a administradores a monitorizar y evaluar el estado de rendimiento de sus entornos Microsoft Dynamics AX.
     

    • Modelado de Procesos de Negocio (Business Process Modeler)

    A través de LCS, los equipos de proyecto serán capaces de crear, ver y modificar los diagramas de flujos para procesos de negocios estándar dentro de Microsoft Dynamics AX. Esto posibilita estandarizar los flujos de procesos y alinearlos a Microsoft Dynamics AX, identificando de una manera mucho más intuitiva los GAPFIT entre las necesidades del cliente y la funcionalidad estándar del ERP. Los procesos de negocios pueden ser adaptados desde proyectos previos, librería corporativa o librerías globales de Microsoft para las mencionadas industrias.

    Este modelado de negocios se integra con diferentes plataformas:

    • Microsoft Visual Studio Team Foundation Server (TFS): la lista de gaps que se ubiquen en LCS se pueden importar manualmente en TFS como elementos de trabajo que se referencian al flujo de proceso en cuestión.
    • Microsoft Word: permite la generación directa de documentación sobre los procesos de negocios (muy útil para las fases de análisis, cuántas horas nos habría quitado en versiones anteriores).
    • Microsoft Visio: permite la exportación de procesos de negocios a archivos Visio (otra maravilla).

    También desde LCS junto con la versión actualizada del grabador de tareas (KB2863182) los equipos de proyecto podrán grabar información sobre los procesos de negocios. Cada diagrama de flujo incluye los pasos detallados y un vídeo creado por el grabador de tareas.

    • Buscador de incidencias o bugs (Issue Search)

    Este buscador permite la posibilidad a los miembros del proyecto de encontrar soluciones y alternativas a incidencias que hayan sido reportadas. Se pueden identificar las incidencias que se han solventado con el pertinente parche que lo resuelve y aquellas que todavía están pendientes de ser resueltas. Los desarrolladores pueden también suscribirse a notificaciones vía email para hotfixes concretos de áreas específicas en Microsoft Dynamics AX.

    Al seleccionar una de estas incidencias se muestra información relevante como la descripción de lo que se ha modificado junto con los objetos afectados. Existe la posibilidad de descargarte el hotfix y poderlo revisar más detenidamente aunque con un simple copy paste puede ser más sencillo.

    • Perfil de uso en la implantación (Usage profiler – beta)

    Esta herramienta permite recopilar información sobre el uso que se está dando a la implantación Microsoft Dynamics AX 2012 y puede ser utilizado para una amplia variedad de propósitos tales como el dimensionamiento del Hardware.

    • Muestra un resumen de las características de uso modelado, incluyendo configuración del sistema, volumen de transacción, información de planificación, productos ISV, personalizaciones, integraciones y reports.
    • Representa un gráfico con los perfiles de la organización con picos de carga. Este gráfico está basado en la combinación de usuarios concurrentes con procesos batch ejecutados. Desde este gráfico se puede definir el pico de carga y a partir de ello replanificar tareas en Microsoft Dynamics AX 2012 para mitigar en la medida de lo posible los picos de máximo rendimiento.

    • Calculadora estimación licencia (License Estimator)

    El calculador de licencia ayuda a los equipos de proyecto a estimar los números de licencias requeridas para Microsoft Dynamics AX 2012. Proporciona un espacio de trabajo que te permite identificar los roles necesarios a utilizar en el proyecto, calculando automáticamente las licencias de accesos a los clientes (CALs). Esta herramienta está disponible para los Partners en proyectos de preventa y a clientes en proyectos de implantación y evolutivos.

    Esta simulación proporciona información que se puede utilizar antes que el cliente compre Microsoft Dynamics AX, antes de arrancar tu implantación, o antes de actualizar a una nueva versión de AX.

    Una vez que se defina el número de empleados, el número de usuarios proveedores y el tipo de implantación (Nueva o Actualización) será necesario seleccionar los departamentos que estarán operativos en la implantación:

    Para cada uno de ellos se tendrá que seleccionar el rol y el número de usuarios que van a desempeñar esta función.

    Con esta información el simulador ya está en disposición de presentarte un gráfico sobre la estimación de la licencia:

    • Análisis de procesos de negocio personalizados (Customization Analysis Services)

    A través del LCS, la sección de análisis de personalizaciones ofrece a los clientes de Microsoft Dynamics AX 2012 una herramienta automatizada que valida su modelo definido comparándolo con el manual de buenas prácticas para tablas, clases, formularios y enumerados. Solo es necesario cargar el modelo (.axmodel) y el sistema genera un report con un resumen de lo que se ha personalizado, un Excel con las incidencias que haya podido detectar y un informe para que el desarrollador pueda cargarlo en el entorno de desarrollo (concretamente en el AOT en el apartado de Compiler output, importar).

    • Análisis para actualización de versiones (Upgrade Analysis)

    En el caso que tu proyecto se base en un cambio de versión, esta funcionalidad será de gran ayuda ya que a través de la carga de los archivos AOD de las versiones anteriores (AX 4.0 o AX 2009), esta herramienta analiza la información del entorno existente ayudando a estimar lo que supondría el cambio de versión a través de un archivo Excel similar a este:

    • Servicios para el diagnóstico del sistema (System diagnostic services)

    Esta funcionalidad permitirá ayudar a los administradores a monitorizar y entender el comportamiento de uno o varios entornos Microsoft Dynamics AX.

    Es una herramienta alojada en un entorno Cloud con un componente instalado localmente que puede ser configurado para cumplir con las siguientes tareas:

    • Definición de entornos on-premise (con BBDD e instancias de AOS).
    • Recopilar datos de entornos.
    • Ejecuta reglas en los datos recopilados.
    • Incumplimiento de reglas a través de un informe.
    • Reports varios relacionados.

    Espero que este breve resumen de las funcionalidades del LCS que echaba en falta en castellano anime a más consultores y clientes a utilizarlo porque verdaderamente tiene una gran utilidad.

    Aunque las horas dedicadas a parametrizar y configurar esta herramienta no sean muy justificadas comercialmente para facturarlas al cliente, esta herramienta se convertirá en uso casi obligatorio para versiones actuales y futuras.

    Recordaros que para logarse en estas direcciones https://lifecycleservices.dynamics.com o https://lcs.dynamics.com es necesario tener credenciales en Partner o Customer Source.

    A continuación os dejo las referencias de todos los vídeos publicados hasta el momento en relación a las funcionalidades vistas junto con documentación añadida (eso sí en inglés):

     

    Visión global LCS - Microsoft Dynamics Lifecycle Services Overview
    http://youtu.be/pNZ3jPyiqR8

    Calculadora/Estimador de Licencia - Microsoft Dynamics Lifecycle Services License Sizing Estimator
    http://youtu.be/9oRqnTA4-h4

    Servicio de análisis de personalizaciones - Microsoft Dynamics Lifecycle Services Customization Analysis Service
    http://youtu.be/6iyOTHWbT08

    Servicio para cambios de versión - Microsoft Dynamics Lifecycle Services Upgrade Analysis Service
    http://youtu.be/nxB6g-JYZlg

    Modelado de Procesos de Negocio - Microsoft Dynamics Lifecycle Services Business Process Modeler
    http://youtu.be/T_FDn1DxhYk

    Servicios de diagnóstico del Sistema - Microsoft Dynamics Lifecycle Services System Diagnostic Service
    http://youtu.be/vopziR-rU4g

    Búsqueda de bugs o incidencias - Microsoft Dynamics Lifecycle Services Issue Search Service
    http://youtu.be/ZyiFk2MYT3E

    Hotfix para el grabador de tareas - Task Recorder Hotfix:

    Podéis descargarlo aquí:
    https://mbs2.microsoft.com/Knowledgebase/KBDisplay.aspx?scid=kb;en-us;2863182

    Documentación Grabador de Tareas - Task Recorder Documentation:

    Installation & Configuration guide for the Task Recorder update:
    http://go.microsoft.com/fwlink/?LinkID=310185

    Documentación Servicio BPM - BPM Service Documentation:

    Business process modeler (Lifecycle Services) [AX 2012]:
    http://go.microsoft.com/fwlink/?LinkID=306500

    Read More..
  • En Microsoft Dynamics AX 2012 R3 configura la búsqueda rápida de artículos, clientes y prospects por los campos que necesites.

    Cuántas veces hemos desarrollado a medida esta funcionalidad que vamos a comentar en el siguiente post. Estoy seguro que cada uno de vosotros ha tenido que solicitar al desarrollador o programar diferentes tipos de búsquedas para que la introducción de productos en las líneas de venta puedan ser mucho más ágiles que meramente utilizando su código o su alias.

    Pues bien con Microsoft Dynamics AX 2012 R3, por fin se puede parametrizar sin necesidad de desarrollar código indicando qué campos se quieren tener en cuenta para que la búsqueda de la cadena de caracteres introducida en el campo código de artículo sea directa en dichos campos.

    Antes de comenzar a parametrizar los campos comentar que se puede seleccionar si queremos trabajar con un tipo de búsqueda de coincidencia parcial o coincidencia completa (o exacta). Esto se ubica dentro de Ventas y Marketing/ Configurar/ Buscar/ Parámetros de Búsqueda. Lo ideal y útil es coincidencia parcial para que haga efecto del funcionamiento del asterisco en AX como cuando hacemos filtros: *xxx*.

    Una vez seleccionado el tipo de búsqueda, será necesario acceder al módulo de Ventas y Marketing/ Configurar/ Buscar/ Definir criterios

    En este apartado seremos capaces de poder configurar criterios de búsqueda para 3 entidades:

    • Cliente
    • Artículo
    • Cliente Prospecto

    En este post y dado que queremos escribir sobre aquello que pueda ser más útil vamos a parametrizar el ejemplo de artículo:


     

    Por defecto el sistema viene con 3 campos propuestos el código de artículo, su alias y la descripción. En muchos casos y dependiendo de la estrategia que tenga la empresa con el catálogo de productos puede ser de mayor utilidad para el departamento de ventas introducir pedidos pero introduciendo valores en el campo de producto otro tipo de campos (como hemos comentado anteriormente en versiones anteriores solo funcionaba si coincidía exactamente con el alias). En este caso hemos configurado estos 4 valores:

    Una vez configurado se pulsa el botón Actualizar para que dicha configuración tenga efecto:


    Esto me permitirá poder introducir en las líneas de pedido de venta sin necesidad de saberme el código, el artículo que quiero vender en este caso con alguna cadena de caracteres coincidente con los campos. Por ejemplo en este caso que hemos configurado me va a buscar aquel artículo que se pueda corresponder con código de artículo, conjunto de producción, descripción o grupo del número de serie.

    Imaginemos que quiero vender un “laser” pero no recuerdo el código; al introducir “laser” dentro de dicho campo y pulsar intro, buscará en los 4 campos que hemos parametrizado y si encuentra registros o coincidencias me los presenta para que pueda indicar directamente el número de unidades de venta a introducir.

    Introduciendo la cantidad de ventas y pulsando Crear, de forma inmediata me crearía dicha línea.

    Read More..
  • Cómo configurar el backflushing (principio de vaciado) o consumo automático de materiales en Órdenes de Producción en Microsoft Dynamics AX 2012 R3.

    En las empresas de fabricación es muy común que dentro de los árboles de materiales (ya sean Listas de Materiales o Fórmulas) existan elementos de bajo coste y por tanto, de bajo impacto económico, que se deben consumir al fabricar el producto terminado o intermedio. Para este tipo de materiales (por ejemplo todo lo relacionado con el embalaje) no merece la pena estar haciendo los pertinentes consumos en los diarios de las listas de selección ya que si se notifica como terminado “X” unidades, se pueda identificar fácilmente que consumos se va a realizar.

    Por ejemplo, imaginemos que fabricamos una mesa y para embalarla necesitamos de 3 cajas. Esta configuración permitirá que se haga el consumo automático de las cajas sin necesidad de indicarlo manualmente, si hacemos una campaña de fabricación de 100 mesas, el sistema internamente cada vez que notifique como terminado (esto es parametrizable) consumirá 3 cajas por mesa, en total 300 cajas.

    Para llevar a cabo este procedimiento es importante tener en cuenta los siguientes parámetros dentro del módulo de Control de Producción (Control de Producción/ Configurar/ Parámetros de control de Producción), de tal manera que el sistema sepa que queremos utilizar el consumo automático de LMat o fórmula según el principio de vaciado.

    También será importante acceder dentro del módulo de Control de Producción/ Configurar/ Ejecución de fabricación/ Parámetros de Producción y de nuevo indicarle que queremos utilizar el criterio de Principio de Vaciado para el consumo cuando se Notifique como terminado.

    Una vez indicado esta parametrización global se accederán a aquellos Productos Emitidos que impacten en la configuración del back flushing o Principio de vaciado, (Gestión de Información de Producto/ Común/ Productos Emitidos) revisando 2 configuraciones más:

    • Dentro de la ficha del producto, acceder al menú “Aplicar Ingeniería” y en el grupo de campos “Producción”, indicar en el campo “Principio de Vaciado” el valor “Finalizar”.

    • También será necesario acceder a las pestaña de arriba denominada “Gestión del inventario” dentro de la opción “Artículos por almacén” para poderle indicar la ubicación por defecto de la que se desea realizar el consumo automático en el proceso de notificar como terminada la producción.

    Es muy importante 2 factores a la hora de configurar este tipo de parametrización:

    • Por un lado, si hay ruptura de stock, es decir, si en este ejemplo no tenemos cajas disponibles en el inventario (y en concreto en la ubicación indicada) supondrá un problema a la hora de gestionar la producción. En el momento de notificar como terminado nos dará un error puesto que al intentar hacer el consumo automático si no encuentra disponible no te permite fabricarlo. Por tanto primer consejo tener siempre el stock del ítem actualizado o si no se requiere tener rupturas de stock, parametrizar en el “Grupo de modelos de artículo” de dicho elemento que se auto consumirá  como permisible para tener Inventario Negativo Físico.

     

    • Por otro, para solventar posibles problemas de tener stock de este tipo de materiales en diferentes ubicaciones que no coinciden con la parametrizada en la definición de “Artículos por almacén”, es recomendable que la recepción de este material se haga en la misma ubicación desde donde se va a consumir, puesto que también puede darse el caso de tener stock en otro ubicación distinta y cuando la línea de producción está fabricando al notificar nuevo producto terminado le salte error de que no hay stock (en realidad si hay pero no en donde el sistema lo está buscando).

     

    Saludos y hasta pronto.

    Read More..
  • Configuración de envío de emails basándonos en la configuración de alertas para Microsoft Dynamics AX 2012 R3

    Microsoft Dynamics AX 2012 R3 como herramienta de colaboración permite tener un comportamiento proactivo de tal manera que el propio ERP sea capaz de controlar cambios o modificaciones en las transacciones o datos maestros avisando mediante alertas o emails a los responsables que proceda.

    Durante este artículo explicaremos los pasos a llevar a cabo para configurar el envío de emails desde la aplicación ejecutados desde la propia Gestión de Alertas que trae el sistema de forma nativa.

    Para una mayor comprensión este proceso se dividirá en 4 grandes bloques:

    1. PARAMETRIZACIÓN
    • El primero de los puntos a configurar será en el módulo de Administración del Sistema / Usuarios / Usuarios y pulsar el botón Opciones para el usuario en concreto al que se desea activar esta opción.

    Desde Opciones de usuario tenemos diferentes opciones en relación a la configuración de Notificaciones (si… desgraciadamente la configuración es individualmente).

    • Recibir notificaciones cada (minutos): Intervalo de tiempo en el que el sistema chequeará si se cumple algún condicionante para enviar notificaciones.
    • Destino de vínculo emergente: Opciones Para Avisar (recomendado) o Para avisar al origen que lo provoca.
    • Enviar alerta como mensaje de correo electrónico: Lo recomendable es que se defina para cada regla de alertas. Existen casos para el departamento de Control de Gestión en el que es interesante que sean conocedores de todas las reglas de alertas, aunque en muchos casos esto no es operativo.
    • Mostrar elementos emergentes: Mismo criterio que el anterior.
    • Tipo de notificación de elemento de línea: Posibilidad de configurarlo a nivel Agrupado o Individual.
    • Mostrar notificaciones en el cliente de Microsoft Dynamics AX: Activar (recomendable)
    • Mostrar ventanas emergentes para notificaciones: Activar (recomendable)
    • Enviar notificaciones en correo electrónico: Activar.

    En el caso que no se haya lanzado el asistente para la creación de secuencias numéricas de toda la aplicación será necesario también en Administración del Sistema / Configuración / Parámetros del sistema / Secuencia Numéricas, concretamente en Id. de regla crear y asociar la secuencia para gestionar los identificadores que van a llevar las reglas.

     

    Es importante que cada usuario tenga bien configurado su email, para ello también desde Usuarios, se accederá al apartado General para rellenar el que corresponda:

    1. CONFIGURACIÓN

    Ahora se configurará los parámetros de email de salida (SMTP) y las plantillas de email a enviar. Para el SMTP se accederá a la Administración del Sistema / Configurar / Sistema / Parámetros de Correo Electrónico.

    Respecto a la definición de la plantilla de email se accederá a la Administración de la Organización / Configurar / Plantillas de Correo Electrónico:

    Existe la posibilidad de crear la plantilla a través del editor o del código HTML.

    Definido la plantilla de email, es necesario que en la Administración del Sistema / Configurar / Parámetros del sistema asociar en los parámetros la plantilla de email del sistema (si esto no se asocia no se podrá ejecutar el envío).

    Para crear un Id. de correo electrónico (plantilla) del sistema, desde este campo accediendo a Ver detalles te lleva directamente al formulario para crearlo (si se crea desde Administración de la Organización / Configurar / Plantillas de Correo Electrónico no se visualizará y no podrá ser seleccionada).

    Una vez parametrizado esta parte de configuración de email, vendrá el proceso de definición de alertas para cada uno de los usuarios. Normalmente este proceso lo realiza cada usuario para controlar ciertos eventos dentro de Microsoft Dynamics AX 2012 R3.

    Su configuración es muy sencilla puesto que simplemente posicionándote en cualquiera de los campos de cualquier formulario, y pulsando el botón derecho, aparece la opción Crear Regla de Alertas.

    Desde mi experiencia, las alertas que más interés causan son las generadas por vencimientos en fechas y por supuesto las modificaciones de datos maestros sensibles. A continuación aclararemos aquellos que tienen descripciones no muy intuitivas:

    • Este importe ha vencido hace tiempo: Permite indicar el número de días vencidos a la fecha para que se ejecute la alerta.
    • Vencimiento: Se ejecuta la alerta en el caso que se llegue a dicha fecha.
    • Vencimiento el: Permite anticiparse a que se llegue a la fecha, de tal manera que te aviso con antelación a que llegue el día indicado.
    1. EJECUCIÓN

    Con esta configuración el sistema ya enviaría emails (basado en el template que se ha parametrizado) con la ejecución de las alertas. A nivel funcional y estándar el sistema tiene esta limitación, es decir, si se desea configurar una plantilla de email por diferentes alertas habría que adaptarlo a través de código X++.

    Espero que os haya sido de utilidad, suerte en vuestras configuraciones es una funcionalidad que merece la pena tenerla activa y utilizarla, pero no abusar de ella.

    Read More..
  • June / 2015
  • Facturación de Proyectos de empresas vinculadas (intercompany) en Microsoft Dynamics AX 2012 R3.

    Con el lanzamiento de Microsoft Dynamics AX 2012 R3 se han hecho grandes cambios para facilitar la labor intercompany dentro del módulo de proyectos. Con esta versión se conseguía que los usuarios pudiesen imputar horas en proyectos que pertenecían a otras empresas siendo en la R2 cuando se consiguió asignar empleados de otras empresas al proyecto.

    Con la nueva Release 3 es posible facturar con la modalidad intercompany (empresas vinculadas) a través de conceptos como horas y gastos (en este último caso tanto de empleados como de proveedores) de proyectos ubicados en diferentes organizaciones.

    Vamos a identificar un ejemplo que representa un escenario intercompany con el módulo de Proyectos:

    Elite de Negocios Tecnológicos (en adelante ELITE) tiene un contrato con un cliente final con el cual tiene creado un Proyecto de Tiempo y Material (PROYELI) para desarrollar un proyecto de Cloud Computing. Para este proyecto se utilizarán empleados de 2 empresas asociadas denominadas appliloo y AXAZURE que imputarán sus hojas de horas contra el proyecto PROYELITE. Cada empresa asociada, periódicamente generan facturas de venta intercompany a ELITE tanto de los gastos como del tiempo imputado por los empleados. Si las facturas que recibe ELITE se aprueban y registran se generará la correspondiente factura al proveedor (en este caso sería para appliloo y AXAZURE). Contabilizadas dichas facturas, el coste ya estará registrado en el proyecto PROYELITE, y comenzaría el proceso de creación de propuesta de factura al cliente final.

    Para llevar a cabo a esta configuración en AX 2012 R3 será necesario definir la relación comercial entre las empresas. Esto significa especificar la relación empresarial tanto en la empresa matriz (proveedores AXAZURE y appliloo) como en las empresas asociadas (cliente ELITE). Para ello en el formulario de clientes y proveedores, en los registros implicados en esta operación se accederá a la pestaña General en concreto a la opción Empresas Vinculadas.

    Desde dicho formulario se definirá la relación de venta y de compra en el procedimiento intercompany:

    Una vez realizada la relación o vínculo, se parametrizará en AXAZURE y appliloo (empresas asociadas) en el módulo de Gestión de proyectos y contabilidad / Configurar / Parámetros de gestión de proyectos y contabilidad la siguiente información:

    En primer lugar se activará la opción denominada “Activar la programación de recursos y las hojas de horas de empresas vinculadas” y en segundo se asignarán en cada empresa asociada la entidad jurídica a la que se presta el trabajador, en este caso ELITE. El check de acumular ingresos se utilizará si se desea acumular ingresos antes del proceso de facturación. Será necesario especificar una categoría por defecto para horas y gastos en el caso que existan escenarios en los que las categorías de horas y gastos no coincidan entre las empresas del grupo (bajo mi experiencia esta tabla en la mayoría de los clientes es compartida).

    Parametrizada la lógica de relaciones toca el momento de definir la contabilidad tanto de los costes intercompany de los recursos prestados y los ingresos recibidos (navegando entre las pestañas Cuentas de Costes y Cuentas de Ingresos).

    Definida la contabilidad, es el momento de definir las tarifas intercompany, funcionalidad bastante mejorada en R3. Esta parte se lleva a cabo desde el módulo de Gestión de proyectos y contabilidad / Configurar / Precios / Precios de Transferencia

    En el siguiente formulario se podrá definir tarifas por diferentes modelos de precios, concretamente 6. Hay 4 modelos basados en cantidad fija o precio de coste:

    • Cant.
    • Coeficiente de contribución
    • Porcentaje de gastos
    • Importe de gastos

     

    Hay 2 modelos más que se basan en el precio final al cliente a través de:

    • Porcentaje de precio de Ventas
    • Importe por debajo del precio de venta

    Por último será necesario confirmar que la unidad Horas tiene marcado “Asignación de unidades fijas”, esto será utilizado en el registro de la factura del proveedor en las empresas asociadas (AXAZURE y appliloo en este ejemplo).

     

     

    Read More..