Download Swagger file | Note: follow instructions here to setup your own local and self-hosted liteweight RCSU for using the TRY function for each API
d365commerce
D365 Commerce Swagger V9.49.24090.3 [10.0.39]
Download Swagger file | Note: follow instructions here to setup your own local and self-hosted liteweight RCSU for using the TRY function for each API
D365 Commerce Swagger V9.46 [10.0.36]
Download Swagger file | Note: follow instructions here to setup your own local and self-hosted liteweight RCSU for using the TRY function for each API
Reconciling Adyen vs D365 Payment Transactions
D365 F&O/Commerce offers an out-of-box Adyen payment connector for use In-Store (“card present/card not present”), in Call centers or Online (“card not present”). When payments are physically captured through this connector, both ‘sides’ (Adyen and D365) capture ‘evidence’ for the physical transaction. In many situations it can be hepful to reconcile this ‘evidence’. For example, when a 3rd party E-commerce solution and D365 Store Commerce App both go through an Adyen Merchant account, when payments have been captured offline (so by manually inputting an amount on the Adyen payment device) or simply to proof that all Payments and related Sales have made it into D365 F&O HQ.
In this blog post I’ll describe how you can reconcile the Payment transactions between Adyen and D365 F&O.
Read the full story here in my Linkedin article
D365 Commerce + IOM = SUPERPOWER!
Microsoft Intelligent Order Management (IOM) is a powerful solution for effectively orchestrating Order Fulfillment scenarios.
D365 Commerce is D365 Finance & Operations plus the Headless commerce engine with more than 400+ Commerce APIs and a local database which is installed on a separate Retail Cloud Scale Unit.
The combination of IOM + D365 Commerce offers next level capabilities for any Retail Enterprise 🚀.
In below video I’ll demonstrate an integrated scenario in which Orders from an E-commerce platform are orchestrated in IOM and fulfilled via D365 Commerce.
Why I am a fan of a Single Company setup for Retailers in D365 F&O
Implementing D365 F&O requires some specific Design considerations when it comes to Retail organizations. A Retail company is not simply organized by Legal entities which transact with each other and 3rd parties. A Retailer has one or more brands to protect. Consumers expect the same brand experience anywhere anytime. This experience cannot have interference from legal entity boundaries or the way an ERP system is configured.
Too often, I see D365 F&O Solution Architects and Consultants automatically translate a Retailer’s subsidiaries to companies in D365 F&O. Even if this does not align with the way the Retailer is organized (central backoffices) and/or their logistics model is setup (hub and spoke). But first and foremost, it can shatter Order fulfillment into pieces and significantly raise operational complexity and overhead with detrimental impact on the Customer Journey..
IS THERE AN ALTERNATIVE FOR THIS?
Read the full story here in my Linkedin article
D365 Commerce Swagger V9.42
Download Swagger file | Note: follow instructions here to setup your own local and self-hosted liteweight RCSU for using the TRY function for each API
D365 F&O/Commerce interfacing via Azure API Management: My Best Practices
I am seeing more and more customers and partners who actively promote the use of Azure API Management for D365 F&O backend and/or D365 Commerce Scale Unit ODATA interfacing. See for example, this blog post by Adrià Ariste Santacreu. However, there’s still a significant number of customers and partners who shrug their shoulders while thinking: “Why would we use it when we can interface ‘directly’?”. In this blog post I’ll address this question by sharing my best personal best practices in using Azure API Management for D365 F&O backend and/or D365 Commerce Scale Unit ODATA interfacing. But before sharing the best practices, we first have to explode the myth that interfacing via Azure API Management (APIM) would not be DIRECT.. 😉.
Read more