Frases de: El principe, Maquiavelo

A los hombres se les ha de aplastar o mimar, pues se vengan de las ofensas ligeras, ya que de las graves no pueden

La guerra no se evita, se retrasa para ventaja del enemigo

Quien propicia el poder de otro, labra su propia ruina

Los hombres hacen daño o por odio o por miedo

Quien cree que nuevas recompensas hacen olvidad viejas injusticias, se engaña

La naturaleza del hombre es contraer obligaciones entre si tanto por los favores que se hacen como por los recibidos

No es una victoria verdadera la que se consigue con armas ajenas

Las armas de otro o te vienen grandes o te pesan o te oprimen

Un príncipe sabio jamás permanecerá ocioso en tiempo de paz

Los hombres vacilan menos en hacer daño a quien se hace amar que a quien se hace temer

Un príncipe debe tener poco temer a las conjuras cuando goza del favor del pueblo

Un príncipe debe ejecutar a través de otros las medidas que puedan acarrearle odio, y por sí mismo las que reporten el favor de sus súbditos

El que no es tu amigo buscara tu neutralidad, el que lo es te exhortara a que combatas a su lado

Un príncipe debe mostrar su aprecio poe el talento

Los buenos consejos han de nacer de la prudencia del príncipe, y no la prudencia del príncipe de los buenos consejos

Solamente son buenas, seguras y duraderas aquellas formas de defensa que dependen de uno mismo

Ax2012, Saldo de ficha de proveedor o cliente

Introducción

Se trata de mostrar las diferentes vías en las que se puede obtener cual es el saldo abierto de una fecha. Este texto se centrará en proveedores, Pero es aplicable igualmente a Clientes.

Transacciones
Se trata de la tabla que almacena cualquier transacción asociada a la ficha, como por ejemplo facturas, pagos, efectos,.. La tabla se denomina VendTransOpen.
La primera forma y más sencilla de obtener el saldo es sumar el campo Importe (AmountMST) de todas las transacciones del proveedor.
La segunda manera de obtener el saldo sería sumar el resultado de la operación Importe (AmountMST) -Divisa liquidada (SettleAmountMST) de todas las transacciones del proveedor.
La tercera y cuarta manera sería igual que las anteriores, pero sumando aquellas transacciones que están abiertas de acuerdo al campo Fecha cerrada (Closed)

Transacciones abiertas
La quinta opción sería sumar el Importe (AmountMST) de todos los registros con el proveedor deseado (AccountNum) de esta tabla, llamada VendTransOpen.
Recordar que esta tabla se relaciona con la tabla de transacciones a través del campo Referencia de recid (RefRecId), que debe coincidir con el RecId de la tabla de transacciones. De esta manera, una transacción puede tener relacionadas múltiples transacciones abiertas, por ejemplo porque cada una de ellas tenga distintos vencimientos.

Integridad entre ambas
1. No puede haber transacciones abiertas no relacionadas con una transacción
2. No puede haber transacciones abiertas relacionadas con una transacción que tenga informado el campo Fecha cerrada (Closed)
3. Toda transacción que no este cerrada, Fecha cerrada no informado, debe tener relacionado al menos una transacción abierta relacionada.
4. La suma de las transacciones abiertas de una transacción debe coincidir con la operación Importe (AmountMST) - Divisa liquidada (SettleAmountMST) de dicha transacción.

Ax2012, AIF Services

Tras una segunda lectura del libro "Microsoft Dynamics Ax 2012 Services" publicado por Pack Publishing, voy a tratar de sintetizar los concepto clave y conclusiones que extraigo.

Microsoft ha realizado un esfuerzo grande para que Ax proporcione los medios, más que suficientes, para que el sistema sea conectable con cualquier otro sistema. Para ello, el servidor de aplicaciones (AOS) se ha convertido en un host WCF (Windows Communication Foundation, concebida para permitir una programación rápida de sistemas distribuidos y el desarrollo de aplicaciones basadas en arquitecturas orientadas a servicios, SOA)

Las ventajas que ello trae son:

1. Podemos diseñar y programar nuestros servicios en X++, reutilizando la lógica que ya tenemos!
2. No necesitamos IIS, si nos limitamos al ámbito de la red local
3. Posibilita el uso de todos sus protocolos, tanto los síncronos y asíncronos (NetTcp, HTTP, FileSystem, MSMQ)
4. Poblemos emplear IIS para servicios expuestos fuera de nuestra red local, y la comunicación entre IIS y AOS ya no se realizará mediante Business Connector sino como WCF Routing.
5. Podemos publicar servicios básicos (netTcp) de una forma sencilla

Veamos gráficamente y fundamentalmente lo que ofrece:

Como podemos ver hay varios tipos de servicios, vamos a entrar en detalle en cada uno de ellos y sobre todo en cuál es su utilidad y cuando deben ser utilizados.

Document services
Permiten exponer un documento (una o varias tablas) y realizar operaciones CRUD sobre el mismo. Su desarrollo es más laborioso, requiere definir una query, unas tablas (Axd) y una clase para el documento y otra para el servicio. Las operaciones CRUD se simplifican ya que en la tabla Axd podemos incluir la lógica de acceso a datos y sus validaciones.
Es recomendado para servicios complejos y que deriven en operaciones con datos, aunque hemos de tener cuidado con los cambios en el esquema de datos de las tablas que se emplean, ya que pueden alterar el servicio.

Custom services
Se desarrollan en base a una clase de contrato (service contract) que contendrá la lógica y un conjunto de clases de datos (data contract) que definirán los parámetros de entrada y salida.
Son recomendables para servicios menos complejos, servicios de proceso y no tanto orientados a datos. Son más sencillos y flexibles a la hora de desarrollar, no seremos dependientes del modelo de datos e incluso podemos llegar a reutilizar los data contract entre diversos servicios.
El nuevo marco de SysOperation será ideal para que reutilicemos la lógica de proceso para clientes Ax como para sus servicios, debemos orientar nuestros desarrollos a ese nuevo marco e ir discontinuando el uso de RunBase.

System services
Estos servicios son proporcionados out-of-the-box, por lo tanto están a nuestra disposición para ser consumidos desde soluciones externas. Tenemos a disposición:

• Query service: Facilita consultar información de tablas y campos Ax, pero no de métodos, por lo tanto no podemos obtener datos calculados y re aprovechar esa lógica. Los datos son devueltos en un DataSet. Ese acceso puede hacerse utilizando:

1. Una query ya definida en el AOT
2. Una query definida al vuelo mediante la clase QueryMetadaClass
3. Una query dinamica definida como clase extendida de AIFQueryBuilder

• Metadata service: Permite acceder a información de los metadatos de objetos de AOT. Por ejemplo obtener el nombre de las tablas, propiedades, etc.
• Session service: Nos proporcionará información de la sesión por la que estamos realizando la conexión. Podremos consultar el usuario, idioma, empresa, etc.

Interoperabilidad, no negociable

Hoy en día, en cualquier organización medianamente compleja es raro encontrar que el sistema de información se limite a una única solución, por buena y completa que sea. Es normal tener que lidiar con:

• Sistemas anteriores (legacy systems)
• Soluciones de nicho o especializadas, incluso diseñadas y desarrolladas in-house
• Soluciones integradas con maquinaria o línea de logística

Además de esto, es posible que incluso teniendo una buena solución core e incluso ampliable, como Microsoft Dynamics Ax, sea conveniente desarrollar o integrar soluciones satélites, en vez de desarrollarlas dentro del sistema. Esta decisión de arquitectura puede fundamentarse fácilmente en:

• La tecnología a emplear. Puede ser más fácil / rápido / barato hacer cierto tipo de soluciones en plataformas distintas a la proporcionada por el sistema core.
• La ubicación y dispositivo del usuario. Si el usuario trabaja de forma remota, quizás una solución 3 capas con trabajo semi-desconectado sea más conveniente y eficiente. Por otro lado si el usuario no usa sistemas compatibles con nuestro core, no tendremos más remedio que realizar una solución externa. Se podría alegar que con soluciones de tipo Terminal, como Escritorio remoto o Citrix, se podría paliar también el problema, aunque de una forma poco amigable para el usuario.
• Los costes de licenciamiento y mantenimiento. Tampoco hemos de descuidar los costes asociados. Si tenemos cientos de usuarios que realizan tareas puntuales o acceden a información limitada, seguramente nos será más económico una solución externa pero bien relacionada con nuestro core, que la adquisición de esos cientos de licencias.

Por todo lo anterior, la interoperabilidad no es un concepto negociable. Gracias a ella, y con un diseño racional, podremos disponer de un sistema capaz de entenderse y hacerse entender con otros, evitándonos por tanto tener que reescribir lógica de negocio o duplicar datos en distintos sistemas.

Puede haber distintos grados de interoperabilidad, como por ejemplo:

1. Nivel 0. No es posible acceder al sistema ni a su información más que desde el propio sistema. Si te encuentras un sistema así y tienes que integrarlo, prepárate a remangarte, tener ideas muy imaginativas y sudar...no me gustaría estar en tu pellejo!
2. Nivel de datos. Somos capaces de acceder a la información, pero no a la lógica del sistema. Es un primer paso, podremos leer e introducir información, aunque las cautelas deben ser máximas ya que al hacerlo de forma externa podemos estar saltándonos las reglas de negocio de la solución y trabajar con información no coherente.
3. Nivel de librería. Disponemos de una API, DLL o similar que nos facilita el acceso a la lógica. Aquí las dificultades vienen cuando librería no ofrece toda la lógica que necesitamos, o bien la librería no corre sobre la plataforma que necesitamos que corra.
4. Nivel de servicio. Realmente este nivel es muy similar al anterior, salvo la limitación de plataforma. Los servicios están basados en estándares y por tanto debe ser operables desde distintas plataformas. La limitación que podemos seguir teniendo es la de que los servicios expuestos no cubran el 100% de nuestras necesidades.
5. Nivel de servicio extensible. Parte de la anterior, pero además el sistema ofrece la posibilidad de extender los servicios ofrecidos, eliminando por tanto la limitación anterior y haciendo por tanto que este caso sea perfecto de cara a la interoperabilidad.

Comentar, por clarificar, que los niveles anteriores no son excluyentes, y por tanto cuantos más y más altos cumpla nuestro sistema mejor será para comunicarse con posibles "vecinos" que conformen nuestro universo de soluciones empresariales.

Breves reflexiones: Grandes y rápidos

“De un tiempo a esta parte llego siempre tarde, a todas mis citas, y la vida me parece una fiesta a la que nadie se ha molestado en invitarme” (Canción: "Últimamente" de Ismael Serrano)

He querido empezar este artículo con dicha estrofa ya que refleja cómo evoluciona este mundo. Por un lado, gracias a los avances y la tecnología de esta era digital, se incrementa la velocidad, todo fluye y discurre sin pausa, a un ritmo difícil de seguir. Como ejemplo, hoy la humanidad es capaz de:

• Generar información y enviarla instantáneamente a cualquier lugar del planeta. Igualmente recibir y consumir esta información, incluso sin demandarla
• Mover casi cualquier producto de un punto a otro del planeta en 2-3 días

Y por otro lado, la estrofa refleja un posible sentimiento de una parte de la población o negocios, a los que esta revolución puede dejar fuera de juego.

Por lo tanto, estamos ante una globalización que avanza rápidamente y sin mirar hacia atrás. A pesar de este peligro, personalmente opino que es un movimiento positivo, enriquecedor. Además, estoy seguro que seremos capaces de adaptarnos y ese riesgo finalmente quedará minimizado.

¿Cómo tener éxito en un mundo así? Yo sólo veo dos maneras, una ser grande y otra ser rápido. Ambas cosas a la vez sería lo ideal, pero es muy muy difícil.

Grande

Ser grande implica poder estar presente y operar en varios mercados, incluso con múltiples propuestas de valor. Es decir, aprovechar la globalización y las economías de escala. De esta manera el riesgo de exclusión se minimiza, podemos soportar la caída de un cliente, mercado o producto, seguramente se verá compensado por el crecimiento en otro.

A pesar de todo esto, el grande no debe quedarse de brazos cruzados, pues si lo hace, parte de su tarta se la irán comiendo los rápidos, y algunos de estos pueden hacerse grandes e incluso dejarles pequeños. Por lo tanto, el grande debe tratar de continuar creciendo, y no bajar el ritmo, es decir, como mínimo no ser lento.

Rápido

Es aquel que es capaz de aprovechar una oportunidad, sin dudarlo, sin pestañear, detecta (o crea, siendo innovador) y satisface una demanda en tiempo record. Si esa demanda es global, rápidamente se hará grande, o se atragantará y morirá de éxito. Si es una demanda local, debe tratar de adaptar su propuesta de valor para abrirse a más clientes y mercados, o bien buscar y satisfacer otras demandas, o bien asociarse con otros rápidos para tratar de crecer. El asunto es que debe seguir moviéndose más rápido que el grande, buscando los nichos que este no acaba de satisfacer.

El peligro para el rápido viene cuando un grande (o varios) comienza a competir él. Es probable que no le arrebate todo el mercado, pero también es muy posible que esas mermas de su pastel hagan que el rápido ya no tenga suficiente alimento, debilitándose y dejando el camino allanado al grande.

Gestión de proyectos, Procesos

Los procesos por los que discurre un proyecto son siempre los mismos, teniendo más o menos nivel de formalización o documentación en cada uno de ellos, dependiendo de lo 'rigurosos' que seamos con la metodología. En mi opinión los pasos fundamentales hay que respetarlos, y extendernos más o menos en un proceso dependerá mucho del tipo, volumen o actores del proyecto.

Iniciación

Es fundamental clarificar, a alto nivel, los objetivos (alcance) y los recursos que serán necesarios, para asegurar la disponibilidad de los mismos.

Es igualmente importante vincular, desde este primer momento, a aquellos actores (clientes, interesados,..) que participarán, utilizarán o se verán afectados por el proyecto, facilitando así su implicación y colaboración futura. De esta forma será más fácil que finalmente se sientan satisfechos con el resultado final.

Ya sólo nos queda formalizar documentalmente lo anterior y la aprobación del inicio del proyecto por parte del Patrocinador en el Acta de formalización del proyecto.

Es muy recomendable, si es posible, realizar una sesión semi-formal semi-lúdica de kick-off o lanzamiento del proyecto, con todos aquellos que vayan participar (al menos los más relevantes), de modo que se recuerden los objetivos, recursos y plazos y se comience con Alegría!!!

Planificación

Puede parecer que esta etapa se realiza únicamente al iniciarse el proyecto, pero no es así, es una tarea continua, es más, cuanto más revisiones hagamos, más detallado y preciso será nuestro plan. 

Inicialmente se hará el esfuerzo más importante, se clarificará algo más el alcance, se inventariarán y valorarán los recursos a emplear, las necesidades de productos o servicios, el cronograma del proyecto y los niveles de calidad o aceptación requeridos. Se incluye en esta fase la realización del Plan de Gestión del proyecto, que reflejará las directivas de cómo se va gestionar el proyecto. Por ejemplo, se procedimentará como vamos a medir los avances, los costes o los pasos a seguir para realizar las compras o adquisiciones.

En esta fase es conveniente contar con aquellos miembros que, por su experiencia o conocimiento, nos puedan ayudar a realizar las estimaciones de tiempos y recursos, sobre todo si el Jefe de proyecto no es un experto en la materia. ¿Quién mejor que aquellos que van a participar los trabajos para realizar las valoraciones de los mismos? Preguntar es bueno!!

Ejecución

Es casi autoexplicativa. Se ejecutan los procesos y tareas para completar los trabajos, así como la coordinación de personas y recursos con el fin de facilitar los avances. En esta fase es muy importante que fluya la información entre los ejecutores para evitar bloqueos, duplicación de tareas o malos entendidos.
Tan importante como hacer las tareas es comunicarlo.

Seguimiento y control

Observaremos la ejecución y mediremos el rendimiento, con el fin de identificar problemas o dificultades para avanzar con normalidad. Es crítico anticiparse e ir allanando el terreno para que el proyecto discurra lo más fluido posible.

En esta fase también iremos detectando los cambios en el alcance, recursos o tiempos, identificándolos para tomas las acciones correspondientes, dentro de la fase de re-planificación, que pudieran incluir incluso la cancelación del proyecto si se tratara de una situación grave.

La detección de cambios o problemas debe ser una tarea compartida por el equipo, para ello es conveniente generar un clima de confianza y respeto entre todo el equipo y hacia el Jefe de proyecto. Además de detectar los problemas conjuntamente, es posible plantear conjuntamente las mejoras, a través de un sistema de lecciones aprendidas.

Resumiendo:

• Observar y medir, como herramientas de mejora (No se trata de formar una "Stasi" como en la RDA)
• La potencia sin control no sirve de nada (Anuncio de Pirelli)

Cierre

Un proyecto siempre finaliza, con o sin éxito, pero finaliza. Igual que en la iniciación, es necesario 'institucionalizar' el cierre formalmente. Si ha habido éxito es recomendable gratificar a los integrantes del proyecto por el esfuerzo realizado, al menos con una palmadita en la espalda y si puede ser algo más.

Antes del cierre, el Jefe de proyecto deberá asegurarse de dejar documentada y actualizada toda la información del proyecto. Dentro de esa información es muy relevante lo referido a Lecciones aprendidas. Esta información del proyecto deberá pasar al equipo de Operaciones, que deberá realizar la explotación del producto o servicio del proyecto.

Ax2012, Debugging managed code desde Visual Studio

En una entrada anterior hemos visto como poder acceder a la lógica de negocio y datos de Ax desde Visual Studio. Ahora se trata de revisar los parámetros que nos permitirán trazar nuestro código VS, incluyendo la parte que se ejecuta en Ax. Para ello debemos tener en cuenta:

• AOS, Configuración del servidor
• Activar 'Habilitar puntos de interrupción para depurar el código X++ que se ejecuta en este servidor' 
• Activar 'Habilitar puntos de interrupción globales'
• Cliente Ax, Configuración
• Activar 'Habilitar puntos de interrupción  de usuario para depuración del código en el Business Connnector'
• Activar 'Habilitar puntos de interrupción globales para ejecución de código en el Business Connector o cliente'
• Usuario Ax, opciones
• En la pestaña Desarrollo, Modo de depuración: Mediante el punto de interrupción
• Equipo cliente
• El usuario logeado que va a realizar el debug debe estar en el grupo local 'Microsoft Dynamics AX Debugging Users'

Únicamente nos queda establecer los puntos de interrupción en código alcanzable por las llamadas realizadas desde Visual Studio y tener en ejecución el programa Microsoft Dynamics Ax Debugger, de esta forma cuando lancemos nuestra aplicación VS podremos ver como la ejecución se para en los puntos de interrupción establecidos y trabajaremos normalmente con el Debugger de Ax y VS.

Finalmente recordar que todos estos parámetros deben estar idealmente desactivados en el entorno Producticvo, mejorando así el rendimiento al evitar que tenga que analizar si debe activar el debug

Nota: Los puntos de interrupción globales en principio no son necesarios, salvo que vayamos a trazar código de Enterprise Portal o ejecutado por BCProxy

Ax2012, Ejecutando lógica Ax desde VS mediante Ax.ManagedInterop

Introducción

La interoperabilidad es una de las características fundamentales que a día de hoy debemos exigir a la hora de seleccionar una solución. Expresa la capacidad de comunicarse y entenderse con otros sistemas, proporcionando interfaces para exponer información y, a un mayor nivel, proporcionar acceso a la lógica de proceso. Es igualmente importante que nuestro software sea capaz de "consumir" información y procesos de terceros.

En versiones previas de Ax, como 2.5 y 3.0, existía el llamado Business Connector, que era una DLL que daba acceso a la lógica y a la información mediante unos interfaces generalizados. Su configuración y funcionamiento era compleja y poco intuitiva. Pues bien, todo eso ha cambiado con Ax2012, ahora con las herramientas de desarrollo para Visual Studio el acceso a la lógica es más sencilla e intuitiva ya que nos crea 'proxies' de los objetos de Ax que necesitamos desde Visual Studio, trabajando por tanto de forma 'tipada' e incluso con Intellisense.

Ejemplo básico

El ejemplo consiste en acceder al nombre de un grupo de clientes (CustGroup). Para ello en Visual Studio,

• Crear un proyecto de tipo 'Biblioteca de clases' (Class Library)

• Botón derecho sobre el proyecto, Add to AOT. (Esto añadirá el proyecto al AOT del entorno que tengamos configurado en el equipo sobre el que estamos desarrollando). Una vez añadido verás que el icono del proyecto cambia, apareciendo 
• En la barra de menú de VS, Ver -> Application Explorer. Nos aparecerá una vista del AOT. 
• Seleccionar el objeto al cual queremos acceder y arrastrarlo al proyecto. En este ejemplo la tabla CustGroup. En este momento creará el proxy y añadirá la referencia al Ax.ManagedInterop
• Modificar la clase Class1.cs que se generó con el proyecto, indicando el siguiente código:

using System;

using Microsoft.Dynamics.AX.ManagedInterop;

namespace GCC_VSAOT

{

    public class AxBL : IDisposable

    {

        Session session;

        public AxBL()

        {

            session = new Session();

            session.Logon(null, null, null, null); //Conectará a la empresa y configuración por defecto del usuario

        }

        public string _cName(string _cu)

        {

            CustGroup cu = new CustGroup();

            cu = CustGroup.find(_cu);                 //Al tener ya creado el proxy nos aparece la clase y sus métodos

            return cu.Name;

        }

        public void Dispose()

        {

            session.Logoff();

        }

    }

}

• Crear un proyecto de tipo 'Aplicación de consola' (Console Application)
• Añadimos una referencia a nuestro proyecto anterior, en mi caso llamado GCC_VSAOT
• Modificar el Program.cs, dejando el siguiente código:

using System;

using GCC_VSAOT;

namespace GCC_VSAOT_ConsoleTest

{

    class Program

    {

        static void Main(string[] args)

        {

            AxBL bl = new AxBL();

            Console.Write(bl._cName("CU"));     //Pasar un código de Grupos de Cliente

            Console.ReadKey();

            bl.Dispose();

            using (AxBL bl2 = new AxBL())           //Con using al ser IDisposable hará el Dispose al final del bloque

            {

                Console.Write(bl2._cName("CE"));    //Pasar un código de Grupos de Cliente

                Console.ReadKey();

            }

        }

    }

}

Problemas

1. Al compilar el proyecto de consola. Solución: Establecer .Net Framework 4 como framework destino (igual que el proyecto de librería) y no .Net Framework 4 Client Profile
2. Al ejecutar. Solución: Añadir al proyecto de consola un App.Config, con lo siguiente:

<?xml version="1.0"?>

<configuration>

  <startup useLegacyV2RuntimeActivationPolicy="true">

    <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.0"/>

  </startup>

</configuration>

Más detalles sobre estos y otros problemas con la conectividad Ax-VS visita el blog de mi compañero Juanma, http://www.overflowexception.es/

Ax2012, Fechas UTC y DateTimeUtil

Esta versión de Ax ha incorporado un nuevo mecanismo de validez temporal (date effectiveness) de los registros, permitiendo en las tablas añadir este mecanismo para mantener la información pasada, presente y futura, sin conflicto entre ellas.

Este nuevo mecanismo almacena las fechas en formato UTC, y hemos de tener muy presente este aspecto si no queremos llevarnos sorpresas, ya que la función validTimeState trabaja con las fechas UTC.

Ejemplo: Si estamos en España e introducimos como valor inicial de un registro 01/04/2013 10:10:10, el sistema almacenará en SQL 01/04/2013 08:10:10 (dos horas menos), aunque siempre nos mostrará la primera en formularios e informes, ya que aplica la diferencia horaria.

Los problemas pueden venir por dos vías:

1. Si leemos la tabla directamente en SQL y no tratamos el valor de fecha, nos parecerá que el registro entró en vigor a las 08:10:10.
2. Si accedemos vía x++ pero construimos la fecha y hora por código para la función validTimeState y no la pasamos a UTC, podemos estar leyendo una información incorrecta.

Para clarificar el problema y conocer las funciones que nos ayudarán a trabajar con fecha UTC tengo preparado el siguiente JOB:

static void GCC_ValidezTemporal(Args _args)

{

    utcDateTime             utcDatetimeUsr,utcDatetimeUTC;    

    date                    _date;

    TimeOfDay               _time;    

    int                     timezoneOffset;

    

    ;

    info(strFmt("Fecha UTC mínima: %1 (no se representa pero es 1900-01-01T00:00:00) y máxima: %2",DateTimeUtil::minValue(),DateTimeUtil::maxValue()));

    

    utcDatetimeUsr = str2datetime("01/04/2013 10:10:10",123);

    utcDatetimeUTC =  DateTimeUtil::newDateTime(DateTimeUtil::date(utcDatetimeUsr),DateTimeUtil::time(utcDatetimeUsr),DateTimeUtil::getCompanyTimeZone());

    timezoneOffset = DateTimeUtil::getTimeZoneOffset(utcDatetimeUsr,DateTimeUtil::getCompanyTimeZone());    

    info(strFmt("Fecha para el usuario: %1, Fecha UTC: %2, Offset: %3", utcDatetimeUsr,utcDatetimeUTC,timezoneOffset));

    

    utcDatetimeUsr = str2datetime("31/12/2013 10:10:10",123);

    utcDatetimeUTC =  DateTimeUtil::newDateTime(DateTimeUtil::date(utcDatetimeUsr),DateTimeUtil::time(utcDatetimeUsr),DateTimeUtil::getCompanyTimeZone());

    timezoneOffset = DateTimeUtil::getTimeZoneOffset(utcDatetimeUsr,DateTimeUtil::getCompanyTimeZone());    

    info(strFmt("Fecha para el usuario: %1, Fecha UTC: %2, Offset: %3", utcDatetimeUsr,utcDatetimeUTC,timezoneOffset));

    

    _date = mkDate(01,04,2013);

    utcDatetimeUsr = DateTimeUtil::newDateTime(_date,_time);

    info(strFmt("Fecha creada desde DMY (la que el usuario ve): %1",utcDatetimeUsr));

    utcDatetimeUsr =  DateTimeUtil::newDateTime(DateTimeUtil::date(utcDatetimeUsr),DateTimeUtil::time(utcDatetimeUsr),DateTimeUtil::getCompanyTimeZone());

    info(strFmt("Su correspondiente UTC: %1",utcDatetimeUsr));    

    utcDatetimeUsr = DateTimeUtil::applyTimeZoneOffset(utcDatetimeUsr,DateTimeUtil::getCompanyTimeZone());

    info(strFmt("Volvemos a la fecha según la ve el usuario: %1",utcDatetimeUsr));        

}

Sabios consejos de Warren Buffet

Gestión de proyectos, Marco conceptual

Trataré de resumir los conceptos fundamentales en la disciplina de Gestión de proyectos (Project Management) (fuente principal, PMBOK 4)

¿Qué es un Proyecto?

Un proyecto es un esfuerzo temporal (con inicio y fin) para crear un resultado único. Normalmente se elaboran de forma gradual, por fases o etapas, para una mejor organización de los trabajos.
Su nacimiento suele estar ligado a la respuesta a:

• Demanda del mercado u organización
• Avance tecnológico
• Cambios legales 

Operaciones vs Proyectos

Las operaciones son continuas y repetitivas, mientras los proyectos son temporales y únicos.

Ejemplo: La implantación de un nuevo procedimiento de copias de seguridad en una compañía sería un proyecto. La llevanza o motorización del funcionamiento de ese procedimiento de copias de seguridad formaría parte de las operaciones del departamento responsable de las mismas.

Ciclo de vida

Normalmente los proyectos se dividen en fases para facilitar su gestión. Habitualmente en cada fase se hace más hincapié en ciertos procesos o tareas. Es muy importante siempre formalizar las fases de inicio y fin. Por otro lado, resaltar la diferencia entre el ciclo de vida del proyecto, y el ciclo de vida del producto final, este último ciclo podría desembocar en nuevos proyectos de mejora o actualización, pero estos no forman parte del proyecto inicial. Gráficamente:

Dirección de proyectos

Consiste en la aplicación de conocimientos, habilidades y herramientas para satisfacer los requisitos del proyecto. El director del proyecto será el responsable de guiar el proceso hacia la consecución de los objetivos, su trabajo incluye:

• Establecer objetivos claros y posibles de realizar
• Identificar los requisitos
• Equilibrar las demandas concurrentes de requerimientos (alcance), tiempo, costes y calidad
• Adaptar las especificaciones, planes y enfoques a las expectativas de los interesados

Para realizar su trabajo correctamente el director de proyectos debe conocer:

• Fundamentos de la dirección de proyectos. (metodología)
• Conocimientos del ámbito de aplicación de proyecto. (comprensión funcional del proyecto)
• Conocimiento del entorno del proyecto (ámbito social, cultural, físico, político relacionado)
• Conocimiento generales de dirección (Gestión financiera, marketing, compras,...)
• Habilidades interpersonales (Muy importante! Influencia en la organización, liderazgo, motivación, gestión de conflictos y problemas, negociación)

Los interesados

Se trata de todas aquellas personas u organizaciones que pueden verse vinculados o afectados por el proyecto. Es importante recalcar que es posible que implique no sólo al personal interno de la organización. Podríamos definir las siguientes figuras:

• Director del proyecto. La persona responsable de dirigir el proyecto.
• Patrocinador. La persona o el grupo que proporciona los recursos financieros, monetarios o en especie, para el proyecto.
• Cliente/usuario. La persona u organización que utilizará el producto/servicio del proyecto.
• Organización ejecutante. La empresa cuyos empleados participan directamente en el trabajo del proyecto.
• Miembros del equipo del proyecto. El grupo que realiza el trabajo del proyecto.
• Equipo de dirección del proyecto. Los miembros del equipo del proyecto que participan directamente en las actividades de dirección del proyecto.
• Influyentes. Personas o grupos que no están directamente, pero que, debido a su posición o relación con la organización del cliente u organización ejecutante, pueden ejercer una influencia positiva o negativa sobre el curso del proyecto.

Ax 2012, Que hay de nuevo viejo!!

A finales de 2011 empecé a buscar y leer información acerca esta versión de Ax. Desde una óptica con origen de Ax 3.0, me llamó la atención:

1. Nuevo modelo organizacional. Basado en entidades legales (compañías), entidades operacionales (centros de coste, unidades de negocio...) y la definición de jerarquías entre ellas.
2. Seguridad. Totalmente nueva, desaparecen los conceptos de grupos de usuario y dominios. Se integra completamente con Active Directory, y se basa a nivel funcional en Roles y Deberes, y a nivel más técnico en Privilegios y Permisos. Para las restricciones a nivel de registro se crean las Políticas, la anterior seguridad a nivel de registro se anuncia que quedará discontinuada.
3. Office add-ins. Permite la exportación e importación de información desde Excel. Esto es factible, pero dado el complejo modelo de datos, es muchos casos no es una solución operativa para el usuario común.
4. Workflow. Permite la definición de flujos de trabajo e información, baso en Windows Workflow Foundation del .NET Framework. Se mejora respecto a Ax2009, aunque para mí que parto de Ax 3.0 es completamente nuevo.
5. Global Address Book. Libreta de direcciones global. Permite definir de forma única información de contacto de las entidades tipo Cliente, Proveedor,...La idea es muy buena, se trata de no duplicar información, aunque añade un plus de complejidad a la hora de obtener información, especialmente si se hace directamente vía SQL.
6. Enterprise Portal. Totalmente renovado (otra vez!!!). Muy integrado con SharePoint
7. Interfaz de usuario. Respecto a Ax 3.0 supone un cambio radical, aparecen muchos controles visuales adicionales y provee de soporte para controles externos Windows Presentation Foundation
8. Modelo de objetos en SQL Server. Desaparecen los ficheros .AOD (información de los objetos de la aplicación) y .ALD (etiquetas de texto), pasando a almacenarse todo en SQL Server. Esto implica una mayor facilidad a la hora de realizar las copias de seguridad y mantener varios entornos, ya que todo lo necesario está en SQL Server.
9. Desarrollo
• Nuevo entorno diferenciado y aislado de la interfaz de usuario
• Mejorado el editor de X++, se basa en el de Visual Studio 2010
• Integración total con Visual Studio 2010. Managed code, proxies para desarrollar en VS empleando objetos de Ax, posibilidad de añadir control de código fuente...
• Interoperabilidad: Servicios AIF y un Business Connector muy mejorado.
• Informes. Se trasladan a SQL Server Reporting Services, aunque la lógica de negocio se sigue implementando en Ax. Aún se mantiene la posibilidad de desarrollar informes en MorphX, pero parece que esta posibilidad irá desapareciendo.
• Normalización en las tablas. Se emplea masivamente los RecId, esto en ocasiones proporciona dificultades a la hora de "entender" la información de una tabla.
• Herencia de tablas. Permite definir tablas que heredan de otras, teniendo las heredas acceso a la información genérica del padre, más la especifica.
• Validez temporal (Date effectiveness). Se añade un mecanismo para poder dotar a las tablas de la gestión de datos pasados, presentes y futuros.
• Unit of work. La idea es crear un paquete de transacciones y realizarlas de forma conjunta, reduciendo el número de transacciones contra el AOS y BBDD y por tanto mejorando rendimiento.
• Otros cambios
• TempDB Tables. Persistidas temporalmente en TempDB de SQL Server, en ciertos escenario mejora el rendimiento respecto a tenerlas In Memory
• Deshabilitar funcionalidades no eliminará las tablas y campos en SQL. Igualmente, si creamos objetos directamente en SQL no serán eliminados al sincronizar el modelo de datos.
• Columnas de tipo Include en los índices, interesante para rendimiento
• Permite usar Full Text Index, interesante para campos con gran información de texto.
• Columnas calculadas en vistas, trata de evitar el RBAR (row by agonizing row), mejorando el rendimiento
• QueryFilter como mejora de QueryRange
• Eventing. Mecanismo para poder lanzar lógica asociada a un evento, como por ejemplo la ejecución de un método

Esto fue mi primera toma de contacto centrándome en los aspectos técnicos, desde luego el "choque" funcional y de usabilidad respecto a Ax 3.0 también se ha demostrado importante, especialmente en módulos como Contabilidad general y Recursos Humanos, pero bueno esas experiencias trataré de ir relatándolas en siguientes artículos.

Post #1. Empieza el viaje

Motivación

Llevo varios años con el propósito (hasta hoy incumplido) de 'abrir' un blog e ir documentando en él mis vivencias, reflexiones e intereses.

Mi deseo es que este blog me sirva para plasmar lo que vivo, aprendo e intuyo, y esperando que a cualquiera que pase por él le pueda parecer interesante y con suerte enriquezca el contenido con sus comentarios.

Contenido

Inicialmente escribiré sobre:

• Vida: Relataré mi visión de lo que sucede en mi país, España, y en el mundo en general. En este apartado incluiré las reflexiones y opiniones que surgen del PLO, que a su debido tiempo explicaré que es.
• Tecnología: Me gano la vida gracias a esto, así que trataré darle bastante importancia. Contaré acerca de mis proyectos, las tecnologías con las que trabajo y todo aquello que me llama la atención de este mundillo.
• Management: También es parte importante de mi trabajo y posiblemente hacia donde vaya mi carrera, aunque ya se sabe que el futuro es incierto. En este apartado incluiré mis pensamientos sobre artículos, libros y material que leo al respecto.

En un futuro me gustaría añadir un apartado más, relacionado con 'Ideas de negocio'. Me gustar pensar e imaginar nuevos productos o servicios, y quien sabe si algún día pueda lanzar alguno de ellos.

De forma general quisiera invitar a cualquier persona a poder escribir en este blog, así que si tienes un artículo y te gustaría incluirlo aquí, será un placer recibirlo. Si me parece adecuado será publicado, siempre bajo tu permiso y especificando tu autoría.

Concluyendo

Inicio aquí mi andadura como blogger, pero no puedo cerrar este primer artículo sin agradecer todo lo que he vivido y me ha sucedido hasta ahora, y por tanto doy las GRACIAS a todos los que me quieren, los que siempre estáis ahí.