Recently one of my colleagues ran into a strange issue. When performing some actions on the POS that involved calling AX 2012 via Real Time Service, the call failed. In another environment with the same code base, the code succeeded. Also, the RTS failure happened only on certain calls, other calls against the same server worked correctly (the specific case: retrieving a previous sales order succeeded, but sending a completed return order to AX failed).
The event log on the RTS machine was quite confusing: the error message was “Cannot create a record in System parameters (SystemParameters). The record already exists.” But there was nothing wrong with the system parameters.
I captured the request from the POS to the RTS and wrote a small job in AX to call the respective class/method directly using the same request and this worked fine. Even more confusing.
The solution came after realising that the Real Time Service uses .NET Business Connector to connect to the AOS. From the architectural perspective, the Business Connector is like a regular AX client without a user interface. Recently the AX environment in question had been updated with new code – but the same code worked fine on another machine. Earlier I had seen weird issues on a regular AX client where the solution was to get rid of the user cache files. And this turned out to be the solution for the RTS too. Continue reading
I have been investigating most of the basic Dynamics 365 for Operations Modern POS (MPOS) & Cloud POS (CPOS) deployment scenarios on a windows 10 platform. Here are my findings showing when you can use the MPOS & CPOS, based on your LAN & WAN connection status and your deployment scenario.
Typical Deployment Scenarios
In all scenarios without WAN connectivity Real-Time service call are not available
If you are working offline in the POS Local only mode at the end of a shift without access to a channel database through the scale unit, it will not be possible to close the shift on the POS device and complete cash management tasks. Continue reading
Whilst the process for adding a field to a channel database and have it populated by AX via the CDX synch engine when data is sent to the channel database is relatively straightforward, the steps required for a “pull” sub job are somewhat longer. Missing some of these steps can lead to a number of outcomes including the synch failing or the data for the extra fields simply not being populated in AX.
To save some of the pain of trying to remember everything that you need to do, here’s a short crib sheet for the steps required. I’m going to use the example of adding a field to the RetailTransactionTable table but this could easily be any of the RetailTransaction* tables. These steps only cover the AX head office changes and not what you need to do to add the fields into the channel database itself (we will cover that in another post some time soon).
- Add the field to the RetailTransactionTable table in the AOT
- Add the field to the RetailTransactionTableX table in the AOT (missing this step will cause an error to be thrown when data is synchronised for this table).
- Modify the RetailTransactionTableX::insertToRegularTable() method, inserting the new field into the two field lists that make up the insert_recordset operation in the method (missing this step will not cause an error to be thrown but the value of your new field will not be persisted to the AX database during the synchronise).
- For AX 2012 FPK & 2012 R2 (missing these steps will mean that the new field will not be included in the sub job transfer field list for the table)…
- Modify the RetailConnSeedDataGenerator.setDRMLocationDesignTableField_01() method to include the new field (if you’re modifying a different table then you will need to find the correct setDRMLocationDesignTableField* method for your table).
- Modify the RetailConnSeedDataGenerator.subjobFields_RBOTransactionTable() method to include the new field (if you’re modifying a different table then you will need to find the correct subjobFields* method for your table).
- For AX 2012 R3 (missing this step will mean that the new field will not be included in the sub job transfer field list for the table)…
- Modify the RetailCDXSeedData_AX63.C_RetailTransactionTable method to include the new field (if you’re modifying a different table then you will need to find the correct C_* method for your table).
- Compile & build the IL (missing this step will mean that the new field will not be included in the sub job transfer field list for the table)
- Click the Retail Parameters –> Initialise button to configure the synch engine with your new field (missing this step will mean that the new field will not be included in the sub job transfer field list for the table)
I’ve previously written about the differences between the original RetailConnSeedDataGenerator class and the set of classes that perform the same function in Dynamics AX 2012 R3. You can find that post here.