D365 Commerce Swagger V9.46
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
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 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
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.
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
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
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 moreIn most projects, customers and partners are deploying Build and DEV boxes from LCS\Cloud hosted environments. These utilise multiple Azure resources such as storage accounts, virtual network and virtual machines. In many cases, the LCS environment is working against only 1 Azure subscription which is eventually used to host the PROD environment as well. If this is the case, you can potentially save your customer quite some money. In this blog post, we’ll see how much and how!
Read moreEver since D365 Finance & Operations V10, we’re in the Managed Updates model which aligns all Customers on a similar Platform Version – It’s the so called “One Version” strategy which brings a lot of benefits. But is there really ONE VERSION in reality? We have License keys, Parameter modules, SysFlighting and Feature Management which already contains 250+ Features in V10.0.11 PEAP. Did you all enable them? If you sum all these parameters, D365 Finops installations can fundamentally differ even if the underlying Platform version is similar.
Now with D365 Retail (Commerce) there is yet another variable – A relatively new Retail/Commerce Parameter area which is controlling Retail functionality behind the scenes… In this blog post we’ll dig out all the Features that can be enabled from here. Fellow Functional and Technical D365 Retail/Commerce consultants sit tight: this area is likely to become more and important in the future. It can also be really helpful for your own customisations.
Read moreAfter walking through the overall D365 Retail API Architecture in part I and II of this series on the D365 Retail APIs, it’s now time to enable anyone to actually use the Retail APIs. To allow this, this blog post will contain all details on how to construct a request to most of the 400 out-of-box D365 Retail APIs – Beyond that, I’ve included a step-by-step instruction on how to use any of the Retail APIs from Microsoft Power Automate (Flow).
But before we can really get things rolling, we first need to apply some additional D365 setup and we need to choose the right security pattern. So that’s where I’ll start this blog post.
Note: to effectively consume the content of this blog post, please ensure to familiarise with the content of Part I and Part II.
Read moreIn any of our D365 Implementation Projects, Solution Prototyping is one of the most important aspects of the implementation. On the one hand this Prototyping serves a common Requirement to find a solution which stays closest to Standard D365 – A Requirement often raised by small to medium sized Retailers. On the other hand, Prototyping let us fully understand D365 Retail which allows us to write the best designs for Custom solutions – An exercise which is often required for the bigger Retailers.
Solution Prototyping is most commonly done from ‘Sea level‘: by setting up D365 Retail in different ways to support variations to a Process which are then evaluated (often in playbacks to Business key users) against Process maps and related Requirements. I think this is a very good and effective way to make progress in a project while still making the right Design Decisions.
However, there are cases in which this ‘Sea level’ approach is either very time consuming or not giving you the confidence that you’ve completely bottomed out the D365 Retail capabilities to support a certain process. You probably recognise this from working on complex Processes which are Retail/Omni related, D365 MPOS/commerce customisations or Retail Integrations. For these cases, you need another approach which I’ve named the ‘Engine Room‘ approach: this approach first descends into the ‘Engine Room’ of D365 for Retail to know exactly what happens there before you work yourself up to ‘Sea level’ again to pick the best Solution for your Use Case. In this blog post, I’ll unveil all the tricks to be able to do this quickly and effectively.
Note: please ensure to familiarise with the D365 Retail API Architecture as per Part I of this series on D365 Retail APIs before you read any further.
Read more