AX 2012 R2: Visualizar paquetes job P de SynchService

4 03 2015

En el sistema de sincronización SynchService de Microsoft Dynamics AX 2012 R2 for Retail para la sincronización de los datos de AX a tienda y viceversa disponemos de la utilidad Pack View para descomprimir los paquetes que el sistema transacciona entre AX y la tienda y al revés. La herramienta Pack View es extremadamente simple, tan solo es necesario indicar el archivo de la carpeta c:\User\<User>\AppData\Local\Microsoft Dynamics AX\60\Commerce Data Exchange\Synch Service\work que queremos descomprimir y pulsar la opción Convert. La herramienta genera en el directorio especificado una carpeta que contiene todos los XML de los datos y tablas que deben modificarse en el destino.

Sin embargo, hay que tener en cuenta que para poder descomprimir los paquetes de los jobs P que viajan de la tienda a AX hay que realizar un cambio de nombre antes de utilizar la herramienta. Así pues, si queremos descomprimir un archivo de un job P que ha llegado a AX, debemos cambiar la letra I del archivo por una R. Una vez cambiada la letra, podemos usar la herramienta para descomprimirlo. En el ejemplo siguiente se ha copiado el archivo recibido SRVPOS01-432727-I.tmp, cambiando la letra I por una R en el directorio c:\Temp:

Tras realizar la copia he ejecutado el Pack View y como observareis he podido descomprimir el archivo sin problemas:





AX Retail 2012 R2: Indicador de transacciones suspendidas

3 04 2014

La aplicación POS de Microsoft Dynamics AX 2012 R2 for Retail nos muestra en la parte inferior derecha de la pantalla principal un indicador de las transacciones que tenemos suspendidas (mediante la acción Suspender transacción). Sin embargo, cuando utilizamos la acción Suspender transacción en una transacción que tenemos a medias, no nos incremente inmediatamente ese numerador. Del mismo modo, cuando recuperamos una transacción suspendida mediante la acción Recuperar transacción, ese indicador no decrece inmediatamente. Sin embargo, tras cierto tiempo, ese valor se actualiza correctamente.

El motivo de este comportamiento es debido a que ese control se actualiza mediante un control Timer que se inicializa al abrir la aplicación y que está programado para ejecutarse cada 60000 ms o lo que es lo mismo, cada minuto. Por tanto, por mucho que suspendamos o recuperemos transacciones con las correspondientes acciones, ese valor se actualiza cada minuto, no cada cuando realicemos la acción.

Por tanto, si en menos de un minuto suspendemos y recuperamos una transacción (comprobación habitual para ver el funcionamiento de este indicador), el indicador nunca cambiará ;-). Así pues, para comprobar su funcionamiento tenemos que suspender una transacción, esperar un minuto, comprobar que se actualiza el indicador, recuperar la transacción, esperar un minuto y comprobar que el indicador se actualiza nuevamente.





AX Retail 2012 R2: Herramienta de comprobación de la sincronización de datos Offline

17 12 2013

A menudo tras instalar el sistema Offline en un POS de Microsoft Dynamics AX for Retail 2012 R2 nos surge la duda de saber si se han sincronizado los datos por primera vez a la base de datos Offline del POS. En otras ocasiones, tras haber activado el sistema Offline durante un tiempo, queremos comprobar si los datos generados en el estado Offline se han sincronizado a la base de datos de tienda. Para ello, tan solo disponemos de la tabla RETAILOFFLINESYNCLOG y de los logs (si los hemos activado) del servicio Offline. En Prodware hemos creado una herramienta que nos permite comprobar si los datos de la base de datos Offline de un POS están correctamente sincronizados con la base de datos Offline.

La herramienta Offline Database Comparer, realiza una comprobación de todas las tablas de los distintos ámbitos de un perfil Offline mediante la recuperación del campo clave de cada una de las tablas. A partir de la clave primaria de cada tabla, se compara el contenido de cada tabla en la base de datos Offline con su homóloga en la base de datos de tienda dependiendo de la dirección de sincronización definida en el ámbito del perfil.

La herramienta recupera la información de conexión a la base de datos de tienda y a la base de datos Offline desde el archivo de configuración POS.exe.config. A partir de esta información nos muestra en primer lugar las últimas sincronizaciones de cada uno de los POS de la tienda en la pantalla principal.

Una vez aceptadas las cadenas de conexión, la aplicación ejecuta una comprobación por cada una de las tablas de cada ámbito del perfil Offline asociado al POS, mostrándonos como resultado una tabla en la que, para cada tabla nos indica si todos los registros de una misma tabla del ámbito están en ambas tablas según la dirección de sincronización determinada en el ámbito.

Offline Database Comparer es una aplicación Windows Forms desarrollada en C# que se instala fácilmente mediante XCOPY en el directorio de la aplicación POS.





AX Retail 2012 R2: Error al instalar CU1 o KB

13 06 2013

Al intentar actualizar un terminal POS con el Cumulative Update 1 o cualquier KB posterior, obtenemos un error si el POS y el usuario con el que iniciamos la sesión en Windows no pertenecen a un dominio.

En general los POS no tienen por qué estar en un dominio por lo que este aviso puede ser habitual que nos aparezca. Para solucionar el problema, podemos proceder del siguiente modo:

1. Ir a Computer/Properties

2. Ejecutar el link Advanced system settings

3. Abrir la opción Environment Variables…

4. Crear una nueva variable con el siguiente nombre y valor:

UserDnsDomain TEST

5. Abrir el registro de Windows (regedit)

6. Editar la variable siguiente de la entrada HKEY_LOCAL_MACHINE/SYSTEM/ControlSet001/Control/ComputerName/ActiveComputerName

ComputerName TEST (Guardar el valor antes de modificar porque deberemos volver a su valor original tras la instalación)

7. Ejecutar la instalación de CU1 y los KB que queramos instalar

8. Una vez finalizada la instalación, eliminar la variable UserDnsDomain y volver la clave del registro a su valor original

 





AX Retail 2012 R2: Crear un skin personalizado

29 03 2013

Una de las características de AX Retail 2012 R2 es la posibilidad de crear un nuevo estilo (skin) para la aplicación POS. Si bien es muy sencillo crear un nuevo skin, debe validarse completamente el comportamiento de cada estilo en el POS tras realizar la personalización. Para personalizar el skin seguiremos los pasos siguientes:

1. Instalamos la aplicación Developer Express v2011 vol 2 específica para AX Retail. Para ello, deberemos adquirir una licencia del producto (necesaria para personalizar el POS de AX Retail) en http://www.devexpress.com y solicitar esa versión específica

2. Una vez instalada la aplicación ya dispondremos de la herramienta SkinEditor, la ejecutamos:

3. Podemos crear un skin desde cero pero, os recomiendo que utilicéis como base el skin por defecto de AX Retail 2012 R2 y a partir de este skin personalicéis lo que necesitéis. Para ello, en primer lugar tendremos que usar la opción File/import para importar la librería por defecto de skins de AX Retail 2012 R2. Encontrareis la librería de skins por defecto, POSThemes.dll, en el directorio C:Program Files (x86)Microsoft Dynamics AX60Retail POSSkins.

4. Seleccionad el archivo POSThemes.dll tras seleccionar el tipo de archivos Skin assembly(*.dll)

5. Tras realizar la importación, los estilos por defecto de AX Retail 2012 R2 estarán disponibles como plantillas para iniciar vuestro skin personalizado (blue, red, green…)

6. Creamos un nuevo proyecto de skin a partir de uno de los skins importados en el paso anterior. Utilizamos la opción File/New y seleccionamos como Template skin, alguno de los estilos de AX Retail 2012 R2 (gray, green, light, pink, blue o dark):

7. En este ejemplo, hemos nombrado el proyecto como TestSkinTheme y el nuevo skin como TestSkin (este nombre lo usaremos posteriormente en AX HQ para asignarlo a un POS):

8. Una vez creado el proyecto, ya podemos personalizar las características que deseemos. En concreto, quizás el que más os interese personalizar sea el formato del formulario y de los botones, que encontrareis en la opción Common, y el aspecto de las tablas, que encotnrareis en el apartado Grid

9. En el apartado Grid podréis personalizar todos los controles relacionados con las tablas. En nuestro ejemplo hemos modificado algunos colores del background de la cabecera y de las filas y en el apartado Common hemos modificado el color de fondo y de la fuente para ajustar el formato a la imagen corporativa de nuestro cliente

10. Una vez realizados los cambios, Guardamos el proyecto y creamos el ensamblado con la opción File/Create assembly

11. Observaremos que se ha creado un nuevo ensamblado en el directorio donde hemos indicado. En nuestro ejemplo, tras completar el proceso:

12. Comprobamos que se ha generado el ensamblado

13. A continuación vamos a aplicar nuestro nuevo skin a un POS. Para ello, tendremos que añadir el nuevo skin a las opciones de AX HQ. En los perfiles visuales, nos situamos en el perfil visual que queramos personalizar y añadimos el nuevo skin al campo Tema y seleccionamos Ver detalles. En el enumerado correspondiente añadimos la opción TestSkin.

14. Una vez configurado el Perfil visual, podemos sincronizar los datos con el POS y continuar con la configuración del skin en el POS.

15. Para configurar el POS, debemos copiar el ensamblado del skin en la carpeta C:Program Files (x86)Microsoft Dynamics AX60Retail POSSkins

16. Tras copiar el ensamblado y haber sincronizado la configuración del Perfil visual, al iniciar la aplicación veremos que utiliza nuestro nuevo skin

17. Podemos probar directamente el skin modificando el campo POSSKINNAME de la tabla RETAILVISUALPROFILE en la base de datos de tienda. De este modo no tenemos que modificar el visual profile en HQ. Sin embargo, una vez validado, deberemos aplicarlo en HQ para que cuando se sincronice el JOB correspondiente no nos sobrescriba ese cambio





AX Retail 2012 R2: Como modificar los numeradores (seed values) en POS

27 02 2013

En Microsoft Dynamics AX 2012 R2 los numeradores se registran en la tabla POSSEEDVALUES de la base de datos de tienda. Sin embargo, si por algún motivo (probablemente para una migración desde 2009) deseamos alterar alguno de los valores de esta numeración nos encontraremos en que no es suficiente cambiar el valor del numerador en esta tabla. A continuación describimos los pasos a realizar para alterar una de las numeraciones almacenadas en POSSEEDVALUES.

Aparentemente, modificando el valor de la tabla POSSEEDVALUES para un tipo de numerador especifico, por ejemplo el TYPEID = 2 que corresponde al tipo ReceiptSale (Ventas), debería cambiar la numeración del ticket de la siguiente transacción. Sin embargo, comprobamos que a pesar de modificar ese valor, POS recupera el valor anterior incrementándolo. Pero, ¿de dónde obtiene la numeración anterior?. En primer lugar podríamos pensar que lo obtiene a partir de una búsqueda del máximo número de ticket, sin embargo, esto sería bastante complicado pues esa numeración se utiliza en la máscara correspondiente al formato de numeración de ticket.

Pues bien, tras investigar el procedimiento usado para recuperar el siguiente valor del numerador correspondiente a uno de los tipos de numerador (a partir del código del service Application) hemos descubierto que localmente POS guarda el último numerador en un archivo encriptado en un LocalStorage. En concreto el archivo lo podéis encontrar en una ruta aleatoria en el path c:ProgramDataIsolatedStorage… El path concreto debéis localizarlo realizando una búsqueda del archivo donde se almacena esos datos que se llama RetailPosSettings.config.

Por ejemplo, en mi portátil, la ubicación del archivo es:

C:\ProgramData\IsolatedStorage\3adcmvnc.yhyroqnoco1.13j\Publisher.m5qskfiokkoxzszdm3chhfwlcduqzom2\AssemFiles

Así pues, si queremos alterar la numeración de algún tipo de numerador en POS, debemos seguir los siguientes pasos:

  1. Localizar el archivo RetailPosSettings.config en el path C:\ProgramData\IsolatedStorage
  2. Renombrar o eliminar el archivo RetailPosSettings.config
  3. Alterar el numerador correspondiente en la tabla POSSEEDVALUES para el terminal del que queramos modificar el numerador. Los tipos de numerador (TYPEID) disponibles se muestran en la siguiente tabla
  4. Iniciar el POS en el terminal y realizar una acción que utilice el numerador (por ejemplo, si modificamos el numerador con TYPEID=2 podemos realizar una venta normal) y observar que ya ha recuperado el nuevo numerador

Tipos de numerador

ReceiptDefault 1
ReceiptSale 2
ReceiptReturn 3
ReceiptSalesOrder 4
ReceiptSalesInvoice 5
ReceiptPayment 6
BatchId 7
TransactionId 8
ReceiptCustomerSalesOrder 9
ReceiptCustomerQuote 10

No he encontrado ninguna información ‘oficial’ de Microsoft sobre cómo realizar este proceso de renumeración por lo que la solución que se propone en este artículo es completamente ‘no soportada’ y se ofrece tal cual, sin ningún tipo de responsabilidad sobre los efectos que pueda producir sobre cualquier instalación de POS.





AX Retail 2009: Control del password de usuario en POS

30 04 2012

Una de las características importantes del POS de AX Retail 2009 es la utilización de Transaction Service para realizar operaciones desde el POS al BackOffice. Una de estas operaciones remotas puede aplicarse a la validación del password de usuario (LogOn). Sin embargo, una configuración específica de este servicio puede tener como consecuencia que el usuario pueda entrar en el POS sin que se valide su clave de usuario, o lo que es lo mismo, que el POS no tenga ninguna validación de la clave del usuario. A continuación describimos brevemente esa situación. Entendemos que esto se trata de un bug de la aplicación (por lo que así lo hemos reportado), sin embargo, mientras esa solución no llega, consideramos importante tener en cuenta la configuración que explicamos a continuación.

En la configuración del Perfil de Transaction Service disponemos de un check que permite indicar si la validación de la clave del usuario se realizará en el equipo local o bien a través de Transaction Service contra el BackOffice.

Si marcamos este flag, debemos tener en cuenta que la validación de la clave se realizará en BackOffice por lo que debemos asegurar la conexión entre el POS y el BackOffice y que el servicio Transaction Service funciona correctamente. Si alguno de esos aspectos falla, la validación del usuario no podrá realizarse por lo que el usuario no podrá acceder al POS tras esperar un tiempo a que el sistema detecte el fallo de conexión y, apareciendo el siguiente mensaje:

Para evitar esta situación, con el flag de autenticación por Transaction Service, uno puede usar otro parámetro de configuración a nivel de usuario que permite obviar los mensajes de error de Transaction Service. Si, manteniendo el flag de autenticación por Transaction Service, marcamos la opción de continuar con errores en Transaction Service en un usuario:

Al intentar acceder al POS, el sistema intentará validar la clave en BackOffice a través de Transaction Service, si encuentra un error lo evitará y accederá al POS sin haber validado la contraseña!!!.

Por tanto, es muy importante que, a menos de que el fabricante aporte otra solución, no se realice la autenticación del usuario en BackOffice a través de Transaction Service y se utilice la autenticación local, es decir que NO se marque el flag de Personal de Retail Transaction Service (traducción poco acertada por cierto…).