Data distribution
Data distribution in Commerce is based on Commerce Data Exchange, which transfers data between Commerce Headquarters and the different channels.
The database that stores data for a channel is separate from the Commerce database. The channel database holds only the data that is required for transactions. For example, master data is set up in Headquarters and then distributed to channels; on the other side of the transaction, transactional data is created in the Store Commerce or the online store and then uploaded to Headquarters.
The different components that help data be distributed between the source and the target system are:
Async service – The packaging of data at the source (the headquarters) is the process of preparing it for distribution. This process happens separately from the process of sending this data to the different channels and applying the changes to their databases. Async service uses the Commerce scheduler to schedule data distribution with upload and download jobs.
Microsoft SQL Server change tracking on the Commerce database – Is used to determine data changes that should be sent to the channel.
Commerce scheduler – A mechanism to exchange data between locations through scheduled batch jobs.
Real-time service – Provides real-time communication between a channel and Dynamics 365 Commerce for scenarios in which the data must be available in real time, such as inventory lookups, issuing and redeeming gift cards, creating and updating customer records, and more.
Consistency in payments management across retail channels
Retailers want to offer the same quality of service to customers across all platforms, while also ensuring that back-office staff have a clear experience handling retail orders. Any of the retail order processing interfaces must be able to view, modify, and process payment transactions related to sales orders in a consistent manner.
The back-end management of Store Commerce and e-commerce order payments uses the MCRCustPaym* tables. By managing retail sales order payment data in a consistent way, true omnichannel retail order payment management is allowed for call center users.
Archive credit card transaction data
Credit card response data can take up a lot of space in a database. Because this data is mostly needed for performing linked refunds, the usefulness of the data decreases dramatically after the business refund policy for a transaction expires. An archival job automatically archives credit card data when it can no longer be used for linked refunds according to business policy, thus ensuring that only critical data is kept for day-to-day operations.
The archival job can be configured to archive credit card XML authorization response data that is over a certain age. When the credit card data reaches the specified age, the job will compress it into a .zip file and export it via document management. Data cannot be restored programmatically after it has been exported. Because the authorization data subject to export is required for linked refunds, only data older than the linked refund window specified in the company's return policy should be subject to export.
Important
Data can't easily be restored after it has been archived. Therefore, transactions that are subject to linked refunds should not be archived. For example, if a merchant's returns policy allows transactions to be returned for refund to the same credit card within two years, the Minimum transaction age in days field for the job should be set to 730 days (two years). In this case, if a transaction is returned after 730 days, the XML that is required to do a linked refund won't be found. Therefore, the customer will have to be refunded via a standalone refund to either a credit card or some other payment method, such as a credit memo or gift card.
For more information on how to set up the archivable job, see: Archive credit card transaction data