Customizing the Retail Transaction Service

Microsoft Dynamics AX 2012 for Retail came with a very powerful feature that I feel is a bit underrated: the possibility to customize the Retail Transaction Service.

The Retail Transaction Service is just a simple Windows Service that sends synchronous requests from the POS to the HQ .Net Business Connector for processing. After the AOS finishes the processing of the data, it returns some data back to the POS.

In Microsoft Dynamics AX 2012 for Retail there are two Classes for the customization: RetailTransactionService and RetailTransactionServiceEx.

The RetailTransactionService Class holds all the standard methods used by the POS like creating a new customer, updating an address or updating a transfer order. These methods represent the basic functionalities of the POS. Of course, if needed customization to these methods can be done.

The RetailTransactionServiceEx Class is there to add functionalities beyond the standard. Just add a new method to this class and you will be able to call this method from the POS. There are a few important notes to make about the methods:

  1. The methods have to be static.
  2. Pick simple parameters when calling the method like strings or integers. For structured data, use an XML.
  3. As return values use a container. Always have a flag to be able to check if the call was successful.

Use the Application.TransactionService.Invoke() method (with the X++ method name and parameters) from the POS side to invoke the newly written method.

Hope you enjoyed my post and in case you have a question don’t hesitate to leave a comment!

Distribution Scheduler for Retail Stores

Microsoft Dynamics AX 2012 for Retail has made a huge step forward in helping partners and clients deploy the AX POS in stores. But how do you keep the POS-DB up to date?

Here comes the Distribution schedule, found under /Retail/Periodic/Retail scheduler/Distribution schedule, in play.

There are 3 types of jobs in the scheduler: A-Jobs, N-Jobs and P-Job. The job number tells you what data the job will replicate on the POS-DB; for example N-1010 replicates everything that is related to Customers and N-1080 replicates everything that is related to Tax information. The different tables that are being replicated on the POS-DB you can see under /Retail/Setup/Retail scheduler/Scheduler job. 

Setup of Scheduler Jobs

Setup of Scheduler Jobs

As you can see from the screenshot, every job is made out of at least 1 subjob (tables) that can be replicated. Here you can create specific jobs, that transfer only the tables that you need. You can also edit existing jobs by enabling or disabling subjobs.

Important to note here is that there are a couple of jobs that seem to repeat, like A-1010 and N-1010. What is the difference between the different job types you might ask? Good question!

  • A-Jobs replicate only changes made to the data in the respective tables since the last time the A-Job has ran
  • N-Jobs replicate the whole table in the POS-DB
  • P-Job replicates the data from the POS-DB in AX (the oposite direction from the A and N-Jobs). Here are the POS transactions, transaction lines, tax information, reason codes etc.

Exactly these A-Jobs are used to keep the POS-DB up to date. Every time there is a new record (or an update) in a table that is relevant to the POS-DB (you can find a list of tables under /Retail/Setup/Retail scheduler/Scheduler subjob) there is a so called Preaction generated. This preaction logs the changes to the tables.  All preactions are saved under /Retail/Periodic/Retail scheduler/Preactions.

These preactions must be then converted into Actions (found at /Retail/Periodic/Retail scheduler/Actions).This can be achieved via a Job found at /Retail/Periodic/Retail scheduler/Create actions. These actions will then be processed by the A-Jobs.

These jobs can run directly or as a batchjob.

Here is a simplified standard walkthrough of the process:

  • A change is made to an existing address.
  • A preaction is automatically generated.
  • At the end of the day there is a batch job that converts the preactions into actions. These preactions are then marked as processed.
  • After that the A-1010 batch job starts and creates a XML file for each table with all the changes.
  • These XML files are created by the Retail Store Connect (RSC) Service. The RSC also packs the files together and sends them to the POS-DB.
  • On the POS-DB the RSC unpacks the file in the respective XML files and writes the changes in the db.

Of course, these jobs can be planned and run multiple times a  day, depending on the needs of the customer.

Hope you enjoyed my post and in case you have a question don’t hesitate to leave a comment!