Enhancements to Retail statement posting
Important
This content is archived and is not being updated. For the latest documentation, see Microsoft Dynamics 365 product documentation. For the latest release plans, see Dynamics 365 and Microsoft Power Platform release plans.
| Enabled for | Public preview | General availability |
|---|---|---|
| End users by admins, makers, or analysts |  Aug 2, 2019 |
Oct 1, 2019 |
Business value
In Microsoft Dynamics 365 Retail, the statement posting process is used to account for the transactions that occur in Cloud point of sale (POS) or Modern POS (MPOS). This process is an integral and vital function of a physical store operation because all the transactions in the store in terms of sales, payments, cash movements, and so on for a business day are reflected back to the headquarters (HQ) through this process. All key daily reporting that personnel in the HQ rely on for decision making such as sales by store for a day, collections by store for a day, inventory movements for different products and categories, and so on are made available through the statement posting process.
The statement posting process also plays a pivotal role in the loss prevention function of a retail organization because data from statement posting is used by the sales audit clerks to monitor and track issues and patterns around fraud and loss prevention. Given that, it is imperative that any retail organization with physical stores has a reliable and performant statement posting process.
Feature details
This feature will enhance the current statement posting process in the ways described here.
Data fidelity checker
The reliability of a statement posting process is highly dependent on the quality of the data that feeds this process. This data is generated and sent over from the retail stores based on transactions in the first-party or third-party POS systems. It is often seen that the fidelity of the data that comes from the store is questionable due to factors like bugs in the POS client, which writes inconsistent data to the store database or data brought in from a third-party POS system through the integration framework. This creates issues and bugs in the downstream process of statement postings.
To overcome these challenges, the data fidelity checker will check the data for omissions and anomalies and only those transactions that pass the validation will be included in the statement process. The following are some of the types of validation that the data fidelity checker will perform (this is not an exhaustive list):
Validate that gift card items are not associated with return lines.
Validate that the records in the discount table match the discount amount in the retail transaction line tables for every transaction.
Validate that the amount on the retail transaction payment lines add up to the payment amount on the header retail transaction table.
Validate that the records in the tax table match the tax amount in the retail transaction line tables for every transaction.
The data fidelity checker feature will also allow a user to fix transactions that are not consistent with the expectations set for auditing for traceability and reconciliation purposes.
Trickle feed order creation (Public Preview)
The current statement posting process is managed in two major parts:
Based on the data synchronized to the HQ, an “inventory job” reserves the inventory for products at a defined recurring schedule.
At the end of the day, when the stores are closed and the end-of-day operations are performed in the store, the remaining data is synchronized to the HQ. Based on a defined schedule, the system creates a statement document for every store and, when this statement document is posted, the system removes the reservation for inventory created and then creates sales orders, payment journals, and ledger journals in the system.
As evident from the above points, only temporary inventory reservations are created during the day. These inventory reservations are then removed at the end of the day and all transactions are processed as sales orders; new inventory transactions are created along with other transactions at the end of the day. There is no processing of these transactions happening during the day and all of them are back-loaded to the end of the day. This creates a situation where large transactions have to be processed in a limited time window and results in phenomenal load and locks, which can result in statement posting failures.
To address these issues, the following improvements will be made 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.
Handling of return lines
To ensure that the return lines are posted with the correct return cost, the current retail statement posting process requires the original sale to be posted before allowing the return posting; however, in scenarios where a statement for the original sale is not posted, then the statement associated with the return transaction also cannot be posted. This results in statements getting backed up and involves users trying to figure out the dependency before posting them manually in the correct sequence. To resolve this and not enforce chronological dependency between the statements, the returns will be posted leveraging the inventory costs from the business date of the original sale.
Handling of batch-controlled items
For batch-tracked items, Retail POS does not support the capture of batch numbers at the time of sale; however, batch numbers are required while posting the sales of these products in the HQ. The current statement posting framework picks an already existing batch number at the time of statement posting; however, in scenarios where quantity with batch numbers does not exist for these products, the statement posting process fails even when negative inventory is turned on for these products. This feature will ensure that statement posting is not blocked for batch-tracked items if the inventory is zero or the batch number is not available if negative inventory is turned on for these items.