Retail statements are one of the most important (and complex) processes a retailer have. It’s where the retail sales and transactions are being transformed to become physical and financial transactions so you can see the sales in finance and in inventory. Retail statement calculation and posting have been covered many times in my blog posts and Microsoft have a large set’s of article on doc’s on the matter. The amount of transactions retail statements calculates and post is to my knowledge THE most complex and intense feature and business process in the entire Dynamics 365 solution. Imagen that every sale, in every store is being processed. For larger retailers Dynamics 365 for Retail are processing millions of transactions daily. This area really put’s computational pressure in the systems and is also one of the areas where Microsoft is investing heavily.
Since the start of D365 there have been done hundreds of improvements on retail statement posting, and the next “big thing” is Retail Statement trickle feed. One of the pain’s in today’s solution is a significantly delay between the when the retail sales have been conducted, and when the inventory transactions have been financially posted. And in short, when the inventory transaction gets a financial status like “Sold”. Why is this important? Because the inventory transactions define on-hand values, as again it defines how the master planning/replenishment is calculated. We want this to be as accurate and up to date as possible. Any delays in having accurate on-hand influences planned purchase orders. Also the ability to spread out the processing of transactions through the day will reduce the amount of “spikes” in the Azure SQL load, making the nightly timeslot more open for other high intensive transaction processing tasks.
Another critical benefit of trickle feed is the decoupling of transactional statements and financial statements. Now you can post transactional statements without even posting a financial statement, and the other way around. Together with the increase of posting frequency that produce small bundles of transactional statements, it will address the main reason for the compounding effect that prevents a series of statement from being posted due to a single invalid transaction. Right now, the only validation that impact financial statements is that all retail transactions for a given shift must be present in HQ in order for a financial statement to be posted. However the transactions don’t need to be successfully posted for a financial statement to be posted.
There is also a new aggregation strategy, where unnamed transactions are always aggregated and named(customers) transactions are never aggregated. There is no more option available to turn aggregation on or off.
Microsoft have made the following improvements to the statement posting process:
Deprecate the “inventory job” that creates temporary reservations.
Create a new job that will, at a predefined schedule, create sales orders, invoice them, and create, post, and apply payments for all the transactions that are synchronized to the HQ at that point of time. In addition, it will also create any ledger journals that need to be created for discounts, gift cards, and so on.
The statement document that gets created at the end of the day will only be used to calculate and post any counting variances.
To enable the new preview (10.0.5) trickle feed solution you have to enable the Retail Statement (trickle feed) – preview configuration key. Also remember to disable the other retail statements configuration keys, and that you don’t have any open statements when doing this.
When finally released (GA) I hope that the new the new feature management is used for enabling this.
When this is done, you will see a set of new menu items. Under the menu \Retail\Retail IT\POS Posting.
The sequence of these batch jobs is to be able to financially post most of the transactions, and the financial statement posting will only be used to calculate and post any counting variances. There is no need to run the “Post inventory” job anymore. But in reality, there is a decoupling, and the transactional statement and financial statement can post independently if the other have not been posted. The only actual requirement is that the P-job have fetched the retail transactions from the retail channel database.
If we look into the Retail Statement form, we now have the possibility to manually create transaction posting and financial reconciliation (That in the essence is the financial statement).
When creating a “Transactional posting”, we see that the form is a bit changed compared how it was before. There a no lines related to payments.
When posting the transactional statement, the following steps are performed:
When calculating and posting a financial statement, you see the more traditional statement posting screen, where you have the payment lines:
The steps in the posting is the following:
The summary of this, is that Dynamics 365 will with trickle feed support a much faster updating frequency to get proper on-hand values and scalability. Since the transaction statement will be running more frequently it also means that there will be less retail statement posting in the evening/night. The transactions will be smaller and therefore also easier to post. But there are a few things to keep in mind. If you trickle feed too often, you will miss out on the transaction aggregation on the unnamed transactions, and will have to process more sales order invoicing per day. This can again slightly increase the load in your system.
This feature will also increase scaling of the system, as posting of transactions can be better load balancing among multiple AOS-batch services. I also have a feeling that there will be more features in this area to come, that will further enable close to real-time master planning, inventory services, and close to real-time power-BI reporting.
Next on customers wish list is a super-duper-fast invoicing service of sales orders(retail), as this still is the most resource demanding task in the processing of retail transactions. It is also in the roadmap the ability for the store manager to perform and generate the financial statement when a shift is closing in POS. The financial statement in HQ in this case will post whatever the financial statement generated in POS defines, breaking the requirement of having all transactions uploaded to HQ db. And beyond this Microsoft is as always improving general performance by working close with customers and partners. We see that the data distribution and different usage of retail statements require different indexes and Microsoft invests heavily in improving how queries are executed.
Great work to the Microsoft team working on the retail statement processing.
Here is a small joke for all of you that don’t care about retail statement posting